【学习图片】08：WebP

本文首发于微信公众号：大迁世界, 我的微信：qq449245884，我会第一时间和你分享前端行业趋势，学习途径等等。 更多开源作品请看 GitHub github.com/qq449245884… ，包含一线大厂面试完整考点、资料以及我的系列文章。

谷歌最初开发的WebP是一种取代JPEG的有损图像格式，它能够产生比以JPEG编码的同等质量的图像文件更小的文件。后来，该格式的更新引入了无损压缩、类似PNG的阿尔法通道透明度和类似GIF的动画等选项，所有这些都可以与JPEG式的有损压缩同时使用。WebP是一种非常多才多艺的格式。

WebP的有损压缩算法基于VP8视频编解码器用于压缩视频关键帧的方法。从高层次来看，它类似于JPEG编码：WebP以“块”为单位操作，而不是单个像素，并且具有类似亮度和色度之间的分割。WebP的亮度块为16x16，色度块为8x8，并且这些“macroblocks”进一步细分为4x4子块。

WebP与JPEG根本不同的两个特征是“块预测(block prediction)”和“自适应块量化(adaptive block quantization)”。

Block Prediction

块预测是指根据其周围块的值，特别是上方和左侧的块，预测每个色度和亮度块的内容的过程。正如你所想象的那样，执行这项工作的算法相当复杂，但用简单的语言来说，“如果当前块上方和左侧是蓝色的，则假定该块是蓝色的。”

实际上，PNG和JPEG也在某种程度上进行这种预测。然而，WebP独特之处在于它采样周围块的数据，然后通过几种不同的“预测模式”尝试填充当前块，有效地尝试“绘制”图像的缺失部分。然后，每个预测模式提供的结果将与实际图像数据进行比较，选择最接近的预测匹配。

当然，即使最接近的预测匹配也不会完全正确，因此该块的预测值与实际值之间的差异被编码到文件中。在解码图像时，渲染引擎使用相同的数据应用相同的预测逻辑，从而针对每个块生成相同的预测值。然后将编码在文件中的预期图像与预测之间的差异应用于预测值 - 类似于Git提交代表一个差异补丁，被应用在本地文件上，而不是一个全新的文件副本。

举个例子：我们不想深入了解真正的预测算法中涉及的复杂数学问题，因此我们将发明一个类似于 WebP 的编码方式，其中包含单个预测模式，并像使用旧格式一样有效地传递数字网格。我们的算法有一个称为“预测模式一”的单个预测模式：每个块的值是它上面和左边的块的值之和，从1开始。

现在，假设我们从下面的真实图像数据开始:

111151111
122456389

使用我们的预测模型来确定2x9网格的内容，我们会得到以下结果:

111111111
123456789

我们的数据很适合我们发明的预测算法--预测的数据与我们的真实数据非常吻合。当然，并不是完全吻合--实际数据有几个块与预测数据不同。因此，我们发送的编码不仅包括要使用的预测方法，还包括任何与预测值不同的块的差异。

_ _ _ _ +4 _ _ _ _
_ _ -1 _ _ _ -4 _ _

使用预测模式一的2x9网格。+4到1x5，-1到2x3，-4到2x7。

最终的结果是一个令人难以置信的高效编码文件。

自适应块状量化

JPEG压缩是一个统一的操作，对图像中的每个块应用相同的量化级别。对于具有均匀组成的图像，这当然是有道理的——但现实世界中的照片并不比我们周围的世界更加均匀。实际上，这意味着我们的JPEG压缩设置不是由高频细节（JPEG压缩擅长的部分）决定的，而是由我们的图像中最有可能出现压缩伪影的部分决定的。

在这个的例子中所看到的，前景中蝴蝶的翅膀看起来相对清晰——与高分辨率原始图像相比略微有点颗粒感，但如果没有原始图像来比较，几乎不会引起注意。同样，蜜蜂花的花序和前景中的叶子——即使把压缩级别调得超过合理水平，你和我也可能能看出一些压缩伪影，但前景中的东西看起来依然过得去。而图片左上角的低频信息——模糊的绿色背景叶子——看起来很糟糕。即使是一个没有经过专业训练的观众也会立即注意到质量问题——背景中微妙的渐变被压缩成了锯齿状、纯色的块。

为了避免这种情况，WebP采用了自适应的量化方法：图像被分成最多四个视觉上相似的部分，并独立调整这些部分的压缩参数。使用WebP进行同样过度的压缩：

这两个图像文件的大小大致相同。当我们看蝴蝶的翅膀时，它们的质量大致相同——如果你非常仔细地观察，你可以看到一些微小的差异，但总体上没有实质性的质量差异。在WebP中，蜜蜂草的花朵只是略微更清晰一些——同样，除非你将两者并排比较并真正寻找质量上的差异，否则很可能察觉不出来。然而，背景则完全不同：它几乎没有JPEG明显的伪影。WebP给我们相同的文件大小，但是更高质量的图像——除了一些我们的心理视觉系统如果不是这样紧密比较就无法察觉到的微小细节。

使用 WebP

WebP的内部机制可能比JPEG编码要复杂得多，但对于我们日常工作而言同样简单：WebP的所有编码复杂性都规范化为一个单一的“quality”值，从0到100表示，就像JPEG一样。同样，这并不意味着你只能使用一个整体“quality”设置。您可以 - 也应该 - 调整WebP编码的所有细节，即使只是为了更好地理解这些通常看不见的设置如何影响文件大小和质量。

谷歌提供了一个名为cwebp的命令行编码器，可以让你转换或压缩单个文件或整个图像目录：

$ cwebp -q 80 butterfly.jpg -o butterfly.webp

Saving file 'butterfly.webp'
File:  	butterfly.jpg
Dimension: 1676 x 1418
Output:	208418 bytes Y-U-V-All-PSNR 41.00 43.99 44.95   41.87 dB
       	(0.70 bpp)
block count:    intra4:     7644  (81.80%)
          	   Intra16:     1701  (18.20%)
          	   Skipped:       63  (0.67%)
bytes used:  header:            249  (0.1%)
         	  mode-partition:  36885  (17.7%)
Residuals bytes  |segment 1|segment 2|segment 3|segment 4|  total
macroblocks:     |       8%|      22%|      26%|      44%|   9345
quantizer:       |      27 |      25 |      21 |      13 |
filter level:    |       8 |       6 |      19 |      16 |

如果你不倾向于使用命令行，Squoosh也可以为我们提供WebP编码。它让我们可以选择在不同的编码、设置、质量水平和文件大小与JPEG的差异之间进行并排比较。

代码部署后可能存在的BUG没法实时知道，事后为了解决这些BUG，花了大量的时间进行log 调试，这边顺便给大家推荐一个好用的BUG监控工具 Fundebug。

原文：web.dev/learn/image…

交流

有梦想，有干货，微信搜索 【大迁世界】 关注这个在凌晨还在刷碗的刷碗智。

本文 GitHub github.com/qq449245884… 已收录，有一线大厂面试完整考点、资料以及我的系列文章。