Allrighty...I think I've got this. It was a bit difficult to track down. I'll keep the dirty details to a minimum, but the adventure went something like this...
As a starting point, I wanted to see what references were actually ending up in the loaded + trimmed astrometry reference catalogs, so I went in and manually output the tables returned by the loader. The following plots a comparison of loaded refCats between the Gen2 and Gen3 processing runs for two of the CCDs in the one visit I have tested so far (1228, HSC-I) [spoiler alert, it also includes the result of the fix on this branch as the green +'s!]:
You can see that the Gen3 (orange x's) loader is clearly not padding the initial bbox. The first "bug" I noted in this regard was that the gen3 reference object loader was using a named parameter, bboxPadding, in the loadPixelBox function (the method called in the astrometric calibration's run method here). This should end up being the value set in the loader's config parameter pixelMargin (as defined here). However, this config is not accessed at all in the gen3 loader path and was just getting the default value of 100 (as opposed to 300)...so, bingo, just get that parameter to match the pixelMargin and all is good, yes? Well, no...playing around with forcing many values for bboxPadding produced the very same catalog (trimmed to the original, non-padded image wcs). I tracked this down to the filtering algorithm that was indeed (erroneously) using the original non-padded bbox to filter on. I've now gotten rid of bboxPadding altogether and have all reference loading paths respecting the padding value set in the pixelMargin config. So, with this fix, where do we stand? Drumroll, please...with the caveat that testing has only been done thus far on a single visit...for every comparison I've made (including image/variance/mask planes, PSFs, WCSs, photoCalibs, for which I also attached the identical refCat selection for photometric calibration for the same two CCDs, EVERY COLUMN IN THE src CATALOGS), the ONLY remaining difference in the src catalogs is the integer offset for the deblend_peakId entries noted in DM-28858. Everything else is now bitwise-identical up to the end of Single Frame Processing.
Story
Allrighty...I think I've got this. It was a bit difficult to track down. I'll keep the dirty details to a minimum, but the adventure went something like this...
As a starting point, I wanted to see what references were actually ending up in the loaded + trimmed astrometry reference catalogs, so I went in and manually output the tables returned by the loader. The following plots a comparison of loaded refCats between the Gen2 and Gen3 processing runs for two of the CCDs in the one visit I have tested so far (1228, HSC-I) [spoiler alert, it also includes the result of the fix on this branch as the green +'s!]:
You can see that the Gen3 (orange x's) loader is clearly not padding the initial bbox. The first "bug" I noted in this regard was that the gen3 reference object loader was using a named parameter, bboxPadding, in the loadPixelBox function (the method called in the astrometric calibration's run method here). This should end up being the value set in the loader's config parameter pixelMargin (as defined here). However, this config is not accessed at all in the gen3 loader path and was just getting the default value of 100 (as opposed to 300)...so, bingo, just get that parameter to match the pixelMargin and all is good, yes? Well, no...playing around with forcing many values for bboxPadding produced the very same catalog (trimmed to the original, non-padded image wcs). I tracked this down to the filtering algorithm that was indeed (erroneously) using the original non-padded bbox to filter on. I've now gotten rid of bboxPadding altogether and have all reference loading paths respecting the padding value set in the pixelMargin config. So, with this fix, where do we stand? Drumroll, please...with the caveat that testing has only been done thus far on a single visit...for every comparison I've made (including image/variance/mask planes, PSFs, WCSs, photoCalibs, for which I also attached the identical refCat selection for photometric calibration for the same two CCDs, EVERY COLUMN IN THE src CATALOGS), the ONLY remaining difference in the src catalogs is the integer offset for the deblend_peakId entries noted in
DM-28858. Everything else is now bitwise-identical up to the end of Single Frame Processing.