为什么 JPEG XL 不适合 Web？
The case against JPEG XL
作为图像压缩领域的从业者，我曾是 JPEG XL 的坚定支持者，但深入分析后却发现它并不适合 Web。虽然 JPEG XL 技术先进，但在有损压缩效率上已被 AV1 和 AVIF 超越，且缺乏方向预测等关键工具。更致命的是，其解码速度缓慢，甚至存在被恶意利用导致设备卡顿的风险。Web 需要的是专为节省带宽和快速解码设计的格式，而非试图满足所有场景的 JPEG XL。
“世界应该不同”并不是针对优化现实世界现状的正当理由。
HN 评论区
378- arthur-st
这篇博客文章很奇怪。鉴于它出自一个专有且收费的商业编码器开发者之手，在那些号称关于 JPEG XL 的图表中却包含了他们即将推出的 "aperture-alpha" 编码器，这让人感觉像是一篇营销软文。当然，他们在整篇文章中都在推销他们的 Iris-WebP 编码器，暗示如果你没向作者付费购买，你就没有正确使用 WebP，大概吧？
此外，还有一些方法论上的怪癖。例如，JPEG XL 的解码测试是在单线程模式下进行的，而它本身是为多线程解码优化的（在这种模式下 AVIF 会出现分块伪影）。另外，测试命令是 "jxl_cli --speedtest"，这意味着基准测试的时间包含了 "--speedtest" 标志的预热过程，而不是纯粹的解码时间。
另一个例子是渐进式渲染，这里选择的比较时间点是一个有利于 AVIF 的局部最大值。JPEG XL 生成完整帧的速度比 AVIF 快得多，从比如 96,256 字节开始，直到完整图像加载完毕，它的效果都比 AVIF 好。
- cbolton
这篇文章提出了一个很好的观点：JPEG XL 很棒，但与 AVIF 相比，它并不特别适合典型的 Web 使用场景。但结论并不成立。拥有一个浏览器支持的优秀且通用的格式是非常有用的！
也许为了节省 20% 的文件大小而对我的网站 JPEG 进行无损重编码并不值得多花 33% 的解码时间，也许网站也不需要非常高分辨率的图像或超过每通道 12 位的色深。但我的个人档案绝对可以用到这些，而且很高兴这样的文件可以在任何地方查看，无需专用工具，包括在内网和 Web 上提供。
总之，JPEG XL 轻松击败了 AVIF 在那些不那么长的长尾使用场景中，而且到处都有兼容的查看器非常有用。随着 JPEG XL 成为 PDF 的一部分，它很快也会成为常见的使用场景。
至于文章的其余部分：基准测试部分有一些有趣的观点，但我认为在 JPEG XL 的采用周期中，现在下结论还为时过早。不过有一点让我很困扰：只有一个图片对比（副标题是“结果不言自明”），我觉得这非常具有误导性：它只是选取了“接收字节数”曲线上的一个点，该点对 AVIF 最有利，而 JPEG XL 表现不佳。你自己试试就会看到，JPEG XL 在 2KB 时就已经显示出内容，而 AVIF 直到 8KB 才显示，且在 100KB 之后 JPEG XL 看起来比 AVIF 更好。
- Daiz
我对 AVIF 的一个潜在重大问题是，因为它基于视频格式，AVIF 获得的任何硬件解码支持可能仅限于常见的视频场景。这可能导致例如硬件解码器仅支持 4:2:0 YUV，因为那是 AV1 Main Profile（因此也是 AVIF Baseline Profile）的上限。而 4:2:0 对于某些类别的图像（如各种插图、截图等）来说非常不合适。我不希望看到一个现代格式严重阻碍有损 4:4:4 图像压缩的 Web 环境。
此外，良好的无损压缩对 Web 也绝对重要。有损图像并不能在所有情况下使用——例如在比较压缩质量时（尤其是视频）！
编辑：再举一个例子，像素画是一个完整的艺术领域（至今仍然非常活跃），其中无损压缩是必须的，而 4:2:0 对质量来说绝对是灾难性的。
- Feathercrown
“对于非摄影图像，‘它们应该是矢量图’的论点站不住脚，因为许多图像可以是矢量图但实际上不是，而且它们无法被完美矢量化。‘世界应该不同’并不是针对优化现实世界方式的合理辩护。”
这是一个很好的段落。我发现人们经常忘记应用最后一句话。
- BugsJustFindMe
这篇博客文章提出了两个相互矛盾的论点：
1) AVIF 现在已经有了巨大的改进，以至于它在以前不擅长的方面实际上变得相当不错。
2) 尽管每种编解码器的性能都随着时间推移而大幅改进，但 JXL 将不会得到改进。
撇开其他一切不谈，包括几个明显的方法论错误，拒绝想象未来的实施工作能取得任何成就，这是违背历史且难看的。有些人可能会称之为虚伪。
- nneonneo
那个 JPEG XL 质数计算是一个相当丑陋的 DoS（拒绝服务）攻击。只是在 Finder 中选中它，打开预览窗格，我的 Mac 上的每个核心都在 QuickLookSatellite 中满载运行，同时消耗了 4GB 内存，持续了大约 15 秒。对于一个 2KB 的图片来说，这不算太差。看来 Apple 没有对他们的 JXL 预览器设置合理的限制。
不过，这确实是一个非常酷的演示，展示了该格式的能力。我不完全确定图像格式是否应该如此灵活，但我仍然印象深刻。
- meinersbur
> 我认为 Web 编解码器应该是为 Web 量身定制的、高效的，并且范围狭窄，仅针对 Web 的需求。
这篇文章低估了通用性的用处。我不同意。我不希望玩“哪种图像格式最适合这张图片和这个使用场景”的游戏，也不希望不得不在它们之间进行转码。例如，如果我能有一个 HTML 画廊，直接显示我硬盘上存储的图片，那就太好了。今天这些图片是 JPEG，因为它是最低公分母。WEBP 和 AVIF 不被摄影工具支持（例如 https://support.captureone.com/hc/en-us/articles/36000262921...），而且我不指望会添加支持，因为它们并不是为摄影而设计的格式。
- F3nd0
在我看来，AV1（AVIF 使用的编解码器）近年来得到了更多的发展，这得益于它在视频领域的广泛采用。JPEG XL 没有看到同样大规模的采用，也许很大程度上是因为 Chrome 以可疑的理由拒绝了它（尽管之前急切地强制采用了 WebP 和 AVIF）。参考实现的开发步伐变得非常缓慢，而且它最近获得的适度关注似乎已经转移到了新的 Rust 解码器上，一旦浏览器最终决定他们想要开发者提供这个。
考虑到这一点，我认为这两种编解码器之间的比较并不公平。JPEG XL 曾经比 AVIF 令人印象深刻得多；很高兴人们（包括作者）能够推动 AVIF 向前发展，但在 JPEG XL 上也未进行类似的认真努力之前，我觉得它们编码器之间的比较并不能说明编解码器本身的情况。作者确实猜测了 JXL 编码器可以改进多少，但这只是猜测。除非经过尝试，否则我们无从得知。特别是考虑到整个不幸的历史，我认为 JPEG XL 真的、真的值得尝试。
- SmasherEpilepti
还没有人提到，但 JPEG XL 在潜力和灵活性上似乎接近 OpenEXR。它似乎更像是与这类东西竞争——用于图像处理流程中的数字艺术流程——而不是像 JPEG、WEBP 或 PNG 这样的东西。
话虽如此，我已经将我的个人 JPEG 转换为了 JPEG XL，因为你可以在这两者之间无损地来回转换，在 JPEG XL 中文件更小且没有质量损失，所以我获得了免费的存储节省，如果需要，还可以逐字节恢复原始 JPEG。
- IvanK_net
注意，JPEG XL 已被添加为 DNG 文件（Digital Negative - 存储包含相机原始传感器数据的原始图像）的一种可能压缩方法。
因此，在过去几年中，所有新款 iPhone 和几乎所有 Android 手机（主要是三星手机）都已经包含了 JPEG XL 编码器/解码器（用于生成这些 DNG 文件）。