[This is a bit overdue…so apologies for any who might have spotted these changes and wondered “why?”!]
As of DM-30030, the default for the following config parameters related to the padding of bounding boxes for, e.g. loading/trimming of reference catalogs and maximum match distances for astrometric calibration, have been updated from 300 to 250 pixels:
characterizeImage:refObjLoader.pixelMargin=250
characterizeImage:ref_match.matcher.maxOffsetPix=250
calibrate:astromRefObjLoader.pixelMargin=250
calibrate:photoRefObjLoader.pixelMargin=250
calibrate:astrometry.matcher.maxOffsetPix=250
Please see the detailed commentary and analysis on DM-30030 if interested, but the gist of this change is that, because of improvements that have been made over the past few years on the assignment of the WCS for raw exposures (which now includes boresight + rotation + cameraGeom), updates to the matchers, and fixes to some erroneous (leftover) WCS shifting during CCD assembly (DM-27868), we have determined with a careful investigation based on HSC data on DM-24024 (along with some experiments with DECam data in the crowded Saha fields as well as DC2 datasets) that 300 pixels is overkill. We would like to keep this padding to as small as is (somewhat conservatively) reasonable. This is for the obvious memory savings and limiting the number of iteration/rejection steps in the matching but, almost more significantly, to avoid having WCS fits drift and converging at an offset that lies beyond where we “know” a priori the CCD sky coordinates boundaries to lie. These parameters all have interplay at some level, so keeping them consistent is best for the defaults.
In addition, the default for the padding config parameter in the ComputeVisitRetions class in lsst.obs.base.definceVisits has been increased from 0 to 250 pixel. This parameter controls the padding added when “defining visits” in a gen3 middleware repository. It must be conservative enough to ensure the effective definition of the visit footprint on the sky (i.e. the “true” WCS) is encompassed within the context of the raw WCS (the only one available to this task). The previous default of 0 clearly does not satisfy the “conservative” criterion for any “real” context. obs_subaru was using an override of 4000 pixels, but this was updated to 250 pixels (see DM-24024 for the detailed study landing on this default). Since 0 is clearly not suitable, the default has been increased to 250 pixel (and the override in obs_subaru has been removed since the default is now what we want for HSC data). Also, in practice, this config should satisfy the criterion that it is >= to the pixelMargin configs listed above, so defaulting them to be equal is the most sensible choice.
A caveat to watch out for is that all non-HSC datasets in the shared Gen3 data repositories were built with the default of 0 padding. As such, while for the most part, things “should” be ok, it is possible we will have the occasional unlucky edge case that lands right on the edge of a given shard (so it won’t have loaded reference objects right to the edge of the padded image bounding boxes). For the LSSTCam-imSim (i.e. DC2/DP0.1) data, my suspicion is that even these edge case won’t really be an issue given the “perfectness” of the reference catalogs (and we have thus far not seen a single case of this, but this is only slightly better than a gut-feeling assertion at this point). Being “real” data relying on “real” reference catalogs, the DECam repo may not fare as well on these edge cases (but we don’t really have a systematic set of processing runs to battle-test that speculation). Updating these repos to use the new default padding would be a significant amount of effort and I am inclined to conclude that it is not currently worth the effort (especially if a “reboot” is anticipated in the near-ish future), but if anyone sees any evidence to negate this conjecture, please do speak up and an update to the existing repos will be taken into consideration.