移动到前置变换和BWT后应用运行长度变换的效率如何?

时间:2012-12-25 01:18:36

标签: encoding compression transformation run-length-encoding burrows-wheeler-transform

我是编码的新手,所以我想了解基础知识。我遇到了一个描述无损文本压缩技术的文档,在本文档中有一个图解说明了它们的压缩工作原理。它的工作原理如下:

Source -> BWT -> MTF -> RLT -> Proprietary Entropy Encoder

我不明白为什么他们会在Move to Front Transform之后使用Run-Length Transform,这对我来说似乎并不高效。据我了解,MTF本身并不会产生很多运行,因此使用RLT后没有用。

非常感谢一些解释!

2 个答案:

答案 0 :(得分:1)

BWT之后的MTF的目标是缩小有利于熵编码的符号范围。由于BWT产生的重复,MTF将其符号替换为通常较小的符号。之后可以应用零长度编码,因为MTF可能产生大量的0(这只是RLE的一个特定情况,其中只有0的运行按长度编码)。

查看https://code.google.com/p/kanzi/的实施示例。您可以使用带有或不带MTF + ZLE的Block编解码器运行BlockCompressor。

答案 1 :(得分:0)

效率不高。

这可能是关于BWT的一篇旧论文。那时候,使用RLE(游程编码器)是提高速度的常用技巧。 RLE,顺便说一句,不仅在BWT之后使用,而且之前也用于加速BWT阶段。 相同的逻辑可以应用于熵编码器,但它不太可能提供那么多的好处。

如今,这个伎俩完全过时了。 在BWT之前,您可能会发现某种LZP预处理,特别是对于远程匹配(超出块大小),与RLE关于速度提升的意图大致相同,但更强大。 MTF也完全被替换,因为它太占用CPU而且效率不高。