I found some very interesting and unexpected things (see attached notebook).
First off, the relevant number for Gen3 work is that we should pad by about 2000 pixels if we want to use the raw WCS to make a boundary that will definitely include the final WCS. I've gone ahead and bumped that up to 4000 pixels just to be safe (in the new configs added to obs_subaru on
It also looks like the boresight according to the raw WCSs is pretty good - it's a much, much smaller effect than the distortion.
The surprising result is that it looks like neither of our approaches to using cameraGeom to distort a raw WCS work correctly:
- makeDistortedTanWcs (which is used by ISR) seem to do the right thing in x (or at least x in the tract coordinate system I've projected everything onto, though it seems to also be x in the pixel coordinates of most CCDs). But it moves things in the opposite direction in y, and seems to have the wrong curvature as well. I first thought that this was a problem with the HSC cameraGeom, but that looks fine on closer inspection - instead it seems like a bug in makeDistortedTanWcs.
- The makeSkyWcs overload that takes a PIXELS to FIELD_ANGLE transform, boresight position, and rotation angle has a scaling problem - it makes all detectors much larger and further from the boresight than they should be. It seems like a units thing, but I don't know if it's an HSC-specific pixels vs. mm thing or a radians vs. degrees thing.
The fact that both of these are broken also makes me worry about the TAN_PIXELS coordinate system we use to correct for distortion when doing single-frame matching and astrometric fitting; I haven't checked that here.