In order to get the CFHT MegaPrime and DECam camera orientations correct on the sky when creating an initial SkyWcs from the telescope boresight and camera geometry (see
DM-20201 and DM-20188), we need to flip DECam along X. This parity flip should be encoded in the camera geometry itself, so that we do not need to specify anything special in each obs package when loading the raw images.
Russell Owen and I have discussed a few options. Here, I propose that we incorporate this parity flip as part of the Transform between the FOCAL_PLANE and FIELD_ANGLE coordinate systems. This would change the definition of the FIELD_ANGLE in CameraSys.h such that it may not always be true that "The orientation of the x,y axes is the same as FOCAL_PLANE." A benefit would be that FIELD_ANGLE will always have a consistent relationship to SKY for all cameras, being a pure rotation and projection to the sphere. Incorporating the parity flip here means that the RotType=SKY definition in VisitInfo would have a single meaning; it currently says "+Y is along N and +X is along E/W depending on handedness."
We would add a getFocalPlaneParity() read-only method to Camera so that the user can determine whether there is such a parity flip. This value would be retrieved from the Transform between FOCAL_PLANE and FIELD_ANGLE.
A challenge of adding this transform is that we do not currently have a coherent system for describing camera geometries. Most existing obs packages have either a camGeom/ or camera/ directory with a python config and a bunch of FITS files (built on pex_config) while obs_lsst uses an YAML format (which also isn't documented, see e.g. DM-12682 and DM-17532).
Implementation detail: A possible solution to how to deal with existing pex_config Cameras is to add a focalPlaneParity boolean to the pex_config camera definitions that gets "automatically" pulled into the appropriate transform when the Camera is created. YAML cameras would have the parity incorporated as part of the transformation directly.