gzipped images in SIAP 1.0

[Thomas McGlynn]

Hi Roy,

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.

	Tom

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
> http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.5
> 
> (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?
> 
> Roy
> 
>