如何在实践中构建霍夫曼编码表?

时间:2017-03-16 01:58:34

标签: c compression huffman-code image-compression

我的问题是具体的。我可以看出霍夫曼编码理论很容易理解。但是,它似乎创建了通常不与字节边界对齐的代码。我遇到的教程中没有涉及缓解此特定问题的实用方法。

有两个问题:

(1)文件编码后,生成的霍夫曼代码文件的文件末尾可能无法在字节边界对齐。我们怎么知道我们已经在压缩文件中达到了霍夫曼编码数据的结尾?

(2)如果文件中包含霍夫曼表以帮助解压缩,那么在实践中如何创建这样的表,因为我们再次遇到与字节边界不对齐的问题?符号本身可以是8位或16位。但是,霍夫曼码可以是任意数量的比特。现在,如果我们在每个代码中包含一个霍夫曼代码,我们还必须包括它的位数,以便解码器可以使用霍夫曼表创建二叉树或其他一些数据结构来帮助解压缩。

Huffman和Arithmatic编码似乎在很多压缩系统中使用,因此这个问题不断出现。

我试图了解如何在JPEG中完成这项工作,并将使用FPGA中的Nios II软核处理器在C中构建编码器,以便将JPEG文件从相机中保存到SD卡中。

1 个答案:

答案 0 :(得分:2)

  1. 附加符号定义为结束代码。遇到该代码时,您已到达流的末尾。除非后面有另一种比特流,否则通常做的是丢弃最后一个字节中的任何剩余比特以转到下一个字节边界。

  2. 根据压缩代码描述的重要性,有许多方法可以改变复杂程度。您可以通过一种方式阅读RFC 1951中的deflate描述,以及RFC 7932中的brotli描述。在这两种情况下,都不会发送代码本身。而是发送每个符号的代码长度,并且代码本身从长度和符号顺序规范地构造。在deflate中,为每个符号发送长度,对于未编码的符号发送长度为零。该系列长度以游程编码,然后本身就是霍夫曼编码。首先发送用于解码代码长度的霍夫曼代码,其使用针对每个长度(3)的固定数量的比特来发送,并且再次被规范地构造。 (查看Canonical Huffman代码。)当不使用预定义的霍夫曼代码时,JPEG还有另一种编码代码长度的方法。