Thanks for taking the time to respond. Based upon reading the extensive discussion here I switched to histogram to the working color space. To be honest, I have come to ignore the histogram, have placed it to the left side of the screen and just ignore it as I now see it as trying to paint by numbers. I am willing to stand corrected on this by an experienced person.
The patch applied cleanly. On 'that sunflower ’ image the difference is quite apparent.
I’m surprised with how little difference i see on other images ? Which is a good thing i guess .
I just had a quick look at some playraw files still on my system. Will have to try more. But is in my build now :).
I normally export in linear rec2020. I had one image where the sky had a certain ‘not too orangey’ look. And when exporting , it suddenly was very , very orange. Exporting in linear 709 fixed it.
Which i thought was weird.
I have the feeling - but not sure - that that same image now exports correctly in linear rec2020… But that might just be between my ears :(.
I use the wave forms. I find this very useful to see what is going on…also the vector scope
Given the following profile settings (working profile is Rec2020, output profile is sRGB, everything else is also sRGB, except for histogram, where linear Rec709 is unbounded, but uses the same primaries as sRGB):
filmic v6 with darktable 4.0.1 defaults:
Same, but merged in lightness mode:
You can see that in the normal blending mode, the reds are squashed to 100%, and the blues are also changed: they are not limited to the sky (the blue arch): we also have blue between the near-zero baseline and the ‘sky arch’. The greens also changed a bit, but that’s not so substantial.
With lightness mode, the reds are not managed; based on my experiments, they’ll be clipped to the sRGB gamut when the final output is generated. Therefore, I suspect it’s mostly the blues that cause the issue.
Switching the merge to the RGB blue channel, we get the salmon petals:
Switching to RGB red, there’s no salmon:
The lightness blended version, exported to sRGB JPG, then reimported (on the right + histogram):
Interesting :). I think that with the blending modes, you are determining which colors, etc, are able to “get around” filmic’s processing. But it will be all processing including basic tone mapping I think.
When filmic V6 is really starting to get to business with the desaturating, and you have these images with lots of oranges and yellows, you’ll see the blues shoot way up (very noticeable in the waveform view).
Filmic v6 was specifically created after people complained about desaturation; it tries to avoid that. That is why you no longer get the saturation graph with v6:
v5:
v6:
Of course, blending in lightness mode circumvents all the colour processing and trying to get colours intelligently inside the gamut. I included it only as a demonstration, not as a recommendation.
I have a couple of presets that I used to use with dehaze that way when I wanted the dehazing without the change in saturation… Acutually I don’t think its a bad recommendation for these types of images.
I get a bit more saturated looking image when I do what you say but maybe we have some other setting different or its just my uncalibrated monitor… but if I open the image with defaults (new ones for filmic and the 0.7EV) I get this … I’ll use a screen shot…
Auto filmic
Bump exposure to something you might consider using?? So say 1.5EV just spit balling
Readjust filmic…auto settings…
Same exercise in lightness… all defaults and auto filmic I get this
Bumping the exposure to 2 EV no addtional filmic… I still have the image…
Using auto filmic settings at this exposure I get this…
So I guess my point is …doing this with filmic gives an image that holds up over a range of exposure adjustment and in some cases I wonder if it might not be easier to correct to taste than fighting with the gamut corrections…again I am talking about getting an image to taste i guess and not color correct if that is a real term… 
BTW, taking the sunset photo from:
https://discuss.pixls.us/t/need-help-for-correct-colors/33116/37
Darkened, without filmic:
Note the hue (LCh): 53.62, chroma 72.63.
Brightened, still without filmic:
h: 53.64
However, note the yellows, most probably due to R clipping.
Filmic v6 (4.0.1 defaults), with only auto-tuning:
h: 44.38 → hue shift
Changing the norm does not really change the h value, only the tone (L), and perhaps C.
Filmic v6, lightness mode:
h: 53.54
Filmic v5, no chroma preservation:
h: 62.90 → hue shift
v5, maxRGB: desaturation (note C=0, so h is irrelevant)
v5, luminance Y:
h: 49.90 → slight hue shift
v5, RGB norm:
h: 38.15, so hue shift, but the sky is almost completely desaturated
Checking the same area in HSL instead of LCh reveals that the dark + without filmic photo has HSV values 11.89; 92.10; 47.82.
Brightened, without filmic: 12.00; 4602.19 (!!!); 98.05.
Filmic v6, normal blending: 11.89 (so, according to HSV, hue does not change!); 100.00 (fully saturated); 65 - 75 (depending on method). Changing the chroma preservation method only changes the V value, but not H and S. However, we do see colour shifts, from yellowing/orange to salmon/pink.
Lightness blending: H=11.92 - 11.96 (depending on the method; slight change), S=180-371 (depending on the method); L=66 - 80 (depending on the method).
It would seem that h of LCh is a better representation of perceived hue than H of HSV. Or colour management (clipping at output) could be playing tricks, and my lack of colour management knowledge bites me again.
What you are showing is really in keeping with what @flannelhead said above about colors that rapidly desaturate and the math used by v6 to maintain hue with Luminance gets really exaggerated…
My start point is likely different from yours but…
Image area with HSL picker… hist profile rec2020 so same as the working profile so picker values come from that
Approx 17.8 245 75
Add default filmic v5 except hard shoulders to be the same as v6
23 86 54
So it shift but still relatively pleasing…
With v6
17.8 50 50
So hue is preserved but more desaturation to achieve this so you get cyans and magentas…
@kofa @kofa Intersting agian- I’ll spend some time playing around with using blend modes in filmic later.
What I notice about this image is that even with filmic off and exposure cut back to 0 eV, the cast of this is sort of pinkish everywhere. I see the same thing with the std build and the test build. This is using the “as shot in camera” illuminant setting in the color calibration module. See below-
no filmic, exposure 0eV
Test build, filmic on, chrominance preservation = no, exposure +.5 eV . You can see here the the brilliance of the highlights is so high that even the test build of v6 is desaturating. This is from the “extreme luminance desaturaiton” slider function defaults, that still desaturates extremes if the are “extreme enough”.
Same as above, but moving the extreme luminance slider to 100% yeilds-
Sometimes screenshots from linux don’t look right because they don’t have the color profile stored. I can’t tell how they look for you, but here is an actual render of the last one above using the test build.
Its a fine balance…so not magenta but this one on my screen at work which is not calibrated is showing a bit of the “rat piss” yellow creeping in
2 Likes
I can see a ‘rat piss / salmon’ toggle appearing in the next release… 
5 Likes
It’s a bit more work, but you can open the file in Gimp, assign (not convert to) the display profile, then convert to sRGB, and export that.
2 Likes
Actually that is exactly what I do , but I was out of time on my lunch break LOL!
Here is a somewhat reduced rat piss version LOL using the exp build once again.
Same as above with Color Balance RGB “vivid” preset and no other color tweaks.
1 Like
In the API reference for LittleCMS2 found here:
LittleCMS - API
The method for gamut boundary check is mentioned to be from Jan Morovic and a paper can be found that describes the procedure here:
Morovic 2000 in Color research and Application
According to the reference doc, colors are essentially clipped to the boundary of the gamut. There is an example on page 109 of the API doc pdf file. In the doc search for “gamut mapping”.
If a color lies outside the gamut, the colorfulness (“C” of the LCh) is reduced such that the new C lies right on the gamut boundary. This is done using constant h (hue angle), and L is also unchanged. Since L is unchanged, I guess you can think of it as a slice through the LCh cylinder space perpendicular to the L axis. So in that slice, each point on the boundary of the gamut is described by rectangular coordinates ‘a’ and ‘b’. In that slice, as the hue angle (h) changes, the gamut boundary has corresponding a and b coordinates defined and the max C for any given h angle is the hypotenuse of the triangle formed by a and b for that particular h.
So mapping is achieved by reducing C until it matches the same C value you get at the gamut boundary.
What isn’t described there is how C gets “reduced”. Do they desaturate by adding white? Some other method? Off hand I’m not sure why it would not escape the challenge we see with v6.