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:30 "Re: Elevation Data", by Joris Van Damme
Bob, Bob Friesenhahn wrote: > On Wed, 17 Jan 2007, Joris wrote: > > > > It makes sense for floating point grayscale data, or any data under > > that Photometric tag, to assume the range of 0.0 to 1.0, simply > > because there is no other intrinsic range on this. For example, 0.0 > > to 255.0, makes no sense, unless there is something intrinsic in > > the concept of grayscale that binds it to 8 bit ranges in > > particular. Amongst the few testfiles I > > It seems that the 0.0 to 1.0 range is "popular". A 0 to 100 range > seems just as useful. Other ranges may make better use of the > floating point values and avoid unnecessary quantization. Such a free dynamic range would only make sense if... a) either the majority of readers listening to correct SMinSampleValue and SMaxSampleValue tags, after the majority of writers actually write that b) or either the dynamic range checking you elaborated upon is used c) or either if interchange isn't important We can't consider c), if interchange is not important that why would we be discussing this? In closed systems, you can do anything you please, of course, but that's nothing to do with this discussion. I can't see a) happening either now or any time soon, but perhaps Ed will correct me on this point. So that leaves either b), or either agreeing a 'just anything' scheme doesn't work. I have some major remarks with the dynamic scheme. For starters, it's a two-pass scheme. Your algorithm needs to browse through the complete data before it's able to derive a range and make sense of the first pixel. That's no problem if images are small and/or buffered, but it doesn't scale to progressive streamed handling if big images. Secondly, it is quite common for image data to have a used range different from an actual colourspace range. Consider high range data, that need to encode 'blacker then black' and 'whiter then white', and needs normal renders to clip. That's a common application of floating point imagery. Your dynamic range detection scheme is not clipping, but taking 'blacker then black' as actual black, 'whiter then white' as actual white, and intended black and intended white become some gray. Conversely, much imagery doesn't use its full range. Normal photographic material, for example, doesn't use the brightest white, nor does it contain patches of pure black. That's intentional, that's the actual image. Your dynamic range detection scheme applies something like a histogram equalisation, in a non-lineair space to add injury to insult, and that's no writer's intention. So, it seems that an 'anything goes as I'll detect it anyway' just isn't a valid option, not with interchange in mind, and not for progressive streamed handling of big images in any case. 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