For the past two years, I have been exporting my images in WebP instead of JPG. If I share it online or send it by an email, I am pretty sure the other side will be able to see them.
I honestly think that all phones and even professional cameras should replace JPG with WEBP, we will have like 30% smaller photos.
The DNG format (for raw photos) allows JPEG XL compression (it used to allow only JPEG in the past). I wish some country made it mandatory for cameras to let user take photos in DNG (just like USB-C is mandatory in the EU).
I am happy that HEIC from Apple did not take off (as it was proprietary, protected by patents).
So as every time I read something decrying how webp is allegedly "annoying", the conclusion is that the problem was never about webp itself but the tooling and ecosystem to handle it
Is there a real distinction? It can be a great format, but if actually using it sucks then in practice it's a pain to use/encounter. (I don't actually have this problem personally - all my apps seem to handle it fine - but the argument seems reasonable.)
Yes, it's important to distinguish annoyances of the codec from annoyances of the ecosystem.
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
It seems much harder to get an audience as someone complaining about technical details of codecs and their implementations, than as someone complaining about the formats (which in practical terms is always going to mean the ecosystem, or really, how broad the support base is or what the user has to do in order to deal with it).
Perhaps it's a matter of who hits the pain point? Ugly specs make annoyed devs, licensing problems make distributors unhappy, and ecosystem issues leave users unimpressed. (With some spillover between categories, of course.)
I haven't seen much if anything saying webp itself is annoying directly, and your conclusion agrees with what I've seen. The complaining I've seen is about the tooling available (mainly from non-techies who don't care to know how to convert to another image format because, and I agree, why should they?) that once you've got a webp image file from one site the next site you try to upload it to doesn't accept them. For those of us who can convert the tooling has been there for ages, as have editors happy to load and save the format.
Though TBH I still use JPEG, PNG, or GIF, depending on use case, out of habit. The size saving for the same quality of lossy compression is not something I've found myself hankering for. It is different if you run a site that sends out millions of every image, but nothing I do is that popular and is never likely to be, and no one stuck on a really slow connection where the difference would matter to them is going to be accessing my stuff.
Yeah it's purely the fault of the tens of thousands of application devs that have been too stupid to recognize the obvious and immense benefits of webp over existing widely adopted formats /s
Firefox actually silently and automatically converts images to webp in some cases when you Save As them, with no option to revert to the format you see in the DOM. It’s fucking infuriating. I hate webp because the support is so spotty.
I don't think that's firefox doing it? I'd guess it's some CDNs doing the conversion. Or the URL says .jpg but when you look at the mimetype sent by the server it's actually webp. Extentions are meaningless for browsers.
No, the server is just sending the file named 'foo.jpg', but encoded as a webp with webp mime type, so when you save the file it defaults to the webp extension cause it ends up treating the filename as a blob of text without an expected extension for the file type.
Hardware JPEG decode isn’t as valuable on today’s hardware. CPU decode with SIMD instructions is fast and energy efficient. It’s such a negligible part of battery usage that it’s barely worth thinking about for fast modern CPUs.
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.
> 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
CPU decode efficiency most certainly was not the reason h.264 was dropped on the Pi
It also lost much of its quality advantage over plain jpeg, given the improvements in jpeg encoders: the jpegli encoder (from google's jpegxl team) has improved plain jpeg encoding significantly.
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.
JPEG decoding is frequently included in systems with DSP blocks because it’s easy to add to a system that is already doing similar math for video decoding.
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.
I was amazed at how much better compression webp offered over jpg and png.
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
Google aren't pushing WebP. Google Docs / Slides still don't support it.
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.
It's not war, it's indifference. Why should Docs give a damn what Chrome's priorities are? The only reason they would is if there were effective leadership ensuring company-wide alignment, but there is no one filling that function.
Because if they did company wide alignment, you would kill their promotion pipeline. Want harmony? Then in Google you build your own app (see N+1 chat apps) to get that feature, get promoted and dump the project on someone else.
Author here: I'm also very much looking forward to using AVIF (and also JPEG XL), but it's another tooling question. I'm really hoping that Pixelmator Pro (now owned by Apple) will support them both soon. Photoshop (which I've recently dumped) supports WebP and AVIF, but not through the "Save for Web" or "Export As" flows. Having a nice export flow where you can easily compare compression vs. quality levels is really important to me, and I suspect to many others.
When it comes to animations, is there much of a reason to use avif over webm? I suppose an avif fits into CSS and <img> without further code changes, but that's about it as far as I can think.
I just switched to AVIF after several years of using WebP. Main reason for me is HDR support, but the smaller encoding is nice. Just beware of lossless AVIF, that's a trap.
Just as with JPEG2000, I'm still not convinced the additional complexity is worth it. There seems to be a lot of immature technologies being pushed in the past few years, when IMHO the Web should've stabilised long ago on the basics. But I guess people need things to do to keep them employed... and Big Tech needs to maintain its monopolies.
The old JPG/PNG choice had a big problem: JPG handles sharp edges, including text, badly. PNG produces huge photo files. Images containing a mix of both don't work well in either format.
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.
https://squoosh.app/editor is a great app to compare how well an image compresses with newer formats like AVIF and WebP, compared to JPG/PNG.
It feels more practical now to have a fast loading page with large images now without too much effort. It was far too much of a burden before to have to provide fallbacks to older formats, on top of different images for different screen sizes/densities.
One forum I use does not embed webp links. They show up as links, period, and it's a damn waste of my time to convert. Small is beautiful unless your forum is run by two people, not having the time to update code all the time.
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 one annoying thing about WebP is that you can no longer see from the file extension whether some image is lossy or lossless.
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.
Author here: as I wrote in the piece, I've recently dumped Photoshop for Pixelmator Pro. It doesn't currently support AVIF. Photoshop does, but not in a way that makes it easy to optimize an image for web export. JPEG XL is also exciting to me, but it's not generally available across browsers. WebP is the current best image format for my use-case, but I'm hoping others supplant it soon.
>but it's not generally available across browsers.
Note that this is changing rapidly. Safari ships JXL, Chrome did a few days ago, and Firefox will in the next few days. Once this flows through to all the chromium based browsers we will see pretty much 100% support on the web.
I honestly think that all phones and even professional cameras should replace JPG with WEBP, we will have like 30% smaller photos.
The DNG format (for raw photos) allows JPEG XL compression (it used to allow only JPEG in the past). I wish some country made it mandatory for cameras to let user take photos in DNG (just like USB-C is mandatory in the EU).
I am happy that HEIC from Apple did not take off (as it was proprietary, protected by patents).
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
How much slower? I'm finding very conflicting numbers.
But on the timescale of "wow this still doesn't support webp" those patents will solve themselves soon.
Though TBH I still use JPEG, PNG, or GIF, depending on use case, out of habit. The size saving for the same quality of lossy compression is not something I've found myself hankering for. It is different if you run a site that sends out millions of every image, but nothing I do is that popular and is never likely to be, and no one stuck on a really slow connection where the difference would matter to them is going to be accessing my stuff.
That is true in life.
EVs aren’t annoying, the charging infrastructure is.
Etc
That’s the whole point, though. If the tools I use don’t handle it properly, it’s annoying. Saying it’s an ecosystem problem doesn’t change that.
How long has it been now? And from what I’ve seen, even Google’s own stuff doesn’t always handle it. That’s not helping their case.
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.
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
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.
https://www.globalnerdy.com/2011/07/03/org-charts-of-the-big...
Contrast this to, say, Apple - which when decides to push something, they go all in. And that's an example of top-down decision making.
Especially for animated images. Comparing webp or avif sizes to gif is easily a factor of five to ten when animated.
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.
It feels more practical now to have a fast loading page with large images now without too much effort. It was far too much of a burden before to have to provide fallbacks to older formats, on top of different images for different screen sizes/densities.
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.
Go straight to jpeg xl and/or avif when the they are mature.
Note that this is changing rapidly. Safari ships JXL, Chrome did a few days ago, and Firefox will in the next few days. Once this flows through to all the chromium based browsers we will see pretty much 100% support on the web.
[0] https://addons.mozilla.org/en-US/firefox/addon/siat/