gzipped images in SIAP 1.0
Guy Rixon
guyrixon at gmail.com
Wed May 30 23:34:04 PDT 2007
Supporting Rob's point, we _should_ use image/fits for single images
and we _should_ have a place in our protocols to state and control
content encoding that is separate from MIME type. Then the problem
goes away except for choosing out a token that means "tile
compressed". Until we put this into our protocols (or until the FITS
committees bless tile compression, or the heat death of the universe,
whichever comes first), our services _should not_ be emitting
compressed images.
Guy
On 31 May 2007, at 05:42, Doug Tody wrote:
> On Wed, 23 May 2007, Rob Seaman wrote:
>
>> The point I was trying to make was that a tile compressed FITS
>> files remains an image. It is represented (that is, "encoded") as
>> a bintable. Any FITS can be application/fits. An image/fits says
>> "I represent a single image". A content encoding could then be
>> applied to that to turn the stream of bytes into anything else,
>> including (potentially) a bintable.
>
> I agree, a tile compressed image is still logically an image, but
> probably we can only call it a image/fits once this feature becomes
> an actual FITS standard (as opposed to a convention).
>
> - Doug
More information about the dal
mailing list