Web 场景中的 JPEG XL 与 AVIF

AVIF 容器与部署方面的顾虑

• 有人认为 AVIF 的基于容器设计有利于长期部署：网站只需要一次写“AVIF”；未来的编解码器（AV2 等）可以复用同一容器，而浏览器只需升级解码器。
• 也有人反驳说，如果客户端没有对应编解码器，容器并不能帮上忙：没有解码器，结果还是一张损坏的图片。
• 真正的瓶颈往往是站点侧逻辑（内容类型白名单、图像处理流水线）跟不上浏览器支持；容器也许能减少重复集成工作，但内容协商和 codecs 参数仍然相关，而且依然很麻烦。

压缩性能与使用场景

• 线程里的共识是：对于典型的网页有损图片，尤其是截图/插图，AVIF 目前在体积—质量权衡和速度上更占优。
• JPEG XL 被认为在以下方面更强：
  • 无损和“近无损”的高质量图像。
  • 对现有 JPEG 的归档/转码，在不额外损失的情况下缩小体积。
  • 超高位深和大分辨率图像、摄影，以及非网页领域。
• 有人指出 JPEG XL 在非常高的质量档位会追平甚至略胜，但这在带宽敏感的网页投放中并不常见。
• 一些评论者仍更偏好用 AVIF 存个人图片集和截图；另一些人计划把 JPEG XL 用于归档和更便于编辑的图像。

编码器、指标与格式潜力

• 多条评论强调，这种对比反映的是编码器成熟度，而不是格式理论极限。
• AV1/AVIF 编码器多年来持续改进；JPEG XL 的编码器则停滞、分散精力，或面向了不同目标。
• 有人认为 JPEG XL 在本质上更受限制；也有人把这称作有根据但并不权威的猜测。
• 感知指标（SSIMULACRA2、Butteraugli）可用于调参，但可能与人类偏好不一致。据称有一个高度针对某个指标调优的编码器，在某些情况下主观观感更差。
• 更快、支持 GPU 加速的 JPEG XL 编码器以及新的 Rust 工具链正在出现；有人乐观地认为 JPEG XL 仍有显著提升空间。

动画、渐进式渲染与 UX 预期

• 很多人强烈认为“动画图像格式”（动画 JXL、把 AVIF 当 GIF 用）在运动表现和播放效率上都不如真正的视频。
• 反方观点是：类似 GIF 的动画有不同的 UX 预期（没有控制、循环播放、按图像看待），所以基于图像的动画仍然有用。
• AVIF 现在支持不错的渐进式渲染；这缩小了 JPEG XL 被认为具有的一项网页优势。
• 有些人非常在意放大后的细节和高光保留；也有人觉得当前 AVIF 的伪影在日常观看中已经可以接受。

实现、安全性与生态政治

• 浏览器在添加编解码器时非常谨慎，因为这会带来维护成本、二进制体积和攻击面问题；这推动了基于 Rust 的解码器，也限制了对“众多格式”的支持。
• 可插拔编解码器或沙箱化解码器的提议时有出现，但浏览器厂商担心安全性和复杂度。
• 多条评论批评某个占主导地位的浏览器早先拒绝 JPEG XL 的做法如何打击了它的发展和采用，而后来的比较又把 JPEG XL 描述成“来得晚而且更差”。
• 也有人提到 AVIF/AV1 的专利风险；JPEG XL 目前看起来更干净一些，尽管这一点并未被深入展开。