[fitsbits] [fitsmime] New MIME-types-for-FITS RFC draft

Just a few fairly minor questions which probably reveal my great ignorance.

Concerning the issue of restricting image/fits to two non-degenerate
coordinate axes, are there any mimetypes in existence that deal with
multi-dimensional images? We're not the only ones who work with three
and more dimensional images. I would have imagined that there would
at least be one for 3-D.

There has been some back and forth on gzipping and identification of
tables. I just wondered whether that would be an area where the
optional parameters might come in handy.
I must admit that I am not so sure about gzipping - that should be
indicated by its own mimetype, really.
But it might be useful if application/fits could provide some clue as
to the way the file is to be used/interpreted.
In particular, we mainly produce FITS files with an empty primary
where the first extension is the "principal" extension. It might be
helpful to say: this FITS file consists of binary tables and you
really should first look in extension X - that's the principal, the
others are auxiliary.
HEASARC/OGIP adopted the concept of HDUNAMEi, a number of years ago,
in an attempt to categorize the tables that are in use. I don't know
whether one would go in that direction - to give the client some idea
of what's coming and to decide whether it can handle it.

- Arnold

--------------------------------------------------------------------------
Arnold H. Rots Chandra X-ray Science Center
Smithsonian Astrophysical Observatory tel: +1 617 496 7701
60 Garden Street, MS 67 fax: +1 617 495 7356
Cambridge, MA 02138
USA http://hea-www.harvard.edu/~arots/
--------------------------------------------------------------------------

Just a few fairly minor questions which probably reveal my great ignorance.

Concerning the issue of restricting image/fits to two non-degenerate
coordinate axes, are there any mimetypes in existence that deal with
multi-dimensional images? We're not the only ones who work with three
and more dimensional images. I would have imagined that there would
at least be one for 3-D.

There has been some back and forth on gzipping and identification of
tables. I just wondered whether that would be an area where the
optional parameters might come in handy.
I must admit that I am not so sure about gzipping - that should be
indicated by its own mimetype, really.
But it might be useful if application/fits could provide some clue as
to the way the file is to be used/interpreted.
In particular, we mainly produce FITS files with an empty primary
where the first extension is the "principal" extension. It might be
helpful to say: this FITS file consists of binary tables and you
really should first look in extension X - that's the principal, the
others are auxiliary.
HEASARC/OGIP adopted the concept of HDUNAMEi, a number of years ago,
in an attempt to categorize the tables that are in use. I don't know
whether one would go in that direction - to give the client some idea
of what's coming and to decide whether it can handle it.

- Arnold

--------------------------------------------------------------------------
Arnold H. Rots Chandra X-ray Science Center
Smithsonian Astrophysical Observatory tel: +1 617 496 7701
60 Garden Street, MS 67 fax: +1 617 495 7356
Cambridge, MA 02138
USA http://hea-www.harvard.edu/~arots/
--------------------------------------------------------------------------

Comments on the rfcFITS-20040312.txt:

1) As previously, my main comment/question relates to "Recommendations
for application writers" for application/fits.

What does it mean in practical terms to say that "An application
intended to handle "application/fits" SHOULD be prepared to
encounter..."? Specifically, does any utility currently exist that
can do something sensible with ANY general FITS file? E.g. I know
that 'fv' does a good job with BINTABLES, etc., but can it even list
pixel values for a 999 dimensional image? What about a random groups
file? Are there any others that even come close? The statement

"Complete interpretation of the meaning and intended use of the
data in each of the HDUs typically requires the use of heuristics
that attempt to ascertain which local conventions were used by the
author of the FITS file."

implies that a certain amount of black magic is required.

2) Do the lists of software packages on page 11 (and 15) really count as
*applications* that can handle "application/fits" (or "image/fits")?
When setting up a mailcap entry you need to specify the name of an
executable, e.g. 'xv' or 'fv' into which you can feed the file.
IRAF, AIPS, miriad, etc. do not fit the bill here, though certainly
they do contain some particular applications that can process some
specific types of FITS file.

3) The last paragraph on p17 should be merged into the first sentence of
"Additional information" on p16 to make it clear from the outset that
NAXIS is limited to 3 non-degenerate axes.

4) Is it reasonable for image/fits to preclude IMAGE extensions? Perhaps
a comment is in order.

Additional comments:

p4, Sect. 4.1: The term "lines" in the phrase "2880-byte blocks which
hold 36 80-character lines" is undefined. You could say "2880-byte
blocks that are divided into 36 records of 80 bytes".

ASCII blank (0x20) is not a "non-printing" character - printing
characters range from 0x20 to 0x7E inclusive. CR, LF, FF and TAB
are better described as print control characters. You could also
mention NUL which causes a lot of confusion for some software.

p9, Sect. 4.7: ATCA archive data is in the form of RPFITS which
decidedly is not FITS. (HIPASS data is in FITS.)

Grammar: "which" is routinely used incorrectly as a relative pronoun in
place of "that" (e.g. the first eleven occurences of "which" in the
document should be "that", the twelfth is the first correct usage).

Mark Calabretta
ATNF

Comments on the rfcFITS-20040312.txt:

1) As previously, my main comment/question relates to "Recommendations
for application writers" for application/fits.

What does it mean in practical terms to say that "An application
intended to handle "application/fits" SHOULD be prepared to
encounter..."? Specifically, does any utility currently exist that
can do something sensible with ANY general FITS file? E.g. I know
that 'fv' does a good job with BINTABLES, etc., but can it even list
pixel values for a 999 dimensional image? What about a random groups
file? Are there any others that even come close? The statement

"Complete interpretation of the meaning and intended use of the
data in each of the HDUs typically requires the use of heuristics
that attempt to ascertain which local conventions were used by the
author of the FITS file."

implies that a certain amount of black magic is required.

2) Do the lists of software packages on page 11 (and 15) really count as
*applications* that can handle "application/fits" (or "image/fits")?
When setting up a mailcap entry you need to specify the name of an
executable, e.g. 'xv' or 'fv' into which you can feed the file.
IRAF, AIPS, miriad, etc. do not fit the bill here, though certainly
they do contain some particular applications that can process some
specific types of FITS file.

3) The last paragraph on p17 should be merged into the first sentence of
"Additional information" on p16 to make it clear from the outset that
NAXIS is limited to 3 non-degenerate axes.

4) Is it reasonable for image/fits to preclude IMAGE extensions? Perhaps
a comment is in order.

Additional comments:

p4, Sect. 4.1: The term "lines" in the phrase "2880-byte blocks which
hold 36 80-character lines" is undefined. You could say "2880-byte
blocks that are divided into 36 records of 80 bytes".

ASCII blank (0x20) is not a "non-printing" character - printing
characters range from 0x20 to 0x7E inclusive. CR, LF, FF and TAB
are better described as print control characters. You could also
mention NUL which causes a lot of confusion for some software.

p9, Sect. 4.7: ATCA archive data is in the form of RPFITS which
decidedly is not FITS. (HIPASS data is in FITS.)

Grammar: "which" is routinely used incorrectly as a relative pronoun in
place of "that" (e.g. the first eleven occurences of "which" in the
document should be "that", the twelfth is the first correct usage).

Mark Calabretta
ATNF