Lee Fastenau wrote:
> Yes. I've only ever (in the past few months) created algorithms
> that build fully optimized huffman trees.
:thumbsup:
I love Huffman trees, there are so "elegant".
> I think it would be easier to do it that way if I were
> compressing the levels by hand, but I'm planning to build a utility
> that will aggregate all the level data I want to include and
> generate the optimum huffman tree for that set.
The 3,4,5 bits distribution was just an example, you can use any
bit lengths you want.
Actually my code requires just an additional step, reordering the bits
created by your optimal generated Huffman tree. Just try it, AFAIK you
can convert any static(!) Huffman tree into that much simpler
structure.
And the decompressing code becomes extremely compact then (~50 bytes).
> I understand what you're saying. That could give a potential
> byte savings on the lookup tree itself, but it still sounds like
> you're hand-selecting the patterns to assign to the compressed
> codes...
Nope. :-)
> whereas using the huffman algorithm to build the tree will
> always yield optimal results. If a few patterns actually take more
> bits to encode than are in the pattern itself, that just means they
> are extremely rare and that compression of other more frequent
> patterns will still yield a net compression benefit. Also, I
> believe the more data that is compressed, the more advantage I'd
> gain from a full huffman table versus direct layout lookups.
You would be absolutely right based on your assumption, but see above.
:-)
Have fun!
Thomas
_______________________________________________________
Thomas Jentzsch | *** Every bit is sacred ! ***
tjentzsch at web dot de |
