[fitsmime] reaction to the draft?

[Arnold Rots]

Here are some comments.  I must confess that I have not read all mail,
so some of this may already have been discussed.

Section 4.2:
Should, I think, define a PHDU and point out its unique
characteristics.
This section also mentions table formats but should point out two
unique properties of these tables:
- the data may be in ASCII or in binary format
- cells may contain scalars or (multi-dimensional) arrays (vectors)

Section 4.3:
Stability is also strengthened by the fact that many astrophysical
archives store their data in FITS files.

Section 5, first text paragraph:
I suggest deleting the reference to SIAP: prototypes that may or may
not survive do not lend any strength to the case for a permanent
standard.

Section 5.1, Additional information:
Should define an "empty PHDU"
Under what an applications SHOULD handle, it may help to explicitly
mention tables.  Most likely, this will be the bulk of the use for
this MIME type, after all.

Second example:
Somehow, I'd like to give this more prominence since it is THE crucial
archival format for all X-ray data.
And one might point that it represents effectively a sparse time
series as well as a sparse image, in most cases.

Section 5.2, Recommendations for application writers:
I'd suggest rephrasing the second, third, and fourth paragraphs:

Note that an application intended to handle "image/fits" has
significantly more responsibility than an application intended to
handle, e.g., "image/tiff" or "image/gif".
FITS image arrays contain elements which typically represent the
values of a physical quantity at some coordinate location, rather than
the rendering of those pixels.
Consequently, they do not contain any rendering information in terms
of transfer functions or color look-up tables.  The application
should provide this functionality, either statically using a more or
less sophisticated algorithm, or interactive allowing the user various
degrees of choice.
In implementing the rendering functionality one should keep the
following in mind:
- The image values may be integers or reals; in some cases complex
numbers
- FITS provides for a mechanism to mark certain pixels as having
indefinite (invalid) values
- The dynamic range of the the pixel values may easily exceed that of
the display medium and the eye; logarithmic, square-root, or quadratic
transfer functions and histogram equalization techniques have proved
helpful

The data array in the PHDU  of a file described as "image/fits" MUST
have a dimensionality between 1 to 999, the boundaries inclusive,
indicated by the NAXIS keyword.  However, one should be aware that any
coordinate axis in a FITS image may only be one pixel long.  Hence a
two-dimensional imaging application would be quite capable of
displaying, for instance, a four-dimensional image (NAXIS=4) whith two
degenerate coordinate axes of length one pixel.

Three-dimensional images (NAXIS=3 without degenerate axes) are of
special interest.  Inspection of the World Coordinate System (WCS)
keywords may indicate that one of the coordinates is time.  Writers of
applications intended to handle "image/fits" SHOULD consider
presenting such an image in a fashion akin to that used for an
animated GIF; however, they should consider offering the option of a
time-lapse sequence display for all three-dimensional images since it
is an effective technique for visualizing three-dimensional data.


I hope this is constructive,

  - Arnold


Steve Allen wrote:
> The Internet Draft to register MIME types for FITS has benefitted from
> several good suggestions during the past few weeks.  It is still at
> http://www.ucolick.org/~sla/fits/mime/
> along with the ancillary documentation about the process.  I hope to
> announce the draft to fitsbits/sci.astro.fits in a while as a general
> call for comments prior to beginning the formal proceedings to get
> clearance from the FITS community, prior to submitting the draft to
> the internet community.
> 
> Reviews and comments about the draft from the VO community would be
> most welcome, for I remain concerned that the draft may not adequately
> address those needs.
> 
> --
> Steve Allen          UCO/Lick Observatory       Santa Cruz, CA 95064
> sla at ucolick.org      Voice: +1 831 459 3046     http://www.ucolick.org/~sla
> PGP: 1024/E46978C5   F6 78 D1 10 62 94 8F 2E    49 89 0E FE 26 B4 14 93
> _______________________________________________
> fitsmime mailing list
> fitsmime at listmgr.cv.nrao.edu
> http://listmgr.cv.nrao.edu/mailman/listinfo/fitsmime
> 
--------------------------------------------------------------------------
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                             arots at head-cfa.harvard.edu
USA                                     http://hea-www.harvard.edu/~arots/
--------------------------------------------------------------------------