10 ms·
Google Revisits JPEG XL in Chromium After Earlier Removal
- mikae1 10mo agoThe final piece of the JPEG XL puzzle!
- free_bip 10mo agoIt'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.
- JyrkiAlakuijala 10mo agoWould PDF 2.0 (which also depends JPEG XL and Brotli) put pressure on Firefox and Windows to add more easy to use support?
- jchw 10mo agoI 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 10mo agoJPEG-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_jpeg_xl/ https://www.theregister.com/2025/11/10/another_chance_for_jp...
- jchw 10mo agoWhat I mean to say is, I believe browsers do support JPEG 2000 in PDF, just not on the web.
- Zardoz84 10mo agothe last time that I check it, I find that I need to convert to Jpeg to show the image in browsers.
- jchw 10mo agoA *PDF* with embedded JPEG 2000 data should, as far as I know, decode in modern browser PDF viewers. PDF.js and PDFium both are using OpenJPEG. But despite that, browsers don't currently support JPEG 2000 in general. I'm saying this to explain how JPEG XL support in PDF isn't a silver bullet. Browsers already support image formats in PDF that are not supported outside of PDF.
- bmicraft 10mo agoI'm not convinced HDR PDFs will be a common thing anytime soon, even without this chicken and egg problem of support
- RobotToaster 10mo agoSo Firefox (or others) can't open a pdf with a embedded jpeg-2000/XL? Or does pdf.js somehow support it?
- lxgr 10mo agoSeems like it: https://github.com/mozilla/pdf.js.openjpeg https://github.com/mozilla/pdf.js.openjpeg This test renders correctly in Firefox, in any case: https://sources.debian.org/data/main/p/pdf2djvu/0.9.18.2-2/tests/test-jpeg2000.pdf https://sources.debian.org/data/main/p/pdf2djvu/0.9.18.2-2/t...
- jchw 10mo agoApparently I really flubbed my wording for this comment. I'm saying they do support it inside of PDF, just not elsewhere in the web platform.
- alwillis 10mo ago> 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. Safari supported JPEG 2000 since 2010 but removed support last year [1]. [1]: https://bugs.webkit.org/show_bug.cgi?id=178758 https://bugs.webkit.org/show_bug.cgi?id=178758
- GuB-42 10mo agoBrotli? Is it still relevant now that we have Zstandard? Zstandard is much faster in just about every benchmark, sometimes Brotli has a small edge when it comes to compression ratio, but if you go for compression ratio over speed, LZMA2 beats them both. Both Zstandard (zstd) and LZMA2 (xz) are widely supported, I think better supported than Brotli outside of HTTP.
- JyrkiAlakuijala 10mo agoBrotli decompresses 3-5x faster than LZMA2 and is within 0.6 % of the compression density, and much better for short documents. ZStandard decompresses ~2x faster than Brotli but is 5 % less dense in compression density, and even less dense for short documents or documents where the static dictionary can be used. Brotli is not slow to decompress -- generally a little faster then deflate through zlib. Last time I measured, Brotli had ~2x smaller binary size than zstd (dec+enc).
- GuB-42 10mo agoStraight from the horse's mouth! The thing is that Brotli is clearly optimized for the web (it even has a built-in dictionary), and ZStandard is more generic, being used for tar archives and the likes, I wonder how PDF would fit in here.
- zinekeller 10mo ago> 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.
- viktorcode 10mo agoA large and important piece, but not the final. If it will remain web-only codec, that is no Android and iOS support for taking photos in JPEG XL, then the web media will still be dominated with JPEGs.
- kasabali 10mo agoSamsung is claimed to be supporting it: https://cloudinary.com/blog/samsung-now-supports-dng-1-7-including-jpeg-xl https://cloudinary.com/blog/samsung-now-supports-dng-1-7-inc...
- charcircuit 10mo agoHere are the direct links: blink-dev mailing list https://groups.google.com/a/chromium.org/g/blink-dev/c/WjCKcBw219k/m/NmOyvMCCBAAJ https://groups.google.com/a/chromium.org/g/blink-dev/c/WjCKc... Tracking Bug (reopened) https://issues.chromium.org/issues/40168998 https://issues.chromium.org/issues/40168998
- IshKebab 10mo agoYeah note that Google only said they're now open to the possibility, as long as it is written in Rust (rightly so). The patch at the end of that thread uses a C++ implementation so it is a dead end.
- surajrmal 10mo agoRick specifically said commitment for long term maintenance and meeting usual standards for shipping. The implementation was abandoned in favor of a new one using rust, so not necessarily a dead end.
- IshKebab 10mo agoI meant the C++ patch is a dead end; not JPEG XL support in general. Seems like there's a Rust library that will have to be used instead.
- caminanteblanco 10mo agoMy 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 https://youtu.be/FlWjf8asI4Y
- adzm 10mo agojxl-rs https://github.com/libjxl/jxl-rs https://github.com/libjxl/jxl-rs was referenced as a possibility; what library is Safari using for jpegxl?
- JimDabell 10mo agolibjxl: https://github.com/libjxl/libjxl https://github.com/libjxl/libjxl https://github.com/WebKit/WebKit/blob/7879cb55638ec765dc033dd9ba1a11bc3c789efa/Tools/jhbuild/jhbuild-minimal.modules#L244C8-L244C14 https://github.com/WebKit/WebKit/blob/7879cb55638ec765dc033d...
- gsnedders 10mo agoThe second link isn't applicable to Apple's WebKit ports — it's entirely built via Xcode. https://github.com/WebKit/WebKit/blob/39386f4547897c89c510d0eeeecddc5efb5d6d13/Source/WebCore/Configurations/WebCore.xcconfig#L29-L34 https://github.com/WebKit/WebKit/blob/39386f4547897c89c510d0... defines USE_JPEGXL only for macOS < 14 (which aren't actually supported any more!). All the in-tree JPEG XL support, e.g., https://github.com/WebKit/WebKit/blob/39386f4547897c89c510d0eeeecddc5efb5d6d13/Source/WebCore/platform/image-decoders/jpegxl/JxlDecoderPtr.h https://github.com/WebKit/WebKit/blob/39386f4547897c89c510d0... is behind a "USE(JPEGXL)" ifdef — so none of that is compiled in. Instead, it's using what Apple ships at a system level, in Image I/O. https://github.com/WebKit/WebKit/blob/39386f4547897c89c510d0eeeecddc5efb5d6d13/Source/WTF/wtf/PlatformHave.h#L1315-L1321 https://github.com/WebKit/WebKit/blob/39386f4547897c89c510d0... defines HAVE_JPEGXL for recent versions of Apple's OSes. https://github.com/WebKit/WebKit/commit/932073284e4c73ce9884d0c6e15fe86fe99685c5 https://github.com/WebKit/WebKit/commit/932073284e4c73ce9884... is the commit which added this — there's really not much there, because it's just setting the define and adding it to the allowlist of image types. And yeah, currently I believe this is libjxl — or a fork thereof — hence the inclusion of libjxl in the Acknowledgements.rtf file on macOS.
- jiggawatts 10mo ago2026 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 10mo agoIt is incredibly annoying that instead of adopting JpegXL they decided to use UltraHDR. A giant hack which works very poorly.
- jiggawatts 10mo ago> 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!
- AshleysBrain 10mo agoI 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 10mo agoIt'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.
- deleted 10mo ago[deleted]
- jmgao 10mo agoDescribing it as 'Google' is misleading, because different arms of the company might as well be completely different companies. The Chrome org seems to have had the same stance as Firefox with regards to JPEG XL: "we don't want to add 100,000 lines of multithreaded C++ because it's a giant gaping security risk", and the JPEG XL team (in a completely separate org) is addressing those concerns by implementing a Rust version. I'd guess that needing the "commitment to long-term maintenance" is Chrome fighting with Google Research or whatever about long-term headcount allocation towards support: Chrome doesn't want the JPEG XL team to launch and abandon JPEG XL in chrome and leaving Chrome engineers to deal with the fallout.
- IshKebab 10mo agoYes and they will also only accept it if the library is written in Rust. The patch to add support that is in the thread, and referenced in the article uses libjxl which is C++ and therefore cannot be used.
- lousken 10mo agoIt is absolutely insane that google has not implemented this yet. They implement all sort of unimportant stuff but not the most critical image format of this decade, what a joke
- theandrewbailey 10mo agoAnd the things they do implement, they kill 8 or so years later. https://killedbygoogle.com/ https://killedbygoogle.com/
- lxgr 10mo agoIf all goes well (which is anything but guaranteed), JPEG XL will take off sufficiently to make any future deprecation as unthinkable as e.g. deprecating GIF rendering support.
- ksec 10mo agoWhile being a big supporter of JPEG-XL on HN, I just want to note AV2 is coming out soon, which should further improve the image compression. ( Edit: Also worth pointing out current JPEG-XL encoder is no where near its maximum potential in terms of quality / compression ratio ) But JPEG-XL is being quite widely used now, from PDF, medical images, camera lossless, as well as being evaluated in different stage of cinema / artist workflow production. Hopefully the rust decoder will be ready soon. And from the wording, it seems to imply Google Chrome will officially support anything from AOM.
- snvzz 10mo ago>medical images Isn't JPEG-XL a lossy codec?
- MagnumOpus 10mo agoIt has both lossy and lossless modes.
- snvzz 10mo agoGood to hear. I sure hope they came up with a good, clear system to distinguish them.
- lxgr 10mo agoAs in, a clear way to detect whether a given file is lossy or lossless? I was thinking that too, but on the other hand, even a lossless file can't guarantee that its contents aren't the result of going through a lossy intermediate format, such as a screenshot created from a JPEG.
- snvzz 10mo agoI meant like a filename convention, and tags in the file itself.
- eviks 10mo agoMaybe they'll do it right this time > The team explained that other platforms moved ahead. Safari supports JPEG XL, and Windows 11 users can add native support through an image extension from Microsoft Store. The format is also confirmed for use in PDF documents. glad those folks didn't listen to "the format is dead since the biggest browser doesn't support it" (and shame on Firefox for not doing the same)
- cgfjtynzdrfht 10mo agoHow quickly things turn. Hard to not support it given chrome wants to support PDF natively.
- _ache_ 10mo agoIt's a little step but a step forward. JXL is on part with AVIF and WebP2 most of the time but is very much better to share photography. There is no reason to block its adoption.
- particlo 10mo agoif you wanna compare jxl vs avif by taking photos yourself and have an android phone then try this APK https://github.com/particlo/camataca https://github.com/particlo/camataca i thought jxl was better by looking at its website benchmarks but then after trying it myself i find jxl generates ugly blocky artifacts
- 0xCAP 10mo agoImagine not trashing it for no valid reason in the first place, saving the useless effort to ditch it and then resume it shortly after.