LibTiff Mailing List
TIFF and LibTiff Mailing List Archive
September 2005
Previous Thread
Next Thread
Previous by Thread
Next by Thread
Previous by Date
Next by Date
Contact
The TIFF Mailing List Homepage
This list is run by Frank Warmerdam
Archive maintained by AWare Systems
Thread
2005.09.25 04:16 "Re: Additional Lossless Compression Schemes", by Joris Van Damme
Frank Warmerdam wrote: > Perhaps I am still think deflate isn't widely > supported in TIFF because it wasn't 10 years ago. I think so. It is one of the problems in a slow moving business like TIFF, statements like flate compression being badly supported persist for a decade, whilst in the mean time most apps came to support it. Most use LibTiff, and LibTiff supports it for quite a long time now. Or at least, it looks that way to me, but again, we've got no way to measure such stuff in an objective manner. > To be honest I don't know much about the predictor stuff. You really should look into it if you want to improve lossless compression ratio. The theory is this: a sequence like... 200 201 202 203 204 ...compresses badly, whilst... 200 1 1 1 1 ...compressed a lot better. Thus, assuming single-channel 8bit per pixel for a minute, the first value in every scanline is encoded as is, but every subsequent value is replaced with the difference with previous value. In multi-channel single-plane images, the first values that make up the first pixel are encoded as is, and every subsequent value is replaced with the difference with the same channel value in previous pixel. Possibly, in this case, it is better to store planar then chunky if you want to get the most compression gain out of prediction. It can really make a lot of difference, depending on the type of image. The tag to use is http://www.awaresystems.be/imaging/tiff/tifftags/predictor.html. There is a more complete description in the spec. Whether or not LibTiff supports it in the sense that it automatically resolves prediction as part of it resolving compression, I couldn't say. If it doesn't, then I guess you need to do that on the encapsulating application level. Another thing I've been thinking about, is that ZLib supports different levels of compression, and different windows widths and such. Possibly, LibTiff defaults to ZLib usage that is a good trade-off but does not please entirely if you value compression ration much more then compression speed. I would guess LibTiff exposes pseudo-tags to let you fiddle with these, but, again, you probably know those a lot better then I do, I'm not a LibTiff expert. Yet another thing is to use good, big enough strip/tile dimensions. If you use (LibTiff?) code that is based on the original recommendation in the TIFF spec that says ideal size of a strip or tile is around 8 kilobyte, to calculate ideal strip/tile dimensions for you, you'll end up storing a single line per strip and such stuff, that is really crazy today and hurts compression badly. I recommend aiming for 2 megabyte instead. That'll give ZLib data with lots of redundancy to eliminate, instead of limiting its view to a single scanline or just a couple of them, and will contribute quite a bit to a good compression ratio. Joris Van Damme info@awaresystems.be http://www.awaresystems.be/ Download your free TIFF tag viewer for windows here: http://www.awaresystems.be/imaging/tiff/astifftagviewer.html