Message-ID: 900805FA5A6FD31180BA009027786C2F054494@atlex01.erdas.com
To: "'Antonio E. Scuri'" <scuri@tecgraf.puc-rio.br>, tiff@olympiakos.com
Subject: RE: Complex Floating Point
From: "Martinez, Max" <max.martinez@erdas.com>
Date: Fri, 31 Mar 2000 13:07:23 -0500
Sender: owner-tiff@olympiakos.com


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
> > 
> 

