[fitsbits] Associating ancillary data with primary HDU

[Randy Thompson]

On 5/9/14, 6:08 PM, "Rob Seaman" <seaman at noao.edu> wrote:

>Hi Bill,
>
>> I've been asked if there are any specific conventions for associating
>>ancillary 
>> data with primary data arrays.  The specific application is one where
>>the 
>> exposure time differs from pixel to pixel (something that can be done
>>with 
>> Active Pixel Sensors), but which could easily apply to other parameters
>>which 
>> vary between pixels.
>> 
>> 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.
>
>As others have suggested, you might consider a dateless primary HDU,
>though the original Image extension proposal had this whimsical language:
>
>>> {\tt NAXIS = 0} is not recommended since it would not make sense to
>>>extend a non-existing image with another image.
>
>At NOAO and elsewhere the opposite choice has been made since day one as
>providing a quite natural hierarchical structure to an MEF.
>
>(I¹d be interested in R. Thompson¹s comment on this ;-)
>

I can¹t say I remember where that suggestion came from, it sounds rather
funny today, 
but the original idea was to consider the image extension as ancillary to
the primary 
HDU. We frequently create FITS files today with NAXIS = 0, particularly
for spectra 
using binary table extensions.

I don¹t know if it was mentioned, but a small advantage to using a primary
HDU with 
an image extension is that you have 2 separate headers for metadata.

Randy