[fitsbits] Abuse of EXTEND keyword
Tim Pearson
tjp at astro.caltech.edu
Wed Aug 22 21:25:43 EDT 2007
> 1. The EXTEND keyword: Since the STEREO mission has started
> producing
> FITS files with EXTEND = F, it is too late to prohibit this usage
> in the
> FITS Standard (because of the "once FITS, always FITS" rule). The
> technical panel was not aware of this usage when it drafted the change
> to the EXTEND keyword definition (which was modeled after the
> definition
> of the BLOCKED keyword which can only have a T value, never F). The
> definition of the EXTEND keyword should probably be revised to explain
> what is meant by EXTEND = F, e.g., something perhaps like this:
>
> "If the EXTEND keyword value is the logical constant F, then this
> suggests that there are no extensions following the primary array.
> This keyword is only advisory, however, so extensions may
> follow the primary array even if EXTEND = F, but this is not
> recommended."
Perhaps I am misunderstanding or misremembering something here, but I
think EXTEND=T does actually have a purpose, and to suggest that both
EXTEND=T and EXTEND=F are merely advisory is crazy. We should not add
the words "nor does the absence of this keyword necessarily imply
that the file does not contain extensions" to the FITS standard.
The Grosbøl et al. paper (1988 A&A) said:
"Note that the presence of EXTEND=T in a primary FITS header ...
indicates that the file _may_ have extensions records and that any
special records will conform to the rules below." The important part
of this statement is the last bit, "any special records will conform
to the rules below" - meaning that the special records follow the
rules laid down for standard extensions, so that in particular the
size of each extension and hence the starting point of the next
extension can be determined.
Note that in this paper "special records" are any 2880-byte records
that follow the last record of the primary HDU. It is (or was) legal
FITS to put anything you like in these records, so long as EXTEND=T
is not present in the primary header.
If EXTEND is not present in the primary header, or if EXTEND is
present with any value other than T, then the reader should not
attempt to interpret any special records as standard extensions.
My guess (it's a long time ago) is that there were FITS files out
there that had special records that did not conform to the rules for
standard extensions, so the EXTEND keyword was needed. Or perhaps
Grosbøl et al wanted to leave open the possibility of other uses for
the special records, which would be indicated by different header
keywords.
So if we change the standard to make EXTEND optional in all cases, we
are effectively prohibiting use of the "special records" for anything
except standard extensions. This sounds like an incompatible change
to me.
The proposed FITS 3.0 standard talks about "special records"
following the last extension, although it "deprecates" them. I don't
think this is or ever has been legal FITS usage: if you have one
standard extension (and EXTEND=T), all the special records must be
standard extensions. If EXTEND is not T, then you can have special
records that are not standard extensions. The only legal options are:
Primary HDU with EXTEND=T, followed by zero or more standard
extensions (HDUs)
Primary HDU without EXTEND=T, followed by zero or more "special records"
If standard extensions are followed by additional special records,
there is no way to indicate where the last extension ends and any
"special records" begin, except to say that any records which don't
conform to the rules for standard extensions must be additional
special records. I don't think Grosbøl et al. intended that, and I
think their paper prohibits such additional special records.
- Tim Pearson
More information about the fitsbits
mailing list