Efficient way of storing Huffman tree
Asked Answered
S

6

37

I am writing a Huffman encoding/decoding tool and am looking for an efficient way to store the Huffman tree that is created to store inside of the output file.

Currently there are two different versions I am implementing.

  1. This one reads the entire file into memory character by character and builds a frequency table for the whole document. This would only require outputting the tree once, and thus efficiency is not that big of a concern, other than if the input file is small.
  2. The other method I am using is to read a chunk of data, about 64 kilobyte in size and run the frequency analysis over that, create a tree and encode it. However, in this case before every chunk I will need to output my frequency tree so that the decoder is able to re-build its tree and properly decode the encoded file. This is where the efficiency does come into place since I want to save as much space as possible.

In my searches so far I have not found a good way of storing the tree in as little space as possible, I am hoping the StackOverflow community can help me find a good solution!

Sainthood answered 17/4, 2009 at 9:20 Comment(0)
O
91

Since you already have to implement code to handle a bit-wise layer on top of your byte-organized stream/file, here's my proposal.

Do not store the actual frequencies, they're not needed for decoding. You do, however, need the actual tree.

So for each node, starting at root:

  1. If leaf-node: Output 1-bit + N-bit character/byte
  2. If not leaf-node, output 0-bit. Then encode both child nodes (left first then right) the same way

To read, do this:

  1. Read bit. If 1, then read N-bit character/byte, return new node around it with no children
  2. If bit was 0, decode left and right child-nodes the same way, and return new node around them with those children, but no value

A leaf-node is basically any node that doesn't have children.

With this approach, you can calculate the exact size of your output before writing it, to figure out if the gains are enough to justify the effort. This assumes you have a dictionary of key/value pairs that contains the frequency of each character, where frequency is the actual number of occurrences.

Pseudo-code for calculation:

Tree-size = 10 * NUMBER_OF_CHARACTERS - 1
Encoded-size = Sum(for each char,freq in table: freq * len(PATH(char)))

The tree-size calculation takes the leaf and non-leaf nodes into account, and there's one less inline node than there are characters.

SIZE_OF_ONE_CHARACTER would be number of bits, and those two would give you the number of bits total that my approach for the tree + the encoded data will occupy.

PATH(c) is a function/table that would yield the bit-path from root down to that character in the tree.

Here's a C#-looking pseudo-code to do it, which assumes one character is just a simple byte.

void EncodeNode(Node node, BitWriter writer)
{
    if (node.IsLeafNode)
    {
        writer.WriteBit(1);
        writer.WriteByte(node.Value);
    }
    else
    {
        writer.WriteBit(0);
        EncodeNode(node.LeftChild, writer);
        EncodeNode(node.Right, writer);
    }
}

To read it back in:

Node ReadNode(BitReader reader)
{
    if (reader.ReadBit() == 1)
    {
        return new Node(reader.ReadByte(), null, null);
    }
    else
    {
        Node leftChild = ReadNode(reader);
        Node rightChild = ReadNode(reader);
        return new Node(0, leftChild, rightChild);
    }
}

An example (simplified, use properties, etc.) Node implementation:

public class Node
{
    public Byte Value;
    public Node LeftChild;
    public Node RightChild;

    public Node(Byte value, Node leftChild, Node rightChild)
    {
        Value = value;
        LeftChild = leftChild;
        RightChild = rightChild;
    }

    public Boolean IsLeafNode
    {
        get
        {
            return LeftChild == null;
        }
    }
}

Here's a sample output from a specific example.

Input: AAAAAABCCCCCCDDEEEEE

Frequencies:

  • A: 6
  • B: 1
  • C: 6
  • D: 2
  • E: 5

Each character is just 8 bits, so the size of the tree will be 10 * 5 - 1 = 49 bits.

The tree could look like this:

      20
  ----------
  |        8
  |     -------
 12     |     3
-----   |   -----
A   C   E   B   D
6   6   5   1   2

So the paths to each character is as follows (0 is left, 1 is right):

  • A: 00
  • B: 110
  • C: 01
  • D: 111
  • E: 10

So to calculate the output size:

  • A: 6 occurrences * 2 bits = 12 bits
  • B: 1 occurrence * 3 bits = 3 bits
  • C: 6 occurrences * 2 bits = 12 bits
  • D: 2 occurrences * 3 bits = 6 bits
  • E: 5 occurrences * 2 bits = 10 bits

Sum of encoded bytes is 12+3+12+6+10 = 43 bits

Add that to the 49 bits from the tree, and the output will be 92 bits, or 12 bytes. Compare that to the 20 * 8 bytes necessary to store the original 20 characters unencoded, you'll save 8 bytes.

The final output, including the tree to begin with, is as follows. Each character in the stream (A-E) is encoded as 8 bits, whereas 0 and 1 is just a single bit. The space in the stream is just to separate the tree from the encoded data and does not take up any space in the final output.

001A1C01E01B1D 0000000000001100101010101011111111010101010

For the concrete example you have in the comments, AABCDEF, you will get this:

Input: AABCDEF

Frequencies:

  • A: 2
  • B: 1
  • C: 1
  • D: 1
  • E: 1
  • F: 1

Tree:

        7
  -------------
  |           4
  |       ---------
  3       2       2
-----   -----   -----
A   B   C   D   E   F
2   1   1   1   1   1

Paths:

  • A: 00
  • B: 01
  • C: 100
  • D: 101
  • E: 110
  • F: 111

Tree: 001A1B001C1D01E1F = 59 bits
Data: 000001100101110111 = 18 bits
Sum: 59 + 18 = 77 bits = 10 bytes

Since the original was 7 characters of 8 bits = 56, you will have too much overhead of such small pieces of data.

Ober answered 17/4, 2009 at 9:38 Comment(9)
Note that the first calculation I added was incorrect for the size of the tree, have corrected it now and added a specific example to boot.Ober
You don't need the actual tree. You need bit length of each letter in the alphabet. That's how GZIP store dynamic huffman block: rfc-deflateCourthouse
@LasseV.Karlsen this is exactly what I am doing but using 001A1C01E01B1D how do you rebuild the tree? Do you have any suggestionsChervonets
Despite the fact that this answer has the most votes, and this is the one which is accepted, this solution usually uses more space then the deflate way. So anyone, who is really considered about space, should go with something like deflate does. Or even better, one should consider to have multiple ways to encode a tree, and choose the one which takes the minimum space.Vu
Why is 10 used in the calculation for the tree size? Why is it not 8, because that represents a character?Inn
This is a beautiful explanation. I'm just curious, though, about mixing binary and character data in the "Tree". What would happen if the characters '0' and '1' were in the original string? How would you separate them from Tree's binary content?Acoustics
There is no problem, when reading the tree there is never any doubt what you're expecting next, either you're expecting 1 bit which corresponds either an internal node or a leaf node, or you're expecting 8 bits for the value of a leaf node. You always start by decoding the root node, which is an internal node, so you're always starting by reading 1 bit and then follow from that. You never read a number of bits and then decide what you just read, you know ahead of time.Ober
@Inn Have you figured it out why is 10 used? I still have no idea.Holism
Yes, 1 bit for internal node, one for leaf + 8 for the word = 10 bits. There's one less internal nodes than leaf nodes, hence the minus 1 at the end. So for 2 leaf nodes you have 1 bit for each leaf node, and 8 bits for each word. You could make it separate like this: "9 * leaf nodes + (leaf nodes - 1)"Ober
M
11

If you have enough control over the tree generation, you could make it do a canonical tree (the same way DEFLATE does, for example), which basically means you create rules to resolve any ambiguous situations when building the tree. Then, like DEFLATE, all you actually have to store are the lengths of the codes for each character.

That is, if you had the tree/codes Lasse mentioned above:

  • A: 00
  • B: 110
  • C: 01
  • D: 111
  • E: 10

Then you could store those as: 2, 3, 2, 3, 2

And that's actually enough information to regenerate the huffman table, assuming you're always using the same character set -- say, ASCII. (Which means you couldn't skip letters -- you'd have to list a code length for each one, even if it's zero.)

If you also put a limitation on the bit lengths (say, 7 bits), you could store each of these numbers using short binary strings. So 2,3,2,3,2 becomes 010 011 010 011 010 -- Which fits in 2 bytes.

If you want to get really crazy, you could do what DEFLATE does, and make another huffman table of the lengths of these codes, and store its code lengths beforehand. Especially since they add extra codes for "insert zero N times in a row" to shorten things further.

The RFC for DEFLATE isn't too bad, if you're already familiar with huffman coding: http://www.ietf.org/rfc/rfc1951.txt

Mcclain answered 2/6, 2009 at 22:4 Comment(4)
How would you regenerate the huffman table from the sequence 2, 3, 2, 3, 2?Catamaran
Checkout en.wikipedia.org/wiki/Canonical_Huffman_code or the deflate spec. This is how canonical huffman tress are generally stored.Mcclain
@Mcclain is it works only if I know all letters from alphabet? What if I have a lot of different punctuation or unicode symbols like йцшщзъ?Hammerless
This is the correct answer. The accepted answer says that you need to transmit the tree, which you do not.Greasepaint
V
7

branches are 0 leaves are 1. Traverse the tree depth first to get its "shape"

e.g. the shape for this tree

0 - 0 - 1 (A)
|    \- 1 (E)
  \
    0 - 1 (C)
     \- 0 - 1 (B)
         \- 1 (D)

would be 001101011

Follow that with the bits for the characters in the same depth first order AECBD (when reading you'll know how many characters to expect from the shape of the tree). Then output the codes for the message. You then have a long series of bits that you can divide up into characters for output.

If you are chunking it, you could test that storing the tree for the next chuck is as efficient as just reusing the tree for the previous chunk and have the tree shape being "1" as an indicator to just reuse the tree from the previous chunk.

Verity answered 17/4, 2009 at 9:32 Comment(0)
W
2

The tree is generally created from a frequency table of the bytes. So store that table, or just the bytes themselves sorted by frequency, and re-create the tree on the fly. This of course assumes that you're building the tree to represent single bytes, not larger blocks.

UPDATE: As pointed out by j_random_hacker in a comment, you actually can't do this: you need the frequency values themselves. They are combined and "bubble" upwards as you build the tree. This page describes the way a tree is built from the frequency table. As a bonus, it also saves this answer from being deleted by mentioning a way to save out the tree:

The easiest way to output the huffman tree itself is to, starting at the root, dump first the left hand side then the right hand side. For each node you output a 0, for each leaf you output a 1 followed by N bits representing the value.

Weekday answered 17/4, 2009 at 9:29 Comment(6)
This would work, with only one downside and that is that it has a very bad worstcase scenario, if the string is AABCDEF the tree I am storing now is ABCDEF, basically I am back to square one, with the normal frequency found in the English language the size of the table I am storing would still cause the compression to be almost non-existent and in some cases even causing the data to be bigger than it was to begin with!Sainthood
Sure. One solution might be to just not compress input data shorter than 512 bytes or so. If this us used for disk-based data, that makes sense anyway, since most filesystems have overhead meaning that small files take up more actual disk space than they contain valid data for.Weekday
I'm afraid you're going to have to realize that not all data is compressible. You're going to incur some overhead any way you do it, and if the data is small, or have a low entropy, the overhead might outweigh the gains of the compression algorithm. You should have a fallback encoding that doesn't compress for those scenarios.Ober
if the table is the one for the English language you don't need to store it for transmission. You just have to agree which one your implementation is going to use in that case.Verity
I think that you can't recreate a Huffman tree based on just the bytes sorted by frequency -- you need the actual frequencies, since different frequency vectors can lead to different Huffman trees even when the sorted order of the frequencies is the same. But I'm open to being proved wrong.Magnetostriction
That is correct, that's not enough, you need something more to get back the exact tree. See my post, which outputs extra bits to lay out the tree.Ober
D
1

A better approach

Tree:

           7
     -------------
     |           4
     |       ---------
     3       2       2
   -----   -----   -----
   A   B   C   D   E   F
   2   1   1   1   1   1 : frequencies
   2   2   3   3   3   3 : tree depth (encoding bits)

Now just derive this table:

   depth number of codes
   ----- ---------------
     2   2 [A B]
     3   4 [C D E F]

You don't need to use the same binary tree, just keep the computed tree depth i.e. the number of encoding bits. So just keep the vector of uncompressed values [A B C D E F] ordered by tree depth, use relative indexes instead to this separate vector. Now recreate the aligned bit patterns for each depth:

   depth number of codes
   ----- ---------------
     2   2 [00x 01x]
     3   4 [100 101 110 111]

What you immediately see is that only the first bit pattern in each row is significant. You get the following lookup table:

    first pattern depth first index
    ------------- ----- -----------
    000           2     0
    100           3     2

This LUT has a very small size (even if your Huffman codes can be 32-bit long, it will only contain 32 rows), and in fact the first pattern is always null, you can ignore it completely when performing a binary search of patterns in it (here only 1 pattern will need to be compared to know if the bit depth is 2 or 3 and get the first index at which the associated data is stored in the vector). In our example you'll need to perform a fast binary search of input patterns in a search space of 31 values at most, i.e. a maximum of 5 integer compares. These 31 compare routines can be optimized in 31 codes to avoid all loops and having to manage states when browing the integer binary lookup tree. All this table fits in small fixed length (the LUT just needs 31 rows atmost for Huffman codes not longer than 32 bits, and the 2 other columns above will fill at most 32 rows).

In other words the LUT above requires 31 ints of 32-bit size each, 32 bytes to store the bit depth values: but you can avoid it this by implying the depth column (and the first row for depth 1):

    first pattern (depth) first index
    ------------- ------- -----------
    (000)          (1)    (0)
     000           (2)     0
     100           (3)     2
     000           (4)     6
     000           (5)     6
     ...           ...     ...
     000           (32)    6

So your LUT contains [000, 100, 000(30times)]. To search in it you must find the position where the input bits pattern are between two patterns: it must be lower than the pattern at the next position in this LUT but still higher than or equal to the pattern in the current position (if both positions contain the same pattern, the current row will not match, the input pattern fits below). You'll then divide and conquer, and will use 5 tests at most (the binary search requires a single code with 5 embedded if/then/else nested levels, it has 32 branches, the branch reached indicates directly the bit depth that does not need to be stored; you perform then a single directly indexed lookup to the second table for returning the first index; you derive additively the final index in the vector of decoded values).

Once you get a position in the lookup table (search in the 1st column), you immediately have the number of bits to take from the input and then the start index to the vector. The bit depth you get can be used to derive directly the adjusted index position, by basic bitmasking after substracting the first index.

In summary: never store linked binary trees, and you don't need any loop to perform thelookup which just requires 5 nested ifs comparing patterns at fixed positions in a table of 31 patterns, and a table of 31 ints containing the start offset within the vector of decoded values (in the first branch of the nested if/then/else tests, the start offset to the vector is implied, it is always zero; it is also the most frequent branch that will be taken as it matches the shortest code which is for the most frequent decoded values).

Dhobi answered 15/8, 2013 at 3:36 Comment(0)
P
1

There are two main ways to store huffman code LUTs as the other answers state. You can either store the geometry of the tree, 0 for a node, 1 for a leaf, then put in all the leaf values, or you can use canonical huffman encoding, storing the lengths of the huffman codes.

The thing is, one method is better than the other depending on the circumstances. Let's say, the number of unique symbols in the data you wish to compress (aabbbcdddd, there are 4 unique symbols, a, b, c, d) is n.

The number of bits to store the geometry of the tree along side the symbols in the tree is 10n - 1.

Assuming you store the code lengths in order of the symbols the code lengths are for, and that the code lengths are 8 bits (code lengths for a 256 symbol alphabet will not exceed 8 bits), the size of the code length table will be a flat 2048 bits.

When you have a high number of unique symbols, say 256, it will take 2559 bits to store the geometry of the tree. In this case, the code length table is much more efficient. 511 bits more efficient, to be exact.

But if you only have 5 unique symbols, the tree geometry only takes 49 bits, and in this case, when compared to storing the code length table, storing the tree geometry is almost 2000 bits better.

The tree geometry is most efficient for n < 205, while a code length table is more efficient for n >= 205. So, why not get the best of both worlds, and use both? Have 1 bit at the start of your compressed data represent whether the next however many bits are going to be in the format of a code length table, or the geometry of the huffman tree.

In fact, why not add two bits, and when both of them are 0, there is no table, the data is uncompressed. Because sometimes, you can't get compression! And it would be best to have a single byte at the beginning of your file that is 0x00 telling your decoder not to worry about doing anything. Saves space by not including the table or geometry of a tree, and saves time, not having to unnecessarily compress and decompress data.

Pneumonectomy answered 24/8, 2021 at 15:24 Comment(3)
The code lengths can themselves be compressed (see deflate for an example), so your cutoff is only valid for the naive approach of transmitting the code lengths.Greasepaint
Forgot about that part. Also haven't exactly implemented anything like that yet! So I'll keep my mouth shut until I do. >:PPneumonectomy
@spitconsumer I saw your question about generating Huffman codes faster than building tree, apart from the usual "create tree in-place in an array" (lots of versions of this) there are also Polar codes and Engel codes which make no tree at all not even a sneaky tree in an arrayPoliticize

© 2022 - 2024 — McMap. All rights reserved.