[fitsbits] CRPIX clarification
Mark Calabretta
mcalabre at atnf.CSIRO.AU
Thu May 29 22:48:46 EDT 2008
On Thu 2008/05/29 08:45:21 CST, Eric Greisen wrote
in a message to: Jonathan McDowell <jcm at head.cfa.harvard.edu>
and copied to: fitsbits at nrao.edu
Dear Jonathan & Eric,
>Guys - the correct way to clarify some misunderstandings in the written
>standard needs to be determined. BUT, the issue of reference point was
I don't think that we have any significant points of disagreement. I
was simply responding to your (Jonathan's) statement that "the WCS
corresponds to the center of the pixel", in the particular context of
whether the definition of CRPIXja should have (or should have had) some
words referring to the "centre of the pixel".
My main point is that the WCS definitions should not refer to pixels
or voxels as finite squares, cubes nor anything with an extent and
consequently a centre. As I explained previously, in terms of Fourier
sampling theory what we call an "image" is actually a shah function.
All we need do is agree on a method of indexing the individual delta
functions in that shah function. We call this index the "pixel
coordinate" and we allow it to take fractional values for the purposes
of interpolation (when it makes sense). FITS has chosen a method that
matches these indexes with the way that arrays are indexed in Fortran,
i.e. each delta function is assigned an integral index starting at 1.
This is neither correct nor incorrect, it's simply the way it was done.
It makes implementation easier in Fortran, though in C you have to
remember to offset the array index by 1, and also that the first array
index changes slowest. Thus, distinguishing between pixel coordinates
and array indices allows everyone to agree that F(2,3) and C[2][1]
actually both refer to the delta function with pixel coordinate
(2.0,3.0). The distinction effectively provides one level of
indirection - which is enough to cause one level of misunderstanding!
>From what Jonathan says, there are other packages out there that index
the delta functions differently, apparently some start at 0.5 and
others might start at 1.5, though mercifully still incrementing by +1
(also a choice). This is neither correct nor incorrect. However, in
practical terms it is perhaps a surprising choice because it imposes a
fractional offset between this index and the array index that must be
used to store the data.
So far we have enough to do full WCS yet we don't have any pixels, only
the misleadingly-named index that we call the "pixel coordinate".
However, we are still left with the question of providing guidance on
representing FITS data on an image display (as opposed to a contour or
raster map):
1) Bearing in mind the way that TV devices work, each delta function
in the shah function is represented by a finite square in which the
delta function is centred.
This is really the only sensible way to do it. I'm sure it's also
the display convention for the other systems mentioned by Jonathan,
it's just that their fractional indexing scheme confuses things.
(Note that display devices have yet another coordinate system
with (0,0) in the top left corner.)
2) The little squares are laid out side-by-side with no intervening
gaps thus building up a picture. Thus they are referred to as
picture elements or "pixels" for short.
3) The pixels are laid out in row-wise fashion starting from the
bottom left corner of the display. That is, the first NAXIS1
pixels in the data array come out across the bottom of the screen,
the next NAXIS1 pixels are placed above that row, etc.
This allows an image to be transmitted to a recipient and viewed in
the intended orientation. It is particularly relevant for images
that have no associated world coordinate system, such as a photo of
your house or budgie. (However, it better be B&W since FITS has no
formal method of representing colour!)
I think it would be appropriate for the standard to contain the above
information in a section completely separate from the definition of
the WCS keywords.
Regards, Mark
More information about the fitsbits
mailing list