> I have a line of bits, 104 bytes wide.
> It might contain anything between
> 000.......000 to 010101.....0101 to 11111.....11111
>
> I had thought of a simple RLE encoding, where
> 1XXXXXXX means X+1 pixels of black, and 0XXXXXXX means X+1 pixels of
white,
> but in the case of 010101 sorts of data, it fails rather badly at
compression!
>
> I also thought about compressing the data, and if the "compressed" version
> was longer than the uncompressed, to abort and send raw.
>
> However, it seems to me that there has to be something out there that's
> simple to work with, yet works better than my little hare-brained scheme.
>
> What say the group?

There is no compression/encoding that works (compresses) ALL possible
inputs. Simply mathematically impossible. All compressions fail (sometimes
miserably) on some inputs. The best you can have is to send one extra bit to
discriminate between compressed and uncompressed, you your maximum overhead
is one bit.

To choose a good (on average) compression algorithm you must know something
about your data. What you describe is RLE (run length encoding), which is
very good for data that contains long rows of unchanged values.

Wouter van Ooijen

Van Ooijen Technische Informatica: http://www.voti.nl
free PIC stuff: Jal compiler, Wisp programmer, WLoader bootloader
PICs kopen? http://www.voti.nl/shop

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics