gzipped images in SIAP 1.0
seaman at noao.edu
Tue May 22 06:17:37 PDT 2007
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.
Sorry, I don't know the answer to your specific question. However, I
might suggest that compression should be addressed in a broader
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/
> Or maybe the other way around?
Ah! The UCD gambit! Watch out - this is vulnerable to the Sicilian
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.
More information about the dal