
国庆发这篇。祝祖国生日快乐。放假前我给同事搭一个导活动图的网页小工具测着测着撞上一件怪事。同一张红底海报质量都填 0.9换个浏览器导出来的红字清楚程度就不一样。有的字边干干净净有的却糊着一圈发暗的红晕像印刷时套色没套准。我先怀疑自己手滑填错了数可来回核对好几遍参数都没错。后来干脆把三个浏览器内核都拉出来挨个导了一遍。测试图是我用脚本画的 1600×900 促销风海报上半截是红底黄字的大标题。下半截的白卡片上印着几行不同字号的红字旁边还有同字号的黑字做对照。这张图里既没有照片也没用任何网上找来的素材。机器是一台 16 GB 内存的 Apple M4 Mac。浏览器用的是 Chromium 149、Firefox 151 和 WebKit 26.5 三个开源构建。它们和平时装的 Chrome 或 Safari 正式版不能直接画等号下面的数只代表这三个版本。三个浏览器导出时一律走网页自带的 canvas 导出接口。清不清楚我没光靠眼睛看还在字边那一圈算了原图和导出图的色差。这个色差叫 ΔE数越小越接近原图一般认为过了 5 的色边一眼就能看出来。三个浏览器导出来的结果差得挺开。Chromium 那份 157 626 字节的文件字边色差是 7.11。WebKit 那份 226 166 字节的色差是 6.64Firefox 那份 246 096 字节的色差只有 2.31。前两个都过了 5 这条线。Firefox 离它还远着。文件大小也对不上。Firefox 这张比 Chromium 那张大了一半还多。同样写着 0.9 的三个文件明显不是按一套规矩压出来的。问题出在「色度抽样」上。JPEG 存图时会把画面拆成管亮暗的一份和管颜色的一份。人眼对颜色没有对亮暗那么敏感管颜色的那份就可以存得粗一点。最常见的粗法叫 4:2:0横竖各砍一半只留四分之一的像素。另一种叫 4:4:4颜色一个像素都不省。用的是哪一种会写在 JPEG 文件头里。我是直接读文件头判断的一读就清楚了。Chromium 和 WebKit 在 0.9 用的都是 4:2:0Firefox 用的是 4:4:4。我又顺手拿 Pillow 按质量 90 加 4:4:4 压了同一张海报。出来也是 246 096 字节。跟 Firefox 那张一个字节都不差。红字为什么偏偏吃亏我的理解是黑字白底只差亮暗亮暗那份一点没被砍。红字白底差的大头在颜色上。颜色的清晰度只剩原来的四分之一以后字边自然就晕开了。我还另画了一张八种配色的颜色对照板来导。同样 0.9 的 4:2:0 下黑字白底色差 0.77红字白底是 10.23。差了十几倍。你看到的红字发糊其实是颜色被存粗了。字本身的轮廓没怎么坏。Chromium 自己从 0.80 拉到 0.99 的时候文件从 118 KB 涨到 265 KB。白卡片上的红字还是裹着那圈发暗的红晕。填到 1.00 换成 4:4:4 以后字边才跟原图一样干净可文件已经涨到 428 KB。Firefox 在 0.9 走的就是这条 4:4:4 的路子。只是质量比 1.00 低了一截色差 2.31 要比 0.19 高一些。那 Chromium 和 WebKit 要填到多少才会换成 4:4:4我从 0.8 开始一档一档往上试每导出一个文件就读一遍它的文件头。Firefox 从 0.895 起就换了这个数取整以后正好是 90。Chromium 和 WebKit 得等到 0.995 取整成 100 才换。填 0.99 时两家都还是 4:2:0。Chromium 的色差是 6.35WebKit 是 6.57Firefox 这时早就降到 0.33 了。填到 1.0 以后三家都换成了 4:4:4文件也跟着一起胀起来。Chromium、Firefox 和 WebKit 依次是 438 482、517 964 和 519 331 字节。原图 PNG 才 123 KB。这就大出去三倍多了。这张表是我把每个导出文件的文件头读出来以后整理的。横着是质量 0.80 到 1.00 这几档竖着是三个内核。红格是 4:2:0绿格是 4:4:4。「没测」就是那一档我没导。要看的是绿格从哪一列开始。Firefox 那一行从 0.90 就绿了另外两行要到 0.995 才绿。上面这些都是我自己画的海报。我又从网上找了一张现成的 2026 年国庆放假通知模板稿定设计的模板图在 Chromium 里重导了一遍。它红底配米白卡片下面是一格格红字日历。底子里还有渐变和插画。换成这张真实模板也是同一个方向。质量从 0.80 拉到 0.99 时体积涨了 3.2 倍。「假期安排」那几个红字的字边色差只从 6.56 降到 4.48。到 1.00 才切成 4:4:4。可 3 643 511 字节的文件比原图 PNG 还大。这张是那张模板日历里「1 廿一」「2 廿二」「3 廿三」三格放大 6 倍的样子。图上没标字。从上到下三行依次是原图、用 Pillow 按质量 75 加 4:4:4 压的 JPEG、Chromium 导出的 0.994:2:0。看的时候盯住格子下面那排「廿一」「廿二」小字。最底下那行的笔画颜色发暗发褐上面原图和中间那行还是正红。中间那行的文件只有 680 616 字节差不多是最底下那份 2 004 878 字节的三分之一。它的字边色差 4.29 还比 4.48 低。弄明白这一层以后我对这类红字图的做法就变了。在网页里导 JPEG 时同一个质量在不同浏览器里可能是两种存法。想靠调高质量让红字变干净基本没戏。Chromium 和 WebKit 不填到 1.0 就一直是 4:2:0填到 1.0 又大得离谱。我平时压图用的是图映 ImgInghttps://imging.cn/这次也在同一台 M4 的 Chromium 149 里拿这张海报试了它。它的 JPG 滑杆拉到 100 导出的文件跟 Chromium 自己 0.99 导出的逐字节相同同样是 4:2:0。在 Chromium 里用它转 JPG 也躲不开这圈红晕。不过它默认根本没让我转 JPG。界面提示检测到图标或线稿后自动走了 PNG-8。结果是 124 色的 48 KB 文件比原图省了 62%。这个省法只对这种几种纯色加字的平面图成立。那张放假通知模板它判成了截图界面默认走 WebP 画质 84 省了 82%。字边色差是 5.12跟普通 WebP 有损差不多。转 JPG 拉到 100 的那份跟 Chromium 的 0.99 解码出来逐像素相同也还是 4:2:0。现在遇到纯色加字、红字又多的活动图我先存 PNG。带渐变插画的模板存 PNG 反而最大。这种我改存 JPEG能指定 4:4:4 就指定上质量 75 就比 0.99 干净。真要 JPEG 就先用 Firefox 导一版再读一下文件头确认是不是 4:4:4。WebKit 这边我只测了开源构建没在正式版 Safari 上验过。正式版 Chrome 和 Chromium 同源我也没单独验。平时用哪个浏览器导图就拿它导一张红字图放大看看。