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 20:22 "Re: Elevation Data", by Joris Van Damme
Ed, Grissom, Ed wrote: > > 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. So how do I communicate to you a photograph of a very bright seen, with no actual black in it? Stretching or equalising when SMin/SMax tags are absent implies that you take range use to be the default value of these tags. That a) conflicts with most imaging application of floating point image data, where used ranges are either wider or more narrow (or wider on one end and more narrow on the other) then the back to white range b) is a technological challenge in image streaming. Condider an 8 gigabyte image, in its uncompressed form. Consider a programmer who feels today's 32bit hardware needs to suffice to render it. Even if the programmer is satisfied to not start rendering it right away, streamed through the chained list of required imaging operations decoding, resampling, and color converting, that programmer is forced to decode the 8 gigabyte compressed image twice. By the time he can even start the actual rendering stream, the user has gone to Rome and back on his bare knees, out of shere frustration. I mean, it doesn't scale. c) is unheard of. Tag default values don't and shouldn't depend on an image analysis process. > 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. Isn't the purpose of public recommendations on authority sites to try and resolve wild west situations, or at least promote convergence towards a more regulated situation in the future? > 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). I've no vested interest but lost half a day already, so please forgive me for only reading the top lines of the message you pointed to. I take it your concern there is similar to Craig's, in that there is no actual real image data rightly and correctly covered by any specific Photometric. Yet, you need to pick one, because even if you do use ExtraSamples as intended and code your multi-band data as Undefined ExtraSamples, you need a Photometric there, and base image channels. In essence, what you guys need is a NULL Photometric, with 0 base channels, and ExtraSamples == SamplesPerPixel. Right? Best regards, 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