在 Chrome 中发布 JPEG XL

原文 ↗ Hacker News 讨论 ↗

Google 决定在 Chrome 中重新启用 JPEG XL，被视为这一图像格式的一个重要转折点。JPEG XL 承诺更好的压缩、高位深和 HDR 支持、渐进式加载，甚至可以对传统 JPEG 做无损转码。评论者围绕 JPEG XL 与 AVIF、WebP 的比较展开讨论，权衡压缩效率、无损性能、解码速度和实际工具链，同时也强调了过去的安全问题，以及 Google 先移除支持、如今又恢复支持背后的政治因素。许多人预计，随着主要浏览器、操作系统厂商，甚至 PDF 生态的支持，JPEG XL 可能会成为如今碎片化的 JPEG、PNG、WebP、AVIF 和 HEIC 的长期通用后继者。

Chrome 中 JPEG XL 的历史与动机

  • JPEG XL 的支持已被加入 Chrome，约在 2023 年被移除，如今又正在重新加入。
  • 早先的移除官方归因于需求低、与 AVIF/WebP 功能重复；一些评论者认为，安全成本、内部政治，或联盟政治（AVIF/AOM）也起了作用。
  • 这次逆转的原因各有说法：更安全的 Rust 解码器（jxl‑rs）、更广泛的生态吸引力、Apple/Safari 的支持（包括 iPhone ProRAW JXL），以及采用 JXL 的 PDF 规范更新，这实际上迫使浏览器为 PDF 渲染提供支持。

技术特性与对比（AVIF、WebP、PNG、JPEG）

  • 许多人将 JPEG XL 视为 JPEG/PNG/WebP/AVIF 的“通用后继者”：
    • 有损和无损，高位深（HDR）、广色域、额外通道、图层、页面、动画、深度图。
    • 对现有 JPEG 的无损重压缩，体积更小且没有代际损失。
  • 有几位表示，JPEG XL 在高质量照片和无损场景上胜过 AVIF/WebP/PNG，包括大文件集合和机器视觉数据集。
  • 也有人认为，AVIF 在极低码率和“网页主视觉图”上更高效，而且现代 AVIF 编码器已经弥补了 JXL 许多被认为的优势。
  • 一篇详细的“反对 JXL 的理由”认为：
    • AVIF 更适合典型网页有损用途。
    • JXL 在无损上相对 WebP 的收益（约 10–13%）不足以证明更高的解码成本合理。
    • JPEG 转码的收益可能会被客户端更慢的解码抵消。
  • 反驳观点：线程中的许多基准和实际测试显示，JXL 在照片和无损方面的质量/体积表现更好，而且 jxl‑rs 现在在性能上已可与 libjxl C++ 竞争，甚至更快。

安全性与实现

  • 早期的 C/C++ libjxl 有多个漏洞，被认为攻击面过大。
  • Chrome 和 Firefox 正在采用 Rust 解码器，以满足内部“二选一”安全准则（内存安全、沙箱、可信输入）。
  • 有人争论，仅靠 Rust 是否足够，而不配合沙箱。

生态、用户体验与兼容性

  • 浏览器：Safari 已支持 JXL（但没有一些高级功能，如渐进式动画）；Chrome 稳定版现在支持；Firefox 将在即将到来的版本中默认启用。Android WebView 预计会跟进 Chrome。
  • 操作系统/应用：macOS/iOS 系统查看器、一些编辑工具和 PDF 技术栈支持 JXL；工具质量参差不齐（有些编码器被认为很差）。
  • 许多人抱怨过去 WebP/HEIC 的兼容性痛苦（LMS、Telegram、Instagram、桌面应用），并担心再来一轮碎片化；也有人指出，JXL 在浏览器之外的采用速度已经比 WebP 当年更快。
  • 渐进式渲染因无需大量缩略图而受到称赞，但也有人担心用户体验（何时算“加载完成”不明确）以及若缩略图与最终图像不一致时可能被滥用。

采用与部署方面的顾虑

  • Web 开发者会关注 caniuse 的支持率；几位表示，在支持率达到约 80–90%，或至少等到下一个 Firefox ESR 之前，不会使用 JXL。
  • 编码成本是动态或即时流水线中的主要顾虑；之前的 AVIF 实验曾导致 CPU 和成本大幅上升。
  • 推荐做法包括通过 <picture> 提供 JXL，并以 JPEG/PNG/WebP/AVIF 作为后备，以及在大范围生产使用前等待几个浏览器发布周期。

更广泛的理念

  • 一些人希望有一种统一的、现代的“就用这个”图像格式；另一些人则偏好一套小而专用的格式组合（例如，AVIF 用于网页有损，PNG/WebP 用于无损）。
  • 怀疑者认为 JPEG/PNG 依然“够用”且具备普遍兼容性；支持者则强调移动数据节省、存储、更好的画质、HDR/位深需求，以及长期归档价值。