Add a decimal on GUI color grading units

Captura de pantalla 2025-06-12 a las 18.54.35.png (218.09 KiB) Viewed 285 times

Lift / Gamma / Gain units are currently shown with 2 decimals.

We are aware that a change from -0.01 to -0.02 is often a big leap on some color management setups
While DVR is managing the 3th dezimal on the background, i. e. when working with panel wheels, those extra decimals are not represented in the GUI.

My request is to get rid of the initial "0" when the value is between -1 to +1, and add a 3th decimal like "-.018" for higher control and precission.

Found a similar request here: viewtopic.php?f=33&t=206149

We are aware that a change from -0.01 to -0.02 is often a big leap on some color management setups. While DVR is managing the 3th decimal on the background, i. e. when working with panel wheels, those extra decimals are not represented in the GUI.

I ignore what the GUI numbers say and try to only regard the Waveform monitor, Vectorscope, and the calibrated color display. Those will tell you the truth. The GUI numbers are "fudged" a bit and not necessarily accurate.

It is possible with some scope systems (like Omniscope) to magnify the scope image and let you see a much closer look at what's being changed and why.

I also tell my students whenever possible to only use the Primary controls in "Bars" mode and to use a control surface like a Blackmagic Micro or Mini or perhaps a Tangent Ripple or Wave. Any control surface is far more precise and exacting than trying to change the controls by the numbers, using a mouse.

The Bars mode also gives you the ability to very quickly see what the relative balance of YRGB is in each mode (lift / gamma / gain), so you can understand color changes in context.

Yeah, I also use it in Bars, never in wheels.

However sometimes I need to see if there is any edit on colors on a given node. Sometimes there is even a slighty, bias on a node that should not have wheels, but have been touched by mistake.
and sometimes we read 0.00, but sometimes this is 0.005, whcih already means a noticeable change on color when set to an individual RGB channel.

I really agree your considerations above, and watching scopes is the way to go. However sometimes reading
0.00 0.00 0.00 0.00
in dezimals can. be

0.00 -0.005 0.00 +0.005 which is Noticeable in color biasing and not reflected in units

My request is to get rid of the initial "0" when the value is between -1 to +1, and add a 3th decimal like "-.018" for higher control and precission.

+1

Yep, I remember asking for this a loooooooo.0000.ooooooooong ago..

Also, for all the AI programmer saints, starting point is either 0 or 100, not 50…. (Saturation is an example…)

Yep, I remember asking for this a loooooooo.0000.ooooooooong ago..
Also, for all the AI programmer saints, starting point is either 0 or 100, not 50…. (Saturation is an example…)

That's all over the place: some modes have the starting point (or Unity gain) at 1, some at 50, some at 100, some at 0. Compare Sizing and Primaries as an example. I think the problem is that those UI numbers were created over a period of 20-25 years, so some represent old code and old decisions.

It'd be great to unify them and make them all the same -- for example, make 0 Unity Gain and then have the ability to go -100 or +100 on any knob.

I don't mind "zero lift" being 0, "nominal gain should be 1... black to white is [0-1].

Saturation at 50 is... bonkers. It comes from the old days where a side was in the neutral state in the middle (50%) and you can go to 0 or double out 100. And while we are at it, I want with the Saturation go to 5x, without Stack 5 nodes one after the other...

Simply adding an extra decimal place could also work. The only thing I did is expand the size of the text fields and the color bars underneath to keep them lined up. Everything else is in exactly the same position.

Color Wheel Precision.png (36.18 KiB) Viewed 43 times

Simply adding an extra decimal place could also work. The only thing I did is expand the size of the text fields and the color bars underneath to keep them lined up. Everything else is in exactly the same position.

I again say that the GUI numbers are arbitrary and don't really mean anything. Whether it's 3 digits or a hundred digits, it's all very specious and illusory. The only thing that will really tell you how the picture is being affected by a given adjustment is to look at the picture and scopes. The numbers are not reliable, and will depend on where that specific node is in the node tree.

I don't mind "zero lift" being 0, "nominal gain should be 1... black to white is [0-1].
Saturation at 50 is... bonkers. It comes from the old days where a side was in the neutral state in the middle (50%) and you can go to 0 or double out 100. And while we are at it, I want with the Saturation go to 5x, without Stack 5 nodes one after the other...

I agree about Sat. It's odd to me that they didn't start with 0. I think this is an oddity that goes back to daVinci 2K, and the GUI numbers were weird and unpredictable even then.

The problem with allowing Sat to go as high as 5X is it would have to be very, very sensitive, unless you didn';t mind turning the knob multiple-multiple times to get there. There are a few modes where you turn the knob and hit a limit, and go "WTF? I need more!" So that does happen.

I concede that there's a point where if you push the knobs too far, things can go horribly wrong. But that's true about a lot of things in the world. I'm seen some sample node trees from students where they just have everything upside down & backwards and stretched to infinity, all because the initial setup was wrong in the very beginning.

There were situations with daVinci 2K where you had to essentially stack a couple of layers to get more range out of the controls, but happily those days are gone.