Update! DaVinci Resolve ‘Levels’ Setting For Premiere Pro Renders

Great Insight Jason, thanks! Out of interest, did you test 444 source to 422 and bring that back into Resolve to compare with the 444 source? I assume that was virtually identical?

Thanks again

Really interesting Jason.
It seems that even after all your tests that some of the variables in the tests were not swapped out to find the problem.
It’s one thing to see a problem,( first ) and another to then determine the exact variable(s) causing the problem. In all test shown here – the two softwares involved were Resolve and Premiere.
I am guessing that since you acknowledged that an Adobe update changed your tests, that one could assume that Adobe’s handling of the codecs might be the problem.
To test that assumption, maybe a different software to ingest the different codecs could be tested as well, as a confirmation to the source of the problems.
Also the rendered clip.
Was that used to test against on all the different renders? If so, just to be sure that it wasn’t influencing the test, maybe a second rendered file could be exported in DnX or even 422 ProRes? Just to confirm or rule out the constant variable. Or maybe I missed something there.

Now if it is determined to be an Adobe problem and Resolve is correctly rendering all files, shouldn’t we just ignore it, and not make any changes in our workflow?
It seems to me that Adobe at some point could change this ( but not fix it correcty ) and an opposite swap where the 422 would look correct and the 444 could have the color shift.
So making all our renders 444 could then be the wrong approach.
Tough call. But determining the actual cause, might give us an indication as to what to do or what not to do.
Just some thoughts.

Yikes! This is alarming news… now we may have to re-assess our workflow for our Premiere clients.

Great Insight, Jason, and timely for me, as I am about to finish a film and render out clips to a Premiere client. I was planning on DNxHR HQX. Now, I will look at DNxHR444. I am becoming increasingly frustrated with Premiere as the years go by.

@jason-bowdach-1 is there a difference that you started the timeline with Rec709 Scene instead of 2.4? I never use Scene for any broadcast work. Also for PC users is DnX HR & HD the same?

Echoing @evan-anthony here, I believe Rec709 (scene) on Mac is gamma 1.8, while Rec709 in Premiere is 2.4 (Premiere is now color managed btw, didn’t used to be). A gamma shift could explain color differences in the vector scope that look different than your classic levels mismatch.

The fact that Resolve defaults to Rec709 (scene) these days is a known headache.

Would also suggest for testing, that rather than (or in addition to toggling) before/after, which relies a bit on visual memory, you do a side-by-side by cropping the upper track 50% and/or doing a difference blend mode. Both of those can reveal more subtle changes and detailed comparison than a memory based toggle.

I also have been dealing with this shift. Premiere seems to be the culprit. But it’s hard to blame others… that being said, clients are noticing and I am being not blamed, but questioned…

So is what does the 422 media do when imported into Resolve? When I re-Import to Resolve, it’s correct, are you finding this?

Is there anything we should be telling editors to set color mgmt to in Premiere, I don’t subscribe to Adobe so don’t know this.

Thanks for doing this Jason!

I haven’t revisited this testing in-depth with the latest version of Premiere but I would assume that the results Jason is getting mimic my previous testing but there is one big thing not shown or discussed here that’s not a levels or codec thing that I think is vital in these workflows – proper NLC tagging.

One of the things that Output Color Space in Projects Settings > Color Management governs is output file NLC tagging. In the video, Jason has his output color space set to Rec 709 Gamma 2.4 and on the deliver page has both output gamma and output gamut set to the same as the project (not overriding them) – which will use what the Output Color Space option is set to.

Because Output Color Space was set to Rec 709 Gamma 2.4 this creates an NLC tag of 1-2-1 (Color Primaries, Transfer Function, Conversion Matrix). This is problematic because a tag of 2 actually means (in NLC parlance) undefined. Although some pro applications do understand it to mean Gamma 2.4 that is the exception, not the rule.

Like many applications, Premiere Pro expects a 1-1-1 tagged file and will also output 1-1-1 tagged files (confirmed with Adobe Premiere Team). So when Premiere Pro (or insert player here i.e. frame.io etc) sees a 1-2-1 tagged file, potentially some sort of compensation will be applied to go from ‘undefined’ to ‘defined’. What that compensation is, depends on how the devs want to handle it for that app or player. While proper color management ‘should’ solve for this it can confuse things to where you get color shifts, gamma shifts etc – I mean just look at any user group for ‘why does this look different!’

Having your output color space in an SDR 709 workflow set to 709 scene (the new default since early 17) will when using Same As Project for gamma/gamut on the deliver page actually creates a properly tagged 1-1-1 file. Or you can override/enforce this (I usually do since I’m OCD and want to be sure) by setting each of these deliver page pulldowns to Rec709. Doing so forces a 1-1-1 tag regardless of what your Output Color Space setting is set to in Project Settings.

Just keep in mind If you’re using properly calibrated 709/2.4 external monitoring the output color space choice has no effect on the pixels you’re seeing there – it’s just metadata so it controls NLC tagging, iCMU Tone Mapping and the Resolve viewer on a Mac using ‘use mac display profiles’.

It’s easy to see this NLC metadata on the file itself in a tool like the free Media Info or my player of choice which is Screen from Video Village (Mac only sorry!).

@joey actually did a detailed, well-explained video on all this a while back – https://mixinglight.com/color-grading-tutorials/davinci-resolve-17_4_5-custom-yrgb-output-color-spaces/

It’s also worth noting, while you can encode/package data/full levels (or R’G’B’) in a ProRes or DNX container these formats are always under the hood – legal range Y’CbCr. Meaning internally all flavors convert to/from legal Y’CbCr.

Quick tangent: This was actually a big source of confusion in the early days of Dolby Vision mastering when ProRes was starting to be accepted as a mezzanine file. Because a DV workflow is largely full range (monitoring etc), people were making explicitly tagged full range ProRes mezzanines that once they hit the AWS encoders at Netflix, Hulu etc that are(correctly) expecting legal range ProRes – a shift happened. If you really want some light bedtime reading Dolby actually has a great article on this here – https://professionalsupport.dolby.com/s/article/Dolby-Vision-Legal-Range-workflows-for-home-distribution?language=en_US

It is true in the past that Premiere Pro had this levels stuff wrong and made all sorts of levels of ‘assumptions’ based on codec, chroma subsampling etc but as Jason shows Auto (which for these codecs makes the file legal) or forced to legal works as expected now. 98.9% of the time auto or legal is the right choice.

I’m not saying that Premiere Pro doesn’t do dumb stuff and their really confusing approach to color management is making it worse, but @jason I’d revisit this test using properly tagged 1-1-1 files and see if you get the same results.

Remember NLC tagging is not changing encoded pixel data – it’s a metadata instruction. You don’t have to regrade anything if you tagged it wrong – tools like CineXMeta can change this metadata on the file instantaneously.

Doing some quick tests tonight any differences in scopes or using a difference mode with the original source file in Premiere and a properly 1-1-1 tagged legal range ProRes (not graded) render from Resolve can be chalked up to encoding entropy – visually they are identical and I was getting the same results with 422 or a 444 render (from 422 footage).

We deliver dozens of national-level spots for a big agency every month that does final online (text audio etc) back in Premiere (and they’re more OCD than me!) and delivering 1-1-1 Legal ProRes 422 that pipeline is rock solid.

Curious to see if you’re able to retest Jason what you get with a 1-1-1 Auto/Legal ProRes 422 and what your results are.

-Robbie

P.S. I don’t seem to have permission to attach screenshots/images. I was going to attach screenshots from Screen showing different NLC tags and CineXMeta editing the tags themselves.

DaVinci Resolve 17.4.5 – Custom YRGB Output Color Spaces

Hi all! Thanks so much for your comments and suggestions!

I’ll be doing a few additional tests and I’ll follow up soon with the results.

EDIT: My initial testing with 1-1-1 tagged media into Premiere brought more questions than answers. I’ll be diving deeper with more testing and a follow-up insight as soon as I get back from NAB! 😃

From my extensive testing and discussions with devs, I’m comfortable saying that Robbie probably has a very crucial point. Premiere is now “sensitive” to NLC tags and that could easily account for the color shifts apparent in the scopes.

And Premiere needs 1-1-1 tags for reliable Rec.709 work. Which means that anyone working in Resolve needs to be aware of what Resolve is setting the tags to for any export.

Another thing Jarle Leirpoll tested out awhile back, is that having both the sequence preview settings set to Max Bit Depth and also any export set to go with Max Bit depth was crucial to getting proper bit depth for any Premiere export. Why the sequence preview setting affects an export is anyone’s guess, but … from checking his work, he was correct.

Premiere is, as Jason notes, a moving target. I’ve spent more time testing it and in contact with the devs than most, and they still release things that catch me totally by surprise. And the public beta has a new wrinkle … the “new” color management settings are moving from the Project panel context menu (right-click/Modify/Interpret Footage) … to a new “Settings” tab in the Lumetri panel.

There are several subtabs … Input, Working Space, Clip, and Display.

The Clip settings are only available if certain conditions are met. They’re grayed out otherwise. It’s … intriguing. I put in the main request for an overall color management panel, was notified some months back it had gone from a request to under consideration.

But this panel seems still a bit of a transitional thing. But something like this is coming to a release version near you … sometime … probably.

Good point about the output tagging – but but my understanding is that tagging it 1-1-1 (rather than the undefined 1-2-1, gamma 2.4) would make Apple assume it was gamma 1.96 and covert it from that to the Apple display. So I’ve always assumed that it’s a better idea to actually define it as gamma 2.2 (1-4-1) so at least it would be closer! Maybe my thinking is wrong? I don’t know what Adobe does as opposed to what Apple does – will Premiere Pro assume 1-1-1 would be 2.4!? Or does it actually understand that 1-2-1 as gamma 2.4 . Probably not.

Thanks again, Jason, for testing! Looks like you’ve got a lot to do for the next episode 😉

It would be ever so nice if the good people at Adobe’s DVA color section would actually tell us what goes on under the hood. But though I’ve got some contacts, and have asked a lot of questions, the replies (when I’ve gotten them) have all been simple use-case examples. “If you have X media and want Y display, use these settings.”

Not a single response as to what the processing pipeline looks like at this time. Not … one.

The “clearest” answer I’ve been able to get was when I told several managers at last year’s NAB that it seemed obvious that the old Premiere CM … covered thoroughly in my Insights here back in 2019 … had been completely gutted and replaced by a new operation. Which they hadn’t officially stated.

What was “clear”? They simply looked at me, and did not disagree. If I was wrong, they’d have told me. So woohoo, confimed they’d gutted & replaced all color management & processing. Almost by reading tea leaves … sigh.

But … they wouldn’t say what in particular was different other than it now can ‘natively’ handle HLG and PQ color spaces rather than treating them as “over-range Rec.709 values” as done up through the fall 2022 release.

So do they use a specific or general internal working space? Dunno. It looks like the three working space choices for sequences may set the actual mathematical working space basis, for that sequence only, to that color space. Which are Rec.709, HLG, and PQ.

And perhaps all the media is transformed to that color space prior to the changes made by Lumetri controls and the image is sent to the display.

Or … perhaps the original data is modified by the Lumetri control changes, then that result is converted/sent to the ‘display’ space controlled by the working space setting … as I’ve seen speculation about from a couple people who also geek on this stuff. In a couple tests, that to them seemed possible. I don’t think so, but … it’s possible. They’ve made a number of choices that have seemed highly illogical to me, why not this one?

So what order things occur in during the processing pipeline … I just dunno. And I’m hoping of course, to get some clarity at NAB next week, but I’m not holding my breath.

The clearest thing at this point, is that this is all constantly, slowly shifting. The movement of CM settings (in a just-released public beta) from the Project panel/Interpret Footage context menu, to the Lumetri panel “Setting” tab, is simply one more step in a continuing process. Where it will end up I’ve no idea.

This is one of several major working issues I’ll be talking with the folks in the Adobe booth about next week. Not sure I’ll get any real illumination, but I’ll certainly ask the questions.

Hi. The color shift you see was sadly related to a rather serious ProRes Hardware Accelerated Decoding bug from Adobe, specifically on Apple Silicon (M1/M2) computers, that I reported back in August 2022. The decoding bug caused 8-bit decoding of all ProRes files, which also affected encoding from ProRes source files due to the decoding bug. It was finally fixed in Premiere Pro 23.3, released on April 12th.

I posted a sample from my Fusion 3D cube analysis, of ProRes files exported from Premiere Pro, which was caused by the mentioned ProRes decoding bug. As you can see, it was pretty bad: https://twitter.com/thomasberglund/status/1584557970569895937

The workaround to fix the problem before Premiere Pro and Media Encoder 23.3, was to disable Hardware Acclerated ProRes Decoding in both Premiere Pro and Media Encoder.

Here is a detailed post from Adobe about the ProRes issues that were fixed in Premiere Pro 23.3.
https://community.adobe.com/t5/premiere-pro-beta-discussions/now-in-beta-improvements-to-prores-playback-quality/m-p/13546603

Some rather serious quality issues out of @AdobeVideo #PremierePro v22/v23 on Mac (Intel/M1). Seeing this with both ProRes 4444 and DNxHR 444 12-bit export (best bit-depth on). No issues like this on Windows PC. DaVinci Resolve on Mac and FCP are fine. #postproduction #postchat pic.twitter.com/tCuuWOGTJb

— Thomas Berglund (@thomasberglund) October 24, 2022