gzipped images in SIAP 1.0 (fwd)

[Patrick Dowler]

I completely agree - what matters is what the FITS standard document says. If 
rice compression of data into bintable is part of the standard, then I think 
the mimetype of a fits file should not change when this internal encoding is 
applied. In practice, one needs to tread carefully or users will do many 
things that don't work (client tools won't understand the fits file).

However, for consistency with HTTP, rice should not change the 
content-encoding either. As it stands right now, I think rice compression 
probably implies a mimetype of application/fits. That is a bit of a shame 
since now clients don't know if they will understand the fits file or not: I 
understand application/fits to be a superset, so at the download stage the 
server may well say that Content-Type=application/fits because in the general 
case that is all it knows for sure.


Pat

On Wednesday 30 May 2007 11:00, Steve Allen wrote:
> On Wed 2007-05-30T10:28:27 -0700, Patrick Dowler hath writ:
> > 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

-- 

Patrick Dowler
Tel/Tél: (250) 363-6914                  | fax/télécopieur: (250) 363-0045
Canadian Astronomy Data Centre   | Centre canadien de donnees astronomiques
National Research Council Canada | Conseil national de recherches Canada
Government of Canada                  | Gouvernement du Canada
5071 West Saanich Road               | 5071, chemin West Saanich
Victoria, BC                                  | Victoria (C.-B.)