This PNG shows a different version when loaded in Chrome than in Safari

37•lr0•2h ago

Comments

dcrazy•1h ago

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/

lr0•1h ago

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.

dcrazy•1h ago

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.

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.

You can also visit this web page to actively test each web browser’s respect for embedded ICC profiles: https://www.gballard.net/psd/go_live_page_profile/embeddedJP...

mirashii•1h ago

Another good test page for the browser: https://www.color.org/version4html.xalter

danaris•39m ago

Where, for reference, Safari shows an image that matches the first one listed—meaning, at least in theory, that it fully supports ICC profiles.

leptons•22m ago

To paraphrase Steve Jobs, "you're pixeling it wrong".

alwillis•13m ago

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.

The WebKit blog from 2016:

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.

[1]: https://webkit.org/blog/6682/improving-color-on-the-web/

culi•1h ago

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

dylan604•1h ago

"correct" in fail, in the same way across browsers? that's hilarious. I forget that throughout the history of the internet the one thing we've been able to depend on is different browsers behaving the same way

culi•22m ago

interoperability of web features has never been this good and it's only getting better

https://wpt.fyi/interop-2025

other than the Manifest v3 fiasco, we're probably living in the golden age of web interop

PaulHoule•44m ago

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.

What gets me is that the image he's publishing is not really a PNG kind of image.

[1] https://cybereality.com/rendepth-red-cyan-anaglyph-filter-op... is a write up that didn't go as deep as my research

garciansmith•1h ago

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.

kaelwd•1h ago

GIMP asks if I want to keep or convert the color profile but both options look washed out. The only thing that opens it "correctly" for me is MPV.

brokensegue•1h ago

you can also do this with JPEGs. se my repo https://github.com/derenrich/hdr-steganography

msla•1h ago

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

dylan604•1h ago

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

alwillis•7m ago

> If you are displaying it using a different color profile, then it needs to be converted. Displaying P3 in sRGB is doing it wrong.

Correct. What's supposed to happen is P3 colors get converted on the fly to the their closest sRGB colors.

firefax•1h ago

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

lr0•1h ago

It was a typo in the url, should have pointed to https://lr0.org/blog/i/2025-12-27_18-21-51_screenshot.png instead. I fixed it, thanks!

firefax•30m ago

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 :-)

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

black3r•15m ago

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.

maybe you linked a different picture?

perching_aix•11m ago

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

Collaboration That Built Modern AI: Conversation with Geoff Hinton and Jeff Dean

Show HN: Buildex – Interactive system design practice with AI feedback

Rclone syncs your files to cloud storage

Nick Fuentes and Groypers: How Bots Built America's Anti-Indian Hate Movement

Both of these influencers are successful – but only one is human

Every Hacker News Post with a Prime Id Number

A Tale of Two Leaks: How Hackers Breached the Great Firewall of China [video]

Ask HN: Best Email AI Assistant?

The Arctic: Where Drones Drop Dead and GPS Goes Haywire

How the CPython Compiler Works

Bauhaus Clock – Most Elegant Clock Screensaver for Mac

Show HN: Design your own post-AGI civilization with tradeoffs

Show HN: Litmus – Specification testing for structured LLM outputs

Play the Monty Hall Game

Show HN: Ssort – I got sick and vibe coded a stream priority sorter

Quality Food Comes from Constraints

The Empiricism Gap in Computer Science

Toll roads are spreading in America

London Eye architect proposes 14-mile tidal power station off Somerset coast

The production bug that made me care about undefined behavior

Google tests 30-minute Lecture Audio Overviews on NotebookLM

Bloat in software is getting WAAAY out of hand

Tell HN: Discord Is Down

Email Is Broken – Can Nostr Fix It?

Scientists Edited Genes Inside a Living Person for First Time, Saved His Life

Data-Oriented Design

First personalized CRISPR therapy given to baby with genetic disease

Tesla's Former AI Director Karpathy Sends 'Open Letter' to Software Engineers

Why Everyone Loves Japan

Windows 2 for the Apricot PC/Xi