gzipped images in SIAP 1.0

[Thomas McGlynn]

Isn't it valid to refer to a compressed FITS file with the header:

    Content-type: Image/FITS
    Content-encoding: GZIP

That would seem to appropriately separate the semantics of the data from
the encoding.  I think we may do this in some of our on-line data at the HEASARC.

	Tom


Rob Seaman wrote:
> 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
> 
>