Monochrome Run-Length Protocol Example
[rev. 11/5/2006]

Let us agree to the following file protocol:

1.	First 2 bytes are 4D 48 hex to indicate author’s initials (MH).
2.	Next 4 bytes are 4D 4F 4E 4F hex (the word MONO) to indicate the type of protocol in use, namely Mr. Hansen’s monochrome compressed protocol.
3.	Next 2 bytes indicate height in pixels (stored little-endian).
4.	Next 2 bytes after that indicate width in pixels (stored little-endian).
5.	Now that the header is complete, the main data portion of the file can begin. Bitstream is to be interpreted as a group of 8-bit blocks, organized as follows: first bit indicates the pixel color (0=white, 1=black), and the next 7 bits indicate the repeat count. For example, consider the byte A7 hex, which can be translated into the 8 binary bits 10100111. The first bit, 1, indicates that the color is black, and the remaining 7 bits, 0100111, indicate that the black pixel is to be repeated 39 times, since 0100111 binary = 39 decimal.
6.	The last byte of the file will be hex 1A (decimal 26) to indicate end of file.

Here is how the checkmark bitmap would be encoded in hex as we implement the protocol above:

Step 1. 4D 48
Step 2. 4D 4F 4E 4F
Step 3. 0C 00
Step 4. 24 00

Step 5.

Action	Binary	Hex	Byte count
white repeated 6 times	0 0000110	06	11 (incl. 10 from above)
black 1	1 0000001	81	12
white 25	0 0011001	19	13
black 3	1 0000011	83	14
white 6	0 0000110	06	15
black 1	1 0000001	81	16
white 23	0 0010111	17	17
black 3	1 0000011	83	18
white 8	0 0001000	08	19
black 2	1 0000010	82	20
white 20	0 0010100	14	21
black 4	1 0000100	84	22
white 10	0 0001010	0A	23
black 2	1 0000010	82	24
white 17	0 0010001	11	25
black 4	1 0000100	84	26
white 12	0 0001100	0C	27
black 3	1 0000011	83	28
white 13	0 0001101	0D	29
black 6	1 0000110	86	30
white 14	0 0001110	0E	31
black 3	1 0000011	83	32
white 9	0 0001001	09	33
black 7	1 0000111	87	34
white 16	0 0010000	10	35
black 5	1 0000101	85	36
white 4	0 0000100	04	37
black 9	1 0001001	89	38
white 18	0 0010010	12	39
black 16	1 0010000	90	40
white 20	0 0010100	14	41
black 14	1 0001110	8E	42
white 22	0 0010110	16	43
black 11	1 0001011	8B	44
white 25	0 0011001	19	45
black 9	1 0001001	89	46
white 28	0 0011100	1C	47
black 6	1 0000110	86	48
white 27	0 0011011	1B	49

6. Last byte (the 50th byte in the file): 1A

Here is the entire file, in hex:

4D 48 4D 4F 4E 4F
0C 00 24 00
06 81 19 83 06 81 17 83 08 82
14 84 0A 82 11 84 0C 83 0D 86
0E 83 09 87 10 85 04 89 12 90
14 8E 16 8B 19 89 1C 86 1B 1A

Total file size = 50 bytes = 400 bits.
If the bitmap had been stored as a raw (uncompressed) 1-bit-per-pixel map, the size required would have been 54 bytes (432 bits). Therefore, the run-length encoding scheme here saved only a small amount of space.

With a cleverer compression protocol, it would be possible to save much more space. For example, since there is no repeat count greater than 31, we do not need 6 bits for storing the repeat count; 5 bits would suffice. Also, since we can assume that the first pixel is white, there is no need to store a “0” or “1” bit to indicate the color. We could simply assume that each repeat count was referring to the opposite color of its predecessor. On the rare occasion when we needed to continue with the same color, a repeat count of 0 could be used.

The disadvantage of coding the “guts” of the file at 5 bits per action is that the byte boundaries become confusing. A computer can be programmed to handle this, of course, but it is difficult to do by hand. With 39 instructions at 5 bits each, a total of 195 bits will be required. We would have to remember to append 5 zero bits at the end in order to reach a byte boundary, making the “guts” of the file 200 bits or 25 bytes. Under this scheme, the file size would be 10 bytes (header) + 25 bytes (“guts”) + 1 byte (terminator) = 36 bytes, a savings of 33% when compared to the uncompressed size of 54 bytes.