2007.01.17 20:07 "Re: [Tiff] Elevation Data", by Joris Van Damme
Thanks for commenting on the proposed recommendation.
Unfortunately, I can't agree with anything but the very last part.
> My concern is with this statement:
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.
> My concern is that it conflicts with widespread existing usage which > is to write out data such as elevation with a photometric
> interpretation of MINISBLACK and no SMin/SMax values.
> I would prefer the statement to read as:
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
Yeah, but, this is a writer recommendation. Writers make mistakes all the time. The thing is, the recommendation reflects the fact that readers aren't logically able to resolve the situation if they don't known the writers range intention first hand.
> I also have no intention of following the following reader advice:
If the SMin/SMax tags aren't present, readers are recommended to take that as a firm indication the standard 'intrinsic' range is use.
That may be perfectly fine in your realm of application, but it conflicts with interchange of image data... I think. Writers may write high-range data or partial-gamut-using data in the 'intrinsic' range, and not specify SMin/SMax tag, and unless you take the absence of those tags to mean that the instinsic range is used, you don't get their range intention but their actual encoded range instead. This is the case for the biggest part of the few files in my test file library.
> So, all things considered I'm inclined to leave things in the current > ill defined state which is working fine for me rather than commit to
> your language.
Well, I've no personal gain here and I've spend too much time already in my quixotic concerns for open formats and interchange. Ill defined state it is.
Joris Van Damme
Download your free TIFF tag viewer for windows here: