Data Levels or Video Levels — How To Choose Wisely

Have you experimenting with Cineform exports and datavideo settings? For some reason, Ive noticed the cineform is quirky in this area. Every other codec works great w auto, but have you had any quirks w cineform and datavideo? You mentioned it was very codec specific AND variant based (RGB vs ycrcb).

This question is specifically for creating a HQ master file, which I can create other deliverable assets off of, such as H264 for web, Bluray, etc. Usually includes a conversion from an RGB to YCrCb. Is a solution to always provide YCrCB based masters (ex ProRes422HQ or CineformYUV) to avoid potential issues? Many thanks!

EDIT: Clarified and simplified

I’d love your insight on Jason’s question also. I never used to transcode, relying on the ability of PrPro to handle any codec, but I’m finding Cineform simply works slicker through the machine during editing. Ok, quick fix … Prelude to batch rename/transcode on upload … but I’m not sure PrPro and Resolve are seeing the same thing. I don’t know if that’s because I’m a noob in Resolve and don’t have the settings right or … just half blind.

Thanks Patrick, I didn’t realize codec came into play with this.
So I have an original dream color monitor that expects 444 RGB so I found I have to monitor with data levels.
It gets tricky with color space emulation like if I emulate rec709 I didn’t know if the dream color was mapping the black to data levels.
I don’t think it is.

There is also gamma that comes into play for levels. What is the difference in RCM between rec709 and rec709 2.4 and 2.2. My dream color emulates rec709 2.4 gamma so I set my default RCM output to that. I also calibrated all my monitors to 2.4 gamma. It just appears so much brighter then the original req709 color space. I’m just confused on why there are 3 separate req709 color space options.

Thanks
Greg

Also what if I’m working for cinema (DCP) and we decided to do it by ourselves? Or even if someone else will do it (the DCP), shouldn’t we keep the project @Data and grade then export it @Data into 444 (or equivalent) format for DCP?

OK! I follow Patrick’s “orders”; I touch nothing. I acknowledge everything that he says and I go away happy. BUT! Then I look at my scopes and they range from 1-1023.
And I have a neat setting that allows me to “Show Reference Levels”. So I set that to [64] and [940] and neat lines are added to whatever scope I set that display on in.
So do I grade my blacks to sit at [0] or do I grade them to sit at [64]? And if I grade them to sit at [0], I assume Resolve will do all the necessary range adjustments as required.
And then, of what value is being able to see lines on a scope at [64] and at [940]?

Jason – RGB doesn’t necessarily mean it’s always expecting Full Range data. I probably used the term ‘RGB’ too often to describe codecs that expect Full Range.

I haven’t worked much with Cineform. I’ve done research and can’t find the specific answer to what their RGB codec expects. We’ll reach out and try to get a definitive answer from them. The quirks will be if one of those codecs can accept both Full Range and Legal Range, then apps will differ as to which they expect to be the default interpretation. I don’t know if this is true for Cineform.

Yeah – I’m now trying to get in touch with the Cineform people. We’ll get an answer on this.

RE: Dreamcolor – Right, that display works full time RGB. Traditionally you’d place some sort of device before the Dreamcolor that would take whatever your input is and deliver full-time RGB. It doesn’t change how you grade, you just need to deliver the display what it expects at the Data or Legal range that it expects. There’s no emulation going on here, just a distinction about how the bit codes should be delivered to the display (although there’s always a chance for a problem with the equipment used to convert the input range into the range that the Dreamcolor wants).

RE: Rec 709 gamma – Rec.709 does NOT explicitly set Gamma levels. For web deliverables, you’d monitor at 2.2 since that’s what computer displays assume. For broadcast you’d set either 2.4 or just plain Rec709. Again, there is no standard, so it tends to be a regional thing. Some cities tend to work at 2.4, others at 2.35. But if you want my suggestion, set it for 2.4 for broadcast work. And if you’re delivering to both broadcast and web, set it for 2.4 – making broadcast the main deliverable.

Did this help?

Assuming out-of-house DCP creation: You should set Data or Legal depending on the codec you’re exporting to. Some codecs will require Legal and if you set to Data the codec will ignore those ‘out of range’ code values and you’ll literally clip highlight and shadow detail.

If you want to deliver Full Range for DCP then pick a codec you *know* can handle full range data. ProRes444, DPX, etc. And whatever you do, make sure you tell them you’re delivering full range. If they don’t know what you’re saying, you’ll want to find a different vendor.

Make sense?

Now: monitoring depends on your grading setup because if you’re monitoring on a display that can handle full range, feel free to set it up that way. Otherwise, don’t. But again, how you set this when rendering (and the choice you have) is always dictated by the codec you choose.

Remember: Choosing Legal doesn’t mean you’re not looking at the full contrast range of your display! It merely tells your display where to find zero black and 100% white, which it’ll then remap to its full contrast range.

“And I have a neat setting that allows me to “Show Reference Levels”. So I set that to [64] and [940] and neat lines are added to whatever scope I set that display on in.”

No!

Don’t do that!

I think you missed the end of the video where I say specifically, Resolve always works at 0-1023. That’s why the scopes are set that way. Do NOT set those reference markers and use them as your new black and white reference levels.

0 on Resolve scopes is where you set your black. 1023 is pure white. Always. ALWAYS. 🙂

Resolve will then remap those to the proper code values depending on the codec your choose.

Is this clearer?

I actually ran into an issue where i had to change clip attributes to Data levels. Creating LUTS for Premiere Pro Cc 2015. Producers are asking me to create primary look luts so that before a show goes to finish the client can look at decent color shots as the approval process gets underway. They are shooting with the XAVC – MPEG 4 codec which is a log format. when exporting a LUT for on screen interviews, then bringing those LUTS in to premiere using the Lumetri color panel that codec was reading the video levels improperly. Once I set those clips to data levels then exported the LUT everything matched in Premiere. Of course prores was still set to video levels and looked fine.

Many thanks, Pat! helpful to know as I provide clients with a master knowing they may transcoding it to other codecs/formats for different deliveries platforms. If I can avoid potential misinterpretation issues by providing a ‘video level’ only codec like PR422 , I’d certainly be interested in doing so

Very clear direction, Pat. Thanks!

I have a decklink 4k pro that can upscale to 444 also I run it though a hdlink as well. I’ve confirmed via a gradient that it wants full levels.

Why in RCM is there such a huge difference between plain old rec709 and 2.4? I recently did a little project with RCM rec.709 2.4 exported it as pro res 422 and h.264 at video levels and the gammas where really different on vimeo after their mandatory 2nd compression. My computer and dream color are calibrated with disccalgui to req 709 2.4 4K+ patterns. After seeing how contrasty vimeo was I started to second guess using RCM rec.709 2.4 since it does appear so much more lifted then plain old req.709. Whats you take on this?

Honestly, I’ve not started using RCM. It’s v001 of that workflow and I’m not willing to trust it yet. Maybe someone else who has tested and is using this workflow can chime in on it.

RE: 2.4 exported at Video Levels on PR422HQ and h.264 – Well, I’m curious if you’d find the same problems if you exported at Auto, allowing Resolve to make the decision which bit codes to place black and white?

Technically, gamma shouldn’t re-adjust the black and white levels, just how the image slopes into black and white… which is why I suggest you re-test using the ‘auto’ setting in the Deliver Page. It may be this is a bug you need to report.