JPEG XL 图像格式现已登陆所有主流浏览器，因此我打算仔细研究一下，它与 AVIF 等其他格式相比，在网页使用场景中各自擅长什么、不擅长什么。后面我会用示例和基准测试展开完整细节，没时间的读者可以先看要点。

JPEG XL 现在已经登陆所有主流浏览器，所以我打算仔细对比一下它和其他格式相比的优缺点。

结论

我会在后文结合示例和基准测试展开详细分析，但如果没时间看，下面是核心结论：

• 网页有损照片方面，AVIF 的文件几乎总是比 JPEG XL 更小。 默认 effort 设置下，最佳 JPEG XL 版本通常比同等 AVIF 大 15–25%；最高 effort 下差距缩小到通常 6–20%。但也有例外，JPEG XL 会接近甚至击败 AVIF，所以想为某张图要绝对最佳结果，值得两个都试。典型例子见 F1 图片，例外见黄鼠狼图片。
• JPEG XL 编码器本身非常关键。 较新的 jixel 编码器通常比 libjxl 产出更小的文件，除非图像带有精细的透明通道。人物图片就是一个例子。
• 对于截图和插画，AVIF 远优于 JPEG XL。 同等质量下，JPEG XL 在默认 effort 下大 30–90%，最高 effort 下大 20–70%。有损 AVIF 就能很好处理这类图，除非真的需要逐位精确，否则不必用无损格式。见截图和插画示例。
• 对于带透明通道的图像，AVIF 远优于 JPEG XL。 libjxl 版本在默认 effort 下大 31–44%，最高 effort 下大 61–70%。jixel 总是无损编码透明通道，导致其文件是 AVIF 的 2–3 倍。
• 综合考虑文件大小时，AVIF 通常编码更快、占用内存更少。 jixel 比 AVIF 更快且内存占用更低，但文件通常明显更大，因此整体上 AVIF 更优。F1 图片是其中一个例子。
• AVIF 解码更快。 在中等质量下，JPEG XL 解码通常要花 2–3 倍时间；但在极高质量下差距缩小，Chrome 有时解码 JPEG XL 反而更快。人物图片是一个例子。
• AVIF 和 jixel 值得用更高的 effort 设置，但 libjxl 不值得。 libjxl 的更高 effort 慢得多、内存占用大得多，效果却几乎没提升，有时文件甚至比默认 effort 更大。截图就是个例子。
• AVIF 的 4:2:0 模式（半彩色分辨率）不应作为默认值。 它很少能缩小文件，还会更难达到高质量，尽管编码和解码更快。如果没时间两个都测，就用 4:4:4。F1 图片是其中一例，截图则是例外。
• 所有编码器的质量设置都挺可靠。 用同一个质量设置时，不同图片的结果质量会有波动，但所有编码器的波动方向一致，而且看起来合理。
• 在高 effort 下，渐进式 JPEG XL 基本是免费的。 jixel 最近加入了早期渐进预览支持，在最慢设置下几乎不增加体积，但在默认设置下文件会大 12%。Firefox 和 Chrome 支持渐进式 JPEG XL；Safari 仍会渲染最终图像，但不显示渐进预览。不过这种渐进渲染的用户体验是否好，见后文示例和数据。
• AVIF 也支持渐进渲染！ 目前仅限 Chrome，Firefox 正在开发中。它比渐进式 JPEG XL 更复杂，但能更好控制预览外观，文件通常更小，解码也快得多。
• 在 HDR 方面，JPEG XL 缺少 gain map，相比 AVIF 是个明显短板。 JPEG XL 格式支持 gain map，但浏览器解码器不支持，编码方案也混乱且处于实验阶段。比较不带 gain map 的 HDR 内容时，我用的两个质量指标分歧很大，但都同意 JPEG XL 比 AVIF 文件更小。
• JPEG XL 能把现有 JPEG 再小 9–20%，且没有额外损失。 除小图外，解码速度也持平或更快。
• 无损压缩方面，JPEG XL 明显胜出。 无损 WebP 对照片大 9–17%，无损 AVIF 大 30–120%。但网页上几乎从不需要无损图。如果确实要在网页用（比如我在本页这样），要注意 jixel 的更高 effort——它常产出于解码过慢的文件。
• 动图格式依然是个蠢主意。 请别用它们。若非要了解，可见动画部分。

就网页用途而言，我目前默认会用 AVIF 4:4:4，并尽可能用最高的 effort 等级。如果觉得 AVIF 产出的文件异常大，我会用 jixel 试一下 JPEG XL，看它是否更好。

AVIF 和 JPEG XL（通过 jixel）最近都有了巨大改进，所以这个建议未来可能会变。这方面有很多错误信息，别轻信，拿自己的图片去测。

AVIF 那边的人认为 JPEG XL 在技术上不如 AVIF。这可能是真的，但本文只关注当前实现下的实际结果。

测试方法

我写了一个基准测试脚本，用各种编码器和设置编码图像并记录数据。使用的编解码器版本是撰写时的最新版：

• avifenc 1.4.2
• libjxl 0.12.0（使用其 cjxl 编码器）
• jixel 0.4.2（git f487299），另一个 JPEG XL 编码器
• cwebp 1.6.0（文章后面会用到无损 WebP）

我选了一组图片，大部分编码到 1598 像素宽——这是本博客图片最大显示宽度的 2 倍，这样在高密度屏（大多数用户都有）上看起来依然清晰。因此，如果你在小屏或低密度屏上看，体验会不完整。基准测试跑在 2024 款 MacBook Pro（M4 Pro）上。

有损压缩——F1 图片

我第一次写 AVIF 时用的就是一辆 F1 赛车，这次又用了它！我把图像按各种编码器质量编码，挑出最接近特定 SSIMULACRA2 分数（JPEG XL 团队做的感知图像质量指标）的版本。50 算中等质量，70 高，80 很高，90 视觉无损。不过我不确定这些评级是否考虑了高密度屏。全篇的视觉对比都使用各编码器的最高 effort，除非最高 effort 反而让文件变大（确实会发生）。

就展示性配图而言，我更看重性能，个人觉得上面 70 的结果可以接受。放大看有质量损失，但我更倾向于用 VisualViewport API 在放大时加载更高分辨率图，而不是让所有人下载都变大。低质量下能看出两者策略差异：细节损失差不多，但 AVIF 倾向于抹平原图，JPEG XL 则引入更粗糙的纹理。另外，中等质量（50）下，我觉得 AVIF 和 libjxl 比 jixel 好看；jixel 在 BWT 标志周围有明显噪点，前翼上的 Microsoft 文字也更难辨认，这让我有点怀疑这个指标。

总之，下面是我对结果的解读：

• 文件大小：AVIF 胜。 默认 effort 下，同等质量的最佳 JPEG XL 比 AVIF 大 14–17%；jixel 在中等/高质量是更好的 JPEG XL 编码器，libjxl 在极高质量略好。最高 effort 下，最佳 JPEG XL（jixel extraslow）比 AVIF（s0）大 6–15%。
• jixel 最慢设置略胜 AVIF 默认 effort，文件小 1–10%，高质量下收益最大。
• 编码时间：AVIF 胜。 默认 effort 下 jixel 比 AVIF 快 12–36%，但文件大 14–18%。要追平 AVIF 默认文件大小，jixel 得用 extraslow，耗时是 AVIF 的 18–27 倍。libjxl 默认耗时是 AVIF 的 1.5–2 倍，文件仍更大。
• 编码内存：AVIF 胜。 默认下 jixel 内存约为 AVIF 一半，但文件大 14–18%；extraslow 内存约 10 倍。libjxl 默认是 AVIF 的 2–3 倍，更高 effort 约 7 倍。
• 解码时间：AVIF 胜。 中等质量下 JPEG XL 解码要 2–3 倍时间，极高质量缩到约 1.5–1.8 倍。Safari 的 JPEG XL 解码器最慢。
• AVIF 值得用更高 effort。 s5 多花约 3 倍编码时间，文件小约 10%。
• jixel 也值得用更高 effort，直到 slow。 slow 比默认 fast 小 9–13%，耗时 3.7 倍；extraslow 再小 3–8%，但比 slow 慢 8 倍、内存 9 倍。即便如此，同等编码时间下仍是 AVIF 赢：AVIF s5 耗时和 jixel slow 相当，文件却小约 13%。
• libjxl 不值得用更高 effort。 最高 effort 几乎没提升，耗时却约 18 倍。
• AVIF 的 4:2:0 模式帮助不大。 编码/解码稍快、内存更少，但文件没明显更小，且更难达到高质量。

完整数据如下，供自行判断：

图像质量

第一张图是 SSIMULACRA2 分数（横轴为视觉质量，纵轴为文件大小，越低越好）。这类图很多，先说明一下：

• 橙色线是 libjxl 编码的 JPEG XL
• 绿色线是 jixel 编码的 JPEG XL
• 蓝色线是 AVIF
• 蓝色虚线是半分辨率色度（4:2:0 / 色度子采样）的 AVIF
• 颜色越深代表该编码器 effort 越高：libjxl 的 e10 是最高 effort；avifenc 叫 speed，s0 是最高 effort；jixel 从 fast（默认）到 extraslow
• 初始只显示默认和最高 effort，点图例可切换其他

用另一个指标 ColorVideoVDP 看质量，结果大致相同，只是它把 AVIF 和 JPEG XL 的差距拉得更大，也显示低质量下 AVIF 的 4:2:0 略有优势，但不明显。

编码性能

我博客上的图会用最高 effort 编码，愿意多等几秒换取用户加载更快。如果在服务器上大量编码，编码时间就更值得关注。下图是编码时间与 SSIMULACRA2 的关系。

编码内存占用

另一个在服务器上编码时可能关心的点是峰值内存占用。下图是峰值编码器内存与 SSIMULACRA2 的关系。

解码性能

解码性能也值得考虑。如果解码特别慢，文件大小的收益就会打折扣，尤其是图片从缓存加载时。JPEG XL 在极高质量下解码会突然变快（但仍慢于 AVIF），我认为这是因为一个边缘保留滤镜在低质量下要做更多工作。下图是解码时间与 SSIMULACRA2 的关系。

有损压缩——人物

我听说有人认为 AVIF 抹平细节的特性不适合人像，所以从 Unsplash 选了这张两个微笑女性一起看手机的照片。

基准测试结果：

• 文件大小：AVIF 胜。 默认 effort 下，最佳 JPEG XL 比 AVIF 大 17–24%；jixel 这次在全部质量区间都是更好的 JPEG XL 编码器，libjxl 则比 AVIF 大 30–50%，差距比 F1 图大得多。最高 effort 下，最佳 JPEG XL（jixel extraslow）比 AVIF（s0）大 12–17%。
• jixel 最慢设置这次没能追平 AVIF 默认 effort。 在中等/高质量下还大百分之几，只有极高质量才略微反超。
• 编码时间：AVIF 胜。 默认下 jixel 快 18–33%，但文件大 17–24%。即便 jixel 的 extraslow（耗时 25–39 倍于 AVIF）也只能在极高质量追平 AVIF 默认文件大小。libjxl 默认耗时是 AVIF 的 1.5–2.2 倍，文件仍更大。
• 编码内存：AVIF 胜。 默认下 jixel 内存约为 AVIF 一半，但文件大 17–24%；jixel extraslow 内存约 10 倍。libjxl 默认是 AVIF 的 2–3.3 倍，更高 effort 约 7 倍。
• 解码时间：AVIF 胜。 中等质量下 JPEG XL 解码要 2–2.9 倍时间，极高质量缩到约 1.3–1.7 倍。在最高质量区间，Chrome 里 libjxl 图像解码和 AVIF 一样快，但其他浏览器不是。
• AVIF 值得用更高 effort。 s5 多花约 3 倍编码时间，文件小 5–8%，收益比 F1 图小。
• jixel 也值得用更高 effort，直到 slow。 slow 比默认 fast 小 7–14%，耗时 3.9 倍；extraslow 再小 4–6%，但比 slow 慢 10 倍、内存 9 倍。同等编码时间下仍是 AVIF 赢：AVIF s5 耗时和 jixel slow 相当，文件小 8–17%。
• libjxl 在这张图上更高 effort 有点用。 和 F1 图不同，libjxl 最高 effort 能比默认小 4–11%，但耗时约 10 倍，文件仍远大于 AVIF 默认。
• AVIF 的 4:2:0 模式帮助不大。 和 F1 图一样。ColorVideoVDP 给它约 4% 的小优势，但 SSIMULACRA2 没有。

低质量下能看到脸上的抹平，但 AVIF 和 JPEG XL 都有。

图像质量

（图表说明同前：横轴 SSIMULACRA2，纵轴文件大小，以及 ColorVideoVDP 版本。）

编码性能

（编码时间与 SSIMULACRA2 关系图。）

编码内存占用

（峰值内存与 SSIMULACRA2 关系图。）

解码性能

（解码时间与 SSIMULACRA2 关系图。）

有趣的是，低质量下 jixel 在 Safari 里解码慢得多。

有损压缩——小熊猫

我加这张是因为它是 Squoosh 的默认图，但我想 sharp 的毛发线条让它和前面几张不同。事实上，即使在中等质量下，它和原图的差异也比其他图更不容易被我看出来。

结果比前两张接近得多：

• 文件大小：AVIF 险胜。 默认 effort 下，最佳 JPEG XL（jixel）只比 AVIF 大 2–6%；libjxl 差很多，大 10–18%。最高 effort 下，jixel extraslow 和 AVIF s0 基本打平，极高质量 jixel 能小最多 5%。但 ColorVideoVDP 不同意，认为最高 effort 下 AVIF 仍领先 5–12%。
• 编码时间：按 SSIMULACRA2 是 JPEG XL（jixel）胜。 默认下 jixel 比 AVIF 快 19–35%，文件只大 2–6%。更高 effort 下，jixel slow 用相同或更少时间产出与 AVIF s5 同大小或略小的文件；jixel extraslow 匹配或击败 AVIF s0，同时快 12–34%。但 ColorVideoVDP 给 AVIF 更大文件优势，所以不那么绝对。libjxl 默认耗时是 AVIF 的 1.3–1.9 倍，文件更大。
• 编码内存：JPEG XL（jixel）在较低 effort 胜。 默认下 jixel 内存比 AVIF 少 37–48%，文件只大 2–6%；slow 内存和 AVIF s5 相当、文件相近，但 extraslow 内存是 AVIF s0 的约 9 倍。libjxl 默认内存约为 AVIF 2 倍，更高 effort 6–7 倍。
• 解码时间：AVIF 胜。 中等质量下 JPEG XL 解码要 2–2.4 倍时间，但极高质量差距消失：jixel 文件在 Firefox 和 Safari 里解码和 AVIF 差不多快，在 Chrome 里快约 25%。
• 这张图上 AVIF 更高 effort 不那么值。 s5 多花 3–4 倍时间，只小 3–6%。
• jixel 值得用更高 effort，直到 slow。 slow 比默认 fast 小 6–14%，耗时 3.5–4.3 倍；extraslow 再小 2–9%，但比 slow 慢 9–14 倍、内存 9 倍。
• libjxl 不值得用更高 effort。 最高 effort 只比默认小 1–2%，耗时约 12 倍。
• AVIF 的 4:2:0 模式没用。 文件和 4:4:4 一样大。

图像质量

（图表说明及两张指标图。）

编码性能

（编码时间与 SSIMULACRA2 关系图。）

编码内存占用

（峰值内存与 SSIMULACRA2 关系图。）

解码性能

（解码时间与 SSIMULACRA2 关系图。）

有损压缩——黄鼠狼

我把玩这两个编解码器很久了，前面展示的照片很有代表性，都是 AVIF 赢。但偶尔会有例外，比如这张。

• 文件大小：JPEG XL 胜。 默认 effort 下，最佳 JPEG XL 比 AVIF 小 4–11%；libjxl 在中等/高质量是更好的 JPEG XL 编码器，jixel 在极高质量更好。最高 effort 下，jixel extraslow 比 AVIF s0 小 12–27%。这次 ColorVideoVDP 也同意。
• jixel 的 medium 设置在这张图上提升很大。 文件比 AVIF 默认小 11–25%，比 AVIF s0（最高 effort）小 4–18%。
• 编码时间：JPEG XL（jixel）胜。 默认下 jixel 比 AVIF 快 28–38%，文件同大小或更小。更高 effort 更一边倒：jixel medium 比 AVIF s5 快 37–65%，文件小 9–23%。libjxl 默认耗时是 AVIF 的 1.5–2.2 倍。
• 编码内存：JPEG XL（jixel）胜。 默认下 jixel 内存比 AVIF 少 14–24%，文件同大小或更小。AVIF s0 内存甚至更高（约默认 1.55 倍），文件仍大于 jixel medium（后者内存比 AVIF s0 少 41–55%）。libjxl 默认是 AVIF 的 2.4–3.6 倍，两个 JPEG XL 编码器的最高 effort 都是 10–18 倍。
• 解码时间：AVIF 胜，但 Chrome 高质量下除外。 JPEG XL 在 Firefox 和 Safari 要 1.3–1.9 倍时间；Chrome 里中等质量约 1.25 倍，但从高质量往上，JPEG XL 比 AVIF 快 11–36%。
• 和前几张不同，jixel 文件在 Safari 里解码不慢。 事实上比 libjxl 略快。
• 这张图上 AVIF 更高 effort 不太值。 s5 多花 3–4.5 倍时间，只小 1–3%；s0 能小 7–8%，但耗时约 50 倍。
• jixel 值得用更高 effort，直到 slow。 medium 比默认 fast 小 6–14%，耗时 1.9–4.1 倍；slow 小 9–19%，耗时 3.9–6.5 倍；extraslow 再小 5–9%，但比 slow 慢 8–18 倍、内存 11 倍。
• libjxl 不值得用更高 effort。 最高 effort 只比默认小 1–6%，耗时 11–14 倍。
• AVIF 的 4:2:0 模式没用。 文件和 4:4:4 一样大。
• 三个编码器对这张图的 SSIMULACRA2 评分都更低。 也就是同样编码器质量值下分数更低。看起来编码器很乐意抹掉一些背景噪点，这似乎没问题。

图像质量

（图表说明及两张指标图。）

编码性能

（编码时间与 SSIMULACRA2 关系图。）

编码内存占用

（峰值内存与 SSIMULACRA2 关系图。）

解码性能

（解码时间与 SSIMULACRA2 关系图。）

有损压缩——截图

好，试张非照片的图：

基准测试结果：

• 文件大小：AVIF 大胜。 默认 effort 下，中等/高质量的最佳 JPEG XL（jixel）比 AVIF 大 73–89%，极高质量（libjxl）大 29–44%。最高 effort 下，最佳 JPEG XL（jixel extraslow 带 patches）比 AVIF（s0）大 23–73%。
• libjxl 默认 effort 下无法产出 SSIMULACRA2 约 45 到约 78 之间的文件（更高 effort 是约 45 到约 75）。jixel 没这问题。
• jixel 的 patches 功能对这张图帮助很大，但默认关闭。开启后，jixel 在较高 effort 下、SSIMULACRA2 约 65 往上，文件小 10–29%。默认 fast 下 patches 无效果。
• 编码时间：AVIF 胜。 默认下 jixel 比 AVIF 快约 50%，但文件大 70–98%。libjxl 默认耗时是 AVIF 的 1.7–1.8 倍，文件仍大得多。
• 编码内存：AVIF 胜。 默认下 jixel 内存比 AVIF 少约 40%，但文件大得多；libjxl 默认是 AVIF 的 1.2–2.2 倍。jixel extraslow 带 patches 最接近 AVIF 文件大小，但内存是 AVIF 默认的约 7.5 倍。
• 解码时间：AVIF 大胜。 取两个 JPEG XL 编码器较快的输出，JPEG XL 解码要 2–3.8 倍时间，取决于浏览器和质量。
• 这张图上 AVIF 更高 effort 更值。 s5 多花 2.5–3 倍时间，小 6–13%；s0 多花 30–45 倍时间，小 16–23%。
• jixel 值得用更高 effort，只要开启 patches。 medium 带 patches 比默认 fast 小 11–44%，耗时 3–4 倍；slow 带 patches 再小 7–16%，耗时是 medium 的约 1.7 倍；extraslow 带 patches 再小几个百分点，但比 slow 慢约 5 倍、内存 4.5 倍。
• libjxl 更高 effort 有害。 极高质量下，libjxl 最高 effort 产出的文件比默认 effort 大 33–40%，耗时约 7 倍。
• AVIF 的 4:2:0 模式在高质量有帮助。 SSIMULACRA2 70 及以上时，文件比 4:4:4 小 7–18%；低质量无差别。
• 三个编码器对这张图的 SSIMULACRA2 评分都更高。 和黄鼠狼图相反，但这似乎是对的。SSIMULACRA2 70 时，Firefox 标志周围 artifacts 相当明显（至少我觉得），所以我会选 80，而编码器们本来也倾向这个分数。

有些开发者，尤其是像我这样资历的，似乎觉得截图这类图必须用无损格式。但我觉得这是因为他们习惯了 JPEG、WebP（以及似乎 JPEG XL）处理不好这类图，而有损 AVIF 处理得非常好。

图像质量

（SSIMULACRA2 图表说明及图；因为指标不支持 alpha 通道，不放 ColorVideoVDP 图。）

编码性能

（编码时间与 SSIMULACRA2 关系图。）

编码内存占用

（峰值内存与 SSIMULACRA2 关系图。）

解码性能

（解码时间与 SSIMULACRA2 关系图。）

这里 JPEG XL 解码时间高，很可能是因为它为同等质量产出了大得多的文件。

有损压缩——插画

很多时候，大色块图会用 SVG。但有时不行（是张截图），有时不划算，比如这张。这张 Unsplash 的插画压缩并 minify 后仍有 1.1 MB，因为阴影区域复杂。所以矢量栅格化后，文件格式在文件大小和解码/绘制时间上反而赢了。

在演示的质量 50 下，jixel 有严重色块，比如猫脸上。这又让我有点怀疑指标。

基准测试结果：

• 文件大小：AVIF 大胜。 默认 effort 下，最佳 JPEG XL（jixel）在 SSIMULACRA2 80 以下比 AVIF 大 32–65%，超过 80 大约 90%。最高 effort 下，jixel extraslow 在 80 以下比 AVIF（s0）大 22–55%，更高更大。ColorVideoVDP 同意，认为差距 27–58%。
• libjxl 在这张图上表现特别差。 默认 effort 下比 AVIF 大 71–106%。
• 有损 AVIF 这张图达不到 SSIMULACRA2 90。 即便最高质量也只到约 87，所以上面 90 的示例不完全公平。JPEG XL 能达到 90，但结果比 JPEG XL 无损版大 8–50%，那还不如用无损。
• 编码时间：AVIF 胜。 默认下 jixel 快 35–44%，但文件大 32–65%，不划算。jixel 需要 slow 设置才能接近 AVIF 默认文件大小（差 7–27%），耗时是 AVIF 的 2.4–2.6 倍。libjxl 默认耗时是 AVIF 的 1.3–2.3 倍，文件大得多。
• 编码内存：AVIF 胜。 默认下 jixel 内存比 AVIF 少约 37%，但文件大得多；slow 内存和 AVIF 差不多，extraslow 约 12 倍。libjxl 默认是 AVIF 的 1.5–3 倍。
• 解码时间：AVIF 大胜。 JPEG XL 在中等/高质量解码要 2–4.6 倍时间，极高质量缩到 1.6–2.1 倍。
• 这张图上 AVIF 更高 effort 更值。 s5 多花约 2.7 倍时间，小 5–8%；s0 多花 35–48 倍时间，小 14–21%。
• jixel 值得用更高 effort，直到 slow。 medium 只比默认 fast 小 4–13%，但 slow 小 19–24%（极高质量最多 36%），耗时约 4 倍；extraslow 再小 2–3%，但比 slow 慢 8–9 倍、内存 11 倍。
• jixel 的 patches 功能对这张图没帮助。 和截图不同，开关文件大小一样，但会增加编码时间和内存。
• libjxl 不值得用更高 effort。 最高 effort 只比默认小 3–9%，耗时 10–13 倍。
• AVIF 的 4:2:0 模式没用。 SSIMULACRA2 认为它比 4:4:4 略差，ColorVideoVDP 认为略好（约 3–4%）。

图像质量

（图表说明及两张指标图。）

编码性能

（编码时间与 SSIMULACRA2 关系图。）

编码内存占用

（峰值内存与 SSIMULACRA2 关系图。）

解码性能

（解码时间与 SSIMULACRA2 关系图。）

有损压缩——透明通道

前面图基本都不透明。带透明的呢？

几点不同：

• jixel 总是无损编码 alpha 通道。 它没有 alpha 质量设置，这让 jixel 在这张图上很吃亏。AVIF 默认有损压缩 alpha 通道，跟随主质量设置。libjxl 默认无损压缩 alpha，要注意。本次基准我把 libjxl 的 alpha 质量设成和主质量一样。
• SSIMULACRA2 给完全透明像素打满分，所以透明区域多时分数会比不透明图高。

基准测试结果：

• 文件大小：AVIF 大胜。 默认 effort 下，最佳 JPEG XL（libjxl）比 AVIF 大 31–44%；最高 effort 下大 61–70%。因为 alpha 无损，jixel 在默认 effort 下是 AVIF 的 1.9–3.1 倍。
• 编码时间：AVIF 胜。 libjxl 默认耗时是 AVIF 的 1.2–1.35 倍，文件大得多；jixel 默认比 AVIF 快约 2 倍，但文件是 2–3 倍大。
• 编码内存：AVIF 胜。 libjxl 默认是 AVIF 的 2.4–2.7 倍（绝对值约 120 MB vs 46 MB）；jixel 默认内存和 AVIF 差不多，但文件大得多。
• 解码时间：AVIF 胜。 libjxl 输出在中等质量解码要 2–3 倍时间，极高质量缩到 1.4–1.8 倍。jixel 输出比 libjxl 快，极高质量和 AVIF 差不多；但低质量下在 Safari 很慢，约 AVIF 的 2.4 倍。
• AVIF 值得用更高 effort。 s5 多花 2.3–2.9 倍时间，小 4–7%；s0 多花 24–29 倍时间，小 10–15%。
• jixel 更高 effort 在这张图上几乎没用。 extraslow 只比默认 fast 小 5–8%，耗时 21–26 倍。
• libjxl 更高 effort 有害。 最高 effort 产出的文件比默认 effort 大最多 8%，耗时约 6.5 倍。
• AVIF 的 4:2:0 模式有害。 文件比 4:4:4 大 4–27%，且无法超过 SSIMULACRA2 约 79。

图像质量

（SSIMULACRA2 图表说明及图。）

编码性能

（编码时间与 SSIMULACRA2 关系图。）

编码内存占用

（峰值内存与 SSIMULACRA2 关系图。）

解码性能

（解码时间与 SSIMULACRA2 关系图。）

有损压缩——小图

前面图分辨率都差不多。小图结果会不同吗？

并不会，和全尺寸 F1 图很像：

• 文件大小：AVIF 胜，差距差不多。默认 effort 下最佳 JPEG XL 大 13–18%；最高 effort 下差距略大，为 12–20%。
• 编码时间与内存：AVIF 胜，不过 libjxl 默认现在和 AVIF 默认速度差不多。jixel 默认比 AVIF 快约 2 倍，但文件大 13–18%，而且这次内存还多约 30%。不过默认 effort 下所有编码都在 50ms 内、内存低于 40 MB，这些差异在这个尺寸下真不重要。
• 解码时间：AVIF 胜，差距类似，但同样一切都只在几毫秒内。

（图表部分。）

有损压缩——大图

那 1800 万像素的图呢？

大部分和常规 F1 图一样，但几点不同：

• 文件大小：AVIF 在中等/高质量胜，且比常规图优势更大。 默认 effort 下最佳 JPEG XL 大 18–46%，最高 effort 下大 28–54%。
• 但 JPEG XL 在极高质量追上来了。 SSIMULACRA2 约 85 时，libjxl 默认追平 AVIF 默认；最高 effort 下，jixel extraslow 比 AVIF s0 小约 6%。jixel slow 在 SSIMULACRA2 80 往上比 AVIF 默认小 10–13%。
• 编码时间：AVIF 在中等/高质量胜，但 JPEG XL（jixel）在极高质量胜。 AVIF 默认约 0.5 秒，libjxl 默认 1–2 秒。jixel 默认比 AVIF 快约 2 倍，中等/高质量下文件大 29–57%，极高质量只大 6–12%，用速度换挺合理。jixel slow 产出和 AVIF s5 同大小文件，同时快 33–41%。
• 编码内存：AVIF 胜，而且现在成本很明显。 AVIF 默认约 560 MB；libjxl 默认中等/高质量约 2.5 GB；jixel 默认比 AVIF 少约 35%，slow 比 AVIF s5 少约 18%。最高 effort 下，libjxl 用 5–6.4 GB，jixel extraslow 用 6.8–8.3 GB。
• 解码时间：AVIF 在中等/高质量胜，差距和常规图类似。jixel 图像在 Safari 里这些质量下解码要超过 AVIF 5 倍时间。极高质量下，JPEG XL 在 Chrome 里解码比 AVIF 快。

（图表部分。）

质量稳定性

另一个我听说的对 AVIF 的批评是质量不稳定：某个质量设置对某些图很好，对另一些就不行，意味着自动编码时要选更高质量才安全，导致某些图文件比必要的大。

对前面看过的图，我用 avifenc -q 50、cjxl -q 70、jixel 质量 80 编码，记录得到的 SSIMULACRA2 分数：

| 图片 | AVIF | JPEG XL | JPEG XL (jixel) | | --- | --- | --- | --- | | s6 4:4:4 | s0 4:4:4 | s6 4:2:0 | s0 4:2:0 | e7 | e10 | fast | extraslow | | F1 | 74.6 | 75.9 | 73.4 | 73.8 | 79.2 | 78.0 | 75.3 | 77.3 | | F1（小） | 70.9 | 73.5 | 68.4 | 69.5 | 75.6 | 73.9 | 70.6 | 72.6 | | F1（大） | 77.0 | 77.4 | 76.2 | 76.6 | 80.1 | 79.2 | 77.5 | 78.9 | | 人物 | 70.7 | 72.0 | 69.8 | 70.5 | 69.6 | 70.3 | 69.1 | 72.3 | | 小熊猫 | 67.5 | 68.8 | 67.0 | 67.2 | 69.5 | 68.4 | 69.2 | 72.3 | | 黄鼠狼 | 56.7 | 57.2 | 56.0 | 56.3 | 56.6 | 55.4 | 54.9 | 59.4 | | 截图 | 80.2 | 80.4 | 82.3 | 81.9 | 86.5 | 87.6 | 76.6 | 80.3 | | 插画 | 78.6 | 79.7 | 76.8 | 77.9 | 80.3 | 78.5 | 75.4 | 77.7 | | 透明 | 67.3 | 69.8 | 63.6 | 64.9 | 69.4 | 66.9 | 66.8 | 69.6 |

各编码器的行为看起来非常相似。都会产生一定范围的 SSIMULACRA2 分数，而且对同样的图一起变高或变低。

我觉得这没问题？比如三者都给黄鼠狼图更低质量，去掉噪点却没降低主体质量；截图则都给更高质量，我看也合理。

显然样本量小，但我没看到任何迹象表明对这三个编码器用单一质量设置是有风险的。

渐进式渲染

AVIF 和 JPEG XL 都能在图片加载时逐步显示内容。Chrome 和 Firefox 支持渐进式 JPEG XL，而只有 Chrome 支持渐进式 AVIF。所以（我咬着牙说）下面这个演示最好在 Chrome 里看（Firefox 补丁我在做）：

已下载：11.5 kB

• AVIF：151.3 kB 中的 11.5 kB
• JPEG XL：166.0 kB 中的 11.5 kB

这又是那张 1800 万像素图，所以设备屏小的话体验不完整。

渐进式 AVIF 和 JPEG XL 工作方式很不同。JPEG XL 可以选择以某种方式存储数据，让解码器先渲染低分辨率版本，再引入高分辨率图块。jixel 最近（撰写时是昨天）也加了支持，叫 "progressive DC"，是 JPEG XL 最重要的渐进渲染方式。

AVIF 的渐进更像视频帧：最多提供四个帧，也就是最终图像前有三个阶段。像视频一样，每帧可以用前一帧数据做优化。好处是你能精确控制这些帧的样子。上面的例子我只用了一个预览帧：1/8 分辨率版本加一点模糊。但预览帧其实可以是完全不同的图像。

关于渐进图像和用户体验的数据很少，所以下面是我的瞎猜：

如果你网速差，数据不像某些限速工具让你以为的那样逐渐到达，而是突发的。所以小图用渐进渲染没啥好处，我也不确定很多渐进阶段有多大用。

我觉得对可能要加载一会儿的图，有个有代表性的预览挺好。我自己体验过，站点或 app 给我明显没加载完、但足够知道将看到什么的东西，这对我有用，因为我能决定要不要等完整图。这也是为什么我觉得 BlurHash 之类很 cute 但没用：它们不是有代表性的预览，用户拿到信息也做不了什么。

我给 AVIF 选的预览帧足以看出是辆开轮式赛车。懂 F1 的话能认出车队，甚至可能知道拍摄地。而这些只用了约 11.5 kB。

JPEG XL 在约 2 kB 时就屏幕上有 BlurHash 式预览，但要到约 63 kB 才追平 AVIF 的预览质量。之后它继续逐步改善，随数据到达提供更细更高质的图。

但我不确信这是好的用户体验，因为它给用户看的东西可能被误认为已加载完但质量差。比如：

这是 JPEG XL 加载到 80% 的裁剪图。有人看到可能合理以为我拍得烂，部分没对上焦。你可能可以说把 ApeCoin 标志模糊了是社会效益，但这仍感觉是次优体验。

AVIF 的系统给我更多控制，但也更复杂。

渐进式开销

我把大 F1 图在开关渐进渲染下各编码一次，调整质量保持 SSIMULACRA2 约 70：

• libjxl 的渐进基本免费。 事实上文件还小 6–10%。默认 effort 下编码也更快、内存更少；解码在 Firefox 快约 10%，但 Chrome 和 Safari 慢 12–20%。
• jixel 看 effort。 我用 progressive DC，图像中心先加载。默认 fast 下，渐进让文件大 12%；extraslow 下文件小 10%、编码快 11%，但内存多 17%。解码几乎不受影响，只在 Chrome 慢 7–9%。
• 但 ColorVideoVDP 对渐进 jixel 不太友好。 它给 jixel 渐进文件打分比非渐进略低，而给 libjxl 渐进文件略高。算上这点，jixel extraslow 渐进只比非渐进小约 2%，而 fast 下大约 18%。
• 常规渐进 AVIF 编码开销更大。 内存约两倍，默认 effort（s6）下耗时两倍；s0 下编码时间只多 9%，但文件大 14%。而且这只是纯编码时间，还没算生成预览帧（比如加模糊）的成本。
• 常规渐进 AVIF 在 Chrome 解码慢 29–44%，其他浏览器差距小些（6–15%）。因为 Chrome 是唯一支持渲染渐进帧的，这可能解释了原因。不过 Firefox 和 Safari 仍要解码渐进帧，因为主图基于它构建。
• AVIF 把最终帧设为关键帧能消除解码开销，代价是编码时间更长。最高 effort 下文件也更小，只比非渐进版大 3–5%。你可以说这是作弊，因为数据上没“渐进”了——就是一个容器里两张图。但如果用户体验更好，谁在乎呢？
• 即便有开销，渐进 AVIF 在解码时间上赢，文件大小通常也赢。 渐进 AVIF 是 152–181 kB；jixel extraslow 渐进 JPEG XL 是 166 kB（在这个范围），但 jixel 默认产出 252 kB，libjxl 渐进文件 233–242 kB。AVIF 解码快 1.6–6 倍，Safari 差距最大，它解码 jixel 文件特别慢。

数据如下：

| 编码 | 质量 | 文件大小 | SSIMU2 | 编码时间 | 内存 | Firefox 解码 | Chrome 解码 | Safari 解码 | | --- | --- | --- | --- | --- | --- | --- | --- | --- | | AVIF s6 | 41 | 175 kB | 69.9 | 405 ms | 381 MB | 46 ms | 41 ms | 53 ms | | AVIF s6 prog | 42 | 173 kB | 70.2 | 815 ms | 764 MB | 49 ms | 53 ms | 56 ms | | 变化 | +1 | −1% | +0.3 | +101% | +101% | +7% | +29% | +6% | | AVIF s6 prog -k | 42 | 181 kB | 70.3 | 1.09 s | 740 MB | 45 ms | 35 ms | 49 ms | | 变化 | +1 | +3% | +0.4 | +169% | +94% | −2% | −15% | −8% | | AVIF s0 | 41 | 145 kB | 69.9 | 8.00 s | 450 MB | 47 ms | 41 ms | 48 ms | | AVIF s0 prog | 42 | 165 kB | 70.5 | 8.71 s | 847 MB | 54 ms | 59 ms | 52 ms | | 变化 | +1 | +14% | +0.6 | +9% | +88% | +15% | +44% | +8% | | AVIF s0 prog -k | 41 | 152 kB | 69.6 | 10.72 s | 798 MB | 47 ms | 40 ms | 46 ms | | 变化 | ±0 | +5% | −0.3 | +34% | +77% | ±0% | −2% | −4% | | JPEG XL e7 | 35.5 | 258 kB | 70.0 | 1.62 s | 2.49 GB | 131 ms | 105 ms | 162 ms | | JPEG XL e7 prog | 25.3 | 233 kB | 70.0 | 1.40 s | 1.90 GB | 119 ms | 121 ms | 183 ms | | 变化 | −10.2 | −10% | ±0.0 | −14% | −24% | −9% | +15% | +13% | | JPEG XL e10 | 41.2 | 258 kB | 70.0 | 22.74 s | 5.67 GB | 132 ms | 107 ms | 162 ms | | JPEG XL e10 prog | 30.2 | 242 kB | 70.0 | 25.54 s | 6.08 GB | 119 ms | 128 ms | 181 ms | | 变化 | −11.0 | −6% | ±0.0 | +12% | +7% | −10% | +20% | +12% | | jixel fast | 66.1 | 225 kB | 70.0 | 304 ms | 361 MB | 131 ms | 89 ms | 281 ms | | jixel fast prog | 60.1 | 252 kB | 70.0 | 333 ms | 393 MB | 132 ms | 97 ms | 290 ms | | 变化 | −6.0 | +12% | ±0.0 | +10% | +9% | +1% | +9% | +3% | | jixel extraslow | 65.1 | 185 kB | 70.0 | 16.75 s | 7.61 GB | 141 ms | 92 ms | 294 ms | | jixel extraslow prog | 55.4 | 166 kB | 70.0 | 14.90 s | 8.94 GB | 140 ms | 98 ms | 293 ms | | 变化 | −9.7 | −10% | ±0.0 | −11% | +17% | −1% | +7% | ±0% |

有损压缩——HDR

回到有损压缩，但这次是 HDR！HDR 图像有几种编码方式，我们看两种。

Perceptual Quantization（PQ）告诉每个像素该是什么：每个值映射到一个绝对亮度，最高 10,000 尼特，曲线形状把数据花在我们眼睛最敏感的地方。如果图像要求的颜色和亮度显示器放不出（没有消费级显示器能到 10,000 尼特），浏览器/系统就得做色调映射，而各平台做得好不好不一样。

Gain map不同。主图通常是普通 SDR 图，旁边再带一个 gain map，对每个像素施加亮度和颜色变化来得到 HDR 版本。

这有两个好处：

1. 同一张图在 SDR 显示器上就是你想要的精确样子——gain map 直接被忽略。
2. 如果显示器支持 HDR，但可能不如图像需要的那么强（比如屏幕处于最低或最高亮度），浏览器/系统可以应用它能处理的 gain map 部分。

CSS 和 <picture> 让我们能通过 dynamic-range 媒体查询给用户提供 SDR 或 PQ 图像，但那样在浏览器表明支持 HDR 却不支持全范围时，就得依赖色调映射。

虽然 JPEG XL 格式支持 gain map，但没浏览器处理它们，编码方案也混乱。

AVIF 支持 gain map，编码方式是提供两张图：SDR 图和 HDR 图，用它来算出并编码 gain map。

你的浏览器/屏幕不支持 HDR，所以 PQ 图看起来会很糟。

中等亮度下，在 HDR 屏上 gain map 和 PQ 图看起来一样。最高亮度下，在我的 Pixel 10 Pro 和 2024 MacBook Pro 上，PQ 图有点过曝，gain map 图看起来更好。低亮度下在我的 Pixel 10 Pro 上，gain map 图也更好。

这是因为极端亮度下设备没有完整 HDR 余量来显示图像，而 gain map 能更好处理这些情况。所以虽然 gain map 似乎让文件大很多，我觉得值得。

也许未来色调映射变得好很多，gain map 的优势就没那么明显了。

常规 SSIMULACRA2 只懂 SDR，所以这张图的分数来自 fast-ssim2 的实验性 HDR 模式。这意味着这些分数不能和本文其他地方的 SSIMULACRA2 比。ColorVideoVDP 原生处理 HDR，这里模拟 1500 尼特 HDR 显示器。

两个指标对这张图分歧很大。而且它们没考虑 gain map 的好处，所以把这些结果当作 PQ 变体间的比较：

• 文件大小：JPEG XL 胜，但指标对程度和哪个编码器有分歧。
  • 按 HDR SSIMULACRA2，jixel 默认比 PQ AVIF 默认小 8% 到大 3%；libjxl 大 5–33%。最高 effort 下，jixel extraslow 比 PQ AVIF s0 小最多 15%。
  • 按 ColorVideoVDP，libjxl 明显胜。默认 effort 下比 PQ AVIF 小 28–53%，比 gain map AVIF 小 17–37%。最高 effort 下比最佳 AVIF 小最多 23%，但 jixel extraslow 和它差不多，从小 12% 到大 14%。
• 指标对 gain map 也分歧。 HDR SSIMULACRA2 说 gain map AVIF 比 PQ AVIF 大 31–38%，但 ColorVideoVDP 说 gain map AVIF 比 PQ AVIF 小 11–25%。
• 编码时间：JPEG XL（jixel）胜。 默认下 jixel 比 PQ AVIF 快约 2 倍，文件同大小或更小（看指标）。libjxl 默认比 PQ AVIF 慢 5–47%，但按 ColorVideoVDP 看的文件大小，这交易合理。gain map AVIF 最慢，因为它要算 gain map，然后基本编码两张图：比 PQ AVIF 慢约 3 倍。
• 编码内存：JPEG XL（jixel）胜。 默认下 jixel 内存比 PQ AVIF 少约 30%；libjxl 默认是 PQ AVIF 的约 1.9 倍，gain map AVIF 约 1.55 倍。最高 effort 下 libjxl 是 PQ AVIF 默认的约 6 倍，jixel extraslow 约 10 倍。
• 解码时间：AVIF 胜。 PQ 和 gain map AVIF 解码速度差不多。JPEG XL 在 Chrome 解码要 1.2–1.7 倍时间，尽管最高质量区间略快。Safari 里要 1.6–3 倍。Firefox 对这些 HDR JPEG XL 特别慢，所有质量都约 AVIF 的 4 倍。我们在修了。
• AVIF 值得用更高 effort。 gain map AVIF 的 s5 多花约 1.9 倍时间，小 9–12%；s0 多花约 11 倍时间，小 14–20%。PQ AVIF 的 s0 多花 17–20 倍时间，小 14–19%。
• jixel 值得用更高 effort，直到 slow。 slow 比默认 fast 小 7–32%，耗时约 3.8 倍；extraslow 再小 1–9%，但比 slow 慢约 10 倍、内存 8.5 倍。jixel 这张图数据点少，数字比较糙。
• libjxl 不值得用更高 effort。 最高 effort 只比默认小 2–7%，耗时约 15 倍。

等 JPEG XL 完全支持 gain map 后会怎样处理，挺值得看的。

顺便说，这些是表示我的猫在室内还是室外的标志，小屏幕显示离下次自动喂食还有多久。

图像质量

（图表说明及两张指标图。）

编码性能

（编码时间与 SSIMULACRA2 关系图。）

编码内存占用

（峰值内存与 SSIMULACRA2 关系图。）

解码性能

（解码时间与 SSIMULACRA2 关系图。）

JPEG 转码

JPEG XL 能把现有 JPEG 转成 JPEG XL 而没有额外损失。我用 F1 图在不同尺寸和 JPEG 质量下测试：

• JPEG XL 比 JPEG 小 9–20%。 省得随分辨率增加，从 400 像素宽时约 9% 到 4900 像素宽时约 20%。JPEG 质量更高时省得略少。libjxl 和 jixel 产出文件大小几乎一样。
• 小图 JPEG XL 解码比 JPEG 慢，要 1.4–2.7 倍时间，取决于浏览器。但也就一两毫秒。
• 大图 JPEG XL 在 Chrome 和 Safari 解码更快。 约 1000 像素宽起追平 JPEG，最大尺寸时解码时间约一半。Firefox 里最终和 JPEG 差不多。
• jixel 输出在 Chrome 和 Firefox 解码比 libjxl 略慢，最多约 25%。但同样是小数字，最多几毫秒。

当然，如果有原图，用 AVIF 或 JPEG XL 做个正经有损新版本会好得多。但 JPEG 能变小、有时解码更快，还是挺酷的。虽然，我猜这只是说明浏览器 JPEG 解码器缺个优化。

（图表部分：文件大小与百万像素关系图、解码时间与百万像素关系图。）

无损压缩

网页上极少需要无损图。前面已经看到，即便截图和插画，有损 AVIF 都处理得很好。讽刺的是，本页就是个例外，因为我想展示压缩版和无损版的对比。幸好 JPEG XL 无损很强！

结果：

• 文件大小：JPEG XL 胜。 默认 effort 下，libjxl 对每张图都产出最小文件，除了插画（WebP 和它打平）。WebP 对照片大 9–17%，AVIF 大 33–122%。最高 effort 下，libjxl 和 jixel 差几个百分点内，WebP 大 5–44%，AVIF 大 29–176%。
• 编码时间：JPEG XL 胜。 libjxl 默认耗时 0.1–0.5 秒，比 WebP 默认快，和 AVIF 默认差不多，但文件比两者都小。
• 编码内存：看图片，JPEG XL 胜或 WebP 胜。 WebP 默认内存约 libjxl 默认一半（55–110 MB vs 110–250 MB），但 libjxl 文件更小。照片上 WebP 即便最高 effort（内存比 libjxl 默认还大）也追不上 libjxl 默认文件大小。截图上两者内存差不多，但 libjxl 文件更小。插画是例外：WebP 最高 effort 产出比 libjxl 默认小 20% 的文件，内存相同。
• 解码时间：看图片，WebP 胜或 JPEG XL 胜。 WebP 在所有浏览器解码照片 17–39 ms，截图约 5 ms。libjxl 输出在 Chrome 要 1–2.2 倍时间，Firefox 1.4–2.7 倍，Safari 2.1–3.2 倍。但照片上，除非连接极快，JPEG XL 更小的文件在首次加载上足以弥补。截图和插画上，WebP 的解码优势赢。无损 AVIF 解码特别慢，Chrome 里最多是 libjxl 输出的 4 倍。
• 无损 AVIF 很差。 明显比别的大，解码也慢。
• jixel 的 medium 设置是文件大小甜点。 每张图都击败 libjxl 默认（小 0.5–23%），照片上和最佳结果差 2–3% 内，耗时 0.4–0.7 秒。但它用 470–670 MB 内存，输出比 libjxl 慢，尤其在 Safari。
• jixel 的 slow 和 extraslow 对照片解码非常慢。 约 200–290 ms，而 libjxl 输出是 22–95 ms，也就是慢 2–13 倍，看浏览器。透明图也慢，80–123 ms vs libjxl 的 14–27 ms。截图和插画没这问题。这意味着，就本页用途我会避开它。
• libjxl 最高 effort 非常慢。 照片文件比默认小 2–7%，截图和插画小约 25%，但耗时 9–46 秒，是默认的 50–180 倍。jixel 几秒钟就能得到同样结果。
• jixel 默认 fast 对无损不好。 它是最快编码器（40–80 ms），但照片文件比 libjxl 默认大 16–32%，截图和插画大约 80%。
• jixel 的 patches 功能对截图有点帮助（小 4–9%），但对插画没区别。

文件大小

| 图片 | 默认 effort | 最高 effort | | --- | --- | --- | --- | --- | --- | --- | --- | --- | | libjxl | jixel | WebP | AVIF | libjxl | jixel | WebP | AVIF | | F1 | 1.07 MB | +32% | +16% | +49% | 1.01 MB | −1% | +20% | +47% | | 人物 | 1.39 MB | +22% | +17% | +49% | 1.34 MB | −1% | +19% | +44% | | 小熊猫 | 1.78 MB | +17% | +9% | +40% | 1.74 MB | −1% | +11% | +31% | | 黄鼠狼 | 2.91 MB | +16% | +13% | +96% | 2.79 MB | −2% | +17% | +29% | | 截图 | 92 kB | +81% | +9% | +122% | 68 kB | +6% | +44% | +176% | | 插画 | 361 kB | +78% | −1% | +100% | 273 kB | −6% | +5% | +139% | | 透明 | 522 kB | +21% | +12% | +33% | 487 kB | −3% | +13% | +32% |

编码性能

（文件大小与编码时间关系图。）

编码内存占用

（文件大小与峰值内存关系图。）

解码性能

（文件大小与解码时间关系图。）

动画

动图格式很蠢，动画 JPEG XL 也不例外。视频格式更擅长视频：它们为视频而生、为视频优化，不光编码，还有播放。

我编码了一段短片，同样 ColorVideoVDP 分数（9.5）下，动画 AVIF 是 725 kB，JPEG XL 是 2.17 MB。

JPEG XL 比 AVIF 噪点多得多，因为每帧独立编码，artifacts 落在每帧不同位置。

AVIF 基本就是 AV1 视频的关键帧格式，加了一堆静态图优化。动画 AVIF 则基本就是 AV1 视频重新包装。你可以把 AV1 MP4 转成 AVIF 再无损转回来——只是换了个容器。这就是它表现好得多的原因，因为它为运动而生。

不过动画 AVIF 在 Chrome 和 Safari 播放很烂。Firefox 里没事，所以这纯粹是实现问题。但…… <video muted autoplay> 就在那儿。

动画 AVIF 有趣的细节是支持透明，而 AV1 视频不支持。但这其实更凸显了 AV1 不支持透明很蠢。

不，我不加演示。我不想它出现在我服务器上。视频就用视频格式。

就这样！

我第一版文章对 JPEG XL 非常负面，但后来听说了 jixel，说实话我很兴奋。现在 AVIF 和 JPEG XL 之间有了激烈竞争，无论谁赢，我们都能受益于更好的图像压缩。

多数人接受原文判断，认为 AVIF 已在 Web 有损压缩、动画和浏览器支持上优于 JPEG XL，JPEG XL 主要只剩无损、JPEG 转码和渐进渲染等场景仍有价值。分歧则集中在当前结论是否被 JPEG XL 编码器不成熟、评测工具有限以及 AVIF 高压缩涂抹细节等因素所掩盖，社区并未真正承认存在单一赢家。

认为 AVIF 在 Web 有损压缩上已整体胜过 JPEG XL

• 从博客配图、游戏截图到大尺寸头图，相同文件体积下 AVIF 的观感通常更好或至少不差；它在动画上可替代 GIF，支持逐帧可变透明，也具备不错的渐进渲染，而浏览器支持率已接近全覆盖。站点采纳还受容器化设计保护：未来 AV2、AV3 仍可包在 AVIF 容器内，网站不必重复经历新格式适配。（认可度：较多人）
• 需要引用时，只用一句中文意译： > 我博客几乎全是游戏截图，保留 PNG 原图以便将来用更好的编码器重压，但每年试 JPEG XL 都发现同体积下 AVIF 通常更好一点。（@theandrewbailey）

认为 JPEG XL 仍守住无损、JPEG 转码与高保真归档场景

• 在无损压缩、把现存海量 JPEG 重新转码变小、超高码率和渐进渲染上，JPEG XL 仍被看作更好选择；它能把老照片和插画归档压得更小，甚至可表示超出人眼视觉极限的无损图像，暂时不会取代天文领域的 FITS，但上限很高。（认可度：较多人）
• 需要引用时，只用一句中文意译： > JPEG 转码是 JPEG XL 最实用的功能之一，现存那么多 JPEG，光是这点就可能为照片归档备份省下大量空间。（@adzm）

认为当前比较受编码器与评测方法局限，现在判胜负为时过早

• AVIF 的优势可能来自编码器而非格式本身；JPEG XL 当前 libjxl 编码器在高努力档极慢且未成熟，若用更好的编码器，无损结果还能再小三到四成。再加上对比控件不好、感知指标并不完全代表人眼质量，社区认为需要更大规模盲测，不宜把少量图片的结果当成最终赢家。（认可度：较多人）
• 需要引用时，只用一句中文意译： > libjxl 现在被很多人低估，用更好的编码器后，那张 Firefox 截图无损 JPEG XL 能从 66.9kB 降到约 40.7kB，插画也能小约 30%。（@linolevan）

批评 AVIF 在高保真照片和高压缩下会抹掉细节

• 对微单照片或需要保留高光的图像，AVIF 在高压缩时会把真实高光抹掉并替换成“看起来合理”的内容；它适合营造整体印象的大图，却不适合认真保存摄影作品，高压缩下也会出现伪影。（认可度：少数人）
• 需要引用时，只用一句中文意译： > 那张 F1 图片正好证明 AVIF 的问题：车身漂亮的高光被抹掉并替换成看似合理的内容，作为博客大图可以接受，但压缩自己的微单照片时无法忍受。（@PaulHoule）

认为浏览器支持 JPEG XL 是错误，AVIF 已足够

• 既然 AVIF 已经在 Web 上表现更好，再引入 JPEG XL 被视为多余；有人认同 Google 的判断，认为当初不添加 JPEG XL 支持是对的，相关情绪也浓缩成一句玩笑。（认可度：少数人）
• 需要引用时，只用一句中文意译： > Chrome 在 Web 已经有更好编解码器的时候，却去支持 JPEG XL。（@phoronixrly）

有价值的补充

• AVIF 采用容器化设计，未来 AV2、AV3 等新编码仍可装进 AVIF 容器，网站不必为新格式再经历一轮痛苦适配；相比之下 JPEG XL 缺少这种平滑演进好处，而站点代码常硬编码已知格式列表，导致 GitHub、GitLab 等即使浏览器支持 AVIF 也难真正采用。（@shmerl）
• 动画 AVIF 几乎就是 AV1 视频重打包，可与 AV1 MP4 无损互转，因此擅长动态画面和逐帧可变透明；但 GIF 类动画在用户预期上与静音自动播放的视频元素不同，不应简单替代，图像查看器里也没有播放控件。（@adzm、@fngjdflmdflg）
• AVIF 对截图和线稿友好：文字与线条有大量高频边缘，JPEG 容易产生振铃伪影，AVIF 更贴合轮廓；此外 AVIF 也支持不错的渐进渲染，这点常被忽略。（@watersb、@fngjdflmdflg）
• libjxl 在高效档极慢，主要因为用 Butteraugli 感知指标做迭代优化；这些计算数据并行，已有支持 CUDA 和 Metal 的 GPU 加速移植 gjxl，可让批量 JPEG XL 编码接近常规速度，常规档也快约 2.9 倍。（@yhjc2692）
• 有开发者做了图像格式盲测小工具，初步结论是 AVIF 在小图上占优，JPEG XL 在渐进渲染、JPEG 升级、无损和高码率上更好；同时感知指标并不完全等于人眼质量，libjxl 会故意牺牲 SSIMULACRA2 分数以换取更高主观质量。（@aadharshpan、@yhjc2692）
• 生产环境有用户分享，用 ffmpeg 配合 libaom-av1、CRF 25、cpu-used 3 等参数，可在保留 PNG 透明的同时把 2K 以内图像压到十倍以上更小且质量良好。（@Metricon）