The picker has some nuance… I set mine to rec2020 and I know that my display profile is not bounded and causing an issue. So this shows me if gamut is ever out of bounds during processing. Because DT has this display profile in the way and not branched out it can for certain profiles cause a problem … In any case I think the only way to be sure that you would always get srgb values would be to set working, histogram and in some case the display profile to srgb otherwise during colorspace converstions there might be small discrepancies. Setting the output profile to srgb maps your data to srgb so I don’t bother setting my picker to that but I can set that with the softproof profile and toggle that on to toggle srgb for the picker values in srgb if I want to see them…
In my case the values don’t change for a couple of selected images claiming to be pure red…only changing the histogram profile alters the values and that is expected…
What do you mean when you say your “set your picker to x”? As far as I know, you can’t set your picker to anything. Are you talking about the histogram profile? I have my histogram profile set to sRGB, but the picker values seem to be reading different values, despite the manual saying the picker works in the histogram profile space (sRGB in my case). So I’m still confused.
The histogram profile determines the values for the picker…this is one of the nuances… so the values will be expressed as appropriate for that colorspace…Profiles are generally matrix and unbounded so you can have negative values and values greater than 255…often they will look weird and the display profile/colorspace cannot accommodate them
If I set my “working profile” to sRGB, I get standard colour picker values (red = 255, 0, 0)
If I revert it to default Linear Rec2020, I get different colour picker values.
This suggests to me that the global picker is governed by the working profile rather than the histogram profile as the manual says. Am I right? Or is there just something I’m not understanding?
Unless you’re saying that the histogram profile is unbounded sRGB, which explains the different values you get for something like pure red?
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.
(emphasis mine)
Maybe if your working space is linear Rec2020 (which is darktable’s default), even if the colour is inside the sRGB gamut (e.g. your input is sRGB, and you don’t enhance/boost colours), the display profile distorts something. What happens if you set your display profile to sRGB, too?
I would say its your image or something…changing the working profile usually has little impact on that.
The DT srgb profile is unbounded as far as I know…
Looking at this exr image you can see initially where everything clips (visually) to white based on the limits of my display…but the data are encoded and not clipped (note the samples). You can see that if I toggle the working profile with the histogram profile set to either rec2020 or srgb that it doesn’t change the values…
Changing the values of the histogram profile does…
And using filmic maps to the display as it should and the values correct… to approx limit of the display …
My display profile is currently set to “System display profile”. If I change it to sRGB, I get a very small difference in the value of red = 254, 10, 10 (compared to 254, 9, 10 when set to “system display profile”). so basically no real change.
But I’ve just discovered something: the default gamut compression setting in the color calibration module is 1.0. When I reduce that to zero, I get the values I would expect (255, 0, 0 for red).
I had set color calibration to bypass so I didn’t think it was having any effect on the image, but the default gamut compression does have an effect. I will do a few more tests, but maybe this was the issue all along! Sorry if I’ve wasted everyone’s time…
I don’t think it was a waste of time… I always forget about that bit of default gamut compression. People setting bypass might as well. If filmic is on I think then it is has less of an impact overall but still looking at the image I shared above… it looks like this upon opening…but it would be applied by the look of it whenever CC is enabled for this image you can see the change induced in the second image.
Yes, me too actually. But I was experimenting with the new Primaries module in the Windows dev version, which I haven’t set up as my proper production editor. So, color calibration was on by default, and that bit of gamut compression caught me out.
You’re right, it’s not a total waste of time. I always learn something new when I go down these rabbit holes, but sometimes I get even more confused. Like, I thought sRGB was by definition bounded, but it turns out you can have unbounded sRGB!
