译者简介：本文使用四幅不同的图片：细节丰富的照片/平面插画/重型SVG/渐变图作为 demo，将常见的图片格式：JPEG，WebP，PNG与 AVIF 进行比较。比较结果显示 AVIF 的压缩效果（大小和图片观感）非常好。但是它也有自己的缺点，比如渐进式渲染和编码时间上。
译者注：本文中有很多图片的比较无法搬到译文中来，译文主要搬运文字部分对AVIF图片格式的介绍与对比，建议结合原文阅读获取更多细节～
在7月，我发布了一段视频，探索了有损和无损图像压缩的工作原理，以及如何应用这个知识为网页压缩一组不同的图像。但这些已经过时了，因为 AVIF 已经来了！Brilliant。
AVIF 是一种从 AV1 视频的关键帧派生的新图像格式。它是免版税的格式，PC 上的 Chrome 85 已支持该格式。很快 Android 也会支持，Firefox 正在实现，尽管 Safari 花费了 10 年的时间来添加怼 WebP 支持，但因为苹果公司是创建 AV1 小组的成员，我认为它不会在这里遇到同样的耗时。
我说这些的意思是：现在是关注 AVIF 的时候了。您不需要等待所有浏览器都支持它：您可以在服务器上使用内容协商来确定浏览器是否支持，也可以使用 <picture> 在客户端上提供后备选项：
<picture>
<source type="image/avif" srcset="snow.avif"> <!-- 如果支持AVIF，使用这个 -->
<img alt="Hut in the snow" src="snow.jpg”> <!-- 否则，使用这个 -->
</picture>
另外，Squeosh 现在支持AVIF，这就是我在本文中压缩示例的方式。
让我们看一下AVIF对比我们已经知道和喜欢的图像格式的效果……
F1 图片
此处有对比图。
JPEG(74.4kB) | WebP(43kB) | AVIF(18.2kB)
我之所以选择这张图片，是因为它包括低频细节（道路）和高频细节（汽车的部分涂装）。另外，红色和蓝色之间的颜色有些明显的变化。并且我喜欢F1。
粗略地说，以可接受的质量，WebP 几乎是 JPEG 大小的一半，而 AVIF 则不到 WebP 大小的一半。我发现令人难以置信的是，AVIF只需18 kB就可以很好地完成图像处理。
在我进一步比较之前：
什么是“可接受的质量”？
对于网络上的大多数图像，我的原则是：
- 如果用户在页面的上下文中查看图像，由于压缩而使图像看起来很丑陋，则该压缩级别是不可接受的。但是，在边界上的一个小缺口是可以的。
- 与原始图像相比，图像可以丢失明显的细节，除非 该细节对图像的上下文很重要。
这里的上下文是关键。图像压缩应在将要呈现给用户的尺寸以及类似的环境下进行评价。如果将图片作为要检查的艺术品展示，则质量和细节保留就变得更加重要，但这是一个极端的情况。
我在网络上看到的大多数图像质量都比需要的质量高得多，这会给用户带来较慢的体验。通常，《The Guardian》对图片的使用给我留下了深刻的印象。比如这篇文章。如果打开文章顶部的图片并放大，我会看到独特的 WebP 制品。街道很平滑。涂鸦周围有一些粗糙。但是，我们不应该为可能会放大图片寻找缺陷的人们优化用户体验。当我查看文章中的图片时，以它的大小和上下文来看，我只是看到有人骑自行车经过一个封闭的酒吧，这就是图片的意图。压缩后的资源很小，这意味着我可以很快看到图像。
在本文中，我将对图像进行优化，就像它们出现在一篇文章中一样，即CSS宽度约为像素宽度的50％，这意味着它们已针对高密度显示器进行了优化。
技术
好吧，“技术”一词可能太强了。为了压缩图像，我使用了Squoosh。我将图像缩小到50％，向下拖动质量滑块，直到看起来效果不好，然后再将其移回一点。如果编解码器具有“effort”设置，则将其设置为最大。我还使用了一个或两个高级设置，我会在后面指出来。
但是这些只是我的估计。 我正在使用在颅骨内的人眼球来比较图像，而不是尝试猜测人对图像的感知的任何算法。当然，人类的感知存在偏差。
实际上，当我向Kornel Lesiński（谈及到图像压缩时，他完全清楚自己在说什么）展示这篇文章时，他对我上面的 F1 的比较不满意，因为JPEG的 DDSIM 得分远低于其他，意味着它的质量更接近原始图像，而且……他是对的。
我努力将 F1 图像压缩为 JPEG。如果低于 74 kB，道路上的条纹对我来说真的很明显，道路的某些灰色部分明显显得略带紫色，但是 Kornel 能够调整 MozJPEG 中的量化表以获得更好的结果：
此处有对比图
JPEG(74.4kB) | JPEG + Kornel powers (65.5 kB) | WebP(43kB) | AVIF(18.2kB)
尽管我很乐意花时间手动压缩网站的关键图像，但是我并不是真的需要技巧来调整JPEG编码器。因此，本文中的结果也反映了编解码器可以用我的适度才能和毅力来做些什么。
我还意识到，手动调整每个图像的编解码器设置不够。如果需要自动进行图像压缩，则可以从一些代表性图像中人工找出设置，然后再添加一些额外的质量以确保安全，然后在自动化工具中使用这些设置。
我将为每个图像提供完整的输出，以便您可以做出自己的判断，并且可以使用 Squoosh 尝试使用自己的图像。
回到 F1 图片
让我们仔细看看编解码器是如何工作的：
此处有对比图
在所有压缩版本中，道路的细节都丢失了，我可以接受。但是，您可以看到Kornel所谈论的细节上的不同。看看原始的红色车身，它由三个不同部分组成：镜子，机翼和边箱的顶部。在 AVIF 中，平滑地消除了这些部分之间的分隔，但是大部分分隔仍然位于 JPEG 中，尤其是 74 kB 版本。
在 JPEG 版本中，您还可以看到 DCT 的各个 8x8 块，但是在缩小时它们并不明显。 WebP 使用解码过滤器避免了这种阻塞，而且效果更好。 AVIF 在保留清晰线条方面做得更好，但引入了平滑处理。这些都是减少图像中数据的方法，但是 AVIF 中的结果却不那么难看。
如果您想“等一下，他在说什么？AVIF 在红色/蓝色周围真的很块状”，那么，您很有可能在 Chrome 85 中看到它。解码器在升级颜色细节时会出现错误。尽管在某些极端情况下仍然会发生这种情况，但这在 86 中大多数情况下是固定的。
如果您想了解有关有损编解码器工作原理的更多详细信息，请查看我从4:44开始的演讲。
文件大小相等时
此处有对比图
即使在最低设置下，我也无法将 JPEG 和 WebP 降低到 18 kB，所以这不是一个完全公平的测试。 JPEG 受困于条带，一旦我低于 74 kB，该条带便开始出现。 WebP 更好，但是与 AVIF 相比，仍然存在明显的块状区。我想这就是十年的进展。
结论
除非自动化，否则提供同一图片的 3 个版本会有些麻烦，但是这里节省下来的成本是非常可观的，因此这是值得的，尤其是考虑到已经可以从 AVIF 中受益的用户数量。
平面插画
此处有对比图
对比：Original | Traced SVG (12.5 kB) | PNG 68 colour (16.3 kB) | WebP 68 colour lossless (12.9 kB) | AVIF 68 colour lossless (41.7 kB)
这是斯蒂芬·沃勒的插图。我之所以选择它，是因为它具有锋利的边缘和纯色，因此它适合测试无损压缩。
图片看起来不像是有很多颜色，但是由于边缘周围的抗锯齿，它有上千种颜色。在看起来太糟糕之前，我能够将颜色减少到 68 种。这对 WebP 无损和 PNG 产生了巨大的影响，当有 256 种或更少的颜色时，它们会切换到“调色板”模式，压缩效果非常好。
与从 AV1 视频的关键帧派生 AVIF 的方式相同，WebP 的有损压缩基于 VP8 视频的关键帧。但是，无损 WebP 是从头编写的另一种编解码器。它经常被忽略，但是每次都优于 PNG。
我没有该图像的原始矢量版本，但是我使用 Adobe Illustrator 创建了一个 SVG 版本，以大致了解 SVG 的性能。
值得注意的是 AVIF 在这里的表现不好。它确实具有特定的无损模式，但不是很好。
可是等等…
为什么不用有损？
我直接使用该图像进行调色板缩小和无损压缩，因为经验告诉我，有损压缩在这些图像上总是做得不好。或者是我以为的...
此处有对比图
对比：Original | Traced SVG (12.5 kB) | PNG 68 colour (16.3 kB) | WebP 68 colour lossless (12.9 kB) | AVIF 68 colour lossless (8.69 kB)
事实证明，有损的 AVIF 可以很好地处理纯色和清晰的线条，并且生成的文件比 SVG 小得多。我在 AVIF 中禁用了色度二次采样，以保持色彩鲜明。
看看细节
此处有细节对比图
我以为有损编解码器能够破坏边缘，但是看起来不错！左边那个家伙的眼镜上方和右边那个家伙的耳朵上方有一点点模糊。如果有的话，AVIF 进行了一些锐化处理–参见眼镜的左侧。这种锐化通常是通过调色板缩小产生的，但根据方向转换和滤镜，这正是 AVIF 的工作方式。
由于调色板颜色减少，PNG 和 WebP 的边缘特别是绿色衬衫周围有锐利的边缘，但是在正常尺寸下并不太明显。
当然，由于矢量缩放，SVG 看起来非常清晰，但是您可以看到在右边的家伙的头发和口袋周围的描边丢失了细节。
文件大小相等时
让我们将其他编解码器减小到AVIF的大小：
此处有对比图
对比：Original | JPEG (8.7 kB) | PNG 8 colour (8.21 kB) | WebP lossy (8.65 kB) | AVIF 68 colour lossless (8.69 kB)
情况并不像 F1 图像那样糟糕，但是 JPEG 非常不清晰，并且明显改变了颜色，WebP 模糊，而 PNG 表明，您需要 8 种以上的颜色。
结论
AVIF 在这里让我大吃一惊。这让我重新考虑了有损编解码器适合的图像类型。
但总而言之，在这里合适的 SVG 可能是正确的选择。但是，即使无法使用 SVG，PNG 和 AVIF 之间的差异也只有几 kB。在这种情况下，创建不同版本的图像可能不值得。
重型SVG
此处有下一张图对比图
Original SVG (82.3 kB) | Optimised SVG (30.8 kB) | PNG 256 colour (84.6 kB) | WebP (50.6 kB) | AVIF (13.3 kB)
令人难以置信，这张图片是用 SVG 创建的。但是，这是有代价的。涉及的形状和过滤器数量众多，这意味着浏览器需要大量的 CPU 渲染它。这是最好避免使用原始 SVG 的那些极端情况之一，即使替代方案更大。
由于平滑的渐变，PNG 在这里表现艰难。我将颜色减少到 256 种，但是我不得不对它们进行dither处理，以避免可见的条纹，这也不利于压缩。
通过将有损压缩与 Alpha 通道混合使用，WebP 的性能明显更好。但是，Alpha 通道始终在 WebP 中进行无损编码（除了一些调色板缩减以外），因此当涉及到汽车下方的透明渐变时，它与 PNG 相似。
即使与 SVG 相比，AVIF 也会以明显更小的尺寸对其进行放大。 AVIF 的部分优势在于它支持有损 Alpha 通道。
看看细节
PNG 放大后，您可以看到调色板缩小的效果。 WebP 变得越来越模糊，并受到一些色彩干扰。
AVIF 看起来与 WebP 相似，但尺寸要小得多。有趣的是，AVIF 只是放弃了引擎盖的绘制，但是缩小时几乎不会引起注意。
文件大小相等时
与之前一样，让我们将其他格式减小到AVIF的大小：
此处有对比图
PNG 版本看起来很酷！ WebP 版本使我想清洁自己的眼镜。
结论
从 86/50 kB 降至 13 kB 是一个巨大的节省，值得付出额外的努力。
下一个：
渐变图
此处有对比图
Original | JPEG (81.7 kB) | WebP 256 colour lossless (170 kB) | WebP lossy (26.8 kB) | AVIF (12.1 kB)
这是斯蒂芬·沃勒的另一幅画。我之所以选择它，是因为它具有许多纯色和清晰的线条，通常可以无损压缩，但是它也具有许多渐变，无损格式可能会遇到困难。
即使我将颜色降低到 256 种，并使 WebP 发挥其无损的魔力，结果仍然是 170 kB。在这种情况下，有损编解码器的性能要好得多。
我禁用了 JPEG 和 AVIF 的色度二次采样，以保持色彩鲜明。不幸的是，有损 WebP 没有此选项，但具有“ Sharp YUV”，它试图减少颜色分辨率降低的影响。
JPEG 在这里不能做得很好：低于 80 kB 的任何内容都会开始引入明显的块状感。 WebP 可以更好地处理图像，但是我再次被 AVIF 的表现所震惊。
看看细节
此处有对比图
放大时 JPEG 有点粗糙，您可以开始在背景中看到 8x8 色块。
使用减少调色板的WebP，您可以开始看到减少调色板的效果，尤其是在精灵的帽子中。
有损 WebP 相当模糊，并且受彩色伪影的影响，这是“ Sharp YUV”的副作用。
AVIF 的颜色确实很干净，但是有些模糊，甚至有些形状发生了变化–由于边缘检测，圆圈看起来几乎是八边形。但是只有 12 Kb！
文件大小相等时
最后一次，让我们将其他编解码器压缩到 AVIF 的大小：
此处有对比图
在这个尺寸下，JPEG 创造了自己独特的作品，WebP 看起来色块很多，且很杂乱。
总结
在这种情况下，与 JPEG 相比，WebP 的大小大大减少了，因此绝对值得将 WebP 提供给支持它的浏览器。但是，WebP和AVIF之间的差异并不大，因此创建AVIF也不值得。
🏆那么，AVIF是冠军么？
我最初对 AVIF 持怀疑态度：我不喜欢必须使用视频格式留下的边角料的想法。但是，哇，上述结果给我留下了深刻的印象。但 AVIF 也并不完美。
渐进式渲染
由于 AVIF 是视频格式的重要部分，因此它缺少一些与视频无关的有用的图像功能和优化：
此处有视频：在2g网速下 JPEG，WebP 和 AVIF 三个图片的加载过程。
上面显示了 2g 速度的高分辨率（2000x1178）高质量图像加载。为了获得大致相同的质量，JPEG 为 249 kB，WebP 为 153 kB，AVIF 为 96 kB。
尽管它们都以相同的速率加载，但是更大的 JPEG 感觉要快得多，这是因为它可以分批渲染。 WebP 从上到下进行渲染，效果不佳，但是至少您可以看到进度。不幸的是，AVIF是一次性渲染：全有还是全无。
视频不需要渲染部分帧，因此它不是要设置格式的内容。可能有像 WebP 这样的自上而下的渲染，但是实现起来很复杂，因此在可预见的将来我们不太可能在浏览器中看到它。
因此，AVIF 更适合于较小的快速加载图像。但这仍然涵盖了网络上的大多数图像。
具有 Alpha 通道的图像会使事情变得更加复杂。 AV1 规范建议主图像应出现在辅助图像之前，并且 alpha 通道将被存储为辅助图像。我们在 Squoosh 中使用的编码器 libavaif 符合此建议，并且他们对更改这一点并不感兴趣。渲染图像的一部分而不带它的 Alpha 通道看起来很难看，因此，我们可以等待整个图像加载完成再显示内容。作者：哦！从头开始，libavif的实现已更改。
编码时间
通常，对 AVIF 进行编码会花费很长时间，但是在Squoosh中尤其如此，因为我们使用的是 WebAssembly，它不允许我们使用SIMD或多线程。这些功能已开始达到标准和浏览器，因此希望我们能够尽快进行改进。
在“effort”值为2的情况下，要花好几秒钟的时间进行编码。 “effort” 3明显更好，但这可能需要几分钟。 “effort” 10（我在本文中用的）要花费 10 分钟以上的时间才能编码单个图像。
AVIF 支持分块图像，将图像切成较小的块，可以分别进行编码和解码。这对于编码很有趣，因为它意味着可以并行编码块，从而充分利用 CPU 内核，尽管 Squoosh 尚未利用这一优势。
解码时间
在解码方面，还有 CPU 使用率与其他格式的问题，但是我还没有深入探讨。尽管AV1开始获得硬件支持，但我得知会有专用硬件对进行视频解码，而在解码包含图像的页面时效果不佳。
JPEG-XL 和 WebPv2 呢？
我们构建 Squoosh 的原因之一是，开发人员可以绕过有关特定编解码器自己尝试。 JPEG-XL 尚未准备就绪，但我们会尽快将其放入 Squoosh。同时，我正在尝试解释一下 JPEG-XL 的优越性。但是，还有很多令人兴奋的事情。
JPEG-XL 是图像格式，而不是视频格式的附带内容。它支持无损和有损压缩，以及渐进式多遍渲染。看起来无损压缩将比 WebP 更好，这很棒。但是，有损压缩是针对高质量而非“可接受的质量”进行调整的，因此它可能不适用于大多数 Web 图像。但是，多遍渲染的好处可能意味着在文件大小方面值得一试。我想我们会拭目以待！
关于 WebPv2 的细节还不多，因此，最好再等一等，直到我们可以使用自己的图像对其进行测试。
就是这样！
！我没想到这篇文章会这么长。我想深入探讨这些编解码器提供的更晦涩的设置，但应该在之后了。
我真的很喜欢为本文创建一些 demo。如果您想深入研究细节：
构建 demo 细节的相关翻译略过了，有兴趣可以去读原文
