AWARE [SYSTEMS]
AWare Systems, , Home TIFF and LibTiff Mailing List Archive

LibTiff Mailing List

TIFF and LibTiff Mailing List Archive
October 1999

Previous Thread
Next Thread

Previous by Thread
Next by Thread

Previous by Date
Next by Date

Contact

The TIFF Mailing List Homepage
Archive maintained by AWare Systems



New Datamatrix section



Valid HTML 4.01!



Thread

1999.10.14 14:55 "TIFF Version validation", by Bill Comstock
1999.10.15 00:33 "Re: TIFF Version validation", by Tom Lane
1999.10.15 17:20 "Re: TIFF Version validation", by Thomas E Deweese
1999.10.16 05:34 "Re: TIFF Version validation", by Jaya Krishnan Chathu
1999.10.16 22:00 "Re: TIFF Version validation", by Michael L Welles

1999.10.15 00:33 "Re: TIFF Version validation", by Tom Lane

Bill Comstock <comstock@fas.harvard.edu> writes:
> I'm interested in putting a large collection of TIFF images through a
> validation process, one that tests each image against a series of rules and
> reports whether it conforms to the TIFF standard and also which version of
> the TIFF standard it complies with.  In other words, I'm looking for a
> utility that can report which TIFF version a particular TIFF file conforms
> to.  If there is not such a utility, how would one know which version TIFF
> s/he is producing?

To my mind, even asking this question indicates a misunderstanding of
the way TIFF works.  There is no version number in TIFF files (unless
you consider the famous "42" to be a version number, but actually it's
just an identifying constant).  Decoders are absolutely not supposed to
decide whether they can handle a file on the basis of whether it is a
"newer version" than what they know about; rather they are supposed to
examine all the important tags and see whether they understand the
contents of each one.  For example, a decoder that encounters a
Compression tag value that it doesn't support cannot decode the file.
That doesn't necessarily mean that the decoder is an older version than
the file is.  The compression method could be one added by a more recent
spec release, but it could also be one that the decoder author knew of
and deliberately omitted support for, or it could be a private
compression method of who-knows-what vintage.  Conversely, a decoder
could successfully decode a file that does use features not present in
the TIFF spec version the author consulted, if those features are only
in auxiliary tags.

A more useful way to look at things is a profile of features required to
decode any particular TIFF --- for example, if your program said "tiled
TIFF using LZW compression and containing 24-bit RGB data", that would
convey helpful information.  You can't usefully boil it down to "version
5.0" (or whichever spec release was the first one to mention all of
those features), because almost no decoder supports the *whole* spec of
any release.

                        regards, tom lane