背景Google推出了一个新的编码算法Guetzli，用于编码jpeg格式，官方称比之前libjpeg可以缩小30%的量。此算法只是改了jpeg的编码算法，并没有改解码算法，编出的jpg通用目前的jpg解码器。考虑webp相对弱的兼容性和慢解码速度，Guetzli值得考虑的方案。本文将通过比较libjpeg, Guetzli,webp的压缩率、压缩延时、压缩资源、解压性能，评估Guetzli可用性。 原理Guetzli基于同样来源于google的一个图片视觉差异评价工具Butteraugli。Butteraugli的评价体系基于三个传统方法没有考虑的原则：
基于这三点，Guetzli主要从两方面下手来进行：
第二步就比较tricky了。我们通常调整质量参数本质上就是有选择的丢弃高频信息。Guetzli在这一步就相当于替我们降低了质量而不告诉用户，让用户以为仍然保持了质量。总的流程就是Guetzli尝试多种a,b两个方面的可能性，然后分别放到Butteraugli评测工具中评分，最后选择一张它认为最好的结果返回给用户。所以它的处理时延特别长。 （此原理描述摘自文章《Guetzli：谷歌家的东西可能也没有想像的辣么美》） 压缩率压缩率：描述压缩文件的效果名，是文件压缩后的大小与压缩前的大小之比 质量系数：图片压缩级别，质量系数1表示最低图像质量和最高的压缩，质量系数100表示最佳的图片质量和最低效的压缩。下图是libjpg、Guetzli、webp不同质量系数下的压缩率，可以看出：
图片肉眼观察质量对于相同质量系数压缩的图片，各算法肉眼是看不出区别 压缩延时模型：这里假设业务需要转5档图，这里压缩延时计算模型是一张图片转换成业务需要的五档图的总延时 数据：下面的表是测试后的平均值，每个数据都是五档图加起来的总延时 可以看出：quetilz算法的压缩延时远远高于libjpg webp，前者到分钟，后者不到秒。也就是说业务用guetzli算法，单个节目或者专辑的图片转五档图，不算任务排队时间，转码就需要1分钟。 OMG的yajunwang同学最近用guetzli算法跑了一个不同大小图片，范围是1k到4M，转换成图表如下：横坐标是图片大小，纵坐标是耗时 （此原理描述摘自文章：《谷歌开源图片压缩算法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更优 以上算法需要线上大量数据测出个均衡值，可以考虑根据带宽和文件大小动态选择。 看一下真实测试的效果
(数据由wealongcai，freddyyao两位同学提供) 分析出：
兼容性gutilz只能编码yuv编码的图片，不能直接编码RGB格式,需要做先做一步转换 综合评估
Guetzli算法刚提出不久，还需要更多的数据支持和验证，如果有问题，请各位指正，谢谢！ 相关推荐 |
|
|
