GNOME Bugzilla – Bug 740153
White balancing gives unpredicable and/or unusable result
Last modified: 2018-05-24 14:54:12 UTC
When I choose Tools -> Color Tools -> Levels, and use the bottom droppers for black point, grey point and white point, it matters in which order I use them. Furthermore, the white point is unusable, as it "overexposes" the image. See the glare of the light source in the envelope before you use the droppers. I've been in contact with the manufacturer of the grey card, and he concludes that there is no glare from the light source catching onto the grey card. The attached file contains an envelope together with a grey card with a grey surface, a black point and a white point. I have set the size of the color dropper to 9 pixels. It used to be 3 pixels, so I thought the error was that, but it gives the same result. As soon as I sample the white point, the image gets overexposed. I have also tried Corel PaintShop Pro 15, which does not exhibit this behaviour.
Created attachment 290745 [details] Envelope and grey card Envelope and grey card.
It also seems to differ in which order in which you apply the black and grey droppers, which it should not. PaintShop Pro has an option "default", which resets the droppers to start position, and I do not know if the dialog is in default mode when I start it the very first time. It is a bit unclear. It is a good thing that there is a Reset button, though.
I don't know what to expect here. The card's black and white areas are not the darkest / brightest areas in the image, so overexposing sounds right to me. Everything that is whiter gets clipped to pure white, everything darker to pure black. What is strange though is that the gray point picker behaves differently before and after the black and white points are picked.
OK, but the result is different than for instant PaintShop Pro 15. It handles the three droppers correctly without clipping. I'm sitting 1 meter from the target. It seems OK, as long as you don't involve the white dropper, but compared to PSP 15, it gives a bluish tint.
"Pick white point" has two meanings: 1. It can mean "Move the Levels right Input Levels Value Channel slider to make the highest RGB channel value (or lowest, or average of all three channels, or true Luminance, or etc) for the place that is clicked equal to 255." This would make the image brighter without changing the color balance. 2. It can also mean "The spot I click on is neutral in color, so for that spot R, G, and B should be equal. So change the Levels right Input Red , Green, and Blue Channel sliders to make R=G=B, but don't clip any channels while doing so. Right now GIMP's "Pick white point" combines both meanings for "Pick white point". But the user probably wants to use "Pick white point" only for the second meaning. The user wants to color balance the image using "Pick white point". The user doesn't want to blow out any highlights in the process. The code could be modified so that the Output Value channel right slider is automatically lowered enough to compensate for the increase in the R, G, and B channels that was required to make R=G=B=255 (as happens now). And then the user could move the slider to make the image more or less bright as desired. Similar considerations apply to "Pick black point". For example, clicking on the gray patch using "Pick white point" requires lowering the Value channel to 112 to restore the otherwise clipped Red, Green, and Blue channel information. The user can already do this manually to recover the blown highlights in GIMP 2.9, but not, it seems, in 2.8. Why use the gray patch to set the white balance? It's easier to get neutral gray colors in a paper print for midtones than it is for shadows or highlights. So the gray part of the card is probably the more accurate portion of the card to use for setting the image white balance. But this can't be done in GIMP 2.8 without modifying the code to lower the Value channel slider enough to not clip any RGB values after using "Pick white point". Setting the white balance by using "Pick black point" and "Pick gray point" in addition to using "Pick white point" assumes that something is seriously wrong with the image that can't be fixed by setting the white balance just using "Pick white point". I wonder how PhotoShop, PaintShop Pro, etc manage to keep the order of picking from affecting the outcome. In the current image, the ratio of Red to Green to Blue for the white balancing card is different for the white dot, the black dot, and the gray patch. Trying to use all three portions of the card to set the image white balance seems a bit problematic.
Created attachment 315044 [details] White balancing the sample image Why white balancing the user's image is not an easy task: 1. White balancing is a highly color-space-dependent editing operation (http://ninedegreesbelow.com/photography/unbounded-srgb-color-correction-fails.html; the same mathematics applies to bounded color spaces). 2. The correct color space for re-white-balancing an image is the color space in which the wrong white balance was applied. 3. For camera-saved sRGB jpegs, the color space in which the wrong white balance was applied is not the sRGB color space. The color space in which the wrong white balace was applied was the color space defined by (some proprietary equivalent of) the camera input profile that was used to convert the interpolated in-memory raw file to sRGB before the jpeg image was saved to disk. 4. The user doesn't have access to this "equivalent of an internal proprietary camera input profile". So sRGB not the right color space to correct a "baked in" wrong white balance, and neither is any other normal RGB working color space. 5. It turns out that of all possible RGB working spaces, sRGB is just about the worst possible working space for attempting to re-white-balance camera-saved sRGB jpegs that were shot with the wrong in-camera white balance. The attached jpeg shows four different attempts to white balance the user's image: * V1 is the result of converting the image to a linear gamma version of the Rec.2020 color space and using "Pick White Point". The colors are still wrong, but the "degree of wrongness" is less than the "degree of wrongness" that results from using "Pick White Point" in the sRGB color space. * V2 and V3 show that in the sRGB color space using "Pick white point" to re-color-balance the image will make the image look very yellow in the highlights, and somewhat blue in the shadows, regardless of whether the operation is done in the regular sRGB color space or in a linear gamma sRGB color space. * V4 shows that "Pick gray point" will split the colors in a way that real light in the real world never does, in the current case producing a more believable wall color, but turning the shadows to inky blue. Variations on "reducing yellow by introducing blue in all the wrong places" are a typical result of attempts to color balance using "Pick gray point". All four versions were processed using high bit depth GIMP so that "Pick white point" could be done using the gray portion of the white balancing card without blowing out the highlights. I made no attempt to preserve detail in the white envelope as doing so would have required extra processing steps.
Responding to the user's specific bug report: First, the best option when using GIMP 2.8 as currently coded is probably to use "Pick gray point" from the gray patch on the white balancing card, and then apply Curves to re-establish desired tonality. Or try "Colors/Color balance" using the values -11/12/50 for the midtones (leaving shadows and highlights alone), again plus Curves to re-establish tonality. Second, the white balancing card in the image can't be used to set the image's dynamic range (the upper set of "Pick" options on the Levels dialog) without blowing out the highlights and crushing the shadows. Ink on paper can never "reflect no light" for setting a precise black point (black ink isn't a perfect light trap). And ink on paper (or just the paper) can never "reflect 100% of the light diffusely" for setting a precise white point (white paper isn't a perfect Lambertian reflector). Third, software that allows the user to "Pick black point", "Pick gray point", and "Pick white point" (the lower set of Levels "Pick . . . "), without have the order of picking matter is probably using: * Some sort of masking or ranges to constrain the results to shadows ("Pick black"), midtones ("Pick gray"), and highlights ("Pick white"). * An internal "fixed order of application" that recalculates the result every time the user picks another point, perhaps using the internal order "Pick white", followed by "Pick gray", followed by "Pick black". * "Pick black, grey, and white" algorithms (the Levels lower white-balancing "Pick" options) that don't actually change the image's current dynamic range but instead simultaneously move the upper and lower "Value channel" end points to maintain the current dynamic range. On the one hand, it probably wouldn't be too difficult to program such an algorithm. On the other hand, this type of white-balancing operation produces *highly* radiometrically incorrect results. In the real world, to reproduce something like the resulting image colors, you'd need the color temperature of the ambient light to change as the intensity of the reflected light changed, which is physically impossible. However, some editing software does include this type of algorithm, and users do use these algorithms to address white balance problems.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gimp/issues/624.