Google Guetzli图片压缩算法预研报告

作者介绍：陈磊，腾讯社交平台部后台开发，高级工程师。参与过朋友网、手机qq空间、微群组、企鹅FM等产品的开发，对大型服务器架构设计、音频、直播、图片领域有研究和工程经验。

背景

Google推出了一个新的编码算法Guetzli，用于编码jpeg格式，官方称比之前libjpeg可以缩小30%的量。此算法只是改了jpeg的编码算法，并没有改解码算法，编出的jpg通用目前的jpg解码器。考虑webp相对弱的兼容性和慢解码速度，Guetzli值得考虑的方案。本文将通过比较libjpeg, Guetzli,webp的压缩率、压缩延时、压缩资源、解压性能，评估Guetzli可用性。

原理

Guetzli基于同样来源于google的一个图片视觉差异评价工具Butteraugli。Butteraugli的评价体系基于三个传统方法没有考虑的原则：

• 人眼对强黄色光附近蓝光变化是不敏感的，因此黄光区域附近的蓝光可以用更少的bit来编码
• 人眼对蓝光有着较低的空间分辨率，视网膜中用于分辨高清细节的区域没有蓝色光的受体，故高频区域的蓝色光部分可以用更粗的粒度编码。
• 将图像中的噪声区域分辨出来进行粗粒度的编码。

基于这三点，Guetzli主要从两方面下手来进行：

• 对全局量化表进行微调，这一步和我们调整质量参数本质上是一样的
• 对DCT系数的高频部分进行有选择的丢弃

第二步就比较tricky了。我们通常调整质量参数本质上就是有选择的丢弃高频信息。Guetzli在这一步就相当于替我们降低了质量而不告诉用户，让用户以为仍然保持了质量。总的流程就是Guetzli尝试多种a,b两个方面的可能性，然后分别放到Butteraugli评测工具中评分，最后选择一张它认为最好的结果返回给用户。所以它的处理时延特别长。

（此原理描述摘自文章《Guetzli：谷歌家的东西可能也没有想像的辣么美》）

压缩率

压缩率：描述压缩文件的效果名，是文件压缩后的大小与压缩前的大小之比

质量系数：图片压缩级别，质量系数1表示最低图像质量和最高的压缩，质量系数100表示最佳的图片质量和最低效的压缩。下图是libjpg、Guetzli、webp不同质量系数下的压缩率，可以看出：

• 整体压缩效果：webp>Guetzli>libjpg
• guetzli比libjpg优12%-33%， webp比Guetzli优20%左右
• guetzli在高质量系数下，压缩率表现更好

图片肉眼观察质量

对于相同质量系数压缩的图片，各算法肉眼是看不出区别

压缩延时

模型：这里假设业务需要转5档图，这里压缩延时计算模型是一张图片转换成业务需要的五档图的总延时

数据：下面的表是测试后的平均值，每个数据都是五档图加起来的总延时

可以看出：quetilz算法的压缩延时远远高于libjpg webp，前者到分钟，后者不到秒。也就是说业务用guetzli算法，单个节目或者专辑的图片转五档图，不算任务排队时间，转码就需要1分钟。

OMG的yajunwang同学最近用guetzli算法跑了一个不同大小图片，范围是1k到4M，转换成图表如下：横坐标是图片大小，纵坐标是耗时

（此原理描述摘自文章：《谷歌开源图片压缩算法Guetzli实测体验报告》)

分析得出：

• 转码耗时整体随着图片大小增长
• 有些异常数据点，是图片size相对小的图片有比较大的像素，这个算法严格的说是耗时和像素大小相关，而不是文件大小

后台压缩资源评估

• cpu：执行一个guetzli进程可以把单核cpu跑满
• 内存：guetzli是个内存消耗性的的算法，占用内存随着像素增加而增加，具体测试数据如下：

比如：处理个7.9MPix的图片，尺寸3264*2448，占用1G内存，60G内存的机器只能同时处理不到60张；库里的图片在100K左右，也要100M左右内存。

假设业务每天的图片入库量10000，上面的数据看到单核cpu处理一个图片均值60s，也就是一小时处理60个图片，10核处理600个图片，17个小时可以消化一天的量。对于延时要求不高的运营图片上架场景，是满足的，也可以增加逻辑提高指定图片的优先级。

客户端下载、解码耗时

用户查看图片经过客户端下载和解码两个阶段：

• 下载延时依赖网络环境、文件大小
• 解码延时依赖解码算法、机器性能
• 同一档图，不同算法，总延时优劣比较方法：

设带宽用户网络带宽为N，Guetzli算法压缩的文件大小与Webp压缩后的文件之差为DeltaSize，Webp解压延时与Guetzli解压延时之差DeltaDecodeCost

Guetzli与Webp的优劣公式： 整体耗时差 = DeltaSize/N - DeltaDecodeCost， 整体耗时差大于0表示Webp更优，整体耗时差小于0表示Guetzli更优

以上算法需要线上大量数据测出个均衡值，可以考虑根据带宽和文件大小动态选择。

看一下真实测试的效果

• 输入：相同的图片源，转换成五档不同的大小
• 机型：andirod选8核、4核、单核三种机型，ios选择iphone5s、iphone6p、iphone7
• 下面第一张表是不同机型的解码耗时；第二张表是两个平台不同网络条件的下载耗时、解码耗时、总耗时

(数据由wealongcai，freddyyao两位同学提供)

分析出：

• 解压性能：guetzli>jpg>webp
• 解压性能与机器性能成正相关关系
• 整体耗时上，webp和Guetzli接近，webp从此数据看更胜一筹，两者比jpg优势明显
• 在网络环境越来越好的情况下，guetzli整体性能表现会越来越好

兼容性

gutilz只能编码yuv编码的图片，不能直接编码RGB格式,需要做先做一步转换

综合评估

• 对于jpg与guetzli的比较，视觉质量上无区别，压缩率上guetzli有明显优势；编码延时上，guetzli对资源要求高，对图片上线延时要求不高的可以接受。
• 对于guetzli与webp的比较，视觉质量上无区别，从目前的测试数据来看，webp整体优一些，但是优势不是特别明显，网络环境越好，guetzli表现的越好。
• 对于H5的jpg在上传延时要求不高的场景，都适合直接用guetzli替换

Guetzli算法刚提出不久，还需要更多的数据支持和验证，如果有问题，请各位指正，谢谢！

相关推荐

Android动态库压缩壳的实现

关于Android图片资源瘦身的奇思妙想