2007.01.17 19:26 "RE: [Tiff] Elevation Data", by Ed Grissom

In a previous message, Joris said:

> Grissom, Ed wrote:
> > Anyone else want to come along?
>
> We could come to an agreed recommendation I think...
>
> How about this...
>
> ** Writer recommendation **
>

I can agree with this. At least for me I am going to start writing them very soon now.

>
> ** Reader recommendation **
>

> Readers are recommended to check the SMin/SMax tags when reading > floating point data. If they are present, their values is to be taken as

> a firm indication of range, meaning any image data outside the range is

> taken to be 'blacker-then-black' or similar and needs to be clipped in > any normal rendering process,

I'm good up to here..

> and, conversely, any partial use of the
> range specified in SMin/SMax is to be taken as partial use of the

> colorspace or range, and does not imply histogram stretching or > equalising is required.

I'm not sure that I understand this "partial use" and what you are saying it does or does not imply. I just need more explanation.

What bothers me is that I think I *do* want to stretch or equalize this data to fit the 0..255 range of my monitor when I display it.

If the SMin/SMax tags aren't present, readers are recommended to take that as a firm indication the standard 'intrinsic' range is use.

In practice, this is going to be the hardest one. I would almost prefer to say that if the tags are not present then it is the wild wild west and you need to be very careful about what you assume about the data.

  -----

I don't understand this distinction (in other messages) about "images". Obviously, there are some severe deficiencies in the allowed TIFF Photometric spaces (http://www.asmail.be/msg0055503273.html), but if I have a grid of values, there should be a way for any app to easily display the data as an image on a 0..255 monitor, no matter if the data is stored as bit, byte, signed short, unsigned short, float, or double (or whatever else).

--
ed grissom
ed.grissom@intergraph.com