[fitsmime] FITS Mime-Types for Mosaics

[Don Wells]

William Thompson writes:
 > My own thoughts on this are that "image/fits" and any
 > "image/fits-..." should be reserved for FITS images which one could
 > expect to be loaded into a generic image viewing program (such as
 > XV or LVIEW) which also handles other image types such as GIF and
 > JPEG.  To my mind, scientific processing, such as forming a mosaic
 > out of a series of images, is not appropriate for the "image/..."
 > MIME type.

I agree. The goal of registering the toplevel type 'image/fits' with
the IETF/IESG is to encourage the non-astronomy imaging tools to
support our most common type of image data.  (A surprising number of
them support us already.)

Note that an 'image/fits' file may have extensions, such as tables of
detected sources, but the idea is that 'image/fits' means that the
primary content of the file is an N-dimensional matrix in the PHDU.

 > MIME types should also be restricted to only those types which have
 > been officially recognized by the IAU, i.e. single HDU, random
 > groups, and the extensions IMAGE, TABLE, and BINTABLE.  Conventions
 > used by specific projects should not be incorporated until they're
 > recognized by the IAU.

Again, I agree. That was approximately my reasoning some years ago
when I proposed the short list of 'application/fits-*' types.

 > ..one for 2D images (image/fits)..

N-dimensional, not just 2-D.  3-D imagery are common, and will be even
more common in the future.  (Most computer systems sold today have 3-D
hardware acceleration -- the Dell computer on which I am entering this
text has an ATI 'Rage128' chipset, with software support on both Linux
and Windows.)

 > ..  I don't really see much utility in types such as
 > "application/fits-bintable" since the internal structure can be so
 > different from file to file..  (On the other hand, I could see that
 > the MIME types "application/fits-group", "application/fits-table",
 > and "application/fits-image" might have some utility.)..

I proposed the latter three categories with the idea that they would
have the following meanings:

* "application/fits-group" -- the primary content of the file is a
			      single random group structure, but there
			      may be extensions. 

* "application/fits-table" -- the primary content of the file is a
			      *set* of tables (TABLEs and/or BINTABLEs).

* "application/fits-image" -- the primary content of the file is a
			      *set* of IMAGE extensions, but there may
			      also be table extensions in the file.  

 > I don't know how I would handle a file with the mime type
 > "application/fits-mosaic", unless there were a universally
 > recognized way of encoding such data.

Because there is not yet an agreed convention for mosaics,
"application/fits-mosaic" is probably premature at this time, although
it may make sense in the future if/when such agreements are produced.

				 -=-

More generally, I wonder whether fine-grain classification of our
files might not be better achieved with a reserved keyword in the
primary header.  The keyword would have value strings coded according
to some convention.  Such a string could specify that an
'application/fits-image' file is an NOAO mosaic, or a DEIMOS mosaic,
or some other scheme for using a set of IMAGE extensions (plus table
extensions) to convey some sort of image data.  The same keyword, or
maybe an analogous keyword, would be used in 'application/fits-table'
files to say whether the content is a set of tables conveying an event
list from a high energy experiment, with the schema conforming to some
convention, or instead the content is a set of tables conveying radio
aperture synthesis fringe visibilities in conformance with the
FITS-IDI (Interferometer Data Interchange) convention. 

Usually the client-side implementation of MIME codes is that one
application code is associated with each code.  It seems to me that it
should be possible to code a simple program which could decide the
provenance and probable detailed type of a FITS file by examining the
headers, even in the absence of a keyword such as the one discussed in
the previous paragraph, and which could then decide which of a set of
application programs will be used to process each individual file.
The classification program would then invoke the proper application.
I.e., if a 'application/fits-table' file is an event list, invoke a
HEASARC or CHANDRA or XMM etc. application, and if it is fringe
visibilities, invoke Classic-AIPS or Miriad or GILDAS etc.  So, while
I think that a classification keyword might be a good thing, I don't
think that it is absolutely necessary in order to get effective
interchange, and I don't think that we need a big set of MIME codes
for all of the detailed types of FITS files. 

-Don
-- 
  Donald C. Wells      Scientist - GBT Project        dwells at nrao.edu
                    http://www.cv.nrao.edu/~dwells
  National Radio Astronomy Observatory                +1-434-296-0277
  520 Edgemont Road,   Charlottesville, Virginia       22903-2475 USA
       (DCW is often in Green Bank, West Virginia, at +1-304-456-2146)