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

New spatially-variant PhotoCalib object

    Details

    • Type: RFC
    • Status: Implemented
    • Resolution: Done
    • Component/s: DM
    • Labels:
      None

      Description

      To improve jointcal's photometric fitting, we need a way to represent a spatially-varying photometric model. Our current Calib object is a constant flux/magnitude zero point (fluxMag0) per ccd/visit. We expect to want to handle a spatially varying component (whether due to sky, optical system, filters, a shift across a CCD, or some combination thereof), and jointcal should be able to fit such a model. As an example, HSC's meas_mosaic fits a 7th order polynomial on the focal plane, plus a fluxMag0 per CCD.

      I propose a replacement for lsst::afw::image::Calib that is built on top of an lsst::afw::math::BoundedField, defined in terms of the conversion from counts to flux in maggies. It will have countsToMaggies() and countsToMagnitudes() methods (replacing the current getMagnitude()) that take counts and/or a point, as well as a SourceRecord or SourceCatalog. The new PhotoCalib will behave the same as the old Calib for spatially invariant scaling (i.e. only fluxMag0 is defined).

      The class docstring for the new PhotoCalib object is as follows:

      /**
       * @brief      The photometric calibration of an exposure.
       *
       * A PhotoCalib is a BoundedField (a function with a specified domain) that converts between calibrated
       * counts-on-chip (ADU) to flux and magnitude. It is defined in terms of "maggies", which are a linear
       * unit defined in SDSS: http://www.sdss.org/dr12/algorithms/magnitudes/#nmgy
       *
       * PhotoCalib is immutable.
       *
       * The spatially varying flux/magnitude zero point is defined such that,
       * at a position (x,y) in the domain of the boundedField zeroPoint
       * and for a given measured source counts:
       *     zeroPoint(x,y) * counts = flux (in maggies)
       * while the errors (constant on the domain) are defined as:
       *     sqrt(countsSigma^2 + zeroPointSigma^2) = fluxSigma (in maggies)
       */
      

      You can see the full API for the new PhotoCalib on this gist.

        Attachments

          Issue Links

            Activity

            Hide
            Parejkoj John Parejko added a comment -

            I'm proposing this now, because it's the minimum thing I need now, and we don't have a way to represent such a calib.

            As I said above re:LDM-151, this is the proposal for a new PhotoCalib that has room to be extended in the future. We already know there needs to be an SED term eventually, and as Russell Owen says, one could make a composite BoundedField to represent a more complicated set of transforms.

            Show
            Parejkoj John Parejko added a comment - I'm proposing this now, because it's the minimum thing I need now, and we don't have a way to represent such a calib. As I said above re:LDM-151, this is the proposal for a new PhotoCalib that has room to be extended in the future. We already know there needs to be an SED term eventually, and as Russell Owen says, one could make a composite BoundedField to represent a more complicated set of transforms.
            Hide
            jbosch Jim Bosch added a comment -

            My vision for the composition and tiling was indeed that it happen within the BoundedField.

            I believe AST is an option for implementing that, though I should emphasize that my previous comment about where AST would go should not be taken to imply that I endorse using it here. Those kinds of implementation questions do to be considered in the larger context Robert Lupton brought up (and probably not on this ticket) - for example, for fitting we probably need to have objects that are not only composable/tileable but differentiable w.r.t. some set of parameters as well, and hence we may find ourselves having to reimplement a lot of what we may have thought AST would provide for us.

            Show
            jbosch Jim Bosch added a comment - My vision for the composition and tiling was indeed that it happen within the BoundedField . I believe AST is an option for implementing that, though I should emphasize that my previous comment about where AST would go should not be taken to imply that I endorse using it here. Those kinds of implementation questions do to be considered in the larger context Robert Lupton brought up (and probably not on this ticket) - for example, for fitting we probably need to have objects that are not only composable/tileable but differentiable w.r.t. some set of parameters as well, and hence we may find ourselves having to reimplement a lot of what we may have thought AST would provide for us.
            Hide
            krughoff Simon Krughoff added a comment -

            This proposal sounds good to me. It seems like the current proposal can go through with the understanding that the extensions need in the future may be available through a re-design of BoundedField.

            Show
            krughoff Simon Krughoff added a comment - This proposal sounds good to me. It seems like the current proposal can go through with the understanding that the extensions need in the future may be available through a re-design of BoundedField .
            Hide
            Parejkoj John Parejko added a comment -

            Adopted as written above. Implementation ticket is DM-9192.

            Show
            Parejkoj John Parejko added a comment - Adopted as written above. Implementation ticket is DM-9192 .
            Hide
            Parejkoj John Parejko added a comment -

            NOTE: One of the various changes in the final implementation is that I've removed the throwOnNegativeCounts argument, as it appears to be almost never used in the current stack.

            Show
            Parejkoj John Parejko added a comment - NOTE: One of the various changes in the final implementation is that I've removed the throwOnNegativeCounts argument, as it appears to be almost never used in the current stack.

              People

              • Assignee:
                Parejkoj John Parejko
                Reporter:
                Parejkoj John Parejko
                Watchers:
                Dominique Boutigny, Jim Bosch, John Parejko, John Swinbank, Michael Wood-Vasey, Pierre Astier, Robert Lupton, Russell Owen, Simon Krughoff, Yusra AlSayyad
              • Votes:
                0 Vote for this issue
                Watchers:
                10 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved:
                  Planned End:

                  Summary Panel