使用WebP技术进行图像压缩

Question

WebP技术用于有损和无损图像压缩，比"JPEG"压缩更多。我正在学习图像压缩技术，如果有人能为我提供清晰的WebP图像压缩算法，将对我很有帮助。

- Samir Karmacharya

---

https://medium.com/@duhroach/how-webp-works-lossly-mode-33bd2b1d0670#.26c74n6re - saurabheights

我还建议您从官方代码库下载所有的jpeg、png、webp代码，包括Mozjpeg。越早这样做，对您越有益。 - saurabheights

感谢@saurabheights的建议。 - Samir Karmacharya

欢迎。很抱歉没有一次性告知所有内容：您还应该订阅他们的开发者邮件列表。您可以直接向他们提出任何问题，但请确保先阅读可用的文档。 - saurabheights

感谢您，@saurabheights。 - Samir Karmacharya

Answer 1

嗯，提供有关有损和无损压缩的完整算法，包括所有变体的详细信息，超出了这个论坛上单个答案的范围。Google免费提供有损和无损比特流规范。然而，后者相当不完整、不准确，甚至部分错误。如果按照此规范实现编解码器，将会很困难，需要学习相当多的源代码。

我可以在这里至少给您一些有关无损格式的详细信息：

• WebP和PNG一样，使用ZIP DEFLATE压缩算法的Huffman编码方法来压缩图像信息。实际上，WebP的大部分压缩效益来自于巧妙地利用Huffman编码。许多细节明显借鉴了DEFLATE，如将代码大小限制为15位，并使用另一种Huffman编码来编码Huffman字母表，这与DEFLATE几乎相同。
• 通过LZ77滑动窗口压缩和2..2048的可选颜色缓存，包括最近使用的颜色，可以实现额外的压缩。编码器可以自由决定使用哪一个。但是，在我的测试中发现，这可能对压缩比有害。照片图像通常可以使用大型颜色缓存进行压缩，并且在使用缓存时，通常最好始终为未出现在缓存中的像素使用文字ARGB编码，而不是使用LZ77后向引用。
• 尽管LZ77压缩的使用方式与DEFLATE基本相同，但Google的规范不是基于字节，而是基于像素。也就是说，ARGB四元组被压缩，而不是单个A-R-G-B字节。此外，WebP允许反向引用长度长达4096像素和引用距离长达1048576-120像素，这相当于DEFLATE的极限。使用单独的Huffman字母表来处理ARGB通道还有另一个好处。
• 像PNG一样，WebP的LZ77压缩具有RLE（Run Length Encoding）特性，这是对一种特殊情况的巧妙处理的结果，即当参考长度超过参考距离时。在这种情况下，可用的字节一遍又一遍地复制，直到达到指定的长度。我发现，使用此功能可以获得“人造”图像的很好的压缩效果，这些图像具有相同颜色的长运行。然而，它与颜色缓存冲突，后者会为这些运行生成相当有效的Huffman代码。根据我的初步测试，颜色缓存优于RLE功能。
• 像PNG一样，WebP在原始ARGB数据上表现不佳。因此，在压缩开始之前，两种格式允许对像素数据应用各种变换。这些变换确实在减少像素流的方差方面表现出色，并占据了最终压缩比的很大部分。WebP定义了13个标准预测器变换，而PNG只有4个。然而，我发现大多数预测器并没有带来太多收益，我通常使用“选择”滤波器，它选择左侧或上方的像素作为更合适的预测器。与PNG一样，简单的过滤器通常比复杂的过滤器更好。
• 除了预测器变换外，WebP还提供了其他变换，其中我只尝试了“减去绿色”的变换，它试图通过从每个像素的R和B中减去G来使RGB通道不相关。事实上，我观察到在预测器后应用此变换会有一些好处。如果在之前应用，可能会对照片图像产生负面影响。
• WebP使用5个单独的Huffman编码来处理位流：一个用于绿色通

  WebP无损压缩提供了广泛的选项可以进行组合和调整。然而，在我看来，大多数组合并不值得测试。根据我的观察，以下默认设置通常会获得很好的压缩效果：

  • 使用“选择”预测器。
  • 应用“减去绿色”变换。
  • 使用具有2048个插槽的颜色缓存。
  • 如果当前像素不在缓存中，则将其编码为文字。

- SBS