[fitsbits] New DUMP FITS extension

[Doug Tody]

Hi Maren -

This is a good question, for which there is no real answer.  One can do
these things, so the question becomes is it good practice?  What should
we recommend?  One answer would be that if it is array data of any
dimension it is reasonable to store it as an "image" (that is, a
regularly sampled, multidimensional array, with associated metadata
and possibly a WCS, flux units, etc.).  This can include 1-D data
such as a spectrum.

If an IFU produces a spectral data cube then this qualifies as a
3-D image.  If the IFU produces a bunch of 1-D spectra however,
this is probably best stored as a table of 1-D spectra, e.g., as
in the Euro-3D format (which is based on binary table).  One can do
things like pack the extracted spectra into the rows of a 2-D image,
but aside from being a trick this is problematic when it comes to
things such as associated error information or quality flags.

I think these cases are all different than for example, storing a
general file blob such as a GZIP as a 1-D byte "image".  For that we
want a general container which can say something about the contents,
rather than pretend it is an Image object just because we can store
it in an array.  I would rather add a general container extension for
this purpose.

	- Doug



On Thu, 16 Aug 2007, Maren Purves wrote:

> Doug,
> 
> Doug Tody wrote:
> > 
> > My personal view on the more general question is that Image should
> > only be used for image data, and it is a trick to stuff arbitrary
> > binary blobs in something called an Image. 
> 
> But every multi-object spectrograph and every IFU does that on-chip
> already. And consider raster-scanning in radio/submm.
> Where do you want to draw the line?
> 
> Aloha,
> Maren
> _______________________________________________
> fitsbits mailing list
> fitsbits at listmgr.cv.nrao.edu
> http://listmgr.cv.nrao.edu/mailman/listinfo/fitsbits
>