Using it in a web-browser 360 panorama viewer enabled pretty substantial latency and storage improvements.
close to 4x iirc.
ditto large "xray" style orthographic images of building scans generated from pointcloud laser scan data.
avif was even better compression for some cases, but seems to take a long time to generate, and less widespread browser support. Will look at jpeg-XL .. but Im guessing it will be a while until it has widespread support
Ecosystem being slow to adopt it is something that can be fixed or improved, but also more importantly (given jpegxl & avif comparisons) are things that will impact any new image format.
Meanwhile annoyances of the codec tend to be things that are dramatically harder to deal with. Like HEIC being a license minefield and also slow as shit. Or that many of these newer image codecs do not have ways to work with them in a memory efficient manner like jpeg does (see eg libjpeg-turbo's sample size & skip scanline options). Or WebP insisted on being in a RIFF container for... uh... absolutely no fucking reason whatsoever afaict. Fortunately RIFF is so trivial that this overhead doesn't actually matter in practice, but then HEIC & AVIF dials up the annoying container bullshit to 11 thanks to their video heritage with ISOBMFF
That is true in life.
EVs aren’t annoying, the charging infrastructure is.
Etc
I appreciate Google isn't a monolith, but that lack of consistency makes it really hard to shake the impression certain tribes within it are at war with each other.
By contrast, when using a modern format like WEBP or AVIF, a single encoder configuration produces decent looking results across a variety of input images.
Especially for animated images. Comparing webp or avif sizes to gif is easily a factor of five to ten when animated.
Go straight to jpeg xl and/or avif when the they are mature.
Many image links that work for search engines don't work for the site and I have to download and then upload to a host to get an embeddable image link.
The other annoying thing is the name, because surprisingly we use images in non-web-related contexts as well. Admittedly, PNG technically has a very similar issue, but it’s less in your face.
I speculate the asymmetric push is a case of it solving Google’s problem (bandwidth cost) but not the end user’s problems (battery and latency).
Even formats like H.264 are being dropped from some hardware decode engines because it’s so easy to do on CPUs now, as can be seen even on the Raspberry Pi 5. Many software stacks will skip hardware JPEG decode even when available because it’s extra maintenance and debugging overhead for such a little gain.
Progressive decode is a feature that is good in theory but rarely used in practice. If you’re concerning yourself with power usage and memory footprints, progressive decode goes in the opposite direction. Users also don’t like progressive decode as much as developers think they will as it’s often perceived as something being broken.
I think WebP made reasonable tradeoffs for the way images are actually used and delivered.
CPU decode efficiency most certainly was not the reason h.264 was dropped on the Pi
Most photo/design apps don't seem to be using SOTA jpeg encoders, though, so I think webp looks better in comparisons like OP's than it actually is. You maintain all the ultra-fast decoding of jpg when you use a modern encoder, too.
It’s not always used when available. It can be a lot easier and safer while being fast enough to do it on the CPU. If the operating system has an image decoder path that will handle everything for you then it might be used (Apple hardware for example) but if you have to go out of your way to implement the API, common software will favor software decoding because nobody wants to maintain code testing branches for different hardware image decode platforms.