Message-ID: 384531D3.DE4F8EB6@calpha.com
To: tiff@olympiakos.com
Subject: Re: libtiff 3.5.3 release.
From: Andy <apex@calpha.com>
Date: Wed, 01 Dec 1999 09:33:55 -0500
References: <3.0.5.32.19991130230733.00b22520@mailhost.cam.harlequin.co.uk>
Sender: owner-tiff@olympiakos.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


