LibTiff Mailing List
TIFF and LibTiff Mailing List Archive
March 2000
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
2000.03.31 15:14 "Re: Complex Floating Point", by Max Martinez
Antonio, I think the Remote Sensing community is interested in getting this right for purposes of interoperability. I'd like Frank to elaborate on why he would discourage you from putting 128 bits per sample. It seems that there are problems going both ways but from an application standpoint, I'd prefer to have it all in one band (sample). Consider first the two samples approach. The multiple samples approach could be adopted by adding an additional ExtraSamples value or two (e.g., 3 = imaginary part of a complex real/imaginary pair), but as you suggested, complex RGB data would be a problem because you would have to have a convention or an explicit specification about which real sample went with which complex sample etc. Also, it would impose a burden on apps trying to put the two together because it would (unnecessarily?) allow for the real and complex parts to be of different bit depths (some might see that as an advantage). Does it make sense for an app to look just at the real part of a complex image? Finally, on behalf of a company that already has support of complex rasters out there, it would make our support of this scheme rather klunky because we would have to simulate a single layer at the point the data is accessed (our apps are all written already to deal with complex data as someting that can exist as a pixel in a band of raster imagery). The second approach would be to put the data all in one sample and signal this with an additional SampleFormat value (5 = Complex as a real, imaginary IEEE floating point pair). This of course has its own problems. I don't think that the fact that most non-complex savvy apps would be able to display anything is much of an argument because most of the mainstream apps don't handle floating point anyway (or even unsigned 32-bit all that well). I don't see yet, however, why you would need an additional type (13, 14) as you suggested. The only thing that I could see you might be thinking is the SMinSampleValue and the SMaxSampleValue, but would that be a complex type? (we typically calc stats and compute lookup tables for visualization of complex based on the magnitudes of the complex numbers which are simply single or double precision floating point values). Is there a standard way of ordering complex numbers other than by their magnitudes? I don't think it is possible to produce universally understood complex without adding to the spec and I am interested in the outcome of this. Max