Given the Safari team has been the major driving force behind support for wide gamut in web browsers (for the very obvious reason that all Apple devices ship with wide-gamut displays), I am extremely suspicious of the author’s assertion that Safari is ignoring an embedded ICC profile while Chrome and Firefox are doing the right thing.<p>I think it’s far more likely that whatever chain of open-source image modification tools the author is using has written out pixel values in a different colorspace than the one named in the embedded ICC profile.<p>But if the author is absolutely confident in their analysis, they are welcome to file a bug report: <a href="https://bugs.webkit.org/" rel="nofollow">https://bugs.webkit.org/</a>
I seem to recall Safari doing the right thing for JPEGs when I was experimenting with publishing red-cyan stereograms [1] where an sRGB (255,0,0) becomes something like (187, 16, 17) on a high gamut display because the sRGB is less saturated than the P3 red. It looks right for a normal photo but for the anaglyph that little bit of blue and green leaks through and makes ghosts. Emedding a P3 profile in JPEG solves the problem. You run into the same problem with print and I ended up addressing those by applying the color profile to the R and L images, doing the anaglyph blend, then attaching the native color profile of the printer -- it probably isn't quite right but the colors are always going to be off for an anaglyph anyway and if I go back to that project I'll design a color grade that pushes the scene away from pure-red and pure-cyan-spectrum colors.<p>What gets me is that the image he's publishing is not really a PNG kind of image.<p>[1] <a href="https://cybereality.com/rendepth-red-cyan-anaglyph-filter-optimized-for-stereoscopic-3d-on-lcd-monitors/" rel="nofollow">https://cybereality.com/rendepth-red-cyan-anaglyph-filter-op...</a> is a write up that didn't go as deep as my research
This might be true but I would hope the web standard is defined enough that browsers can also fail in the same way. Regardless of which browser is the most "correct" here
You can try. I'm on Safari Version 18.6 (20621.3.11.11.3) [Seqouia 15.6.1] on my Mac, unsure of the version in my iPhone and iPad, but all of them ignore the ICC profile.
Apple essentially invented color matching on personal computers back in the classic Mac OS days; it's hard to believe after all this time, they're not dealing with color correctly.<p>The WebKit blog from 2016:<p><i>WebKit color-matches all images on both iOS and macOS. This means that if the image has a color profile, we will make sure the colors in the image are accurately represented on the display, whether it is normal or wide gamut. This is useful since many digital cameras don’t use sRGB in their raw format, so simply interpreting the red, green and blue values as such is unlikely to produce the correct color. Typically, you won’t have to do anything to get this color-matching. Nearly all image processing software allows you to tag an image with a color profile, and many do it by default.</i><p>[1]: <a href="https://webkit.org/blog/6682/improving-color-on-the-web/" rel="nofollow">https://webkit.org/blog/6682/improving-color-on-the-web/</a>
Again, my suspicion is that you are actually seeing the ICC profile being applied correctly, and it is the pixel values in your image that are incorrect.<p>A good test would be to run a single 100% sRGB red pixel through your image processing pipeline, and then inspecting the resulting PNG file in a hex editor to see what value is encoded.<p>You can also visit this web page to actively test each web browser’s respect for embedded ICC profiles: <a href="https://www.gballard.net/psd/go_live_page_profile/embeddedJPEGprofiles.html#" rel="nofollow">https://www.gballard.net/psd/go_live_page_profile/embeddedJP...</a>
Another good test page for the browser: <a href="https://www.color.org/version4html.xalter" rel="nofollow">https://www.color.org/version4html.xalter</a>
Where, for reference, Safari shows an image that matches the first one listed—meaning, at least in theory, that it fully supports ICC profiles.
To paraphrase Steve Jobs, "you're pixeling it wrong".
Something is off about this.<p>> Plot twist; here was never a gAMA chunk to begin with!<p>But I do see a gAMA chunk in the file?<p>> 00 00 00 04 67 41 4d 41 00 03 5b 5e 5c ff 26 78<p>Which decodes to a value of 2.19998. Conversely, I don't see any bundled ICC profiles (iCCP chunks).<p>Mind you, I <i>am</i> able to reproduce the different colors, so something is indeed wrong. Chrome (Windows) and the Photos app (MS Store) both present it as a washed out, ghostly image (I wouldn't describe it as foggy, as that to me suggests a blur as well, but alas). In contrast, when I open it in MS Paint (the modern, MS Store app version), I do get saturated colors.<p>UPDATE:<p>The gamma chunk does exist, and is wrong. That's the author's issue.<p>> Aha! Surely this is a gamma correction issue. Chrome must be applying gamma math differently than desktop apps.<p>And so the author was actually correct here, just the wrong way around. The actual gamma stored in the picture is ~2.2, while 0.4545 is the <i>correct</i> value for a typical SDR gAMA chunk (1÷2.2).<p>After hex editing the gAMA chunk to feature 0.4545 instead, the image now renders correctly everywhere for me.<p>The actual difference then is that some apps simply ignored this chunk and just forced 0.4545 anyways.
"Chrome was not wrong. it's doing proper color management by respecting the embedded ICC profile"<p>That's not how color management is meant to work. The color profile tells you how the data is saved. If you are displaying it using a different color profile, then it needs to be converted. Displaying P3 in sRGB is doing it wrong. How can you conclude Chrome "was not wrong"?
><i>If you are using Firefox or a Chromium browser (for me Google Chrome 143.0.7499.170), it's very likely that you are seeing a very foggy version of the painting, however, if you download the image and open it with your default image viewer (or open it in the Safari browser), you will see the image normally.</i><p>Why does the page 404 when opening the image? Bandwidth issue? Firefox issue? (Yes, the username is a joke - I don't work for Firefox I just use it and thought this would be a funny name)<p>they wayback machine doesn't have a copy of <a href="https://lr0.org/i/2025-12-27_18-21-51_screenshot.png" rel="nofollow">https://lr0.org/i/2025-12-27_18-21-51_screenshot.png</a> or i was going to link to it in the post here usually, i'd try to balance a blunt reply like this with they wayback version<p>cheers!<p>Edit: <a href="https://web.archive.org/web/20251227181428if_/https://lr0.org/blog/i/2025-12-27_18-21-51_screenshot.png" rel="nofollow">https://web.archive.org/web/20251227181428if_/https://lr0.or...</a>
It was a typo in the url, should have pointed to <a href="https://lr0.org/blog/i/2025-12-27_18-21-51_screenshot.png" rel="nofollow">https://lr0.org/blog/i/2025-12-27_18-21-51_screenshot.png</a> instead. I fixed it, thanks!
this picture does show differently in Chrome and Safari, but if I analyze it using the methods you did I arrive at a different result - I don't see an iHDR chunk there, instead I see a gAMA chunk and if I remove it with pngcrush it shows normally in Chrome.<p>maybe you linked a different picture?
that was quick, i edited the wayback cache of the image in like i lamented i couldn't in the orginal, i'm such a pessimist :-)<p><a href="https://web.archive.org/web/20251227181428if_/https://lr0.org/blog/i/2025-12-27_18-21-51_screenshot.png" rel="nofollow">https://web.archive.org/web/20251227181428if_/https://lr0.or...</a>
Image looks the same to me in Firefox (Linux) and Falkon as it does in image viewers (Gwenview and GIMP). Which in all cases seems kind of washed out, so I think that's the "smoky," not "normal" image but I'm not sure.
you can also do this with JPEGs. se my repo <a href="https://github.com/derenrich/hdr-steganography" rel="nofollow">https://github.com/derenrich/hdr-steganography</a>
Ah, so we're back to koolefant:<p><a href="https://x42.com/koolefant/" rel="nofollow">https://x42.com/koolefant/</a><p>> If you are using Netscape(*) you will probably see the happy cow above.
Internet Explorer-users on Windows and Mac, however, will see a dead flat elephant. And this is due to a strange browser-feature.<p>> (*) or MSIE for Solaris<p>Yes, Netscape and MSIE on Solaris. This goes back to the 1990s:<p><a href="https://web.archive.org/web/19990222144857/http://x42.com/koolefant/" rel="nofollow">https://web.archive.org/web/19990222144857/http://x42.com/ko...</a>