译文作者:张小朵，一个热爱生活，追求完美的搬砖工。
本文译自：http://jakearchibald.com/2020/avif-has-landed， 如与原文内容有出入，请以原文为准，并欢迎指正。
早在7月我发布了一个视频，深入探讨了有损和无损图像压缩的工作原理，以及如何应用这些技术压缩一组不同的用在网页中的图片。然而，这些却因为AVIF的到来已经过时了。哇哦~
AVIF是从AV1视频衍生而来的一种新的图像格式。它不仅是开源的，并且已经可以在Chrome 85上应用。Android和Firefox也在努力支持中，虽然Safari花费了10年的时间来支持WebP格式，但我不认为这次我们还会等那么久，毕竟苹果是AV1的创始成员之一。
我想说的就是，现在正是关注AVIF的时候。不需要等所有的浏览器都支持它-你可以使用内容协商来确定浏览器的支持情况，或者使用
方式在客户端上进行降级处理。
image
接下来文章中的图片都是采用Squoosh进行压缩的。
让我们来看看AVIF是如何压缩图片的。
动静结合图的压缩对比
我选择这张照片是因为它混合了静态景象(道路)和动态景象(汽车)。同时，在红色和蓝色之间有一些明显的颜色变化。当然，也因为我喜欢F1。
简单来说就是，在可接受的画质下，WebP的大小几乎是JPEG的一半，而AVIF的大小还不到WebP的一半。我觉得更惊艳的是，AVIF处理好一张图片大概只需要18kb。
在我进一步比较之前，先来说说:
什么是“可接受的画质”?对于网络上的大多数图片，我的标准是:
- 如果用户在浏览网页时，由于压缩导致图片变型或失真，那么这个级别的压缩肯定是不能接受的。如果只是在图片的边缘有细微的瑕疵，那我认为是可以接受的。
- 与原始图像相比，压缩过的图片失去一些细节是无关紧要的，除非这个细节对图片本身非常重要。
图片的用途是关键。在相同情况下，图像压缩应根据它将呈现给用户的大小来判断。如果您将一幅图片作为一件艺术品进行检验，质量和细节保存将变得更加重要，但这只是一种特例。
我在网页上看到的大多数图像的画质都比他们所需要的更高清，这会导致更慢的用户体验。但是给我留下深刻印象的是《卫报》对图片的使用。随便打开一篇文章。如果我打开文章中的图片并放大，我可以看到更高清的WebP图片。例如干净的街道，涂鸦的细节。当然我们不需要为那些吹毛求疵的人优化用户体验。当我看文章中的图片时，我看到有人骑着自行车经过一家关门的酒吧，这就是图片本身的内容。AVIF可以压缩出更小的图片，以便用户更快的浏览。
在这篇文章中，我将优化图片，就像它们出现在网页中一样，其中它们的 CSS 宽度约为像素宽度的 50%，这意味着它们针对高密度显示器进行了优化。
技术“技术”这个词可能太大了。我使用Squoosh去压缩图片时。直接把图片缩放到极限，然后再一点点放大，每放大一点时，我用Squoosh的编解码器参数“努力”设置成最佳，我还使用了一两个高级设置，这个我后面再说。
但这个方法只是我的估计。因为我是用肉眼在比较这些图片，而不是任何一种计算机算法所模拟的人类视觉。当然，人类的视觉也有偏差。
事实上,当我把这篇文章给Kornel Lesiński(一个真正了解图片压缩原理的人)时,他并不满意我上面那张图片的比较结果。因为JPEG DDSIM score比其他参数低得多,这意味着它的质量接近原始图像，然后…他是对的。
我尝试将这张赛车图片压缩为JPEG格式时，一旦这个图片的大小小于74kb时，道路上的条带就会变得非常明显，并且道路的一些灰色部分出现肉眼可见的紫色，但Kornel能够用MozJPEG通过调整图层来优化图片:
尽管我很乐意花时间手动调整网页图片中的关键参数，但我真的不具备用同样的技术调节 JPEG的编解码器。因此，这篇文章的结果也反映了编解码器可以做什么，和我有限的能力。。
我还意识到，手动调整每个图像的编解码器设置不能批量化处理。如果需要自动执行图像压缩，可以从一些具有代表性的图像中挑选出一些重要参数，这些参数设置成最优比。设置好之后，把它应用在自动化工具中。
我会提供每个图片的所有压缩步骤便于你做出自己的判断。你也可以用你自己的图片在Squoosh中尝试。
回到F1赛车图像让我们仔细看看，看看编解码器是如何工作的:
道路的精细细节在所有压缩版本中都是丢失的，这是我可以接受的。然而，你可以看到 Kornel 所谈论的细节上的差异。看原图当中的红色车体部分，有三个明显的不同-车体的镜面效果，机翼连接板，和车体两侧。这些在AVIF中，表现的更加平滑没有颗粒感，但JPEG格式的颗粒感会表现的更加明显，特别是在小于74kb的图片中。
在JPEG格式的图片中，您还可以看到DCT的单个 8x8 色块，但缩小后就不明显了。WebP格式用它的技术一定程度避免了这种色块的问题，但也仅仅就好了一点。AVIF在在色块明显的区域比其他的格式处理的更加平滑。以上提到的都是减少图像中数据的方法，但是AVIF比其他表现的更好。
如果你阅读到这想说，AVIF也并没有很好的处理这些色块的问题。有可能是因为你的浏览器版本问题。Chrome 85在处理一些图片色彩的问题上存在一些bug。这些bug已经在Chrome 86中修复掉了，当然还是会有一些特殊情况出现。
如果你想了解更多编码器是如何工作的，可以查看我的视频，从4:44开始。
文件大小相等的情况下有一种方法可以比较不同格式解码器的差异，那就是用大致相同的文件大小来测试它们:
即使调到最低设置，我也不能把JPEG和WebP降低到18kb一下，所以这不是一个不完全公平的比较。JPEG有糟糕的色带问题，而且一旦小于74kb，它就开始出现了。WebP格式要稍微好一点，但与AVIF相比仍然有明显的色差。我想这就是这二十年来图片压缩技术的发展。
结论除非它是自动化处理的，否则同时展示一个图片的三种格式是有点麻烦的。但是，这个结果对于用户来说却是非常重要且值得的。特别是已经从AVIF格式中获益的大量用户。
图一的全方位展示结果。
平面插图的压缩对比
这是Stephen Waller画的插图。我选择它是因为它清晰的边缘和明艳的色彩，所以它非常适合用来做无损压缩测试的样片。
虽然图像看起来没有过多的色彩，但由于图片中不同颜色之间的衔接部分很多。在图片变得难以辨认之前，我把色值减少到68。当切换到小于256“调色板”模式时，图片色值的降低会优化webP和png图片格式的压缩效果。
类似于AVFI是AV1的衍生格式，webP的有损压缩也是基于VP8的衍生格式。然而，无损的webP是一种完全不同的编解码方式。它经常被忽视，但它每次都比PNG显示的更好。
虽然我没有这张图片的原图，但是我用Adobe Illustratorr创建了一个可溯源的SVG版本，以便于得到一个近似的原图。值得注意的是，AVIF在这里有一个缺点。它虽然有一个特定的无损模式，但却没有svg表现的好。
但是等一下…
为什么不能做到无损?我直接降低了这张图片的色值和无损压缩，因为经验告诉我，有损压缩在这类图片上总是做得不好。至少我是这么想的……
事实证明无损AVIF可以很好地处理明艳的颜色和清晰的线条，并生成一个比SVG小一点的文件。但是在AVIF的色度抽样中就不能继续保证色彩和线条了。
局部图片对比
我本以为有损压缩会破坏图片边缘的清晰感，但它看起来很棒！仅在左边这个人的眼镜上和右边这个人的耳朵上有一点点模糊。如果有什么不同的话，就是在左边的镜片上能够看出AVIF的一定锐化。这种锐化程度的产生是由于色值降低所导致的，但是在本图当中是因为AVIF的定向转变和过滤所导致的。
PNG和WebP有更粗糙的边缘，特别是在绿色衬衫的部分是由于色值降低导致的，但是在原始大小的图片中它并不明显。
当然，你可以用过SVG的矢量特性，查看头发和口袋原本的样子。
文件大小相等的情况下让我们把其他的解码器压缩到AVIF的大小:
在同样大小的情况下，这张图片的呈现效果要优于赛车图片。但是，JPEG的噪点非常高，而且颜色有些失真，webP有些模糊，而PNG如上图所示，需要调高色值。
结论AVIF的表现让我有了新的想法，这让我重新思考了不同图片格式的应用。
但如上述所说，合适的SVG格式是这张插画的最佳选择。即使不能使用SVG，PNG和AVIF之间的差别也只有几个kB。在这种情况下，创建不同格式的图片是没有意义的。
图二的全方位展示结果。
超大SVG图的压缩对比
我觉得难以置信的是，这张图片是用SVG创建的。通常SVG创建大图是有代价的，所涉及的图形和颜色的处理意味着浏览器渲染它需要占用大量的CPU内存。这是最好避免使用原始SVG格式的情况。但是这张图是个例，因为它比其他图片的格式更小。
在这张图中，PNG由于平滑的色彩过渡在这张图上的表现也不错，但这是因为我把色值减少到了256，，但我不得不高频振动它们，以避免明显的色带，但这个方法不利于压缩。
WebP通过将有损压缩和alpha通道混合在一起，可以让图片成像更佳。然而，alpha通道总是在WebP中进行无损编码(除了一点色值的降低)，所以当涉及到汽车下面的透明渐变时，它呈现出了和PNG一样的效果。
AVIF的突出优势是它极小的图片大小，即使和SVG相比。AVIF的部分优势在于它支持有损alpha通道。
局部图片对比
当放大到PNG图片格式时，您可以看到色值降低的影响。WebP格式有点模糊，并且有颜色噪点的产生。
AVIF格式看起来和WebP很像，但是图片大小要小得多。有趣的是，AVIF只是有点放弃引擎盖部分的着色，但是在缩小到正常图片大小的时候，很难被注意到。
文件大小相等的情况下和往常一样，让我们把其他格式的大小推到AVIF:
PNG格式看起来有点像漫画图，然后而WebP格式让我想要擦一下我的眼镜。
结论是的，从86/50kb降到13kb是一个巨大的跨越，对比结果是值得我们思考的。
图三的全方位展示结果。
颜色梯度图的压缩对比
这是Stephen Waller的另一个插画。我选择这个是因为它有很多浅淡的色彩和清晰的线条，这通常指向无损压缩，但它也有很多颜色梯度，这是无损格式可能较难处理的地方。
即使我把色值降低到256，并让WebP发挥它的无损处理优势，结果图片大小仍然有170 kB。所以在这个案例当中，有损压缩模式可能会表现更佳。
我禁用了JPEG和AVIF的色度抽样，以保整色度不变。不幸的是，有损WebP没有这个选项，但它有“Sharp YUV”，试图减少色彩分辨率降低的影响。
JPEG在这里做得不是很好 —— 任何低于80kb的文件都有明显的色块。WebP处理图像要好得多，但AVIF的表现再一次让我惊艳。
局部图片对比
放大后，JPEG的噪点非常高，你可以在背景中看到明显的色块。
在WebP中，你可以看到色值降低的影响，特别是在小精灵的帽子上。
WebP的有损模式更加模糊，这是“Sharp YUV”的副作用。
AVIF又重新使色彩变得明艳，但仍然有一点模糊，甚至改变了一些图形的形状 - 例如圆形的边缘看起来更接近八角形。但是拜托，它只有12kb !
文件大小相等的情况下最后一次，让我们把其他的图片大小降低到和AVIF一样:
在这些大小上，JPEG已经完全失真，而WebP看起来有更加明显的色块。
结论在这个案例中，与JPEG相比，WebP在大小上有了很大的下降，所以在支持webP格式的浏览器上使用它是非常值得的。然而，WebP和AVIF之间的差异不是很大，所以可能不值得创建一个AVIF格式的图片。
图四的全方位展示结果。
所以AVIF是冠军吗？起初，我对AVIF持怀疑态度——我不喜欢图片是视频的片面表现形式的想法。但是， 我对上面的分析结果印象深刻。但话又说回来，它并不完美。
进一步的呈现因为AVIF是视频格式的一个截图，它缺失了一些明显的图片特点同时优化了一些视频无关的内容:
请在原文中查看视频
上面显示了一个高分辨率(2000x1178)，高质量的图片加载在2G的速度下。为了获得大致相同的质量，JPEG是249kb, WebP是153kb, AVIF是96kb。
虽然它们都以相同的速度加载，但大得多的JPEG感觉更快，因为它多频的加载方式。WebP从上到下渲染，虽然不是很好，但至少你看到了进展。不幸的是，和AVIF，它们只能靠边站了。
视频是不需要一点一点去渲染的，所以这并不是格式的问题。也可以像WebP一样从上到下呈现，但是实现会很复杂，所以在可预见的将来我们不太可能在浏览器中看到它。
正因为如此，AVIF感觉更适合加载速度更快的小图片。但这仍然涵盖了网络上的大多数图像。
比如更大的图片问题，可以通过格式本身嵌入一个预览版本的图片在文件刚打开的时候来解决。如果浏览器没有文件的其余部分，它会呈现这个。因为这是一张不同的图片，开发人员可以选择质量、分辨率，甚至可以使用滤镜，比如模糊:
image
给这样一张大的图片增加5kb看起来是值得的，这样可以获得低质量的早期渲染效果。它的样子是这样的:
请在原文中查看视频
我已经向AVIF规范人员提出了这个建议。
编码时间AVIF编码通常需要很长时间，但在Squoosh中尤其糟糕，因为我们使用的是WebAssembly，而WebAssembly不允许我们使用SIMD和多线程操作。这些特性已经开始在浏览器的标准中应用了，所以希望我们能很快改进。
在“最优选项”为版本2时，编码还只要花费几秒钟的时间。“最优选项”版本3中图片效果有了明显的提高，但是编码却要花费几分钟的时间。‘最优选项’版本10(我在本文中用的版本)中，优化一个图片却需要超过10分钟的时间。
AVIF支持平铺图像，它将图像分割成更小的块，可以分别进行编码和解码。这对于编码来说是很有趣的，因为这意味着块可以并行编码，充分利用CPU核心，尽管Squoosh还没有利用这一点。
这个命令行工具能够一键平铺图片，比编码再解码要快很多，当然你也可以用compile libavif，或者是在OSX上，安装这个程序：
brew install joedrago/repo/avifenc
还有一个Rust实现，cavif。
我目前的工作流程是使用Squoosh在“最优选项”版本2中修改参数，然后使用libavif在“最优选项”版本10中尝试相同的设置。希望我们能加快Squoosh版本的更新!
解码时间在解码时，还有CPU使用与其他格式相比的问题，但我还没有深入研究这个问题。虽然AV1已经开始研发硬件支持，但我听说研发出的硬件将会优先支持视频格式，所以在解码图片时效果不太好。
那么JPEG-XL和WebPv2呢?我们创建Squoosh的原因之一是，开发人员可以绕过那些关于特定编解码器的标准，而只是自己尝试。JPEG-XL还没有完全准备好，但我们会尽快把它加入Squoosh。与此同时，我试图对JPEG-XL宣称的优越性持保留态度。然而，还是有很多让人兴奋的事情。
JPEG-XL是一种图片格式，而不是视频格式的剪切。它支持无损压缩和有损压缩，以及渐进式的多遍渲染。看起来无损压缩比WebP的要好。然而，有损压缩的图片画质比“可接受画质”更好，所以它可能不适合大多数的网页图片。但是，多遍渲染的好处可能意味着当涉及到文件大小时，它有些得不偿失。我们可以拭目以待!
关于WebPv2还没有太多的细节，所以最好还是等着看，直到我们能用自己的图片来测试它的优缺点。
哇哦!我没想到这篇文章会写这么久。我想更深入的研究这些编解码器提供的设置，但我将保留现在的进度，等待后续的研究。
我很喜欢这篇文章中的Demo测试。如果你想深入了解细节:
- 我构建了一个Preact组件来处理图像加载和解码，所以AVIF/WebP可以在没有浏览器支持的情况下工作。开发者可以使用Squoosh的WebAssembly解码器处理实际的解码。我通常使用comlink来帮助开发人员进行沟通，但由于缺少工作模块的兼容性，所以我选择了更小、更复杂的工具来代替它。
- 我希望这个页面上的演示是静态构建的一部分，以避免布局转移，但我不想用JS重新渲染整个页面(这种模式你在Gatsby和Next.JS中经常看到)。我实现了一个解决方案，其中我的markdown被包含在< script type="component">中，在解析新标签的时候，这种方案会将其替换为HTML，并在客户端实时展示。
- 整个页面比较视图使用Squoosh提供的 two-up and pinch-zoom web 组件。
- 下面是渐进式图像加载演示。它在服务开发人员中使用TransformStream来限制图片数据。
- 为了文章中的视频，我构建了一个工具，可以让你感受图像二次压缩的应用。
- 同样，为了这些视频，我构建了一个工具来可视化DCT模式中清晰的看到8x8色块的问题。
译文作者:张小朵，一个热爱生活，追求完美的搬砖工。
本文译自：http://jakearchibald.com/2020/avif-has-landed， 如与原文内容有出入，请以原文为准，并欢迎指正。
,
