内容简介:For the testing I used theIn addition to these, ImageMagick was used to scale down the images from the originals and converting between PNG, WebP and TGA (cwebp only supports TGA input). All conversions were done in sRGB color space.For comparing the quali
For the testing I used the Kodak image dataset in 3 different sizes: 500 px, 1000px and 1500px.
- For JPEG conversion I used cjpeg with
--optimize
flag,--progressive
flag and 4:2:0 chroma subsampling. - For MozJPEG conversion I used MozJPEG with
--optimize
flag,--progressive
flag and 4:2:0 chroma subsampling - For WebP I used cwebp with
-m 6
flag for maximum compression and-af
for auto filter which presumably trades encoding time for increased quality. WebP only supports 4:2:0 subsampling so this doesn’t need to be specified separately. - For AVIF I used colorist with flags
--tonemap off
,--yuv 420
and--speed 0
which is the slowest but highest quality encoding
In addition to these, ImageMagick was used to scale down the images from the originals and converting between PNG, WebP and TGA (cwebp only supports TGA input). All conversions were done in sRGB color space.
For comparing the quality I used kornelski’s dssim utility which calculates structural similarity index between images. My target SSIM is 0.0044 which roughly corresponds to JPEG quality of 85.
Results for 500px images
Open comparison in a new window
Here are the results on a graph:
If we look at the median file sizes, we can see that compared to cjpeg, MozJPEG is roughly 11% smaller, WebP is 18% smaller compared and AVIF is 31% smaller at the equivalent SSIM index.
Results for 1000px images
Open comparison in a new window
Here are the results on a graph:
If we look at the median file sizes, we can see that compared to cjpeg, MozJPEG is roughly 11% smaller, WebP is also 11% smaller compared and avif is 28% smaller at the equivalent SSIM index.
Results for 1500px images
Open comparison in a new window
Here are the results on a graph:
If we look at the median file sizes, we can see that compared to cjpeg, MozJPEG is roughly 9% smaller, WebP is the same size as cjpeg and AVIF is 28% smaller at the equivalent SSIM index.
Average for all image sizes
Just for fun, I graphed the averages of all image sizes. I know this might not be a fair comparison but still, here you go:
As you can see, when compared to cjpeg, MozJPEG is about 9% smaller, WebP is 6% smaller and AVIF is 30% smaller.
If you are interested, you can view the raw data for all the images as a spreadsheet here . Source code for the comparison app and raw images are available on GitHub: 500px , 1000px and 1500px . Check the originals directory for the raw images.
Conclusions
Is WebP better than JPEG?
So, is WebP better than JPEG? It depends if you are using the reference libjpeg library or the improved MozJPEG encoder.
WebP seems to have about 10% better compression compared to libjpeg in most cases, except with 1500px images where the compression is about equal.
However, when compared to MozJPEG, WebP only performs better with small 500px images. With other image sizes the compression is equal or worse.
I think MozJPEG is the clear winner here with consistently about 10% better compression than libjpeg.
Since most of the time WebP is used alongside JPEG fallback, by using WebP you will essentially double your storage costs with little benefit. So, in the end, I would recommend using WebP in only the following cases:
- You have a lot of small images in the 500 px range.
- You can’t use MozJPEG.
- You pick an arbitrary fixed quality instead of using a metric like SSIM.
In any case, when converting images to WebP, check that they are actually smaller than the JPEG equivalent. There’s no need to serve larger images to your users than needed.
How do image formats derived from video codecs differ from JPEG?
One notable difference between JPEG encoders compared to WebP (based on VP8) and AVIF (based on AV1) is that it’s pretty easy to see how the latter were derived from video codecs. JPEG compression uses the same quantization factor for each 16x16 “macroblock” so the compression is consistent throughout the image.
WebP and AVIF on the other hand use different compression factors for different parts of the image so while the detailed parts of the image retain their quality, surfaces like skin or the sky which have low detail are “smoothed out”. This is especially noticeable with the red window shutters in this image.
While the bricks in the image look sharp, the doors look almost like they have a “Smart blur” Photoshop filter applied to them.
I think this kind of adaptive compression is a valuable thing to have. Think about a photo with a forest and the sky. A traditional image encoder would have to decide a single compression ratio for the whole image. While it’s good to use a lot of bits for the forest trees with high-frequency detail, they are wasted for the sky with low-frequency detail.
A smarter encoder like WebP or AVIF will be able to process these areas separately to use the available bits efficiently.
Is AVIF the future of image formats?
I think AVIF is a really exciting development and compared to WebP it seems like a true next-generation codec with about 30% better compression ratio compared to libjpeg. Only concern I have is the excessive blurring of low detail areas. It remains to be seen if this can be improved when more advanced tooling becomes available.
Right now the tooling is a bit spotty. Colorist was the only program I found which can reliably encode AVIF files. Encoding AVIF files is also really slow! A big image can take several minutes to encode. I’m using the AOM encoder but rav1e might be faster. Browser support also still in progress. Firefox has AVIF support but it’s behind a flag and it doesn’t seem to read ICC profiles correctly . Still, it’s more browser support than Apple’s "next-gen" HEIF which isn’t even supported in Safari .
I think in the next year or so we might see a radically different landscape. With Chrome on board, we could see supported browsers jump to something like 70% of all browsers which means AVIF would be a pragmatic thing to support in web projects.
Caveats
In this test, I only used photographic images. WebP may be better when compressing graphics, for example, since it supports lossy compression for the alpha channel which PNG and JPEG do not.
I also tested the images in “Web quality” target of 85 so WebP may perform differently in very high or very low-quality settings.
Also, Google’s study used a different program to compute the SSIM values. In my tests, I used the dssim utility which computes multi-scale SSIM in LAB color space while the former seems to use simple SSIM in RGB color space. This means they likely give different results but it’s hard to say which is more accurate.
Edit 21.6.2020
By popular demand, added error bars to the graphs. These represent 25th and 75th percentiles. I also added GitHub links for the comparison app and raw images.
以上所述就是小编给大家介绍的《Is WebP better than JPEG?》,希望对大家有所帮助,如果大家有任何疑问请给我留言,小编会及时回复大家的。在此也非常感谢大家对 码农网 的支持!
猜你喜欢:本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。
Visual C#从入门到精通(第8版)
夏普 (John Sharp) / 周靖 / 清华大学出版社 / 2016-6-1
《Visual C#从入门到精通(第8版)》共27章,结构清晰,叙述清楚。所有练习均在Visual Studio 2015简体中文版上进行过全面演练。无论是刚开始接触面向对象编程的新手,还是打算迁移到C#的C、C++或Java程序员,都可以从《Visual C#从入门到精通(第8版)》汲取到新的知识。迅速掌握C#编程技术。一起来看看 《Visual C#从入门到精通(第8版)》 这本书的介绍吧!