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 18:31 "Fwd: RE: Complex Floating Point", by Antonio E Scuri
This is only a forward of the previous messages. scuri >I think people are just getting half this conversation again >because I had subscribed to the TIFF list under a different >email address. > >Anyhow, I think, almost by definition, adding complex to TIFF >requires changing the spec. Otherwise there is no specified >way to put complex data into a TIFF file, only conventions. > >Which image attributes in the current TIFF spec do you see >being potentially complex values? Are you talking about >private tags? > > > -----Original Message----- > > From: Antonio E. Scuri [mailto:scuri@tecgraf.puc-rio.br] > > Sent: Friday, March 31, 2000 11:06 AM > > To: tiff@olympiakos.com > > Subject: RE: Complex Floating Point > > > > > > > > >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). > > >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. > > > > I agree with you. In fact my very first solution was to add a new > > SampleFormat value. It makes many things easier. > > > > I was just wondering if we can reach another solution > > without changing > > specs. As you can see this is much more "complex"... > > > > >I don't see yet, however, why you would need an additional > > type (13, 14) > > >as you suggested. > > > > This is because you can have image attributes (Tags) that > > have complex > > values. So also you will need to add values to the FieldType in the > > IFDEntry definition. > > > > scuri > > > > > > -----Original Message----- > > From: Martinez, Max > > Sent: Friday, March 31, 2000 9:14 AM > > To: 'Antonio E. Scuri'; tiff@olympiakos.com > > Cc: 'warmerda@home.com' > > Subject: RE: Complex Floating Point > > > > > > 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 > > > > > > > > > -----Original Message----- > > > From: Antonio E. Scuri [mailto:scuri@tecgraf.puc-rio.br] > > > Sent: Friday, March 31, 2000 5:34 AM > > > To: tiff@olympiakos.com > > > Subject: Re: Complex Floating Point > > > > > > > > > > > > >Also I would recommend some other file format for storing > > > stuff no-one is > > > >going > > > >to be able to read anyway. You are only fooling people by > > > making a file that > > > >looks readable, but turns out not to be. (this is just an opinion) > > > > > > In fact this effort is to try to make the image readable > > > by scientific > > > applications in near future. If they eventually decide to > > > implement some > > > sort of Complex Tiff images. > > > > > > scuri > > > > >