Handling keywords in FITS extension HDUs

Data Management
#1

There is a registered FITS keyword INHERIT

http://fits.gsfc.nasa.gov/registry/inherit.html

that controls whether an HDU inherits the keywords in the PDU. It is quite clear that they should if INHERIT=T, and should not if INHERIT=F

The BNL MEFs that Merlin and I have been looking at for monocam do not include an INHERIT keyword, but are clearly expected to inherit the PDU as each amp is in its own HDU bereft of any useful information such as exposure time.

What is the common expectation in the community when reading files like this? I don’t think that cfitsio or pyfits merges the headers (but I’m not sure they obey INHERIT either; we do). What should we do in afw – the current behaviour is causing problems?

#2

This doesn’t answer the question yet, but out of curiosity, what does Astropy do?

That is, what does the fitscheck command line tool from Astropy say about the file?

This might help answer what the community does in general. Astropy has additional docs on what they consider ‘fixable’ FITS standards violations: http://docs.astropy.org/en/stable/io/fits/api/verification.html#fix

#3

Definitely worth checking with astropy: I’m not sure that it’s used much outside the keyword proposers.

#4

ftncheck (as provided by anaconda 2.1.0, I think 0.4.2) tells me nothing useful, except that I found a bug:

$ fitscheck --checksum none --compliance /nfs/lsst2/photocalData/data/monocam//calib/dark/113-03_dark_bias_002_20140709225639.fits
EXCEPTION '/nfs/lsst2/photocalData/data/monocam//calib/dark/113-03_dark_bias_002_20140709225639.fits' .. 'PrimaryHDU' object has no attribute '_checksum'
1 errors

fitscheck tells me that reading e.g. extension 2 ignores the primary header. Adding INHERIT = T doesn’t change this behaviour.

#5

Astropy may not have updated the FITS checking code, but FYI that version of astropy is from Sep 23, 2014.