1999.12.01 14:33 "Re: libtiff 3.5.3 release.", by Andy

Unfortunatly, the compression removal means that saved image size has grown dramatically. Without a change in the TIFF spec to support another lossless compression format, this is unavoidable.

The library can use zip for lossless compression (thanks, Sam!), but as this is not part of the spec, TIFFs using zip compression may not work with other software.

At present the only specification for ZIP in TIFF would appear to be the code in LibTIFF, so only applications built around LibTIFF will support ZIP.

If somebody were to produce a text specification, akin to the draft tech note 2 that defined the used of Compression=7 for new format JPEG, then it's possible that more software would be written to support ZIP in TIFF.

I realise that this reinforces a two-level specification, which is not a good thing, but it may also provide a little pressure in the right places for things to be moved on in a more 'official' way.

THat sounds like a fine idea.

I am thinking one thing that would be great to consider would be PNG (Portable Network Graphics) differencing predictors. From PNG Spec 1.1, there are a variety of descriptors, from PNG Spec section 6, Filter Algorithms:

0 None
1 Sub
2 Up
3 Average
4 Paeth

Offhand, these exact same predictors are used in PDF for FlateDecode data, albeit with different numeric values, as well as an "optimal" encoding, where each scan line is prepended with that line's filter. Generally, the PDF FlateDecode algorithm just uses optimal and reads PNG-style data.

I'm not sure how well this particular differencing filter scheme would work with strip or tile based TIFF IO, yet it certainly would engender interoperability.

What is the compression tag TIFFTAG_COMPRESSION assigned to Zip? The file tiff.h says

#define     COMPRESSION_DEFLATE  32946 /* Deflate compression */

An associated tag is Zip quality:

/* Note: quality level is on the ZLIB 1-9 scale. Default value is -1 */
#define TIFFTAG_ZIPQUALITY  65557 /* compression quality level */

Then, it appears that each strip is encoded by itself as one Zip/Deflate compressed data segment. I don't know if/what are bit/byte endianness issues with that.

So, to add predictors, while tif_zip.c has included tif_predict.h, I don't see where it is used. I am thinking that using Deflate with predictors ala PNG is requiring a separate TIFFTAG_COMPRESSION tag, for example 32947, except this is already reserved in tiff.h for something else, so any unused number, or maybe something that is in TIFF 7.0. Would there need to be a different tag?

Then, there could be a TIFFTAG_ZIPPREDICTOR, although the way PNG does it, this predictor is prepended to each scanline, so it wouldn't be needed as an IFD level tag. Are there other ways to have a predictor on the scanline data that should be considered?

I am thinking PNG compresses all the data as one contiguous block, even if the data is broken into more then one IDAT chunk, I may be wrong. What are the issues with compressing strips separately or all strips, I guess it should be one Zip per strip.

PNG: http://www.cdrom.com/pub/png/

So, maybe Leffler's tif_zip.c should be accepted as canonical TIFF-Zip, and then one set up for more compressible TIFF-Zip99 with predictors, and then maybe TIFF 7.0 will say something about it.

Andy