"Bob Whiteman" <[EMAIL PROTECTED]> wrote
> Also out of curiosity, bitmaps can be compressed using scan line
compression
> or run length compression. RLE is a pretty standard compression algorithm,
> but what is scan line compression? (I'd like to decide which compression
> will be better for the images in my resources, but I'd rather not have to
> make that decision by trying it out on every image. Knowing the
compression
> algorithm would help.)
>
I worked in document imaging for a while and can offer a possibility. Some
TIFF versions used a compression that compares scan lines and stores the
*difference* between then, then compressing that. This is suited to
documents that have a high level of vertical repeatability (which is true
for typed documents because of the nature of most fonts). This also works
well on images that have solid blocks of colour.
>From here in terms of increase in complexity and potential benefit you move
to variants of quadtree compression which recursively cut the image up into
quarters until a solid square is found and store the tree of parts down to a
solid colour. This is excellent for large images with roughly square blocks
of colour but will typically *increase* the size of images with high levels
of pixel-to-pixel variation.
All of this is good for large images but in the sort of size we're dealing
with on the Palm I'd have thought that it wasn't worth the effort of moving
much past scan-line compression (particularly since the decompression
algorithm takes up code space).
The right compression for your image depends fairly heavily on it's
characteristics. You should look for patterns. You might find significant
advantages by breaking the images up and storing different parts in
different ways or even by implementing a simple vector format (for line art
these can produce amazing compression).
Chris Tutty
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palmos.com/dev/tech/support/forums/
