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.
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…
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?
After all the title question is about 33 % solved! Thank you.
I recall the picker indeed does a small blur / averaging before sampling.
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?
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??
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)”:
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:
Correct, when image stands still (left 60 and right 238):
Flickering, when moving image horizontally with left mouse button:
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.
what if you try it with opencl off assuming it is on?? I have always noticed those transtions as DT processes and refreshes…
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.
Dear Bastian,
thank you for this information. So the color picker:
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?
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.
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. 
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.
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:
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:
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.
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.
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:
@darky without some explanation of your working spaces and color profiles, it’ll be hard to say what’s right and wrong.
Thank you Mica,
to my humble opinion the issue has nothing to do with DT working space and color profiles. It is just how the pixel calculation is done. May be you can try my posted PNG file. I doubt, that there is any special setting in DT to do the calculation and display correctly.
Here is a screenshot of my Smath calculation result:
In DT you can play with all profiles (input, display, working) and even with all set to sRGB (web safe) the color picker and display is incorrect.
Well for sure you can see the different pipeline processing or something going on for display/preview of this image… If I select 100% or anything greater directly from the dropdown I get yellow or green display… whereas anything under 100% zoom or any scrolled zoom will display as more the red…
200%
Arbitrary 172…
On my screen 100 and 200 are more green…this doesn’t show in chrome as I am looking at it here now…
Yes, thank you Todd.
For high zoom > 100% of course the display turns better, because you see the single pixel better.
Open the checkerboard file with Gimp and it is displayed correct for ALL zoom values.
This should always (like in Gimp) be the resulting
and correct effective (perceived) color:
This is RGB=188,188,128 and not the red with G=128
from the wrong DT color picker and display.
Y it was just interesting to see the different processing in DT 100 200 400 or any setting that I could go to directly from the dropdown looked like what you are showing… if I scrolled one click then I got the more red version… so 105 195 250 850…any percentage so DT must use a different scaling or processing for any zoom not in that list??
