TIFF and LibTiff Mail List Archive


1996.12.11 02:01 "Confusing TIFF Tags", by Hugues Talbot
1996.12.11 10:17 "Re: Confusing TIFF Tags", by Niles Ritter
1996.12.11 18:31 "Re: Confusing TIFF Tags", by Sam Leffler

1996.12.11 10:17 "Re: Confusing TIFF Tags", by Niles Ritter

I'm confused by (at least) one thing in Sam's library. Some tags, like the SampleFormat tag (#339), which help interpret each data sample in a pixel, should be associated with as many values as there are samples per pixel, according to TIFFv6.0

Yet Sam's library allows to retrieve only one value for this tag per subimage, regardless of the number of samples. The TIFFGetField function should return an array of values, not a single one.

There are other examples, like SMinSampleValue, SMaxSampleValue, etc.

Is this a known libtiff limitation or is this a policy? in any case where can I find some documentation about these puzzling facts?

This is a libtiff limitation. Not much of one, though, since few images have mixed types. The limitation is for several reasons. One is that some bogus TIFF writer programs only wrote one value for the multi-valued tag, and so the library has to allow for that. Secondly, the logic for keeping tracking of heterogeneous multi-sampled data is much more nasty, and just asking for trouble if used. The compression codecs, in particular, would get very upset at variable-bit data. libtiff just checks to make sure that all N values of these particular "per sample" tags are all the same, and just returns the common value. If they differ, libtiff issues an error, "Cannot handle different per-sample values for field \"%s\"

Supported libtiff features are driven more by use, than by attempting to fully implement all possible TIFF files (1024 bits per sample?) although it does an admirable job at that. If a bunch of heterogeneous image files come along and populate the earth, and there is a darn good reason for their continued existence, then there is an argument for extending TIFF.