gzipped images in SIAP 1.0
tam at milkyway.gsfc.nasa.gov
Tue May 22 08:29:16 PDT 2007
I'm not sure I agree with this summary. The best solution
does not involve the SIA protocol at all. A user with
an SIA service that provides gzip compressed data would return
a URL of the form http://host/dir/xx.fits.gz but should
in principle provide HTTP headers indicating a content type
of FITS and a content encode of GZIP compressed. I don't
know if and how this is set for standard HTTP servers like Apache
but I suspect it can be done. I don't know if it typically <is> done.
For CGI generated data this is very easy to do.
Nor do I think tile-compressed data is a significant issue. I don't believe
usage is widespread, and there is always a danger that a given
provider may supply a data type that the reader cannot handle.
E.g., I imagine that many users would have trouble reading
a BITPIX=64 image even though I think that's further along the
standards track than tiled compression.
Roy Williams wrote:
> I am hearing three opinions (I think)
> (1) SIAP specification remains unchanged and gzipped images are declared
> non compliant. Unfortunately this means fewer VO-compliant data
> services, more broken registry records, and less happiness in the world.
> (2) The SIAP spec is changed to allow a new field may be in the table
> with |ucd=*"VOX:Image_Encoding"*|, and if present, the value may be
> "gzip", or "compress" etc as written here
> (3) The compression may be FITS tile-compressed; this does not affect
> the SIAP protocol, but clients may get a surprise if their FITS reader
> library is not up to date. Which versions of cfitsIO and wcslib do I
> need to be able to read tile-compressed FITS?
More information about the dal