gzipped images in SIAP 1.0

[Andreas Wicenec]

On 22.05.2007, at 15:29, Thomas McGlynn wrote:

> Isn't it valid to refer to a compressed FITS file with the header:
>
>    Content-type: Image/FITS
>    Content-encoding: GZIP


Yes, I agree, that's the correct way of doing it and that was also  
what we have envisioned
when the FITS mime-type proposal was created, else we would need a  
different mime-type for
every allowed encoding.

Andreas

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