Manipulating saturation of colors (e.g via HSV or RGB curves, but also within color picker) shifts HUE #69562

New Issue

Yegor · 2019-09-05T22:41:31+02:00

Yegor commented

2019-09-05 22:41:31 +02:00

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: b6e7e173ec

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

color_hue_shift_bug.blend

**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: `b6e7e173ec` **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 ![image.png](https://archive.blender.org/developer/F7718787/image.png) [color_hue_shift_bug.blend](https://archive.blender.org/developer/F7718796/color_hue_shift_bug.blend)

Yegor commented

2019-09-05 22:41:31 +02:00

Added subscriber: @YegorSmirnov

blender-admin commented

2019-09-05 22:41:31 +02:00

#82631 was marked as duplicate of this issue

blender-admin commented

2019-09-05 22:41:31 +02:00

#75876 was marked as duplicate of this issue

blender-admin commented

2019-09-05 22:41:31 +02:00

#79212 was marked as duplicate of this issue

blender-admin commented

2019-09-05 22:41:31 +02:00

#79220 was marked as duplicate of this issue

blender-admin commented

2019-09-05 22:41:31 +02:00

#70352 was marked as duplicate of this issue

Philipp Oeser commented

2019-09-25 13:40:53 +02:00

Added subscriber: @lichtwerk

Philipp Oeser commented

2019-09-25 13:40:53 +02:00

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

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

Philipp Oeser commented

2019-09-25 15:21:58 +02:00

Added subscribers: @troy_s, @brecht

Philipp Oeser commented

2019-09-25 15:21:58 +02:00

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
CC @troy_s

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 CC @troy_s

Viktor Mukayev commented

2019-09-25 15:56:30 +02:00

Added subscriber: @VictorMukayev

Brecht Van Lommel commented

2019-09-25 18:58:03 +02:00

I think this is the same issue as the original report in #41287 (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.

I think this is the same issue as the original report in #41287 (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.

Troy Sobotka commented

2019-09-26 00:30:46 +02:00

Agree with @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:

Have a buffer for the UI kept around, that holds the RGB values in a linear state.
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.
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.

Agree with @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.

Sam Van Hulle commented

2019-09-27 23:47:04 +02:00

Added subscriber: @frameshift

Sam Van Hulle commented

2019-09-27 23:47:04 +02:00

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?

> 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?

Troy Sobotka commented

2019-09-28 01:05:04 +02:00

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:

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.
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.

> 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.

Brecht Van Lommel commented

2019-09-29 12:36:07 +02:00

Added subscriber: @MrBeep

Jeroen Bakker commented

2020-02-04 11:13:32 +01:00

Added subscriber: @Jeroen-Bakker

Jeroen Bakker commented

2020-02-04 11:13:32 +01:00

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.

[D6653: ColorManagement: PoC Windowmanager Areas](https://archive.blender.org/developer/D6653) 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.

Philipp Oeser commented

2020-07-30 14:13:42 +02:00

Added subscribers: @Leroy-Xie, @JacquesLucke, @iss

Philipp Oeser changed title from ~~Manipulating saturation of colors via HSV or RGB curves shifts HUE~~ to Manipulating saturation of colors (e.g via HSV or RGB curves, but also within color picker) shifts HUE

2020-07-31 12:08:20 +02:00

Philipp Oeser commented

2020-07-31 12:09:48 +02:00

Added subscribers: @cheteron, @Garek, @mano-wii