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