I’ve been working on my own problem image, of a sunset:
There’s a bright, partly overexposed highlight around the sun, which filmic desaturates into salmon and white:
While the salmon hue is probably physically correct in some sense, this looks profoundly wrong to my eyes. Sunsets should get “hotter” near the sun, and “hot” means yellow, not white, somehow. So here’s my mitigation strategy:
I add a parametric mask to filmic that excludes the topmost 1% of Jz, which lets the brightest highlights clip:
And if the effect is too strong, I add a second instance of filmic with the inverted raster mask of the first filmic, but reduced opacity:
For reference, here are two commercial renditions, from Capture One and DxO, which clearly employ different levels of hue preservation:
That’s an interesting comparison. The latter (DXo) version looks a bit salmon too… have you tried setting filmic to V5 and preserve chrominance to ‘no’? That would (I suspect) look more like the Capture One version, at least in the highlights. But I get the impression that it may also cause other problems though.
filmic doesn’t cause a hue shift in highlights (as designed!) and
there are situations were you want or even expect such a hue shift (psychologically)
That seems to imply you’ll have to arrange for that shift elsewhere in the pipeline…
Only for (black body) emitters. And for those, white is cooler than blue…
In the case of sunsets, you are dealing with filtered and scattered light, so any direct link between colour and temperature is muddled anyway
Is this a good design goal if it makes your images look odd? The anti cyan sky effect is positive but that’s caused by clipping right? Somehow it doesn’t add up.
I think I was wrong about V5 no preserve looking better. I just tried it! I’m a bit puzzled about this image actually… something I can’t put my finger on about the colours…
What keeps me up at night is whether this is a look we learned from photos, or whether it is psychophysically fundamental to our vision.
Reflection highlights on skin should not twist yellow. Fire and sunset highlights should twist yellow. Magenta and Cyan twists in clothing, flowers, skies pretty much always looks wrong. This might imply that reddish highlights drifting yellow are simply a pleasant look. Probably connected to “yellow” generally looking “brightest” of all colors, even if technically less bright than, say, salmon.
I agree, but it could well be not a problem of filmic but of dt’s pipeline which somehow gets avoided with sigmoid.
Coming back to the sunflower: whatever the reason for the v5/v6 discrepancy, it’s a problem somewhere and potentially a better example to track down, as the expectations of that color are more SDR than Sunsets or Fires, both of which are higher dynamic range things (sensor clipping artefacts!) and have distinctly different hue-constancy expectations in case of raising or lowering exposure.
I’m finding all this quite complicated and will perhaps have to come back to it. In the meantime here are a few comments -
I don’t understand this.
I wouldn’t expect the histogram profile to affect what the gamut button shows. The 3.8 manual says under 8.3.1.4 Gamut Check “This function highlights, in cyan, all pixels that
are out of gamut with respect to the selected softproof profile.” Which makes sense to me.
I realise now I don’t really understand how the histogram profile works. At the end of 8.3.5.9 it says
“As the scopes module runs at the end of the preview pixelpipe, it receives data in display color space.”
And also
“Image data is converted to the histogram profile before the scope data is calculated.”
So if my display profile is adobe rgb and histogram profile is rec2020 for example, does this mean
a) the preview data is in adobe rgb space and is after all modules except Output Color Profile, then
b) this data is converted to rec2020 space, then
c) a histogram (scope) is calculated
??
I find it a bit difficult to accept that after what is essentially a fancy raising of exposure. You need to go in and manually, by eye edit the colours. The salmon fire is wrong! No “but it’s maintaining hue” arguments can make me change my mind.
The goal should be to be that the colours are correct after such adjustments. I mean that’s the whole purpose right. If you have to manually recreate the scene colours bye eye using a multitude of tools you’re right back to “stupid” tools again. There’s very little advantage to filmic at all.
I find it risky to do local colour tuning. Our eyes and brains are so easily fooled. I need to take breaks and look at the image again another day to be sure I’ve not recalibrated my brain whilst editing. This should be done only in exceptional cases for my type of work. It’s to risky. The internal colour relations are very important to an image.
Edit: If we were to come to the conclusions that it’s impossible to handle the normal range of photography with one tone mapper (for non creative edits) due perhaps to memory, expectations social seeing etc. it would be a huge blow to the whole idea. But then if this could be managed by presets for common scenarios it would be a bit of a work around. Still terrible when processing 2k photos but workable for amateurs with lots of time on their hands.
The yellow in these photos just looks ugly to me, even the desaturated dxo version. It is the infamous rat piss!
One thing you can do if you don’t like the colourless sun, or white flames, or white flowers, is increase the white relative slider. Remember, auto picking the white relative slider will set your brightest pixel to white. But how often do we see true white with our eyes? Most of us will agree that while the sun is the brightest thing we see, it often appears to have a yellow hue. Same with the bright flame. I haven’t downloaded the RAW, but sometimes with my own photos I find manually adjusting the white relative slider is best if I want colour in the highlights.
And there you have the whole problem. “Correct” according to what definition?
Filmic gets its input from what went before in the pipeline. At that point, “correct” behaviour is (in my opinion) to put out the same hue and chromaticity as went in (as far as possible), and only adjust the luminosity (as filmic is a tone mapper).
the pseudo code is this(could be used inside filmic, sigmoid or rgb tone curve):
Power-norm
i=[r,g,b]
max=max(r,g,b)
min=min(r,g,b)
lum=(r^3+g^3+b^3)/(r^2+g^2+b^2)
rtm=(1-(pivot/((r/gray)^power+pivot))) // tone mapping or simple tone curve on the red channel
gtm=(1-(pivot/((g/gray)^power+pivot)))// tone mapped or simple tone curve on the green channel
btm=(1-(pivot/((b/gray)^power+pivot)))// tone mapped or simple tone curve on the blu channel
crgbtm=[rtm,gtm,btm]
maxtm=max(rtm,gtm,btm)
mintm=min(rtm,gtm,btm)
lumtm=(rtm^3+gtm^3+btm^3)/(rtm^2+gtm^2+btm^2)
chromatm=1-(mintm/lumtm)
chroma2=1-(min((r-lum+lumtm),(g-lum+lumtm),(b-lum+lumtm))/lumtm)
chromamult=if(chromatm==0||chroma2==0,0,chromatm/chroma2)
i=[r,g,b]
final_image=((i-lum)*chromamult+lumtm)*0.60+crgbtm*0.40;
I agree that the definition of “correct” is critical. And I concede that it probably varies upon use case. The question is when or for whom the salmon fire, salmon flower and salmon people are correct. Is the hue even maintained? I’m getting confused by all the edits but picked one from above that was a v6 filmic edit. You can’t really argue that white is the same hue as orange. I know about the highlight desaturation but with filmic I can’t quite understand what produces salmon. Presumably a combination of things.
This is a Darktable problem…basically the data go through display before the histogram. So if the display profile is not well behaved it can cause issues. It should be forked and the histogram should get data directly from the working profile but it doesn’t. So this is why there was the thread where it was described to get true clipping you need to set your display to rec2020 to avoid this…your image won’t look right but the clipping warnings will be accurate
Basically I would assume that the overexposure when set to display full gamut would be the same as the actual gamut checker and for me they are not. One is tied to the histogram profile and the other is not. The gamut checker seems to be using the softproofing profile and I don’t think this is correct. I understood that color picker values and gamut values came from the current histogram profile setting?? It’s a bit off topic for the thread but along with what @kofa was noticing and what I have now observed with that sunflower image having a different preview in Lightable vs Darktable despite trying every setting that modifies thumbs. It seemed like the two previews are using different colorspace setting or at least behave as explained by @kofa when he exports…
And someone has mentioned an effect, which describes the ‘visual’ hue shift (humans seeing bright, saturated colours with hue shifts) – the name escapes me, I’m afraid.
Edit: I’ve found it:
I think the ‘sensors’ in our eyes, and the processing pathways (the internal ‘working colour space’ of the brain) can be saturated just like camera sensors and how the computer’s colour spaces can have out-of-gamut colours. And/or the original image may have too much red, due to infrared (though I believe cameras have filters fitted to avoid that – maybe when shooting such extreme heat, they are not sufficient?).
Anyway, I’ve tried introducing a gradual reduction of red (a parametric mask on exposure, merging only the R channel), but got horrible results, whether I did it before of after input color profile:
