Just for my understanding.
Global picker reports this RGB values… Is 259 valid? This is beyond 255, the maximum for 8 bits.
HDR has more bits per channel. depending on your camera up to 16bits.
Global picker gets the data at the end of the pipeline.
Output color profile is sRGB. It should be web safe, colors between 0-255.
… and Bruce’s calculator allows out-of-range RGB values for what it’s worth:
http://www.brucelindbloom.com/index.html?ColorCalculator.html
I don’t know where darktable is pulling the values for the picker, but it’s entirely valid to expect data to be pushed past “white” during processing. Indeed, that’s what you’d want, with the hope that it can be pulled back in sanely prior to export, where it’ll get truncated…
There isn’t enough information here to give an answer. Do you have a tone mapper in your processing stack? + many other questions.
yes, sigmoid. Just ask.
What is your histogram profile set to???
histogram profile is sRGB
Sigmoid should coral it if you have not changed display white…
I took a look at a recent playraw…I dont’ have access to DT right now but with sigmoid off and rec2020 the blown area on the beak of the raptor was 1150 or something and then changing the histogram profile to srgb made it 520 or something and finally turning on sigmoid gave the value of 246. The matrix profile of DT is unbounded so you can see values greater than 255 there esp if the display profile is not an issue with clipping and you are using scene referred modules…
If you do the export using srgb and bring the jpg back in from say the state where the image was 520 for red channel ie srgb histogram and no sigmoid…the output profile will handle it and that area is 255… when you import the jpg…
I didn’t change display white. I exported the image as jpeg, loaded in GIMP, and red is 255 in that point … so it is exported ok.
Let’s say, even I’m not 100% convinced, that the values could be greater than 255. But when we hoover over the live sample, we get this info, which is not correct, because 0xFF (hexa) is not equal to 259 (decimal) …
In any case, something is going on here …
You are working in a scene referred pipeline so it’s not like older or other software that applies the display transform at the outset and then you are working in display space…you can use the legacy module order and the basecurve to set that up and then you will likely see things as you are interpreting them. Maybe share your image and XMP and a more informed answer might put you are ease
They absolutely can. In the scene-referred part of the pixelpipe (so up until the tone mapper), the values are effectively unbounded. 1 (or 255, depending on the scale used) also has no intrinsic meaning and is just another value.
The darktable FAQ has some helpful links: faq | darktable
Yes, sure, I am aware of this. The question is, where in the pixelpipe is the live sample taken? I was assuming, that it was taken after tone mapper. Is this wrong?
“The global color picker works in the histogram color space and takes its samples after the complete pixelpipe has been processed.”
I think you should share your xmp for others to test.
Sure, here you are.
The issue is behind the neck, I made a screenshot.
_C7A8415.CR3 (51.0 MB)
_C7A8415.CR3.xmp (11.7 KB)
This file is licensed Creative Commons, By-Attribution, Share-Alike.
If I recall you are using rec2020 primaries in sigmoid and you made some large changes in the primaries…the large change to blue rotation in combination with the other settings seems to be the main driver of this boost in the red…
Also the illuminant in your xmp is quite different than if you introduce the picker…somewhere between the two might be a better choice also to work with that red channel that is so really high in this image…even just loading it the red is sky high in that zone before editing… rgb primaries could likely bring it back in gamut
But at least here it seems the blue rotation that you have used is a big driver…
Versus no blue rotation
Without sigmoid the red is quite out of bounds…with your illuminant…