I switched to WebP about a year and a half ago. I’d been watching for a long time and it had finally reached the point where support was universal enough that I could not publish a JPEG.

WebP has the big advantage that the quality setting is meaningful, you can set it at a certain level and then encode thousands of images and know the quality is about the same. This is by no means true about JPEG, if you are trying to balance quality and size you find you have to manually set the compression level on each image. Years back I was concerned about the size of a large JPEG collection and recompressed them which was a big mistake because many of the images were compressed too hard.

In 2023 I think you can just use WebP and it will work well, my experience looking at images is that AVIF does better for moderate to low quality images but for high quality images it doesn’t really beat WebP.

This image is helpful to see how they all kinda stack up, feature wise.

https://archive.smashing.media/assets/344dbf88-fdf9-42bb-adb...

There is plenty of wrong or misleading information here:

- What is the cross supposed to mean for PNG compression of photographic images? PNG can compress photographic images just fine and for some applications (where you want lossless) it used to be a good choice.

- PNG has animation support, even if everyone except Firefox tried to

- While WEBP and AVIF support lossless compression and animation, those features are not available in all browser versions that support static lossy webp/avif images.

> Years back I was concerned about the size of a large JPEG collection and recompressed them which was a big mistake because many of the images were compressed too hard.

Distortion metrics[0] such as MS-SSIM, MS-SSIM*, SIMM, MSE, and PSNR can be used to define a cut-off or threshold for deciding the point at which the image is "compressed enough" by using one or more of those algorithms and predefining the amount of acceptable/tolerable distortion or quality loss. Each of those algorithms has some trade-offs in terms of accuracy and processing time, but it can definitely work for a large set if you find the right settings for your use-case. It is certainly more productive than manually settings the Q-level per image.

Some SaaS such as https://kraken.io do this on JPG images.

[0] https://sourceforge.net/projects/iqa/

Actually this isn't accurate, Kraken.io doesn't use any SSIM-related algorithms, it just blindly applies some standard compression regardless of the image's content.

If you're looking for a tool that really smartly optimizes the images (by using SSIM) that is https://shortpixel.com/online-image-compression

You can use jpegli for better jpeg compression heuristics. It uses custom heuristics that were originally used in JPEG XL, then copied over and further optimized using nelder-mead to minimize distortion metrics (butteraugli and simulacra 2)

a) This is a property of the encoder, not of the image format.

and

b) Like any other video codec-based format, webp overcompresses dark areas in images so no, you can't rely on consistent quality across collections of arbitrary images.

"switched to"? There's no full switch to anything.

Webp has been around for over a decade. AVIF will probably get adoption as a faster rate in my estimation.

WebP was the classic Google “ship the prototype” move - they were hoping Chrome could muscle it through but it delivered only modest compression improvements (10-15% real world - the marketing papers promised 30% based on comparisons to unoptimized JPEGs) but it was missing features and had very primitive software support, making it harder to produce, deliver, or share (when Facebook switched, a common complaint was someone downloading a picture and finding it didn’t work in another app or when they sent it to a friend).

Very few sites pay for so much outgoing image bandwidth to make that compatibility cost lower than a 15% savings.

it's still a version of jpeg that supports transparency, and it's actually well supported (down to ios 14) to use without also having to deliver a fallback format now. it's not as good as it's successors, but if you are chosing one format and care about image size, it's the best choice.

I’m not saying it was terrible but that it took a long time for it to be worth the trouble unless you really needed transparency. It’s only been the last year or so that you could expect to be able to use it for anything non-trivial and not spend time dealing with tools which didn’t support it.

it did, but mostly because safari dragged its feet for years. Thank god they didn't take this long for AVIF (though I would have loved it if they had shipped AVIF in io15, since a bunch of devices won't get ios16)

AVIF works on safari on iOS 15. Open the browser inspector on a blogpost on xeiaso.net and you'll see that it's selecting an AVIF image.

Safari was the least of it - most image processing tools didn’t support it (e.g. PhotoShop got support last year, Microsoft Paint was the year before) or you had to do things like recompile the versions of common tools to add support (again, better now but it takes a while for support to spread through Linux distribution releases), and now you have more security exposure. That was a lot of hassle for very modest compression gains.

AVIF has gone better because it wasn’t based on a video codec which was never really competitive, was developed collaboratively, and didn’t have feature regressions from JPEG. As with tool support, that last matters a lot at many organizations because the edge experience tends to decide things - even if 95% of your usage is boring 8-bit 4:2:0 the institutional memory tends to be shaped by the times you hit something which can’t be used without more work. If it compressed as well as AVIF, more people might have decided WebP was worth it but since it only marginally outperformed JPEG the case was never that strong.

Part of what I meant by “shipping the prototype” was this kind of stuff: someone at Google wanted to find another use for the On2 IP they’d purchased so they tossed it into a 20 year old container format and shipped it. As with WebM, the benchmarks were fast and loose which meant that anyone who replicated them saw substantially lower performance, which is another great way not to build confidence in your format.