darktable UI/UX - white balance module poll

Just use the RGB coeffs directly, forget about temperature, that’s all.

1 Like

Ok I’m still stuck with the ‘how’ but I’ll raise another thread

Here I am all alone with my gray sliders.

4 Likes

Not any more!.. some thoughts -

  1. Aesthetically I think the colours are a step backwards, they seem like clutter to me.
  2. Harder to maintain code in future with colours added.
  3. These controls are very basic, do they really need colour to explain them? (or even confuse people) If someone is not sure what they do, it’s pretty obvious when you move a slider!
  4. A nice tidy-up would be to remove the dots under the left side of each slider which “zero” the slider. This is not relevant to white balance. But ok, perhaps it’s part of a standard widget so not practical.
2 Likes

Vote on gray too, after reading AP’s reasoning (“there’s no color at this point”).
Besides, it kind of breaks the current aesthetic of almost no color present in the UI, although the added colors are subtle.

2 Likes

Theoretically WB adjustments from what little I gathered recently “makes sense” between ~1677K and 25000K. I don’t really know if current white balance code can handle values below 1901K though (those are hardcoded).

Maybe a bit. But I’d rather have option to turn it on/off since ever enabling it helps me visually and “feels” right. Regardless whether temperature slider is blackbody radiation or fake lightroom-like :wink: And whether R/G/B sliders actually represent what they do in extreme ranges (in small adjustments they actually work as “expected”, shenenigans happen with extreme differences between coefficients). TBH it’s also true for all other sliders, meaning extreme “blue” will turn image magenta, extreme “green” will turn image yellow, extreme “red” will turn image pink/violet…

The solution to that might be similar to what @guille2306 suggested, eg “what would happen with white if it were to pass though pipe with those coefficients” That could create a bit more meaningful visual indication.
Or go with “those are just coefficients, so numbers, not colors. as in ‘patch size’ not something you have color for!” :smiley:

To each his own regarding aesthetics, but seriously this is kind of visual guide that actually helps me. I do enable/disable it via option, so it isn’t as with lightroom options of “get f*** if you want to change something” :stuck_out_tongue: And honestly that adds very tiny amount of clearly separated code.

All sliders can be done that way though. But that isn’t good UX at all. Hell, I personally don’t want to move any slider that has no color/tooltip.

To quote some comedy scene (so nobody gets offended, it’s a quote): “You Bastard! You complete absolute bastard!”. Thanks. I hate it.

Now I see it EVERYWHERE and hardly anywhere is it “right”. In color balance it’s mostly right, in tone equalizer, simple tab it’s totally right, but masking tab has it (imho) a bit wrong, exposure has it wrong on cliupping threshold, highlight reconstruction has it wrong, white balance has it wrong everywhere, local contrast has it wrong everywhere, sharpen has it wrong everywhere, haze removal has it partially right… AAAaaarght!!! And I’m yet to check what it should do/show/indicate and your remark alone made me question it on every slier!

How about color for temperature of illuminant + tint? Those do have color at that point though!

Never even noticed those were there

1 Like

It’s fine to me, but I keep my vote to gray as default.

1 Like

I put them there during the UI revamp, one year ago. The reason is some sliders have zero on the right, some on the left, and some in the middle. So having a dot to show you the zero give you that info immediately (and also, for “balanced” sliders with zero in the middle, you can feel the balance).

3 Likes

THB those work for most part especially in balanced case, so thanks for them!

Can we set up that dot for sliders with no meaningful zero, or which can’t go to zero etc, to rather indicate “balance point”?

It’s zero if there is one, or minimum value in the range else. In this last case, it’s just to see which way decreases the parameter.

1 Like

Ah, but there’s the rub: a choice that looks and feels right to one group looks and feels wrong to another. I tend to look at this kind of thing pragmatically. In the end you’ll wind up with a never ending round of complaints and counter complaints.

Maybe there’s a grand comprise: have an option for all three! OTOH, that’ll probably just get everyone complaining… Life is just too short for that. :cowboy_hat_face:

1 Like

@johnny-bit -

I was just looking in Preferences but can’t see anything like this, could you expand pls?

Put on dark glasses, sit down, have a drink! :slightly_smiling_face:

1 Like

sure:

This obviously isn’t “final” of it :wink:

Yes indeedy!! Color temperature was a thing in the captured scene; once it’s recorded it’s all about the R, G, and B channel alignment, that’s why it’s called ‘white balance’. Temp/tint in post is just a software abstraction of the concept to allow one to continue thinking of it in terms of the scene lighting. Me, I’ve never been able to make it work, much prefer RGB multipliers, looking at the histogram…

1 Like

+1 for colored sliders (where it makes sense)

1 Like

Voted for gray sliders. Why would I be looking at pretty colors on the sliders instead of looking at the photo?

1 Like

BTW, as far as we touched this module. I find in quite inconvenient that the scales on tint and the temp sliders are quite different. I mean that the temp is changing very slow, so I’m pressing shift 99% of the time I adjust it. While the tint slider is much rougher. Thinking in LAB terms, the sensitivity on “a” and ‘b’ axis are quite different, that seems quite inconsistent to me.

1 Like

Oh man don’t get me started… I spend hours reading about that and that behaviour is in fact weirder.

Yeahhhh… the process is actually division by tint in different colorspace to calculate coefficients, which might not be greatest idea for “true” temp+tint adjustment… I’m digging deeper on it, but my plan for now is to “make a bit more accessible” the gui part and then deal with weirdness regarding tint later (tbh tint shouldn’t be [0.135…2.326] bacause that doesn’t realy describe disance from planckian locus over normal for given temperature. the “correct” one (or the one I could find in my sleep-deprived state) is Duv (but those are expressed in values like [-0.01…0.01] so would have to be scalled to something more manageable (like [-10.0…10.0])

1 Like

Here’s a general thing to consider:

For a slider or other such arbitrary adjusters, the range within which most will work should be “one-handed”, that is, easily modifiable within that range. Then, involvement of the second hand should be left to ‘extraordinary’, or ‘extreme’ modifications. This behavior should be consistent across the tools: normal work with one hand; if more is needed, bring in the other hand to switch to ‘more’ or ‘extreme’ or ‘ludicrous’…

I’m gradually replacing sliders in my software with integer and float spin controls of my own design. One thing they do is increment/decrement by the lowest precision by default, but allow one to go to x10 or x100 by holding down the Shift or Alt key, respectively (can’t really do that with a slider…). Then, when I incorporate one of these for a parameter, I try to make the default range fall within the normal operating regime for that parameter. I’m not all there yet; my filmic tool requires separate thinking behind each coefficient, not the most intuitive situation , but I’ve trained myself in the vagaries…