Interestingly, if I add the Rec2020 TIFF exported from darktable to darktable, it looks good in the darkroom. Top: raw file; bottom: exported+imported TIFF
Edit: opened https://github.com/darktable-org/darktable/issues/12175
3 Likes
Its one of those images with some extreme light and so how much you keep or how you hand WB might strongly impact the end result but I didn’t really do an edit or adjust filmic at all I merely pointed out that the edit shown for filmic was a long way off. I just took the edit presented and used default filmic settings instead with no adjustments at all so its not an edit just meant to show this notion of calling an edit a filmic edit…@age pointed out that it was a strongly modified custom grey value, the filmic curve was a bit clipped at both ends and the latitude was zero…
Your point is of course true, settings matter and make comparisons difficult. However your example is a very dark edit that avoids the difficulty of the photo. The blacks look crushed or at least way to dark. (On my phone so can’t say for sure)
The question is does the tonemapping allow you to map the tones and achieve correct and pleasing results in a controlled way. I’m sure you can but it’s probably possible to make it more robust for users.
For sure and it wasn’t actually an attempt at an edit. I was merely trying to show that one example presented for filmic which appeared quite like a ghost to me was not indicative of what using filmic as a tonemapper for this image was likely to produce or even capable of…in the image I just changed the edit of @age to have filmic at its defaults. @age had not added any exposure preferring to try and tweak the image with the middle gray slider instead so for sure me just flipping it to defaults darkened the image but it wasn’t imo that far off the presented examples and a subsequent edit by @mikae1 was also quite acceptable.
Perhaps the question is not if you can but more so how hard is it to achieve consistent predictable and desirable results wrt another method. I think many believe this is where the sigmoid module has shown some promise??
Thats certainly how I see things. With the caveat that I wonder if the pinkish results are in any way correct or acceptable. It’s such a nasty effect that a good tool/algo should avoid it imho but perhaps I’m missing some situation where it’s desirable.
edit: just to add that the pinkish thing is particularly noticeable with portraits. We’ve seen quite a few threads with people struggling with it.
A real hdr image from a Sony hdr video demo (4000 nits peak brightness),I have extract a frame and done the conversion to rec2020 floating point :
Sony 4K HDR Demo - Camping in Nature.mp4.7z (10.8 MB)
the frame
My version (actually it is sigmoid )
hdrframe.pfi (16.1 KB)
RGB per channel tonemapping
Darktable no preserve chrominance
Darktable preserve chrominance
Sigmoid with film-like hue preserve (the same used in rawtherapee)
2 Likes
Export from darktable in Rec2020, reload it, export as sRGB without any changes - how does that look?
1 Like
t004100.tif.xmp (6.3 KB)
Exported from darktable as tiff 32bit, the conversione to srgb is done in gimp, in dt i’ve used the same settings as before
No preserve chrominance
Preserve chrominance
Good catch
Well, with the ‘original frame’, I still get horrible colours in darktable. But is that the file you processed (did you start with that JPG)? (Edit: I now see that you have uploaded your results.) Pinkish, does not convey the scorching heat, the glow.
I’ve started from the tiff in the zip, the jpeg named original is the tiff with way dark exposure compensation
I think it’s not that far from ‘Sigmoid with film-like hue preserve (the same used in rawtherapee)’, but has more detail in the reds.
I processed the TIF using the attached sidecar:
t004100_01.tif.xmp (5.9 KB)
1 Like
Tried the best I could do with filmic (with my laptop display). So, “filmic v6 max RGB” after exposure, “tone equalizer”, “color calibration” and “color balance rgb”. I even use some “shadows and highlights” 
.
t004100.tif.xmp (5.1 KB)
On my PC …the lightable view is fine but not the darktable view…so this is without any exporting just toggling back and forth…I will confirm…for the flower…
No matter what settings I use for the lightable thumbs including use the raw …I get this for the darktable preview…
and this for the lightable one…
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.
t004100.tif.xmp (3.8 KB)
@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.
1 Like
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.
2 Likes
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.
t004100.tif.xmp (18.0 KB)
2 Likes
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.
4 Likes
Hi Bob, thanks! You’ve clarified what I was getting at a lot… it’s an interesting subject!
1 Like
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…