Dual image catalog association » History » Version 3
Dual image object association¶
In Balrog test, we found a population of objects, for which the simulated and recovered properties are strongly discrepant, e.g. a simulated galaxy with true magnitude 26 that is measured at mag 22. Using the tile viewer, we could confirm that the brighter object actually does exists. However, the positional offsets between the mock object and the measured object had excursions up to dozens of arcmin. So the problem is that two objects are associated, which should not be.
For the coadds catalogs, SExtractor runs in dual image mode, using the riz coadd as detection image. This is different from using the association mode, which requires a reference catalog and performs objects matching in catalog space. Instead, dual image mode simple performs the measurements in the analysis image on the set of pixels (for each object) found in the detection image, basically a sort of forced photometry with a fixed aperture. To be abundantly clear: In dual image, no cutoff criterion for object association (such as the default 2 pixels centroid offsets) is considered, meaning that potentially very distant objects end up being associated with each other.
Here are the plots for positional offsets between g and r, r and i, r and z from DESDM...
But how can such associations be made? A very old bug in SExtractor is the presence of disjoint pieces of the segmentation map that are assigned to one object. For instance, the object red in the segmentation map (this isn't DESDM, but from the v4 SV pointed cluster coadd of Bullet, which employed a very setup very similar to DESDM) has the same ID 234200 for the big object and the tiny speck below it:
But since they are obviously not the same object, the dual image mode will force the analysis to utilize pixels that belong to actually two independent objects. This will have undesired consequences for photometry (among other parameters), effectively introducing additional scatter from merging two independent objects. The piece of code in SExtractor that causes this merging is in the <tt>clean</tt> function. Particularly line 121 in clean.c of the v2.18.10 code base states that the spatial distance for merging is set by 10 times the sum of the semi-major axes of both objects, which can be a very large reach for a big galaxy. Since such galaxies are rare, large offsets should be rare (and considering the plots above: they are).