Subject: Re: FITS Coordinate Keywords

From: Lucio Chiappetti <lucio at ifctr.mi.cnr.it>
Date: Thu, 2 Sep 1993 10:01:00 +0200 (MET DST)

On Tue, 31 Aug 1993, William Pence wrote:

> This note describes the 3 different sets of coordinate system keywords
> that the HEASARC proposes to use within it's FITS files.  One of these
  [...]
> primary array).  Any comments, criticisms, or suggestions about these
> proposed sets of keywords are welcome.
> 

  Here are my 0.02 {currency_units}

> ---------------------------------------------------------------------------
> A.  Possible FITS Image Representations
> 
    Are you concerned here only with "true" images (counts vs detector x,y
    and/or counts vs ra,dec), OR ALSO with any z=f(x,y) representation
    (e.g. z=response matrix, x=input energy y=output channel ; z=chisquare,
    x=log NH y=spectral index ; etc. etc.) ?

    I will be concerned also of the second case       

> 
> 1.  Primary Array Coordinate Keywords
> 
> All the keywords listed here, except for the last CUNIT keyword,
> have been widely used in the FITS world and form the basis for
> the 2 other sets of derived keywords.  The CUNIT keyword has been
> added for generality in cases where the axis units are not already
> implied by the CTYPE value.

  This is the WCS convention set, isn't it ?
  This convention is essentially geared to celestial images and uses CTYPEm
  in a very specific way. 
  However, it looks to be backward compatible with the basic FITS standard,
  in which CTYPEm can be anything (e.g. "Log NH" and "Spectral_Index") and
  one can use CRPIX,CRVAL,CDELT to manage a linear transformation.
 
  [an extension to WCS to handle LOGARITHMIC transformation would be
  useful]

  I would not forget BUNIT in the keyword list (that is, the units on
  the z axis)

  By the way ...
  in X-rays one usually has :

  *   detector x,y "raw" coordinates
  *   detector x,y "corrected" coordinates ( = raw if no distortions)
      arbitrary x,y rebinned pixels
  *   celestial coordinates using WCS

  I generally assume that one may be interested only in the asterisked
  quantities (usually detector coords). DOES EVERYBODY AGREE ON THIS ?
  E.g. for an 8192x8192 detector, with a 273x273 images,
  anchored at pixel 2731,2731 and zoomed by a factor 10 one will have,
  conforming with the conventions :

 (J) NAXIS1       =          273
 (J) NAXIS2       =          273
 (C) BUNIT        = PHOTONS
 (C) CTYPE1       = XPIX                 or name tbd
 (C) CTYPE2       = YPIX                 or name tbd
 (R) CRPIX1       =  1.00000
 (R) CRPIX2       =  1.00000
 (R) CRVAL1       =  2731.00
 (R) CRVAL2       =  2731.00
 (R) CDELT1       =  10.0000
 (R) CDELT2       =  10.0000

> 
> 2.  BINTABLE Array Coordinate Keywords
> 
> In this case the image is represent by a vector column in a Binary Table.

  If I understand correctly the case mentioned here is the one in which
  each element of the table is a 10x20 image.
  I fail to understand why one may want to do this, and I'll certainly
  not use nor encourage use of columns with TDIMensionality greater than 1.
  
  Therefore I have no comments on the proposed convention since I will
  never make use of such complex format.

  The cases I'm considering are :

      table elements are scalar
      (e.g. one column contains energy, and the other contains counts/s)
      in this case the TUNITn are sufficient

      table elements are 1-d vectors
      (e.g. one column contains scalar time, and the other contains an
      entire spectrum, or the counts in several bands)
      In this case at the moment the description of what is on the
      single "depth" axis is undefined.
      Can your convention cope with it ? Is a different convention better ?
      Or does one instead need an ad-hoc convention case-by-case ?

> 3.  Table List Coordinate Keywords.
> 
> In this case the image is not represented as an array, but instead each
> pixel (or perhaps only each non-zero pixel) is listed separately on
> multiple rows of a FITS table.  Each row has a column for the X

  It looks like that what you have in mind here is a photon list where
  the coordinates are not detector x,y as usual, but directly RA and DEC.
  (Your convention is required, beyond usual TUNiTn, ONLY in such case,
  did I get it right ?)

  Does the transformation (projection) used to display a pre-accumulated
  image (which a photon list is not) really matter ?
  Can't you (if you really want to store RA and DEC) convert detector
  x,y to RA,DEC using the satellite attitude (better if stored in the file
  header, EVEN if one is keeping the file as detector x,y ... but you 
  already have a separate convention for that) and leave any projection
  to the image accumulation/display software ? 

-----------------------------------------------------------------------------   
Lucio Chiappetti - IFCTR/CNR Milano        |         U N I C U I Q U E          
via Bassini 15 - I-20133 Milano - Italy    |          System  Manager           
Internet: LUCIO at IFCTR.MI.CNR.IT            |           FORTUNAE SUAE            
Decnet:   IFCTR::LUCIO (39610::LUCIO)      |                                    
Bitnet:   <please do not use any more>     |                                    
-----------------------------------------------------------------------------

---

From: bschlesinger at nssdca.gsfc.nasa.gov (BARRY M. SCHLESINGER)
Date: 2 Sep 1993 09:21 EDT

In article <Pine.3.05.9309020911.B20224-d100000 at poseidon.ifctr.mi.cnr.it>, Lucio Chiappetti <lucio at ifctr.mi.cnr.it> writes...
>			... 
>			...

I'm not sure what is intended in the verbal description -- that is,
what the raw pixel values in the FITS files are supposed to be, and
what the physical interpretation is supposed to be.  However, the set
of keywords would be interpreted as follows: 

The FITS file constains a 273 x 273 array (values of NAXISn).  The
axes represent pixel numbers. FITS array member (1,1), from the value
of CRPIXn, corresponds to physical pixel unit (CRVALn) values
(2731,2731). ("The value field [of the CRVALn keyword] shall contain a
floating point number, giving the value of the CTYPEn keyword at the
reference point CRPIXn." __NOST _Definition of FITS_).  The increment
per index number in the FITS file is 10; thus, FITS array member (2,2)
would be coordinate (2741,2741). 

(By the way, the quotes around the character string keywords were 
left out in the example.)

				Barry Schlesinger
				NSSDC/NOST
				FITS Support Office

---

From: Lucio Chiappetti <lucio at ifctr.mi.cnr.it>
Date: Thu, 2 Sep 1993 17:13:10 +0200 (MET DST)

> >  conforming with the conventions :

     etc. etc.

> (2731,2731). 
> The increment
  Yes, this a 273x273 "image pixel" image rebinned with zoom factor 10
  from a portion of the full FOV of an 8192x8192 "detector image" (actually a
  spare ROSAT PSPC in focus of SAX FM mirrors at Panter Long Beam facility),
  with the lower corner at (2731,2731).
  This way one can always refer to (meaningful) detector coords and not to
  (meaningless) "image pixels"

> left out in the example.)
   Yes, this the output of an header lister (and actually the original
   file is not even FITS), but the meaning was clear anyhow

---

From: thompson at serts.gsfc.nasa.gov (William Thompson)
Date: 2 Sep 93 14:08:41 GMT

>On Tue, 31 Aug 1993, William Pence wrote:

	(stuff deleted)

>  not use nor encourage use of columns with TDIMensionality greater than 1.

Well, from my point of view, multiply dimensioned columns in FITS binary tables
are a must.  Without it, binary tables just aren't much use to us, and without
binary tables, FITS files just aren't much use except for fairly simple data
sets.  (Of course there is the IMAGE extension, but the thought of having
files with 30-50 seperate image extensions all related to each other makes me
shiver.)

>      Or does one instead need an ad-hoc convention case-by-case ?

The case I'm considering has the following properties:

	* Multiple simultaneous measurements in up to 32 wavelength regions.

	* Each data array can have up to four dimensions (2 spatial, spectral,
	  temporal) depending on the configuration of the instrument.

	* The data set will also include associated information about the
	  observation--e.g. mechanism positions, pointing, exact times.  These
	  data may also be multidimensional.  For example, in a pinhole raster
	  scan, each X, Y point will have a separate time.

The best way that I can see to put this data into a FITS file is to use binary
tables with the TDIM convention for the multidimensional aspect.  I have also
considered the Green Bank convention and the new IMAGE extension.

Bill Thompson

---

From: pence at tetra.gsfc.nasa.gov (William Pence)
Date: Fri, 10 Sep 93 18:11:07 EDT

[This note from Bob Payne may be of general interest, so I'm reposting
it and my reply to the whole group].

----- Begin Included Message -----