LibTiff Mailing List

Hugues writes,

>  	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.

 --Niles.


AWARE [SYSTEMS]		Imaging expertise for the Delphi developer
		TIFF and LibTiff Mailing List Archive
	LibTiff Mailing List TIFF and LibTiff Mailing List Archive December 1996 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 1996.12.11 02:01 "Confusing TIFF Tags", by Hugues Talbot 1996.12.11 17:17 "Re: Confusing TIFF Tags", by Niles Ritter 1996.12.11 18:31 "Re: Confusing TIFF Tags", by Sam Leffler 1996.12.11 17:17 "Re: Confusing TIFF Tags", by Niles Ritter Hugues writes, > 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. --Niles.

LibTiff Mailing List

Thread

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