You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
(Reposting this from decam-chatter to better keep track of the issues.)
The "BRICK_PRIMARY" value in the tractor catalog does not always match the "NPRIMARY" bit in "MASKBITS". This happens for a small number of objects (a few hundred objects in a sweep catalog). The plot below shows (in red points) objects with the NPRIMARY bit set in a sweep catalog (which by definition only contains BRICK_PRIMARY==0 objects). Clearly they are all along the brick boundaries. I wonder if it's because each value is defined differently (perhaps BRICK_PRIMARY is based on geometry, while NPRIMARY is based on the maskbits pixel images).
In any case, we should figure out if the NPRIMARY mask bit in the sweep catalogs should ever be used, and specifically, if requiring NPRIMARY=0 would remove unique real sources. If that is the case, we should put a clear warning in the documentation not to use this bit.
The text was updated successfully, but these errors were encountered:
(Reposting this from decam-chatter to better keep track of the issues.)
The "BRICK_PRIMARY" value in the tractor catalog does not always match the "NPRIMARY" bit in "MASKBITS". This happens for a small number of objects (a few hundred objects in a sweep catalog). The plot below shows (in red points) objects with the NPRIMARY bit set in a sweep catalog (which by definition only contains BRICK_PRIMARY==0 objects). Clearly they are all along the brick boundaries. I wonder if it's because each value is defined differently (perhaps BRICK_PRIMARY is based on geometry, while NPRIMARY is based on the maskbits pixel images).
In any case, we should figure out if the NPRIMARY mask bit in the sweep catalogs should ever be used, and specifically, if requiring NPRIMARY=0 would remove unique real sources. If that is the case, we should put a clear warning in the documentation not to use this bit.
The text was updated successfully, but these errors were encountered: