Conversion by RawTherapee 5.11 confirms the blow reds and also the 100% saturation in the region of interest:
2 Likes
This is all I can contribute:
Find the purest possible tone for color calibration
Check if the skin tone matches
Brightnesses are within a tolerable shade (gray or aquamarine)
In Filmic, adjust the scale (-21.5%) of the range control to desaturate the red…
Cheers
2 Likes
Thanks for your suggestions. It is a difficult light situation: from the left (behind the drumer) strong red light, from the right, evening daylight, shadow actualy, no direct sunlight.
I want to keep some of the red color from the left, but reduced of course. On the right side I reduce the strong blue cast. What I did:
- first I reset all other color changes, clean start
- color calibration, took sample from the big drum in foreground
- used color mixer to reduce the blues and greens using a parametric mask …
and I got this, a good start to continue editing:
1 Like
Regardless of tricky lighting, the manual goes on to say “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”, which was sRGB, so surely anything above 254 is a bug?
1 Like
The global color picker works in the histogram color space and takes its samples after the complete pixelpipe has been processed. […]
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.
(darktable user manual - global color picker)
So this means your display profile can influence the colour you see picked. If you really want to see what the sRGB value is, use sRGB as your histogram profile, and temporarily switch your display profile to sRGB, too.
I’m not sure that during editing the output colour profile is used at all, and if gamut clipping is done. If not, that could explain values over 100% (255).
sigmoid with the smooth preset + sRGB base + adjusted red attenuation could give you this:
Or with Rec 2020, this:
2 Likes
Perhaps, but a value over 255 (and not 254!) is not mathematically invalid (it’s out of range for one byte, but if you are working in 16 bits/channel, it’s actually a rather low value), the more as darktable works in floating point. Keep in mind that the range 0…255 is an “artifact” of using 8-bit integers.
Such a value would be a bug only if it’s supposed to represent a value in an 8-bit integer-encoded image.
The “sRGB” is not relevant here, actually, you could use AdobeRGB…
And there’ s no reason for filmic/sigmoid/AgX/basecurve to clamp the values to 0…1, as long as the final conversion to a displayable or exported image takes care of the conversion to integer and clamping as required.
1 Like
I don’t think there’s anything blown in the raw file except for some specular highlights. Here’s a screenshot from RawDigger:
1 Like
Isnt that what is supposed to happen when the display profile is converted to the histogram profile step (see @kofa comment above with quote from the manual)?
Since @leonidas111 said the histogram profile is set to sRGB, then shoudlnt we expect things to clamp at sRGB specifications?
The way I read that part of the manual is: IF the display color space is not “well behaved”, colors will clip/distort when converted to histogram color space. In which case, a color in the display profile which is out of bounds for sRGB (histogram space) should not produce a value in the color picker which is outside of sRGB space.
1 Like
Well, something funny is going on: if I keep display, softproof, and histogram profiles at sRGB, the picker values behave. If I set the display profile to e.g. “system display profile”, it’s easy to get picker values above 255…
Such settings mean there is a conversion between display space and histogram space. That can easily expand or contract the space covered by the image. As darktable works internally in float values (and there’s no reason to convert to 1-byte integers before actual export), the picker just converts the picked floating point values to integers, with 0.0 == 0 and 1.0 == 255. There’s no particular reason to do any clamping here, so the conversion in the colour picker can lead to values > 255.
Nor is it a problem for any exported image, where values will be clamped properly. If that wasn’t done, you get a situation where you get values “modulo 256”, and that would be very visible. (Or you get a runtime error, which is even worse!)
Note that the actual image, and editing problems in it are actually irrelevant to this issue, it’s purely related to the different colour profile settings. And those haven’t been given by @leonidas111 .
Oh, and of course an exported jpeg is limited to values in the range 0…255: it’s encoded in 8 bits/channel. And that limit is completely independent of the colour profile used… So unless and until you convert it to something working with more bits/channel, you shouldn’t get values above 255 …
1 Like
Yes, and this is documented in the manual. In the darkroom:
Preview pipeline (working profile) → output profile = display → to picker using histogram profile. Most probably there is just no clamping to [0, 1].
I suspect this is it and only at the output is there clipping to the chosen output profile…
Reading here its not totally clear but I think it supports what you are saying…
And to me it makes sense…so you can set the histogram profile at sRGB. This provides the picker value in that profile. It is unbounded in DT or at least thats how I see it… because if you disable the tone mapper you get a value of 300 plus for red…
Using sigmoid it drops but with the changes made in primaries the channels are pushed and this passes through that same unbounded pipeline… If you clean that up in sigmoid you can correct it…
Here is the OP posted xmp with one change using srgb in the primaries part of sigmoid…the value gets even larger in red…
Simply correcting the large blue rotation added in sigmoid brings it back well under 255…
So to me the pipeline through to the histogram profile is unbounded and only impacted if the display profile has clipping or a lower gamut than the profile selected for the histogram profile…which here is not the case as we are looking at a low gamut color space for the histogram ie sRGB.
The necessary clamping happens with the output profile… I think Aurelien has done away with the histogram profile in Ansel to make things cleaner.
Using filmic instead with all the other edits the same manages the red before it goes through the last couple of steps so here again red is contained… you would have to compensate as other aspects of the image are obviously not correct by just swapping to filmic…
So to me it looks like you can introduce values outside of the traditional srbg bounded color space with sigmoid but perhaps when using filmic these are not passed along…
You can show this when you add primaries before filmic with extreme settings of max purity…filmic will keep them in gamut
But dragging it after again you get values greater than 255 so that part of the pipeline will not clip out of range values…
Doing the same with the OP settings for sigmoid and adding that rgb primaries saturation boost caused large values before and after sigmoid…
1 Like
EDIT: After thinking about this more this is wrong or woefully incomplete.
I think @kofa is correct about the clamping. I assume this is because of how ICC profiles are implemented, and the histogram profile is sourced from an ICC. Same as softproofing. Fun fact, softproofing on sRGB will not force a clamp either.
In going through some of my own photos, I have been unable to get a value over 255 (with any configuration of display/histogram) and Filmic rgb active. Even on photos with clipping at the sensor (if dt is accurate).
Anyway, I think this is a case of the wording of the manual being somewhat ambiguous and leading to people (like me) getting the wrong impression of what is happening.
1 Like
Try the log-log view:
Yes, each channel is clipped hard at 14335, albeit at a low count. How that would affect dt’s conversion, I don’t know.
Well, you can only clip to the output values once you know the output format. That could be 8 bits/channel int, but also 16 bit/channel or float… Until that point, best keep the values in the internal format (i.e. float)
As I understand sigmoid, that module cannot produce values outside the range 0…1, the math won’t allow it.
From what I’ve seen, the values >255 in the colour picker arise from certain combinations of display profile and histogram profile.
I checked also with display profile sRGB, and got the same result, that means red values greater than 255.
1 Like
The clipping is in the specular highlights from the reflective surfaces like the drums, earphone and wire, which are shown in the screenshot. You can see from the upper histogram of the drummer’s neck that all the other areas are within exposure limits
1 Like
Understood, thanks.
1 Like
To me this is driven by messing with the primaries in sigmoid. If they are untouched I think normally sigmoid should likely keep things in check but even then I have not tested it and it might not be that true as I was also able to drive values up by using extreme settings in an instance of rgb primaries placed before sigmoid but not with filmic…you can set your display and histogram profile to default DT srgb so things should be fine and still get the greater than 255 values…
THe changes made in the OP to those primaries which are generally there to attenuate things when you have gamut issues actually drive the red out of bounds…one slider the blue rotation setting shoots the red up.
So I think if you distort the primaries using those sliders it is possible to end up with “out of bounds” values that will be greater than 255 even when changing the color space for them away from rec2020 to srgb …
And at least with sigmoid they can be pushed even further…
Ya raw clipping is pretty trivial to a couple of spots…I think the extreme red comes from both the choice of illuminant used and then how subsequent processing impacted that…with one slider in sigmoid basically driving the red really hard by rotating blue to a new position…
Here I add 3 instances of rgb primaries with purity set to max for red green and blue…
If the setting of the OP are used…red gets driven… to like 290
Now just zero the blue rotation that was in the original example …
Values are well managed despite the added push from rgb primaries…
You can also push the red channel in the channel mixer to 2…
OP settings with blue rotation
Reset it to zero and sigmoid handles it…
1 Like
