|
|
Thread Tools | Display Modes |
#1
|
|||
|
|||
[fitsbits] Start of the 'INHERIT' Public Comment Period
On Fri 2007/03/23 16:06:53 EDT, William Pence wrote in a message to: FITSBITS 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 |
#2
|
|||
|
|||
[fitsbits] Start of the 'INHERIT' Public Comment Period
On Thu, 12 Apr 2007, Mark Calabretta wrote:
"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). 1) I doubt the authors of a convention (which, once again, is NOT a standard) can "require" anything. The convention is all just a recommendation, or even less, a suggestion. 2) WCS keywords could/should be considered "array specific keywords" "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. Here I agree. The sentence does not belong to the convention. One of the purposes of convention documentation should be to allow the user/reader to identify a file as respecting a particular convention, ideally in an univocal manner. Then, IF the file is univocally identified as obeying a convention, and the reader supports it, it shall interpret the file according to the convention. If the reader does not support it, it interprets it as a "plain"file. If the file is not identified as obeying a convention, ditto. About self-containment, it seems to me similar e.g. to the requirement of page independence in postscript (which is good practice but can be and is violated sometimes). Should the STANDARD say something about this (food for IAUFWG or the IAUFWG Technical Panel). "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? E.g. creating a data structure with the keywords in the current extension, another with the keywords in the PHDU, and appending to the current one the kwds in the PHDU which are not overridden in the current. Sort of when configuration files in /etc, /usr/share, /usr/local and ~user are combined. "... 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. Commentary keywords are intended as human readable documentation, not for computer processing. So they'd appear only once. For the rest it seems normal sound practice for me to report in the PHDU computer-readable (keywords) information relevant to all extensions, e.g. the instrument configuration of the observation. Of course each extension should contain its own necessary data (so "array related" might include not only NAXIS* BSCALE WCS but also e.g TFIELDS and TT* keyowrds). If a file contains, say, n image extensions which are respectively 512x512, 512x1024 and 512x768, it seems silly (and incorrect) to me have NAXIS1=512 only in the PHDU. If a file contains n binary tables, each with 5 columns but with names and types different, it is also silly to have TFIELDS=5 only in the PHDU (which, BTW, is not a binary table) If a file contains n binary tables with different number of columns, but one of them (say the second) is always the same, it is equally silly having TTYPE2='energy' only in the PHDU. -- ---------------------------------------------------------------------- is a newsreading account used by more persons to avoid unwanted spam. Any mail returning to this address will be rejected. Users can disclose their e-mail address in the article if they wish so. |
Thread Tools | |
Display Modes | |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
[fitsbits] Start of the 'INHERIT' Public Comment Period | Thierry Forveille | FITS | 0 | April 6th 07 10:44 PM |
[fitsbits] Start of the 'INHERIT' Public Comment Period | Robert Hanisch | FITS | 0 | April 6th 07 06:20 PM |
[fitsbits] Start of the 'INHERIT' Public Comment Period | William Pence | FITS | 0 | April 6th 07 06:00 PM |
[fitsbits] Start of the 'INHERIT' Public Comment Period | Rob Seaman | FITS | 0 | April 6th 07 04:03 PM |
[fitsbits] Start of the 'INHERIT' Public Comment Period | William Pence | FITS | 0 | March 23rd 07 08:06 PM |