Colorpicker: Hue is not saved if Saturation is on 0 #88261

New Issue

Julien Kaspar · 2021-05-13T18:53:06+02:00

Julien Kaspar commented

2021-05-13 18:53:06 +02:00

System Information
Operating system: Windows-10-10.0.19041-SP0 64 Bits
Graphics card: GeForce GTX 1060/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 445.87

Blender Version
Broken: version: 3.0.0 Alpha, branch: master, commit date: 2021-05-12 23:52, hash: 06e62adfb8

Short description of error
This is an interesting papercut I noticed a lot. When you start changing the hue of a color but the saturation is on 0, it won't remember that hue if you close and reopen the color picker.
This can be annoying at times, especially when using the Square (SV + H) color picker layout.
My guess is that this is because the values that are actually stored for the color are the RGB values and not the HSV values.
So if a color is (0.5, 0.5, 0.5) and you change the hue, it is meaningless.
But perhaps this can still be improved since other painting applications are actually saving the HSV values and artists would expect Blender to remember what Hue is chosen even if the color is essentially grey.

Exact steps for others to reproduce the error
This can be easily shown by changing the hue on a color with 0 saturation. The 2 hue sliders are of course not actually changing the color but they are also disconnected and not remembered.
But once there is a bit of saturation this is fixed.

2021-05-13 18-50-05.mp4

**System Information** Operating system: Windows-10-10.0.19041-SP0 64 Bits Graphics card: GeForce GTX 1060/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 445.87 **Blender Version** Broken: version: 3.0.0 Alpha, branch: master, commit date: 2021-05-12 23:52, hash: `06e62adfb8` **Short description of error** This is an interesting papercut I noticed a lot. When you start changing the hue of a color but the saturation is on 0, it won't remember that hue if you close and reopen the color picker. This can be annoying at times, especially when using the Square (SV + H) color picker layout. My guess is that this is because the values that are actually stored for the color are the RGB values and not the HSV values. So if a color is (0.5, 0.5, 0.5) and you change the hue, it is meaningless. But perhaps this can still be improved since other painting applications are actually saving the HSV values and artists would expect Blender to remember what Hue is chosen even if the color is essentially grey. <video src="https://archive.blender.org/developer/F10095109/2021-05-13_18-50-05.mp4" title="2021-05-13 18-50-05.mp4" controls></video> **Exact steps for others to reproduce the error** This can be easily shown by changing the hue on a color with 0 saturation. The 2 hue sliders are of course not actually changing the color but they are also disconnected and not remembered. But once there is a bit of saturation this is fixed. [2021-05-13 18-50-05.mp4](https://archive.blender.org/developer/F10095109/2021-05-13_18-50-05.mp4)

Julien Kaspar commented

2021-05-13 18:53:06 +02:00

Added subscriber: @JulienKaspar

Richard Antalik commented

2021-05-13 20:48:32 +02:00

Added subscribers: @ideasman42, @iss

Richard Antalik commented

2021-05-13 20:48:32 +02:00

I guess this is papercut, but not sure how complicated to resolve. @ideasman42 do you think this would be possible to implement so we can make this task TODO?

Evan Wilson commented

2021-05-14 01:38:27 +02:00

Added subscriber: @EAW

Evan Wilson commented

2021-05-14 01:38:27 +02:00

I recall seeing that there is a piece of code that assigns epsilon instead of 0 to saturation to prevent this from occurring. I’ll see if I can track it down.

Campbell Barton commented

2021-05-17 10:42:55 +02:00

Fairly sure this was reported before, this was an attempt to resolve this issue although it didn't really work out D9370.

Ensuring some small level of saturation isn't great as it means users can't set the grey colors.

We could handle this as a kind of run-time storage, similar to menu-memory, where a block's unique name + button-identifier is used to store the hue for re-use when the color popup is activated again.

Fairly sure this was reported before, this was an attempt to resolve this issue although it didn't really work out [D9370](https://archive.blender.org/developer/D9370). Ensuring some small level of saturation isn't great as it means users can't set the grey colors. We could handle this as a kind of run-time storage, similar to menu-memory, where a block's unique name + button-identifier is used to store the hue for re-use when the color popup is activated again.

Richard Antalik commented

2021-05-17 16:17:30 +02:00

@ideasman42 Thanks for info. Since code is working as intended, do you think we should confirm this task as TODO? Otherwise I will have to close this as feature request.

Julian Eisel commented

2021-05-17 16:22:30 +02:00

Added subscriber: @JulianEisel

Julian Eisel commented

2021-05-17 16:22:30 +02:00

This is a papercut & known issue in my opinion. We generally try to keep such things open in the UI module to not sweep issues under the rug.

Philipp Oeser commented

2021-07-13 16:35:59 +02:00

Changed status from 'Needs Triage' to: 'Confirmed'

Philipp Oeser removed the

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Colorpicker: Hue is not saved if Saturation is on 0 #88261