If I had to guess, it’s a matter of setting up the Huffman tables such that every code ends up with a length of four bits, and then prepending that precomputed Huffman table onto the “compressed” stream. Then you can abuse the zlib library as a decompressor mapping the 4-bit “Huffman” codes to regular bytes.
Of course, this won’t be anywhere near as efficient as just implementing the decoder in C, as Huffman decoding needs to be much more general than just unpacking fixed-width chunks. But it will definitely be an improvement over naive loops.
I wonder whether .hex() could be pressed into service as a very scuffed 4-bit unpacker? Maybe something like .hex().encode().translate() to get an arbitrary palette mapping?
> Of course, this won’t be anywhere near as efficient as just implementing the decoder in C
> It is quite easy to add new built-in modules to Python, if you know how to program in C. Such extension modules can do two things that can’t be done directly in Python: they can implement new built-in object types, and they can call C library functions and system calls.
Then why are you talking about this instead of extension modules?
Of course, this won’t be anywhere near as efficient as just implementing the decoder in C, as Huffman decoding needs to be much more general than just unpacking fixed-width chunks. But it will definitely be an improvement over naive loops.
I wonder whether .hex() could be pressed into service as a very scuffed 4-bit unpacker? Maybe something like .hex().encode().translate() to get an arbitrary palette mapping?