AWARE [SYSTEMS] Imaging expertise for the Delphi developer
AWare Systems, Imaging expertise for the Delphi developer, Home TIFF and LibTiff Mailing List Archive

LibTiff Mailing List

TIFF and LibTiff Mailing List Archive
January 2007

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



Valid HTML 4.01!



Thread

2007.01.17 02:25 "Elevation Data", by Craig Bruce
2007.01.17 02:57 "Re: Elevation Data", by Bob Friesenhahn
2007.01.17 08:07 "Re: Elevation Data", by Joris Van Damme
2007.01.17 15:24 "Re: Elevation Data", by Ed Grissom
2007.01.17 15:55 "Re: Elevation Data", by Joris Van Damme
2007.01.17 16:03 "Re: Elevation Data", by Ed Grissom
2007.01.17 16:20 "Re: Elevation Data", by Joris Van Damme
2007.01.17 16:52 "Re: Elevation Data", by Ed Grissom
2007.01.17 17:20 "Re: Elevation Data", by Joris Van Damme
2007.01.17 19:26 "Re: Elevation Data", by Ed Grissom
2007.01.17 20:22 "Re: Elevation Data", by Joris Van Damme
2007.01.17 20:52 "Re: Elevation Data", by Joris Van Damme
2007.01.17 21:00 "Re: Elevation Data", by Bob Friesenhahn
2007.01.17 21:58 "Re: Elevation Data", by Joris Van Damme
2007.01.17 22:18 "Re: Elevation Data", by Bob Friesenhahn
2007.01.18 11:09 "Re: Elevation Data", by Andrey Kiselev
2007.01.17 20:00 "Re: Elevation Data", by Craig Bruce
2007.01.17 17:01 "Re: Elevation Data", by Bob Friesenhahn
2007.01.17 18:35 "Re: Elevation Data", by Joris Van Damme
2007.01.17 21:08 "Re: Elevation Data", by Frank Warmerdam
2007.01.17 19:27 "Re: Elevation Data", by Frank Warmerdam
2007.01.17 16:08 "Re: Elevation Data", by Bob Friesenhahn
2007.01.17 16:30 "Re: Elevation Data", by Joris Van Damme
2007.01.17 19:03 "Re: Elevation Data", by Frank Warmerdam
2007.01.17 17:28 "Re: Elevation Data", by Joris Van Damme
2007.01.17 21:18 "Re: Elevation Data", by Frank Warmerdam
2007.01.17 16:51 "Re: Elevation Data", by Gerben Vos
2007.01.17 18:03 "Re: Elevation Data", by Joris Van Damme
2007.01.17 16:27 "Re: Elevation Data", by Frank Warmerdam
2007.01.17 19:00 "Re: Elevation Data", by Joris Van Damme
2007.01.17 21:51 "Re: Elevation Data", by Frank Warmerdam
2007.01.17 03:35 "Re: Elevation Data", by Frank Warmerdam
2007.01.17 08:00 "Re: Elevation Data", by Joris Van Damme
2007.01.17 20:07 "Re: Elevation Data", by Joris Van Damme

2007.01.17 20:00 "Re: 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).

--------------------------+----------------------+--------------------------
Dr. Craig S. Bruce        | Ph 819-771-8303 x205 |             CubeWerx Inc.
Senior Software Developer |   Fax 819-771-8388   |  Gatineau, Québec, Canada
csbruce@cubewerx.com      |  http://csbruce.com/ |  http://www.cubewerx.com/
--------------------------+----------------------+--------------------------
  "Q: What is the most pervasive carcinogenic substance in our atmosphere?
                                 A: Oxygen."