Post a Comment On: cbloom rants

Huffman to Arithmetic coder transformation. This is something well known by "practictioners of the art" but I've never seen it displayed explicitly, so here we go. We're talking about arbitrary-alphabet decoding here obviously, not binary, and static probability models mostly. Let's start with our Huffman decoder. (a bit of review here or here or here ). For simplicity and symmetry, we will use a Huffman decoder that can handle code lengths up to 16, and we will use a table-accelerated decoder. The decoder looks like this : // look at next 16 bits (but don't consume them) U32 peek = BitInput_Peek(16); // use peek to look in decode tables : int sym = huffTable_symbol[peek]; // use symbol to get actual code length : int bits = symbol_codeLength[sym]; // and remove that code length from the bit stream : BitInput_Consume(bits); this is very standard (more normally the huffTable would only accelerate the first 8-12 bits of decode, and you would then fall back to some other method for codes longer than that). Let's expand out what Peek and Consume do exactly. For symmetry to the arithcoder I'm going to keep my bit buffer right-aligned in a big-endian word. int bits_bitLen = // # of bits in word U32 bits_code = // current bits in word BitInput_Peek(16) : { ASSERT( bits_bitLen >= 16 ); U32 ret = bits_code >> (bits_bitLen - 16); } BitInput_Consume(bits) : { bits_bitLen -= bits; bits_code &= (1 bits_bitLen)-1; while ( bits_bitLen 16 ) { bits_code = 8; bits_code |= *byteStream++; bits_bitLen += 8; } } it should be obvious what these do; _Peek grabs the top 16 bits of code for you to snoop. Consume removes the top "bits" from code, and then streams in bytes to refill the bits while we are under count. (to repeat again, this is not how you should actually implement bit streaming, it's slower than necessary). Okay, now let's look at an Arithmetic decoder. (a bit of review here or here and here ). First lets start with the totally generic case. Arithmetic Decoding consists of getting the probability target, finding what symbol that corresponds to, then removing that symbol's probability range from the stream. This is : AC_range = size of current arithmetic interval AC_code = value in range specified Arithmetic_Peek(cumulativeProbabilityTotal) : { r = AC_range / cumulativeProbabilityTotal; target = AC_code / r; return target; } Arithmetic_Consume(cumulativeProbabilityLow, probability, cumulativeProbabilityTotal) { AC_range /= cumulativeProbabilityTotal; AC_code -= cumulativeProbabilityLow * AC_range AC_range *= probability; while ( AC_range minRange ) { AC_code = 8; AC_range = 8; AC_code |= *byteStream++; } } Okay it's not actually obvious that this is a correct arithmetic decoder (the details are quite subtle) but it is; and in fact this is just about the fastest arithmetic decoder in the world (the only thing you would do differently in real code is share the divide by cumulativeProbabilityTotal so it's only done once). Now, the problem of taking the Peek target and finding what symbol that specifies is actually the slowest part, there are various solutions, Fenwick trees, Deferred Summation, etc. For now we are talking about *static* coding, so we will use a table lookup. To decode with a table we need a table from [0,cumulativeProbabilityTotal] which can map a probability target into a symbol. So when we get a value from _Peek we look it up in a table to get the symbol, cumulativeProbabilityLow, and probability. To speed things up, we can use cumulativeProbabilityTotal = a power of two to turn the divide into a shift. We choose cumulativeProbabilityTotal = 2^16. (the longest code we can write with our arithmetic coder then has code length -log2(1/cumulativeProbabilityTotal) = 16 bits). So now our static table-based arithmetic decode is : Arithmetic_Peek() : { r = AC_range >> 16; target = AC_code / r; } int sym = arithTable_symbol[target]; int cumProbLow = cumProbTable[sym]; int cumProbHigh = cumProbTable[sym+1]; Arithmetic_Consume() { AC_range >>= 16; AC_code -= cumProbLow * AC_range AC_range *= (cumProbHigh - cumProbLow); while ( AC_range minRange ) { AC_code = 8; AC_range = 8; AC_code |= *byteStream++; } } Okay, not bad, and we still allow arbitrarily probabilities within the [0,cumulativeProbabilityTotal] , so this is more general than the Huffman decoder. But we still have a divide which is very slow. So if we want to get rid of that, we have to constrain a bit more : Make each symbol probability a power of 2, so (cumProbHigh - cumProbLow) is always a power of 2 (< cumulativeProbabilityTotal). We will then store the log2 of that probability range. Let's do that explicitly : Arithmetic_Peek() : { r = AC_range >> 16; target = AC_code / r; } int sym = arithTable_symbol[target]; int cumProbLow = cumProbTable[sym]; int cumProbLog2 = log2Probability[sym]; Arithmetic_Consume() { AC_range >> 16; AC_code -= cumProbLow * AC_range AC_range = cumProbLog2; while ( AC_range minRange ) { AC_code = 8; AC_range = 8; AC_code |= *byteStream++; } } Now the key thing is that since we only ever >> shift down AC_Range or << to shift it up, if it starts a power of 2, it stays a power of 2. So we will replace AC_Range with its log2 : Arithmetic_Peek() : { r = AC_log2Range - 16; target = AC_code >> r; } int sym = arithTable_symbol[target]; int cumProbLow = cumProbTable[sym]; int cumProbLog2 = log2Probability[sym]; Arithmetic_Consume() { AC_code -= cumProbLow (AC_log2Range - 16); AC_log2Range += (cumProbLog2 - 16); while ( AC_log2Range min_log2Range ) { AC_code = 8; AC_log2Range += 8; AC_code |= *byteStream++; } } we only need a tiny bit more now. First observe that an arithmetic symbol of log2Probability is written in (16 - log2Probability) bits, so lets call that "codeLen". And we'll rename AC_log2range to AC_bitlen : Arithmetic_Peek() : { peek = AC_code >> (AC_bitlen - 16); } int sym = arithTable_symbol[peek]; int codeLen = sym_codeLen[sym]; int cumProbLow = sym_cumProbTable[sym]; Arithmetic_Consume() { AC_code -= cumProbLow (AC_bitlen - 16); AC_bitlen -= codeLen; while ( AC_bitlen 16 ) { AC_code = 8; AC_bitlen += 8; AC_code |= *byteStream++; } } let's compare this to our Huffman decoder (just copying down from the top of the post and reorganizing a bit) : BitInput_Peek() : { peek = bits_code >> (bits_bitLen - 16); } // use peek to look in decode tables : int sym = huffTable_symbol[peek]; // use symbol to get actual code length : int codeLen = sym_codeLen[sym]; BitInput_Consume() : { bits_code &= (1 bits_bitLen)-1; bits_bitLen -= codeLen; while ( bits_bitLen 16 ) { bits_code = 8; bits_bitLen += 8; bits_code |= *byteStream++; } } you should be able to see the equivalence. There's only a small difference left. To remove the consumed bits, the arithmetic coder does : int cumProbLow = sym_cumProbTable[sym]; AC_code -= cumProbLow (AC_bitlen - 16); while the Huffman coder does : bits_code &= (1 bits_bitLen)-1; which is obviously simpler. Note that the Huffman remove can be written as : code = peek >> (16 - codeLen); bits_code -= code (bits_bitLen - codeLen); What's happening here - peek is 16 bits long, it's a window in the next 16 bits of "bits_code". First we make "code" which is the top "codeLen" of "peek". "code" is our actual Huffman code for this symbol. Then we know the top bits of bits_code are equal to code, so to turn them off, rather than masking we can subtract. The equivalent cumProbLow is code<<(16-codeLen). This is the equivalence of the Huffman code to taking the arithmetic probability range [0,65536] and dividing it in half at each tree branch. The arithmetic coder had to look up cumProbLow in a table because it is still actually a bit more general than the Huffman decoder. In particular our arithmetic decoder can still handle probabilities like [1,2,4,1] (with cumProbTot = 8). Because of that the cumProbLows don't hit the nice bit boundaries. If you require that your arithmetic probabilities are always sorted [1,1,2,4], then since they are power of two and sum to a power of two, each partial power of two must be present, so the cumProbLows must all hit bit boundaries like the huffman codes, and the equivalence is complete. So, you should now see clearly that a Huffman and Arithmetic coder are not completely different things. They are a continuum on the same scale. If you start with a fully general Arithmetic coder it is flexible, but slow. You then constrain it in various ways step by step, it gets faster and less general, and eventually you get to a Huffman coder. But those are not the only coders in the continuum, you also have things like "Arithmetic coder with fixed power of two probability total but non-power-of-2 symbol probabilities" which is somewhere in between in space and speed. BTW not directly on topic, but I found this in my email and figure it should be in public : Well, Adaptive Huffman is awful, nobody does it. So you have a few options : Static Huffman - very fast code lengths must be transmitted can use table-based decode Arithmetic with static probabilities scaled with total = a power of 2 very fast can use table-based decode must transmit probabilities decode must do a divide Arithmetic semi-adaptive "Deferred Summation" doesn't transmit probabilites Arithmetic fully adaptive must use Fenwick tree or something like that much slower, coder time no longer dominates (symbol search in tree time dominates) Arithmetic by binary decomposition can use fast binary arithmetic coder speed depends on how many binary events it takes to code symbols on average It just depends on your situation so much. With somehting like image or audio coding you want to do special-cased things like turn amplitudes into log2+remainder, use a binary coder for the zero, perhaps do zero-run coding, etc. stuff to avoid doing the fully general case of a multisymbol large alphabet coder.