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

Understand and fix (if necessary) relative calibration for Zogy

    Details

    • Type: Story
    • Status: Done
    • Resolution: Done
    • Fix Version/s: None
    • Component/s: ip_diffim
    • Labels:
      None

      Description

      Zogy suffers if there is inaccurate relative calibration between the two images. This issue can be seen in DMTN-061. Not clear how frequently this occurs. This can be fixed by fitting for the relative calibration and setting them as the Fr and Fn parameters for Zogy, or else ensuring that the LSST stack calibration is accurate. Another possibility is that the images are not being loaded for Zogy correctly or that a (already measured?) flux calibration should be applied to the pixels in the images before running Zogy.

        Attachments

          Issue Links

            Activity

            Hide
            gkovacs Gabor Kovacs added a comment - - edited

            Let's have a brief chat about this in the near future to ensure that we're on the same page. Added links to tickets that touch the same topic.

            Show
            gkovacs Gabor Kovacs added a comment - - edited Let's have a brief chat about this in the near future to ensure that we're on the same page. Added links to tickets that touch the same topic.
            Hide
            Parejkoj John Parejko added a comment -

            I didn't have any real suggestions on the code. Given the way `self.Fr` and `self.Fn` are used in `zogy.py`, I don't have an obvious solution to what to do here. Technically you should be using `photoCalib.calibrateImage()` to do the actual rescaling, but it doesn't look like the code itself does that rescaling anywhere (those numbers go into variance planes, etc.). Our coadds should all have a constant scaling (1, if I had my druthers, but the existing code takes out spatial variations), and we aren't fitting spatially varying terms in `calibrate`.

            Honestly, I'd suggest deprecating the `templateFluxScaling` and `scienceFluxScaling` config parameters as part of this. Those shouldn't ever be specified by the user: they should always come from the input PhotoCalibs.

            Show
            Parejkoj John Parejko added a comment - I didn't have any real suggestions on the code. Given the way `self.Fr` and `self.Fn` are used in `zogy.py`, I don't have an obvious solution to what to do here. Technically you should be using `photoCalib.calibrateImage()` to do the actual rescaling, but it doesn't look like the code itself does that rescaling anywhere (those numbers go into variance planes, etc.). Our coadds should all have a constant scaling (1, if I had my druthers, but the existing code takes out spatial variations), and we aren't fitting spatially varying terms in `calibrate`. Honestly, I'd suggest deprecating the `templateFluxScaling` and `scienceFluxScaling` config parameters as part of this. Those shouldn't ever be specified by the user: they should always come from the input PhotoCalibs.
            Hide
            gkovacs Gabor Kovacs added a comment - - edited

            Did you test run with the spatiallyVarying==True? In ImageMapReduceTask.runMapper() it seems that a subexposure is created by using the Exposure copy constructor with an existing exposure and a bbox. I assume it inherits the same PhotoCalib instance (the documentation only mentions the issue of pixel copy).

            subExp = exposure.Factory(exposure, box0)
            

            John Parejko Does getCalibrationMean() change when a subexposure is created this way ? I.e. subExp.getPhotoCalib().getCalibrationMean()==exposure.getPhotoCalib().getCalibrationMean() ?

            Michael Wood-Vasey Otherwise, I'm OK with the change. Sorry that this ticket wasn't on top of my priorities to look into.

            Show
            gkovacs Gabor Kovacs added a comment - - edited Did you test run with the spatiallyVarying==True ? In ImageMapReduceTask.runMapper() it seems that a subexposure is created by using the Exposure copy constructor with an existing exposure and a bbox. I assume it inherits the same PhotoCalib instance (the documentation only mentions the issue of pixel copy). subExp = exposure.Factory(exposure, box0) John Parejko Does getCalibrationMean() change when a subexposure is created this way ? I.e. subExp.getPhotoCalib().getCalibrationMean()==exposure.getPhotoCalib().getCalibrationMean() ? Michael Wood-Vasey Otherwise, I'm OK with the change. Sorry that this ticket wasn't on top of my priorities to look into.
            Hide
            wmwood-vasey Michael Wood-Vasey added a comment -

            Added handling for images passed without a photoCalib object.

            Passes Jenkins:

            https://ci.lsst.codes/blue/organizations/jenkins/stack-os-matrix/detail/stack-os-matrix/31223/pipeline/47/

            Show
            wmwood-vasey Michael Wood-Vasey added a comment - Added handling for images passed without a photoCalib object. Passes Jenkins: https://ci.lsst.codes/blue/organizations/jenkins/stack-os-matrix/detail/stack-os-matrix/31223/pipeline/47/
            Hide
            wmwood-vasey Michael Wood-Vasey added a comment -

            Merged to master.

            Show
            wmwood-vasey Michael Wood-Vasey added a comment - Merged to master.

              People

              • Assignee:
                wmwood-vasey Michael Wood-Vasey
                Reporter:
                reiss David Reiss
                Reviewers:
                Gabor Kovacs, John Parejko
                Watchers:
                Bob Armstrong, David Reiss, Gabor Kovacs, John Parejko, Michael Wood-Vasey
              • Votes:
                0 Vote for this issue
                Watchers:
                5 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved:

                  Summary Panel