[fitsbits] Start of the 'INHERIT' Public Comment Period

[Thierry Forveille]

> Indeed, this is getting off topic, but we might want to have a separate
> discussion sometime about the "FITS data model" and perhaps even how
> to map this into more flexible serializations or storage mechanisms.


> (also, as a matter of history, FITS began as an image transport format,
> and tables and image extensions came much later).
>
Yeah, I am uunfortunately old enough to remember that (even enough
to have written random groups) ;-). Tables were the first extension
I think, then the image extension.

> The basic FITS model provides a keyword table (PHU or some other form
> of empty image kludge), an N-dimensional image object, a table, plus
> a simple general container (the MEF).  We can aggregate instances of
> these three basic objects in a container, an associate them in some
> fashion to model more complex objects, such as instrumental datasets.
> Usually this is done by defining a convention, e.g., using custom
> keywords in the PHU and/or extensions.
>
Well, that's one way of looking at it. The alternate perspective
that I am arguing for is that everything should go into one table
extension, with images as either multiple entries in one row
or entries in successive rows. Essentially, that's the perspective
that's taken by the Green Bank convention for sets of radioastronomical
spectra.

> One can argue that Table can contain anything including an image,
> but the regularly sampled N-Dim Image case is so important that it
> deserves its own class.  If nothing else, this is still required to be
> able to efficiently store and access large data arrays.
Actually, storage and access inside a binary table is perhaps
slightly more difficult to get right, but it is just as efficient
as using image extensions (if anything margiinally more efficient,
due to less block padding).

> In addition,
> the basic Image object is much simple than Table, and much existing
> code can do useful things with a FITS image, but cannot do anything
> with a FITS table.
>
That's definitely a factor that needs consideration. For DENIS
we used a large binary table to store stripes of 180 1kx1k images,
but ended often/usually working through a filter that extracted one
image to a FITS file because a tool expected that. On the other
hand, that format did provide very robust consistency (stable
header items in extension header, variable ones as element of
the data rows, and nothing ever duplicated).


> Within VO, FITS is still the preferred format for image data, whereas
> VOTable is often used instead of FITS for table data.  One could
> argue that the FITS Image is the most successful and widely used part
> of FITS, and even today provides a better mechanism for storing and
> manipulating regularly sampled data arrays than anything existing
> alternative.
>
Simpler and most successful for sure. Better, that depends on what your 
goals/criteria are :-)