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

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Mon Mar 18 23:32:03 PDT 2024


https://bugs.webkit.org/show_bug.cgi?id=270981

--- Comment #3 from Alex Gunnarson <alexandergunnarson at gmail.com> ---
Thanks for your comment, Greg! Your site has been instrumental in helping our team make sense of the HDR landscape as we build out a new feature for our web app (shopdeft.com).

Interesting that you note some potential pitfalls around the format of the uploaded image (jpegli). The (co-)author of the JPEG-XL format, Jyrki Alakuijala, said that "Overall I believe jpegli is in its own class of jpeg codecs ... [it] allow[s] 10+ bits of dynamics for '8 bit' jpegs. I believe Jpegli and jpeg xl lead in the highest quality category (5 BPP)" (https://news.ycombinator.com/item?id=36429397). He also notes that "... we can ... jam more bits into the 8-bit formalism than the original authors thought would be possible and extend[] it into 10+ bits while being backward compatible. This can unblock traditional JPEG for high quality HDR uses, too" (https://www.linkedin.com/posts/jyrkialakuijala_jpegli-news-since-its-introduction-in-1992-activity-7158133901616390144-uHkZ).

I'm not yet well-versed in the world of HDR, so help me understand. I read Jyrki's statements as saying that jpegli (the format of the image featured in this bug report) is a high-quality HDR-capable format designed for backwards compatibility. When you say that "That format is insufficient to avoid banding with HDR", and "I would not necessarily expect support", what am I missing?

For what it's worth, viewing the jpegli in Safari 16 on my Mac M1 looks identical to: 
- The jpegli version as viewed in Chrome 122 on my Mac M1
- The JPEG XL version (from which the jpegli derives) as viewed in Safari 17 on my iPhone
- The AVIF version as viewed in Chrome 122 on my Mac M1
- Etc.

and it is distinct from the lossless WebP version as viewed in Chrome 122 on my Mac M1 (in the WebP as I've transcoded it, the HDR data appears to have been truncated to SDR, with the pure white "maxing out"; though it's not washed out, turned to near-black, etc.).

>From this I can observe that the jpegli is indeed displaying correctly in HDR in a number of non-Safari-17 browsers, with no discernible (to me) difference in quality.

It appears there are a number of caveats to displaying HDR content, even in modern browsers. Correct me if I'm wrong, Greg, but seems like the best way to display HDR content at this time (assuming an HDR display, so no tone mapping required) is, in decreasing order of preference:
- JPEG XL (Safari 17; prior to this release, JPEG XL didn't appear to have HDR support on Safari)
- AVIF (non-Safari browsers; IIRC Safari 16 had spotty support)
- Single-frame HEVC (Safari < 17)
- JPEG gain maps (I believe jpegli falls into this category?)

-- 
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/b31795df/attachment.htm>


More information about the webkit-unassigned mailing list