It works the *exact* same way. You process the input one byte at a time, build a histogram, construct the Huffman Tree and encode the input.

Why should it work different? Text files are just regular files where the bytes only use a specific subset of the possible values they could have.

If you do have some knowledge about the data you are encoding, you can be a little bit smarter about it: e.g. for the text section of an executable, you might work on individual instructions instead of bytes, maybe use common, prepared Huffman Trees, so you don't have to encode the tree itself.

On a side note: IIRC the Intel Management Engine does that using a proprietary Huffman Tree, backed into the hardware itself, as an obfuscation technique[1].

To circle back to your question: PNG simply feeds the pixel data into the zlib deflate() function as-is.

[1] https://en.wikipedia.org/wiki/Intel_Management_Engine#Design

You ask why it should work differently but then give a good reason why it should work differently: sometimes splitting by bytes is not the best unit.

And it actually does often work differently for PNG! PNG has a handful of preprocessing options for the pixels. So in filter mode 2, for example, deflate is encoding the difference between each pixel and the pixel above it. More or less.

But you still apply Huffman coding to the bytes after filtering.

I think this is true even when using 16 bits per sample, but i'm not sure.

From what i remember, in gzip, Huffman coding is applied to the offsets of repeated blocks, which are not single bytes.

JPEG uses Huffman as the compression stage. Here's[1] a brief but nice overview, here's[2] a more in-depth one.

Some encoders just use a precomputed Huffman table, but you can make an optimized one as discussed here[3].

Huffman is not the most optimal compression that can be used, for example Dropbox's Lepton[4] saves an additional 20% by replacing the Huffman stage with something better.

However, since it's a lossless stage this can be done transparently, which is nice.

[1]: http://www.robertstocker.co.uk/jpeg/jpeg_new_11.htm

[2]: https://www.impulseadventure.com/photo/jpeg-huffman-coding.h...

[3]: https://www.impulseadventure.com/photo/optimized-jpeg.html

[4]: https://dropbox.tech/infrastructure/lepton-image-compression...

The main key is that you can look at any file as a string of bits! And apply Huffman coding at whatever granularity you like. For text files, you're essentially applying it at the byte level (since each character is a byte (in ASCII, anyways)). For images, you might have one byte per colour channel, RGB. Then you can apply Huffman coding at the byte level, or even at the 3 byte level to operate on entire colours as opposed to channels.

Huffman coding generally works on symbols, where a symbol can be represented by any (possibly variable-length!) string of bits. I recall reading about a compression scheme (lzw?) where the symbol table had an entry for each raw byte value, plus the encoding instructions (e.g. lookback x bytes for y bytes).

That's pretty much all of them except LZW (which is an LZ78-alike, rather than LZ77). gzip has a number of Huffman tables for literals, distance, and for building Huffman tables at runtime... Yes, the instructions for building the Huffman tables used for decompression are themselves compressed using... more Huffman tables (HCLEN)!

Anything to save a few bits...

Oh yeah, might have been remembering gzip. All I remember is that it was one of the old/common ones. Don't know why my mind jumped to lzw instead of the obvious gzip haha.

It's generally used on bytes, but as others have said, it can be any symbol. Even on complete words!

https://www.nayuki.io/page/huffman-coding-english-words

It's the opposite: It's almost never used on bytes, because that just doesn't give you a lot of compression.

It is generally used as the final stage of some other compression algorithm, and operates on symbols generated by that algorithm. Often, this is some variation on LZ77, and the symbols are something like "bytes 0-255" in addition to various symbols that denote a match in previous data of some length and at some offset.

Indeed, this is an example where each English word in a book gets a unique symbol for the purposes of Huffman coding. Note that the Huffman output is in base 52 (abc...xyzABC...XYZ) alphabet instead of the usual binary.

One way could be to split the image file into RGB or CMYK channels, and then compress the relative brightness of pixels per channel.

Huffman coding is not used directly by PNG. PNG instead uses the regular DEFLATE algorithm from Zip (and Gzip), which uses Huffman coding as its last stage, to output the symbols created by its LZ77-based compression algorithm.