gzipped images in SIAP 1.0

[Alberto Micol]

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?
In that case image/fits is not valid, and application/fits is to be  
used.
In which case, the RFC 4047 section 5.1 states that:
>    An application intended to handle "application/fits" SHOULD be able
>    to provide a user with a manifest of all of the HDUs that are  
> present
>    in the file and with all of the keyword/value pairs from each of  
> the
>    HDUs.
>
>    An application intended to handle "application/fits" SHOULD be
>    prepared to encounter XHDUs that contain either ASCII or binary
>    tables, and to provide a user with access to their elements.

Only God knows how many clients exist that do implement those SHOULDs...

In all cases, it is the acref (probably a CGI) that should do the job.
We should keep SIAP Simple...

Alberto
PS:
> RFC 2616: Use of program names for the identification of encoding  
> formats
>         is not desirable and is discouraged for future encodings.  
> Their
>         use here is representative of historical practice, not good
>         design. For compatibility with previous implementations of  
> HTTP,
>         applications SHOULD consider "x-gzip" and "x-compress" to be
>         equivalent to "gzip" and "compress" respectively.


On May 22, 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
>
> 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
>



--
Alberto Micol
Office: B67
Phone:  70354
Group:  SAT/VO & HST support



================================================================================================
This message and any attachments are intended for the use of the addressee or addressees only. The
unauthorised disclosure, use, dissemination or copying (either in whole or in part) of its content
is prohibited. If you received this message in error, please delete it from your system and notify
the sender. E-mails can be altered and their integrity cannot be guaranteed. ESA shall not be liable
for any e-mail if modified.
=================================================================================================