[iaufwg] FITS conventions

[Doug Tody]

On Fri, 10 Feb 2006, Francois Ochsenbein wrote:
> Sure, but NAXIS=3 with BITPIX=8 and NAXIS1=4 does exactly the
> same thing, with the advantage that the associated metadata
> can explain the content. There is not FITS keyword to explain
> the content of the array -- in which keyword would you specify the
> RGB (or RGBE -- BTW what is the meaning of the 'E'?)
> Some systems use BTYPE (as an analogy with CTYPEn) but it's not
> a standard FITS keyword. And assuming a 32-bit array, is the red
> component represented by the higher or lower byte ?

FITS does not currently have a standard way to define the observable -
this is a fairly major ommission which should be rectified.  We can specify
the coordinates of a pixel but not the content of the pixel pointed to.
BTYPE is an example of what is needed, but as you say, it is not yet a
carefully worked out standard.  While we don't yet have a standard way to
do this in FITS, there has been some effort to define standard metadata to
describe the observable in VO, e.g., in the Characterization data model
and in SSA.  Maybe when this is mature enough we can map the appropriate
bits into one or more FITS keywords.  This general mechanism, which we
need in any case, could also provide a means to identify how rendered
pixels are encoded.

To me it seems clear that RGB encoding is a semantic type for the pixel
value, not a coordinate.  If we want work in terms of a physical spectral
coordinate we can already express a multi-band observation as a 3D cube
or MEF - but considerable effort is required to render that into RGB for
visualization purposes; they are not the same thing.

The details of RGB encoding at the byte level are best addressed by
following some standard graphics encoding.  All we are changing is how
the data is packaged in FITS, not the details of how rendered graphics
is encoded.  RGB, CYY, RGBE, etc. (there are lots of others) are all
standards for color encoding graphics.  If we do anything with rendered
graphics in FITS we should base it on such standards so that standard
graphics libraries can be used.


On Fri, 10 Feb 2006, Steve Allen wrote:
> There are examples of GIS applications using GeoTIFF images which are
> capable of overlaying property line databases with sidewalk location
> surveys to show who does and does not legally own the sidewalks in
> front of their houses, and then to combine these with aerial
> photography which allows the vector graphics survey data to overlay
> the imagery.
>
> Many of the FITS WCS projections prescribed by Calabretta are already
> supported by the GeoTIFF specification.  The translation between the
> two kinds of WCS would often be one-to-one.
>
> There is significant financial incentive for the GIS software to
> evolve and perform these sorts of things.  Some county recorders have
> begun to offer java-based applets which provide limited views into
> these databases for the sake of their constituents who have web
> browsers.  In this regard they are far ahead of the VO efforts,
> and it seems likely that situation will persist indefinitely.
>
> Although I am a bit reticent to imply that software which was
> developed to show where sewer lines run might be the best thing to
> use, I think the astronomy community might be better served by working
> out schemes for inter client communication between astronomical and
> GIS applications than by re-inventing such software and figuring out
> how to encode it in FITS.

I am sure this is all wonderful technology, and it might well be worthwhile
for us to evaluate this for use in appropriate applications.  However what
you are describing is quite complex, with serious software implications,
while merely adding a basic color capability to FITS is a fairly simple
matter.  Since we already have a widely used image format in use within
astronomy it is reasonable to ask why it cannot handle simple RGB rendered
images as well as raw flux values.  One could imagine for example, a FITS
science image, suitable for data analysis, including all our astronomy
specific metadata, which includes an RGB rendered and compressed preview
image of the same field, at the same scale, with metadata describing how the
RGB version was rendered.  This is not much different than using a Z-scale
algorithm to render the data in grayscale as we do routinely now, and could
be a useful capability to integrate into our image visualization tools.

Again, I think this is relatively low priority since other solutions
already exist.  But it is not an unreasonable feature to consider, could
be useful, and is also a relatively simple problem technically since the
graphics technology required already exists and is mature.

By the way, when this came up initially I checked a popular windows graphics
viewer app (IrfanView) to see if it supported FITS, and it does.  See

     http://www.irfanview.com/main_formats.htm

There are many others of course (xv, GIMP, etc.).  To the greater world
outside, FITS is already just another of many existing graphics file
formats.     - Doug