Message-ID: 900805FA5A6FD31180BA009027786C2F054488@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 10:14:28 -0500
Cc: "'warmerda@home.com'" <warmerda@home.com>
Sender: owner-tiff@olympiakos.com


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
> 


