Something is off about this.

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

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.

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/

"Chrome was not wrong. it's doing proper color management by respecting the embedded ICC profile"

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

> What's Really Happening

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

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

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

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 https://github.com/derenrich/hdr-steganography

Very interesting! I tried holding down on the image to open the context menu and open it in a new tab. In the context menu, I could see a bright and vivid thumbnail of the image, but when I clicked "Press image in a new tab" it showed the same washed out image as on the web page. Interesting!

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

I was wondering why, in my Firefox, the image appears saturated when embedded on the website, but opening it in a new tab by a direct URL shows an unsaturated version. The `img` tag on the website seems to be styled with `mix-blend-mode: multiply`, which makes the image darker because the background is #f0f0f0.

Ah, so we're back to koolefant:

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

> This is an arbitrary picked image, hashed internally and mapped to this page. You will have to see it as long as you in my website. hash: eb46e097… → idx 29/166

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?

[dead]