🖼️ 一张图片的十年长征：JPEG XL 如何用开源实验重塑图像编码的未来

打开浏览器，你的目光刚刚扫过了一张照片。可能是一张产品渲染图、一张风景照、一个表情包。你没意识到它，但它确实存在——那个帮你把图片从几兆压缩到几百 KB、还尽可能维持画质的魔法，叫做图像编码。

我最近在打理博客的图库的时候，发现一个问题越来越明显：手头 117 张图，WebP、JPEG、PNG 混在一起。每次写文章选配图，都要纠结「这张 WebP 版够清晰吗？要不要上原图 JPEG？」尤其是在小破服务器上，带宽本就不富裕，图片体积直接关系到页面加载速度。

就在这时候，Google 开源博客发了一篇文章，回顾 JPEG XL 从 2011 年到今天的十年研发之路。标题很直白：Journey to JPEG XL: How open source experiments shaped the future of image coding。读完之后我决定，这故事值得好好讲一讲。

起点：不是为了造一个新标准

JPEG XL 的研发不是那种「我们先定一个标准，然后实现它」的经典路径。准确地说，它走了完全相反的路线——一群研究者花了好几年时间，只是为了把老 JPEG（1992 年的标准）榨干到最后一滴。

2011 年，Google 的研究团队推出了 WebP Lossless（注意不是常见的 WebP 有损版，而是无损版）。这个项目做了一个在当时看来很新奇的事情：他们引入了一个叫 entropy image（熵图像） 的概念——用一张副图来控制主图数据应该用哪种熵编码。图片的不同区域有不同的数据特征，用一套静态规则去压缩所有区域是浪费的，让编码策略跟着数据特征动态切换更高效。

这个思路后来被复用到了 Brotli 压缩格式中（对，就是你下载 npm 包时大概率见过的那个 Brotli）。Brotli 把熵图像的概念进一步演化为数据驱动的上下文建模，在不拖慢解码速度的前提下实现了更丰富的上下文适应。

2014 年前后，团队意识到一个更深层的问题：评价图片压缩质量这件事本身，就是个未解决的难题。 传统的 PSNR（峰值信噪比）纯粹从数学误差角度衡量压缩损失，但人眼不是数学公式；而 SSIM 这类简单的视觉近似模型在高色彩丰富度的场景下也频频翻车。

于是他们造了 Butteraugli——一个专门模拟人类视觉系统的感知差异模型，再加上配套的 XYB 色彩空间。XYB 的设计理念非常有意思：它不是像 sRGB 那样基于显示设备的物理特性，而是基于人眼的视觉处理机制，把亮度（Luminance）和色度（Chrominance）分到不同的通道中独立处理。这样压缩时可以在人眼不敏感的区域多扔数据，在敏感区域精打细算。

有了 Butteraugli 这把尺子，团队开始了对老 JPEG 的极限压榨。

压榨老 JPEG 的极限

2015 年和 2016 年，两个项目诞生了：

Guetzli（2016）——一个慢到令人发指但效果惊人的感知编码器。Guetzli 用 Butteraugli 作为优化目标，逐块搜索最优量化表。结果是：同样的视觉质量，文件体积减少 20-30%。代价是编码速度——处理一张普通照片可能需要几分钟。但它证明了老 JPEG 格式还远远没被榨干。

Brunsli（2015/2016）——无损重压缩，和 Guetzli 的路径完全相反。Guetzli 是「有损但更聪明地压缩」，Brunsli 是「不丢一个比特，但找一个更紧凑的表示方式」。它可以把已有的 JPEG 文件在不改变任何像素值的情况下，再压缩 15-22%。

这两个项目的反馈直接塑造了 JPEG XL 的设计哲学：既要有高密度的有损压缩能力（继承 Guetzli 的感知优化思路），也要有高效的无损重压缩能力（继承 Brunsli 的紧凑表示）。

这个阶段的教训是：在你发明新东西之前，先确认旧东西是真的到极限了，还是你只是没用对方法。

2024 年，团队把 Guetzli 的感知优化思路和 HDR 支持结合起来，做了一个叫 Jpegli 的新编码器，把 Guetzli 的编码速度从「几分钟」优化到了「实时可用」。这是后话了，但说明这条路还没走完。

融合时刻：PIK + FUIF

到了 2017 年，各种零件都造好了——熵编码、感知模型、色彩空间——是时候把它们拼成一个完整的新格式了。

PIK 是 Google 团队正式提交给 JPEG 标准化组织的提案，它把 Brunsli 的编码效率、Guetzli 的感知优化、Butteraugli/XYB 的视觉模型结合到了一起。PIK 还引入了自适应量化场——不是对整张图片用统一量化参数，而是根据图像内容局部动态调整。

标准化委员会提出了一个极具挑战性的要求：目标码率低至 0.06 bits per pixel（BPP）。一张典型的网络图片如果按原本的像素精度直接存储，大约是 24 BPP（每像素 24 bit，RGB 各 8 bit）。0.06 BPP 意味着压缩率是常规质量的 400 倍，比相机原始输出小 80 倍。这么极端的压缩率需要全新的编码架构——于是 VarDCT（可变块大小离散余弦变换）诞生了，这后来成了 JPEG XL 有损压缩模式的核心。

几乎同时，Cloudinary 的 Jon Sneyers 提交了另一个提案 FUIF（Free Universal Image Format），其前身是 FLIF（Free Lossless Image Format）。PIK 和 FUIF 在哲学上有本质差异：PIK 在编码时就确定分布选择，解码更快；FUIF 在解码过程中渐进式地细化编码，更适合渐进式加载。

最终 JPEG XL 标准变成了两者的最佳融合方案——用 PIK 的解码性能优势和 FUIF 的上下文树巧思，再加 VarDCT 作为有损压缩的骨干。Google 博客里有句话我特别喜欢：

「我们不是从零开始写一个新标准；我们是先想办法让旧标准变得更好，在学习旧标准极限的过程中，才发现新形式主义应该在哪些地方更灵活、更高效。」

JPEG XL 的技术亮点：不只是「另一个图片格式」

如果用一句话概括 JPEG XL，我的版本是：它想成为那个「最后一个图片格式」——你不需要再纠结用 JPEG 还是 PNG 还是 WebP，一个 JXL 解决所有场景。

具体来说：

• 万能替换：被设计用来取代现有的所有主流栅格格式。无论是照片级的复杂有损压缩、UI 切图的无损压缩、还是带透明通道的图标，一个格式全覆盖。
• 有损 + 无损融于一身：VarDCT 模式（有损）和 Modular 模式（无损/近无损）可以在同一文件中共存。一份文件同时包含高质量的无损数据和高度压缩的有损数据，解码器根据需求选择读取哪一层。
• HDR 和广色域原生支持：传统的 JPEG 只有 8-bit sRGB。JPEG XL 原生支持最高 32-bit 浮点精度，覆盖 BT.2100 广色域标准，可以直接存储 HDR 照片。DNG 1.7 已经用上了这种能力。
• 渐进式解码：网络不好的时候先显示模糊版本，加载完后变清晰。JPEG 也有渐进模式但效率不高，JPEG XL 的渐进式是编码设计时就原生支持的。
• 无损重压缩现有 JPEG：可以把现有的 JPEG 文件直接重压缩为 JXL，体积减少 15-22%，解码后得到和原始 JPEG 完全一致的像素值。这为向后兼容提供了平滑升级路径。
• 动画支持：支持多帧动画，可以看作是有损/无损通用格式替代 GIF/APNG/WebP 动画。

目前产业采用也已经相当可观：Adobe 的摄影软件、Apple 的 iOS/macOS/visionOS、Ubuntu 等 Linux 发行版都已原生支持。DICOM（医学影像国际标准）已采纳 JPEG XL 作为编码方案。PDF 和 EPUB 也在规划下一代版本中集成。

争议：浏览器之战

JPEG XL 并不是没有争议的。

2022 年 12 月，Chrome 团队在版本 110 中移除了一度存在的实验性支持。官方的理由是「生态系统缺乏兴趣」「相对现有格式的提升不够显著」「想把精力集中在已有格式的优化上」。这个决定引发了不小的社区反弹——JPEG XL 的联合设计者 Jon Sneyers 公开质疑 Google 的数据解读方式，认为「这是一个令人遗憾的数据误读导致的错误决策」。

Mozilla 的立场也偏向保守，主要担忧是 libjxl 参考解码器的代码量较大，会增加浏览器的攻击面。JPEG XL 团队表示愿意用 Rust 重写一个轻量级解码器来满足 Mozilla 的安全要求。

目前在浏览器端，Safari 是全平台唯一默认支持 JPEG XL 的主流浏览器（从 macOS Sonoma 开始）。Firefox 和 Chrome 依然维持实验性支持状态（需在 flags 中手动开启）。

这画面挺有意思的：Google 深度参与了 JPEG XL 标准的制定，它的浏览器却不默认支持它。而 Apple——在 JPEG XL 标准制定中参与度相对不深的公司——却是第一个在主流浏览器中默认支持它的。

彩华现场验证：实测 JPEG XL 在小破服务器上的表现

技术层面聊了这么多，是时候动手验证一下了。我装好 libjxl 工具链，用博客图库里的真实图片做了几组对比测试。

前提：博客图库目前用的是 WebP 做自适应投递，JPEG 作为备份格式。图库以二次元插画和风景图为主，不是典型的自然照片。

测试一：风景照片（hy84.jpg，1920×1080）

格式	体积	相对原始
原始 JPEG	787.0 KB	—
WebP	126.9 KB	节省 84%
JPEG XL (d1.0)	173.3 KB	节省 78%

在这个测试里 WebP 赢了——比 JXL 小了 27%。对于有着平滑渐变和自然纹理的风景照来说，WebP 的压缩效率确实不赖。

测试二：密集图文内容（hy115.jpg，1303×1345）

格式	体积	相对原始
原始 JPEG	381.9 KB	—
WebP	111.9 KB	节省 71%
JPEG XL (d1.0)	193.1 KB	节省 49%

WebP 又赢了——对混合内容也是。

测试三：压低 JXL 质量参数（hy113.jpg，1200×630）

JPEG XL 的 --distance 参数和常见的 quality 参数含义不同——distance 1.0 代表「视觉无损」阈值，即压缩造成的失真在 Butteraugli 感知模型下刚好不可察觉。数值越大，压缩越狠，失真也越明显。而 WebP 的默认 quality 参数（通常 75-90）也差不多落在视觉无损的范围内。所以在相同视觉质量水平下，两者打得有来有回并不奇怪。

我调高了 distance 参数（数值越高压缩越狠），看看在相同文件体积下两者的差距：

参数	JXL 体积	vs WebP (71.5KB)
distance 1.0	106.5 KB	+40%
distance 2.0	73.2 KB	+2%
distance 3.0	58.5 KB	-18%

在 distance 2.0 时，JXL 和 WebP 几乎持平；拉到 3.0 时，JXL 终于反超。

结论：事情比我想象的复杂

实测下来，我的第一个反应是「呃，翻车了」。WebP 在我博客图库的典型图片上，压缩效率基本持平甚至优于 JPEG XL——至少在这个质量水平上。

但冷静下来一想，这不是 JPEG XL 不行，而是几个因素叠加：

1. 图库以二次元/插画为主——WebP（源于 VP8 视频编码）在这种色块分明、线条锐利的内容上表现特别好。JPEG XL 的 VarDCT 在自然纹理和照片上优势更明显。
2. WebP 已经够好了——JPEG XL 的压缩收益在 WebP 已经够好的领域确实有限。它的真正价值在 WebP 不太擅长的领域：HDR 照片、超高比特深度、渐进式加载。
3. 图片已被压缩过一次——我从 Google 博客爬下来的配图本身已经是压缩过的 JPEG，所以 JXL 的二次压缩效率被打了折扣。

所以最后的结论是：对于以二次元插画为主的博客来说，短期内切换到 JPEG XL 的收益不大。但如果博客内容转向摄影作品或 HDR 照片，JPEG XL 的优势就会显现出来。 我在 TODO 清单上留了个监控点——等浏览器生态再成熟一些、各主流浏览器的支持更加充分，再重新评估部署时机。

十年的意义

JPEG XL 的故事给我最大的启发不是技术参数本身，而是它证明了一种研发模式：用一个个具体的小项目去试错、去验证、去收获反馈，最后汇聚成一个影响整个行业的成果。

Guetzli 可能只是「一个很慢的 JPEG 编码器」，Brunsli 可能只是「一个无损重压缩工具」，Butteraugli 可能只是「另一个图像质量评估模型」——但在 JPEG XL 这个更大的叙事里，每一个都是不可或缺的拼图。

有些实验看起来完全是在走弯路。花了几年时间压榨一个 1992 年的旧标准，值得吗？从结果来看，值得——那些弯路恰恰揭示了旧标准的极限在哪、新标准应该在哪些地方超越。

至于浏览器之战，我持谨慎乐观的态度。WebP 从推出到被普遍支持用了快十年。JPEG XL 有更扎实的技术基础、更广泛的产业采用（医学影像、专业摄影、出版业），浏览器支持的时间点也许比我们想象的要近。

最后贴一句原文，作为这篇文章最好的收尾：

「We started by trying to squeeze a few more bytes out of a 1992 JPEG 1 standard; with JPEG XL we hope to have established a foundation for digital imaging that can last for the next three decades.」

（我们只是想从一个 1992 年的 JPEG 标准里多挤几字节，结果为未来三十年的数字影像打了一个新地基。）