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.

But if the author is absolutely confident in their analysis, they are welcome to file a bug report: https://bugs.webkit.org/

https://x42.com/koolefant/

> 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.

> (*) or MSIE for Solaris

Yes, Netscape and MSIE on Solaris. This goes back to the 1990s:

https://web.archive.org/web/19990222144857/http://x42.com/ko...

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"?

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)

they wayback machine doesn't have a copy of https://lr0.org/i/2025-12-27_18-21-51_screenshot.png 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

cheers!

Edit: https://web.archive.org/web/20251227181428if_/https://lr0.or...

> Plot twist; here was never a gAMA chunk to begin with!

But I do see a gAMA chunk in the file?

> 00 00 00 04 67 41 4d 41 00 03 5b 5e 5c ff 26 78

Which decodes to a value of 2.19998. Conversely, I don't see any bundled ICC profiles (iCCP chunks).

Mind you, I am 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.

UPDATE:

The gAMA chunk not only exists, its value is wrong! That's the author's issue. Either they authored the image incorrectly, or their authoring software is getting it wrong.

> Aha! Surely this is a gamma correction issue. Chrome must be applying gamma math differently than desktop apps.

And so the author was actually correct here, just the wrong way around. The actual gAMA value stored in the picture is ~2.2, while 0.4545 would be the correct value for a typical sRGB gAMA chunk (1÷2.2). Gamma is 1÷display_exponent, and so the usual "~2.2 gamma" you hear is actually that display_exponent in this context; see: https://www.w3.org/TR/2003/REC-PNG-20031110/#12Encoder-gamma...

After hex editing the gAMA chunk to actually feature the "default" 0.4545 instead, the image now renders correctly everywhere for me.

For those looking to repro, these are the bytes I substituted in:

> 00 00 00 04 67 41 4D 41 00 00 B1 8F 0B FC 61 05

The actual difference then is that apparently some apps simply ignore this chunk and just force 0.4545 anyways.

What is this nonsense about? I’m on a tablet and over 1/3rd of my screen is basically telling me to go fuck myself?

> (1) The PNG contains an embedded ICC color profile* (likely Display-P3 or another wide-gamut color space),

Why didn't you check? From what I can tell when I did, there is no color profile in the original image so it'll default to sRGB. This really looks like a gamma issue of some sort (see @perching_aix's comment).

(I'm running Brave Mobile if that matters. I'm curious if the thumbnail is rendered differently on other mobile web browsers as well?)