[fitsbits] gzipped images in SIAP 1.0

On May 23, 2007, at 7:48 AM, Mark Taylor wrote:

I agree it makes sense in human terms to view a tile-compressed
FITS file as an image. However the point of registering MIME types
is to standardize how applications are supposed to treat streams of
bytes that come labelled with particular MIME types.

I was speaking in the context of applications and autonomous
semantics. Applications exist for humans, of course - what a
computer needs and what a human needs are not disjoint.

Unless it's standardised somewhere that a tile-encoded BINTABLE is
supposed to be treated as an image (and how this is to be done)
you're asking the software to perform the artificial intelligence
task of guessing what the data provider had in mind.

While we're wondering where our jetpacks went (http://www.amazon.com/
Wheres-My-Jetpack-Amazing-Science/dp/1596911360), we might spend a
few cycles wondering who ran off with the AI from our laptops.

Tile compression is standardized he http://fits.gsfc.nasa.gov/
fits_registry.html#tiledimage

If you're talking about MIME types then the way that this kind of
standardisation is done is using the registration process described
in RFC2048.

One presumes that other MIME types also inherit the fundamental
description of the formats in question from external standards.

So, my understanding is that image/fits does *not* say "I represent
a single image", it says "I conform to the encoding rules in
RFC4047 section 5.2, or relevant updates to that document as
registered with IANA according to RFC2048".

I don't read it that way:

"A FITS file described with the media type "image/fits" SHOULD be
principally intended to communicate the single data array in the PHDU."

A tile compressed FITS image remains the expression of a single data
array. For example:

"This means that "image/fits" SHOULD NOT be applied to FITS
files containing MEF (multi-exposure-frame) mosaic images."

....as such an image is not. (Although tile compression can ALSO be
applied to MEF mosaic images.) Further:

"A FITS file described with the media type "image/fits" is also
valid as a file of media type "application/fits". The choice of
classification depends on the context and intended usage."

Just to emphasize that description: "the context and intended usage".

And even if we're focusing on the rote representation of complex,
multi-extension, FITS objects, these are also explicitly allowed:

"FITS files declared as "image/fits" MAY also have one or more
conforming XHDUs following their PHDUs. These extension HDUs
MAY contain standard, non-linear, world coordinate system (WCS)
information in the form of tables or images. The extension HDUs
MAY also contain other, non-standard metadata pertaining to the
image in the PHDU in the forms of keywords and tables."

All FITS can be conveyed as application/fits. The question of
whether they may also be conveyed as image/fits rests squarely on the
intent to represent a single N-dimensional image array. To the
extent that FITS syntax is discussed, extension HDUs are permitted
precisely for the purpose they are used in tile compression. In
general:

"Note that an application intended to render "image/fits" for viewing
by a user has significantly more responsibility than an application
intended to handle, e.g., "image/tiff" or "image/gif"."

That is - it is the responsibility of the application to remain
current with the evolving FITS standard. Presumably this is one goal
of the IAU registry of FITS conventions.

By all means lobby for an update of RFC4047 to include tile-
compressed FITS files as legal instances of image/fits.

I believe the single (hard enough) step of evolving the FITS standard
was sufficient. One does not then have to modify MIME standards
unless the intent of RFC4047 is significantly altered. The intent of
tile compression remains, however, to convey a representation of a
classic FITS image array.

My original question (on FITSBITS, anyway) was whether a content
coding was required. I'll here assert that unlike external filters
like gzip, no such explicit acknowledgment of a non-standard encoding
is required for tile compression, i.e., the default is correct:
"Content-encoding: identity".

A tile compressed FITS image is a FITS image.

Rob