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 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:
does pick the color from the downsampled preview, which is apparently also sharpened and
does take into consideration an unknown number of pixels and
does calculate wrong with the arithmetic mean of RGB values and
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?
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:
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.
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.
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:
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:
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…
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??
the wrong sRGB color calculation is not a new thing and I really do not understand
why a sophisticated tool like DT does address highly complex modules
but does NOT address the basics of RGB calculation for display and color picker.
A couple of people raised the topic multiple times as a general issue
of most software tools for image browsing, (pre)viewing, editing, scaling …
Since 2007 (!!!) Eric Brasseur about “Gamma-Scaling-Error” on his website www.ericbrasseur.org/gamma.html with the famous test image of Dalai Lama.
The math and solution is well defined in sRGB standard IEC 61966-2-1 since 1999 (!!!).
The standard has to be purchased, but all relevant formulas are published.
For example here: en.wikipedia.org/wiki/SRGB.
In the chapter “Transformation” you find the gamma-companded and gamma-compressed formulas. They are defined stepwise, a linear area and an exponential area.
On my website www.mtlc.eu/dam/srgb.html you can find a couple of graphics of this function.
The principle with sRGB is:
For any pixel calculations you have to convert the nonlinear coded sRGB values
back to linear values. Then you can process and make any manipulations.
For example the average calculation of color picker or resizing images.
After this you have to convert this result back to nonlinear coded sRGB.
I assume, that this calculation is done correctly in all DT modules with state “lin RGB” processing.
But I will check step by step, if this is really always the case. Especially the “last” module with scaling to specific output pixel dimensions is most important.
Without correct scaling of images in any zoom not equal to 100 %, the displayed image
will be wrong and the result is subject of misinterpretation!
This does not affect homogenous color areas, BUT it does affect any small details
(color and brighness variation between pixels).
How and to whom shall I address this DT issue? Thank you for any advice. May be a direct contact to the SW authors? I am hesitating to explain this simple basic topic in Github in detail. I can understand Aurelien, who complains about GUI extensions in DT. Better concentrate on the “hidden” basics. sRGB standard is now 24 years old and apparently still ignored quite often.
Here is a good color picker: onlinejpgtools.com/jpg-color-picker
who does the color calculation exactly how it should be.
It can not only pick from jpg, but at least also from png files
You can start with from 1 px to more pixel eyedropper diameter.
Following is a screenshot with my above checkerboard and the correct effective color with 15 px radius.The checkerboard is not displayed correctly (scaling issue of all browser), but the measurement result is ok.
But you need to upload a file. That is why I would really like to have an offline color picker tool, with all these features! Or even better implemented in DT or/and Ansel!
