Color management and tools issues

Bad LMS for Global wheel.

What is Global wheel?
It is gain (multiply) operation performed in a LMS color space. LMS color spaces are, in short, the best color spaces for adjusting white balance. And Global wheel is a white balance tool that should (and for gray scale does) work like white balance in RAW or color filters in front of light sources or a lens. Different LMS color spaces give different results. Some work better for some colors and others for other colors. You can find some of them in Chromatic Adaptation plugin for example. CAT02, Bradford… and so on. So, they are implemented to be a better alternative to performing white balancing in native source primaries.

What’s the problem. Well… LMS color space in HDR palette is just bad. It works worse than performing white balance correction in either native source primaries, or DaVinci Wide Gamut primaries, or AP1 primaries, or CAT02 primaries.

How I tested it.
Here is Alexa RAW image shot under tungsten lighting. In project settings I’ve set color science to Davinci Color Managed and chosen DaVinci Wide Gamut preset, but it’s for simplicity only. It has nothing to do with it and the problem is in HDR palette itself. I’ve set Output Color space to Rec709 (Scene). Also I’ve added just one timeline node and slightly increased contrast. Just to make the difference a bit more noticeable.

For a reference I used Camera RAW white balance settings to set neutral white balance for a 18% gray card. I set Exposure in RAW to the value that gave me the closest result to 0.18 value in scene linear.
For performing adjustments in different color spaces, I’ve set node’s Gamma to Linear and then was changing node’s Color space to the primaries I wanted to test. Then I’ve adjusted white balance (and exposure for compensation) with Gain trackball and Gain wheel of this node. So it was basically the equivalent of a Global wheel, but performed in different color spaces (primaries). For CAT02 LMS I used Chromatic Adaptation OFX and the next node’s gain in linear gamma for exposure compensation.

Here are the results:

No WB correction:



WB correction performed in Camera Raw:



WB correction performed using Global wheel:



WB correction performed using Alexa Wide Gamut primaries:



WB correction performed using DaVinci Wide Gamut primaries:



WB correction performed using CAT02 color space:



All the colors after Global wheel adjustment are not even close to the original colors! Especially the skin tones that become reddish!

So at this moment there is no mathematically correct tool for adjusting white balance in the most popular software for color correction. The only one is chromatic adaptation but it can’t be adjusted from trackball.

And if you could not just fix it, but add a list for selecting different LMS for HDR palette that would be awesome! Like CAT02, Bradford, CIE 2006 and so on.
And one more very important thing. HDR palette works differently for every color space. I mean, this is not because it should work in a different way because they are different. Let’s say you have some image. You transform it into AWG LogC and then set HDR palette to AWG LogC and adjust white balance with Global wheel. And you get some result. Then you take the same image and transform it into RWGRGB REDlog3G10 instead, and do the same with HDR palette, switch it to RWGRGB REDlog3G10 and make identical corrections with Global wheel. And then, if you compare results with the previous image - they are different. So this is definitely a bug.
And one more bug. When HDR palette set to Linear there is hidden OOTF is turned on without a reason. Global wheel set to linear should be identical to Gain wheel, but it isn’t.

I have a lot of other bugs with HDR palette, color management and Color Space Transform. But threads go down from the 1st page so fast, so I will post them into this thread one by one from time to time. So this thread could have a chance to be seen by someone from BM.

I understand that they all won’t be fixed until Resolve 18. So just let us know that you are aware of these issues. And if you need any help in replicating these issues I would be happy to help you with this.

From the first days I got used to using the HDR pallet, but alas, when "commercial"came to me, I realized that the skin was turning purple.
If the balance is made from the skin (which I do), then the rest of the product is not correct. Please, please. Look at the HDR rings. They are beautiful but not accurate.

There are so many different little bugs and issues with HDR wheels palette, that making it useless in real everyday work because it slowing down grading process dramatically!

It’s true. This is the Way too but it's one of the reasons why I am not using HDR Wheels yet.
Second, that it does not have a hotkey to switch between Primaries and HDR.
Third, that I am using Wave2 and it's not working well with HDR Wheels... Please reassign the keystrokes on it.

Anyway, I think Anton Meleshkevich is a great choice for a beta tester. He can find the bugs anywhere!
Thanks!

When HDR palette set to Linear there is hidden OOTF is turned on without a reason. Global wheel set to linear should be identical to Gain wheel, but it isn’t.

Here is the screenshot demonstrating this bug.

Screenshot 2021-11-04 034736.jpg (182.29 KiB) Viewed 4075 times

Timeline color space is set to linear. In the first node I lowered the exposure with Global wheel. In the second node I brought it back using simple gain wheel. It has to be a straight line on the waveform analyzer, because I've set Timeline color space to Linear. But the curve shows us that there is OOTF curve applied, that shouldn't be there.

One more bug.

ACES 1.3 Reference Gamut Compress clips negative values.
It shouldn't do that by its original design, but it does in its Resolve implementation.

gdfgdfgdg.jpg (220.96 KiB) Viewed 4071 times

Another very old bug I've tried to report multiple times with no luck.
Incorrect white point of Canon Cinema Gamut primaries.

Screenshot 2021-11-04 040321.jpg (96.54 KiB) Viewed 4065 times

I have a lot more color management and color tools bugs to demonstrate, but will do it a bit later to bump up the thread when it will go down far from the 1st page.
It's so sad that a lot of Edit, Cut or Fairlight pages bugs are fixed so fast but not the color bugs, that are here from one version to another. And fixing most of them is just a matter of a few lines of code.


UPDATE:
Incorrect Canon Cinema Gamut white point bug is fixed in v17.4. Thanks!

How much bugs in the color management. It explains why it is co difficult to make some projects works...

Sent from my LM-V600 using Tapatalk

Color Warper bugs.

Color Warper is a color space aware tool. This means that it converts the image from a color space that is set in the Timeline color space field, to its internal color space.

Color Warper have 2 bugs. The first one is it distorts saturated colors with any log encoded image. And the second one is it turns all pixels that have negative values into black pixels.



1. Distorted colors.


Here is the source image without any corrections applied



Timeline set to AP1 ACEScct. I barely moved red dot in Color Warper and immediately got killed reds and black negative values (below lens cap black level of the selected log)



Timeline set to AWG LogC



Timeline set to DWG Intermediate. Here we can't see the turning pixels with negative values into black, but this is because lens cap black of DaVinci Intermediate Log is placed at 0 value. So the bug is still there, but it just can't be seen with this example



Timeline set to Rec709 Linear. It works accurate with any primaries, the key setting here is Linear encoding curve. Seems like the only way to use Color Warper with wide gamut images. But this still isn't. Because values greater than 1 (above 100 nit) aren't affected by Color Warper at all. So using Linear encoding for Color Warper is also not an option



2. Negative values.


Timeline set to Linear, but this is only to avoid the artifacts mentioned above. Pixels that have negative values, that are introduced here by adjusting the image with offset wheel, become black pixels



it isn't just a simple clipping here. But even if it would a simple clipping (like with RGC) - this is still not acceptable. Negative values contain noise that is later used as a noise reduction sample as a minimum. But usually they also have useful information with underexposed images. This is how all cameras black level is set. It is set not to the lowest intensity signal that comes from sensor, but to the average noise level. And preserving negative values is even more important in actual color grading. The most popular color grading tool is still offset wheel. And this tool immediately produce negative values. So negative values should be preserved in any tool throughout the whole pipeline and they should only be clipped by a show LUT or a DRT.

I see you've fixed HDR contrast/pivot that was clipping negative values! Thanks!

But there are still a few things to improve in this tool.

1. Inaccuracy in the shadows.

I've set Timeline to DaVinci Intermediate log as it's for showing the issue. It has black level at 0, so any artifacts we see are in the actual working range of the image.



If I slightly adjust the contrast, it introduces artifacts into the shadows.


From what I was able to reverse engineer HDR palette, there are two reasons for that.
The first one is the way HDR contrast tool works with negative values. It works the opposite with the negative values and this is expected from the way this tool was coded.





For increasing contrast this can easily be fixed with something like this:

Code: Select all

if (input <= 0) output = input;

And for decreasing - probably something more complicated, as it doesn't have black point pinned to 0. And for me - it would better if it would be. So it would be basically a power function operator but with pivot point at 0.18 value.

The second reason is that this artifact that should normally be seen in the negative values range only, does actually appear with positive values. This is why I showed it with DaVinci Intermediate log.


2. If Timeline color space set to Linear, HDR contrast knob introduces this artifact even with this little adjustment.


3. Contrast knob has different sensitivity when it adds contrast compared to when it reduces it. This is very uncomfortable to work with.

I had same issues wit hglobaw wheel and color warper, and also, HDR palette kinda useless with Micro panel as there is no "natural" way to work with all of the wheels and other sliders, maybe new panel software with new buttons set might be an option for smaller panels?

One more bug.
ACES 1.3 Reference Gamut Compress clips negative values.

I know this will be addressed with the next update, but there is one more bug with RGC.
It doesn't do anything when custom DCTL IDT is selected, either at the project/clip level using ACEScc(t) Color Science or in ACES Transform OFX.


This post doesn't have images, so the signs are for attention here, because using custom IDTs is very important for me

Another old bug with ACEScc(t) OETFs and Color Space Transform gamut mapping.

It introduces very noticeable artifacts into the shadows.

Screenshot 2021-12-20 081858.jpg (98.82 KiB) Viewed 3607 times

Here is another OETF (and gamut but it doesn't matter, because OETF is what causes this) for comparison. It doesn't have this artifact in the shadows. Seems like the only two OETFs that have this are ACEScc and ACEScct.

Screenshot 2021-12-20 082232.jpg (100.14 KiB) Viewed 3607 times

And Resolve Gamut Mapping also clips negative values as you can see in this picture. And doesn't actually map the blue color, but distorts it. Not only with V-Gamut, it's a typical issue for Resolve Gamut Mapping.