Is it possible to compress a single byte without any loss?

Question

I know it sounds kind of impossible, because 1 byte can represent 256 different values, but I still wonder if there's (even just theoretically) any approach to achieve that.

Answer 1

Sure. You need to map all 256 values to something. That something could be a variable-bit-length code, usually a prefix code so that it can be uniquely decoded. So I could map the 256 possible byte values to the bit sequences 0, 10, 110, 1110, ..., (255 1's)0. The first seven are less than eight bits in length. So if the single byte to compress is a 0, then I can compress it to 1 bit. I can send that one bit, and the decompressor will recognize it and decompress it to the 0 byte. Voilà! I have compressed a single byte with no loss.

(By the way, I am taking the question "possible to compress" to also mean the ability to losslessly decompress to the original input. If you do not require decompression, then 100% compression is always possible with the "delete" command.)

You will note however that in this case I cannot compress all of the possible single-byte inputs to less than eight bits. Only some of them. And others of them will expand to more than eight bits. That is always the case for lossless compression. If some inputs are compressed, then there must be other inputs that are expanded.

Why? As an example, there is no way to compress all 256 eight-bit values to all seven-bit values, since there are only 128 seven-bit values. Therefore there must be at least two byte values that map to one seven-bit value. If the decompressor receives that seven-bit value, it has no way of knowing which of the two eight-bit values resulted in that seven-bit value.

Simply by counting how many possible inputs there are, you can show that in order to have enough unique possible outputs to cover all of those inputs, there must be expansion if there is compression.

Answer 2

One byte is the minimal unit to represent 256 unique values. Compression is only possible when you have a domain that is a subset, for example only 16 values [0,15]. In that case you can compress 2 "bytes" into 1 byte, by using 2 nibbles (half byte). Generally, that is what bitmasks are there for. (Bitmaps are an extension of bitmasks.) Generally, in order to compress you have to reduce the domain.

Answer 3

Of course you will be able to compress some combinations and expand others. So from that perspective it is possible.

It leads to an interesting question, what is the smallest average compression size achievable assuming uniformly random input and the input length is fixed at one byte saving 3 bits to specify less than 8 bit lengths? The example stated in another answer would require (1+2+...+255+256)/256 bits which is 257×128/256=257/2=128.5 bits. This is far worse than 8 bits. There is no proof as far as I am aware on a lowest bound for this? However given the output length itself encodes information, it should be that 0 bits could be a valid value, 1 bit gives 2 more, 2 bits 4 more, etc so 1+2+4+8+16+32+64+128=255 plus a single full 8 bit remaining value would maps to 256 unique values.

Therefore (0+1×2+2×4+3×8+4×16+5×32+6×64+7×128+8)/256=1546/256=6.0390625.
So for 8 bits if it's your total fixed data length should be on average compressible to just over 6 bits. However the complexity of the code which can decompress it may be significantly more than the simple scheme with 128.5 bits on average.

This trade off in data size of the compressed data vs the data size of the code used to decompress is part of what Kolmogorov complexity is used to represent. The larger the decompression algorithm, the more compressed the data can be since the decompression algorithm itself is containing a lot of information. This does not consider the practical speed efficiency of the decompression algorithm which is practically speaking important. Theoretically speaking, the best algorithm from a pure data perspective is that whose average compression size plus the size of the code required to decompress it are the smallest. For sake of mathematical generality, the whole data and decompression algorithm would need to be encoded on a Universal Turing Machine (UTM) to make a valid comparison.

This comes back to the reason a theoretical minimum is not known. Otherwise purely for the 8 bits fixed input case logically what I specified should be a theoretical maximum disregarding the algorithm. Likely it will still be the best if a best matching algorithm for that mapping could be found which I think is possible.

If you want arbitrary bit lengths or for example any bit length from 1 to 8 bits, it certainly changes the problem. At that point, the output length may also need to be specified unless its built into the compression scheme like using the 0 markers as mentioned or even specifying a length up front. However, specifying the length up front again allows for this highly compact mapping algorithm to be used. There are lots of practical concerns when dealing with any unit smaller than a byte though as effectively it will be rounded up to 8 bits anyway.

But this is sufficient proof that its indeed possible.