11 ms·
Every time I run an image comparison, the webp version looks worse and yet Google insists it's the same quality. It's baffling. Even if the above were just an
by gruturo 6y ago
Every time I run an image comparison, the webp version looks worse and yet Google insists it's the same quality. It's baffling.
Even if the above were just an individual... bafflement? and not an actual issue, the size savings really don't seem worth the compatibility hassle, the extra manpower/workflow complexity to support 2 formats, the additional storage (and caching) caused by this duplication.
And the above is if it's done RIGHT. 80% of people outside this forum won't understand that you're not supposed to convert from a lossy format to another, and just convert jpegs to webp.
Webp seems so pointless. A progressive jpeg with an optimized Huffman table can be understood by a 27 year old decoder without issues, achieves 90% of the quality/size claims of webp and can be produced losslessly from your source jpegs. This is without even touching Arithmetic Coding (also lossless, part of the official standard, but poorly supported due to some software patents, even though they all expired by now), or playing with customized DCT quantization matrices to get more compressible outputs (incurs a generation loss, but produces standard files).
- ksec 6y agoAnd that is the reason why I dont like Open Media Alliance in General. Not only does the best JPEG encoder perform as good if not better than the best WebP encoder. With a JPEG Repacker [1] JPEG file size could easily be 20% smaller. If you have to support a new format with relatively little benefits, why not just support using the repacked instead. [1]https://github.com/google/brunsli https://github.com/google/brunsli
- gruturo 6y agoAbsolutely. Simply unscrewing the Huffman stage from the bottom of JPEG and replacing it with a more effective, modern lossless stage kills webp's gains and does not incur in generation loss - the image is pixel accurate to the source jpeg. You'll probably know this already, but Brunsli made it into the JPEG XL standard. I'm quite happy about it!
- jerryX 6y agoJPEG XL uses this new ANS coding as e.g. zstd: https://en.wikipedia.org/wiki/Asymmetric_numeral_systems https://en.wikipedia.org/wiki/Asymmetric_numeral_systems
- chrismorgan 6y agoWhat has AOMedia to do with this? That alliance is what has made AV1 (and thus AVIF), which is clearly superior to JPEG. AOMedia had nothing to do with WebP (though Google is a member, and WebP is based on VP8, and AV1 is based in part on VP9 which was the successor to VP8).
- ubercow13 6y agoIs it better? The AVIF examples in the article look even worse than the WebP ones
- 9OzUIvDwF4LvfUM 6y agoDo you mean the Alliance for Open Media? WebP was created solely by Google years about AOM was founded.
- SiVal 6y agoI thought the JPEG people were supposed to have JPEG XL [1] out by now, and it was supposed to be the open standard for JPEG's next generation. Anyone know what's happening there? [1] https://en.wikipedia.org/wiki/Joint_Photographic_Experts_Group#JPEG_XL https://en.wikipedia.org/wiki/Joint_Photographic_Experts_Gro...
- jonsneyers 6y agoYes, here's an update: https://cloudinary.com/blog/how_jpeg_xl_compares_to_other_image_codecs https://cloudinary.com/blog/how_jpeg_xl_compares_to_other_im... TL;DR: We're now at "Draft International Standard" stage; soon we'll enter "Final Draft International Standard" stage and at that point the bitstream is effectively frozen and adoption can start. The officially ISO-published International Standard will take until first half of 2021, but the codec should be ready to use before that.
- JimDabell 6y agoYou can argue the toss over quality, but JPEG can't do transparency while WebP can. So if you need transparency, you need to compare the size savings to PNG, not JPEG. WebP is the clear winner there.
- moring 6y agoIf transparency was the main issue, adding transparency to JPEG sounds easier than coming up with a completely new encoding, especially a lossy one.
- agumonkey 6y agoclearly we need to dig in past work to find who tried that
- asjw 6y agoFlash could do it
- TylerE 6y agoHow? Do you know how many binaries link to some old version of libjpeg? You're breaking 99.9% of the world and 80% of it is stuff that can't even be recompiled, probably. In fact, JPEG 2000, which was standardized, in, well, 2000, already has transparency support, and 20 years later still have no meaningful support.
- moring 6y agoAll that is true for WebP too, isn't it? If you cannot recompile a piece of software, how are you going to add WebP support to it? And you aren't breaking it. In a theoretical world where transparency got added to JPEG, software that doesn't support it will show a fully opaque JPEG (adding transparency in a backwards compatible way isn't rocket science). Compare that to using WebP instead, where software that can't handle it won't even show the image.
- tedunangst 6y agoAnd then there's times I want to save an image, and can't convince the web site to give me a jpeg, so I have to convert it again.
- gsich 6y agoI also don't get it why people insist on the same quality with lesser size. How about more quality and the same filesize?
- MaxBarraclough 6y ago> people insist on the same quality with lesser size. Because a great proportion of people browsing the web have slow connections and/or data caps. > How about more quality and the same filesize? We're already able to get acceptable quality.
- gsich 6y ago>Because a great proportion of people browsing the web have slow connections and/or data caps. That doesn't matter one bit. See "webpages are doom". >We're already able to get acceptable quality. Apparently not when some examples are worse.
- Narishma 6y agoMaybe it's just me but I couldn't tell the difference between the comparison images in the article without zooming in a bunch.
- TylerE 6y agoPNG already exists.
- leadingthenet 6y agoThe answer is simple: money
- DavidSJ 6y agoIf you can get one then you can get the other, for any compression format that allows varying compression ratios.
- jandrese 6y agoBecause the files already looked fine for the most part. Assuming the JPEG is sensibly encoded the human eye probably won't be able to detect the quality improvements in a different algorithm. So the only place they can target is where JPEG starts to break down: When you've cranked the quality knob down to 20 and you're seeing macroblocks and other artifacts in the image. But this is a niche use case as network speeds continue to improve every year. The worst part is that they have to compete with free, and that's never easy, especially if you're talking about "well, it's still distorted, but the distortion is less displeasing to the eye", also you need to configure some pain in the ass licensing system and work out how to do the payments.
- rokweom 6y agoIt's the same situation with VP9. It's supposed to be a competitor to HEVC, but in reality lack of serious psychovisual optimizations in any of the publicly available encoders make it at best on par with x264 compression-wise, while being significantly more computationally expensive. Its only appeal is that it's royalty-free, but since all devices that support VP9 decoding also support h.264, is it really worth it?
- vernie 6y agoUsing VP9 recently has really made me appreciate how great x264 is both in terms of quality and speed.
- pseudosavant 6y agoThe quality of encoders have a much bigger effect on whether or not a codec is 'good' or not. LAME, mozjpeg, and x264 are great examples. MP3 is competitive with AAC and far more compatible, if you use LAME. Same with JPEG and WebP, or x264 and VP9. All 3 of those encoders deliver higher quality AND better encoding speed than their competitors. Switch encoders before you switch formats.
- basilgohar 6y agoYou are comparing an encoder (x264) with a format (VP9). While there is a reference encoder for VP9 (libvpx). x264 has been one of the most heavily optimized encoders whose development was sponsored by many different organizations, whereas libvpx did not see the same kind of love and most of the work came from Google's employees (with some from outside, I'm sure). There exist other VP9 encoders, but all for specialized purposes.
- jbk 6y ago> x264 has been one of the most heavily optimized encoders whose development was sponsored by many different organizations No, it did not. > whereas libvpx did not see the same kind of love and most of the work came from Google's employees. You're getting your facts wrong: x264 was developed by a very small open source community, with at most 5 developers on it, on their free time, while libvpx got quite a few people from Chrome Media Team paid to work for years on it.
- baxtr 6y agoWhat’s interesting is that Google’s Lighthouse tool for measuring site speed pushes for “Next Gen” image formats like WebP. But I often find that WebP files are larger than jpg, too. Yet Lighthouse recommends it. And, of course it’s a great idea to follow Google’s advice since they include the Lighthouse score in their ranking algorithm.
- gsnedders 6y ago> And, of course it’s a great idea to follow Google’s advice since they include the Lighthouse score in their ranking algorithm. AFAIK they don't? They use some of the metrics which are provided in Lighthouse (Largest Contentful Paint, First Input Delay, Cumulative Layout Shift) all play a role in ranking, but the score itself is meaningless.
- hoten 6y agoYou're both wrong, but you're only slightly wrong. It's been announced that those metrics will contribute to ranking in the bear future. Search for Core Web Vitals.
- gsnedders 6y agoYou are, of course, technically correct, which is the best type of correct. There's been some level of performance weighting for a while (but only very slight and mobile-only), but I don't actually know what metric they were using for that (this was from ~2018, before any of those metrics landed in Blink).
- 72deluxe 6y agoThe irony is that the Lighthouse site itself scores really badly! Can you accept its advice?
- innocenat 6y agoIdk. I optimized the end-user facing part of my website heavily, while the backend part (which is used only by a few people), I don't really care. I didn't even minify the JS.
- viluon 6y ago> Every time I run an image comparison, the webp version looks worse and yet Google insists it's the same quality. It's baffling. Could you share your comparisons? From the ones I've seen, it looks like WebP significantly outperforms JPEG encoders[0]. [0]: https://wyohknott.github.io/image-formats-comparison/#endeavour-with-columbia*3:1&jpg=s&webp=s https://wyohknott.github.io/image-formats-comparison/#endeav...