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 16:52 "Re: Elevation Data", by Ed Grissom
In a previous message, Joris said: > > Though, still, have you seen many actual use of these tags in the > implied sense? If you've test images that do use them this way, I'd be > very grateful for a copy. No, unfortunately, in the GIS/RemoteSensing community, we are all just standing on the sidelines waiting for someone else to go first. I have some 32bit floating point data that I am not allowed to share, but it does not use any of the min/max tags. I do not know what software was used to create it either. > 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 ? -- ed grissom ed.grissom@intergraph.com