Uploaded image for project: 'Data Management'
  1. Data Management
  2. DM-25173

Inspect initial WCS quality for HSC and DECam


    • Type: Story
    • Status: To Do
    • Resolution: Unresolved
    • Fix Version/s: None
    • Component/s: None
    • Urgent?:


      Gen3 relies on our raw WCSs (which are now generally derived from boresight+rotation+cameraGeom, not FITS WCS header keys) to generate the regions for its spatial relationships, even for derived datasets like calexp that may improve on those WCSs.

      This has been a problem for DECam in particular, because we think there are some exposures with significant pointing error. HSC right now probably has the opposite problem: we're probably padding the raw-WCS-derived regions more than we need to, which is bad for database performance.

      The goal of this ticket is to do an analysis of initial WCS quality for both instruments by comparing to a later-stage "truth" WCS - calexp.wcs is probably good enough for this most of the time, though jointcal_wcs might be a bit better. I'd like to come away from with it with a bit of reusable tooling that we could use to repeat the analysis in the future. It doesn't need to be super polished (even unit tests might be overkill, as we're not going to run it a ton), but I'd like it to actually be committed to a maintained LSST git repo (obs_base, maybe?).

      The specific questions I'd like to answer are:

      • Are there visits with unusually large (i.e.) outlier-level pointing errors? If so, are they a consistent offset in any coordinate system? I would approach this by transforming (0, 0) in focal plane coordinates to sky via a combination of cameraGeom and then initial or truth WCS, and then averaging over CCDs in a visit and looking for outliers in the difference between initial and truth over all visits.
      • If we correct for the above pointing errors, are there significant rotation angle errors? (This is a bit trickier, and I haven't worked out the details of how I would compute it, but I think something analogous to the previous step would work). We also don't have any evidence of a problem here, yet, so I'm not totally sure it's worth doing...but if we do have a problem, it would totally confuse the next step.
      • If we correct for any outlier-level pointing or rotation angle errors, what is the padding (in pixels) we would need to apply to the initial-WCS bounding boxes to ensure that they always contain the truth-WCS bounding boxes on the sky? I would approach this by using the WCSs to construct sphgeom.ConvexPolygon objects and using those to do relationship tests; you can find examples of this in the Gen3 code that actually constructs regions for us in defineVisits.py in obs_base.

      This analysis probably needs to be done with Gen2 butlers right now, because that's the form in which we have the data (HSC PDR2) or could at least easily produce it (various DECam datasets). The guts of any tooling would hopefully avoid using any butlers and would this be easily transferrable to Gen3 in the future.


          Issue Links


            There are no comments yet on this issue.


              • Assignee:
                jbosch Jim Bosch
                Jim Bosch, John Parejko, John Swinbank
              • Votes:
                0 Vote for this issue
                3 Start watching this issue


                • Created:

                  Summary Panel