Last modified 11 years ago Last modified on 09/03/2008 03:48:03 PM
There are three issues here:
      1/ What's the index of the bottom-left pixel?
      2/ What is meant by the bottom-left pixel?
      3/ Where within that pixel is the point (0.0, 0.0)

I propose the we:
      1/ Use 0-based coordinates, so the bottom-left pixel is (0, 0)

      2/ Define the bottom left by:
             Orientate the CCD so segment 00 (see Appendix) is at the
             bottom left corner of the device when looking at the
             sky; take its bottom left corner pixel to be the
             bottom-left pixel.

      3/ Use the FITS convention that the pixel centre is (0.0, 0.0),
      so the first pixel physically extends from -0.5 to 0.5

	This results in a right-handed coordinate system.

	All CCD data must be stored in such a way that it can be
	mapped to the "silicon" coordinates define by the figure in
	the appendix by translations (no rotations or flips). When
	dealing with data from segments 10 --- 17 it is likely that
	someone will have to flip the data left-to-right; we need
	to define if this is a camera or DM responsibility.


Frank Valdes and Abi Saha point out the FITS IAU standard as a
precedent for defining coordinate systems, adopting the bottom left
pixel centre as (1.0, 1.0).

To address the first issue, while FITS is 1-based, that's basically
because Fortran is.  Almost all other languages (in particular
C/C++/Python) aren't, and I think that that's a stronger argument;
having to add 1 to all array indices is error prone as well as ugly.

On the second point.  FITS takes the pixel centre to be (0.0, 0.0)
which (as Abi points out) makes sense when you realise that a CCD
image samples a continuous (pixel-convolved) image at the position
of each pixel centre.

SDSS went with the pixel centre being (0.5, 0.5) which means
that you always have to add 0.5 to a pixel position to get
the centre (and truncate, not round, a floating position to
get a pixel index).  We had no strong reasons to do this, and
it was causing trouble.  Jim Gunn was not happy (he still isn't)
that we took this decision.

N.b. as regards e.g. ds9, it's easy to add an extra WCS to display pixel
coordinates in any adopted convention

Appendix:  Physical layout of CCD segments

Kirk Gilmore referred me to a document written by Martin Nordby
( with a sketch of a CCD as viewed from L1,
which is referred to as the sensor "back side":

   | | Segment 17   |  Segment 07   | |
   | |--------------+---------------| |
   | |              |  Segment 06   | |
   | |    O       --+---------------| |
   | |              |               | |
   | |                              | |
   | |                              | |
   | |                              | |
   | |                          O   | |
   | |                              | |
   | |                              | |
   | |                              | |
   | |                              | |
   | |              |               | |
   | |    O       --+---------------| |
   | |              |  Segment 01   | |
   | |--------------+---------------| |   ^
   | | Segment 10   |  Segment 00   | |   |
   ------------------------------------   y
                                    <- x -+

The "O"s are sensor package mounts and the "| |" gutters at each side
are the serial registers.

These are back-side illuminated chips with three mirrors, so that
means that the looking-at-the-sky coordinate system is right-handed,
with segment 00 at the bottom left.

Note that this layout is not to be assumed by the LSST software ---
it's merely illustrative of how we can define the origin for data
from the LSST camera.

Comment by Russell on Thu 29 May 2008 04:27:07 PM CDT

Two points:

1) LSST code should NOT assume a convention. There are inline
functions in afw for converting between index and position, plus a
constant describing the difference between the two. In my opinion all
LSST code should be required to use these. This avoids the following
common problems:
- A coder assumes the wrong convention and codes accordingly. RHL
notes many examples of this. There are two conventions already in
common use and RHL is proposing to adopt a third, which will
exacerbate the problem.
- A coder assumes the right convention but codes it wrong. In
particular, the transformation from position to index is notoriously
easy to get wrong.
- A coder forgets the difference between index and position. This
leads to code that is hard to understand and is often subtly

2) Given the fact that there are already two standards that are in
widespread use I see no reason to adopt yet another standard. But if
we adopt (1) then I don't have strong feelings about it either.

Add comment