Jyrki Alakuijala 博士,Google, Inc.
Vincent Rabaud 博士,Google, Inc.
最后更新时间:2017 年 8 月 1 日
摘要 - 我们将 WebP 编码器/解码器的资源用量与 PNG 无损模式和有损模式下的资源用量进行了比较。我们使用从网络中随机选择的 12000 张半透明 PNG 图片的语料库,并通过更简单的测量结果来展示性能变化。我们重新压缩了语料库中的 PNG,以便将 WebP 图片与大小优化的 PNG 进行比较。我们的结果表明,在大小和处理速度方面,WebP 非常适合用于在网络上使用 PNG。
简介
WebP 支持无损和半透明图像,因此是 PNG 格式的替代方案。WebP 也支持 PNG 压缩中使用的许多基本技术,例如字典编码、霍夫曼编码和颜色索引转换,因此在最糟糕的情况下,可以实现相似的速度和压缩密度。同时,许多新功能(例如不同颜色通道的单独熵代码、反向参考距离的 2D 局部性,以及最近使用的颜色的颜色缓存)提高了对大多数图片的压缩密度。
在此工作中,我们将 WebP 的性能与使用 pngcrush 和 ZopfliPNG 进行高度压缩的 PNG 图片进行比较。我们使用最佳实践重新压缩了网页图片的参考语料库,并将无损和有损 WebP 压缩与此语料库进行比较。除了参考资料库之外,我们还选择了两张较大的图片(一张是照片图片,另一张是图片),以便进行速度和内存使用情况基准测试。
事实证明,解码速度比 PNG 更快,并且压缩密度比目前的 PNG 格式高 23%。我们可以得出结论,WebP 可以更高效地替代目前的 PNG 图片格式。此外,支持无损 alpha 的有损图片压缩能够进一步提高网站速度。
方法
命令行工具
我们使用以下命令行工具来衡量性能:
cwebp 和 dwebp。这些工具是 libwebp 库的一部分(从头编译)。
实现转化。这是 ImageMagick 软件 (6.7.7-10 2017-07-21) 的命令行工具部分。
pngcrush 1.8.12(2017 年 7 月 30 日)
ZopfliPNG(2017 年 7 月 17 日)
我们使用命令行工具及其各自的控制标志。例如,如果我们引用 cwebp -q 1 -m 0,则表示已使用 -q 1 和 -m 0 标志调用 cwebp 工具。
图片资料库
选择了三个语料库:
单张摄影图片(图 1)。
单张半透明的图形(图 2)
网络语料库:从互联网抓取的 12000 张随机选择的 PNG 图片(无论是否透明)。这些 PNG 图片通过 conversion、pngcrush、ZopfliPNG 进行优化,并会在研究中考虑每张图片的最小版本。
图 1. 摄影图片,1024 x 752 像素。喷火 “Jaipur Maharaja Brass Band”Chassepierre 比利时,作者:Luc Viatour,照片已获知识共享 署名 - 相同方式共享 3.0 未移植许可。点击此处即可找到作者网站。
图 2. 图形图片,1024 x 752 像素。来自 Google 图表工具的拼贴图片
为了衡量现有格式 PNG 的全部功能,我们已使用几种方法重新压缩了所有这些原始 PNG 图片:
每个组件限制为 8 位:转换 input.png -depth 8 output.png
无预测器的 ImageMagick(1):转换 input.png -quality 90 output-candidate.png
带有自适应预测器的 ImageMagick:转换 input.png -quality 95 output-candidate.png
Pngcrush(2): pngcrush -brute -rem tEXt -rem tIME -rem iTXt -rem zTXt -rem gAMA -rem cHRM -rem iCCP -rem sRGB -rem alla -rem text input.png output-candi
ZopfliPNG(3):zopflipng --lossy_transparency input.png output-candidate.png
具有所有滤镜的 ZopfliPNG:zopflipng --iters=500 --filters=01234mepb --lossy_8bit --lossy_transparency input.png output-candidate.png
成果
我们计算了网页语料库中每张图片的压缩密度,并对比了以下三种方法的经过优化的 PNG 图片大小:
WebP 无损(默认设置)
最小的无损 WebP (-m 6 -q 100)
使用 Alpha 版(默认设置)充分发挥 WebP 无损和 WebP 有损效果。
我们对这些压缩因子进行排序,并将它们绘制在图 3 中。
图 3. PNG 压缩密度为 1.0,用作参考。相同的图像使用无损和有损方法进行压缩。对于每张图片,都会计算压缩后 PNG 的大小比率,并对大小比率进行排序,并同时显示无损压缩和有损压缩。对于有损压缩曲线,如果无损压缩会生成较小的 WebP 图片,则选择这种方式。
WebP 的 PNG 压缩密度比 libpng 的最高质量(转换)和 ZopfliPNG(表 1)都更胜一筹,其编码(表 2)和解码(表 3)的速度与 PNG 大致相当。
表 1. 使用不同压缩方法的三个语料库的平均每像素比特数。
图片集 | 转换 -质量 95 | ZopfliPNG | WebP 无损 -q 0 -m 1 | WebP 无损(默认设置) | WebP 无损 -m 6 -q 100 | WebP 有损(使用 Alpha 版) |
---|---|---|---|---|---|---|
照片 | 12.3 | 12.2 | 10.5 | 10.1 | 9.83 | 0.81 |
血腥 : 露骨 | 1.36 | 1.05 | 0.88 | 0.71 | 0.70 | 0.51 |
web | 6.85 | 5.05 | 4.42 | 4.04 | 3.96 | 1.92 |
表 2. 压缩语料库和不同压缩方法的平均编码时间。
图片集 | 转换 -质量 95 | ZopfliPNG | WebP 无损 -q 0 -m 1 | WebP 无损(默认设置) | WebP 无损 -m 6 -q 100 | WebP 有损(使用 Alpha 版) |
---|---|---|---|---|---|---|
照片 | 0.500 秒 | 8.7 秒 | 0.293 秒 | 0.780 秒 | 8.440 秒 | 0.111 秒 |
血腥 : 露骨 | 0.179 秒 | 14.0 秒 | 0.065 秒 | 0.140 秒 | 3.510 秒 | 0.184 秒 |
web | 0.040 秒 | 1.55 秒 | 0.017 秒 | 0.072 秒 | 2.454 秒 | 0.020 秒 |
表 3. 使用不同的方法和设置压缩的图片文件的三个语料库的平均解码时间。
图片集 | 转换 -质量 95 | ZopfliPNG | WebP 无损 -q 0 -m 1 | WebP 无损(默认设置) | WebP 无损 -m 6 -q 100 | WebP 有损(使用 Alpha 版) |
---|---|---|---|---|---|---|
照片 | 0.027 秒 | 0.026 秒 | 0.027 秒 | 0.026 秒 | 0.027 | 0.012 秒 |
图形 | 0.049 秒 | 0.015 秒 | 0.005 秒 | 0.005 秒 | 0.003 | 0.010 秒 |
web | 0.007 秒 | 0.005 秒 | 0.003 秒 | 0.003 秒 | 0.003 | 0.003 秒 |
内存性能分析
对于内存性能分析,我们记录了 /usr/bin/time -v 报告的最大常驻大小
对于网络语料库,最大图片本身的大小便决定了最大内存使用量。为了更好地定义内存测量,我们使用单张照片(图 1)来概述内存使用情况。下图给出了类似的结果。
我们在设置 -q 0 -m 1 和 -q 95(默认值为 -m)中测量了 libpng 和 ZopfliPNG 的 10 到 19 MiB,WebP 无损编码的测量尺寸分别为 25 MiB 和 32 MiB。
在解码实验中,对于 libpng 和 ZopfliPNG 生成的 PNG 文件,将 -resize 1x1 转换使用 10 MiB。如果使用 cwebp,WebP 无损解码使用 7 MiB,有损解码使用 3 MiB。
总结
我们发现,编码和解码速度与 PNG 处于同一网域。编码阶段的内存使用量增加,但解码阶段的下降幅度是正常的,至少在将 cwebp 的行为与 ImageMagick 转换的行为进行比较时,是如此。
这种压缩密度对超过 99% 的网页图片的压缩密度更高,这表明可以相对轻松地从 PNG 更改为 WebP。
当使用默认设置运行 WebP 时,其压缩率比 libpng 高 42%,比 ZopfliPNG 压缩高 23%。这表明,WebP 有望为包含大量图片的网站提速。
参考
外部关联
以下这些是并非由 Google 赞助的独立研究,Google 不保证其所有内容的准确性。