RGB calculation: Color picker and display (wrong), exposure module (solved)

Software darktable
1

Can someone explain to me, why the exposure module and color picker in darktable is doing the calculation not linear and therefor not correct? Please correct me, if I am wrong or do miss something basic with my following interpretation.

In the next graphic you see a 50 % checkerboard in the background. In the foreground are two homogenously filled areas. With zoom 100 % the background should have the average intensity of 50 % and therefor roughly sRGB=186 (right side area) and not the left side value of sRGB=128.

checkerboard_ok
The color picker from top to bottom does give the results:
picker_ok
The 2nd value of the checkerboard is the arithmetic mean, but not the perceived brightness of 186. If you zoom such image in a browser or irfanview or most other tools (inclusive darktable), the brightness of the checkerboard will change and deviate strongly from the correct average of 186. This effect is well known. Look for the good and famous article of www.ericbrasseur.org/gamma.html about gamma error in picture scaling.

But it turns even worse!
If you decrease with the exposure module in darktable with −1 EV, the result is as follows:
checkerboard_wrong
The color picker does show (again left to right = top to down):
picker_wrong
Again, the mean calculation of the second checkerboard value is the “mean” average. That is acceptable as arithmetic value, but: The exposure module does the calculation not with linear light. The modification of −1 EV corresponds to 50 % intensity. And 50 % (−1 EV) intensity decrease of sRGB=186 (50 % intensity) is not sRGB=93, but it is sRGB=137 (25 % intensity). The value of 93 is too dark, because sRGB=93 is only about 11 % intensity.

You can try this also with any 255 (100 % intensity) white filled area. Decreasing the exposure by −1 EV should give 186 (50 % intensity) and not 127 (21 %). BTW, depending on calculation and rounding with exponent 2.2 (approximation) or 2.4 (accurate) according to sRGB standard the 50 % gray is 196,187 or 188 and 21 % can be 127 or 128. I usually calculate with correct values 188 and 127, but my above figures are not yet updated with this.

Wrong gamma calculations generally give too dark results. Especially with fine bright details this is visible. This because one white pixel line and one black pixel line do NOT give sRGB=127 as perceived average, but sRGB=188, which is much brighter (50 % instead of 21 %).

Looking forward to your enlightening comments.
Thank you!

2

Be sure first that mapping collapsible parts on those modules are correctly reset. If not, it’s mapping that is done. To reset, open it and double-click on sliders. Those mapping do not work on the best intuitive way…

3

What is your histogram profile set to??

You might have provided this image??

Two pickers one on 128 and one on 193

0EV

image
image1920×1080 324 KB

-1EV

image
image1920×1080 299 KB

+1EV shows unbounded profile used by DT

image
image1920×1080 295 KB

So appears to be using sRGB(0-1)

Likely because of how the display profile is used, ie again likely 0-100% ??

From the manual

“As the global color picker runs at the end of the preview pixelpipe, it receives data in display color space then converts it to histogram color space. If you are using a display color space which is not “well behaved” (this is common for a device profile), then colors that are outside of the gamut of the display profile will clip or distort.”

I think it would be better if DT were like vkdt shown here as one way you can set up its pipeline… I know there has been discussion about this position of the display profile in DT…

image
image3839×2159 1.13 MB

4

Thank you very much Todd,

Yes, the display profiles in the “toggle gammut checking” warning triangle (right mouse button) have a strong impact on the color picker. I have calibrated and profiled monitors, but my profiles in DT are still all set to default “sRGB (web safe)” for display, softproof and histogram profile. So my png test image you referenced does show with the color picker exactly the homogenous sRGB values which are given as text information in the png image. In this forum are some updated images with various gray areas:
synthetic-image-for-understanding-darktable-modules

When I switch to “linear Rec2020 sRGB” for histogram profile, the color picker result for sRGB=188 (50 % intensity) is then 128 (50 % of 255). But still a reduction of −1 EV in the exposure module does give the wrong result 55 and not 128 or 188 for white sRGB=255.

I know about calibration and profiling and own a spyder5 with spydercheckr24. But DT is really confusing with the wrong “mean” color picker and with exposure −1 EV not beeing 50 % but something else!

To my humble opinion the arithmetic mean value of sRGB pixels is nonsense and really useless. To make it correct, you have to convert sRGB values to linear intensity, then make the arithmetic mean and then convert back from linear to nonlinear sRGB.

For a 50 % white+black checkerboard image the average sRGB value is definitively 188 and not 128 or 55 or something else. So you can not trust this color picker, regardless of profile. If the color picker does not show the correct value for checkerboard it will not show the correct values for any other mixture of any pixel colors.

6

May have stumbled on it… note the module order…there is one for jpg and non raw that moves exposure after (above) the input profile… I think this fixes things… For raw it comes before and I think often jpg files don’t trigger this automatically…

image

EDIT:

If this is the answer in your mind we should edit the title to solved

2 Likes
7

That definitely would make sense. For raw images, input profile only does gamut mapping - it’s linear in and linear out.

For JPEG inputs, input profile does linearization. Doing an exposure adjustment on the nonlinear data before the input profile would be Bad. Even an exposure adjustment afterwards would be problematic, in a similar manner to doing exposure adjustment after filmic/sigmoid/basecurve.

8

A little off topic but given your interest in synthetic and test images… I came across these backing up through a link shared by @flannelhead on a recent post by @kofa

I am going to look through them later…

9

Dear Andy and Todd,

thank you for the highlighting. Yes, apparently darktable 4.0.1 does not switch with PNG, but also not with JPG files automatically to the correct module order v3.0 JPEG. That is a pitty. Can this be corrected/configured somehow from the user?

With this module order the exposure slider does result exactly as it should. Exposure −1 EV does then decrease sRGB=255 white to sRGB=188 gray. Problem solved

But the color picker is still doing wrong calculations for any mixed pixels. Take the white/black checkerboard with 50 % white+black. The mean value is still 128, but should be 188 and even the max and min value is not 255 or 0, but also 128. This effect happens in both modes (point and area). Seems that the point mode isn’t a real point=pixel, but a small area of pixels (the visible picker circle?).

There is an additional issue with the color picker when approaching with high zoom from a dark gray area to a brighter area. The picked color does not change smoothly, but as follows. In this example the two areas are sRGB=60 and sRGB=255. In the figure are 5 picker point going from left to right (top to down). Very strange is the much too dark value 44 and too bright value 269 next to the edge. What’s going on here?

from-60-to-255
from-60-to-255_picker

After all the title question is about 33 % solved! Thank you.

10

I recall the picker indeed does a small blur / averaging before sampling.

11

Yes, Sakari. Thank you.

And the averaging calculation is not only wrong, but there is also a strange overshoot, when moving from dark to bright. I tested with two filled areas having exactly sRGB=60 and 235. With a maximum zoom, the value of the picker does change from 60 over 46 and 251 to 235 when moving over the area border. At the edge it is 178 (not correct, because no linear and no nonlinear “mean” value).

Just checked with the fresh new DT version 4.2.0. A pitty that this bug was not on the focus. May be nobody ever cared about color picker quality or did not “see” it?

12

Well not that I know any better but recalling the issue with the highlights and the brilliance slider and the way it would introduce something like lens flares or blown areas if you pushed it beyond its limits, you would often see the artifacts vary highly depending on the zoom and also you could have 3 versions of the image one in the navigation preview, one in the main display and one that would be different on export. This was apparently a side effect of the different pipelines used for each of these displays but if this could happen then I could see how you might also potentially see different things at different zoom’s … or maybe not maybe this would only be an issue when some elements were near thresholds crossed slightly differently due to the calculations for the various previews??

13

May be a misunderstanding? For the reported color picker issues and PNG test images, I have of course not any modules activated. Only input and output color profile are enabled by default and both set to “sRGB (web-safe)”. The working profile of the “input color profile” module is "linear Rec2020 RGB. The profiles at “toggle gamut checking” are all set to “sRGB (web-safe)”:

dt-profiles-for-jpg-png
dt-profiles-for-jpg-png697×401 28.1 KB

With this setting the possible optional exposure module has the expected influence on sRGB values. But the other issues of color picker are really strange.

But what I just detected:
If you move the image with your mouse with maximum image zoom (1600 %), then you can see on the screen a flickering edge between dark and bright areas:

  1. Correct, when image stands still (left 60 and right 238):
    dt-flicker-ok

  2. Flickering, when moving image horizontally with left mouse button:
    dt-flicker-zoom

And the big surprise. The sRGB color values displayed by color picker, when you move him slowly over the non moving picture 1, are exactly the visible colors of screenshot 2. These values are starting wiht 60 but near at the edge turn to 62, 46, 178, 251, 235 and finally to 238.

What the hell is going on with this color picker? Is it my PC? Is there a sharpening going on in the background, which is not visible and affects only the color picker and when you pan the picture on the screen? Can someone confirm this behavior? I am using since one hour DT v4.2.0, but the effect was identical with DT v4.0.1.

14

what if you try it with opencl off assuming it is on?? I have always noticed those transtions as DT processes and refreshes…

15

What you’re seeing there is the preview, AFAIK, i.e. the same thing that’s visible in the preview window at the top left. The color picker samples from the preview, which should be something like a downsampled version of the real image, i.e. smoothed. However, your screenshot looks like it’s sharpened as well.

16

Dear Bastian,
thank you for this information. So the color picker:

  1. does pick the color from the downsampled preview, which is apparently also sharpened and
  2. does take into consideration an unknown number of pixels and
  3. does calculate wrong with the arithmetic mean of RGB values and
  4. does calculate something unknown as min max value.

Huuuu! That is no comprehensible and useful precision. The perceived color and brightness is not such mean and “sharpened” sum of RGB values.

But DT is not alone with such color picker issues. For other tools including blender there are ongoing dicussions about this. I am also still searching for a simple windows color picker, which can pick more than one pixel. ColorPic v5.1 for example is quite good, but fails also with correct (linear) 3x3 or 5.5 pixel sum. Other standalone color pickers have other issues, e.g. do not work for multiple monitors.

My above screenshot 1 is from the main image. Screenshot 2 is from the main image during movement of the image with left mouse button. Strange, that the image is sharpened only during movement. May be a graphic card effect? Or during movement the preview graphic is displayed in the main window?

17

The problem as I understand it is that the main view only renders what is visible. It therefore might not be rendering the spot a color picker sits on, so we can’t really sample from that. Additionally, the main view pixels change when zooming, but we don’t want the color picker to change value when zooming. Which is why it samples from the preview, as far as I understand it.

No idea about the sharpening. That might be a bug. I have no idea. I would assume that sharpening is necessary to make the preview look good.

Therefore, as a precaution, I always try to sample far from edges. It may also be a good idea to use the area picker whenever possible, as that introduces a second layer of averaging.

18

Thank you Bastian for the explanation.
Now it is clear, that the color picker has some drawbacks, which might be difficult to solve.
And DT is finally not a measuring device. For best measurement we have our human eyes. :slightly_smiling_face:

The area picker is not better, because the wrong mean calculation is also taking place.
If you have an area with different pixels (not mixed pickles!) the color picker result
is not the perceived color, but much darker. 128 instead of 188 for a checker board in point and area picker mode.

Yes, an output sharpening does always makes sense for the DT preview or any exports with lower resolution. The required raw input sharpening and the artistic sharpening is something else.

19

Happy New Year to everybody reading this!
I hope you have had also good experience with new DT 4.2 after Xmas.

I checked again DT and its pixel calculation. I am sorry the math behind is wrong!
Take a checkerboard image with:

  • RGB1 = 188,255,128 (light green)
  • RGB2 = 188 0,128 (magenta)

and the resulting image is displayed in DT not correct with average RGB = 188,188,128 but wrong with RGB = 188,128,128. So the visible color is wrong with “light red” instead of correct with “light yellow”. The display in DT is wrong:

  • for color picker and
  • for preview and
  • in the darkroom with zoom > 100 % or zoom < 100 %

Other tools like Gimp or Mobjects can do this calculation and display absolutely correct, but Digikam has the same error as DT. Apparently for a lot of professional tools NOT every pixel counts!

Please find in my next post the checkerboard file and the calculation result.

20

Here is the checkerboard PNG file. Please zoom this in any application including the browser and you will see, if the application does or does not falsify the effective color.

mtlc_checker-col_green-magenta_v20230106
mtlc_checker-col_green-magenta_v20230106900×506 3.25 KB

  • Note: the correct color is light yellow (sRGB=188,188,128)
    and NOT light red (sRGB=188,128,128)

As usual for internet browser the effective color is also wrong in this forum. But you can zoom with Ctrl-Mousewheel until the 900 pixel width is displayed correctly.

To be clear about the checkerboard file, here is a zoomed detail of it:
mtlc_checker-col_green-magenta-zoom_v20230106

1 Like
21

@darky without some explanation of your working spaces and color profiles, it’ll be hard to say what’s right and wrong.