[Webkit-unassigned] [Bug 270981] JPEG with HDR renders incorrectly

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Tue Mar 19 06:38:54 PDT 2024


--- Comment #4 from Greg <greg323464 at gmail.com> ---
Hi Alex- Glad to hear it's been so helpful!

I am unfamiliar with jpegli, though that sounds like a strong endorsement. Ultimately, 8 bits encodes less data than 10 and creates a higher risk of visible banding (quantization error) for a given encoding scheme/parameters. I assume what they likely are trying to do is to use dithering in an intelligent way such that it makes it hard to see banding at 8-bits (and probably selectively to avoid increasing file size by encoding noise where it isn't helpful). But that's just my uninformed guess.

Even if that is successful for an SDR JPG, I would have several concerns extrapolating that success to HDR:
(1) HDR encodes a much large range of luminance - which means each bit is stretched further and the risk of banding increases. You're well beyond the "Barten ramp" at this point and very prone to banding (12-bits required to avoid banding for some images).
(2) HDR is much more likely to use P3 and Rec 20202 gamuts, which adds to that risk.
(3) AVIF is now set to become a major file standard (now that all modern browsers support it) and offers much better file size efficiency. I believe it has the potential to quickly displace JPG once adoption starts to take off.

At this time, I see the HDR file format landscape as:
- ISO JPG gain map is the ideal way to share HDR on the web. It is 100% safe (falls back to SDR on both non-supporting displays and non-supporting browsers). This is the format encoded by Adobe software and Android devices, with Adobe using the spec more fully at this time with a 3-channel vs luminosity only gain map. [Note that Apple has a proprietary JPG gain map standard which is different.]
- Second best is HDR AVIF (no gain map), which is well supported by Chrome, Edge, Brave, and Opera. Safari will always tone map it due to a lack of HDR support, and Firefox fails to render properly (makes a very dark image). With a standard AVIF, tone mapping will be used if the display is SDR or a less-capable HDR display (Chrome-based browsers offer much better tone mapping that Safari at this time). Gain maps produce superior results as the SDR rendition has input from the creator. So I'm not generally a fan of simple HDR AVIF, though I use it on my test site to eliminate SDR fallback for testing/demonstration purposes.
- In the future, the best solution will likely be AVIF with a gain map. We don't have encoders yet, but Chrome already supports it under a dev flag and looks great with samples published by Adobe. With an AVIF gain map, we would get smaller files with the superior flexibility of a gain map to support both SDR and HDR displays. The quality will very likely be higher as well. And it would support transparency (though I haven't see any gain map support for that yet).

JPEG XL (JXL) is a great format, but probably going nowhere fast since Chrome pulled dev support. https://caniuse.com/jpegxl
HEIC is another great format, but with limited support: https://caniuse.com/heif

You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20240319/91657763/attachment.htm>

More information about the webkit-unassigned mailing list