1.9KB 炸弹让死忠粉倒戈
2023 年 Chrome 将 JPEG XL 踢出支持列表时，社区爆发了强烈的抗议，多数人将其视为 Google 偏袒自家 AVIF 格式的政治操作。三年后，一个用 Rust 编写的 JXL 解码器 jxl-rs 尝试重新进入浏览器，引发了 Firefox 和 Chrome 可能翻案的猜测。就在此时，曾经为 JXL 站台的压缩工程师 Gianni Rosato 却给出了截然不同的结论。他曾在 Interop 2024 大会上公开推广 JXL，并与格式的两位主要作者 Jon Sneyers 和 Jyrki Alakuijala 多次交流。这次立场反转并非外部视角的批评，而是内部支持者基于工程数据的重新审视。
让浏览器厂商最忌惮的是格式设计带来的安全漏洞。一张计算 33,599 以内素数的构造图只有 1,918 字节。在 M5 Pro 旗舰芯片上用 Rust 解码器跑完，竟耗费 17.43 秒的用户态时间。Rosato 警告，这正是要进入 Chrome 的解码器。若在网页里塞入几十张这种图，足以拖垮低端设备，也能拖慢原生支持 JXL 的 Apple 设备。
**这种图灵完备式的解码机制把图像格式变成了一个现成的拒绝服务攻击武器。**为了支持规范中的庞杂功能，解码器付出了难以承受的计算代价。
规范过度灵活徒增计算包袱
JXL 规范设计的初衷是试图包揽所有场景的需求。它支持高达 4096 个通道、任意色深、渐进式解码以及无损重压缩。Web 分发端真正需要的只有 4 个通道（RGB 或 YUV 加上 alpha）与 10bit 色深，外加快速且安全的加载能力。这种把所有功能打包给所有人的设计，让解码端背上了沉重的包袱。
同一源图在 size-matched 编码测试下的数据揭露了收益的匮乏。将文件压制到相近体积，JPEG 为 2,478,828 字节，JXL 为 2,599,428 字节，AVIF 为 2,649,949 字节，WebP 为 2,693,794 字节。JXL 在这组测试中甚至比古老的 JPEG 还要大。作者借此指出，在特定的文件大小区间内，它并没有赢过 JPEG 多少。
无损 JPEG 重压缩功能确实能省下 20% 的文件体积。其代价是重压后的 JPEG 解码时间增加了约 33%。省下来的传输比特并不是免费的，设备必须消耗更多算力来偿还。即便是体积最大的 WebP，其解码速度也比用 jxl-rs 解码 JXL 快了 10 倍以上。复杂的规范设计没有转化为网络传输优势，反而拉高了解码耗时。
图：解码时间对比图，jxl-rs 解码耗时远高于 WebP。来源：Gianni Rosato 博客
编码器缺失三件核心工具
抛开安全和耗时，JXL 在本职的压缩效率上也未能兑现超越同行的承诺。在 SSIMULACRA2 客观指标测试中，libjxl 的感知优化表现全面落后于 AVIF 依赖的 libaom 的 perceptually-optimized tune。实际跑分拉出了明显的差距，巨大的落差直接暴露了底层工具链的缺失。
图：SSIMULACRA2 客观指标对比图，libjxl 曲线明显靠下。来源：Gianni Rosato 博客
JXL 编码效率不佳的根源在于缺失了三件核心工具。libjxl 至今没有方向预测模式（directional prediction）。它的 VarDCT 块从 2x2 到 256x256 都无法进行精准方向预测。去块滤波（DLF）同样缺席。现有的 gaborish 和 EPF 组合加起来也无法替代真正的去块滤波。这导致图像在低码率下依然存在明显的蚊子噪声（mosquito noise）。
XYB 色彩空间的设计也暴露了工程问题。这套基于直觉的色彩空间配合 libjxl 对 B 通道的激进量化，导致色彩保持能力大打折扣。新一代 JXL 编码器的作者在开发时，必须手动撤销这些激进的量化操作。只有这样才能勉强维持正常的色彩保真度。
补丁机制拖垮非照片图像压缩
在处理非照片图像（如图标、UI 截图、插画）时，JXL 的残差编码设计十分别扭。它采用的补丁（patches）机制比 AV1 的 Intra Block Copy（IntraBC）难用得多。在 AV1 中，一个 IntraBC 块的成本大约等于一个运动矢量加上残差系数。JXL 构建相同效果的开销却大得惊人。它的一套构造可能需要参考帧、帧头、裁剪、混合信息、补丁字典项、补丁坐标以及残差帧。
当图像中的重复区域不够大时，补丁机制巨大的额外开销会吃掉所有压缩收益。由于性能代价过高，libjxl 在 effort 7 以下的压缩等级中直接默认关闭了补丁功能。
在无损压缩领域，JXL 的表现同样缺乏说服力。测试表明它只比无损 WebP 小了约 11.9%。更关键的是，用来论证优势的测试集并不符合 Web 的真实情况。数据集中包含了 157MP 的超高像素照片、10MP 的插画和 27MP 的书籍扫描件。在真实的 Web 流量中，无损内容的占比微乎其微，为这种体量的场景引入庞大解码器在工程逻辑上站不住脚。
竞争对手抹平渐进渲染壁垒
过去几年，JXL 阵营一直将「渐进式解码」作为防御其他格式的核心武器。现在，AVIF 已经加入了这项特性的支持。在 JXL 自己的对比页面上，AVIF 仅需加载整图 2-3% 的体积，就能呈现出可用的图像轮廓。**格式竞争中的独占优势，已经被对手在工程迭代中抹平。**作者在截取对比图时特别注明，AVIF 的渐进解码目前已在 Chrome 可用。而 JXL 在 Safari 里也只是通过 polyfill 来实现。
图：AVIF 渐进式解码截图，约 2-3% 体积即显示可用画面。来源：Gianni Rosato 博客
Web 编解码器应当是窄范围、目标明确（purpose-built）且能防范边缘异常情况（防 foot-gun）的产物。作者认为，多数支持 JXL 进浏览器的声音，要的是开发者选择自由，而非客观更优的技术本身。
Web 端拒收，专业生态仍有退路
JXL 远未走到绝路，争论也远未结束。作者坦承「不存在编码器基准，只有编码器实现的基准」。格式规范的理论上限确实高于 libjxl 目前达到的水平。但他判断 libjxl 短期内追赶无望。在 Web 之外的专业领域，比如 Adobe 系工具链、相机厂商和手机 OEM 中。它免版税的特性以及 JPEG 委员会的背书，依然赋予它真实的商业价值。
脱离了严苛的浏览器安全沙盒和解码时间限制，格式理论上的高天花板才能在本地创作环境中得到释放。但在分发端，浏览器面对的是性能参差不齐的设备，以及无孔不入的恶意代码构造。当一个 1,918 字节的文件能让旗舰芯片停转 17 秒时，争论它比无损 WebP 能多省 11% 体积，在真实的工程决策中已经没有分量。
参考链接：
- The Case Against JPEG XL
- Hacker News Discussion
- Lobsters Discussion
