[fitsbits] XTENSION = 'FITS' proposal

[William Pence]

Perry Greenfield wrote:
> 
> Viewed with the mindset that the library does not need to interpret the
> structure, and support merely consists of being able to access end-point
> extensions there are two approaches I would offer:
...
> 2) Have the library in effect convert the 'FITS' extension header into
> a standalone null data extension. Then the file can be read
> sequentially and have something sensible to return for each element it
> finds. Would this really be hard to implement?  To be more explicit,
> the code that examines the next extension finds XTENSION='FITS', Either
> moves NAXIS value elsewhere (different keyword) or otherwise provides a
> means of indicating no data present. It then moves on to the next
> extension. All the nested extensions are simply interpreted this way in
> a sequential process. User software can reconstruct the grouping by
> using the sizes of extensions. Unlike the GROUP_BEGIN proposal, there
> are "group" keywords available. To make writing of such files possible,
> the library must allow a nonzero NAXIS1 for the XTENSION='FITS' case
> only.  Perhaps I'm wrong, but these seem like minimal changes to
> support sequential access.

In fact it would probably require only a small change to the CFITSIO library
for it to recognize XTENSION = 'FITS' as a special case and then ignore the
NAXIS and NAXIS1 values and proceed as if NAXIS = 0.  This then would
provide sequential access to all the HDUs within the groups.  One would also
have to permit extensions beginning with "SIMPLE = T" instead of XTENSION =
'IMAGE'.

However, this effectively becomes  identical to the GROUP_BEGIN and
GROUP_END alternative proposal.  The XTENSION = 'FITS' extension serves
exactly the same role as the GROUP_BEGIN extension. "Group" keywords (that
apply to all members of the group) could be written in either case.  The
only difference is that in one case the length of the group is given by the
NAXIS1 keyword in the 'FITS' extension, and in the other case the end of the
group is marked by the GROUP_END extension. 

Given that these 2 ways of grouping HDUs are so similar and provide the same
functionality, why go to all the trouble of inventing a new type of
extension with XTENSION = 'FITS'?  The GROUP_BEGIN/GROUP_END alternative
requires no changes to any FITS libraries, and requires no changes to the
FITS Standard to be officially recognized. 

Having said this, I don't particularly like either of these proposals
because they are both limited to just grouping HDUs within a single file. 
Why not use the existing Jennings et al. 'Grouping' proposal, which can be
used to group HDUs within a single file, but also provides much more general
support for grouping HDUs in multiple files?

-Bill
-- 
____________________________________________________________________
Dr. William Pence                          pence at tetra.gsfc.nasa.gov
NASA/GSFC Code 662         HEASARC         +1-301-286-4599 (voice)     
Greenbelt MD 20771                         +1-301-286-1684 (fax)