WebP is obsolete. It's still based on VP8 codec, which in video has been replaced by VP9 long time ago. AVIF is based on AV1, which is a successor to VP10. So WebP is a few generations behind in the VPx lineage, and is no match for modern codecs.
AVIF was a quick hack originally by Netflix by placing an AV1 frame into a HEIC container. I believe it was done in a few weeks of work.
AV1 was largely based on VP9/VP10 and was developed by a team working in Chrome organization.
JPEG XL main mode (VarDCT) and the JPEG recompression is largely developed by Google Research.
WebP as a format was based on VP8, a video codec built by On2 Technologies. On2 was bought by Google in 2010 -- a year before Google published WebP. The transparency and lossless encoding as well as non-video keyframe-by-keyframe animation were designed at Google. The On2 VP8 codec used initially in WebP lossy was not that suitable (too many artefacts) for photography transmission. Jeff Muizelaar wrote a great blog post about this. The codec for WebP were redesigned (without format) changes at Google, and kept improving significantly until around 2015 when it reached pretty good maturity.
(Personally, I don't like what it does to highly saturated dark colors, such as dark forests or dark red textures, but it is much much better than it was.)
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)
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.
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.
> 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.
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.
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)
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.
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.
