Processing RAWs for HDR displays in Darktable

Software darktable
,
59

Though I agree with you, and we won’t beat a large (wide) screen for the immersion feeling it provides with a smartphone any time soon. But the reality is, the market for “HDR TV” is shrinking like snow in the sun, so I don’t want to target such displays.

My setup for viewing my photos, is essentially wide gamut SDR, and when I want people to see my work as I created it, my photos end up being viewed, 99%+ of the time, as sRGB’s on SDR monitors. I find this unacceptable, and I’m looking at my options so that at minimum my photos would be seen as wide gamut images. Ideally, that would be on a Rec2020 display, which would still squash my color by the way. But who as the kind of money needed for such capable device.

~Yves

60

Then you are out of luck: given how difficult color science is in here, the average consumer is probably not going to care about wide gamut for quite a while. So won’t spend the money on such screens.

Also, large screen \neq HDR \neq wide gamut…

1 Like
61

Yes, of course, I’m hoping to use HDR short videos as a workaround. Since more and more HDR capable device also have a wider gamut than regular displays.

As a second and non-negligible benefit, I’ll be able to flex my creativity without anyone complaining my photo is to this or to that, can you show us the RAW? I don’t think people will complain about my compositing and creative color editing now, it will change the perspective. I’m thinking as well to create short animated video, kind of fantasy world. And I won’t make much effort to make SDR versions either.

62

So what? There’s not a single display system that’s capable of exceeding the Rec. 2020 gamut currently and won’t be for a long time if ever. If clipping to Rec. 2020 for final export is unacceptable for you, just give up on any image processing. There’s not a single display standard in existence or in development that has a gamut wider than Rec. 2020.

Given how the Rec. 2020 gamut is defined with primaries on the spectral locus which is as wide a gamut as you can physically achieve with three primary colors, it’ll never happen for a display to exceed this gamut unless someone does something like bring back a variant of Sharp’s Quattron except with a fourth cyan emitter instead of the Quattron’s yellow. The chances of this actually happening are pretty unlikely.

By default, yes. Most TVs default to really awful color and motion processing settings, often called something like “vivid”, which do things like just throw sRGB content at a Rec. 2020 display without actually bothering to do a matrix transform and accept the unnatural increase in saturation. However even cheaper TVs like Vizio have “Calibrated” settings that have fairly good color accuracy. Of course if you want to go all out, LG’s C-series TVs have earned a reputation for being your best option for HDR mastering if you can’t afford a full-blown mastering display (which most people can’t since they’re tens of thousands of dollars…) because their “Calibrated” mode has been determined to be very accurate from the factory. LG C3 OLED Review (OLED42C3PUA, OLED48C3PUA, OLED55C3PUA, OLED65C3PUA, OLED77C3PUA, OLED83C3PUA) - RTINGS.com

2 Likes
63

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
64

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
65

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…)

66

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:

SDR
SDR3032×2020 1.55 MB

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)

67

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

1 Like
68

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.

69

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
70

<

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.

71

PNG have just added the metadata to store HDR images.

1 Like
72

FYI, darktable supports this as well.

74

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
75

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.

76

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
77

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.

78

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.

79

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