Received: from sgi.sgi.com (192.48.153.1) by cerious.com
 with SMTP (Apple Internet Mail Server 1.1.1); Wed, 11 Dec 1996 19:31:06 -0500
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA03406; Wed, 11 Dec 1996 13:11:26 -0800
Received: (from daemon@localhost) by cthulhu.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id RAA14059 for tiff-list; Wed, 11 Dec 1996 17:20:42 GMT
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37]) by cthulhu.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id JAA14026 for <tiff-relay@relay.engr.sgi.com>; Wed, 11 Dec 1996 09:20:36 -0800
Received: from iems.jpl.nasa.gov (iems.jpl.nasa.gov [137.79.1.40]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA11400 for <tiff@sgi.com>; Wed, 11 Dec 1996 09:20:33 -0800
Received: from tazboy.JPL.NASA.GOV (tazboy.jpl.nasa.gov [128.149.24.99]) by iems.jpl.nasa.gov (8.6.12/8.6.6) with SMTP id JAA17976; Wed, 11 Dec 1996 09:22:19 -0800
Received: by tazboy.JPL.NASA.GOV (4.1/SMI-4.1+DXRs2.3)
	id AA23613; Wed, 11 Dec 96 10:17:38 TAN
Date: Wed, 11 Dec 96 10:17:38 TAN
From: ndr@tazboy.jpl.nasa.gov (Niles Ritter)
Message-Id: <9612111717.AA23613@tazboy.JPL.NASA.GOV>
To: Hugues.Talbot@dms.csiro.au
Subject: Re:  Confusing TIFF Tags
Cc: tiff@sgi.com
Sender: owner-tiff@relay.engr.SGI.COM
Precedence: bulk
Status: R

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.
