Conforming - Resolve back to FCP

[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