31–40 of 61 posts
The age is never the prime characteristic of a technology, only collateral in many of the circumstances, but far from for all. Emphasizing modernness or freshness is a bit superficial and childish.
There are many better comparisons on the internet, with much better examples and metrics.
Safari on iOS added support for webp in iOS 14, in late 2020. Before that version reached widespread adoption you would have needed a jpeg fallback for your webp images.
AVIF is still not universally supported.
The non-browser support of WebP is just bad. I hate website using WebP, because, when I save them, I have a hard time editing them.
I've got several hundreds of GB of unused SSD storage, and I'm downloading it over a 1Gbps connection. Honestly, I really could not care less about those 150KB I'm saving.
Just for fun, I downloaded the wbep in the article to my desktop to check non-web comparability and found something strange. For usability reasons, I still use Windows Photo View from the XP days on my modern Windows 11 computer. After loading it up there, I noticed that the webp image is viewable but decodes very differently than other applications. For comparison, I included the image as Firefox sees it, as the nat…
And because of that school of thought, about 20% of all sites I visit are currently broken for me. I'm still on macOS Catalina, which is the last somewhat bearable version of macOS, but which has no webp support in Safari.
Even pages which pretend to specify JPG fallbacks via srcset and the like do not, because the JPG endpoints return webp anyway.
The non-browser support of WebP is just bad. I hate website using WebP, because, when I save them, I have a hard time editing them.
We need a website like caniuse.com that tracks support for file formats on operating systems and software. I would be interested to see the support of WebP out of the box on Windows 11, macOS, Ubuntu, stock Android, iOS, the GIMP, Adobe Photoshop, and so on.
An image codec comparison that doesn't include JPEG XL.
https://caniuse.com/avif - 87% penetration. JpegXL have about zero (actually 5% - safari). So, in practice, you can't use it
I am trying to minimize using things originating from Google.
Earlier quoted context omitted.
If that's indeed true, there is no point to compress an image that is larger than a target viewport---any larger image can be scaled down on encoding and upscaled on decoding. But all formats mentioned easily support much larger images.
When I said "This isn't what any lossy formats are designed for", I meant on the web, which I thought was the context with the article and all. And then there is indeed little point of uploading images to a web server that is far larger than viewports. I also still maintain that lossy formats aren't designed to manage users zooming into textures and trying to find out compression artifacts and wavelet caused softenin…
And even so, it is utterly unclear to me how lossy image formats can be designed "for the web" in the way you have described. I will probably expect a good progressive decoding support and possibly animation, but that's all. Otherwise it's a good old psychovisual optimization under specific viewing conditions, and it is much debatable which viewing conditions represent the web environment.
> I also still maintain that lossy formats aren't designed to manage users zooming into textures and trying to find out compression artifacts and wavelet caused softening of power lines.
Which is a fair point but WebP at the lower quality does show significant enough artifacts visible without zoom for ordinary displays. Mobiles with higher pixel density in a constrainted form factor do matter, but you can't ignore ordinary displays in your file format solely for that reason.