AVIF已着陆

早在古代的7月，我就发布了一段视频，深入探讨了有损和无损图像压缩的工作原理，以及如何应用这些知识为网络压缩一组不同的图像。嗯，那已经过时了，因为AVIF已经到了。非常出色。

AVIF是从AV1视频的关键帧中衍生出来的一种新的图像格式。它是一种免版税的格式，而且桌面版Chrome85已经支持它。虽然Safari花了10年时间才添加对WebP的支持，但我认为我们不会在这方面看到同样的延迟，因为苹果是AV1的创建者之一，所以很快就会增加对Android的支持，火狐也在努力实现这一功能，尽管Safari花了10年时间才添加了对WebP的支持，但我认为我们不会看到同样的延迟，因为苹果是AV1的开发者之一。

我想说的是，现在是关心AVIF的时候了。您无需等待所有浏览器都支持它-您可以使用内容协商来确定服务器上的浏览器支持，或使用<；Picture&>在客户端上提供后备：

<；Picture；<；source type="；image/avif&34；srcset="；Snow.avif&34；>；<；img alt="；src="；src="；Snow.jpg&34；>；<；/图片&>如果支持此类型，请使用此…。否则这个。

另外，squoosh现在支持AVIF，这就是我压缩这篇文章中的示例的方式。

让我们来看看AVIF与我们已经知道并喜爱的…图像格式相比是如何表现的。

我之所以选择这张照片，是因为它是一张混合了低频细节(道路)和高频细节(部分车身)的照片。此外，红色和蓝色之间的颜色也有相当剧烈的变化。我还喜欢F1。

粗略地说，在可接受的质量上，WebP的大小几乎是JPEG的一半，而AVIF的大小还不到WebP的一半。我觉得AVIF在短短18kB内就能很好地处理图像，这真是令人难以置信。

如果用户在页面上下文中查看图像，并且由于压缩而让他们觉得很难看，那么这种压缩级别是不可接受的。但是，比这一界限高出一个细微的刻度就可以了。

与原始图像相比，图像丢失明显的细节是可以接受的，除非该细节对图像的上下文很重要。

在这里，上下文是关键。图像压缩应该根据它将呈现给用户的大小以及在类似的环境中进行判断。如果你把一幅画作为一件要检查的艺术品来展示，质量和细节的保存就变得更加重要，但这只是一个边缘情况。

我在网上看到的大多数图片的质量都比需要的要高得多，这导致用户的体验变慢了。“卫报”对图片的使用总体上给我留下了深刻的印象。拿着这篇文章。如果我打开文章顶部的图像并放大，我可以看到与众不同的WebP工件。街道已经被平整了。涂鸦周围响起了一些响声。但我们不应该为那些可能放大寻找缺陷的人优化用户体验。当我看着文章中的图片，在它呈现的大小和背景下，我只看到有人骑车经过一家关门的酒吧，这就是图片的意图。那里使用的压缩产生了很小的资源大小，这意味着我很快就看到了图像。

在本文中，我对图像进行了优化，就像它们出现在文章中一样，其中CSS宽度约为其像素宽度的50%，这意味着它们已针对高密度显示进行了重新优化。

嗯，“技巧”这个词可能用得太重了。为了压缩图像，我使用了squoosh。我将图像缩小到50%，向下拖动质量滑块，直到它看起来很差，然后将其向后移动了一点。如果编解码器有一个努力设置，我会将其设置为最大。我还使用了一两个高级设置，我将在此过程中指出这些设置。

但这些只是我的估计。我正在使用我安全地保存在头骨里的人类眼球来比较这些图像，而不是任何试图猜测人类如何感知图像的算法。当然，人类的感知也存在偏见。

事实上，当我把这篇文章拿给Kornel Lesiński看(当涉及到图像压缩时，他知道自己在说什么)时，他对我上面的F1比较很不满意，因为JPEG的DDSIM值比其他的要低得多，这意味着它在质量上更接近原始图像，而…。他是对的。

我费力地把F1图像压缩成JPEG格式。如果我低于74kB，道路上的条带对我来说就变得非常明显，道路的一些灰色部分以一种明显的方式显示为略微紫色，但Kornel能够调整MozJPEG中的量化表以获得更好的结果：

虽然我很乐意花时间手动压缩网站的关键图像，但我真的不需要以这种方式调整JPEG编码器的技能。因此，这篇文章的结果也反映了编解码器能用我中等的天赋和毅力做些什么。

我还意识到，手动调整每个图像的编解码器设置并不会影响比例。如果您需要自动压缩图像，您可以从几张有代表性的图像中手动计算出设置，然后为安全添加一些额外的质量，并在自动工具中使用这些设置。

我为每个图像提供完整的输出，以便您可以做出自己的判断，并且您可以使用squoosh尝试使用您自己的图像。

*咳嗽*对这一切感到抱歉。我只是想走在这股热潮的前头，那如果真的是这样呢，那实际上是怎么回事呢，而且实际上也是这样的。(这句话的意思是：“如果…”怎么样？

这条路的细微细节在所有的压缩版本中都丢失了，我对此没什么意见。然而，您可以在Kornel所说的细节上看到不同之处。看看原件中的红色车身，有三个截然不同的部分-镜子，连接挡板的机翼，以及侧舱的顶部。在AVIF中，平滑消除了这些部分之间的划分，但它们大部分仍然存在于JPEG中，特别是74kB版本。

在JPEG版本中，您也可以看到DCT的各个8x8块，但是当缩小时它们并不明显。WebP使用解码过滤器避免了这种阻塞，而且，嗯，只是做得更好。AVIF在保留清晰线条方面做得更好，但引入了平滑。这些都是减少图像中数据的方法，但是AVIF中的伪像没有那么难看。

如果你在想，等等，他在说什么？AVIF在红/蓝的周围真的是块状的，嗯，很有可能你会在Chrome85上看到它。当涉及到放大颜色细节时，解码器中有一个错误。这在86中大部分是固定的，尽管也有一些边缘情况仍然会发生。

如果您想了解更多有关有损编解码器如何工作的详细信息，请查看我从4：44开始的演讲。

使编解码器之间的差异真正明显的一种方法是在大致相同的文件大小下测试它们：

我甚至无法将JPEG和WebP调到18kB，即使在最低设置下也是如此，所以这不是一个完全公平的测试。JPEG有可怕的条带，当我降到74kB以下的时候就开始出现了。WebP要好得多，但与AVIF相比，仍然存在明显的块状现象。我想这就是十年或二十年的进步是什么样子。

除非它是自动化的，否则提供同一张图片的3个版本是一件有点痛苦的事情，但这里的节省是相当可观的，所以它似乎是值得的，特别是考虑到已经可以从AVIF中受益的用户数量。

原始跟踪SVG(12.5 kB)PNG 68色(16.3 kB)WebP 68色无损(12.9 kB)AVIF 68色无损(41.7 kB)。

这是斯蒂芬·沃勒(Stephen Waller)的插图。我选择它是因为它锋利的边缘和纯色，所以它是无损压缩的一个很好的测试。

这张图片看起来颜色不是很多，但是由于边缘的抗锯齿效果，它有几千种颜色。在情况开始变得糟糕之前，我就把颜色降到了68色。这对WebP无损和PNG有很大的不同，当256色或更少时，它们会切换到调色板模式，压缩效果真的很好。

同样，AVIF是从AV1视频的关键帧派生出来的，WebP的有损压缩也是基于VP8视频的关键帧。但是，无损WebP是一种不同的编解码器，是从头开始编写的。它经常被忽视，但它的表现每次都比巴新好。

我没有这个图像的原始矢量版本，但我使用Adobe Illustrator创建了一个跟踪的SVG版本，以便对SVG的性能有一个非常粗略的了解。

值得注意的是，AVIF在这里的表现有多么糟糕。它确实有一种特殊的无损模式，但它不是很好。

我直接对这张图片进行调色板压缩和无损压缩，因为经验告诉我，有损压缩在这些类型的图片上总是做得不好。或者我是这么想的，…。

原始跟踪SVG(12.5 kB)PNG 68彩色(16.3 kB)WebP 68彩色无损(12.9 kB)AVIF(8.69 kB)。

事实证明，有损AVIF可以很好地处理纯色和锐利的线条，并且生成的文件比SVG小得多。我在AVIF中禁用了色度子采样，以保持颜色的锐利。

原始跟踪SVG(12.5 kB)PNG 68彩色(16.3 kB)WebP 68彩色无损(12.9 kB)AVIF(8.69 kB)。

我原以为有损的编解码器会破坏边缘，但它看起来很棒！在左边的人的眼镜上方和右边的人的耳朵上都有一点非常模糊的痕迹。如果说有什么不同的话，那就是AVIF引入了一些锐化-请看眼镜的左侧。这种锐化通常是通过减少调色板来实现的，但这里正是AVIF的工作方式，这要归功于定向变换和滤镜。

由于调色板的减少，PNG和WebP在绿色衬衫周围有锐利的边缘，但在正常尺寸下并不是很明显。

当然，由于矢量缩放，SVG看起来非常锐利，但您可以看到跟踪丢失了右边那家伙头发和口袋周围的细节。

事情并不像F1图片那样糟糕，但是JPEG噪音很大，颜色变化很大，WebP很模糊，PNG显示，嗯，你需要8种以上的颜色。

AVIF有点让我大吃一惊。这让我重新考虑有损编解码器适合的图像类型。

但总而言之，在这里，一个合适的SVG可能是正确的选择。但是，即使SVG不能使用，PNG和AVIF之间的差别也只有几kB。在这种情况下，可能不值得复杂地创建不同版本的图像。

原始SVG(82.3 kB)优化的SVG(30.8 kB)PNG 256色(84.6 kB)WebP(50.6 kB)AVIF(13.3 kB)。

我觉得这张图片是用SVG创建的，这太不可思议了。然而，这是有代价的。涉及的形状和滤镜的数量意味着浏览器渲染它需要大量的CPU。它是那些边缘情况之一，它最好避免原始的SVG，即使替代方案更大。

巴新在这里由于平滑的渐变而挣扎。我把颜色降到了256色，但我不得不抖动它们，以避免可见的条带，这也会影响压缩。

通过将有损压缩与Alpha通道混合在一起，WebP的性能要好得多。但是，Alpha通道始终在WebP中无损编码(除了一些调色板减少)，因此当涉及到汽车下方的透明渐变时，它会受到与PNG类似的影响。

即使与SVG相比，AVIF在明显更小的大小上再次使其成为王牌。AVIF的部分优势在于它支持有损的Alpha通道。

原始SVG(82.3 kB)优化的SVG(30.8 kB)PNG 256色(84.6 kB)WebP(50.6 kB)AVIF(13.3 kB)。

放大PNG时，可以看到调色板缩小的效果。WebP变得越来越模糊，并且受到一些颜色噪声的影响。

AVIF看起来与WebP相似，但尺寸要小得多。有趣的是，AVIF只是有点放弃绘制引擎盖，但它几乎没有注意到当它缩小。

PNG版本看起来有点酷！而WebP版本让我想要擦拭我的眼镜。

是的，从86/50kB降到13kB是一笔巨大的节省，值得付出额外的努力。

这是斯蒂芬·沃勒的另一篇文章。我之所以选择这个，是因为它有很多平坦的颜色和清晰的线条，这通常意味着无损压缩，但它也有很多渐变，这是无损格式可能难以处理的。

即使我把颜色降到256色，让WebP发挥它的无损魔力，结果仍然是170kB。在这种情况下，有损编解码器的性能要好得多。

我禁用了JPEG和AVIF的色度子采样，以保持颜色的锐利。不幸的是，有损的WebP没有这个选项，但它有夏普YUV&34；，它试图减少色彩分辨率降低的影响。

JPEG在这里做得不是很好-任何低于80kB的东西都会开始引入明显的块状效应。WebP对图像的处理要好得多，但AVIF的表现也让我大吃一惊。

JPEG在放大时非常嘈杂，您可以开始在背景中看到8x8的块。

使用简化的调色板WebP，您可以开始看到减少调色板的效果，特别是在精灵的帽子中。

有损的WebP相当模糊，并且有彩色制品，这是夏普YUV&34；的副作用。

AVIF的颜色真的很干净，但有些模糊，甚至还稍微改变了一些形状-由于边缘检测，圆圈看起来几乎是八角形的。但是C'；MON，12KB！

在这些尺寸下，JPEG已经完成了自己的艺术，而WebP看起来既笨重又凌乱。

在这种情况下，与JPEG相比，WebP的大小有了很大的下降，所以向支持WebP的浏览器提供WebP绝对是值得的。然而，WebP和AVIF之间的差别并不大，因此可能也不值得创建AVIF。

我最初对AVIF持怀疑态度--我不喜欢网络不得不捡起视频格式留下的残留物的想法。但是，哇，上面的结果给我留下了深刻的印象。也就是说，它并不完美。

由于AVIF是一种视频格式的临时格式，因此它缺少一些与视频无关的有用图像功能和优化：

上图显示了2G速度下的高分辨率(2000x1178)、高质量图像加载。为了获得大致相同的质量，JPEG为249kB，WebP为153kB，AVIF为96kB。

虽然它们都以相同的速率重新加载，但大得多的JPEG感觉更快，因为它在多个通道中的渲染方式。WebP从上到下呈现，这不是很好，但至少您看到了进展。不幸的是，对于AVIF来说，要么全有，要么一无所有。

视频不需要渲染部分帧，因此它不是该格式设置要做的事情。像WebP这样的自顶向下呈现是可能的，但实现起来会很复杂，所以在可预见的将来我们不太可能在浏览器中看到它。

对于具有Alpha通道的图像，情况会变得更加复杂。AV1规范建议主图像应显示在辅助图像之前，并且Alpha通道存储为辅助图像。我们在sqoosh中使用的编码器libavaif符合这一建议，他们对改变这一点不是很感兴趣。在没有Alpha通道的情况下渲染图像的一部分会看起来非常难看，因此在显示任何内容之前，我们会回到等待整个图像加载的状态。

正因为如此，AVIF感觉更适合较小、加载速度更快的图像。但这仍然涵盖了网络上的大多数图片。

一般来说，编码AVIF需要很长时间，但在squoosh中尤其糟糕，因为我们使用的是WebAssembly，它不允许我们使用SIMD或多线程。这些功能正开始进入标准和浏览器，所以希望我们能很快改进。

在2的努力'；，它需要很好的几秒钟来编码。付出的努力要好得多，但这可能需要几分钟的时间。对单个图像进行编码可能需要10分钟以上的时间(我在本文中使用的是图像)。

AVIF支持平铺图像，它将图像切成可以单独编码和解码的较小块。这对于编码来说很有趣，因为这意味着块可以并行编码，充分利用CPU核心，尽管squoosh还没有利用这一点。

当涉及到解码时，还有一个CPU使用率与其他格式相比的问题，但我还没有深入研究这一点。虽然AV1开始获得硬件支持，但我告诉他们，专用硬件将针对视频进行调整，在解码一整页图像方面不是很出色。

我们构建squoosh的原因之一是，这样开发人员就可以绕过关于特定编解码器的声明，而只是自己尝试一下。JPEG-XL还没有完全准备好，但我们会尽快将其安装到squoosh中。与此同时，我正试图对JPEG-XL声称的优越性持保留态度。然而，还有很多值得兴奋的地方。

JPEG-XL是一种图像格式，而不是视频格式的剪辑。它支持无损和有损压缩，以及渐进式多通道渲染。看起来无损压缩将比WebP&39；s更好，这很棒。但是，有损压缩是针对高质量而不是可接受的质量进行调整的，因此它可能不太适合大多数Web图像。但是，多遍渲染的好处可能意味着在文件大小方面值得一试。我想我们还是拭目以待吧！

关于WebPv2的细节还不是很多，所以最好还是拭目以待，直到我们可以用我们自己的图片来测试它。

哟！我没想到这篇帖子会这么长。我想包括一个潜水到这些编解码器提供的更模糊的设置，但我会把它留到另一天。

我真的很喜欢为这篇文章构建演示。如果您想深入了解细节：

我构建了一个Preact组件来处理图像加载和解码，因此即使没有浏览器支持，AVIF/WebP也可以工作。工作人员使用squoosh中的WebAssembly解码器处理实际解码。我通常使用comlink来帮助员工沟通，但缺乏与员工模块的兼容性意味着我会选择更小/更黑的工具。

我希望此页面上的演示成为静态构建的一部分，以避免布局改变，但我不想使用JS(您在Gatsby和Next.JS之类的东西中经常看到的一种模式)重新呈现整个页面。我拼凑了一个解决方案，其中我的标记包含<；HTMLscript type=<；​script type="；Component"；>；，它在解析标记时被替换为该组件的HTMLHTML，并在客户机上变为活动状态。

这里是渐进式图像加载演示。它在服务工作者中使用TransformStream来限制图像数据。

在演讲中，而不是在本文中，我构建了一个工具，允许您尝试色度子采样。

同样从演讲中，我构建了一个工具来可视化形成8x8块的DCT模式。

感谢Kornel Lesiński，Surma，Paul Kinlan，Ingvar Stepanyan和Sam Jenkins的校对和事实核查！