LibTiff Mailing List
TIFF and LibTiff Mailing List Archive
November 1999
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
1999.12.01 14:33 "Re: libtiff 3.5.3 release.", by <apex@calpha.com>
Martin Bailey wrote: > At 17:23 30/11/99 -0500, Michael L. Welles wrote: > > >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. > > Regards > > Martin Bailey > > ------------------------------------------------------------- > Senior Technical Consultant martinb@harlequin.com > Digital Print & Publishing +44 1223 873800 > Harlequin http://www.harlequin.com > ------------------------------------------------------------- > If my views didn't usually coincide with those of my employer > I probably wouldn't work here, but I am not a spokesman for > Harlequin and the buck stops with me for what I say. > ------------------------------------------------------------- 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