Fast decompress codec for pics?

[Bob]

What are good codecs that offer fast decompress, for still pictures? I only
need 256 colors, more is fine, but I dont really need it. Images will
usually be that of a text document, but may contain pictures.

For my application, JPEG offers good compression, lossy is fine, but JPEG
decompresses too slow. So, compared to JPEG, is there a codec that has
faster decompress, and comparable compression and quality?

Any advice will be appreciated.

[Hans-Bernhard Broeker]

[F'up2 cut down --- should have been done by OP, but wasn't...]

In comp.graphics.algorithms Bob <b...@bob.bob> wrote:

> For my application, JPEG offers good compression, lossy is fine, but
> JPEG decompresses too slow. So, compared to JPEG, is there a codec
> that has faster decompress, and comparable compression and quality?

For 256-color images, you should definitely consider PNG (using the
same compression algorithm as 'gzip' and 'zip'). The
compression/decompression algorithm are a whole lot simpler.

--
Hans-Bernhard Broeker (bro...@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.

[Marco Schmidt]

fup2 comp.compression

Bob:

If you only have 256 colors and if you are not using grayscale but
"real" color, JPEG probably never was the right choice for you in the
first place.

Vector image quantization is known to compress well and slow, and
decompress very fast.

At <http://www.gamasutra.com/features/20010416/ivanov_01.htm> there is
a nice introductory article. If it is the one I think it is, now you
need a free login to read it.

Regards,
Marco

[Bob]

Thanks for the suggestion. I'm using quicktime which offers quite a few
codecs, but vq does not appear to be one of them.

[Bob]

on 8/15/03 5:29 AM, Hans-Bernhard Broeker wrote:

> For 256-color images, you should definitely consider PNG (using the
> same compression algorithm as 'gzip' and 'zip'). The
> compression/decompression algorithm are a whole lot simpler.

You are right, I tried PNG and it does work very well for 256 colors. Two
negative things about it are: Blank white images are about as large as
complex images. Some of the other codecs are 1/3rd the size of PNG for blank
images - and blank images may occur often. But, if there is anything in the
image, PNG kicks butt. (I could always scan the image and check if its blank
and handle that separately.) The other negative, which isnt specific to PNG,
is that all the codecs (other than RLE) are slower than I wish they were.
The images are in a scrolling list, so if scrolling is to be fast and
smooth, then decompression must be fast too.

[Thomas Richter]

Hi,

> You are right, I tried PNG and it does work very well for 256 colors. Two
> negative things about it are: Blank white images are about as large as
> complex images. Some of the other codecs are 1/3rd the size of PNG for blank
> images - and blank images may occur often. But, if there is anything in the
> image, PNG kicks butt. (I could always scan the image and check if its blank
> and handle that separately.) The other negative, which isnt specific to PNG,
> is that all the codecs (other than RLE) are slower than I wish they were.
> The images are in a scrolling list, so if scrolling is to be fast and
> smooth, then decompression must be fast too.

Another pretty fast lossless (or near lossless) codec would be JPEG-LS
(not to be mixed with traditional JPEG, it's a horse of a quite different
color). It uses a low-complexity prediction model coupled (in the baseline
mode) with Huffman compression that could be made quite fast if required.

For encoding palette images, you should, however, sort the palette in a
way that similar colors use similar palette indices. This will improve
performance.

So long,
Thomas