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)
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.
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.
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.
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:
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)
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.
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.
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.
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.
For some odd reason, this is the case with all PC and laptop monitors. It’s basically an “anti-sweet-spot”.
HDR TVs can provide excellent picture quality at EXTREMELY affordable price per square inch. Especially stuff like an LG Cn (where n is either the last digit of the year or X, not sure what happens when they roll around to previously used years…), where a 42" C3 (smallest they make) will outperform most monitors in the 27-32 inch range at a much lower price.
Similarly lots of OLED in phones, hell Samsung has been doing AMOLED for well over a decade in the vast majority of their phones. Of course back then, they were AMOLED with zero color management so were kinda notorious for garish oversaturated colors (Samsung marketed this as a feature…)
I think you may have misunderstood what I mean. All of what you say here is correct. I’m from the ICC world, and most colorspace ICC profiles are matrix profile, and can only do gamut clipping in theory, some CMM cheat a little bit. Here is a perfect example of what I mean, on the left is perceptual gamut mapping, and on the right, plain gamut clipping. The flower photos I take, looks almost as bad the right photo when converted from the camera colorspace to Adobe RGB ICC profile of my monitor. I have created ICC profiles versions of sRGB, Adobe RGB, ProPhoto, and soon Rec2020 made with 3d LUT, which will allow gamut mapping, contrary to matrix profile. I can also create ICC device link profile that do an even better job, and can be translated into LUT.
I’m trying to use my DSLR stills, which in my case mean a 14 bits depth and 14 stops, either alone, or merge into EXR, without tone mapping, to create HDR slideshows that I can upload to YouTube.
If your images or even your video clips colors fit with minimal or without clipping into say Rec709 (sRGB), you’ll never see that much clipping, if any, of course. Trust me, my shots are almost always way out of the gamut of Rec709 and even out the Rec2020 gamut quite often.
I’ll most likely do the following, first I’ll do a perceptual gamut mapping from ProPhoto RGB to DCI-P3 or Display-P3 and then to linear Rec2020 or to HLG Rec2020. That way, for any display capable of 100% P3, it will never require clipping. Of course, on an SDR, Rec709 display, it’s another story, but it seems we can provide a LUT for YouTube to use in rendering Rec709, I’ll make sure there is no clipping for SDR viewing as well.
I really want to view these images but it seems I don’t have a single HDR display in my house. I hoped my Pixel 6 supported it, but I think only the Pixel 6 Pro does.
