2007.01.17 02:25 "[Tiff] Elevation Data", by Craig Bruce

2007.01.17 20:00 "Re: [Tiff] Elevation Data", by Craig Bruce

"Grissom, Ed" <ed.grissom@intergraph.com> wrote:

> We currently are using Min/Max as a valid range (if they are present and > make sense) in violation of the spec for 16 bit data. I had not looked

> at the spec for SMin/SMax closely before today, but I am going to start > using these in preference to Min/Max, since they do appear to do what I

> want.
>

Anyone else want to come along?

I do, I do! I've made my application write the SMin/SMax tags for "unusual" image types. My reading application presently interprets the Min/Max tags as hard range values if they happen to match sensible powers of two, since some our customers use them in this way. As someone else said, this is something one does in the wild, wild west.

"Gerben Vos" <Gerben@zylab.com> wrote:

> I don't see where the TIFF6 spec says they're just statistical. It > doesn't specify sanctions for when they're wrong, but the text seems

> quite clear that if the tags are present, they are to contain the real > bottom and top of the value range. An application rejecting a TIFF

> because it finds a sample value outside the defined range would be in > its right based on the text.

Section 8 of the TIFF 6.0 Final-June 3, 1992 sepecification says:

   MaxSampleValue

   The maximum component value used.
   Tag       = 281 (119.H)
   Type      = SHORT
   N         = SamplesPerPixel

   This field is not to be used to affect the visual appearance of an
   image when it is displayed or printed. Nor should this field affect
   the interpretation of any other field; it is used only for statistical
   purposes.

   Default is 2**(BitsPerSample) - 1.

A hard range definition would necessarily "affect the visual appearance of an image".

Section 19 says only:

   SMinSampleValue

   Tag     = 340 (154.H)
   Type    = the field type that best matches the sample data
   N       = SamplesPerPixel

   This field specifies the minimum sample value. Note that a value
   should be given for each data sample. That is, if the image has 3
   SamplesPerPixel, 3 values must be specified.

   The default for SMinSampleValue and SMaxSampleValue is the full range
   of the data type.

"Joris" <joris.at.lebbeke@skynet.be> wrote:

** Writer recommendation **

Writers are recomended to use the 'intrinsic' range of the colourspace they use for floating point image data. That means 0.0 to 1.0 for MinIsBlack, MinIsWhite, or any of the R, G, or B channels, 0.0 to 100.0 for the L* channels of CIE L*a*b*, etc. For Undefined extra samples, the range of 0.0 to 0.1 is recommended. If this 'intrinsic' range is used, it is recommended to write out proper values for SMin/SMax tag.

It is also valid, and recommended as a second best choice, to use any other range. In this case, writing out the SMin/SMax tag is obligatory.

Sounds good to me.

Frank Warmerdam <warmerdam@pobox.com> wrote:

> I normally write such scientific data as the whole dataset (not as > some sort of addition to a display image). My normal practice is

> to set PHOTOMETRIC_MINISBLACK for this sample. That is, I think the > default display is as a greyscale image.

Exactly. Why write the data twice? Of course, it would be nice if regular photo viewers could do something sensible with an elevation raster.

When I used the term "BlackIsZero" before, I was just quoting the TIFF 6.0 spec. Libtiff uses PHOTOMETRIC_MINISBLACK to refer to the same code value (1 for tag 262).

> If values are rescaled to some arbitrary range (like 0.0 to 1.0) before > writing to the TIFF file there is no way to reconstruct the original

> values since we can't embed the scaling information in TIFF. It is > true that we also don't capture the units properly in TIFF (as a rule)

> and it is up to the user to keep track of those themselves (ie. meters > or feet).

The horizontal units can be specified as part of a GeoTIFF 3D coordinate system, such as EPSG:4329 (WGS84 + heights in meters).

--------------