探讨 JPEG XL（JPEG XL）作为 Web 图像编解码器的地位。该格式技术表现令人印象深刻，是 JPEG（JPEG）的明确升级，比 WebP（WebP）更通用，也能处理网页之外的场景。但它在 2023 年曾被 Chrome（Chrome）拒绝支持。最近，一个 Rust（Rust）实现的 JPEG XL 解码器已部分进入 Firefox（Firefox）和 Chrome，Web 的主要利益相关方或许正因此转变对 JPEG XL 的态度，新解码器可能避免重演 2023 年 WebP 漏洞事件。
正文
为什么？
JPEG XL 是技术上令人印象深刻的图像编解码器；它明确优于 JPEG，比 WebP 更通用，也适合 Web 之外的用途。但它在 2023 年被 Chrome 拒绝。对一个来自 JPEG 委员会、免版税、灵活、压缩高效且当时正受到大公司关注的编解码器来说，这个决定让很多人不满。
最近，一个 Rust 写的 JPEG XL 解码器以某种形式进入 Firefox 和 Chrome。Web 的主要利益相关者可能因此改变对 JPEG XL 的态度，因为新解码器可能让 Web 免于重演 2023 年的 WebP 漏洞。这就足以让 JPEG XL 在 Web 上站住脚吗？
过去，我一直是 JPEG XL 的坚定支持者。我曾为 Interop 2024 背书 JPEG XL，也多次与 Jon Sneyers 和 Jyrki Alakuijala（该格式的两位主要作者）交流。我一直钦佩他们的公开举止、冷静、技术能力和对领域的热情。
这不是要抹黑格式作者或他们的工作，也不是要在自由软件中该编解码器的象征意义方面表明政治立场。目的是提供一次实证观察，看看 2026 年图像压缩和 Web 平台的现状。部分灵感来自 Dmitry Grinberg 的《RISC-V: They Should Have Known Better》。
Web
我做图像压缩工作，最初来自视频压缩。在开发 AV1 编码器时，Julio Barba 和我对 AVIF 做出了重大改进，我也从中收获很多。当决定构建自己的编码器时，我认真思考了哪些格式天花板最高、能被有效优化、当前和潜在用途最大。我决定不做 JPEG XL。
按数量看，Web 上很少有用例不能由通用的有损压缩服务。普通 Web 用户不需要无损，只需要一个通用到足以避免糟糕伪影的有损编解码器（比如 JPEG 在非摄影内容上的表现）。这就排除了 JPEG XL 的无损优势；实践中它只比无损 WebP 小约 11.9%，而且测试数据集对 Web 不现实（157 MP 照片、10 MP 插画、27 MP 书籍）。为了在极小体量、且对带宽本就不敏感的内容上节省 12%，不值得把新图像编解码器带进浏览器。我这么说是因为 JPEG XL 在有损上不具竞争力，无损会是它唯一真正的优势。
有损压缩效率
JPEG XL 最初的论据之一是它的参考编码器比竞争编码器更感知优化。现在，无论速度还是每比特保真度，其他编码器都更强。
AV1 参考编码器基于受控主观人类试验做了专门的感知调优，以增强效率，同时保持一个为感知指标优化的调优模式。SVT-AV1 也有类似调优模式。没有令人信服的理由说现代编码器没有为人类眼睛调优。
指标不完美，但对 JPEG XL 来说前景严峻：aperture-alpha 是 Halide Compression 即将推出的编码器，代号 Aperture。我把它列出来，是为了显示 libjxl 要在前沿竞争还需追赶多少。
一些分析称 JPEG XL 在指标上表现不佳，但感知实力更强。我没有足够证据表明差异大到能让我展示的图表被完全反转。CVVDP 和 SSIMULACRA2 都是很强的感知指标，当差距如此大时，它们确实告诉我们一些东西。对 AVIF 来说，libaom 的感知优化调优（tune IQ）只比其感知指标优化调优（tune SSIMULACRA2）低几分。此外，JPEG XL 参考编码器历史上一直有感知问题，且大多未解决。
不存在编解码器基准，只有编码器基准；理论上 JPEG XL 作为格式的上限高于 libjxl 目前达到的水平。但缩小差距有多难？作为压缩工程师，我认为它在这方面处于劣势。原因有：
- JPEG XL 没有方向预测模式。压缩图像被分成 VarDCT 块（从 2x2 到 256x256），并变换为像素的频率表示。其他基于块的图像编解码器如 WebP，允许你利用周围数据预测一个块的像素，从实际像素中减去预测，再做频率变换。方向预测模式如果编码器没有感知优化，可能导致模糊，但强大的模式决策流程能选对模式并节省大量比特。例如，带方向预测的编解码器边缘保持更强，JXL 在这方面较弱。
- 边缘保持差距的提议解决方案是样条，使用难度大得多。困难在编码器一侧：你需要高效算法判断哪些像素可表示为样条，然后把每个候选送入 RDO 决定是否值得编码。目前没有用样条做边缘保持的 PoC，我也没有理由相信它们会比方向预测更好。
- JPEG XL 没有去块环路滤波（DLF），也没有任何去块滤波器。它有两个环路内工具，有时被当作部分替代：gaborish，最接近 AV1 的环路恢复滤波；以及 EPF（边缘保持滤波），最接近 AV1 的 CDEF。两者都不是去块滤波器，合在一起也不能完全替代合适的 DLF。DLF 会平滑图像，但如果编码器聪明，它只能帮你避免蚊式噪声，而 JPEG XL 仍受蚊式噪声困扰。
- JPEG XL 的感知 XYB 色彩空间基于大量直觉，即使 SSIMULACRA2 等指标就在同一色彩空间工作，也不总能转化为其他格式中的增益。使用 XYB 所声称的效率节省也没有最初宣传的那么大，因为 libjxl 目前依赖激进量化 B 通道。这导致色彩保持不佳，新的 JXL 编码器开发者必须明确抵消这一点。
- JXL 在非摄影图像上表现差。提议方案是补丁，但比 AV1 的 Intra Block Copy 更难用。
- 要达到与 IntraBC 相近的表现力，编码器必须处理图层和混合等额外概念，而在比特流层面表示它们并不便宜。
- 残差编码很别扭。用 AV1，你预测一个块，从源中减去预测，变换系数自然表示残差。用 JXL 的构造，你解码一个残差帧，然后混合参考补丁，所以你需要一个实际帧或图层，其解码像素表示残差。那很可能是 Modular 帧；有意思的是，Modular 不像最终渲染图像那样受限于传统无符号图像值。
- 一个 IntraBC 块本质上只花费一个运动向量加残差系数，而一个 JXL 构造可能花费参考帧、帧头、裁剪、混合信息、补丁字典条目、补丁坐标和残差帧。除非重复区域相当大或重复使用很多次，否则这些开销会压倒节省。
- 在 libjxl 中，低于 effort 7 时必须显式启用补丁，因为它们目前有性能问题。
对非摄影图像，“它们应该是矢量图”的说法站不住脚，因为很多图像可以是矢量图但并不是，也无法被完美矢量化。“世界应该不同”不能成为不针对世界实际样子做优化的正当理由。
很容易认为这些点意味着上限高于 libjxl 所能达到，我们可以做得更好；但我不确定它能迅速超越优化良好的 AVIF 编码器，因为它的编码工具更不直观（也可能更弱）。
解码时间
JPEG XL 的规范灵活得惊人。除编码工具外，它支持最多 4096 通道、任意色深、渐进解码、JPEG 重压缩等。很多功能在 Web 上并不广泛有用；你需要 4 个通道（RGB/YUV + alpha）、支持 HDR 的合理色深（10 位就够），以及快速加载能力。
渐进渲染（AVIF 支持）会在完整图像到达前解码一个低保真版本。AVIF 有一段时间不支持渐进渲染，那段时间我认为它被严重夸大。现在 libavif 已实现（它一直可行），讨论似乎结束了。结果自己会说话：
这来自 JPEG-XL 信息网站，AVIF 在仅约全图大小 2-3% 时就显示出可用图像，远早于 JXL。再加上 AVIF 整体更小，这是明显的胜利。我截了图，因为 AVIF 渐进解码只在 Chrome 中有效，使用的是浏览器原生解码器；JPEG XL 使用 polyfill，因为即使在支持它的 Safari 中，渐进解码也不可用。
JPEG 重压缩是指把 JPEG 无损重新编码为 JXL 并节省比特；常引用的数字是节省 20%。但用户要在解码时间上付出代价，重压缩后的 JPEG 解码时间约长 33%。现代消费设备很强大，但说这些节省是“免费”的具有误导性。
说到这个，解码时间与最好的相比没有竞争力：
公开讨论中，AVIF 被认为解码慢；那 JXL 算什么？这也是 10 位 AVIF，所有图像都是同一源的尺寸匹配编码。JPEG 为 2,478,828 字节，JPEG XL 为 2,599,428，AVIF 为 2,649,949，WebP 为 2,693,794。WebP 大了超过 90kb，却仍比 jxl-rs 配合 wpd 解码快 10 倍以上。
由于该编解码器的表现力，可以造出解码时间长到离谱的图像。比如这个例子（打开需谨慎）计算到 33,599 的质数，在我的 M5 Pro 上用 Rust 解码器解码需要 17.43 秒用户时间。还要记住，这正是正在进入 Chrome、Firefox 等的解码器——那张质数墙图像只有 1,918 字节，所以很快就能轻易对低端设备发起 JXL 炸弹攻击。你已经可以在网页里放几十张这样的图，拖慢 Apple 设备，因为 Safari 原生支持 JPEG XL。
结论与观点
我认为 Web 编解码器应该专门构建、高效，并窄范围针对 Web 需求。WebP 范围有点太窄，但想法是对的；AVIF 的容器可以更好，AV1 规范可以更具体地规定图像某些属性的处理（例如规范化的 4:2:0 上采样），但 AVIF 因 AV1 一直是 Web 的必然补充，并受益于非常成熟的生态。
那我们还需要 JPEG XL 吗？它一点都不窄，设计上就是要对所有人做所有事。我认为很多其他用例需要这个，但 Web 需要节省带宽、快速解码、防止踩坑；我不觉得 JPEG XL 甚至能像 WebP 那样合适。更别说现在还有额外的兼容性麻烦：任何只是想从互联网下载图像并在别处使用的人都会遇到。让 WebP 被广泛采用已经够难了，我不认为为 AVIF 和 JPEG XL 再爬同一座山、把痛苦翻倍是值得的。尤其当 JPEG XL 似乎没有给 Web 平台增加任何东西时。
3 年半前我说过：
我想要一个 AVIF 和 JPEG XL 都能存在的网络，开发者根据其优点决定用哪种格式。[……] 在我看来，JPEG XL 和 AVIF 有根本不同的优势，适合不同用例。
当时，JPEG XL 在中高保真有损图像压缩上还是强得多的竞争者。现在 AVIF 统治了整个保真范围，JPEG XL 唯一真正的优势已经消失。
JPEG XL 来自 Cloudinary 和 Google，但我认为讨论它的方式没有把这一点讲清楚。另外，JPEG XL 和 AVIF 都免版税。由于围绕 Google 浏览器市场主导地位的政治、AV1 来自 Google、以及 Google 的 WebP 争议，我的看法是，大多数支持 JPEG XL 的论点来自想要一个开发者选择更多的 Web，而不是想要技术上更优的图像编解码器。我理解这一点，也认为 JPEG XL 仍可在 AVIF 永远做不到的 Web 之外繁荣。我早先还写道：
我目前乐观的希望是，JXL 在 Web 之外流行起来，被使用 Adobe 套件或替代工具的专业人士、相机厂商、智能手机 OEM 和其他人注意到，并开始更认真地考虑 JXL。
JPEG XL 不是没用；对 Web 之外的用例，它确实是引人注目的技术。我只是个人不确信我们需要它很快进入浏览器。
评论
讨论围绕JPEG XL是否应在Web图像领域推广，实用主义者担忧额外格式加剧兼容痛点并疑其政治驱动，而技术派则指出评测偏差并强调JXL在专业管线与无损场景的不可替代性。
认为引入JPEG XL对Web是额外负担且动机偏政治
- 担心再添格式重演WebP推广艰难，且JXL未给Web带来新能力，跨平台下载使用更麻烦（较多人）
- 认同非照片图像“应转矢量”不现实，格式优化须基于世界现状而非理想（较多人）
- 质疑若Web不采纳，相机与编辑工具链采用动力不足，转码成本难抵收益（少数人）
- 指出决策常非纯技术，意在打破单一巨头解码格式垄断，工程上吃亏但迎合各方（较多人）
- 建议直接沿用设备已有HEIC避免无谓转码（少数人） > 不该为AVIF和JXL重复爬坡增加痛苦，尤其JXL似乎没给Web平台添什么新东西（@dmix）
认为AVIF的渐进渲染宣传有误且JXL才是真渐进
- 纠正原文称AVIF支持渐进渲染之误，指出其仅是低分辨率图层，JXL才支持从全分辨率数据派生的真正渐进解码（较多人） > AVIF所谓的渐进渲染只是先加载低分辨率缩略图，而JXL能从全分辨率数据派生低质预览，才是真渐进（@aniviacat）
认为JXL被不公平对待且技术潜力未耗尽
- 指出JXL发展慢因浏览器拒用，曾比AVIF惊艳，应投力优化再比而非当下定论（较多人）
- 强调AVIF脱胎视频Codec，硬件解码或限4:2:0，对插画截图像素艺术劣质，且无损压缩对Web比较场景亦重要（较多人）
- 新格式在Web之外价值更明，不应与WebP历程简单等同（少数人） > 这些新格式在Web之外表现更好，所以并不是“同一座山”（@eviks）
认为JPEG XL更适合作为专业图像与相机RAW桥梁
- 提议作无反相机RAW灵活易预览，或反促Web采用（少数人）
- 已入DNG标准，新手机普遍内置编解码（少数人）
- 类比OpenEXR用于图像处理管线，个人无损转JPEG省空间（少数人）
有价值的补充
- JPEG XL与WebP均含双模式：无损JXL胜WebP胜PNG，有损AVIF胜JXL胜WebP胜JPEG（@Dwedit）
- JPEG XL质数预览可成DoS，Finder耗满核心与4G内存15秒，但也炫示格式灵活（@nneonneo）
- 渐进AVIF近期才实现，与JXL对比出乎意料（@adzm）