Page MenuHome

Manipulating saturation of colors via HSV or RGB curves shifts HUE
Confirmed, NormalPublicTO DO

Description

System Information
Operating system: Linux-4.15.0-58-generic-x86_64-with-debian-buster-sid 64 Bits
Graphics card: GeForce GTX 1080 Ti/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 430.40

Blender Version
Broken: version: 2.81 (sub 8), branch: master, commit date: 2019-09-05 10:52, hash: rBb6e7e173ecd9

Short description of error
To desaturate a color you plug a HSV or RGB curves node. But the more you light up the color the more hue shifts. I've tested it with eyedropper in blender and gimp. Dragging the right side control of the RGB curves node (making darker) doesn't shift hue.
If i'm doing something wrong, then what's a correct way to desaturate a color without hue shifting?

Exact steps for others to reproduce the error
Open up the attached file
Fire the render
From the Picker node pick the color from the render view
Compare the hues on both nodes


Event Timeline

Philipp Oeser (lichtwerk) lowered the priority of this task from 90 to 50.Sep 25 2019, 1:40 PM

Tempted to confirm this, not 100% sure though, checking...
Same is true for compositing...

Actually not sure about this...

  • rgb <> hsv conversion seems to go right during rendering [checked values there and hue doesnt shift even after desaturation]
  • If I leave out ui_scene_linear_to_color_picker_space in color picker code I also get the same values for hue there [even after desaturation].
  • that would mean that the values in the button are actually right, but we are presenting them to the user differently [might be better even to not show the raw values but something "perceptual" instead -- with the consequence though that this shifts e.g. hue...]
  • what confuses me is that when I save both versions [having "Save as Render" unchecked], then the hue shift is in those (but this might as well be another issue...)

Without diving deeper [which I really want to do sooner than later], I'll have to pass this on to someone else I guess...
CC @Brecht Van Lommel (brecht)
CC @Troy Sobotka (sobotka)

I think this is the same issue as the original report in T41287: Color Picker applies color management incorrectly in 2.71.

I don't really understand the context of that entire discussion, but I think what we should do is:

  • Make the HSV values that are displayed and edited in the number buttons scene linear, to match the RGB values.
  • Leave all the other widgets unchanged.

In implementation this is not entirely simple because all those widgets point to the same HSV value in memory, so we have to be careful to convert everything as appropriate.

Agree with @Brecht Van Lommel (brecht).

The issue here is the tip of a larger iceberg, and perhaps it can be resolved in the right direction. The core issue is that the HSV code is legacy, and was based on the nonlinear assumptions behind sRGB. Rightfully so, given how old it is. Although the discussion of hue linearity is complex, at the simplest level, as long as the RGB light ratios hold, the chromaticity angle will hold.

A potential path to solution:

  1. Have a buffer for the UI kept around, that holds the RGB values in a linear state.
  2. Roll the buffer through a chosen transform, on the UI. This permits the UI to function in the particular context the audience needs. Given the context varies, it needs to be selectable.
  3. When choosing, use the buffer to index the value, not the post-transformed version via an invert. The latter will not work, hence the buffer must be held.

The core issue is that the HSV code is legacy, and was based on the nonlinear assumptions behind sRGB.

Would this be the cause of the HSV colour picker returning crazy RGB ratios when using an alternative OCIO config?

Would this be the cause of the HSV colour picker returning crazy RGB ratios when using an alternative OCIO config?

I believe the “crazy” ratios are a byproduct of a number of anachronistic / legacy issues:

  1. The actual HSV code assumes nonlinear, and display referred. We can all agree this is a huge mess. Solution: Provide transform selection on the UI to accommodate the contextual need such as scene emissions, display linear selection ala albedo, normals and other data, or any of the other plethora of contexts. Extending the UI to support scene ratios is a part of this, as the results currently go sideways due to display referred nature of the UI code.
  2. Leaning on a poor assumption that the post-transformed data is always invertible. Buffers aren’t always invertible when dealing with colour information, and relying on invertibility is a core problem. The most simple example to understand would be a greyscale conversion, where we will have lost the reference light ratio information. Complex camera rendering transforms also share this facet. Solution: keep the reference state buffer around, drawn using the chosen transfer function / transform, and select from the internal non-transformed data values.
Jeroen Bakker (jbakker) changed the subtype of this task from "Report" to "To Do".Tue, Feb 4, 11:13 AM

D6653: ColorManagement: PoC Windowmanager Areas addresses a step into the direction of solving this issue. I set this to TODO as it needs a design how to fix the color picker related issues.