I tried with an image that had black at RGB 1,1,1, which I exported and opened in Firefox, where the color picker also showed RGB 1,1,1. So in general, blacks don’t worry me, and I’ve never really been concerned or obsessed about this. However, I think it would be useful to know if a part of the image is pure black and be able to see it using clipping. Or am I thinking about this the wrong way?
As the clipping warning 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 that 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.
(darktable 3.6 user manual - clipping warning)
There are no issues with the PNG file above; it displays as it should. Even when I check my JPG files alongside the RAW files, clipping works… For comparison, a RAW image that also has a corresponding JPG file—if I leave the display profile as the default system display, the RAW file has no clipping. But if I set the display profile to sRGB, some clipping appears in the RAW file.
That hints at a display profile that is not ‘well-behaved’ (does not have a real black point, e.g. to overcome crashing shadows by the display, or to compensate a viewing environment where the deepest shadows would not be discernable e.g. because of ambient light), at least the way I understand it.
What is a well behaved RGB color space? Color balanced
[…] if R=G=B, the resulting color is neutral gray. Normalized
[…] if R=G=B=0, the resulting color is solid black, and if R=G=B=the maximum possible value for the bit depth of the image, the resulting color is solid white Well behaved working space profiles
To follow up on what @kofa mentioned in one of his posts…the display profile because of the current nature of its position in the pipeline can cause issues with clipping by actually masking it…
Here is your image with the clipping indicator (luminance only) on and two samples taken one on the man and one on the water. I have set the histogram profile away from the default wider gamut linear rec2020 so that we are looing at srgb for clipping and picker values…
Note the values in the picker dialogue and the settings for profiles…at this point with sigmoid deactivated and exposure set to 0…these are the values I get with a profile I recently made in displaycal as my display profile.
Looking at a second profile made with different settings notice the results… changing the display profile altered the picker values a little and changed the clipping.
Essentially the display profile should not be impacting clipping and picker data but because of how DT calculates these if a profile is not well behaved and it is clipping data already then the clipping indicators wont show clipping because it is essentially masked by the effects of the display profile…there have been some fixes to try and mitigate this but some profiles will still show this…
Adding sigmoid compresses things so you can see more clipping
If your display profile is well behaved then you can set the histogram profile to this (rec2020) and it will in a sense show you clipping as it relates to the working space which is by default linear rec2020. If you have no clipping there then the output profile will handle mapping the working space to the output space ie for something like srgb for a jpg export. If you set the softproof profile to srgb this is what the standard gamut checker uses so you can use that to check for srgb clipping or you can just change your histogram profile to srgb for srgb checks with the overexposure tool… so the profiles are important to determine what will be evaluated as clipping
Discussion and some of the links to work on this can be found here…
A visual here
All this is another illustration of what you saw in your example, ie if you use the well behaved srgb profile in DT there was not an attenuation of the data and the true clipping can be shown…
