Additional "summary" flags during single frame and centroid processing?

Data Management
, ,
#1

I feel like it would be useful to have some additional summary flags and calculated values available for e.g. selecting sources for astrometry calculations. In addition to the centroid covariance (not currently computed by the SDSS centroider), two “derived flags” would be quite helpful: “this is possibly multiple sources” and “this source has a well determined centroid” (note that that’s different from the negation of the existing centroid_flag, which tells you if the source was able to be centroided at all).

I feel like such logic should live in the code that did the calculation in the first place, as that is where the most knowledge about the calculation resides. It also means that code further down the line does not have to re-invent the calculation every time, possibly saving noticeable compute time (e.g. having to check the number of peaks of each source’s footprint in a catalog).

Here’s a first cut at what these flags would mean, although those who are more familiar with the details of the relevant algorithms may be able to do better:

multipleFlag (computed by deblender?):

any(
parent != 0,
deblend_nChild > 0,
len(footprint.getPeaks()) > 1,
)

goodCentroidFlag (computed by centroider):

all(
not centroidFlag,
isfinite(centroid),
isfinite(sigma),
ok covariance (??),
not saturated,
not interpolatedCenter,
not edge,
not multipleFlag (??)
)

goodCentroidFlag could be independent of multipleFlag, thus needing both to be checked to know if a source has a totally reliable centroid. That might simplify the flag setting code, as the centroider would not have to know anything about the deblender results.

I’m not sure if adding flags requires an RFC, or whether there are a few others that could be taken care of at the same time, hence this post.

#2

I agree that another set of flags for determining isolated vs. blended object status could be very useful. While people who have spent a lot of time with either our code or SDSS typically can navigate the meanings of different filters on parent and deblend_nChild, it’s one of the most confusing things about our catalogs to new users. Maybe the following:

  • blended: deblend_nChild > 0
  • isolated: parent == 0 and not blended

In contexts where we don’t run the deblender, we could instead set:

  • blended: len(footprint.getPeaks()) > 1

If the deblender has been run, I don’t think there’s a need to check both the number of peaks and the number of children, but I may be missing an edge case somewhere.

The intent of the centroid flag is actually to be what you want: whether the centroid is good. Because they can fall back to the peak position (see also DM-4926), centroiders should always return a non-null result, but the flag should specify whether that result is trustworthy. This is generically true of measurement algorithms: the general flag indicates a good result, not the presence of any result. So if you’ve found cases where centroids are not reliable but the flag is not set, please report those as bugs in the centroider.

Of course, if the indication that the centroider is bad comes form information the centroider doesn’t have access to, we’ll have to think about how to include it.