Rec 2100 JPEG XL looks worse in Firefox than in Safari
Categories
(Core :: Graphics: ImageLib, defect)
Tracking
()
People
(Reporter: hsivonen, Unassigned)
References
(Blocks 2 open bugs)
Details
(Keywords: parity-safari)
Attachments
(1 file)
|
5.73 MB,
image/png
|
Details |
image.png
Steps to reproduce
- Load https://hsivonen.com/test/moz/hdr.html in Firefox with JPEG XL enabled and Safari with an SDR sRGB screen.
Actual results
The top left image (Rec. 2100 PQ with BT.2408 reference white JPEG XL) looks like the image on bottom right in Safari, but in Firefox the top left image looks desaturated (grayish).
Expected result
Expect the top left image to look as good in Firefox as it does in Safari.
Additional info
This is not about asking for HDR presentation but about doing good-looking tone mapping when the presentation isn't actually HDR, so that Web developers don't start withholding HDR images from browsers presenting Firefox's UA string.
|
Reporter | |
Updated•7 months ago
|
|
||
Comment 1•7 months ago
|
||
This is because for HLG and PQ transfer functions which go up to 1000 and 10000 nits we scale that maximum as SDR white. Thus a white pixel with brightness 1000 nits (10000 nits) gets mapped to (255,255,255), and this makes the whole image too dark. We should probably be taking 213 nits as our sdr white point when rendering these images as SDR.
There are several bugs filed on this already so I'll mark this as duplicate of bug 1793091.
|
|
||
Comment 2•7 months ago
|
||
(In reply to Timothy Nikkel (:tnikkel) from comment #1)
This is because for HLG and PQ transfer functions which go up to 1000 and 10000 nits we scale that maximum as SDR white. Thus a white pixel with brightness 1000 nits (10000 nits) gets mapped to (255,255,255), and this makes the whole image too dark. We should probably be taking 213 nits as our sdr white point when rendering these images as SDR.
There are several bugs filed on this already so I'll mark this as duplicate of bug 1793091.
*** This bug has been marked as a duplicate of bug 1793091 ***
Oops, I was too quick in reading this bug. Our jpeg xl support is preliminary right now and I don't think it supports color management yet. Bug 1986393 should resolve that issue. But then we will render too dark because of bug 1793091.
|
||
Comment 3•7 months ago
|
||
Not necessarily if we decide to land progressively. The patch there right now is too big.
|
|
||
Comment 4•7 months ago
|
||
Okay, we already have bug 1709814 that we can use for jpegxl + color profiles.
|
|
Reporter | |
Comment 5•7 months ago
|
||
Reopening, because the bug this was marked as a duplicate of talks about ICC profiles, and the image used for steps to reproduce does not use an ICC profile (uses CICP).
|
|
||
Comment 6•7 months ago
|
||
cicp is just a short way to represent a color profile. We don't need separate bugs for icc profiles and cicp profiles.
|
|
Reporter | |
Comment 7•2 months ago
•
|
||
Reopening, because this is not fixed despite the bug this was marked as a duplicate of getting fixed. It looks like CICP that isn't representable as SDR ICC still needs a separate fix.
|
||
Comment 8•2 months ago
|
||
The severity field is not set for this bug.
:tnikkel, could you have a look please?
For more information, please visit BugBot documentation.
|
|
||
Updated•2 months ago
|
|
|
||
Comment 9•2 months ago
|
||
FWIW, AVIF looks terrible there. Is there any relevant bug for that?
|
|
||
Comment 10•2 months ago
|
||
(Or can we close this and track the remaining bits in bug 1793091?)
|
|
||
Comment 11•2 months ago
|
||
Left in the latest nightly, right in the 2026-02-28 build. Bug 1986393 certainly made better colors although too dark as mentioned above.
|
|
Reporter | |
Comment 12•2 months ago
|
||
(In reply to Kagami Rosylight [:saschanaz] (they/them) from comment #10)
(Or can we close this and track the remaining bits in bug 1793091?)
There's already been one round of closing this due to another bug existing, and the other bug didn't fix this. Since HDR JPEG XL and HDR AVIF that are supposed to look the same look different, it seems reasonable to assume that at least for now they go through different enough code paths for it to be justified to keep this open for JPEG XL specifically.
|
|
||
Comment 13•2 months ago
|
||
(In reply to Timothy Nikkel (:tnikkel) from comment #2)
Oops, I was too quick in reading this bug. Our jpeg xl support is preliminary right now and I don't think it supports color management yet. Bug 1986393 should resolve that issue. But then we will render too dark because of bug 1793091.
But that's already mentioned and it's AVIF that looks bad, JXL looks better. Tracking that sounds out of scope of this bug?
|
|
||
Comment 14•12 days ago
|
||
I tested and this should be much improved after bug 2034984. I don't think we are all of the way there yet, but a big improvement so leaving this bug open to track remaining work.
|
|
Reporter | |
Comment 15•11 days ago
|
||
This is subjective, of course, but in my opinion PQ JXL now look better in Firefox than in Safari when viewing both on an SDR display. (Safari looks better on an HDR display, obviously, now that Safari can do HDR on an HDR display, which it couldn't when I filed this.) To me, Firefox's tone mapping looks like the photo was a regular SDR photo while Apple's tone mapping looks to me slightly darker than a photo from an SDR workflow would.
That is to say, from my perspective, this is now fixed and even better than I hoped. Thank you!
Description
•