哦，提供有损和无损压缩的整个算法，包括所有变体的全部细节，远远超出了本论坛的单一答案。 Google免费提供lossy和lossless位流的规范。然而，后者非常不完整，不准确，甚至部分甚至是错误的。您将很难根据此规范实现编解码器，并且研究相当多的源代码也是必不可少的。
我可以在这里至少给你一些关于无损格式的细节：
- 与使用ZIP DEFLATE压缩算法的PNG一样，WebP也对所有图像信息使用霍夫曼编码。实际上，WebP的大部分压缩增益源于巧妙地使用霍夫曼编码。许多细节显然是借用DEFLATE，即将代码大小限制为15位，并使用另一个霍夫曼代码对霍夫曼字母进行编码，这与DEFLATE使用的几乎相同。
- 通过LZ77滑动窗口压缩和尺寸为2..2048的可选颜色缓存实现额外压缩，包括最近使用的颜色。编码器可以自由决定使用哪一个。两者都可以混合。但是，我在测试中发现这可能对压缩率有害。摄影图像通常使用大色缓存进行精细压缩，使用缓存时，通常最好对缓存中不存在的像素使用文字ARGB编码，而不是使用LZ77反向引用。
- 虽然LZ77压缩的使用与DEFLATE几乎相同，但Google的规范并非基于字节，而是基于像素。也就是说，ARGB四倍是压缩的，而不是单独的A-R-G-B字节。此外，WebP允许后向参考长度高达4096像素，参考距离高达1048576 - 120像素，这远远超出了DEFLATE限制。另一个好处是通过为ARGB频道使用单独的霍夫曼字母来获得。
- 与PNG一样，WebP LZ77压缩具有RLE（运行长度编码）功能，这是在参考长度超过参考距离时巧妙处理特殊情况的结果。在这种情况下，可用字节反复复制，直到达到指定长度。我发现使用此功能可以对长度相同颜色的“人工”图像产生很大的压缩效果。但是，它与颜色缓存冲突，这将为此类运行生成非常有效的霍夫曼代码。根据我的初步测试，色彩缓存优于RLE功能。
- 与PNG一样，WebP在原始ARGB数据上表现不佳。因此，两种格式都允许在压缩开始之前对像素数据应用各种变换。这些变换确实可以很好地减少像素流的方差，并且可以解决大量的压缩比。 WebP定义了13个标准预测变换，而PNG只有4个。但是，我发现大多数预测变量都不会产生很大的增益，我通常使用“选择”滤波器，它选择左边的像素或者以上，哪一个看起来更适合作为预测者。与PNG一样，简单过滤器通常比复杂过滤器更好。
- 除了预测变换之外，WebP还提供了一些其他的变换，其中我只尝试了“减去绿色”，它试图通过从每个像素的R和B中减去G来去除RGB通道的去相关。事实上，在预测器之后应用时，我发现了一些好处。如果之前应用，可能会对照片图像产生负面影响。
- WebP为比特流使用5个独立的霍夫曼代码：一个用于绿色通道，LZ77长度代码和颜色缓存索引，一个用于红色通道，一个用于蓝色通道，一个用于alpha通道，以及一个对于LZ77距离代码。这是一个聪明的设计，因为ARGB频道中的信息可能非常不相关，因此将它们合并为单个字母表可能不是最理想的。
WebP无损提供了广泛的选项，可以组合和调整到最大。但是，在我看来，大多数组合都不值得测试。根据我的观察，压缩通常很好，具有以下默认值：
- 使用“选择”预测器。
- 应用“减去绿色”转换。
- 使用带有2048个插槽的颜色缓存。
- 如果当前像素不在缓存中，请将其编码为文字。