darktable UI/UX - white balance module poll

Hi!

In PR #4360 I brought back colored sliders for white balance module + added tooltips and options to configure colored sliders colors (or lack of thereof).

Since I don’t have many UI/UX testers I’m asking for your input, especially regarding default options.

Here’s how white balance looks now:
white balance now

Here’s how it looks with colored sliders being enabled:
colored sliders

And here’s how it looks like when enabling “Lightroom emulation” for temperature slider (so instead of blackbody radiation, we show effect on the scene):
lightroom emulation

Both my wife and I agree that colored sliders are way better UI/UX than standard ones (and tooltips help tremendously). My wife however says (and it is confirmed by some opinions I found regarding old behaviour) that having temperature slider showing blackbody radiation instead of scene effect is “a bit confusing and needs at least explaination in tooltip”. One can however get used to it and it makes sense in a way, eg “this is the color of light source that was iluminating the scene”.

My question now is: what should be the default option set for this:

  • Gray sliders
  • Colored sliders, blackbody radiation for temp slider (with tooltip explaining it)
  • Colored sliders, lightroom emulation for temp slider

0 voters

I would love to know your opinion overall!

3 Likes

When looked at in isolation, the blackbody color makes more sense to me. However, it wouldn’t be consistent with all the other sliders that show which will be the effect on the image. So, for consistency, I would go with the third option.

One side point: I don’t know if its my camera’s color response, but in the few images I tested moving the blue slider to the right adds a purple cast to it, not a blue cast. Then, for consistency again, the “blue” slider should really have a purple background…

1 Like

Thank you!

let’s see how vote goes :pray: either way I do want to keep the option for changing it visible.

It’s a bit of old code re-enabled + tweaked a bit by me. Now that you’ve mentioned it, for some cameras the filter colors are not only red/green/blue but red/green/blue/emerald. Or even such weirdness as green/magenta/cyan/yellow so I’d probably need to update slider’s colors based off on that too…
As for blue bg - it’s also not actually making picture more blue by sliding blue slider alone, it’s white balance blue coefficient so… IMO it’s ok-ish interpretation :wink:

Option number 2 for me; It is the only correct one.

Although the third one might be more intuitive for some it confuses the bleep out of me when I come across it. I think that one needs the tooltip to be honest!

2 Likes

I vastly prefer colored sliders! I keep forgetting the direction of the tint slider, so coloring it would be teriffic!

As a minor point, I would advocate displaying the same logic in the tint and temperature and RGB sliders: moving towards green or blue or red should make the image greener or bluer or redder. I find it counter-intuitive that tint and RGB work one way, and temperature the other.

3 Likes

However, both green and red give the picture a green and red color cast, respectively, so naively a new user would expect the blue slider to do the same. I agree it’s more a problem of the definition of the sliders names that probably goes beyond the scope of this change, but still looks weird (although I don’t know if it would be weirder to have a slider named ‘blue’ with a purple background…)

1 Like

Heh, it’s even more complex. Say - if you maxout or minout one or two of them the effects are completely different. So maybe that’s why people got additionally confused by them? For example - max out any 2 of those and then go with 3rd to maxing it out too - your effect won’t be making whole image “greener” or “bluer” but it will actually go white (overexpose) :stuck_out_tongue:
For that a slider gradient would probably have to constanly update based on others… Hmmmm… I did something like that in my other software I did ages ago… I wonder if I could replicate the effect in dt sliders…

Maybe define the current configuration as ‘white’ and show each side of the slider position how white would look like if you move that slider? But then it would be more important to keep the consistency and show the same on the temperature slider (by default).

Ugh… That’s a bit of stretch but possible. Say if you set all RGB sliders to “1” you get “white”. if you set all of them to “2” you still get “white”, but the effect will be as if you raised the exposure by 1 EV (on picture, not on sliders). I think the best consistency would be if I attept to do that similarly to what GIMP has in it’s color sliders…

If anybody can get me a proper lightsource temperature adjustment -> scene effect for temperature range in [1901-25000]K range then I’ll do that :wink: Otherwise more consisten would be blackbody radiation (and not inverse (or hoverer RGB->BGR switch in that case should be called))
:slight_smile:

I would advise you to make the slider consistent with user expectations, go with the Lightroom emulation. The black body radiation scale may be technically correct, but you will find yourself forever responding to complaints that the slider is backwards and they will argue the point you’re trying to make in the tooltip

1 Like

I was just thinking two days ago about opening a feature request for colored sliders in white balance.

1 Like

And now you have it :smiley:

2 Likes

What I was thinking was:

  • define the current status as middle gray
  • run this color through the white balance pipe for a few different positions of each slider (one at a time)
  • use the output colors to paint the slider background, starting with middle gray for the current position

Maybe too expensive computationally?

I’m just throwing ideas around, so just disregard any unfeasible or technically impractical proposal :blush:

1 Like

Nah, but a bit complex…

Current implementation (that @houz wrote) is based on http://www.brucelindbloom.com/index.html?Eqn_XYZ_to_T.html (and related works) so it correctly calculates blackbody colors (imagine a material heated to that temp, will emit that color of light). The inverse is just switching reply from RGB to BGR (same as lightroom does).

Assuming current as middle gray and then going with it both ways for temperature wouldn’t be so bad visually nor computationally, but unless there’s some paper describing that I’d feel it’s “wrong” if you know what I mean.

It’s sensor blue. Which is not blue at all. Which makes me wonder about the usefulness of the colour in the control.

Sensor RGB is called RGB just by convention. None of these channels actually represent the color they say.

As I said on Github :

Inverting the gradient so that 1900K is matched with blue really itches me. I would just rename that slider “temperature of the illuminant”, which is remapped to D65 or D50, depending on what the input color profile expects.

Doing things the stupid LR way just because people are used to it is a slippery slope to follow.

1 Like

Visual indication seems to be good idea. Seriously - best example being color balance module, where one “knows” what slider will (probably) do. Similar thing with filmic rgb, where orange color was utilized perfectly to indicate problem/point of interest.

Agree :slight_smile:

A bit off-topic here but is there a reason why white balance bottoms out at 1900K? I’m doing some infrared photography at the moment and quite a lot of the time I’m hitting the bottom of the slider.

On that I would tend to agree. If adding a color scale forces a choice between irking one group of users or confuses another, then it would be best to leave things as they stand.

There is a vast difference between white balance and colour balance. Colour balance works in sRGB or ProphotoRGB, where blue channel “means” blue. White balance works in unbalanced sensor RGB, where blue channel means “that upper slice of the spectrum split by the sensor”. It holds no perceptual meaning whatsoever, and the first comment about it was the “blue” slider shifts the picture to magenta, which is telling it will not improve UX. More importantly, you will not be able to match sensor blue to display RGB.

There is simply no colour at this point of the pipeline. The only places where you can show colour is the temperature and tint, because you are able do derivate a chromaticity from black body temperature, and match it to display RBG, but that’s about it.

I think polynomial models matching the black body temperature to spectral emissions stop at 2800 K or something, then it’s another model that is used and that gets wonky pretty fast. But infrared photography is completely out of the scope of white balance, since the very definition of white (and all subsequent chromatic adaptation) applies in the visible locus.

1 Like

Maybe one for a separate thread: pretty much every tutorial for post-processing infrared starts with discussions of how to set the ‘white balance’. Of course, it’s not real white balance because, as you say, it’s not in the visible spectrum, but I don’t know what other tools to use as it’s a pretty niche subject.