DHT包含16个字节，其中只包含使用从1位一直到16位的每个长度的霍夫曼代码编码的值的计数。在此之后，它包含已编码的实际值，所有这些值都是8位。
问：为什么没有存储霍夫曼代码，解码器如何导出代码？
问：如果有4个具有3位长的霍夫曼代码的值，我们将它们写为4个字节。它们处于什么顺序或者必须按升序或降序排列是否重要？我知道值必须按顺序排列，使得带有1位霍夫曼代码的值后跟具有2位霍夫曼代码e.t.c的值。
问：我用jpegsnoop来查看不同文件的huffman表，其中一些是用MS绘制的，有些是下载的。我发现他们都有SAME表。以下是我从JPEG snoop获得的DHT条目：
Destination ID = 1
Class = 1 (AC Table)
Codes of length 01 bits (000 total):
Codes of length 02 bits (002 total): 00 01
Codes of length 03 bits (001 total): 02
Codes of length 04 bits (002 total): 03 11
Codes of length 05 bits (004 total): 04 05 21 31
Codes of length 06 bits (004 total): 06 12 41 51
Codes of length 07 bits (003 total): 07 61 71
Codes of length 08 bits (004 total): 13 22 32 81
Codes of length 09 bits (007 total): 08 14 42 91 A1 B1 C1
Codes of length 10 bits (005 total): 09 23 33 52 F0
Codes of length 11 bits (004 total): 15 62 72 D1
Codes of length 12 bits (004 total): 0A 16 24 34
Codes of length 13 bits (000 total):
Codes of length 14 bits (001 total): E1
Codes of length 15 bits (002 total): 25 F1
Codes of length 16 bits (119 total): 17 18 19 1A 26 27 28 29 2A 35 36 37 38 39 3A 43
44 45 46 47 48 49 4A 53 54 55 56 57 58 59 5A 63
64 65 66 67 68 69 6A 73 74 75 76 77 78 79 7A 82
83 84 85 86 87 88 89 8A 92 93 94 95 96 97 98 99
9A A2 A3 A4 A5 A6 A7 A8 A9 AA B2 B3 B4 B5 B6 B7
B8 B9 BA C2 C3 C4 C5 C6 C7 C8 C9 CA D2 D3 D4 D5
D6 D7 D8 D9 DA E2 E3 E4 E5 E6 E7 E8 E9 EA F2 F3
F4 F5 F6 F7 F8 F9 FA
Total number of codes: 162
和
Destination ID = 1
Class = 0 (DC / Lossless Table)
Codes of length 01 bits (000 total):
Codes of length 02 bits (003 total): 00 01 02
Codes of length 03 bits (001 total): 03
Codes of length 04 bits (001 total): 04
Codes of length 05 bits (001 total): 05
Codes of length 06 bits (001 total): 06
Codes of length 07 bits (001 total): 07
Codes of length 08 bits (001 total): 08
Codes of length 09 bits (001 total): 09
Codes of length 10 bits (001 total): 0A
Codes of length 11 bits (001 total): 0B
Codes of length 12 bits (000 total):
Codes of length 13 bits (000 total):
Codes of length 14 bits (000 total):
Codes of length 15 bits (000 total):
Codes of length 16 bits (000 total):
Total number of codes: 012
AC表压缩包含零游程长度和AC系数幅度的RRRRSSSS，而DC表压缩SSSS。因此，我认为AC表必须包含总共255个条目（exlcuded 0），而DC表必须包含15个条目（排除0）。但是，这两个表都不包含这么多的代码总数。为什么？
答案 0 :(得分：1)
问：为什么没有存储霍夫曼代码，解码器如何导出代码？
Huffman表被定义为它们而不是实际代码的原因是它以这种方式编码更小更简单。 PNG使用类似但不同的方法。
请记住，要将Huffman代码存储在JPEG流中，您需要包括长度和代码本身。结果将比编码长度计数大得多。
问：如果有4个具有3位长的霍夫曼代码的值，我们将它们写为4个字节。它们处于什么顺序或者必须按升序或降序排列是否重要？
如果霍夫曼代码有3位，则将其写为JPEG流的三位。代码按升序生成。
问：我用jpegsnoop来查看不同文件的huffman表，其中一些是用MS绘制的，有些是下载的。我发现他们都有SAME表。
编码器很懒惰并且使用固定的霍夫曼表。 JPEG标准中有一个他们经常使用的样本霍夫曼表。为了生成最佳霍夫曼码，编码器必须对数据进行两次传递。使用预设表，编码器只需要进行一次通过。
答案 1 :(得分：1)
由于DC霍夫曼符号只需要从0到11的SSSS值，因此他们报告的霍夫曼树只需要12个代码。
AC霍夫曼符号的前缀零运行计数从0到15. 11位大小可以达到16 * 11 = 176个符号。但是，它们不包含符号0x10,0x20，... 0xE0，因为它们是冗余的。它们编码运行1,2，... 14个零，后跟0值。如果编码器具有7个零值后跟3位值，则可将其编码为0x73。没有必要用两个符号0x60; 0x03编码它。
忽略那14个无用的符号，我们最终报告了162个代码。
顺便说一下，需要0xF0（ZRL）值，因为没有一个符号可以表示16个零的运行，后跟一个值，因此无法合并。
我不知道为什么JPEG规范将DC和AC值限制为一定的位数。我推测额外的精度没有效果，或者通常被量化抛弃。或者它可能与反向离散余弦变换的数学有关。请记住，这些霍夫曼编码值是IDCT的（量化）系数，并且仅与连续色调RGB输出间接相关。
答案 2 :(得分：0)
霍夫曼编码几乎完全由所有256个符号的相对频率决定（决胜局规则除外）。这意味着您可以选择多种格式来编码这些相对频率;最简单的就是简单地存储所有这些频率。接收器然后可以从该顺序重建编码。
背景：霍夫曼编码的两个最不频繁的字符共享相同（长）的前缀，并且仅在最后一位有所不同。然后为该组合分配联合频率（两种组合的总和），其递归地用于确定前缀。最后，你最终得到两组，一组拿着X个字符，另一组拿着256-X字符。第一组具有前缀0，第二组具有前缀1。
是的，这是任意的，你可以交换那些0和1，并且有一个类似的表和相同的压缩率 - 0和1一样长。这就是你有详细规则的原因（例如，最常见的设置为0，决胜局是设置中的第一个字节）
返回编码。您希望有效地存储这些相对频率，因为我们在这里使用压缩。现在，正如我所指出的那样，当我们有代码后缀-0和后缀-1时，它们都具有相同的长度（即后缀长度加1）。所以我们从事实中知道有119个唯一的16位代码，有60个唯一的前缀，长度为15.后向计算，我们也知道有两个独特的符号，长度为15，总共62，所以必须有31个前缀长度14.我们可以再次回溯到长度为1的前缀。
同样，有必要指出我们在这里不知道这些前缀的准确值以及匹配的符号。正如所指出的，这取决于决胜局规则，但这些规则对于JPEG是固定的。
JPEG确实有一些特殊情况：非常罕见的符号的霍夫曼代码应该超过16位。这很不方便，因此在构建表时，如果其中任何一个已经具有较长的后缀，则不要选择具有最小组合频率的两个集合 - 将这两个子集组合在一起只会使后缀更长。您可以在示例中看到所有16位代码：大多数应该在纯霍夫曼编码中使用更长的代码。
我认为最糟糕的情况是最常见的角色是50％，接下来的25％等等。你会得到代码0,10,110,1110等等。这是一元计数，对于那种情况确实是最佳的，但最长的代码现在是256位。但是，您需要一个具有2 ^ 256字节的文档，其频率为2 ^ -256。