gzipped images in SIAP 1.0 (fwd)

[Steve Allen]

On Wed 2007-05-30T10:28:27 -0700, Patrick Dowler hath writ:
> > This feature allows compressed files to be passed through the protocol
> > unchanged, and manipulated by applications in compressed form.  I think
> > generic whole-file compression of this sort is a separate issue from
> > something like tiled images with Rice compression; the latter is an
> > internal feature of FITS.  We might enable it at the protocol level
> > in the future, but currently there is no attempt to support this.
>
> The way Rice compresion (a la cfitsio) works, such a resource must be declared
> as either
>
> Content-Type=image/fits
>
> IFF this compression to bintable form is part of the FITS standard (and the
> content is a 2 image) and it must be declared as
>
> Content-Type=application/fits
>
> if it is not in the FITS standard (eg it is an arbitray fits file). There is
> no "external" encoding involved (there could be, eg you could have rice on
> the inside and gzip on the outside) and despite that probably being dumb it
> is legal and easily characterised with the 2-3 http headers mentioned here.

While we were drafting the FITS MIME RFC we asked questions about the
exact dividing line between image/fits and application/fits.
At that point the responses indicated that the VO community had not
really gotten to the point of being sure.  For that reason we left
a little room for interpretation of image/fits as applying to something
other than a 2-d classical FITS data array in the PHDU.

I find it a bit contrary to the Jon Postel spirit of being
"conservative in what you send" to contemplate declaring a Rice
tile-compressed FITS file as "image/fits".  While that compression
does exist in CFITSIO (which is a big point in its favor), the FITS
standard is not defined by an implementation, but by a document.
I do not see that compression as more than a recognized FITS
convention, and that's very different than being part of the standard.

I would tread carefully until it is clear whether and when the FITS
community at large is prepared for that sort of usage.

--
Steve Allen                 <sla at ucolick.org>                WGS-84 (GPS)
UCO/Lick Observatory        Natural Sciences II, Room 165    Lat  +36.99855
University of California    Voice: +1 831 459 3046           Lng -122.06015
Santa Cruz, CA 95064        http://www.ucolick.org/~sla/     Hgt +250 m