Processing RAWs for HDR displays in Darktable

Hello all.

I, too, have been experimenting with HDR processing, and using commercial tools (Adobe, Pixelmator) have been mostly disappointed with the results. Using a MacBook Pro HDR display, most photos have had really unpleasant highlights, especially skin and hair. Only certain photos improved at all, but I still wasn’t happy with the results, as my tastes lend toward the natural, film-like look. Which is why I also love Darktable and the results I’m getting from it in SDR.

Having almost ruled HDR out for the time being, I yesterday experimented further with Darktable and Apple’s own Photos app. And stumbled upon what I now consider the holy grail of solutions, at least for those in the Apple ecosystem.

Developing within Darktable, (default scene-referred with Sigmoid), being careful not to make the image too bright (leaving a bit of space to the right of the histogram is preferable) and simply exporting as a 10 bit JPEG XL with HLG Rec.2020 profile, Apple’s internal handling of the file does all the heavy lifting inside the Photos app (which recognizes the images as HDR).

The photos look every bit as natural and pleasant as I’m used to from Darktable, only automagically™ expanded to fully utilize the capabilities of the display. In a word, they look stunning. None of the over-processed, metallic highlights from Adobe, just bright and beautiful lights. Colors pop without looking oversaturated (I find adding a bit more saturation than in SDR is preferable to offset the added brightness a bit) and blacks are just as inky as expected.

Apple’s tonemapping does a great job for SDR display, too. Images retain their “Darktable” character, even if the saturation becomes a little wonky if you add too much of it for HDR displays. Like always, there’s a trade-off.

I have also verified that this process does exactly the same wonders for scanned film. A 16 bit file from my Nikon 5000 ED using VueScan, basically untouched in Darktable, now looks more vivid than ever. It’s almost uncanny. All of the image quality of film comes through better than ever, as if what I’m looking at on the display is actually the slide lit from behind (only with much deeper shadows and blacks).

Oh, and the files end up unbelievably small at 80%. The future is officially here.

I have yet to experiment with how this works on non-Apple hardware, such as a TV. It’s still early days, but the future is undoubtedly HDR. Darktable will get there, too, UI-wise. And while it’s a moving target and a mess with competing standards, no doubt things will settle down in a few years.

But in my mind, I’m there. This is the way forward for me. I will still make adjustments for printing and SDR output. But through basically no extra work, I get the best reproduction quality I’ve ever seen, using the tool I prefer and the hardware I currently have.

Those of you with the same hardware (or similar), I encourage you to give the magic of Darktable plus HLG a go.

3 Likes

Thanks for sharing.

In my early experiments I found that pulling -1.36 EV was “theoretically ideal” for HLG export (i.e. preserves same mid-gray as when mastering for SDR).

Just out of curiosity - does 10-bit HLG AVIF have the same level of support in your environment?

1 Like

Thanks for sharing @mosnee! My experience with macOS and JPEG XL is also consistent with what you wrote, but you managed to put it into words much better than I could.

One question to @kmilos, just out of curiosity: how did you come up with the -1.36 EV value for HLG?

I am not very familiar with HLG, so I almost exclusively used the PQ Rec2020 RGB profile so far, with a final exposure correction of log2(203 nits /10000 nits) ≈ -5.622 EV as the last step in the processing pipeline, in order to map the SDR white to 203 nits (which is the value used by the Adobe viewer).

However, Apple softwares have lots of performance issues with PQ (reported, but still not fixed), and so far I didn’t manage to preserve the middle gray and the contrast when exporting to HLG. So I still don’t have an export format that works out-of-the-box with “mainstream” viewers like macOS/iPadOS Photos.

EDIT: I just tested again with HLG and -1.36 EV, and I still get crushed blacks (darker than on the SDR or PQ images), while the specular highlights are brighter than on the PQ image. So the contrast is still unnaturally strong when I export to HLG. I’ll try to find a good test image to show the issue (I promised it long ago but then forgot about it…)

Ok, here is a picture that I think shows the problem quite clearly.

First, the SDR JPEG (sRGB), just so everyone can get an idea of what the image looks like:

The scene itself has a high dynamic range, and I have kept the contrast linear (just applied some corrective modules). The sunshades, red tableclothes and part of the roofs are clipped in the SDR version.

The same picture in JXL format but still with sRGB (SDR) profile: SDR.jxl (1.6 MB)

And now various HDR versions in JXL format, that only vary by their profile and the amount of exposure compensation that is applied at the end of the pipeline:

I viewed all these images on the iPad (Photos app) and on the Mac, using both Photos and Adobe’s experimental viewer (“Gain Map Demo App”) on the latter. I kept the default “Apple XDR Display (P3-1600 nits)” profile on the Mac (this is important in order to get the right SDR brightness).

When using these apps and settings, the non-clipped part of the image is consistent between the SDR and PQ images, so I think I got the right exposure compensation for this profile. However, the blacks seem crushed and the contrast off in both HLG versions, regardless of the viewer.

So it seems to me that something is still wrong with the HLG export. But I have no idea if this is due to a bug in Darktable or to a fundamental limitation of HLG. Any insights would be highly appreciated!

Finally, the raw and sidecar files, in case you want to try to reproduce my results:
_DSC6846.NEF (30.8 MB)
_DSC6846.NEF.xmp (7.8 KB) (matches the PQ version)

Been a while, but basically a factor needed to align the 0.5 points on these two curves.

1 Like

Very interesting! I hadn’t seen that thread, nor much else (from a cursory search) that indicated HLG had much traction.

HLG is still new to me, and I fully intend to experiment further before settling on a Standard Operating Procedure for my own uses. Dialing back exposure does seem to be backed by theory, indeed.

I also wonder, but haven’t yet looked into, to what extent Apple has done their usual thing of taking a standard and adjusting it as they see fit. In other words, what’s theoretically ideal may not always yield the best results on Apple hardware using Apple software, simply because they “think different”.

As much as -1.36 EV certainly takes some of the “pop” out, for better and worse. SDR compatibility takes a practical hit in the sense that the SDR representation appears much darker compared to regular SDR material in the Photos library. As long as there are SDR screens involved, I’d ideally like a version that works reasonably well in both SDR and HDR.

And yes, AVIF works equally well.

Thank you!

You’ve obviously gone much further than I, and I fear you may be right that a completely dependable, fleshed out solution will be a while yet. Again, I may land on a compromise that works for me, but as you can tell, I’m very excited having anything that even gets close. The Photos app is just the top layer for convenient access, but being able to stay in Darktable and still reap most of the benefits of HDR reproduction is a revelation to me. One can always change the settings and do a new export in bulk somewhere down the line.

PQ seems the better choice for professional work that warrants something approaching absolute control, but as you noted, it doesn’t appear to work as well for now. It seems likely the relative nature of HLG is a better fit for Apple, given that they still do their own thing on an OS level, across different hardware.

By the way, does anyone get why the Adobe stuff looks so different (to me: awful) out of the box? I’m talking a basic import in Lightroom, HDR enabled and some auto adjustments. The overly bright and overly saturated highlights looked like over-processed photos from a smartphone. The gain map thing seems clever, but I haven’t yet seen results I like from it.

1 Like

<

Thanks for taking the time. I’m am seeing what you’re seeing, both in yours and in my own output of your file. I probably haven’t had such extreme contrast in any of my own test material, it’s a very good test to have done.

PNG have just added the metadata to store HDR images.

1 Like

FYI, darktable supports this as well.

Biggest issue with this is colorspace/gamut - more important than dynamic range in most modern HDR displays is that they also tend to support gamuts wider than sRGB. Hence rec. 2020.

There are two problems with HLG’s “SDR fallback” mechanisms:

  1. A rec. 2020 image is going to be washed out, or have gamut clipping, if fed to a Rec. 709 display. (Sadly, the same “SDR fallback” mechanisms also will usually lead to Rec. 2020 content being mis-displayed as if it were Rec. 709 content, e.g. washed out/desaturated)
  2. The HLG transfer function lacks the “foot” that most S-curves have. Of course, if you add a “foot” for blacks in your content, HLG now appears on an SDR display like it has an S-curve, since the HLG transfer function handles the “shoulder” in SDR fallback mode

To be fair, the report from ITU and the published user guides say that HLG is backwards compatible with BT.2020 SDR displays and that it’s designed to have a neutral look on top of which artistic controls can be added.

For example, if you look at the recent Super Bowl, there was definitely an added artistic look.

An artistic look is definitely something common to nearly all HDR productions I’ve seen.

People are SO used to an S-curve that feeding HLG without an additional S-curve looks VERY different. See Kamacira Japan’s various Sony HLG footage at https://www.youtube.com/@Kamacira/videos as an example

Most cinematic/TV HDR productions seem to only just push a little tiny bit outside of the SDR range, vs. Kamacira’s content which has no curve applied other than the basic HLG transfer function. No curve at all looks like garbage on an SDR display, but WOW it’s impressive on a good HDR display.

2 Likes

Not directly related to the recent discussions, but some time ago there was a mention of gain maps, that allow to simultaneously support both SDR and HDR displays.

And today I finally saw them for the first time in the “wild”, in this blog post about ML rigs (external link):

The pictures do indeed “pop” quite a bit (even though it’s just GPUs with RGB lightning, so not really fine art).

You need some Chrome-based browser (and a HDR monitor) to see the full dynamic range, but thanks to the gain map, backward compatibility with unsupported browsers (e.g. Firefox, Safari) is there and the pictures don’t look clipped.

This is actually where it would seem some players are heading: AVIF (and JPEG XL?) implemented support for gain maps (and are used by Adobe in their products I think), and Google is pushing it as a JPEG add-on via their “Ultra HDR” format proposal.

I was reading this post last week. Looking at it on the cellphone (HDR) vs my monitor is very different. I guess it is time to buy an HDR monitor instead of a GFX camera.

https://gregbenzphotography.com/hdr/

1 Like

Both JXL and AVIF definitely support it (I remember trying both using Adobe’s demo app). Not sure what it would take to use this feature in Darktable, though. I’ll try to experiment when I have time. The easiest way might be to “blend” the SDR and HDR version of an image using some utility.

Thanks for the link! The post looks very interesting.

Lightroom recently got proper support for HDR processing. UI-wise there are some good ideas worth stealing:

As I mentioned further up:

I do wonder what Google’s play is exactly. If this is intended to be the JPEG Gain Map implementation done in cooperation with Adobe, or if they just seized the opportunity before anyone else. While there are a number of articles about UltraHDR out there, they are typically not much more than fancy PR pieces, so hard to know for certain. And I have even seen it described as proprietary, which it is clearly not.

Google’s reference library indeed works by ingesting both an SDR and HDR version of the image, deriving the gain map from the difference.

1 Like

Great to see that the library is open-source! I’ll try to build it and play with it.

However, it is not fully clear to me if it supports anything else than JPEG as input or output. I saw some mention of TIFF in the issues, but I would have loved to see AVIF or JXL too.

Interesting thread. Following a tea and laptop accident in 2021 I bought a macbook with XDR display (P3 gamut and 1600 nit max) so have tracked the HDR evolution with interest.

It seems to me that the various approaches reflect the nature of the businesses involved.

Dolby has historically provided a new high end standards e.g. PQ 10,000 nits max.

Adobe with a huge base of legacy users/images has pursued a bridging approach jpg + GainMap.

I expect Google has their own business interests in minimizing image transport/retention and the number of formats to efficiently support.

The hardware vendors will push out new display hardware as they can differentiate it, produce it, and sell it. Apple with XDR. VESA (PC trade group) has a multiple tiers of max luminance (400 500 600 1000 1400) https://displayhdr.org

My cursory look at OLED is that while there is wide adoption for the larger area lower pixel-per-inch televisions, and smaller area higher pixel-per-inch phones/tablets it will still be a few years before they will be commonplace for computer displays medium area medium pixel-per-inch.

I expect there will need to be some bridging solution given the large based of displays and images, and maybe a separate final next generation standard based on technology that may not yet exist. So, it seems to me a big part of a solution is how the navigate the next decade while all this is sorted out. Specifically, how to produce images that can be rendered optimally for a target but sufficiently well elsewhere.