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:
Not absolutely sure, but I thought that one of the design aims was to change only the luminosity, and leave hue (and possibly chroma) alone. That what you posted a bug report about, if I understood correctly
Anyway, my remarks were in reply to @nosle 's posts, where he complained about filmic not causing a fairly large hue shift he felt was required to get a correct image. And that’s certainly not filmics responsability.
I did manage to introduce a bit of yellow in the flames with the color balance and a bit of masking, after reducing contrast with the tone equaliser:
YES!
While not everything discussed there should be seen as “gospel” I think it is a remarkably well informed discussion about goal definitions of a DRT, different approaches for creating DRTs and presenting intermediate results that are somewhat meaningful (including, but not limited to exposure sweeps) enough to compare different DRT approaches.
Reading those threads brought up the idea ushered above that judging fire (it’s representation by a SDR-DRT) is a lot more complex than starting with test-swatches that gradually get brighter and must dechroma at some point, or out-of-gamut swatches that need meaningful representation inside a much smaller gamut.
the first image is the result of a sigmoid tonemapping on the rgb channels, as final step I’ve copied the original hue (from CIE LCH) to the tonemapped image t004100.pfi (39.4 KB)
I’ve just dipped my toe into those discussions. Wow! Until recently I never realised what a complex area this whole tone/gamut mapping thing is. Thanks for taking my thoughts onboard everyone… I think I might back out before I expose my ignorance any further
On second thoughts, I have a quick question… If I use the color picker set to LCh, does the ‘h’ show a valid reading of hue? I ask because I tried switching filmic in and out while adjusting exposure, on @bastibe 's sunset image, and filmic does shift it a bit towards blue - not sure whether its a significant amount or not. If anyone wants to try, I was simply pushing the exposure up and down, with filmic enabled, while watching the color picker on a spot in the bright bit near the sun.
It seems to me that we need to add the norm before assigning something to filmic so filmic plus this norm resulted in this effect because simply using a different one can make the observation something different
I’m just about to give sigmoid a go, in your portable build from a few months back… I’m feeling a little filmic-jaded myself To be honest though, I don’t think I had worried about it too much before I found this thread. Maybe I need to take a step back and actually take some photos!
Sigmoid is very user-friendly on the fire image - by default it gives a bit salmon flames, but it has a hue preservation slider that lets you go all the way to ‘ratty’ yellows if one wants OR anywhere inbetween. It doesn’t feel as flexible as filmic but as an option I think it’s quite good. Having said that, I sort of understand AP’s view that it’s an unnecessary option, but I can’t see anything against having it available…
One more observation, before I head off for now. Sigmoid doesn’t handle oversaturated colour very well… a bright red car turned partly black when I pushed the saturation a bit in color balance rgb. Whereas filmic V6 effortlessly pulls it in line.
I expect there’s a good reason for this, but my feeling atm is that neither are ideal, filmic or sigmoid. Maybe the perfect one doesn’t exist yet…?
It would take some poking in the code and someone likely knows the answer strait away but I think some of the modules might take data from filmic if it is activated…maybe not I just thought I recall AP talking about the scene referred modules being coded/designed to work together so it could be a bit of this that you are seeing… This could also be complete rubbish I am just going from someting I think I recall hearling…
that’s not the case. Exposure and Filmic modules take the exposure compensation from the image exif data and use that info to set their parameters accordingly; there is some communication between white balance and color calibration to flag to the user when there is a doubling up of CAT. But apart from that, the modules all operate independently, and each perform their own gamut mapping to ensure valid values on their output.
If this sigmoid thing is outputting black pixels, it is most likely a buggy implementation in that code.
Thanks I was certain AP had made mention of some interplay between filmic, color calibration and or color balance but as noted I really had not investigated…thanks for setting the record strait…