WebP has flaws as a format – don’t we all – but I think the commentary should be putting more blame on (1) the industry’s failure to standardize on (and rigorously reviews the implementations of) a single JPEG successor format, given the obvious hunger, and (2) the practice of implementing anything that reads nontrivial untrusted data in a programming language that is not memory-safe.
I’ve been surprised by the number of people popping up with “I always hated webp, the format I can never open properly”. I’m not saying that’s wrong.
But like … wepb is BSD-licensed and, as a lossy image format in the abstract, pretty okay.
The problems are mostly industry silliness (e.g., Apple being halfhearted about it without presenting a better alternative) and the fact that the reference implementation is in The Language Whose Creators Regretted Giving It That Fundamental Security Flaw.
(“JPEG is PERFECTLY FINE and only IGNORANT ASSHOLES want to mess with something that has worked ADMIRABLY FOR THIRTY-ONE YEARS and actually this is THE PROBLEM WITH SOFTWARE TODAY” is also a common point of view. It does not, in my limited experience, survive a thoughtful conversation with someone who pays bandwidth bills, cares about color reproduction, etc.)
This is a fun client-side demo of what the current generation JPEG-replacing codecs can do. Some of them only really shine when you turn the effort slider up. If you spend what would have been an absurd amount of CPU cycles in 1992 on encoding, you can get acceptable quality at itty-bitty sizes. (Try the built-in sample images.) https://squoosh.app/editor
@vruba wow MozJPEG is really impressive.