It's the future – you can stop using JPEGs

From what I can tell, the author is focusing a bit too much on numbers, but is unsure why these alternatives haven&#x27;t gained widespread adoption.<p>The comparison photo isn&#x27;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&#x27;d not want my photos created, converted, or displayed in that format.<p>But numbers aside, the main reason is because JPG is &#x27;good enough&#x27;. It&#x27;s the same reason that old protocols like FTP and SMTP still hang around, why customers still want CSVs&#x2F;Excels over Parquets. If a thing is good enough, it will hang around for a very long time because there&#x27;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 &#x27;workarounds&#x27; like CDNs, even the development teams have little incentive to look for savings here (for now).<p>There will be hundreds of workflows built around JPG&#x27;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 &#x27;in the field&#x27; for decades.<p>Additionally it&#x27;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&#x27;s compatible on all desktop OSes, and through tooling like GIMP, Photoshop, Affinity, exiftool, ffmpeg, imagemagick, etc.<p>It&#x27;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&#x27;s a .webp or .jpg.

I encourage everyone to click the images and zoom in on them. The test itself is pretty flawed since the images probably all came from the jpeg in the first place (and if they didn&#x27;t, then that&#x27;s pretty damning to the non-jpeg options, in my opinion).<p>The place I found the most interesting is the dark, top of the screen. Zoomed to 240% and looking at the top area, especially where the power lines are going across, there&#x27;s a very, very clear difference in quality between even the 95% jpeg and webp, and in my opinion, the jpeg wins for being more honest. That difference is more stark at the 65% compression option.<p>Is that difference worth the larger size? That&#x27;s up for each of us to decide as we choose our technology; but, those images are very different from my perception.<p>Caveat: I&#x27;ve used Firefox to render them, which may have different results than Chrome, perhaps.

An image codec comparison that doesn&#x27;t include JPEG XL.

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.

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?<p><a href="https:&#x2F;&#x2F;imgur.com&#x2F;a&#x2F;inom1D0" rel="nofollow noreferrer">https:&#x2F;&#x2F;imgur.com&#x2F;a&#x2F;inom1D0</a>

I give some leeway before passing judgement, but this article is not very good. It uses one single photo, a bad one at that, picks some arbitrary percentages that don&#x27;t mean the same thing for all formats and in the end the only message is that &quot;progress is happening&quot;.<p>There are many better comparisons on the internet, with much better examples and metrics.

It would be nice if the author would add mozjpeg[1] to the comparison. At certain image resolutions, it can produce smaller file sizes than WebP, and because it is still a jpeg, it has a much better compatibility story, which the author alluded to.<p>[1]<a href="https:&#x2F;&#x2F;github.com&#x2F;mozilla&#x2F;mozjpeg">https:&#x2F;&#x2F;github.com&#x2F;mozilla&#x2F;mozjpeg</a>

Great advice but... really should have picked another picture. A night shot on a phone camera is going to be heavily postprocessed, it&#x27;s grainy... just not the best demonstration of the tech

WebP produces visible artifacts at compression levels comparable to JPEG:<p><a href="https:&#x2F;&#x2F;eng.aurelienpierre.com&#x2F;2021&#x2F;10&#x2F;webp-is-so-great-except-its-not&#x2F;" rel="nofollow noreferrer">https:&#x2F;&#x2F;eng.aurelienpierre.com&#x2F;2021&#x2F;10&#x2F;webp-is-so-great-exce...</a><p>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.

I think the article assumes that JPG 65, WebP 65 and AVIF 65 all produce same quality which is not necessarily true.

Jpegli will lift traditional JPEG compression density by 25–30% and support 10+ bit HDR within the backward compatible 8 bit formalism. Jpegli is based on porting jpeg xl encoding strategies back to old jpeg. It is a whole new reimplementation, instead of tweaking old libs such as libjpeg, libjpeg-turbo or mozjpeg. Jpegli is API and ABI compatible with its usual alternatives like three mentioned before.

1MB club, yeah, that triggered me.<p>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&#x27;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?<p>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&#x27;s a grid that blinks now and then, especially when those buttons &quot;restaurants&quot;, &quot;hotels&quot; etc.<p>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.<p>Google could substantially reduce the maps servers&#x27; load, and the network load, but their &quot;top talent&quot; programmers just made it heavyweight and ugly by design. They&#x27;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?<p>Look at the enormous amount of requests to www.google.com&#x2F;log204 and &#x2F;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!)<p>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.

&gt; In fairness, it wasn’t practical to use even with a fallback until around 2015 and only became usable without a fallback in the last 2-3 (ish?) years.<p>And because of that school of thought, about 20% of all sites I visit are currently broken for me. I&#x27;m still on macOS Catalina, which is the last somewhat bearable version of macOS, but which has no webp support in Safari.<p>Even pages which pretend to specify JPG fallbacks via srcset and the like do not, because the JPG endpoints return webp anyway.

That dark blurry photo can be compressed at 10% without any meaningful loss of quality.

I never see the point of giving an argument for replacement, even just as a title, on the basis of being old. It is good that inside there are functional arguments but the title should reflect that too.<p>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.

Would be interesting to see how all those jpegs fared if run though ECT (<a href="https:&#x2F;&#x2F;github.com&#x2F;fhanau&#x2F;Efficient-Compression-Tool">https:&#x2F;&#x2F;github.com&#x2F;fhanau&#x2F;Efficient-Compression-Tool</a>). I’ve found it can save a surprising amount of space sometimes.

Worth mentioning that it&#x27;s only been &quot;the future&quot; for a little less than 3 years.<p>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.<p>AVIF is still not universally supported.

&gt; 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.<p>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).

&gt; An overview of some compelling alternatives.<p>The story lost me at the subtitle--I&#x27;ll wait until there&#x27;s one. Seriously though if a very large part of your company&#x27;s cost or user experience depends on efficiently rendering quality images, then this should be on your reading list.<p>For the vast majority, choosing the nearly-right image dimensions and compression level is probably going to do a lot more than choosing any format over jpeg.

Years ago when I was tight on disk space I converted my photos all to jpeg2000 to save space. I&#x27;ve regretted it ever since, as I&#x27;ve permanently lost resolution of my personal photos of friends and family, and some turn out to be completely lost.<p>For web pages, you can just turn up the jpeg compression on photos, and use pngs for constructed images with hard edges.

Would be interesting to know if there&#x27;s any increase in CPU battery (power) consumption to render these different formats too?

PSA: Safari still doesn&#x27;t support HDR AVIF, more than a year after it was reported: <a href="https:&#x2F;&#x2F;bugs.webkit.org&#x2F;show_bug.cgi?id=245858" rel="nofollow noreferrer">https:&#x2F;&#x2F;bugs.webkit.org&#x2F;show_bug.cgi?id=245858</a>

Apart 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.

I wish .net standard libraries would support anything else but they are frozen in time to the early 2000s (at least on .net framework full).

webp is perfect for serving images but not perfect as a source. jpeg at 100% quality is less lossy than webp lossy version. webp lossless is fine, but then not very small. taking photos at 100% jpeg can be a good middle ground for that reason, unless you really dont care about the quality.

email support for anything other than jpg and gif is pretty sparse.