gzipped images in SIAP 1.0

[Rob Seaman]

Roy Williams wrote:

> I would like to know if it is possible for a compliant SIAP to  
> return *compressed* FITS images. I note that some so-called SIAP  
> services have already been built where the image access URL (the so- 
> called acref) ends in .fits.gz, and so I expect that these are  
> gzipped fits images. However, the standard seems to say that this  
> is non-compliant[2].

Sorry, I don't know the answer to your specific question.  However, I  
might suggest that compression should be addressed in a broader  
context, VO-wide.

In particular, a ".fits" file may itself already be tile-compressed.   
We find Rice tile compression to be superior to gzip for our data  
sets in all key regards:  file size, time to compress, time to  
decompress.  There is also better on-the-fly support for tile  
compression than for gzip in CFITSIO (and potentially in other  
astronomical FITS libraries and utilities).  There is going to be  
significant pressure for the VO to support tile compressed formats.

> I am asking because I am writing client code, and I want *only*  
> fits files, no jpegs or anything like that. Currently it just  
> checks for a format of "image/fits" and rejects anything else. Is  
> this too harsh?

If compression has not previously been considered in the VO MIME  
discussions, it should be now.  This seems like an orthogonal  
question that might logically be expressed something like "image/fits/ 
gzip", if this were possible.

One has to believe that formallly your approach is correct, however,  
and that a ".fits.gz" file cannot be considered an "image/fits"  
type.  Note, however, that this is not true of a tile compressed FITS  
image, which is a bintable - but is also an image - and certainly  
remains FITS, however its nature is interpreted.

> -- If somehow the answer is yes, that gzipped images *can* be  
> returned by a SIAP, can somebody recommend a MIME type to use?     
> Would it be application/x-gzip?

Boy - this seems to sacrifice the entire utility of the FITS MIME types.

> -- Does the client need to parse the URL? (i.e. look for ending in
>    .fits.gz or .fit.gz or .FITS.gz or all the other combinations)

...and this seems to miss the entire point of a MIME type in  
general.  (This is similar to the "Is it XML?  Or is it Memorex?   
discussions about Params in VOEvent.)  A MIME type should protect you  
from having to do such up-front parsing/classification.

> -- Does anyone remeber the intention of the comma-delimited list of  
> MIME types?     Should  my code look for "application/x-gzip,image/ 
> fits"
>    Or maybe the other way around?

Ah!  The UCD gambit!  Watch out - this is vulnerable to the Sicilian  
defense.

Doesn't this just imply a list of separately acceptable types, that  
is:  gzip OR fits - not gzip AND fits?  Disjunction, not conjunction  
or some other laundry list.  Radio buttons, not checkboxes?  (And a  
strict exclusive-OR relationship seems implied by the choice between  
application/, image/, etc.)  Like I said, this seems a broader  
discussion than SIAP.

Rob