Hacker News Reader

Comment by Macha | Hacker News Reader

The big feature over other new formats is compatibility with legacy JPEGs. You can (simplified) take the raw data from a legacy JPEG, reformat it as a JPEG XL, and achieve like 20-30% filesize savings without any actual re-encode, just better packaging of the same data. While converting them to AVIF or webp is a lossy re-encode, and so loses quality. I think it's really this feature that has people wanting it still despite the support for AVIF.

Also webp is IMO subjectively worse at the same file sizes than the other two. Dunno if there's any studies on it to back that up though. It also has a max image size that is plausibly a problem in some use cases (16k in one dimension) while AVIF is 65k per axis and JXL 1M per axis.

View on HN

Webp lossy is better (compresses more with higher quality image results) than jpeg at everything except smooth gradients at high quality settings according to the research I remember doing. Webp lossy can't seem to get rid of banding until you go ultra high quality settings. Jpeg can show blue skies without banding at much more reasonable quality settings. So webp is better at anything where smaller files is preferred, like all website usage. Jpeg is better for long term storage of very high quality lossy compressed images.

I chose webp for long term storage of scanned documents in our SaaS product, as size reduction was more important than no banding.

Also webp has excellent support in modern software and operating systems. So that's not a drawback any more. JpegXL will be the best of all worlds choice in a few years when software support is good.

> JpegXL will be the best of all worlds choice in a few years when software support is good.

Where is the software support lacking other than the browsers at this point?

The encoder currently isn't using a lot of format features like curves or layers (which would partially also require deeper integration in for example Photoshop to pass such information to the encoder).

File explorer support, thumbnails, local image viewers and editors, import into other media software like slideshows, video editors, 3d modeling software, etc etc.

macOS and Windows’ respective file explorers and built-in image viewers both support it, as do Photoshop, GIMP, Krita and a few more. https://en.wikipedia.org/wiki/JPEG_XL#Official_software_supp...

I suspect there are a few 10s of thousands of websites that still only accept Jpeg (as a user upload). Some accept PNG. Few accept HEIF, almost none accept JPEG-XL

This is probably going to be the longest tail of them all.

I only accept webp, jpg, and png atm in my SaaS product. I should probably add support for HEIF right now at least. All iPhones are using that, so it's hard to get around it.

Aren't they translating to JPG on upload automatically anyways?

That must be happening, because I haven't gotten any complaints and I know we have many users on ios.

There are some other advantages, such as jxl being able to progressively load in web broswers, while avif can't for some reason. However avif compression seems to be better at low qualities, which might be relevant for some web applications, if one doesn't want to serve both jxl and avif.

There's a good visual comparison here:

https://www.youtube.com/watch?v=SzsM4HMKmEI

JPEG has had progressive loading on browsers since the almost the very beginning. But everybody stopped using it because it added slightly to the file size and "looked ugly." According to most web designers, anyway, who would actually rather serve the user a blank page than have even one of their precious pixels out of place.

I haven't actually seen a progressive jpeg rendering since the dialup days at any rate.

Most JPEGs are slightly smaller as progressive. The drawback is rather that it’s slightly more resource-intensive to decode, and if you overdo it and split the chroma, you can get weird effects: https://cloudinary.com/blog/progressive_jpegs_and_green_mart...

> According to most web designers, anyway, who would actually rather serve the user a blank page than have even one of their precious pixels out of place.

Think of pixels out of place as portions of code left unoptimised. It still compiles, runs and works just fine. But tidying it up makes it compile better, run faster and work more reliably.

Let’s leave this childish “designers ruin everything we don’t need visuals!!!!” nonsense for the reddits of the internet, yeah? You’re not a better code monkey just for complaining about designers.

It has been at least a few months since I did some testing on my MacBook Pro m4, where I converted a bunch of camera jpegs to jxl losslessly, and yeah the jxl files were smaller, but the decoding/viewing experience on macOS was worse than with jpegs. Thumbnails were missing, and just browsing through a folder of them with QuickLook was unbearably slow compared to jpeg, perhaps at least few hundred milliseconds or even longer than a second, when the JPEGs were instant. Idk if that’s just Apples implementation not good yet, but that’s why I at the time abandoned converting all my JPEGs to lossless jxl

Lossless Webp is still very good, and it decompresses very quickly. Lossless JXL compresses better, but decompresses much more slowly. Lossless AVIF is a joke.

Reply on news.ycombinator.com