3.3.0+1211~g2fba9d98e, Ubuntu 20.04, OpenCl enabled or disabled
For quite some time I’m observing a unexpected behaviour when using the hue eyedroppers in color balance module. The effect is small (more or less not noticeable) for small slider values of saturation, but gets clearly visible for large values above 50%.
Test image for demonstration of the unexpected behaviour :
load this test image into darktable
select module color balance
click mid-tones/hue eyedropper (gives a reading of hue = 186,74° / saturation 53.09%)
take snapshot (for comparison)
move saturation slider with the mouse a tiny bit to the left, then back to the right (giving the same reading of hue = 186,74° / saturation 53.09%). The color changes markedly as shown in the following screenshot (left snapshot after using eyedropper, right after slider movement)
For me this looks like a bug : the numbers shown for hue and saturation are identical in both cases, for significant different colors. Or formulated differently : The readings shown after using the eyedropper seem not to correctly represent the result of the underlying calculation. Someone able to reproduce?
I confirm the behaviour, using dt 3.3.0+1217 — however, I am not certain about it being a bug
I am on some thin ice here, but let us try to analyze the image:
Look at the histogram (before any changes). The image has an RGB value
of 231, 136, 136, resulting in two spikes in the histogram. One R spike (value 231), and a combined G/B spike at value 136.
Then you invoke the mid-tones hue eyedropper in the color balance module, which manages to put the spikes closer together – but it does not succeed in neutralizing the image (in which case all three spikes would have ended up the same spot).
So this leaves me with a hypothesis that the red original spike is outside the work range intended to be taken care of by the mid-tone eyedropper.
“Proof”: instead of moving the saturation slider, invoke a second color balance module, and click the mid-tones/hue eyedropper again. Since the spikes already were quite close when you invoked the second color balance module, they now are in the proper working range.
Or something similar – unless, of course, I have misunderstood the whole thing!
You must not focus on this special test image. I created it to simply give others a fast way to reproduce. Taking any raw image the effect shown can be created. In my understanding the readings for hue and saturation should be independent of they way I get them into the panel. Using the eyedropper should give me the starting point for a further edit with the slider.
Actually using the eyedropper to achieve the readings mentioned in my first post gives a different color of the image compared to entering the same readings by using the slider. In my understanding this should not be the case.
Just tested with darktable 3.3.0+1045 (I don’t have a more recent one on this computer) and I can confirm the behavior.
I initially thought it was a rounding error, but definitely a bug somewhere.
When selected with the eye dropper, the saturation is set to ~53%.
But if I reset the color balance module, set the same hue value, and enter the saturation manually, the correct value to neutralize is around 40%.
From reading pull requests and commits, I know that something has been done in the way those values are stored; maybe a regression there. It’s probably worth a pull request.
Thank you for your confirmation. Would it be possible for you to create an issue at github? Unfortunately I cannot do this myself because github violates my privacy and safety settings when trying to create an account.
Depends on your browser settings. I assumed that you could already have an account. If not, we must hope that one of the developers is reading this thread.
My question is more rhetoric than a real technical issue; the fact that I could have a github account or not is not the question.
Why do you want or impose to someone else to lower his privacy and safety settings if you are not ready to do it yourself ?
