最有效地使用PNG之续篇:Zopfli优化

原文作者:Jeff Atwood

2007年,我写过一篇文章介绍使用PNGOUT来产生非常小的PNG图片。我仍然经常提起这个话题,因为8年后的今天,我随便在网上看到的PNG图片很有可能是未经优化的。

举个例子,来看看pbfcomics.com上最近发布的这张卡通图:

最有效地使用PNG之续篇:Zopfli优化_第1张图片

把图片从网站直接保存下来,我们发现,这幅漫画是800 x 1412、32位的PNG图像,文件大小为671012字节。让我们把它保存为几种不同的(无损)格式,来看一看这幅图像要占用多少空间:

  • BMP,24位                     3,388,854
  • BMP,8位                        1,130,678
  • GIF,8位,无抖动                147,290
  • GIF,8位,最大抖动           283,162
  • PNG,32位                      671,012

PNG表现不错,因为它像GIF一样采用了压缩算法;与GIF不同的是,你的图像位深不会被限制在令人不快的8位(256色)。现在,我们用PNGOUT(点击这里下载)来处理一下,看看情况会怎样?

  • 原始的PNG           671,012
  • PNGOUT               623,859                 7%

随便从哪里拿来一个PNG,用PNGOUT处理一下,你很可能获得大约10%的文件大小缩减,也许还能更多。记住,这是无损压缩!输出的图像质量是完全相同的。在网上传输的文件会变得更小;而且文件越小,解压缩就越快。同学们,这是免费带宽啊!还有比这更好的事吗?

嗯,还真有……

2013年,谷歌推出了一种完全向后兼容新算法,他们称之为Zopfli:

Zopfli产生的输出通常比zlib在最大压缩比的情况下还要小3~8%。我们相信,Zopfli代表了Deflate压缩算法的当前工艺水平。为了可移植性,ZopfliC语言写成。这个库只支持压缩;现有的软件都能对它解压缩。ZopfligzipZipPNGHTTP请求等使用的压缩是位流兼容的。

非常抱歉,这个情况我了解得太晚了!还是让我们来验证一下他们的大胆狂言吧。拿上面这幅图片来试验,会发生什么呢?

  • 原始的PNG           671,012
  • PNGOUT                       623,859                 7%
  • ZopfliPNG                     585,117   13%

看起来不错啊!不过,那只是一张图片。在discourse.org上,我们都喜欢用表情图片。让我们试试第一版表情Emoji One——那是一整套64 x 64、32位的842个PNG文件:

  • 原始的PNG           2,328,243
  • PNGOUT               1,969,973             15%
  • ZopfliPNG             1,698,322         27%

哇,此等好事,我岂能错过!

在我的测试中,Zopfli处理过的PNG图像总能比PNGOUT小3~8%,尽管PNGOUT已经非常强大了——这真是令人难以置信的成就!而且,任何使用标准gzip压缩的资源都能从Zopfli获益,比如jQuery:

最有效地使用PNG之续篇:Zopfli优化_第2张图片

我们再来看一看各种标准的压缩测试:

测试素材

gzip -9

kzip

Zopfli

Alexa 10k

128mb

125mb

124mb

Calgary

1017kb

979kb

975kb

Canterbury

731kb

674kb

670kb

enwik8

36mb

35mb

35mb

 (奇怪得很,我之前都没有听说过kzip。事后证明,那又是我们的老朋友Ken Silverman的杰作。他也许使用了跟PNGOUT工具一样的压缩技巧。)

不过,有一个问题,因为问题总是有的——它同时也慢80倍。不,我没有搞错。你也没看错!

  • gzip -9                        5.6s
  • 7zip mm=Deflate mx=9         128s
  • Kzip                     336s
  • Zopfli                          454s

Gzip压缩一般比上表里的速度还要快一点,因为第9级是比较慢的:

 

时间

大小

gzip -1

11.5s

40.6%

gzip -2

12.0s

39.9%

gzip -3

13.7s

39.3%

gzip -4

15.1s

38.2%

gzip -5

18.4s

37.5%

gzip -6

24.5s

37.2%

gzip -7

29.4s

37.1%

gzip -8

45.5s

37.1%

gzip -9

66.9s

37.0%

你看吧,为了获得gzip -7和gzip -9之间那区区0.1%的压缩比差异,是否值得花上双倍的CPU时间呢?再说开一点,这也是为什么几乎所有的压缩工具的“极端”压缩级别或模式通常都不靠谱。你从算法悬崖边上快速掉了下去,因此你须待在曲线的中间或者最理想的位置,这常常就是缺省的压缩级别。他们选择那些缺省参数总是有原因的。

PNGOUT也不快,别急着用它;想象一下为了压缩一幅图像或一个文件会慢80倍的(这还是好的情况!),这肯定让人望而却步。如果只是处理小图片,你可能注意不到这个问题。但如果PNG比较大,你基本上可以出去吃一个三明治;或者如果你有一个多核CPU,处理完PNG的时间够你吃4~16个三明治。这也是为什么使用Zopfli来处理用户上传的图片可能是不明智的,因为第一台尝试用Zopfli处理10k x 10k PNG图片的服务器会掉入绝望的深渊。

然而,请记住解压缩的速度是一样的,并且绝对安全。这意味着你可能只想用Zopfli处理一些可以预处理的资源,也就是说,压缩一次,然后用于几百万次的下载场景——这跟你的用户上传一些PNG图片,不管你对这些图片做何等的优化,可能最多也只会被浏览几百次或几千次的应用场景是不同的。

举个例子吧。在discourse.org,我们有一个默认头像渲染器,可以为用户基于他们的用户名里的第一个字母产生一个很好看的PNG格式的头像,并且根据用户名的哈希值选定一种颜色。噢,对了,我们还用了很漂亮的来自谷歌的开源字体Roboto。

最有效地使用PNG之续篇:Zopfli优化_第3张图片最有效地使用PNG之续篇:Zopfli优化_第4张图片最有效地使用PNG之续篇:Zopfli优化_第5张图片

我们在输出头像图片的优化上花费了很多时间,因为这些头像会被使用几百万次。基于这些约束条件:

  • 10个数字
  • 26个字母
  • 大约256种颜色
  • 5种大小

预先把这些头像生成出来就是45000个文件,也并不是毫无道理。我们还有一个所有discourse.org实例都能访问的中央https CDN,需要的话也可以用于部署这些头像图片,这样可以进一步减小负载、提高缓存命中率。

因为这些图像都是单色的,为了节省空间,我把调色板降低到了8位(实际上用了128种颜色)。当然,我用PNGOUT优化处理了这些文件。它们差不多已经小到极限了。当我对这些头像文件执行Zopfli时,我超级兴奋,因为我期望看到3~8%的文件大小缩减。不过,在处理命令执行完之后,我看到的是……分别省了1字节、5字节、2字节……我有点忧伤!

(没错,生成“有损的”PNG图像在技术上是可行的,尽管有点奇怪,但我想那样有悖于PNG的精神——它就是为无损图像而生的!如果你想要有损的图像,那就用JPEG或其他格式吧。)

Zopfli的最大特色是,假设你不介意极高的CPU要求,它就是“用完就丢”的一次性优化步骤,你可以应用在任何地方,而且不会受到任何伤害。好吧,除了可能会烧掉很多空闲的CPU周期。

如果你参与的项目需要提供压缩素材,仔细看一看Zopfli吧。它不是银弹——听了上述建议之后,你拿自己的文件来测试看看——但对于干我们这行的人来说,它真正是给我们送来了免费带宽啊!

你可能感兴趣的:(png,zopfli,pngout)