我正在尝试找到LZ77的正确实现,LZ77是the 1977 paper中原始的著名算法。我发现有许多不同的实现会产生不同的输出,但仍标记为LZ77。例如,有些使用哈希表,而LZRW或LZJB等更“正式”的算法中使用了哈希表。所以我很困惑。
我测试了一些实现:
据我所知,没有人使用任何后处理编码,例如霍夫曼(Huffman)等。
我以前压缩的文本:
Oho! Oho! Rise up, O Teti!
Take your head, collect your bones,
Gather your limbs, shake the earth from your flesh!
Take your bread that rots not, your beer that sours not,
Stand at the gates that bar the common people!
The gatekeeper comes out to you, he grasps your hand,
Takes you into heaven, to your father Geb.
He rejoices at your coming, gives you his hands,
Kisses you, caresses you,
Sets you before the spirits, the imperishable stars...
The hidden ones worship you,
The great ones surround you,
The watchers wait on you,
Barley is threshed for you,
Emmer is reaped for you,
Your monthly feasts are made with it,
Your half-month feasts are made with it,
As ordered done for you by Geb, your father,
Rise up, O Teti, you shall not die!
所有这些都有不同的输出流。是否没有LZ77的纯参考实施或标准可检查?
为什么不是所有的“ LZ77”压缩器都给出相同的压缩率,相同的输出比特流?
答案 0 :(得分:1)
LZ77仅提供算法本身的一般数学概念。它的灵活性在于可以更改其参数,从而导致对编码器和解码器的要求不同,并且可以极大地影响结果数据流。决定这些细节的方法取决于实现,例如缓冲区的大小以及代码字的构造方式。这些参数的敏感性是为什么竞争性实现可能将自己称为LZ77但不兼容的原因。
例如,DEFLATE specification指定32768的窗口大小,并将位置和长度存储为15 + 8位代码字。一个更简单但效率较低的实现方式可以选择12位距离和4位长度,从而提供4096字节的窗口大小。另一个人可能会选择一个8192字节的窗口大小,使用13位来表示距离,如果每个令牌使用16位,则仅保留3位的长度。
这种自由导致了其他方式的创新,例如LZSS引入文字标志或使用哈希表的LZRW。另一个流行的创新是使用Huffman coding(如DEFLATE)或其他熵编码器跟踪基于LZ的压缩,以提高压缩率。