🚀 go-pugleaf

In article <DWELLS.92Nov5190043@fits.cv.nrao.edu>
dwells@fits.cv.nrao.edu (Don Wells) writes:
>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.

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@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.

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 @ Deimos.Caltech.Edu, Pearson_T @ caltech.edu
BITNET/EARN:               TJP @ CITDEIMO
NSI-Decnet (SPAN):         Deimos::TJP or 15237::TJP
Telephone:                 +1 818 356-4980
FAX:                       +1 818 568-9352