Details
-
Type:
RFC
-
Status: Implemented
-
Resolution: Done
-
Component/s: DM
-
Labels:
Description
This proposal changes the way the initial "raw" WCS – what is returned by butler.get("raw_wcs") or, equivalently butler.get("raw").getWcs() – is determined. The current implementation uses the standard FITS header keys (CRVAL, CRPIX, CDX_Y) to create a SkyWcs. That SkyWcs is passed to ip_isr, where it is optionally updated with a camera geometry-defined optical distortion model, and subsequently used by the astrometric calibration task for the initial reference catalog match. Here, the proposal is to build this initial "raw" WCS based on a combination of telescope boresight and rotation angle (from VisitInfo) and detector positions and optical distortion (from the camera geometry). This means that ip_isr will no longer attempt to create a distorted WCS (previously configured via addDistortionModel): the SkyWcs object attached to the raw will always be our best guess at the true pixel->sky transformation.
The proposed change stems from work done in DM-19943 and detailed in DM-19951 (see comments on those tickets for further detail & discussion).
Doing this as part of the butler handling of raw exposures simplifies our WCS code paths, as ISR will no longer be able to potentially overwrite the SkyWcs. This was a source of confusion during the investigation phase of DM-19943: there were multiple possible places that could generate the input SkyWcs used to initialize AstrometryTask.
As part of this change, we will add a "raw_header_wcs" butler dataset type to allow users to get at the FITS header WCS stored in the raw exposure (what was previously returned by butler.get("raw_wcs")).
This approach avoids answering some important questions in the gen3 butler regarding versioned camera geometry and the provenance of the raw WCS. We will deal with those questions once the Gen2 butler has been retired, to avoid having to implement two different systems for said versioning and provenance.
Attachments
Issue Links
Activity
If we had a way of returning the "totally-raw" md (and I see confusion about this), then we could indeed construct the desired Wcs from the metadata. So if we need this functionality, I'd rather add a way of getting that "totally-raw" header which is potentially useful in a wider range of applications – and we can construct a Wcs when desired.
For example, if we read a file with a corrupt header that doesn't give a valid Wcs, we'd have a way to debug things.
Can we leave the question of dealing with "totally raw" metadata to a different RFC? I've got an implementation of `raw_header_wcs` already written, which will solve the immediate problem.
Are there any more objections to this? I have two triggering tickets in place.
Adopting this, as there don't appear to be any further objections.
How we handle modifying metadata can be sorted out at a future date.
The internal conversation that resulted in `header_wcs` instead of `metadata_wcs` was that this is explicitly a WCS created from FITS header keys, which has a very well defined meaning, as opposed to some generic metadata. Given the above questions about what exactly `metadata` is for a `raw`, I think in this case explicitly using `header` is a good idea. Alternately, `raw_fits_header_wcs` would be even more explicit on that point.