gzipped images in SIAP 1.0

[Rob Seaman]

On May 22, 2007, at 8:29 AM, Thomas McGlynn wrote:

> 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.

A tile compressed file is a legal FITS bintable.

The VO and archives in general are too prone to falling into the trap  
of planning against current usage rather than expected future usage.   
Tile compression is superior in many regards and will likely gain  
market share rapidly once a certain critical mass is reached.

On May 22, 2007, at 8:48 AM, Alberto Micol wrote:
> In line with Tom. At ST-ECF the HST proxy (CGI) uses:
>
> Content-type: XXXXXX
> Content-Encoding: x-gzip
> Content-Disposition: attachment; filename=your.fits.gz
>
> where XXXXXX could be:
>
>   A.- application/octet-stream
>   B.- image/fits          (as per RFC 4047 see section 5.2)
>   C.- application/fits    (as per RFC 4047 see section 5.1)
>
> A. is used to download on disk
> B. is used to display a PHDU NAXES >=2 image
> C. is used to display any other FITS (e.g. a multi-extension fits  
> file)
>
> I guess that tile-compression involves multiextension fits files,  
> correct?

Yes.

> In that case image/fits is not valid, and application/fits is to be  
> used.

That is one option, or one could regard such data as an image (which  
it is), as FITS (which it is) and as an encoding (which it is).  That  
is, we could arrange to add "fits-tile-compress" (or whatever) to the  
list of encodings, e.g.:

	http://www.iana.org/assignments/http-parameters

To return to something Norman Gray said:

> If you wanted to distribute a gzip file -- ie, the client is  
> neither expected nor permitted to _transparently_ unzip it -- then  
> you'd use application/x-gzip, or whatever the appropriate MIME type  
> for a zipped file is; but that's not what you want, I don't think

In the case of SIAP (and the VO in general) what is the client  
expected to do with such files?  Is the assumption that the value of  
the compression is purely for transport, not for client storage  
efficiency?  In that case might not a transfer encoding be what is  
desired, not a content encoding?

One more advantage of FITS tile compression is that files need not be  
decompressed to be used, including to access header metadata.   
Perhaps we should expect a surge of popularity of application/fits.

Rob