Understanding the difference between camera engineering and science visualization coordinates for the full focal plane.

The way it looks to those building the camera

If you look at https://ls.st/LCA-13381, you will see that the camera coordinate system in the engineering drawing has rafts labeled with a pair of incrementing (x, y) pairs. Raft (0,0) would be coincident with the origin and raft (4,4) would be the furthest from the origin. The engineering diagrams make this somewhat hard to see since the x-axis runs to the left on those diagrams. Within each raft, the sensors are named similarly with sensor (0,0) being adjacent to the origin and sensor (2,2) being furthest from the origin. Finally, the sensors have a grid of segments each associated with an amplifier. In the engineering diagrams, these are again labeled such that the amplifier adjacent to the origin is labeled (0,0) and the one furthest from the origin is (1,7).

Why this is an issue.

The issue comes in when you recognize that the engineering diagrams have the parallel transfer direction along the x-axis. The result of this is that, using most traditional plotting tools, the parallel direction is along the bottom of the screen. This results in bleed trails appearing to be horizontal. Horizontal bleed trails look strange because most astronomers are used to looking at images with the serial register along the x-axis (bottom of the screen).

What is the situation right now?

We want to have a simple transform between the coordinates in the engineering and coordinates astronomers feel more comfortable with. There are two obvious ways to do this:

Rotate the entire coordinate system by 90 degrees
Transpose the entire grid
Current work on obs_lsst has assumed convention #2. This can be demonstrated by looking at a full focal plane representation of the camera from obs_lsst. See this image for evidence. You will see the first raft index increase in the y-direction and the second index increas in the x-direction. A rotation would have a different signature. Namely, the raft labeled (0,0) would no longer be coincident with the origin.

Unfortunately, when I wrote the amp definitions for the LSST camera, I assumed the transform was a 90 degree rotation. This leads to internal inconsistencies which are currently handled by renaming the amps when packaging them up for ingestion.

Path forward

We need to decide whether we are going to rotate or transpose. I do not really mind either way. I find thinking about rotations slightly easier than transposition, but the math involved in doing the transpose is easier than that of rotation. The current system (other than CCD assembly assumes transposition.

If we choose rotation, we will need to update the camera definition to place the chips in the correct place for a rotation. If we choose transpose, we will need to change the amp segment definitions.

In either case, we should fix the phosim repackager so that it no longer renames the amp segments.

The proposal. 

My proposal is that we accept the transpose as the recognized transformation between the engineering coordinates and the display coordinates. The argument is that it is less error prone than doing the rotation. With the transpose, just switching x and y coordinates gets the right answer. With a rotation, some (simple) math is required to get the right answer. This makes applying the transform much easier to do in your head than the rotation.