recommendations for lossless compression of many small bitmaps?

How much compression are you hoping for? 2:1, 4:1?

Does the compression have to be lossless, or will near lossless work
(visually lossless?)

JPEG may not be all that bad on small pictures, if you strip out the
overhead. Compressing one sample 32x32 image I get 909 bytes at 80%
(using paint shop pro), removing the IPC/EXIF information from the
file yields 597 bytes. And you might be able to trim the header as
well, or use a smaller custom header, getting it to around 4:1
compression. Tileing smaller images may help, but it may be wise to
put then on 8 pixel boundaries since JPEG works on 8x8 blocks.

Do you have any samples of the images?

-Tim

Tue, 15 Jul 2003 09:45:18 +0800, " Hong Peow" <iou@iwow.com.sg>
wrote:

>Thanks Tim.
>
>The bitmaps are all in 16 bit colors (RGB 565). Yes, due to their size, the
>actual number of colors might be less than 256. They are quite small, that's
>one reason I believe it would be inefficient to compress them individually.
>For the big true color pictures, I'm using jpeg compression.
>
>I'm not acquainted with png. I'll check it out.
>Is there any compression scheme that can retieve the relevant infomation
>without decompressing the entire block? E.g. compress 100 bitmaps in 1
>block, and can retrieve the 3rd bitmap.
>
>>Creating blocks with many tiles will help compression (more so if each
>>tile is similar in content), but this assumes you have enough working
>>memory to decompress a tile set rather than just the tile you are
>>after.
>I can have about 50 - 60k of working memory.
>
>
>Initially, I had the idea to group those similar icons so that they'd
>utilize a common color table. E.g. 4 bitmap icons share a common LUT.
>Process the bitmap icons such that the max number of colors would fall
>within those in the color table.
>
>E.g. the savings:
>4 (32x32) 16bit bitmaps =>
no compression, 4 x 1024(pixels) x 2(16bits) bytes = 8 k bytes
common LUT 4 x 1024(pixels) x 1 + 512 (color table) =
>4.5k bytes
>
>I dropped the idea cos
1) the savings isn't much,
2) the icons would not look so good cos they are designed to be photo
>realistic. Maybe too lossy than lossless.
>
course, the process to clipped & share color table is automated. But the
>user have to choose ( intuitively ;-) ) which bitmap to group. I'm not ready
>to run into optimization problem.
>
>
>
>Thanks.
Hong Peow
>
>
>
>>Hi,
>>
>>I have many small bitmap, sizes typically say 16 x 16, 30 x 30 and I've
>>about couple of hundreds. They're meant for embedded environment so space
>is
>>issue.
>>I guess I've to compress blocks of them rather than individually. Thus
>>retrieval of a bitmap would require decompressing the corresponding block,
>>and then retrieve the actual bitmap to be bitblt.
>>
>>Do you have any recommendation which algo would be suited?
>any better scheme to store them for retrieval?
>
>Can you give any more details about these bitmaps? Are they full
>color picture, icons, 256 colors, etc. The content of the pictures
>can influence the choice of compression method quite a bit. For
>example, if you have icons that are full color, but really only use 32
>unique colors, etc
>
>For general compresison png may work ok, or even a simple range coder,
>but other methods may work better or be simpler to implement depending
>on the content.
>
>Creating blocks with many tiles will help compression (more so if each
>tile is similar in content), but this assumes you have enough working
>memory to decompress a tile set rather than just the tile you are
>after.
>
>-Tim
>
>