Lee wrote:
> No, but I've thought about it a lot. Since each uncompressed byte of level
> data only uses 5 bits, that would mean up to 32 data nodes in the huffman
> tree to represent all the bit patterns, plus 1 extra node to represent the
> end of a level.
Why would you need an end of level node? You know the number of pattern
for each level, don't you.
And are you sure 32 pattern are enough? (probably I miss something here)
> Since there are n-1 branches, my huffman tree could get as
> large as (and would likely take) 65 bytes. Then I have the bit pattern
> lookup table which is another 16 bytes long, bringing the overhead to 81
> bytes.
That's the part which would be drastically reduced with my approach. There
you only need one byte/bit. So with a maximum length of e.g. 7 bits, you
would only need 7 bytes for that table.
> My decompression routine, not including the mirroring function,
> takes another 156 bytes.
And my simple code would only need ~50 bytes.
> Basically, the compressed level data would require 237 bytes of decompression
> overhead, which just _feels_ like too much.
Probably, at least definitely to much "extra" overhead, even if you assume
that your compression would be better. (which it is not! ;-)
> I guess my point is... I'm having second thoughts about straight huffman
> compression. I may need your help soon, Thomas. :)
No problem. If you provide the encoding, I can do the decode code quite easily.
Have fun!
Thomas
_______________________________________________________
Thomas Jentzsch | *** Every bit is sacred ! ***
tjentzsch at web dot de |
_________________________________________________________
Mit WEB.DE FreePhone® mit höchster Qualität ab 0 Ct./Min.
weltweit telefonieren! http://freephone.web.de/?mc=021201
