[fitsbits] FITS MIME RFC ready for review

[Arnold Rots]

I may have misunderstood.  Are you saying that a file of type
image/fits without a primary data unit (i.e., some NAXISi=0) should be
considered an empty image?

I don't have a problem with that.
What I would have a problem with is a prescription that says: if the
MIME type is image/fits and there is no primary data unit, look for an
extension of type IMAGE, or something like that.

  - Arnold

Tom McGlynn wrote:
> I'd planned on waiting till I got home before discussing this, since
> my previous message came from there and I could reuse some text
> but it sounds like the discussion has already begun...
> 
> 
> I've not been privy to the FITSMIME discussion, but
> it seems to me that image/fits is a reasonable MIME type to use when
> the data of interest is a simple primary HDU.  Here are a couple of
> examples of how I thought this might be used.
> 
> SkyView currently uses the image/x-fits extension for its MIME type
> and it allows the user to specify the pixel dimensions of the image
> to be returned.  Somewhat to my chagrin it currently fails silently
> if the user specifies a Nx0 pixel array.  However in fixing this bug
> I'd anticipate that what we're likely to do is to provide the user
> with a primary image with no pixels but with the header associated
> with the position and survey they user requested.  As it stands I
> cannot legally return this image using the same MIME type as all of the other
> images SkyView generates.  So both SkyView and the invoking program
> need to be able to handle two different MIME types.  In practice I would
> imagine that distinction would be ignored by developers so 0 pixel images
> would be returned as Image/FITS regardless of what the rules say!
> 
> Another example is supposing a users has a time sequence of images with
> a specific instant associated with each image.  A user may request
> an the images within some interval.  If there are N images found in
> the interval and images have some common a x b format, the data might
> appropriately be returned as an a x b x N image -- a FITS equivalent
> to an animated GIF.  If no images are found a return of an a x b x 0 image
> may be the most natural return format.  Again, it seems strange to
> constrain this value to be in Application/FITS while all others
> are legal Image/FITS.
> 
> I don't see Image/FITS as a moribund MIME type supported purely for
> historical interest, but as a strong suggestion to the reader that the primary HDU is
> of interest.  I think that's similar to what Steve is suggesting.
> 
> 
> 	Regards,
> 	Tom McGlynn
> 
> Steve Allen wrote:
> > On Tue 2003-06-03T15:24:09 -0400, Arnold Rots hath writ:
> > 
> >>Uh, does this mean that you retract your earlier proposal to change
> >>MUST to SHOULD or is it meant to strengthen the argument?
> >>
> >>If the latter, then I would argue that we should not put the cart
> >>before the horse.  SIAP is a prototype and we should not design a
> >>standard on the basis of usage in a prototype interface.
> > 
> > 
> > I do not retract the change from MUST to SHOULD, but I would very much
> > like to know whether the VO community thinks that "application/fits"
> > alone serves their current and future needs.
> > 
> > I neglected to mention the existing non-astronomical applications
> > which currently also use what is effectively "image/fits".
> > The semantics of FITS files with the standard keywords is currently
> > very limited.  The grammar the existing standard keywords consists of
> > NOUNs and ADJECTIVEs.  Is there any standard keyword that functions as
> > VERB?
> > 
> > The absence of keywords that describe what to do with the data and
> > metadata in a FITS file is already contrary to the notion embodied by
> > most other MIME types.  One thing that the MIME type "image/fits" can
> > do is to allow the server to inform a client that it should be
> > acceptable to hand the incoming FITS file to a "simple" image browser
> > like gimp or xv.
> > 
> > In any case, this dearth of VERBs is not going to be remedied without
> > significant effort on the part of the FITS community.  I believe that
> > we need a MIME type sooner than that.  In the interim two MIME types
> > may be a partial remedy.
> > 
> > Note that the IANA rules do permit the MIME media type registrations
> > to be amended at a later date.  Is the risk of having to refine the
> > registrations later greater than the urgency with which they are
> > needed now?
> > 
> > --
> > Steve Allen          UCO/Lick Observatory       Santa Cruz, CA 95064
> > sla at ucolick.org      Voice: +1 831 459 3046     http://www.ucolick.org/~sla
> > PGP: 1024/E46978C5   F6 78 D1 10 62 94 8F 2E    49 89 0E FE 26 B4 14 93
> > 
> > _______________________________________________
> > fitsbits mailing list
> > fitsbits at listmgr.cv.nrao.edu
> > http://listmgr.cv.nrao.edu/mailman/listinfo/fitsbits
> > 
> > 
> 
> 
> _______________________________________________
> fitsbits mailing list
> fitsbits at listmgr.cv.nrao.edu
> http://listmgr.cv.nrao.edu/mailman/listinfo/fitsbits
> 
--------------------------------------------------------------------------
Arnold H. Rots                                Chandra X-ray Science Center
Smithsonian Astrophysical Observatory                tel:  +1 617 496 7701
60 Garden Street, MS 67                              fax:  +1 617 495 7356
Cambridge, MA 02138                             arots at head-cfa.harvard.edu
USA                                     http://hea-www.harvard.edu/~arots/
--------------------------------------------------------------------------