[fitsbits] gzipped images in SIAP 1.0

[Rob Seaman]

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 here:  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