Conforming - Resolve back to FCP

[Luis Otero]

Hello,

This may have been discussed before (or even in the literature), but would someone care for sharing the best workflow to get the footage corrected on Resolve back to Final Cut Pro?

There are so many output options available. I will export 10bit DPX Sequences to avoid the QT scaling back to 64-940; it was graded with full range 0-1,023.

Just another piece of information: I have Glue Tools to ease the movement of DPXs to FCP.

Please, advise.

[jake blackstone]

If you have Glue Tools, then just use it. GT wraps DPX into QT and DPX appears as a QT in FCP. For this matter with GT DPX appears within OSX as a QT wrapped file, so you can play back DPX files as a QT. In my opinion, this is the best option.
You can also use AJA or BM 10 bit RGB QT codec, which allows to use the full range.

[Luis Otero]

Jake,

Thanks for responding. I want to use the DPX sequences since the final destinations are multiple, so I can still have the highest quality available.

But, this brings me to the questions I have, so let me describe the pipeline and the areas in question:

1. I exported the EDL from FCP (very easy)
2. I ingested the footage based on EDL and graded using Resolve (easy)
3. Graded al full range (0-1,023), so I want to preserve that range, so I will export RGB 10bit DPX sequences.

Now, the unknown: what setting on the export page have to be done (name, prefix, suffix, folder per clip, etc), so when we perform the conforming back to FCP, we can re-link the media to the new sequences?

Thanks for sharing your knowledge...!!!

[mikeburton]

Jake,

Thanks for responding. I want to use the DPX sequences since the final destinations are multiple, so I can still have the highest quality available.

But, this brings me to the questions I have, so let me describe the pipeline and the areas in question:

1. I exported the EDL from FCP (very easy)
2. I ingested the footage based on EDL and graded using Resolve (easy)
3. Graded al full range (0-1,023), so I want to preserve that range, so I will export RGB 10bit DPX sequences.

Now, the unknown: what setting on the export page have to be done (name, prefix, suffix, folder per clip, etc), so when we perform the conforming back to FCP, we can re-link the media to the new sequences?

Thanks for sharing your knowledge...!!!

Do you need individual clips back in FCP? If not just export the entire Master sequence from Resolve and use GT to open it in FCP in a QT wrapper. Are you doing the layback in FCP?

[jake blackstone]

Jake,

Thanks for responding. I want to use the DPX sequences since the final destinations are multiple, so I can still have the highest quality available.

But, this brings me to the questions I have, so let me describe the pipeline and the areas in question:

1. I exported the EDL from FCP (very easy)
2. I ingested the footage based on EDL and graded using Resolve (easy)
3. Graded al full range (0-1,023), so I want to preserve that range, so I will export RGB 10bit DPX sequences.

Now, the unknown: what setting on the export page have to be done (name, prefix, suffix, folder per clip, etc), so when we perform the conforming back to FCP, we can re-link the media to the new sequences?

Thanks for sharing your knowledge...!!!

If you export your project as one file out of Resolve, then there is no need to relink. If you'd like to relink, the you need to export every event in separate folder (folder per clip on the Resolve export page), but as far as keeping the same names, then hopefully someone, who uses Resolve can chime in. I don't really use Resolve...

[Luis Otero]

Well, I am just trying to do the appropriate conforming: clip by clip. How to name and organize it so that media re-link can help us (kind of what Clipfinder does for RC-X). So, we can send it to Compressor to assure no rescaling from 0-1,023 to 64-960.

Any idea if this is now available? If not, I have not done the DPX exporting of the Master Sequence. Any special area to be aware of, or any other pointer?

Thanks!!!

[Tom.Wong]

when you render out, select SOURCE mode, and click up top that says use source suffix, etc. that should have you retain the original file names if you originally conformed NOT using scene detection.

if you are using scene detector to break up the sequence and grade, it will NOT retain the original clip name from the FCP timeline you had.

when you render as source, you might have to have it render to it's own individual folder for every event. It's gonna run into identical file name issues if there are a clips linked to the same source file in the original cut. and they'll end up conflicting if you render to the same folder.

Then when u go back to fcp, you have to relink manually 1 clip at a time to each folder. If it's a very long piece, that's what you have to do.

If anybody knows of a way to export a separate edl based on how you rendered and do a quick import into FCP please chime in, but as far as I know there is no other way. Resolve was designed to be an absolute FINISHING tool. meaning they never really intended it to go back into a NLE. I'm hoping blackmagic comes up with a good solution soon. I had to do this for a hour and 50 minute feature film, and was reconnecting for 10 hours.



export dpx or bm 10 bit rgb to keep full values as Jake mentioned.

[Tom.Wong]

Well, I am just trying to do the appropriate conforming: clip by clip. How to name and organize it so that media re-link can help us (kind of what Clipfinder does for RC-X). So, we can send it to Compressor to assure no rescaling from 0-1,023 to 64-960.

Any idea if this is now available? If not, I have not done the DPX exporting of the Master Sequence. Any special area to be aware of, or any other pointer?

Thanks!!!

make sure you have a lot of hard drive space :)

and if you are using glue tools you should be able to see each dpx sequence as a clip like normal, should be like anything else really. just be sure to spot check the clips (as usual) incase there is a corrupt frame or two.

[Luis Otero]

Tom,

Thanks a lot!!! I know that the relink would be a pain. This is a feature of almost 2 hours. Well, the assistant editors have their work cut out for them...

BTW, I do not have the BMD as an option of the "Option Type" pull down menu...That is weird, isn't it?

[Tom.Wong]

very... i'd check on the BM website and see if they have a codec package for you to use.

yes the assistants will have a LOT of work cut out for them, but when you export into individual folders, it will sequence and name the folders according to the event number and version it is on your Resolve timeline.

so the first clip should be 001, second clip is 002, etc. etc. so they should just be able to go right down the timeline and reconnect one at a time, and just ignore the "media doesn't match original blah blah blah" error final cut will give them.

it's gonna be trick if there are transitions included in the timeline though, I'm not sure how that's gonna look. and they will have no handles either, so you'll probably have to prepare for a bit of headache on that playing around. You might to export certain chunks to keep the transitions, or export out individual clips with handles so they can re apply the transition.

thus I suggest staying with BM rgb/quicktime, and only put out dpx when necessary, like VFX work. they can easily re export to DPX later for a DCP or filmout.

It's gonna be a lot of careful file management, it might get unstable on export too if you aren't careful so you gotta keep an eye on it. Having too long of a timeline can cause strange things to happen, or having too many timelines can cause weird things too...

[Hans von Sonntag]

I don't have any experience with GT and DPX. But I know from many, many projects that FCP has little malicious pitfalls when it comes to RGB. FCP thinks in YUV and DPX are RGB, go figure.

If you have the possibility to conform elsewhere, do it. I bought Smoke for this reason. If your project is a feature film and not a TVC Resolve maybe the right answer. Why not staying there?

If you break down the project into handy chapters of 10 - 20 minutes you can replace the VFX shots in Resolve, add with alpha carrying clips titles, etc... and keep track of your project. Resolve has been THE finishing tool for many well known feature films. Why not for yours?

Hans

Disclaimer: I haven't work with Resolve yet.

[Tom.Wong]

Unfortunately the nature of the business as is now, lot of people don't have their sh*t together like on a hollywood feature film. You're really supposed to END and FINISH in Resolve, but a lot of projects always seem to have "more to do", and coloring as a finishing move is a bit out of their realm.

I had a client that did scaling and reframing in the edit, and they were adamant that I don't do it in resolve, and they wanted 4k quicktimes instead so they can do it themselves because they know exactly how it should be...

there are a lot more reasons too, but it's just how it is. I'm hoping Resolve will get a major update soon that can accommodate more difficult workflows soon...

[Hans von Sonntag]

...I had a client that did scaling and reframing in the edit, and they were adamant that I don't do it in resolve, and they wanted 4k quicktimes instead so they can do it themselves because they know exactly how it should be...



I hope they used FCP for that. FCP is the best software for panscan.

Hans

[jake blackstone]

I'm hoping Resolve will get a major update soon that can accommodate more difficult workflows soon...

What do you propose BM should do in order to achieve this goal?

[Luis Otero]

Guys,

All your information has been very helpful. The reason for DPX is that it is needed for one of the deliverables (DCP).

However, I would love to have available, as I do on other softwares, the BM RGB Quicktime as an option within Resolve, but I don't see it. Would it be called differently? I own BM cards, HD Links, etc. So, I can see and use it in FCP, for example. But oddly not in Resolve (except if it is called differently).

Again, thanks a lot...!!!

[M Most]

Resolve was designed to be an absolute FINISHING tool. meaning they never really intended it to go back into a NLE.

This may not help you, but that is not true at all. Resolve was designed in part to accommodate "traditional" commercial post paths, which have, for years, been based around color grading "select reels" that were then sent back to an online editor and reconformed. That's why it has timeline re-sorting modes that allow sorting by source time code, and it's also why you can do a video playout using either the timeline time code or the source time code and maintain either one on tape.

[Luis Otero]

I got confirmation fro BMD that actually, the codec within Resolve called "QT RGB Uncompressed 10 bits" is the BMD version.

However, the outcome is so different:

ProRes 422 vs RGB UC 10 Bits


Any word of wisdom on what is going on here?

Thanks,

[Hans von Sonntag]

I got confirmation fro BMD that actually, the codec within Resolve called "QT RGB Uncompressed 10 bits" is the BMD version.

However, the outcome is so different:

ProRes 422 vs RGB UC 10 Bits


Any word of wisdom on what is going on here?

Thanks,

What you are experiencing is a phenomenon to which people refer as "Apple's QuickTime Gamma Hell". ProRes 422 is YUV, the BDM codec is RGB and there are many other other pitfalls such as "Automatic Gamma Correction" and individual unpredictabilities.

ProRes4444, encoded in SpeedGrade or elsewhere in RGB, does not shift gamma in SpeedGrade, Shake and Smoke. In FCP it shifts. So far my observations. All other codecs are useless in my experiences.

Because QT is so bad regarding colour consistencies Smoke has a gamma correction tool in its IO Module that can be adjusted to any gamma values for individual compensation. Go figure.

You can create a LUT for compensation. Sometimes a tedious task.

Hans

[Luis Otero]

Hans,

Incredibly, the one that kept the gamma value was the ProRes. The dark one was using the BM RGB Uncompressed, so it does not make any sense.

I was assured by BMD support that the codec within Resolve called "QT RGB Uncompressed 10 bits" is the BMD version, which preserves the scale and the gamma, hence no shifting issue should be experienced.

[Oliver Peters]

If the BMD codec is truly RGB, this makes total sense. If the BMD codec thumbnail you posted is after FCP, then FCP is simply crushing the levels. It expects YUV mapping and isn't properly processing this codec. ProRes4444 is not an RGB codec, like TIFF or JPEG. It is a YUV codec with 4:4:4 color sampling instead of 4:2:2. So levels allow for black/white excursions instead of mapping 0-1023.

Remember that there is no way you can trust the QuickTime Conversion export of a still image from FCP, because it is going through yet another color space/gamma conversion as QuickTime writes the graphic.

- Oliver

[Oliver Peters]

I would add that in the testing I've done, FCP has a very hard time correctly passing a full-swing image. I've had far better luck with Media Composer, believe it or not. Make sure that all of your sequence settings are set to RGB. Nothing 10-bit, 8-bit or high-precision YUV, if you are working in an RGB codec.

- Oliver

[Luis Otero]

Oliver,

Thanks for chime in. Both were directly rendered from Resolve. I never render from FCP. It is for me just a bridge to send footage to Compressor, which does not modify scale or gamma. So, coming directly from Resolve, it is bugging me a lot, in addition of the pressure that tomorrow is the day to start exporting to conform the feature.

I have the reply from BMD that assured me that even though the name contains QT, it is just the wrapper, and that the RGB 10 bit, no scaling-down is assured. However, the test does not support such statement. :emote_hanged:

[Oliver Peters]

It is for me just a bridge to send footage to Compressor

Huh? You don't need FCP for that. Just open directly Compressor. Using the "send to Compressor" function in FCP is completely broken.

Another way to check is to run the results out through BMD's Media Express utility through the Decklink card to an external monitor and see if you get the same results as in FCP.

- Oliver

[Luis Otero]

Oliver,

That is a good idea, and it was already done. We do all our monitoring via HDLink Pro3D, so what we saw through it does not match with the grading in resolve; again, only the ProRes does, which is unheard of.

I just need to reiterate that none of them came from FCP. They are renders direct from Resolve. The use of FC as a bridge to Compressor is for DPX sequences via Glue Tools, which is the outlined pipeline they recommend.

Thanks for taking time to share ideas! :thumbup1:

[Oliver Peters]

again, only the ProRes does, which is unheard of. I'm not tying to belabor the point, but I'm not quite sure why this surprises you. Would you elaborate? Thanks.

- Oliver

[jake blackstone]

Luis.
You have GT, so why aren't you using it? GT is extremely powerful. With GT you can work with Log DPX files and use the built-in LUT to linearize it in real time. It even allows to set the black and white points, if needed. But the whole point of using the GT is to avoid QT altogether untill the final QT render. All GT does is just wraps DPX into QT without affecting anything. If you don't like using GT, I'll take it off your hands:-)

[Hans von Sonntag]

..ProRes4444 is not an RGB codec, like TIFF or JPEG. It is a YUV codec with 4:4:4 color sampling instead of 4:2:2. So levels allow for black/white excursions instead of mapping 0-1023.

Oilver,

Most of your observations are congruent with mine.

But regarding Apple ProRes 4444 you are misinformed. ProRes 4444 exists in both flavours, YUV (Y’, C-B, C-R) and RGB. Which colour space ProRes4444 adopts depends on the source. If you ingest video via SDI you will likely get ProRes 4444 in YUV, if you have an RGB source such as the Red SDK for transcoding you'll get ProRes 4444 in RGB.

For reference please read page 4 on http://images.apple.com/finalcutstudio/docs/Apple_ProRes_White_Paper_July_2009.pdf

ProRes 4444 encoded in RGB does not shift in RGB applications but it shifts in FCP because FCPs current version is designed as a video application. It can read RGB but converts it internally to 8 bit (!) YUV (at least that is my information - but I'm not a FCP software engineer).

Hans

[Hans von Sonntag]

I got confirmation fro BMD that actually, the codec within Resolve called "QT RGB Uncompressed 10 bits" is the BMD version.

However, the outcome is so different:

ProRes 422 vs RGB UC 10 Bits


Any word of wisdom on what is going on here?

Thanks,

I've got the same problems with SpeedGrade. IMHO, it's not a Resolve/BM issue, it's an Apple Quicktime YUV/RGB automatic compensation gamma, matrix, whatnot problem.

If you re-import the ProRes 422 footage into Resolve and compare it to the original graded footage off the R3Ds I bet that a subtle shift is still visible, not to mention the differences in the histogram/RGB parade.

IMO, even a subtle shift is not acceptable. Any gamma shifts render calibrated displays obsolete. Shooting with a camera system that is above 50k (add a few lenses and you'll reach 100k easily) and then finishing with software that screws up colour and contrast is just plain ridiculous.

My experience is that if I stay in RGB all the way in the finishing process I'm safe. That's the reason why ProRes4444 encoded in RGB works well - IF you don't let FCP touch it.

That's the reason why I bypass FCP as a rendering and IO tool completely. I'm not sure how well GT copes with FCP shortcomings in this regard. Maybe Jake can elaborate more on this?

Hans

[Hans von Sonntag]

I just need to reiterate that none of them came from FCP. They are renders direct from Resolve. The use of FC as a bridge to Compressor is for DPX sequences via Glue Tools, which is the outlined pipeline they recommend.


Luis,

have you loaded the dark BM RGB QT back into Resolve? Does it shift in Resolve as well? If so, you either have wrong export settings or BM's own pipeline is somewhat whacky and a reason to file a bug.

How does the dark BM RGB QT look in an other RGB applications, Shake for instance?

In theory the BM RGB QT codec should look like DPX. Like Glue Tools BM wraps the 10Bit RGB frames into a QT wrapper.

Importing an RGB QT into FCP never worked for me. I'm not sure how Compressor handles RGB but I have some hopes that Compressor is not based on YUV. So direct encoding (bypassing FCP) may work.

Hans

[Oliver Peters]

ProRes 4444 exists in both flavours, YUV (Y’, C-B, C-R) and RGB. Which colour space ProRes4444 adopts depends on the source. If you ingest video via SDI you will likely get ProRes 4444 in YUV, if you have an RGB source such as the Red SDK for transcoding you'll get ProRes 4444 in RGB.

Hans,

Thanks for the correction. So far my working with ProRes4444 has been with AE and from Alexa and those have all appeared to by YUV - or at least reacted like YUV. Thanks.

Cheers,
Oliver

[Hans von Sonntag]

Hans,

Thanks for the correction. So far my working with ProRes4444 has been with AE and from Alexa and those have all appeared to by YUV - or at least reacted like YUV. Thanks.

Cheers,
Oliver

Oliver, can you double check the Alexa ProRes files regarding RGB/YUV? Alexa produces RGB by default, or, to put it differently, there is no obvious reason that Alexa's ProRes 4444 files are YUV.

How is your methodology to determine between YUV and RGB?

Thanks,

Hans

[Oliver Peters]

can you double check the Alexa ProRes files regarding RGB/YUV? Alexa produces RGB by default

Hmm... You are probably right. I'll have to double-check when I get back in front of some 4444 files. Right now the only Alexa files I have in hand are HQ. I'll post back what I see.

In any case, workflow is either FCP or MC related, so there may be some conversion going on. The color levels appear to map to standard REC 709 levels though, from what I can tell. So the recorded profile I see is typically either REC 709 or Log-C intended for conversion to 709. I haven't worked with any of the ARRIRAW files, yet.

- Oliver

[Hans von Sonntag]

Probably the obvious: In AE right click the file in question, interpret footage/colour management.

When it says none, you are in RGB. When in YUV you will see Rec709 YCBCR.

Hans

[Oliver Peters]

Hans,

The Alexa clips do appear to match your suggestion. I stand corrected. I've pulled up camera clips, an exported sequence from FCP and a rendered graphic from AE. All in ProRes4444 and they all show up in AE color management with an embedded profile of "none". The ProResHQ clips show up with embedded "HDTV (Rec 709) YCbCr" profile. Thanks.

Cheers,
Oliver

[Hans von Sonntag]

Hans,

The Alexa clips do appear to match your suggestion. I stand corrected. I've pulled up camera clips, an exported sequence from FCP and a rendered graphic from AE. All in ProRes4444 and they all show up in AE color management with an embedded profile of "none". The ProResHQ clips show up with embedded "HDTV (Rec 709) YCbCr" profile. Thanks.

Cheers,
Oliver

Thanks Oliver,

don't have Alexa files available in the moment and your findings confirm my assumption.

Hans