[fitsbits] start of Public Comment Period on the INHERIT convention

Steve Allen sla at ucolick.org
Wed Jul 1 15:19:43 EDT 2015


On Wed 2015-07-01T11:18:00 -0700, Steve Allen hath writ:
> The optical CCD instruments at Keck are not constrained to have the
> same readout geometry for every IMAGE extension in their
> multi-extension FITS files.
>
> See the tartan/patchwork image example here.
>
> http://www.ucolick.org/~sla/fits/mosaic/panes/phduNoted.html

The multi-extension FITS file depicted in the example above is an
extreme example of what can be done, not what should be done, and
not what is typically done.

I now head back to the question of including INHERIT in the standard.

The multi-extension FITS files from Keck DEIMOS, HIRES, and now also
LRIS inherited their basic structure from the NOAO mosaic.  The
individual IMAGE extensions in those FITS files do not contain all the
metadata, and they do not stand alone.  A single spectrum extends
across multiple IMAGE extensions, so a single IMAGE is not complete
even for the pixel data of one object.  Without the metadata both from
the PHDU (describing the telescope and instrument) and from the TABLE
XHDUs that are appended after the IMAGE XHDUs (describing the slitmask
design) it is not possible to get science out of the pixel data.

Whereas we are effectively relying on the conventions of the INHERIT
keyword, we did not choose to use the INHERIT keyword.  The usage in
the FITS files from DEIMOS, HIRES, and LRIS is sensible, legal, and
not part of the FITS standard.  I do not object to making INHERIT part
of the standard.  I also do not see the need to add the complexity of
INHERIT to the FITS standard.

--
Steve Allen                 <sla at ucolick.org>               WGS-84 (GPS)
UCO/Lick Observatory--ISB   Natural Sciences II, Room 165   Lat  +36.99855
1156 High Street            Voice: +1 831 459 3046          Lng -122.06015
Santa Cruz, CA 95064        http://www.ucolick.org/~sla/    Hgt +250 m



More information about the fitsbits mailing list