more on FITS and VO

[Mike Fitzpatrick]

> > On Wed, 26 Nov 2003, Robert Hanisch wrote:
> 
> >> I've been asked to poll the VO community concerning the proposed FITS MIME
> >> type and a restriction that has been suggested:
> 
> >> A FITS file described with the media type "image/fits" MUST have a
> >> primary header and data unit (PHDU) which consists of at least one
> >> pixel.
> >
> > so that instead of "MUST" it would read "SHOULD".
> 
> >>> Do you, or other members of the VO community, have any objections to
> >>> this change to the FITSMIME proposal?  The effect of this one word
> >>> change (from 'must' to 'should') would be to allow null images (with
> >>> one or more NAXISn keywords = 0) to be given the mime type

	My first reaction was that if it was a MUST then it wouldn't be
possible to send an MEF file without rewriting it to add a single pixel
(and it's extra record) to conform in this case, but the RFC says that
I'm allowed to use extensions for image/fits. If you read the mime RFC and
look at the definitions:

  application/fits
	A FITS file described with the media type "application/fits" may
      have an arbitrary number of conforming extension header and data
      units (XHDUs) which follow its mandatory primary header and data
      unit (PHDU).  The PHDU may contain zero or more dimensions with
      zero or more pixels along each dimension. 

  image/fits
        A FITS file described with the media type "image/fits" MUST have
      a primary header and data unit (PHDU) which consists of at least
      one pixel.  The FITS file MAY also have one or more conforming
      extension HDUs following the PHDU.
		:
	A FITS file described with the media type "image/fits" SHOULD be
      principally intended to communicate the single data array in the
      PHDU.  Among other things this means that "image/fits" SHOULD
      NOT be applied to FITS files containing mosaic images.

It would seem that in the first case you could send an MEF with NAXIS=0 in
the PHU, but for image/fits you would need to add a pixel for the PHU but
can still legally send extensions containing data.  So for image/fits I
SHOULD send only a SIMPLE FITS file but I MAY include extensions.  Why
even allow that in the first place?  Applications would still need to
figure out what to do with the extensions of an image/fits and data
providers would need to add the pixel or change the mime type, VO
consumers would need to be able to handle either the application/image
types as separate cases (or require a service to provide a particular mime
type) and figure out what to do with the data (e.g. skip the dummy pixel
record and deal with extensions or not).


> Note: NAXIS**n**, i.e. NAXIS1 or NAXIS2 etc.  
> 
> >>> "image/fits".  Without this change in wording this would not be
> >>> allowed, and such null images would have to be given the mimetype
> >>> "application/fits".  

	Not necessarily, it just means I'd have to pad the image.  From 
the above I can send extensions either way, but the one case I can think of
is in returning a FITS header with no data.  text/plain works just fine for
that and I can send headers with the actual NAXISn values without sending
data which wasn't found in a cutout, or couldn't be processed, or....
(I can also send an error message about failed data return as well and
apps don't need to figure out *why* there was no data).  I can still send
this as a legal image/fits with no data by setting NAXIS(n) appropriately.


> > This change sounds unhelpful.  Something with NAXIS=0 isn't an image; 
> > you can't display it in an image viewer.  Surely the point of
> > image/fits is to separate those datasets that can be passed to a
> > generic image-viewer from those where the receiving programme needs to
> > know the semantics of the data?

	Depends on the viewer, DS9 can take an MEF file with NAXIS=0
(or NAXISn=0 in the PHU) and display the image extensions just fine.  The
image/fits lets me send the data in extns but it might actually break
this particular viewer if I had a dummy-pixel PDU before them.  NAXIS=0
is more likely to break inline viewers such as those used in web browsers
where all the permutations of FITS are supported.


Bill Pence wrote:

> The intent of this subtle change is wording is to allow the "image/fits"
> mimetype to be legally applied to FITS files in which the Primary
> array has NAXIS greater than zero, and has one or more NAXISn keywords
> equal to zero, and thus contains 0 pixels,  e.g.,
>   NAXIS  =   2
>   NAXIS1 = 100
>   NAXIS2 =   0
> 
> Take for example a web site or service that returns 2-dimensional FITS
> images to the browser, with mimetype 'image/fits'.   Some people have
> argued that there could be times when the web site would need to return
> a zero pixel length image, e.g., the user might only want the FITS
> header information (metadata) without the image itself, or a zero pixel
> image might be returned if the requested image position was not available
> for some reason (outside of the area covered by a survey).  For whatever
> reason, some people have argued, there *might* be occasions where the 
> web service would need to return a zero pixel image, and in that case
> it would be more convenient, and less confusing to the end user, to assign
> 'image/fits' to the file, just like all the other images that it returns.

	But then it's not FITS!  According to the NOST standards doc
description of the "NAXISn Keywords"

	A value of zero for any of the NAXISn signifies that no data
	follow the header in the  HDU. If NAXIS is equal to 0, there
	should not be any NAXISn keywords

By adding a pixel we add a HDU and violate this statement, whether it's
a MUST or a SHOULD.

	It seems clearer to me to just disallow extensions entirely for
image/fits and use this only for compliant simple FITS files which can be
displayed by event he simplest viewer.  Anything with extensions where an
application may need to sort out the images from table, figure out a mosaic
layout, etc should be left to application/fits.  In any case, mime XXXX/fits
should at least be a legal FITS image.  I'm in favor of moving to SHOULD
if only because it means I'm no longer *required* to add the pixel.


-Mike