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
Thread
2007.01.17 17:20 "Re: Elevation Data", by Joris Van Damme
Ed, Grissom, Ed wrote: > > In any case, when it comes to a recommendation for writers, would > > you agree that recommending them to stick with the 'intrinsic' > > range of the samples, as I explained it, is best and most likely to > > lead to good interchange (as far as there is interchange of > > floating point image data, at all)? > > I don't mind such a recommendation as long as folks don't think they > _have_ to transform their data. > > We will rarely see a 0.0 to 1.0 range on elevation data. Typically, > elevation data will be stored in either feet or meters and will be a > floating point number within a limited range (for instance, the (USA) > State of Tennessee should have no elevations below 50ft, nor above > 7000ft). I would want to store this _as_collected_ and put the real > min and max in the SMin and SMax values. I don't want to scale and > descale the data to a 0.0 to 1.0 range. Especially since there is no > STANDARD way of storing the scale and bias in an approved tag. > > When using meters as a unit, most elevation data for earth would fall > between +/-10,000. > When using feet as a unit, most elevation data for earth would fall > between +/-30,000. > > If the data does not have a "measured in the real world" > interpretation, then a 0.0 to 1.0 range makes more sense as a default > way to represent it. > > 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 ? We could come to an agreed recommendation I think... I can certainly understand your application and concerns and think they should be supported. And I do think a recommendation would be nice, as I hope to expand my site in the very short term with discussions of topics just like this one. How about this... ** 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. ** 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, 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. If the SMin/SMax tags aren't present, readers are recommended to take that as a firm indication the standard 'intrinsic' range is use. Would you agree? Joris Van Damme info@awaresystems.be http://www.awaresystems.be/ Download your free TIFF tag viewer for windows here: http://www.awaresystems.be/imaging/tiff/astifftagviewer.html