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 Received on 2007-05-22Z15:18:07