gzipped images in SIAP 1.0

[Mark Taylor]

On Wed, 23 May 2007, Rob Seaman wrote:

>> as I understand it tile-compressed FITS images are stored in a BINTABLE
>> extension (hence not the PHDU), so they should properly be described
>> as application/fits and not image/fits.
>
> The point I was trying to make was that a tile compressed FITS files remains 
> an image.  It is represented (that is, "encoded") as a bintable.  Any FITS 
> can be application/fits.  An image/fits says "I represent a single image".  A 
> content encoding could then be applied to that to turn the stream of bytes 
> into anything else, including (potentially) a bintable.

I understand that point, and 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.  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.
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.

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".  By all means lobby
for an update of RFC4047 to include tile-compressed FITS files
as legal instances of image/fits.

Mark

-- 
Mark Taylor   Astronomical Programmer   Physics, Bristol University, UK
m.b.taylor at bris.ac.uk +44-117-928-8776 http://www.star.bris.ac.uk/~mbt/