[taikahessu]

Can someone explain where are we at the image processing world/timeline? Why do coding tools suggest to me .avif and .webp, and the support of these lags in Windows OS and then we have things like JpegXL and Jpeg2000 or whatever others are there flying around? Why is it so hard to find our next "jpg format"?

[Gigachad]

AVIF and webp kind of only exist for the web, they get used when you want to really crunch down on data as much as possible. They aren’t really used for files you’d save on your computer or get out of a camera.

JPEG XL is replacing regular jpeg and heif for photography. It offers 16 bit color rather than 8 from jpeg and HDR support along with a ton of extra features.

Every OS but Android supports it, safari supports it, chrome and Firefox have it behind a beta flag.

[Yokohiii]

> AVIF and webp kind of only exist for the web, they get used when you want to really crunch down on data as much as possible.

Speaking only for webp here. It is designed to balance download and decompression time to load faster than it's competitors. Compressed filesize isn't generally smaller and compression time is notoriously slow.

[gforce_de]

It's all about licences. If you need the images for the web: go for jpegli, webp and avif - the distance to jpegxl or webp2 is not worth the hassle:

https://show.quicky.club/results/14/f8/f1/d8db84d57222d32db6...

[qingcharles]

Agree. JXL won't be baseline for at least three years.

[Theodores]

Part of the problem is that images are used by everybody, including the non-technical people. It is usually the non-technical people that make the images, so we can't confuse them with file formats.

Hence the workflow with least amount of man-splaining is to stick to what the non-technical people know. Let them create everything in PNG (or JPG) with absolutely no compression whatsoever. Then have the origin server for the CDN substitute every requested image for a webp variant, mashed down to acceptable compression levels for the product/customer.

Since browsers don't care about file extensions for images, the images can be served with '.jpg' or '.png' extensions but contain webp. The browser will be fine with this because of the internal header in the image file.

Note that if the customer/user right clicks to download one of these webp images pretending to be png/jpg they should get served the PNG or JPG original, rather than the compressed webp. Yes it requires the origin server to read the headers and the CDN to read the headers too, however, this can be setup to be transparent to the people that create the images and the people that see them.

If the images are overly compressed or not compressed enough, the CDN cache can be cleared.

Note that this approach could be used to support JPEG XL right now, serving JPEG XL to browsers that support it and webp to those with lesser browsers.

What I find amusing about JPEG is that it was optimised for analogue CRTs and slow CPUs. We now have digital screens and fast(er) CPUs. The Mozilla encoder is easy to retrofit and this makes JPEG images better suited to what we have now rather than what we had in the 1980s. Things like banding goes away and the file sizes are smaller. Yet nobody adds the Mozilla libjpeg to their /bin/local.