Add a decimal on GUI color grading units

Captura de pantalla 2025-06-12 a las 18.54.35.png (218.09 KiB) Viewed 230 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...