Re: [fitsbits] Start of the 'INHERIT' Public Comment Period
- From: Mark Calabretta <mcalabre@xxxxxxxxxxxxx>
- Date: Thu, 12 Apr 2007 13:07:58 +1000
On Fri 2007/03/23 16:06:53 EDT, William Pence wrote
in a message to: FITSBITS <fitsbits@xxxxxxxx>
A document describing this convention and a sample FITS file that uses
it are available for public review and comment from the FITS registry
web page at
http://fits.gsfc.nasa.gov/fits_registry.html
My comments only refer to the documentation of the convention, not the
convention itself.
The document states:
"It is recommended that this inherit convention be used only in
FITS files that have a null primary array (e.g., with NAXIS = 0) to
avoid possible confusion if array-specific keywords (e.g., BSCALE
and BZERO) were to be inherited."
If this is the way that INHERIT has always been used then it should be
required, not "recommended" (inheriting from a non-null primary HDU
would be asking for trouble, especially concerning WCS keywrds).
Also, while recommended usage may assist human interpretation, it is
unhelpful for software which can't assume that any recommendations have
been followed and so must be completely general.
"If the INHERIT keyword is not present, nothing should be inferred about
whether the inherit convention should apply or not because the FITS
standard says nothing regarding the relationship of keywords in the
primary header to those in an extension."
This statement is contentious. It is widely understood that FITS HDUs
must be self-contained, whether or not that is stated explicitly in the
standard. Basically this statement tries to excuse the exploitation of
a loophole in the standard.
"When an application reads an extension header with INHERIT = T, it
should merge the keywords in the current extension with the primary
header keywords, ..."
What does "merge" mean here? A simple way to picture keyword
inheritance is to think of appending the extension header onto the
primary header (as a character array) and feeding the lot into a header
parser that accepts the last occurrence of any repeated keyword.
"... with the exclusion of the mandatory keywords, and any COMMENT,
HISTORY, and blank keywords in the primary header."
If COMMENT and HISTORY keywords are not propagated then there should
also be some statement that extension headers must contain a full
complement of COMMENT and HISTORY cards whether or not they duplicate
those in the primary header.
General:
The FITS WCS standard defines default values for WCS keywords that are
omitted from a header. The document should discuss how the INHERIT
convention interacts with the omission of such keywords.
Although it is reasonable to discuss the relative merits and
deficiencies of the convention compared to other alternatives, much of
the content of the first paragraph of the section entitled "Practical
Considerations" seems to deal with one particular implementation. As
such it should either be omitted or recast into a discussion of the way
that it should be implemented.
As another practical consideration, serial readers (e.g. tape or
internet download) have no way of knowing in advance whether the primary
header will be required for later use by an extension that inherits it.
Therefore, in order to implement this convention, they would need to
cache the primary header from ANY general FITS file in case it later
turns out to use the INHERIT convention.
Mark Calabretta
ATNF
.
- Follow-Ups:
- Re: [fitsbits] Start of the 'INHERIT' Public Comment Period
- From: Lucio Chiappetti's NoSpam Newsreading account
- Re: [fitsbits] Start of the 'INHERIT' Public Comment Period
- Prev by Date: [fitsbits] Start of the ''Hierarchical Grouping' Public Comment Period
- Next by Date: Re: [fitsbits] Start of the 'INHERIT' Public Comment Period
- Previous by thread: Re: [fitsbits] Start of the 'INHERIT' Public Comment Period
- Next by thread: Re: [fitsbits] Start of the 'INHERIT' Public Comment Period
- Index(es):
Relevant Pages
|
Loading
