This is the best I can get using only filmic. I’m using v5 here with no chrominance preservation. Dynamic range scaling and target white luminance were also tweaked.
The results of filmic v6 are very bad.
@kofa so you confirmed it’s a bug. I will try to create a bug report. Maybe I would need some help for that, because I still newbie and not very familiar with the terminology.
Sad that AP is not here anymore. His opinion about this would be very interesting.
I’ve just been playing with the embers/fire image. I’ve got a idea (nothing more) that AP’s view might be that filmic is doing exactly what it should, as in preserving the hue.
I think that awkward ‘pinkish’ look that the flames take on with filmic preserving chrominance is actually very close in hue to what one can see if one simply drops the exposure to prevent any clipping and disables filmic, only brighter.
The problem is that for whatever reason one expects a ‘hot’ red color like this to push into yellow with brightness, which is actually a big hue shift?
Filmic V5 with ‘no’ set in preserve chrominance doesn’t do anything to preserve hue, and it looks a lot better in this case. But apparently (if i understood AP) it causes consistency problems elsewhere.
This is my take anyway - any thoughts?
edit: I’ve just fiddled with filmic and the vectorscope, and filmic (except V5 ‘no’) is indeed preserving the hue angle - whereas any natural looking result is actually drastically shifting reds to yellow. Which looks a lot better - in this case.
To illustrate (hopefully) my point, this image is done using filmic V6 rgb power norm, which looked similar to some of the worse version above, but I’ve added 2 instances of color balance rgb, one to add saturation, and one masked to the highlights doing nothing except introducing a hue shift. It’s not perfect, but looks better IMO, and more like how a fire should look.
I’ve added the xpm file as well, it probably shows some of my other attempts tinkering but should match the jpeg.
Fire, as in hot black-body radiators, might be the worst content to judge highlight compression on.
Intense, bright hot orange fire does hue shift a lot compared to dim deep red glowing embers…namely along the blackbody emission line. And since the viewer knows how ‘More intense fire shifts to orange, then to yellow’ a gamut compression that just desaturates along hue-constancy lines does look “wrong” for deep red embers. Basically, lifting the shadows SO much detroys the perceived relative intensities so profoundly that the “wrong” hue shifting to yellow, mimicks what the viewer would expect from much hotter fire at much higher luminance level.
Displaying glowing red ambers at 4000nits and then highlight compressing that to fit into a 100nit display might just be the wrong starting point for judging a DRT. The underexposed Original is probably a good SDR approximation that comes somewhat close to the HDR version, although much MUCH dimmer.
Maybe testing such issues should always include an exposure ramp to visualise the behaviour better than a single exposure. Then one could ask: which one of the SDR-DRT versions of that fire looks still “good” at which underexposure?
But “wrong” hue shifts with fire might still look acceptable, while the “right” dechroma raises eyebrows. Something without inbuilt hue shifts might be a more practical starting point for judging this.
Hi Bob, thanks! You’ve clarified what I was getting at a lot… it’s an interesting subject!
By default the input profiles don’t have gamut clipping…what happens to your edit if you set that to rec2020 in the input profile…
I am not sure if this impacts any of the things going on here but I have also noted that the following happens…
If I set the overexposure setting to full gamut. Then it seems to use the histogram profile as expected and so if I change the histogram profile I can have more or less of the image out of gamut.
However if I use the gamut checker, it seems to ignore any change of the setting for the histogram profile and it responds to changes in the softproof profile… so set that wider less out of gamut and smaller space more out of gamut… This is with softproofing off as well only activationg the gamut checker. I thought in the pixel processing changing the softproofing profile only resulted in this being used instead of the display profile when soft proofing was on. I don’t think it should impact the gamut warnings that are supposed to get data from the histogram profile and esp when it is also not activated…??
Can you check this??
Todd, I’m not 100% sure if you were referring to my edit, but boy, setting the gamut clipping to rec2020 in the input profile makes a big difference.
This image is as per my previous one, but as well as the clipping setting I’ve switched off the color balance rgb module that I was using for the highlight hue shift, as it’s now redundant and pushing the highlights the wrong way.
The gamut clipping seems to ‘fix’ the pink highlights in one short step… I’m not sure that I fully understand what’s happening here though!
DSC09445.ARW.xmp (13.3 KB)
Well I have just been poking around a few of the settings…and I threw that out therer to test for really anybody.
But it seems like many of the issues in DT are happening trying to manage out of gamut colors or keep them in gamut…so I though why not see what happens if you clip then right as they come in to the working space and try editing a few images that way… I like your edit …looks really nice…
Thanks 
I just tried the same thing with the sunflower image that started this post. It wasn’t so successful.
The first image is my basic edit using filmic V6 (forgotten which options - I think it was preserve chrominance set to max rgb).
The second is similar, I’ve just changed that clipping option in the input profile to rec2020. The whole area around the sunlit petals has, well, clipped! It’s changed the dynamic range that filmic is working with too, if I then auto levels the highlights in filmic it ends up desaturating those petals too.
Just cos I could I’ve posted this image with a quick masked application of color zones on those petals. A quick fix 
I already opened an issue, https://github.com/darktable-org/darktable/issues/12175 (see above)
Edit: unfortunately, I can confirm that the export-reimport ‘trick’ does not manage colour correctly. To verify this, import the Rec2020 TIFF, export it as sRGB. Then, enable gamut-clipping (to sRGB) in input color profile, and export again. Load the two into Gimp as layers, set merging mode to Difference, then merge the visible layers. You get a completely black image. In other words, if you use sRGB output, darktable simple clips the colours, and the good-looking yellows in the output are the result of clipping. I’ll experiment more with command-line tools (tificc, although LittleCMS has been accused of not doing colour mapping correctly). I don’t know what else I could try – the cctiff tool from Argyll dumps core on me (https://www.argyllcms.com/doc/Scenarios.html#TR1).
I can load the TIFF images into Gimp and Krita and RawTherapee, and check the result, but how can I be sure it is correct?
Note that by clipping the gamut you are corrupting the input. It simply means that colours that cannot be handled by the working space (normally, Rec2020) are clipped hard. Since in the glowing ambers, the red channel is the strongest, this will reduce it, while leaving green and blue unchanged – thus, the brightest reds will become orange/yellow.
If, instead, first you reduce exposure (no filmic or anything else is involved!), you’ll see that the input has no (or very little) orange and yellow:
And this is not just darktable; RawTherapee agrees:
BTW, I’ve continued my experiments with filmic v6.
darktable’s export with luminance Y, if output profile is set to sRGB:
Exported as Rec2020, and converted to sRGB using Argyll (LCMS gives pretty much the same result), using perceptual rendering intent:
darktable’s export with no, if output profile is set to sRGB:
Exported as Rec2020, and converted to sRGB using Argyll (LCMS gives pretty much the same result), using perceptual rendering intent:
Same pair for Eucledian (the other norms, legacy Eucledian, power norm and maxRGB, gave very bad results, with all detail lost):
dt’s sRGB export:
For me, no + Argyll is the winner from this group.
Hi István,
Yes, I’ve been thinking about it while going about my business this afternoon/evening and had reached that conclusion… it’s not a solution as such.
I’ve also reached the conclusion that to look good (to my eyes) that fire shot needs a hue shift in the bright bits… I only wonder what the best way is to achieve that… I like the level of detail you’ve managed to retain but (again, to me) the colours don’t look natural. I understand that the hue is correct, but I’ve never seen a fire that looked quite like that in reality.
But the above looks believable and has none of that translucent pinkish appearance. The little flame transitions towards yellow and the embers are also towards orange.
Yes, I agree. I think this comes back to what @PhotoPhysicsGuy was saying . . . basically that in this kind of scene just increasing the ‘brightness’ or exposure without shifting reds towards yellow looks wrong… and this is what filmic does - keeps the hues the same, just brighter. Which happens to look odd 
PS. But I suppose the darker version looks ok because we’re not brightening it… it may come down to what we expect the darker scene to look like?
But the visual signature of the mapping is the same as for the portrait. A pinkish desaturated look in the highlights. It looks less orange than the unmapped dark image. The look has followed filmic for a long time the outdoorsy woman photo, the many sigmoid / filmic stock image comparisons some early cityscape images etc.
This signature comes up again and again and I don’t think a robust way of countering it has come up? Or does it just get lost in the forum for each case?
Is the constant hue assumption perceptually correct for exposure changes? Or is it important for colour grading control?
I get your point. But I don’t think I’m qualified to comment really… in my own photos I rarely have a real problem, and if I do there’s always (ok, usually…) a way round it, tweaking hues in color balance or zones (for example).
But it would be nice to have a setting or, hey, how about a slider in filmic that gives the option of the current, supposedly accurate but wrong-looking colours, OR cheerful saturated colours that might not be accurate but are “crowd pleasing” colours…
edit: I believe the hue preservation or whatever it’s called is important for colour grading control - AP did a video not that long ago, called something like 'Why do darktable’s colors look like s***"
But I don’t know whether it’s perceptually correct… not a clue…
I’m not, as many will testify 
, qualified either! It just seems to me that a tonemapping + module should solve the issues of mapping tones from hdr to sdr whilst maintaining a believable look. It’s the consistency of the problematic look that suggests to me that there’s an issue that could be solved in there.
I’ve mentioned it before but I’m wondering if there is a use case split. I can see how an art director looking to maintain brand colours or a colour grader working against a set palette may benefit from manipulations that have strict hue, brightness, chroma separation. But are they really perceptually correct for normal photographic applications? The struggles around this with filmic really makes me wonder. Saying that I understand it’s a tricky business and the photoflow RT solutions aren’t bulletproof either.
That seems an interesting point, the possible use case split. But I’m going out of my depth… 
It’s only in the last year that I’ve dived into processing raw photos - I was mostly a jpeg guy before that… I still shoot raw+jpeg so I have the option. But it’s increasingly rare that I use the jpgs! I started by using PS Elements Camera Raw… but never found much point over the jpgs somehow. I tried RawTherapee, but didn’t really get on with it for some reason. I eventually tried darktable and spent some time learning (from youtube) about the scene referred workflow and so on, and got to really like it. But I do occasionally find it hard to get the look I want… hence my interest in these threads!
EDIT(again): I’m always hesitant to blame a tool (or module) because I’ve found again and again in the past that it’s usually my own expertise at fault
I find dt’s rather ‘hands-on’ approach much preferable though to the ‘LR’ cut-and-dried approach which seems inclined to encourage certain styles - to the point where images can seem a bit commercial and tired… (I hasten to add that I’ve never actually used Lightroom so shouldn’t comment!)
