Notably GCP is rolling this out to their DICOM store API, so you get the space savings of JXL but can transcode on the fly for applications that need to be served JPEG.

Only know this because we have tens of PBs in their DICOM store and stand to save a substantial amount of $ on an absurdly large annual bill.

Native browser support is on our wishlist and our contacts indicate the chrome team will get there eventually.

That's not to say that JXL is bad or going away. It currently has poor browser support, but it's now finding its footing in niche use cases (archival, prosumer photography, medical), and will eventually become ubiquitous enough to just be what the average person refers to as "JPEG" 10 years from now.

To address selected claims made in the post:

• "AVIF is 'homegrown'" – AVIF is an open, royalty-free AOMedia standard developed by the Alliance for Open Media (Google, Microsoft, Amazon, Netflix, Mozilla, etc.).

• "AVIF is 'inferior'" – AVIF is significantly better than JPEG/WebP in compression efficiency at comparable quality, and comparable with JXL in many scenarios.

• "AVIF is ridiculous in this aspect, capping at 8,193×4,320." — JXL's theoretical maximum image size is bigger. The author cites AVIF's Baseline profile (think embedded devices), but AVIF supports 16,384×8,704 per tile. It HEIF container format supports a grid of up to 65,535 tiles (so logical images sizes up to 1,073,725,440 wide or 283,111,200 tall).

So, JPEG XL is good. Yes, it's far behind AVIF in terms of adoption and ecosystem, but that will improve. AVIF is likely to erase any current JXL quality advantages with AV2, but both JXL and AV1/AV2 encoders will get better with time, so they're likely to be neck-and-neck in quality for the foreseeable future.

[0] https://issues.chromium.org/issues/40168998#comment507

Uncompressed: 3.5–7 exabytes Realistically compressed: Tens to hundreds of petabytes

Thats a serious high-res image

Chromium Team Re-Opens JPEG XL Feature Ticket https://news.ycombinator.com/item?id=46018994

FSF Slams Google over Dropping JPEG-XL in Chrome https://news.ycombinator.com/item?id=35589179

Google set to deprecate JPEG XL support in Chrome 110 https://news.ycombinator.com/item?id=33399940

Chromium jpegxl issue closed as won't fix https://news.ycombinator.com/item?id=40407475

I am using .avif since some years; all my old .jpg and .png files have been pretty much replaced by .avif, in particular fotos. I am not saying .avif is perfect, but IMO it is much better than .jpg or .avif.

I could have gone .webp or perhaps jpeg-xl but at the end of the day, I am quite happy with .avif as it is.

As for JPEG XL - I think the problem here is ... Google. Google dictates de-facto web-standards onto us. This is really bad. I don't want a commercial entity control my digital life.

I think both Mozilla and Google are OK with this - if it is written in Rust in order to avoid that situation.

I know the linked post mentions this but isn't that the crux of the whole thing? The standard itself is clearly an improvement over what we've had since forever.

Well tbf, the only time I ever hear about JPEG XL is when people complain about Chrome not having it. I think that might be its only actual use case.

Encoding and decoding JPEG XL file is: #djxl input.jxl output.png.

Imagine how long it will take for JPEG XL that didn't even reach wide browsers support yet.

Side note - comparing JPEG XL and AVIF features wise is sort of pointless if AVIF will continue to evolve based on AV2 and etc.

The insanity that the web platform is just "whatever Google's whims are" remains insane and mercurial. The web platform should not be as inconsistent as Google's own product strategies, wonder if XSLT will get unkilled in a few months.