Trouble with colour sampling. Is this normal?

For a while now, I’ve had trouble accurately sampling colours in Darktable. I’ve submitted issues on Github in the past but they’ve always been closed as unfixable. Maybe it’s just me, but I feel that accuracy with the colour picker is essential.

Anyway, I took this video while editing tonight because I was having real trouble with the colour picker. I tried lots of things to narrow it down to where the problem is. It turns out that the Crop module and Rotate modules make a big difference to where the colour is sampled. But even when I disable those modules, it’s still not accurate.

Does it look normal to you? Keep an eye on the colour patch as enable/disable modules.

I am on DT5.1 windows computer and I can not replicate the problem. I hope someone can help you with this issue.

I think you should open a new issue. This seems to be different from e.g. Color picker not sampling exact colour under crosshairs in Color Equalizer module · Issue #17851 · darktable-org/darktable · GitHub. That one is caused by the picker using the downsampled preview, which makes pixel-level, precise colour-picking impossible. However, on the video, you select a rectangle well inside the homogeneous, dark region (az least at the 20 second mark), and the picker is way off in both cases.

One thing to check, before you do that: do you, by chance, have the following preference enabled on the processing tab? That would reduce the resolution of the preview even more, leading to even less accurate results, I think:

prefer performance over quality
Enable this option to render thumbnails and previews at a lower quality.

I am on darktable 5.0.0 (Archlinux) and tried to reproduce the issue using a screenshot of your post. I observed the weird behavior that when I selected an area containing a small gray line from the selecting tool in the screenshot, the picked color was gray. When I just chose the dark background the picked color looked normal.



Another test with a test image generated with inkscape.
picker_test
black and 20% gray.



whats your setting “reduce resolution of preview image” :

2 Likes

In my tests it was set to “original” but it makes no difference.

Edit: Also, no difference with or without openCL and “prefer performance over quality”

And this one?

Though I suspect this is not just the averaging (due to downscaling).
Could the downscaling itself introduce edges? When picking from inside the small square, you got 204:

But on the whole image, you got 216:

Another possibility is that it’s not an edge (overshoot) that takes the value up to 216, but rather some of the dark background gets ‘avereged into’ the light square, bringing the value down to 204.

What should the correct value be? (That is, if you create an image filled with the light grey, how does it read in darktable?)

The correct value of a pure light grey image is 204, 204, 204 and is correctly reported in darktable.
Interestingly, if I add a small black rectangle similar to the grey square above, darktable reports 210, 210, 210.

Do the scaling/interpolation options affect the result?

No, these settings make no difference. You can download my original test image from above. Feel free to test yourself. I think there must be something fundamentally wrong with the averaging.

One other thing that may or may not be an issue…what is your histogram profile…if the default then the values are in rec2020… also as the picker gets the values from the histogram profile if your display profile is at all impacting the pipeline it could result in different values than you expect…you could quickly test that by setting your display profile to linear rec2020…image will look funny but the picker value should not change if it does then your display profile is impacting the output to the picker…

A choice of colour space would not explain how picking the maximum RGB from the whole image (dark, except for the light spot in the middle) would give a higher reading than sampling that spot.

Besides, R=G=B is grey in any ‘well-behaved’ space, primaries and gamut can be ignored.

We use RGB working spaces all the time without ever thinking about what a working space really is. One commonly agreed-upon criterion for a “well behaved”, “synthetic”, “working”, or “editing” RGB color space profile is that if R=G=B, the resulting color is neutral gray.
[…]
Well behaved RGB working spaces are color balanced: If R=G=B, the resulting color is neutral, meaning it has LAB coordinates of (L*,0,0).
(https://ninedegreesbelow.com/photography/well-behaved-profile.html#well-behaved)

No I just meant citing values for gray…people often work on the 0-255 numbers assuming we are talking in terms of srgb but the values change when the histogram profile is changes…ya its not going to impact the selection part for sure… I think the roi being used is somehow has issues…esp when you see what happens with the rotate module toggle going from blue to black…

Interesting. I just wanted to check again. But now I am at my laptop at home and everything works as expected with my test file.
I will check some more settings. OS and darktable version are the same. Maybe the graphics card?

I know nvidia has some scaling things that can be enabled and I think they are mostly to support video and video games… one is supersampling … I don’t think these could be an issue but one could also check and see if they have any GPU level stuff enabled and try seeing what it would be like turned off if they do… I don’t think this would be a factor but stranger things do happen…

Oh damn! What an embarrassing mistake :blush:. The color picker was set to max in my tests! But not in @europlatus original post. Still a little strange that the values increase somewhat when you add black but not as strange as I originally thought.

So, basically I can not reproduce the findings of @europlatus.

1 Like

I do not have this setting enabled.

It was set to 1/4! I changed it to Original, and I think I’m getting much more predictable results. I’ll do more testing and see.

I have no recollection of ever changing that setting. It’s probably something I did many moons ago.

1 Like

After some quick testing on the same image as before, I can confirm that I have much more predictable results now. There is still quite a difference, depending on where the rectangle is placed. Near colour transitions is obviously where the problems start to show up.

With no crop or rotate:

With either Crop or Rotate enabled:

I’m not getting the wild leaps anymore, but the RGB values still change considerably, presumably where the picker is actually sampling some of the ocean in this particular picture, even though the rectangle is completely over the orca’s fin.

So, I’m now thinking this is just “as designed”, and that we should really only sample colours with Crop and Rotate modules disabled? Would I be right? Or is there any merit in getting this investigated further?

The scaling algo creates ringing:

Pixel peeping in the Gimp, the light patch in navigation area (top right, under the logo) looks like this:

The middle is, indeed, at value 204, but the brightest pixel is at 215 (the exact values vary a bit based on the display profile and the zoom level).