Details
-
Type:
Bug
-
Status: Won't Fix
-
Resolution: Done
-
Fix Version/s: None
-
Component/s: afw
-
Labels:
-
Epic Link:
-
Team:Alert Production
Description
Calib::Calib(std::vector<CONST_PTR(Calib)> const& calibs) constructs a Calib whose fluxMag0 and fluxMag0Sigma are both 0. It carefully computes a new exposure date and exposure time, but not a new fluxMag0 or fluxMag0Sigma.
That constructor demands that the fluxMag0 and fluxMag0Sigma be equal (within epsilon) for all input calibs, and I would expect that the resulting Calib would have fluxMag0 = the input fluxMag0, and fluxMag0Sigma either equal the input fluxMag0 or perhaps be reduced by some factor, if averaging beats down the error.
Robert Lupton please weigh in as the desired behavior, then feel free to reassign or this ticket (e.g. to me).
Attachments
Activity
Where is this functionality used?
Robert Lupton I was hoping you'd know why the constructor existed. Prompted by your question I looked through my stack and did not see any obvious usage, other than in a unit test. but I may have missed something. It would certainly be easy enough to get rid of it if you don't think it's needed, though it will require an RFC. I took the liberty of adding Jim Bosch as a watcher in case he knows why we'd build a Calib from a list of Calib.
I'm guessing in coadd production, but then I don't understand the constraints on the implementation.
I don't know of any uses of this code.
I originally thought of coadds, as well, but since they usually are made of images that overlap in interesting ways, a proper coadd Calib would surely have to be more complicated than a single image Calib. Another possibility is stacked images such as snapshots, but I do not know of a use case for computing calibration separately for each image in a stack.
Robert Lupton if we are not using it then should we get rid of it?
I discovered this ticket while looking through the tests of the old Calib object. The new PhotoCalib (RFC-289) does not have such a constructor, and I have no plans to add one. Once PhotoCalib fully replaces Calib, we can close this ticket. Although maybe we can just close it won't fix right now?
Calib will be disappearing in the near future, and so will this constructor, so this is no longer relevant.
Found while removing exposure time an date from Calib for
DM-5503. A unit test clearly needed updating to test what merging did to fluxMag0. For now I have the test explicitly checking that the value is 0, but that's presumably not correct, so I added a comment pointing to this ticket.