# Handling keywords in FITS extension HDUs **URL:** \ **Category:** Data Management\ **Created:** [April 29, 2016, 10:46pm UTC](https://www.rubin.community/t/handling-keywords-in-fits-extension-hdus/745 "2016-04-29T22:46:26Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![RHL](https://sea2.discourse-cdn.com/flex002/user_avatar/www.rubin.community/rhl/32/25_2.png) [@RHL](https://www.rubin.community/u/RHL)\ **Post date:** [April 29, 2016, 10:46pm UTC](https://www.rubin.community/t/handling-keywords-in-fits-extension-hdus/745/1 "2016-04-29T22:46:26Z")
There is a registered FITS keyword INHERIT > [Registered FITS Conventions](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? ---
**Author:** ![jsick](https://sea2.discourse-cdn.com/flex002/user_avatar/www.rubin.community/jsick/32/672_2.png) [@jsick](https://www.rubin.community/u/jsick)\ **Post date:** [April 29, 2016, 11:10pm UTC](https://www.rubin.community/t/handling-keywords-in-fits-extension-hdus/745/2 "2016-04-29T23:10:25Z")
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](http://docs.astropy.org/en/stable/io/fits/usage/scripts.html#module-astropy.io.fits.scripts.fitscheck) 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](http://docs.astropy.org/en/stable/io/fits/api/verification.html#fix) ---
**Author:** ![parejkoj](https://sea2.discourse-cdn.com/flex002/user_avatar/www.rubin.community/parejkoj/32/138_2.png) [@parejkoj](https://www.rubin.community/u/parejkoj)\ **Post date:** [April 29, 2016, 11:43pm UTC](https://www.rubin.community/t/handling-keywords-in-fits-extension-hdus/745/3 "2016-04-29T23:43:03Z")
Definitely worth checking with astropy: I’m not sure that it’s used much outside the keyword proposers. ---
**Author:** ![RHL](https://sea2.discourse-cdn.com/flex002/user_avatar/www.rubin.community/rhl/32/25_2.png) [@RHL](https://www.rubin.community/u/RHL)\ **Post date:** [May 2, 2016, 8:36pm UTC](https://www.rubin.community/t/handling-keywords-in-fits-extension-hdus/745/4 "2016-05-02T20:36:31Z")
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. ---
**Author:** ![jsick](https://sea2.discourse-cdn.com/flex002/user_avatar/www.rubin.community/jsick/32/672_2.png) [@jsick](https://www.rubin.community/u/jsick)\ **Post date:** [May 2, 2016, 10:33pm UTC](https://www.rubin.community/t/handling-keywords-in-fits-extension-hdus/745/5 "2016-05-02T22:33:30Z")
> [@RHL](#): > > ftncheck (as provided by anaconda 2.1.0, I think 0.4.2) Astropy may not have updated the FITS checking code, but FYI that version of astropy is from Sep 23, 2014.