JC>The original question was about formats that didn't require any
JC>compression at all.  I was merely pointing out that while RLE IS
JC>compression, it's extremely simple so there's rarely a reason to exclude
JC>supporting it.
JC>This is less true of LZ based compression: while not _terribly_ complex,
JC>these certainly require a LOT more work than uncompressed or RLE images.
JC>It's FAR from true of DCT, which is quite complex, and generally MUCH
JC>slower than the preceding alternatives.  Finally, DCT is a lossy
JC>compression, and the amount of compression it achieves depends largely
JC>upon the amount of deterioration of the image you allow.  The idea is to
JC>find a balance where you get minimal loss of quality in exchange for a
JC>substantial improvement in compression.  However, in some cases even a
JC>minimal loss of quality isn't acceptable.
JC>Finally, I'd note that which will work best depends heavily on the type
JC>of images you're working with.  DCT works well for more or less
JC>photographic type images, but does far less with, say, line drawings.
JC>For many line drawings and similar items, RLE will produce nearly the
JC>same comrpession as other forms, but with far less work.
JC>    Later,
JC>    Jerry.
Yes, I agree that DCT is lossy, but it is effective in true colour/high 
colour modes.
I've seen some of the strangest graphics format compressions. One which I saw 
uses huffman encoding, and I must admit, it is pretty tricky.  If you've ever 
seen a huffman coded bitmap you'd be surprised by the fact that it uses 
Binary Trees.
LZW compression is also pretty good, but the best overall I think is 
arithmetic compression.
... Hard work never killed anyone but why take a risk?
--- Ezycom V1.48g0 01fd016b
---------------