1793091 - HDR images are rendered extremely dark

Status: NEW

(Core :: Graphics: Color Management, defect)

Description

[Greg]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:105.0) Gecko/20100101 Firefox/105.0

Steps to reproduce:

View any properly encoded HDR image, such as https://raw.githubusercontent.com/AOMediaCodec/av1-avif/master/testFiles/Netflix/avif/hdr_cosmos01000_cicp9-16-0_lossless.avif

Actual results:

The HDR image displays extremely dark. Firefox appears to tonemap the image to SDR (standard dynamic range). All of the content (including HDR over-range values) are rendered in the SDR range.

Expected results:

View the same page with Chrome on a supported HDR display (such as the M1 MacBook Pro). It will render as expected with proper brightness across the image.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::Layout: Images, Video, and HTML Frames' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[Kelsey Gilbert [:jgilbert]]

Yep, we're still working on HDR support.
I'm not sure if we want this in ImageLib or General or Color Management, I suppose it depends on how we want to address it:

• Tone-map (better) in ImageLib
• or render HDR properly

Comment 3

[Greg]

Here's a page showing HDR images for reference / testing (renders properly on Chrome to see intended appearance): https://gregbenzphotography.com/hdr/

Comment 4

[Greg]

(In reply to Kelsey Gilbert [:jgilbert] from comment #2)

Yep, we're still working on HDR support.
I'm not sure if we want this in ImageLib or General or Color Management, I suppose it depends on how we want to address it:

• Tone-map (better) in ImageLib
• or render HDR properly

It seems to me like both are needed. True HDR display is most desirable, but tonemapping the image for an SDR display is ideal to avoid clipping. A website could use a media query to serve both separate SDR and HDR versions of an image, but the media query is not properly supported as of FireFox 112. Here's a series of HDR-related tests: https://gregbenzphotography.com/hdr/#tests

Even if HDR rendering is done properly, tone mapping would still be ideal. For example, an HDR image mastered for 1000 nits would need tone mapping to display on a 600 nits HDR display without clipping.

Comment 5

[Greg]

A related consideration: support of HDR gain maps: https://helpx.adobe.com/camera-raw/using/gain-map.html

Comment 6

[Lucas Garron]

I also spent some while being confused until I realized Firefox is doing this. There are a few details making this particular tricky for web developers:

• The image in Firefox is truly is extremely dark. The image might still be vaguely recognizable, but it's very much on the side of "unusable" rather than "a little worse but okay". 😢
• The options for serving images based on HDR support are limited: CSS supports a media selector (which can also be used from JS), but srcset does not: https://github.com/w3c/csswg-drafts/issues/8767
• Even if it's possible to serve multiple versions of an image for a given site, this is an additional dimension of "Cartesian explosion" when generating a set of web-ready images.

Safari implement some HDR → SDR basic tone mapping that is more than reasonable, and that would be incredibly useful to have in Firefox. For simple websites, it means that I could serve a single HDR image in AVIF that is:

• Supported across Blink, Gecko, and WebKit.
• Significantly smaller than JPEG.
• Shows as HDR when possible and reasonable SDR otherwise.

Comment 7

[Lucas Garron]

Attachment: Screenshot 2024-08-14 at 00.05.35.heic

Here's a screenshot of https://garron.net/test/hdr/ demonstrating the issue for a real-world image where a "flame" is significantly brighter than the rest of the image.

Comment 8

[Lucas Garron]

Attachment: Screenshot demonstrating the issue at https://garron.net/test/hdr/

(JPEG replacement for the HEIC screenshot upload.)

Comment 9

[Mark Rejhon]

Author of TestUFO here, reporting FireFox HDR glitches:

I am getting a similar problem at https://beta.testufo.com/photo -- Select one of the HDR photos and it doesn't correctly convert them to HDR. Even though the CANVAS remains SDR on FireFox, it should still downconvert HDR to SDR more properly without going dark;

Also, FireFox needs to add support for HDR CANVAS -- https://beta.testufo.com/hdr

Comment 10

[Lucas Garron]

I've had another user report of this issue for a website I maintain.

If this can't be fixed soon, could I ask for at least a recommendation from Mozilla for what sites should do — particularly given that there is no simple workaround using <srcset>?

As web developers, we are regularly advised to avoid browser sniffing. But I don't see a workaround for browser sniffing here. 😕

Comment 11

[Greg]

Lucas- The workaround to this bug is to share HDR images encoded with a "gain map". This won't offer HDR on FireFox today, but it will render safely. And even if the FF bug were fixed, this is still the ideal solution because a gain map helps better adapt an image to any display, regardless of what level of HDR capability it has.

You can export gain maps from Adobe Lightroom (or Camera RAW): https://gregbenzphotography.com/hdr-photos/jpg-hdr-gain-maps-in-adobe-camera-raw/

You can also batch process (including creation of HDR images from standard ones) and fully control the SDR base image of the gain map using a plugin I've developed for Photoshop.
https://gregbenzphotography.com/hdr-photos/web-sharp-pro-v6-adds-significant-new-capabilities-for-sharing-hdr-photos/
Full control of the base SDR offers the highest image quality possible.
https://gregbenzphotography.com/hdr-photos/great-hdr-requires-a-great-sdr-in-the-gain-map/

Ultimately, it's still very important that FireFox add support for HDR photos (both with and without a gain map) if it is to remain relevant as demand for higher image quality grows. But at least using a gain map will ensure a good (standard) result in FireFox now.

Comment 12

[Lucas Garron]

@Greg: thanks for the info!

I guess that means the "JPEG (HDR — P3)" image at https://garron.net/test/hdr/ is probably using a gain map? I exported that from Lightroom (CC).

Unfortunately, using that JPEG instead of AVIF on a site would make the picture look significantly worse in Safari because the gain on the dark noise is too high. So I would still have to use browser sniffing to make sure the picture is rendered as well as possible in each browser. 😕

Unfortunately, I also can't justify paying for Photoshop just for this — do you know if there are any open-source tools that can handle gain map adjustments? Normally I'd look to ImageMagick, but this issue seems to have stalled: https://github.com/ImageMagick/ImageMagick/issues/6377

Comment 13

[Greg]

Unless you're running into banding at 8-bits (which is unlikely here), there is no reason you can't do this with a JPG gain map. Few standard images should show a benefit at 10-bits. The image you posted on your site is a valid gain map, but the base JPG is awful. It just wasn't encoded from a clean source - you can get results which exactly match your first image using Web Sharp Pro (the exact same image as the SDR base).

ImageMagick has already added support for gain maps (by including libultrahdr). You need to enable a compile option to enable it in the build, it isn't part of the default binary. See https://github.com/ImageMagick/ImageMagick/pull/7198.

This is getting off the main topic for the bug report, so I'd suggest following up over email: https://gregbenzphotography.com/contact/

Comment 14

[Jeff Muizelaar [:jrmuizel]]

Greg, does ImageMagick or some other open source tool supporting taking an HDR jpeg and converting it to a tonemapped SDR jpeg with a gain map?

Comment 15

[Greg]

Jeff- ImageMagick (when enabled via compile flag) includes libultrahdr, an open-source library with excellent support for HDR JPG gain maps (including both the ISO standard and Android XMP specs for gain maps). It can encode, decode, and transcode (crop, resize, compress, mirror). I believe libultra only decodes HDR to uncompressed RAW formats (P010, RGBA1010102). So ImageMagick is ideal to exporting to a wider range of formats. And it would be ideal if libvips would add support too.

To clarify, an HDR with a gain map is not "tone mapped" to SDR. In the case of a JPG gain map, the base image is always SDR, and therefore the SDR would simply be used without modification straight from the HDR JPG gain map (the metadata and auxiliary image would be ignored / unused).

An HDR JPG with a gain map would be displayed as any of the following:

• the fully decoded HDR (on displays supporting the max HDR capacity required in the gain map metadata),
• the unmodified base SDR JPG (on displays lacking HDR support),
• or interpolated between the two (on displays with limited HDR headroom). I'm not aware of any open-source libraries for shader code to do this, though they may exist. Google Chrome and derivative browsers all natively support HDR gain maps. MacOS / iOS / iPadOS now have native APIs for displaying ISO-encoded HDR JPG gain maps (this is really all that is needed, most encoding already uses ISO and the main benefit of XMP gain map support would be to offer HDR support for legacy images - nice, but not necessary).

I have many details and resources for developers related to gain maps at https://gregbenzphotography.com/hdr/#developers
Please let me know if you have further questions.

Comment 16

[Jeff Muizelaar [:jrmuizel]]

Sure. But let's say I have the image https://bug1942956.bmoattachments.org/attachment.cgi?id=9460887 which is a jpg with a PQ profile which displays poorly in Firefox. Is there a tool to convert that to JPG with a gain map so that it has better compatibility?

Comment 17

[Greg]

In that case, any automated approach would be no better than tone mapping. The only benefit of that approach would be to ensure that all browsers render the image consistently (rather than use their own proprietary tone mapping). However, the quality of the result is low and you're probably better off just keeping the file size small, I don't think the extra consistency matters much given the low quality of result.

A JPG without a gain map should be avoided for HDR. You have a valid result, but the 8-bit depth creates very high risk of banding (a gain map is two 8-bit images and therefore banding is not a concern). A better option for a simple HDR image without gain map would be AVIF. I would transcode this image from JPG to AVIF in that case. Browser support for the base AVIF format is ~95%, simple due to lag for some users to update to a modern browser. However, I don't believe FireFox supports HDR AVIF tone mapping yet (I've only ever seen very dark results).

You can manually tone map HDR to SDR with excellent results using Lightroom, Adobe Camera RAW, or my Web Sharp Pro plugin for Photoshop. Web Sharp Pro can help both create that base SDR and the gain map using workflow #2: https://gregbenzphotography.com/hdr-photos/web-sharp-pro-v6-adds-significant-new-capabilities-for-sharing-hdr-photos/. This would allow very high quality with about 30 seconds of work. But none of these options are open-source.

To be clear, the key formats for HDR include:

• HDR JPG with a gain map. This is 100% safe, supports HDR, and can adapt to any display. It is the best option today. This is ideally created by an artist for optimal results, but is also the native capture format for iPhone and Android now. But other automatic conversion of simple HDR to this format is probably not useful.
• Simple HDR AVIF (no gain map). This is already well supported in many places and offers small file sizes. As it lacks a gain map, the image quality will vary and may suffer significantly on displays with SDR or limited HDR. It has use on its own, but support is more critical as we can encoding AVIF gain maps with an HDR base image (this allows us to prioritize HDR results when compressing file size aggressively).
• AVIF with a gain map. This is an ideal format for very high quality with small file sizes. Support for encoding and decoding today is lacking, but this should be a very exciting format in about 12 months. Once ready, this should replace JPG with gain map for any new image creation.

Comment 18

[Greg]

Apple is adding support for a wide range of HDR photo formats with iOS, iPadOS, and MacOS v26 updates to WebKit / Safari. One side effect of this is that FireFox on iOS / iPad now does support HDR photos thanks to WebKit. (more info at https://gregbenzphotography.com/photography-reviews/apple-safari-now-supports-hdr-photography/)

This also means that FireFox is the only widely used browser which does not support HDR photos (either as HDR or at least tone mapped to SDR to avoid nearly black images). HDR is now the native image capture format iPhone and Android phones, as well as being well supported by creative software such as Lightroom and Photoshop, and websites like Instagram / Threads.

Can the dev team comment on the road map for support? Without HDR photo support, FireFox is going to start to feel obsolete to many users over time as the web increasingly uses more engaging images.

Comment 21

[Henri Sivonen (:hsivonen)]

(In reply to Greg from comment #17)

To be clear, the key formats for HDR include:

• HDR JPG with a gain map. This is 100% safe
  ...
• Simple HDR AVIF (no gain map).

A relevant data point is that with every vendor doing its own gain map format, JPEG + gain map exported from Lightroom Classic doesn't expand to HDR in Apple software when the Apple software does expand Apples own gain map format (I haven't tested iOS/macOS 26, yet), so PQ AVIF actually interops better between Adobe, Google, and Apple software than gain map JPEG for HDR.

It would be good for Firefox to at the very least provide Safari-competitive tone mapping to SDR for PQ HDR input sooner than later to avoid a situation where Web devs start UA sniffing not to serve PQ to Firefox, which would be bad at a future date when adding HDR rendering for PQ inputs.

Comment 22

[Timothy Nikkel (:tnikkel)]

Yes, we definitely want to produce reasonable SDR sooner rather than later.