Subject: World Coordinate System proposal

From: dwells at fits.CV.NRAO.EDU (Don Wells)
Date: Fri, 6 Nov 1992 00:00:43 GMT

A special session was held on FITS WCS [World Coordinate System]
issues yesterday at the ADASS-92 meeting in Boston. The session was
well attended, and it was clear that there is considerable interest in
defining and implementing interoperable WCS implementations.  Bob
Hanisch distributed copies of a paper which he and I prepared in
February 1988. This paper documented the conclusions reached during a
WCS workshop held in Charlottesville in January 1988; it should be the
starting point for a new round of discussions of WCS issues. Anyone
who was not in the WCS session yesterday and who wants a copy of the
paper will find it in the anonymous-FTP server fits.cv.nrao.edu
[192.33.115.8] in directory /FITS/Documents:

     101705 Nov  5 10:12 FITS_wcs88.ps
      21856 Nov  5 10:07 FITS_wcs88.tex
--

Donald C. Wells             Associate Scientist        dwells at nrao.edu
National Radio Astronomy Observatory                   +1-804-296-0277
520 Edgemont Road                                 Fax= +1-804-296-0278
Charlottesville, Virginia 22903-2475 USA            78:31.1W, 38:02.2N

---

From: sla at umbra.UCSC.EDU (Steve Allen)
Date: 6 Nov 1992 21:31:05 GMT

In article <DWELLS.92Nov5190043 at fits.cv.nrao.edu>
dwells at fits.cv.nrao.edu (Don Wells) writes:
>Bob Hanisch distributed copies of a paper which he and I prepared in
>starting point for a new round of discussions of WCS issues.

In looking over this paper I am left asking a question about the
CRPIX1 and CRPIX2 values at the point of tangency on the sky.

The question boils down to another question:  Are FITS images representing
binned data or sampled data?  How do you tell?

By binned data I mean that pixels are represented by adjacent rectangular
regions and that the value of the pixel represents some kind of integral
(i.e., of the surface brightness of the sky) of a pixel response function
which is nearly uniform over the entire rectangle.

By sampled data I mean that pixels are represented by point samples within
each rectangle, or more precisely, that the pixel response function can be
thought as being very much smaller than the inter-pixel spacing.

In sampled data it is reasonable to think of the "middle" of the pixel as
having an integral coordinate.  In binned data there is some variance of
convention, but many people consider that the "middle" of a pixel has
a half-integral location (e.g., the boundaries between pixels are integral).

There are some applications where the distinction between sampled and binned
data should be made in order to assure a more rigorously correct
interpretation.  In either case, it is important to tell the next user of
this data which convention of pixel numbering is used to specify the
CRPIX values.

For the sake of this WCS proposal, which convention is being used?
_______________________________________________________________________________
Steve Allen          | That was the equation!         |   sla at lick.ucsc.edu
UCO/Lick Observatory | Existence!...Survival must     | If the UC were opining,
Santa Cruz, CA 95064 | cancel out programming! -- Ruk | it wouldn't tell me.

---

From: hanisch at stsci.edu (Bob Hanisch, ST ScI)
Date: Fri, 6 Nov 1992 22:12:11 GMT

In article 1deo6pINNlj9 at darkstar.UCSC.EDU, sla at umbra.UCSC.EDU (Steve Allen) writes:
> etc....

This issue was discussed during the meeting in Boston, and it was agreed
that the proposal has to be revised to indicate the conventions being
used.  The consensus was that for FITS, pixel (1,1) is the pixel in the lower
left-hand corner of an image and that for the purpose of the WCS, this
pixel represents data from 0.5 to 1.5 in pixel coordinates.  This clarification
will be added to the proposal.

---
Robert J. Hanisch                       Tel. (410)338-4910   Fax. (410)338-5090
Space Telescope Science Institute       NSI: hanisch at stsci.edu [130.167.1.2]
3700 San Martin Drive                   DECNet: STSCIC::HANISCH [6549::] 
Baltimore, MD  21218  USA               Bitnet: hanisch at stsci

---

From: sla at umbra.UCSC.EDU (Steve Allen)
Date: 6 Nov 92 23:30:21 GMT

>will be added to the proposal.

It will be very important to add this clarification.

>From my experience I infer that the astronomical community has
pretty much established that the first pixel in an array is the pixel with
the integer tag 1 which has floating point boundaries 0.5 and 1.5
(middle of pixel is integral).

This is significantly different from the common practice in computer graphics
(CG) where the first pixel in an array is the pixel with
the integer tag 0 which has floating point boundaries 0.0 and 1.0
(edges of pixel are integral).

If the astronomical community will be variant in this way it will be
essential to clearly document the definition of a pixel.  There will
undoubtedly be some astronomical programmers who cling to the more widely
used CG definitions of pixels, and interoperation of their software with
other software will be difficult if these underlying assumptions are not
made explicit in the documentation.
_______________________________________________________________________________
Steve Allen          | That was the equation!         |   sla at lick.ucsc.edu
UCO/Lick Observatory | Existence!...Survival must     | If the UC were opining,
Santa Cruz, CA 95064 | cancel out programming! -- Ruk | it wouldn't tell me.

---

From: cur at rlstar.bnsc.rl.ac.uk (Malcolm J. Currie)
Date: Sat, 7 Nov 92 19:52:43 EST

------- Start of forwarded message -------
From: cur at rlstar.bnsc.rl.ac.uk (Malcolm J. Currie)
To: fitsbits-request at fits.CV.NRAO.EDU
Subject: Re: World Coordinate System proposal
Date: Sat, 7 Nov 1992 19:39:15 GMT

>(middle of pixel is integral).

In Starlink we use pixel indices that, by default, start at 1.  However,
our definition of pixel co-ordinates has the first pixel (index 1)
between floating-point boundaries of 0.0 and 1.0, since we regard pixels
as binned data.  Isn't it more logical to start at the origin rather
than 0.5? 

Our NDF data structure permits axis widths to be defined in addition to
axis centres.  So for sampled data the widths could be made much smaller
than inter-pixel spacing. 

- -----------------------------------------------------------------------
Malcolm J. Currie   |     Span: RLVAD::CUR
Starlink Project    |     Janet: CUR at UK.AC.RUTHERFORD.STARLINK
                    |     +44-235-821900 x6735
- -----------------------------------------------------------------------
------- End of forwarded message -------

---

From: mcdowell at head-cfa.harvard.edu (Jonathan McDowell)
Date: 10 Nov 92 14:22:07 GMT

>From article <1dev6dINNnkp at darkstar.UCSC.EDU>, by sla at umbra.UCSC.EDU (Steve Allen):
> 

[... Does the center of pixel (1,1) have the coordinates (1.0,1.0) or (1.5,1.5)???]

> made explicit in the documentation.

I agree that clear documentation is crucial. Here at SAO we have always
used the "CG" definition (center of bottom corner pixel is at "0.5");
IRAF uses  mostly "1.0" but not always; and historically FITS has left
it up to the user to include a comment card to document how the
coordinate system used by CRPIX is mapped on to the data array. We've
run into awful trouble in the past by getting confused about this. I'm
happy with the "1.0" choice, but we need to make it as explicit as
possible. Make the distinction between the number of a pixel (an integer
n-tuple) and the coordinates of its center (a real n-tuple) explicit,
even if the choice of convention makes them numerically equal. 

I hope the standard will use lots of small and simple words and some
examples (like: "The first data item in the array section is considered
to be the pixel whose number is (1,1,1,...1). The number of the next
pixel is (1,1,1,...,2). The  coordinate value corresponding to the
center of the pixel numbered (1,1,...1) is (1.0,1.0,...,1.0)."

 .-----------------------------------------------------------------------------.
 |  Jonathan McDowell                 |  phone : (617) 495-7176                |
 |  Harvard-Smithsonian Center for    |                                        |
 |   Astrophysics                     |                                        |
 |  60 Garden St, MS4                 |                                        |
 |  Cambridge MA 02138                |  inter : mcdowell at urania.harvard.edu   |
 |  USA                               |  inter : mcdowell at cfa.harvard.edu      |
 '-----------------------------------------------------------------------------'

---

From: tjp at eccles.caltech.edu (Tim Pearson)
Date: 10 Nov 1992 14:33 PST

I support the recommendations of Hanisch and Wells in their "World
Coordinate Systems" document. It is not intended to provide a complete
and final solution to this problem, but to establish conventions that
will simplify the exchange of datasets that share similar
characteristics.  There are many possible ways of making images, and
they may involve many different possible coordinate systems; but there
are certain types of images that are common in astronomy for which it is
desirable to establish uniform conventions.

The recommendations address three issues:

(1) The FITS standard conventions for rotated images are just plain
wrong: you do not represent a rotation of an N-dimensional image by N
rotation angles, one for each dimension. This has made the CROTAn
keywords virtually useless. The document establishes a rational
interpretation of CROTA1 and CROTA2 for two-dimensional images (ignore
CROTA1!); and suggests a better method (CDiiijjj) for the general linear
transformation between pixel numbers and world coordinates. This new
method is applicable to all images which are sampled on a regular grid
(with equal-size pixels) in the world-coordinate system.

(2) Astronomical images are samples of the celestial sphere, for which
no regular gridding (with equal-size pixels) is possible. The document
establishes conventions (which can be extended) for images that are
obtained by regular gridding of a plane projection of part or all of the
sphere. It is appropriate to include information about the projection in
the CTYPE keywords, because in such cases the coordinate that is sampled
at equal intervals is not DEC (declination) but a function of both RA
and DEC. I do have some reservations about the use of these conventions
with rotation, however: e.g., in an Aitoff projection with tangent point
not on the equator, I am not sure that the two axes can be meaningfully
called GLON-AIT and GLAT-AIT or RA---AIT and DEC--AIT. Additional
clarification is needed as to precisely how to calculate sky coordinates
of a pixel in such cases. 

It is worth emphasizing the distinction between world coordinates
(linear functions of pixel number, derived by applying CRVAl, CRPIX,
CDELT, and CROTA; _or_ the CDiiijjj matrix) and sky coordinates (two
angles derived from the world coordinates by an additional non-linear
transformation specified by CTYPE). I think this distinction might best
be made by putting the description of the CDiiijjj convention in a
separate section, before the description of conventions for projections
of the celestial sphere.

(3) The conventions proposed for coordinate reference frames (equinox,
epoch, etc.) should be adopted as widely as possible to clear up a lot
of confusion and misunderstanding in this area.

In addition to the proposals of the Hanisch-Wells document, I think it 
would be useful to adopt the following conventions. I do not think they
should be part of a legalistic "standard", but I think they should be
strong recommendations to FITS writers.

(1) In the absence of any information to the contrary, FITS readers
should display two-dimensional images with the first pixel in the
lower-left corner, with the first axis increasing to the right and the
second axis increasing upwards. This would not preclude a program from
looking at the axis descriptions and overriding this convention (as AIPS
does for RA/DEC axis pairs), or the user from requesting a different
display. Uniform adoption of this convention would I think remove a lot
of the frustration involved when a program displays an image
"upside-down" or "back-to-front".

(2) The world-coordinates (x,y) of a pixel (i,j), computed according to
the FITS conventions from CRVAL, CRPIX, CDELT, CROTA apply to the
_center_ of the pixel. I agree with Eric Greisen that this is the only
rational choice. Assuming that the image P(i) is a discrete
representation of an idealized continuous function S(x), the
pixelization operation can be described mathematically (for the
one-dimensional case) as a convolution:

        +inf
P(i) = Integral F(x-i) S(x) dx
        -inf

where the convolution kernel F(x) would be delta function for an ideal
"sampling" operation (e.g., a radio aperture-synthesis CLEAN map); or
a top-hat function

F(x) = 1 (-0.5 < x <= 0.5)
       0 (otherwise)

for an ideal "binning" operation (e.g., a perfect CCD).

In practice F(x) is almost always going to be a symmetrical function,
and it seems sensible to choose the center of symmetry as the origin.

Tim Pearson, Astronomy Dept 105-24, Caltech, Pasadena, California 91125, USA
Internet:                  TJP  at  Deimos.Caltech.Edu, Pearson_T  at  caltech.edu
BITNET/EARN:               TJP  at  CITDEIMO
NSI-Decnet (SPAN):         Deimos::TJP or 15237::TJP
Telephone:                 +1 818 356-4980
FAX:                       +1 818 568-9352