[lnanek2]

As a mobile developer I generally see WEBP getting served to Android devices and HEIC to Apple devices. Is there any advantage to JPEG XL over those?

If our app supported older iOS devices, maybe JPEG would be needed as a fallback, but it seems like JPEG XL wouldn't be compatible with old devices anyway, right?

[brigade]

I don't believe any platforms or browsers have enabled JPEG-XL support yet, so right now you'd need to ship the decoder yourself anyway.

But, it's at least as much better than WebP as WebP was better than JPEG. And unlike HEIC, web browsers are considering supporting it, though AVIF is currently ahead of JPEG-XL in browser support.

JPEG-XL also currently beats HEIC and AVIF at medium to high quality, but it's a fair question just how much that's intrinsic to the format and how much that is from libjxl's tuning focus being at those quality levels; AV1 and HEVC encoders have mostly focused on lower bitrates in the range that video would use.

JPEG-XL is the ~best lossless image format currently available, though.

[CSSer]

> though AVIF is currently ahead of JPEG-XL in browser support.

It certainly looks like AVIF is ahead because it has landed in and Firefox and Chrome, but it's blocked in Safari by a required OS change[0] (iOS/macOS support if I understand the comment correctly?). Additionally, there's no implementation in Edge (even though it's chromium)[1]. Sorry, I wish I had more details but I'm not sure where to look to find a status update on that.

Meanwhile, JPEG-XL has support behind a feature in every major browser except Safari[2]. As you and others have noted, there seems to be a lot of buzz and excitement around JPEG-XL throughout the ecosystem. The webkit folks seem to be making an effort to get the ball rolling[3]. I might be misinterpreting something but it all looks very encouraging at any rate. It almost seems like it might gain wide support in Firefox and Chromium (Chrome & Edge) around the same time with Webkit following (hopefully) closely thereafter. Heck, I don't see why Webkit doesn't just abandon AVIF and focus on rolling out JPEG-XL.

[0]: https://bugs.webkit.org/show_bug.cgi?id=207750#c25

[1]: https://caniuse.com/avif

[2]: https://caniuse.com/jpegxl

[3]: https://bugs.webkit.org/show_bug.cgi?id=233364

[Markoff]

you can serve new devices with JPEG XL and convert it back to JPEG without loss on server for old devices

[mkl]

I think you might have that backwards. JPEG can be losslessly converted to JPEG XL with better compression (~20% smaller), but I haven't seen anything about going the other direction. I'm not sure how it would be possible with JPEG XL's different sized blocks and different available transforms. https://en.wikipedia.org/wiki/JPEG_XL

[brigade]

The JPEG -> JXL conversion is reversible, so you can encode JPEG -> convert JXL -> convert back to JPEG as needed. You could potentially encode a JPEG-XL directly with the subset that can be converted back to JPEG, but it's not clear to me if libjxl currently implements that.

Either way, it's not that useful for anyone that's already deploying post-JPEG formats; even WebP should save more than 20%. Mostly it's useful for CDNs and SaaS companies like Cloudinary to transparently deploy JPEG-XL for JPEG-only customers.

[remram]

Do you mean that you would want that to happen on the web server, if they detect a user-agent that doesn't support JXL, they would convert back to JPEG? That seems pointlessly costly in CPU.

Also like mkl said, there doesn't seem to be any evidence that JXL->JPEG can be done losslessly.

[rasz]

Dont know about web servers, but there are people doing it on the backup/storage side. https://dropbox.tech/infrastructure/lepton-image-compression...

[pabs3]

I tried it locally on my computer, JPEG -> JXL -> JPEG results in two bitwise identical JPEGs.