Color Picker Hopes and Dreams

[jedypod]

Hello again! I was playing around with 6bd8b84, and am really liking the improvements. I will share a few thoughts if they are helpful:

• Dragging only works when the mouse pointer is inside the hue or value vs saturation field. When the mouse pointer moves outside of it, dragging stops. This makes it annoying when trying to adjust along the achromatic axis or when adjusting hue.
• Hue resets back to Red / 0 when saturation is 0. This is annoying when trying to tune in a saturation of a specific hue close to achromatic and it keeps resetting. And when it resets you can't drag the hue slider anymore, until you drag in the value vs saturation field.
• Currently it's not possible to specify values over 1, which may be desirable with scene-referred grading operators.
• HSV sliders might be more desirable than RGB sliders at the bottom for some tools. Maybe it could be possible to have an option in the widget to select which style is shown? (I'll paste some code I was testing to do HSV slider widgets instead of rgb here - for around like 246 in render_darkroom.h)

        // Testing HSV ColorPicker
        float hsva[3];
        nk_colorf_hsva_fv(hsva, *val);
        hsva[0] = nk_propertyf(ctx, "#H:", 0, hsva[0], 1.0f, 0.01f, 0.001f);
        hsva[1] = nk_propertyf(ctx, "#S:", 0, hsva[1], 1.0f, 0.01f, 0.001f);
        hsva[2] = nk_propertyf(ctx, "#V:", 0, hsva[2], 2.0f, 0.01f, 0.001f);
        *val = nk_hsva_colorfv(hsva);
        nk_combo_end(ctx);

Here's a screenrecording which explains everything in context if it's helpful:

2024-10-27_14-32-33_pt1.mp4

2024-10-27_14-32-33_pt2.mp4

[hanatos]

okay, you're right. let's give this some love.

great to see you found your way around the code!

i thought i had fixed the dragging outside of widget, but i didn't. this annoys me too.

the hue reset is likely because the data is internally represented as rgb. i was going to make this HSV internally now, because that seems to be the only way these values are ever edited in practice. this will be a breaking change though and render all current history stacks broken. we're <1.0.0 so i'm still ready to accept this.. sorry for destroying some old config files.

i just pushed hsv knobs to master now, where v < 2.0 (if that is enough range?).

do you ever want to dial in numbers? i can make these properties instead of knobs such as most other values. i kinda like how compact it is like this.

[hanatos]

okay this is way too much fun. now with big ui elements and HSV based on OKLab (because HSV is not a colour space or particularly useful)

[hanatos]

cough i think i might have changed my mind about the backend storage. maybe it is better the way it was, storing the coefficients in plain rec2020 rgb. this makes it easier to edit the values in the .cfg files from the outside if need be, or create presets to match external software, say.

also oklab is of course a different level of sophistication than plain hsv (which is useless: changing hue changes lightness so much), but it's still merely "ok". while gradients of colourfulness look great, there are some hues that change so much when changing lightness:

(okay this goes to 2.0, so 1.0 is at the top and there is some early clipping in some colour channels that makes results especially bad here)

but still it seems to be a good idea to keep the data backend independent of gui colour spaces that might perspectively be replaced by even better/more perceptually uniform controls in the future.

will probably polish the hsv knobs code a bit more and then revert the grade data backend to rgb (as it is in the released version 0.9.1 too) and then push.