DaVinci color management issue

I recently decided to try out the DaVinci color managed workflow, and it pretty much broke the color tools altogether. I thought I had all the settings correct, and I do feel like I sufficiently understand the concept o color management, but I ended up with the classic nightmare of my renders having vastly different colors from what I saw in the viewer. However, when I previously graded test footage from the same camera, I did not have this issue, presumably since I was using color space transforms instead of color management.

That said, at least this isn't keeping me from being able to continue working, since I could just use color space transforms, but I would really like to keep my projects future proof in terms of being able to remaster them once I get an HDR monitor.

There is one thing about this that is still concerning to me though: I set up color management using the same settings that I used to set up my color space transforms, which makes me worry that the CST method might be incorrect as well. I can easily tell that they are different, but at this point I have no reason to assume that the first is actually correct - it could easily be the case that my results from my first tests were simply less wrong, but still inaccurate.

Since I have a naively enthusiastic drive for certainty, I want to do some null tests to make sure that the CST is definitely working correctly. Does anyone have any tips about what specifically to test, or how to avoid mistakes in setting up the test properly?

Thanks.

...but I ended up with the classic nightmare of my renders having vastly different colors from what I saw in the viewer.
Thanks.

Unfortunately Resolve's viewer is not meant to use as an accurate preview (I hope BMD will do something here as even laptop screens only get better in the future and not everyone needs perfect accuracy all the time).
You need an external, calibrated monitor, then something like the UltraStudio Monitor to send a clean, standardized signal into it without any OS or software interfering, and a viewing environment that has consistent (low) light, with the screen's brightness fitting that.

If you have absolutely nothing else, generate a SMPTE chart inside Resolve and see how the PLUGE bars behave with different settings of timeline and output color space.
https://www.asc.ohio-state.edu/price.566/courses/752/blacklevel.html
Many variables here though and even if set up the best as possible you won't get a truly trustworthy base from Resolve's viewer afaik.

If there's a way I'd like to know too though.

Hi, it's kinda hard to tell what the problem is here. For that you have to provide a bit more information.

Where are you seeing color differences? Are you watching your renders with Quicktime Player, VLC, etc. or do you load them into Resolve?

The best way to check the render is to browse the file in Resolve's Media Page. Don't import it into the project, because then color management will (have to) be applied. But browsing in the media storage shows you the exact render as it is.

If it looks different from what you are seeing in VLC etc, but the same as your timeline, then there is only a tagging problem.

If it looks different from the timeline, then there are several problems possible.

How are your render settings? Do you use Flat Pass? Turn it off.
Do you use gamma and color space tags? Set them to Rec.709 / Gamma 2.4 (for sdr renders, hdr will eventually be different)


Please also provide a screenshot of your color management settings.

Also what do you mean "it broke all the color tools"? Probably only a way of saying the tools behave differently than expected, right?

You may want to look at this from Daria.

Thank you so much! This is exactly the kind of information I'm looking for.

You may want to look at this from Daria.

Yeah, I've watched that video a few times and feel like I have a good understanding of it. That was why I even knew what the problem was in the first place. I'll get back to this in my point number 3 below.

A few of you were quick to point out that I am working with less than professional hardware, which is indeed the case. That said, if you know your monitoring environment is less than perfect, the only reasonable response in my mind is to do some tests so you can get a better understanding of how your monitoring is compromised, and hopefully develop a little bit of a sense for when you can reasonably assume that the viewer is giving you information that should not be used to inform whatever decision you're currently trying to make.

I know there are a few very non-trivial variables working against me here, but please bear with me, because I do have a plan, and in theory/my brain, it should work pretty well.

To the best of my current understanding, I see three possible places in my signal chain where the color data could be incorrectly interpreted:

First and foremost, what Michel said:

Unfortunately Resolve's viewer is not meant to use as an accurate preview

This is 100% the biggest issue, but it's the last in the signal chain, so we can't really design any meaningful tests until we make sure the upstream processes are giving clean results.

So number 1 is the viewer/my display. And yes, I realize those are actually two different variables, but for now I'm grouping them as a "what I'm seeing" issue. I'll get back to that soon though.

Number 2 is exactly what Sven said:

Also what do you mean "it broke all the color tools"? Probably only a way of saying the tools behave differently than expected, right?

Yes, what I meant by "broke the color tools" is that they were making changes that slightly didn't match my inputs. For example, I noticed that sometimes when making blue-yellow temp adjustments for white balance, the green-magenta tint would be affected as well, but only once rendered out of Resolve.

Number 3 is that I could have set up color management wrong in some way that caused it to apply the wrong CST. I have graded log footage on this machine several times before, and never seen a color shift anywhere near this egregious, which leads me to believe it is not just the inaccuracies of the viewer that are giving me these results.

Originally, my goal was to set up a null test within the color page, and check the results of a render rather than the viewer display. If it passes the null test with no color processing, I feel like I can conclude that the CSTs are working properly. Then if it passes the null test with color effects applied, it means that the only inaccuracies are coming from the viewer display. Then I can do some null tests between my renders and the viewer display to get an idea of when the viewer is least reliable.

However, Sven brought up another great point I hadn't thought of:

Where are you seeing color differences? Are you watching your renders with Quicktime Player, VLC, etc. or do you load them into Resolve?

The best way to check the render is to browse the file in Resolve's Media Page. Don't import it into the project, because then color management will (have to) be applied. But browsing in the media storage shows you the exact render as it is.

If it looks different from what you are seeing in VLC etc, but the same as your timeline, then there is only a tagging problem.

If it looks different from the timeline, then there are several problems possible.

This is a great point that I wasn't aware of. So I guess then I would need to do the null test within Resolve rather than using a render. This would mean you couldn't use the viewer to interpret the results of the null test, but you still check the image data.

Although that brings up another important question: If the viewer is incorrect, hopefully that means that the analysis tools (histogram, picker RGB values, etc) are showing the data from the actual source rather than the viewer display, right?

Thank you all for all this great info. Does anyone have any idea how to set up a null test in the color page? Someone helped me figure it out in Fusion before, but apparently Fusion exists outside of the color management ecosystem, so the null test will need to be done on the color page.

Funny how everyone always screams that the viewer is incorrect or inaccurate by definition. It really depends on how your GUI monitor is set up, the OS and hardware/software calibration. The whole Rec.709 vs viewing video online is also an entire pandora box on it's own. I'm saying this because you can have a clean feed out of a Decklink to a broadcast reference Rec.709 monitor set up and your deliverable would still look different online.

Does anyone have any idea how to set up a null test in the color page? Someone helped me figure it out in Fusion before, but apparently Fusion exists outside of the color management ecosystem, so the null test will need to be done on the color page.

You'd import your render and tag it as your output colorspace so the management conversions null. Then place it on top of your timeline and set the blending mode of the rendered clip to 'Difference'. If the entire image is black it means they null. However you'll likely see differences due to compression on the rendered version unless it's a very high quality export in 10bit.

You'd import your render and tag it as your output colorspace so the management conversions null. Then place it on top of your timeline and set the blending mode of the rendered clip to 'Difference'. If the entire image is black it means they null.

I don't think this would be an accurate null test of the viewer. The whole problem is that the viewer is displaying the image data incorrectly, but the rendered file is correct. Setting up a null test like this means that I would be comparing the correct image data from the render to the correct image data in resolve, which would always result in a null even if the colors are completely different in VLC than they are in the viewer.

However, this is a great way to null test the color management system! I could grade a clip once using color management, then do the same grade again with the CST method, and diff the renders against each other. Thank you!

Funny how everyone always screams that the viewer is incorrect or inaccurate by definition. It really depends on how your GUI monitor is set up, the OS and hardware/software calibration. The whole Rec.709 vs viewing video online is also an entire pandora box on it's own. I'm saying this because you can have a clean feed out of a Decklink to a broadcast reference Rec.709 monitor set up and your deliverable would still look different online.

This is a really interesting point to me. I'm new to color grading, but I do audio work professionally and everyone says "you can't properly mix on consumer speakers in an untreated room" in the same way people I see people say "you can't properly color grade on an uncalibrated consumer monitor."

As far as most people's audiences are concerned, most people are viewing media on a display that's cheap or small if not both, and nobody is watching on a calibrated color grading monitor.

So I don't have a monitor that shows me the exact correct information, and that's legitimately a bummer. But I can still render the project, upload it to YouTube, and watch it on a bunch of devices that are terrible in different ways. I feel like most of the time, that will give me enough of the information I need, even if it takes ten times as long.

https://youtu.be/NzhUzeNUBuM

This is EXCELLENT.

This is a really interesting point to me. I'm new to color grading, but I do audio work professionally and everyone says "you can't properly mix on consumer speakers in an untreated room" in the same way people I see people say "you can't properly color grade on an uncalibrated consumer monitor."

As far as most people's audiences are concerned, most people are viewing media on a display that's cheap or small if not both, and nobody is watching on a calibrated color grading monitor.

So I don't have a monitor that shows me the exact correct information, and that's legitimately a bummer. But I can still render the project, upload it to YouTube, and watch it on a bunch of devices that are terrible in different ways. I feel like most of the time, that will give me enough of the information I need, even if it takes ten times as long.

This is not what Shebbe’s comment is about though. The ”gui not work” is based on false assumptions that a) gpu output is unpredictable and changes randomly and b) you can’t calibrate display connected on digital interface that is not SDI based. Both of these assumptions are blatantly wrong. The problem lies between chair and display in most cases, not in ”gui bad, gpu no work” axioms.

Better analogy from audio world would be that if your cable is not colored red, it will not properly pass through digital signals because bits like red.

I noticed that sometimes when making blue-yellow temp adjustments for white balance, the green-magenta tint would be affected as well, b.

Hmmm isn't blue + yellow green? If so adding blue/yellow should effect green. Shouldn't it?

However, this is a great way to null test the color management system! I could grade a clip once using color management, then do the same grade again with the CST method, and diff the renders against each other. Thank you!

Yes that is what I meant to use it for. It's irrelevant if the viewer is inaccurate or not. If something with the export itself and file tagging etc happened. Then the resulting file should be different from the timeline. If not then at least that aspect can be ruled out.

Yes that is what I meant to use it for. It's irrelevant if the viewer is inaccurate or not. If something with the export itself and file tagging etc happened. Then the resulting file should be different from the timeline. If not then at least that aspect can be ruled out.

Sorry for misunderstanding, but thank you, it's very helpful.

Hmmm isn't blue + yellow green? If so adding blue/yellow should effect green. Shouldn't it?

Blue + yellow is only green when dealing with subtractive color (ie surface reflectance, like when printing or mixing paint). With additive color (light sources like monitors or light bulbs) blue + yellow = white. That's why the primary colors for monitors are red, green, and blue, but the primary colors for printers are yellow, cyan, and magenta.