HDR image export which can be viewed in a browser?

[gregbenz]

Is there a way to use ImageMagick to convert a 32-bit (HDR) TIF into any image format which can still be viewed as an HDR image on any browser?

I've been able to use ImageMagick to convert to JXL, but it shows as clipped (no HDR content) in FireFox and Chrome. When I reverse convert the JXL back to TIF, I do see the HDR content, so it looks to me like JXL image support in these browsers does not include HDR image content.

I believe AVIF can support HDR content. However, when I try to convert using ImageMagic (command line: magick "my source file.tif" - depth 32 "my new file.avif"), the result is a 16-bit channel depth (as reported using: magick identify -verbose). When I reverse it back to a 32-bit TIF, the result is clearly clipped, so I'm pretty confident my AVIF conversion failed. Is an HDR-compatible export from ImageMagick not possible?

Running "magick -version" reports "ImageMagick 7.1.0-45 Q16HDRI...", which I believe should support HDR conversions.

[snibgo]

Do you have an HDR monitor? If not, then some software (or hardware, I suppose) will need to convert the HDR image to SDR to display the full tonal range on your monitor.

JXL can record HDR values. For example, I can do a round-trip on Windows:

f:\web\im>%IMG7%magick -size 10x1 gradient: -evaluate Multiply 10 -depth 32 x.jxl

f:\web\im>%IMG7%magick x.jxl txt:
# ImageMagick pixel enumeration: 10,1,0,65535,srgb
0,0: (176585,176585,176585)  #FFFFFFFFFFFF  srgb(269.451%,269.451%,269.451%)
1,0: (167933,167933,167933)  #FFFFFFFFFFFF  srgb(256.249%,256.25%,256.25%)
2,0: (158515,158515,158515)  #FFFFFFFFFFFF  srgb(241.878%,241.878%,241.878%)
3,0: (148503,148503,148503)  #FFFFFFFFFFFF  srgb(226.601%,226.601%,226.601%)
4,0: (137499,137499,137499)  #FFFFFFFFFFFF  srgb(209.81%,209.81%,209.81%)
5,0: (124623,124623,124623)  #FFFFFFFFFFFF  srgb(190.163%,190.163%,190.163%)
6,0: (110177,110177,110177)  #FFFFFFFFFFFF  srgb(168.119%,168.119%,168.119%)
7,0: (92733,92733,92733)  #FFFFFFFFFFFF  srgb(141.501%,141.501%,141.501%)
8,0: (68819,68819,68819)  #FFFFFFFFFFFF  srgb(105.011%,105.011%,105.011%)
9,0: (125,125,125)  #007D007D007D  srgb(0.191198%,0.191198%,0.191198%)

Another option that is sometimes required for writing HDRI is -define quantum:format=floating-point.

I don't know about AVIF. AVIF doesn't work for me (IM v7.1.0-42 on Windows 8.1).

f:\web\im>%IMG7%magick -size 10x1 gradient:  x.avif

f:\web\im>%IMG7%magick x.avif txt:
magick: Invalid input: Invalid clean-aperture specification (2.120) `x.avif' @ error/heic.c/IsHEIFSuccess/135.

[gregbenz]

Yes, an Apple M1 Macbook Pro (XDR display). I can very clearly see as many as 5 stops above SDR white (typically 3.5 stops under my working settings). My source image in Photoshop (using the tech preview for HDR display) looks awesome and very clearly is HDR (as compared to another non-HDR monitor I've used for testing). The same HDR image after conversion to JXL looks like a 16-bit image when viewed in the browser, it is definitely not displaying as HDR in Chrome or FireFox. I can see HDR videos on these same browsers, so they display HDR for at least YouTube.

When I convert my JXL back to TIF, I am seeing an HDR image again. I suspect the JXL implementation in these browsers simply does not support HDR at this time, but perhaps they do with other file formats?

So as best I can tell, I've created a valid JXL HDR image but neither FireFox nor Chrome is displaying JXL as HDR. I don't know another way to display and confirm the JXL on this computer, as Photoshop does not support that file format.

[snibgo]

As of October 2021, Firefox apparently didn't support HDR. See https://support.mozilla.org/en-US/questions/1321197

AVIF on Chrome seems more promising. See https://stackoverflow.com/questions/51936897/how-does-one-create-and-display-hdr-images-in-web-browsers

[gregbenz]

@snibgo Any idea how to convert a 32-bit HDR TIF into some kind of valid HDR AVIF file?

When I try the following, the output is reported as 16-bit and if I reverse convert it to 32-bit TIF, it has lost all HDR values (everything is clipped to SDR white):
magick "sourceFile.tif" -depth 32 -define quantum:format=floating-point "newFile.avif"

I'm not sure if I'm failing to use the right options or if ImageMagick simply won't create a 32-bit (or HDR compatible) AVIF

[snibgo]

Sorry, I don't use AVIF for anything, and can't advise.

[dlemstra]

We currently only support writing 8, 10 or 12 bit heic and avif images.

[gregbenz]

@dlemstra My source is 32-bits from Photoshop for HDR, but my understanding was that the encoding for these formats is different. I had thought that 10 and 12-bit in that context would support HDR, is that not correct?

[dlemstra]

10 and 12 are written as an unsigned short and that doesn't support out of bound values.

[gregbenz]

@dlemstra Thank you for the confirmation.

Are you aware of any other tools which do currently support converting a 32-bit TIF to an HDR-compatible AVIF file?
(ideally converted in a way which works with Google Chrome, which I understand should support HDR with AVIF - my ultimate goal here is to be able to show HDR still photographs on the web).

[sturmen]

@gregbenz check out my complete end-to-end workflow for an HDR image in Chrome: https://sturmen.github.io/posts/hdr-jpeg-xl-2022/

[gregbenz]

@sturmen Thank you for sharing that info. Great to see the discussion thread with Adobe, Google, etc too.

[gregbenz]

@sturmen When changing brightness of the screen in MacOS, do you ever see discrete jumps in HDR values? It happens quickly and is not 100% reproducible for me, but I see this a fair bit when dimming and viewing Chrome. For example, when viewing your cat image I darkened the screen, and then a moment later the blue background jumped to a much brighter value. I can't recall seeing the same issue in Photoshop. HDR adjustments from the OS are very obvious and slow. I'm not sure if this is an OS glitch or a Chrome glitch that causes a very rapid jump.

[sturmen]

Your guess is as good as mine! I would imagine such behavior would be implemented at the OS level in order to protect the hardware. I know OLED TVs have an Auto Brightness Limiter (ABL) that does pretty much the same thing.

[gregbenz]

It gets even stranger. On your page, scroll down away from the HDR cat, change brightness, and then quickly scroll back up to the cat. Most of the time, I find the image is completely missing, along with some of the text above and below. The faster I scroll, the more text I seem to lose. It then shows up again after a little while. That feels more specifically like a Chrome bug, but who knows how they're rendering the text.

[gregbenz]

FYI that Adobe now supports HDR exports as JXL files through Adobe Camera RAW (ACR) v15, shown in this video: https://gregbenzphotography.com/photography-tips/acr-15-adds-high-dynamic-range-output/

It only works when using ACR to open a file, but you can do that with a flattened 32-bit TIF to work from anything (as long as PS prefs specify using ACR to open any supported TIF).

[harshxjoy]

Sorry I didn't use this please tell me about this I want to experience.

[gregbenz]

Sorry I didn't use this please tell me about this I want to experience.

See https://gregbenzphotography.com/hdr/

[SPAHI4]

Any progress on that? it seems like AVIF is the way to do HDR images because Chrome disabled JPEGXL support.
I still haven't managed to find any resize tool for hdr images

[gregbenz]

Agree that JXL is not a priority because loss of Chrome support makes the format of very limited use.

There are three formats which I believe are critical to support for HDR:

1. standard HDR AVIF (this issue).
2. gain map JPG, aka Ultra HDR JPG (covered by this separate issue: Add support for HDR gain maps #6377 (comment)).
3. gain map AVIF (also address in that other issue, though it should probably be broken out as AVIF and JPG have differences in implementation of the details)

The gain map options are ultimately most attractive, as this allows a single image to look its best whether viewed on an SDR or HDR screen. It contains a base rendering (SDR or HDR is ok), an auxiliary / secondary image (which provides the data to render the other version of the image), and some metadata (also required to derive the other image).

This issue (#1) is a prerequisite to support #3 (as the base image in an AVIF gain map can be an HDR AVIF).

[gregbenz]

Closing out this thread as there are now several formats which support HDR in multiple browsers. Most browsers now support both HDR JPG gain maps as well as standard HDR AVIF (Chrome has support for AVIF gain maps, and so does Brave under a developer flag: brave://flags/#avif-gainmap-hdr-images). Gain maps are clearly the way to go, as they offer superior image rendering on SDR (non-HDR) displays.
Info on gain maps: https://gregbenzphotography.com/hdr-images/jpg-hdr-gain-maps-in-adobe-camera-raw/

JPG gain maps are clearly the best option at this time as they offer true HDR display, superior SDR display, and full backwards compatibility (browsers which don't understand gain maps fall back safely to the SDR version of the image).

Unfortunately, ImageMagick does not support gain maps. A feature request has been submitted here: #6377

[arpu]

@gregbenz gainmaps will come to threejs mrdoob/three.js#27183

[gregbenz]

@arpu Interesting. Not familiar with that libarary (or much of 3D). What's the use case here, to load entire 3D environments (textures, etc) in a browser which adapt to SDR or HDR?

[arpu]

gainmaps can be used for enviroment maps for the 3d models ( lightning)

[Entropy512]

As far as a lack of HDR photos online - that's partly due to the lack of standardization. Apple has their approach (HEIF), Google has theirs (gainmaps), JXL had a lot of potential but Google killed it as anything but an intermediary storage format, without browser support it's not a useful delivery format. Support Google's method and Apple users won't see your images, support Apple's method and anything Google won't support it. Plus all of the other HDR-capable formats nearly no one supports, like CTA-2072 (supported only by Panasonic) - https://shop.cta.tech/products/hdr-still-photo-interface

Right now the only reliable way to get an HDR photo to display on a wide variety of systems is to encode it as an H.265 video with PQ transfer curve and HDR10 metadata, or HLG transfer curve with the appropriate alternate transfer curve metadata. :(

[gregbenz]

@Entropy512 That'll all get sorted out soon enough with projects like libultrahdr, which is based on the ISO standard for gain maps (Apple also uses gain maps, but they pre-date the ISO standard and are therefore different - though they can be transcoded to the ISO standard). There are effectively three different gain map implementations at the moment, but they are very similar (and the Adobe / Google standard are the same, it's just that the Google implementation is only using single channel gain maps at the moment, whereas Adobe is using the full RGB capability in the spec - both are correct and there is a tradeoff there between quality and file size, so both will likely be used long term).