Uploaded image for project: 'Request For Comments'
  1. Request For Comments
  2. RFC-616

New approach to the WCS of raw exposures

    Details

      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

            Hide
            Parejkoj 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
            Parejkoj 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
            rhl 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
            rhl 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
            Parejkoj 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
            Parejkoj 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
            Parejkoj John Parejko added a comment -

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

            Show
            Parejkoj John Parejko added a comment - Are there any more objections to this? I have two triggering tickets in place.
            Hide
            Parejkoj 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
            Parejkoj 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:
                Parejkoj John Parejko
                Reporter:
                Parejkoj John Parejko
                Watchers:
                Jim Bosch, John Parejko, John Swinbank, Lauren MacArthur, Meredith Rawls, Paul Price, Robert Lupton, Tim Jenness, Yusra AlSayyad
              • Votes:
                0 Vote for this issue
                Watchers:
                9 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved:
                  Planned End:

                  Summary Panel