# Understand and fix (if necessary) relative calibration for Zogy

XMLWordPrintable

#### Details

• Type: Story
• Status: Done
• Resolution: Done
• Fix Version/s: None
• Component/s:
• Labels:
None
• Story Points:
6
• Team:
External
• Urgent?:
No

#### 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.

#### Activity

Hide
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
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
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
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
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
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
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
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
Michael Wood-Vasey added a comment -

Merged to master.

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

#### People

Assignee:
Michael Wood-Vasey
Reporter:
David Reiss
Reviewers:
Gabor Kovacs, John Parejko
Watchers:
Bob Armstrong, David Reiss, Gabor Kovacs, John Parejko, Michael Wood-Vasey