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 native Windows 11 Photos app sees it, and as the XP-era Photo Viewer sees it. Notice that Photo Viewer is darker and with what looks like messed up HSL saturation values. Why would it do this, instead of just not displaying the file at all?
It's the future – you can stop using JPEGs
21–30 of 61 posts
Re: It's the future – you can stop using JPEGs
#22From what I can tell, the author is focusing a bit too much on numbers, but is unsure why these alternatives haven't gained widespread adoption.
The comparison photo isn't great. Even my pedestrian eyes are able to tell that the Webp and Avi conversions result in poorer photos (most glaring example is the tree in the background), so immediately I'd not want my photos created, converted, or displayed in that format.
But numbers aside, the main reason is because JPG is 'good enough'. It's the same reason that old protocols like FTP and SMTP still hang around, why customers still want CSVs/Excels over Parquets. If a thing is good enough, it will hang around for a very long time because there's no compelling reason to move away from it. Considering the bloat that websites already present to the user, and the general lack of attention to bandwidth savings in the development stage, AND the existence of 'workarounds' like CDNs, even the development teams have little incentive to look for savings here (for now).
There will be hundreds of workflows built around JPG's capabilities as well, right from how cameras take the photos, embed metadata into it, how tools read that metadata. Think of embedded devices and webcams that produce images, which will be running 'in the field' for decades.
Additionally it's not just about browser support, which is a very limited way of considering it. For people working with those image types, they will want to know if it's compatible on all desktop OSes, and through tooling like GIMP, Photoshop, Affinity, exiftool, ffmpeg, imagemagick, etc.
It'll probably be a good number of years before there is widespread adoption that enable those workflows, at which point we (hopefully) no longer have to care whether it's a .webp or .jpg.
Re: It's the future – you can stop using JPEGs
#23Earlier quoted context omitted.
> Zoomed to 240% and looking at the top area This isn't what any lossy formats are designed for. How much do the lossy spots stick out when viewed in a cursory glance without zooming from a normal viewing distance? This is what lossy formats are designed for.
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 softening of power lines. We have lossless compression for this and in this regard, WebP is actually surprisingly powerful, far far more so than PNG.
Re: It's the future – you can stop using JPEGs
#24Just 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…
Looks like a lack of color correction/Gamma profile stuff in XP’s viewer.
Re: It's the future – you can stop using JPEGs
#25The 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.
Re: It's the future – you can stop using JPEGs
#26Apart from being a single sample of a low quality photo to start with. The WebP seems noticeably softer at 100% viewing, especially textures on the wall and some faces.
Re: It's the future – you can stop using JPEGs
#271MB club, yeah, that triggered me.
Try to open Google Maps, or any Google product webpage for that matter. In Maps, just get to a chosen place and repeatedly zoom in to the maximum and then zoom out to see a few countries (or US states). The best is to click on + and - buttons so that you're sure the area and zoom ratio is the same. Observe network requests. Many requests are in range 1-20 bytes, but they send 800 bytes in request headers and cookies. Cookies? Really? For a static image (map tile) or a supporting JSON? Do they have to be that long? Are those requests really necessary?
Also look at the length of URL. Is it really required to send that much crap? And there are thousands of those requests, only some of them get cached. And there's a grid that blinks now and then, especially when those buttons "restaurants", "hotels" etc.
Compare that to OpenStreetMap which is way leaner and smoother (and now, after changing maps color scheme by Google, much nicer and more professionally looking), and works flawlessly with Firefox, too.
Google could substantially reduce the maps servers' load, and the network load, but their "top talent" programmers just made it heavyweight and ugly by design. They're against all web best practices they require others to follow. Is all that crap required to spy users, or is it because of their programmers are way overrated?
Look at the enormous amount of requests to www.google.com/log204 and /gen_204. There can be several of them for one display of map in a specific place at a specific zoom rate. Each of them is about 680 bytes, of which 500 is the GET request, rest is headers (+ cookie, of course!)
And I need to mention that my mobile data transfer plan gets depleted much faster than it could have if this product was properly developed (yeah I often use maps on my laptop with mobile internet plans). Not everybody sits in a colorful office having 1- or 10Gbps fiber internet connection and nicely stuffed microkitchen.
Re: It's the future – you can stop using JPEGs
#28> Regardless of whether AVIF ends up being better than WebP, it’s clear that there are viable alternatives you can use today that are massive improvements over JPEG.
Friendly reminder that there is JPEG-XL which is arguably better for all cases than WebP and AVIF (and also supports progressive decoding!). Unfortunately Google (who have a vested interest in WebP and AVIF), are actively hostile towards supporting it and have outright lied about their reasoning (stating lack of interest despite thousands of developers and market-leading corps saying otherwise).
Re: It's the future – you can stop using JPEGs
#291MB club, yeah, that triggered me. Try to open Google Maps, or any Google product webpage for that matter. In Maps, just get to a chosen place and repeatedly zoom in to the maximum and then zoom out to see a few countries (or US states). The best is to click on + and - buttons so that you're sure the area and zoom ratio is the same. Observe network requests. Many requests are in range 1-20 bytes, but they send 800 by…
>>(and now, after changing maps color scheme by Google, much nicer and more professionally looking
I'm glad I'm not the only one who finds the new colour scheme for Google maps horrendous.
Re: It's the future – you can stop using JPEGs
#30WebP produces visible artifacts at compression levels comparable to JPEG:
https://eng.aurelienpierre.com/2021/10/webp-is-so-great-exce...
As Aurélien points out, if you fixate on a bunch of metrics without actually caring about the professional applications, the outcome will look... amateurish.