Remix.run Logo
Google Revisits JPEG XL in Chromium After Earlier Removal(windowsreport.com)
74 points by eln1 4 hours ago | 17 comments
caminanteblanco 2 hours ago | parent | next [-]

My introduction to JPEG-XL was by 2kliksphillip on YouTube, he has a few really good analyses on this topic, including this video: https://youtu.be/FlWjf8asI4Y

charcircuit 3 hours ago | parent | prev | next [-]

Here are the direct links:

blink-dev mailing list

https://groups.google.com/a/chromium.org/g/blink-dev/c/WjCKc...

Tracking Bug (reopened)

https://issues.chromium.org/issues/40168998

AshleysBrain an hour ago | parent | prev | next [-]

I think the article is slightly misleading: it says "Google has resumed work on JPEG XL", but I don't think they have - their announcement only says they "would welcome contributions" to implement JPEG XL support. In other words, Google won't do it themselves, but their new position is they're now willing to allow someone else to do the work.

jonsneyers 39 minutes ago | parent [-]

It's technically correct. Googlers (at Google Research Zurich) have been working on jxl-rs, a Rust implementation of JPEG XL. Google Research has been involved in JPEG XL from the beginning, both in the design of the codec and in the implementation of libjxl and now jxl-rs.

But until now, the position of other Googlers (in the Chrome team) was that they didn't want to have JPEG XL support in Chrome. And that changed now. Which is a big deal.

mikae1 4 hours ago | parent | prev | next [-]

The final piece of the JPEG XL puzzle!

free_bip 3 hours ago | parent [-]

It's a huge piece for sure, but not the only one. For example, Firefox and Windows both don't support it out of the box currently. Firefox requires nightly or an extension, and on Windows you need to download support from the Microsoft store.

zinekeller 24 minutes ago | parent | next [-]

> on Windows you need to download support from the Microsoft store.

To be really fair, on Windows:

- H.264 is the only guaranteed (modern-ish) video codec (HEVC, VP9, AV1 is not built-in unless the device manufacturer bothered to do it)

- JPEG, GIF, and PNG are the only guaranteed (widely-used) image codecs (HEIF, AVIF, and JXL is also not built-in)

- MP3 and AAC are the only guaranteed (modern-ish) audio codecs (Opus is another module)

... and all of them are widely used when Windows 7 was released (before the modern codecs) so probably modules are now the modern Windows Method™ for codecs.

Note on pre-8 HEVC support: the codec (when not on VLC or other software bundling their own codecs) is often on that CyberLink Bluray player, not a built-in one.

JyrkiAlakuijala 2 hours ago | parent | prev [-]

Would PDF 2.0 (which also depends JPEG XL and Brotli) put pressure on Firefox and Windows to add more easy to use support?

jchw 2 hours ago | parent [-]

I don't think so: JPEG 2000, as far as I know, isn't generally supported for web use in web browsers, but it is supported in PDF.

fmajid 2 hours ago | parent [-]

JPEG-XL is recommended as the preferred format for HDR content for PDFs, so it’s more likely to be encountered:

https://www.theregister.com/2025/11/10/another_chance_for_jp...

jchw 2 hours ago | parent [-]

What I mean to say is, I believe browsers do support JPEG 2000 in PDF, just not on the web.

adzm 2 hours ago | parent | prev | next [-]

jxl-rs https://github.com/libjxl/jxl-rs was referenced as a possibility; what library is Safari using for jpegxl?

jiggawatts an hour ago | parent | prev [-]

2026 is nearly upon us, and Google, Microsoft, and Apple remain steadfast in the refusal to ever allow anyone to share wide-gamut or HDR images.

Every year, I go on a rant about how my camera can take HDR images natively, but the only way to share these with a wider audience is to convert them to a slideshow and make a Rec.2020 HDR movie that I upload to YouTube.

It's absolutely bonkers to me that we've all collectively figured out how to stream a Hollywood movie to a pocket device over radio with a quality exceeding that of a typical cinema theatre, but these multi-trillion market cap corporations have all utterly failed to allow users to reliably send a still image with the same quality to each other!

Any year now, maybe in 2030s, someone will get around to a ticket that is currently at position 11,372 down the list below thousands of internal bullshit that nobody needed done, rearranging a dashboard nobody has ever opened, or whatever, and get around to letting computers be used for images. You know, utilising the screen, the only part billions of users ever look at, with their human eyes.

I can't politely express my disgust at the ineptitude, the sloth, the foot dragging, the uncaring unprofessionalism of people that get paid more annually then I get in a decade who are all too distracted making Clippy 2.0 instead of getting right the most utterly fundamental aspect of consumer computing.

If I could wave a magic wand, I would force a dev team from each of these companies to remain locked in a room until this was sorted out.

mirsadm an hour ago | parent | next [-]

It is incredibly annoying that instead of adopting JpegXL they decided to use UltraHDR. A giant hack which works very poorly.

jiggawatts 42 minutes ago | parent [-]

> A giant hack which works very poorly.

Indeed. I tried every possible export format from Adobe Lightroom including JPG + HDR gainmaps, and it looks... potato.

With a narrow gamut like sRGB it looks only slightly better than JPG, but with a wider gamut you get terrible posterization. People's faces turn grey and green and blue skies get bands across them.

Meanwhile my iPhone creates flawless 10-bit Dolby Vision video with the press of a button that I can share with anyone without it turning into a garbled mess.

Just last week I checked up on the "state of the art" for HDR still image sharing with Gemini Deep Research and after ten minutes of trawling through obscure forum posts it came back with a blunt "No".

We've figured out how to make machines think, but not how to exchange pictures in the quality that my 12-year-old DSLR is capable of capturing!

... unless I make a YouTube video with the images. That -- and only that -- works!

geocar 40 minutes ago | parent | prev [-]

> the only way to share these with a wider audience is to convert them to a slideshow and make a Rec.2020 HDR movie that I upload to YouTube

i understand some of this frustration, but really you just have to use ffmpeg to convert it to a web format (which can be done by ffmpeg.js running in a service worker if your cpu is expensive) and spell <img as <video muted autoplay playsinline which is only a little annoying

> I can't politely express my disgust at the ineptitude, the sloth, the foot dragging, the uncaring unprofessionalism of people that get paid more annually then I get in a decade who are all too distracted making Clippy 2.0 instead of getting right the most utterly fundamental aspect of consumer computing.

hear hear

> If I could wave a magic wand, I would force a dev team from each of these companies to remain locked in a room until this was sorted out.

i can think of a few better uses for such a wand...

jiggawatts 37 minutes ago | parent [-]

> <img as <video muted autoplay playsinline which is only a little annoying

Doesn't work for sharing images in text messages, social media posts, email, Teams, Wikipedia, etc...

> i can think of a few better uses for such a wand...

We all have our priorities.