Comparing filmic color science v5/v6

This is my tone mapping method

plus saturation

Original raw with lowered exposure

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;
1 Like

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.

That looks great! A very natural transition from red to yellow. I like it!

A problem with this particular image, though, is that the red channel is actually clipped, so some of the yellow is an artifact.

It’s fun how we are building a vocabulary here, with the “salmon” and “rat-piss yellow” as names for artifactual light-red and yellow.

2 Likes

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…

Are you sure about the filmic doesn’t cause a hue shift bit? I don’t know colour spaces, unfortunately, but LCh’s ‘h’ seems to change. See Comparing filmic color science v5/v6 - #59 by kofa.

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:

Before input color profile:

After:

Besides the ‘rat piss yellow’, we have green as well.

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:

1 Like

Given the direction the thread has taken, maybe someone might find some of these discussions interesting:

2 Likes

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.

I can highly recommend reading those discussions.

A last comparison:

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)

this second image is my tonemapping

1 Like

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 :smiley:

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 was actually quite happy with my filmic less edits near the start of this thread…no wrestling with norms and color science :slight_smile:

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 :grin: 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… :smile:

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.

1 Like

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…