[fitsbits] Associating ancillary data with primary HDU

[Lucio Chiappetti]

> On 5/9/14, 4:24 PM, "William Thompson" <William.T.Thompson at nasa.gov> wrote:
>
>> The simplest and most obvious approach would be to store the actual 
>> data in the primary HDU, and then store the exposure times in an 
>> extension with the same dimensionality.

On Fri, 9 May 2014, Randy Thompson wrote:

> This is actually the application that first prompted the Image extension 
> to be proposed as a FITS standard.

I was going to say something similar (actually I might have been confusing 
the two posters with same surname :-)) ... I remember image arrays with 
ancillary data (quality, bad pixels, fiducial marks) for IUE (perhaps even 
pre-dating usage of FITS ... didn't the old VICAR format have something 
like that).  The IMAGE extension was originally called IUEIMAGE when it 
still was a private proposed convention.

Therefore I consider the fact of having primary data and ancillary data in 
arrays of equal dimensionality a well established (and well 
understandable) usage.

Whether the primary data is in the PHDU ("HDU0") or the PHDU is dataless 
and it is in the first extension ("HDU1") is just a matter of taste.

The alternative (to add a further NAXISn increasing the dimensionality of 
the array to include "layers" for ancillary data) seems to me less "neat" 
(although it allows some space saving in header overheads), I've seen it 
sometimes used for 1-d spectra (stored in a NAXIS=2 array, where things 
like quality, background, gross vs net etc. are stored in further "image 
rows").  One can spend less time administering header kwds, but the 
resulting "documentation" is less neat. Could be acceptable for a local 
private usage, but less for a public long term archiving.

--
Lucio Chiappetti - INAF/IASF - via Bassini 15 - I-20133 Milano (Italy)
For more info : http://www.iasf-milano.inaf.it/~lucio/personal.html