组里有个同事在周会上提议把商品详情页的大图全部换成渐进式 JPEG。他的依据是网上文章说的能小一成左右可我手上刚跑完的一组对照没那么好看。同一张图同一个质量下渐进式只比基线式小 3.9% 到 6.3%。差出来的这几个点我追了一下午才发现不全是渐进式本身的功劳。有一部分来自哈夫曼表要看拿来比的那份基线式有没有开优化。先交代样本和环境。一张是网上找的风景照来自 Wikimedia Commons 并缩到 2736×1824 当网页大图用。另一张是网上找的放假通知模板是稿定设计的一张 1242×2688 的模板图。编码用的是底层为 libjpeg-turbo 的 Pillow 11.3。机器是 Apple M4 / 16 GB每张图出质量 75 和 85 两档。我跑了四种编码基线式默认表、基线式加 optimize、渐进式、渐进式加 optimize。第一个意外出在渐进式那两份上。开不开 optimize 四组的字节数都一个不差。风景照质量 85 的两份都是 1,048,255 字节模板质量 75 的两份都是 502,023 字节。渐进式本来就在用按图生成的哈夫曼表这个开关对它不起作用。我翻了 libjpeg 编码初始化那段代码发现渐进模式下它会直接把优化编码打开注释的意思是标准默认表不适合渐进式。基线式就不一样它默认用 JPEG 标准附录里那套通用表。打开 optimize 之后编码器会先把整张图扫一遍数清每个符号出现多少次再给这张图单独造一套表。四组里这一步分别省了 0.8%、1.5%、3.7%、2.0%。两件事放在一起看就明白了比法不同结论也不同。拿渐进式去比默认表的基线式四组小了 4.7%、6.0%、9.2%、8.1%。模板那张已经接近一成了。换成优化过的基线式就只剩 3.9%、4.6%、5.7%、6.3%。Pillow 保存 JPEG 时 optimize 默认是关的。很多人随手写两行对比脚本时只在一边加了 progressive另一边什么都不加。这样量出来的差距里就混进了哈夫曼优化那一份网上那个一成我猜多半是这么来的。别人当时用的什么参数我核对不了我只能说自己复现出来是这个量级。剩下的 4% 到 6% 才是渐进式自己的本事。它把所有块的同一个频段放在一遍里写。高频那几遍几乎全是 0可以一句话带过一长串全零的块。这部分原理网上讲得很多我就不展开了。我更在意的是另一件事。渐进式强制用优化表说明它离不开按图统计。它每一遍扫描都要单独建表。各遍的统计特征差得很远用一套通用表去套只会更亏。libjpeg 那句注释说的就是这个意思。换句话说渐进式的体积优势里本来就捆着一份哈夫曼优化。比的时候要是只有它用了、基线式没用这一份就被一起算到了渐进式头上。说到这儿也能看出来这点体积不值得单独追。优化表那一份基线式自己打开开关就能拿到用不着改成渐进式。真要换的理由得是体验上的比如下载到一半能先出整张模糊图。代价也得一起算。同一组测试里渐进式解码是基线式的约 2.3 到 2.6 倍好在都是毫秒级。浏览器里首屏到底快了多少我这次没测这个数我手上没有。还有一件跟日常链路有关的事。我平时导图用的是图映 ImgInghttps://imging.cn/这次看的是它在 Chromium 149 开源构建里导出的 JPG。文件头是 SOF0 基线式它的 JPG 走的是浏览器原生编码。在这个浏览器里用 canvas.toBlob 导出 JPEG 拿到的也只有基线式。前端这一侧导出的图想要渐进式都得到服务端或者用专门的编码库再转一次。我最后在组里提了两条建议。第一条是对比脚本里基线式那一边先把 optimize 打开不然量出来的差距是虚高的。第二条是这 4% 到 6% 不单独拿来当换格式的理由。要换就把解码开销和兼容性一起评估。想自己核一下也简单。拿一张商品大图用 Pillow 按同一个质量存三份。一份什么都不加一份只加 optimize还有一份只加 progressive。对照三个文件的字节数就知道你那边的「渐进式更小」里有多少是哈夫曼表的贡献。
组里有个同事在周会上提议把商品详情页的大图全部换成渐进式 JPEG。他的依据是网上文章说的能小一成左右可我手上刚跑完的一组对照没那么好看。同一张图同一个质量下渐进式只比基线式小 3.9% 到 6.3%。差出来的这几个点我追了一下午才发现不全是渐进式本身的功劳。有一部分来自哈夫曼表要看拿来比的那份基线式有没有开优化。先交代样本和环境。一张是网上找的风景照来自 Wikimedia Commons 并缩到 2736×1824 当网页大图用。另一张是网上找的放假通知模板是稿定设计的一张 1242×2688 的模板图。编码用的是底层为 libjpeg-turbo 的 Pillow 11.3。机器是 Apple M4 / 16 GB每张图出质量 75 和 85 两档。我跑了四种编码基线式默认表、基线式加 optimize、渐进式、渐进式加 optimize。第一个意外出在渐进式那两份上。开不开 optimize 四组的字节数都一个不差。风景照质量 85 的两份都是 1,048,255 字节模板质量 75 的两份都是 502,023 字节。渐进式本来就在用按图生成的哈夫曼表这个开关对它不起作用。我翻了 libjpeg 编码初始化那段代码发现渐进模式下它会直接把优化编码打开注释的意思是标准默认表不适合渐进式。基线式就不一样它默认用 JPEG 标准附录里那套通用表。打开 optimize 之后编码器会先把整张图扫一遍数清每个符号出现多少次再给这张图单独造一套表。四组里这一步分别省了 0.8%、1.5%、3.7%、2.0%。两件事放在一起看就明白了比法不同结论也不同。拿渐进式去比默认表的基线式四组小了 4.7%、6.0%、9.2%、8.1%。模板那张已经接近一成了。换成优化过的基线式就只剩 3.9%、4.6%、5.7%、6.3%。Pillow 保存 JPEG 时 optimize 默认是关的。很多人随手写两行对比脚本时只在一边加了 progressive另一边什么都不加。这样量出来的差距里就混进了哈夫曼优化那一份网上那个一成我猜多半是这么来的。别人当时用的什么参数我核对不了我只能说自己复现出来是这个量级。剩下的 4% 到 6% 才是渐进式自己的本事。它把所有块的同一个频段放在一遍里写。高频那几遍几乎全是 0可以一句话带过一长串全零的块。这部分原理网上讲得很多我就不展开了。我更在意的是另一件事。渐进式强制用优化表说明它离不开按图统计。它每一遍扫描都要单独建表。各遍的统计特征差得很远用一套通用表去套只会更亏。libjpeg 那句注释说的就是这个意思。换句话说渐进式的体积优势里本来就捆着一份哈夫曼优化。比的时候要是只有它用了、基线式没用这一份就被一起算到了渐进式头上。说到这儿也能看出来这点体积不值得单独追。优化表那一份基线式自己打开开关就能拿到用不着改成渐进式。真要换的理由得是体验上的比如下载到一半能先出整张模糊图。代价也得一起算。同一组测试里渐进式解码是基线式的约 2.3 到 2.6 倍好在都是毫秒级。浏览器里首屏到底快了多少我这次没测这个数我手上没有。还有一件跟日常链路有关的事。我平时导图用的是图映 ImgInghttps://imging.cn/这次看的是它在 Chromium 149 开源构建里导出的 JPG。文件头是 SOF0 基线式它的 JPG 走的是浏览器原生编码。在这个浏览器里用 canvas.toBlob 导出 JPEG 拿到的也只有基线式。前端这一侧导出的图想要渐进式都得到服务端或者用专门的编码库再转一次。我最后在组里提了两条建议。第一条是对比脚本里基线式那一边先把 optimize 打开不然量出来的差距是虚高的。第二条是这 4% 到 6% 不单独拿来当换格式的理由。要换就把解码开销和兼容性一起评估。想自己核一下也简单。拿一张商品大图用 Pillow 按同一个质量存三份。一份什么都不加一份只加 optimize还有一份只加 progressive。对照三个文件的字节数就知道你那边的「渐进式更小」里有多少是哈夫曼表的贡献。
