# New approach to the WCS of raw exposures

XMLWordPrintable

#### Details

• Type: RFC
• Status: Implemented
• Resolution: Done
• Component/s:
• 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.

#### Activity

Hide
John Parejko added a comment - - edited

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.

Show
John Parejko added a comment - - edited 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.
Hide
Robert Lupton added a comment -

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.

Show
Robert Lupton added a comment - 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.
Hide
John Parejko added a comment -

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.

Show
John Parejko added a comment - 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.
Hide
John Parejko added a comment -

Are there any more objections to this? I have two triggering tickets in place.

Show
John Parejko added a comment - Are there any more objections to this? I have two triggering tickets in place.
Hide
John Parejko added a comment -

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.

Show
John Parejko added a comment - 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.

#### People

Assignee:
John Parejko
Reporter:
John Parejko
Watchers:
Jim Bosch, John Parejko, John Swinbank, Lauren MacArthur, Meredith Rawls, Paul Price, Robert Lupton, Tim Jenness, Yusra AlSayyad
0 Vote for this issue
Watchers:
9 Start watching this issue

#### Dates

Created:
Updated:
Resolved:
Planned End:

#### Jenkins

No builds found.