Weng said:
Your method is interesting, but is far from what I am looking for.
It is too slow.
I found that almost all Huffman encoding applications are static as in
FAX, electronic books, ZIP files, JPEG, MPEG and so on.
You are wrong there. ZIP files and most EBooks use some variant of LZ
encoding using a suffix tree (which might be feasible in hardware),
followed by Huffman coding - static *or* dynamic - on the resultant
symbols. Zip in particular uses the deflate algorithm, which can emit
either static or dynamically-generated Huffman data on each block.
But AFAIK, the Huffman table is *not* updated with each symbol. There
was a kid on sci.crypt a while back banging on about a per-symbol
dynamic Huffman technique he'd invented, perhaps look there.
JPEG and MPEG use a DCT (and optionally in MPEG, motion compensation)
before applying further compression. The DCT is *not* huffman by
another name, its a discrete cosine transform.
Also, look for information on Suffix Trees (used in Lempel-Zif
encoding), and you might find it can be done in a limited way in
hardware. The tree is built incrementally, and looks kinda like
Logan's trie, except that the first symbol of a sequence is at
the leaf, with the last symbol at the root. Kinda...
In general, though Huffman coding was thought to be "optimal" two
decades ago, newer techniques have been shown to be better. For
example, arithmetic coding (needs two passes over the data though),
and the Burrows-Wheeler transform (used in bzip).
There should be enough terms for you to go googling and perhaps find
a more suitable algorithm than Huffman. Don't forget - compression is
simply the process of removing whatever is predictable from a data
stream. The better you understand your data, the better an algorithm
can predict it, and the better your compressor can be.
Good luck!
Clifford Heath.