Deblended/saturated nearby stellar object artifacts

What is the recommended course of action for nearby stars in the Object catalog that are bright enough/cover a large enough angular size that are likely saturated and the deblender processes them and reports multiple “children” objects but not the original one?

I am interested in crossmatching the Gaia Catalog of Nearby Stars to DP1 fields, but am finding that for G/K/early-M stars their angular size and brightness are large enough to trigger the deblending pipelines and they subsequently are reported as multiple children objects in the Object table. The children objects all share the same parentObjectId, but I’m struggling to find a way to work backwards and get reliable positions, magnitudes, etc for the primary object itself. It’s my understanding that this is a known issue, but I’m curious what the recommended approach to these situations is. From my reading of documentation surrounding the deblending scarlet algorithm, it seems to be optimized for galaxies and not large/bright stellar sources. This deblending seems to be most problematic for nearby low mass stars (G/K/early-M stars) and becomes less of an issue for later spectral types.

There are two specific use cases our group has encountered:

  1. Trying to match nearby saturated objects, we want to get reliable measurements for positions, magnitudes, etc (or at the very least, if an object is saturated maybe a lower limit on the magnitude).
  2. Trying to identify color outliers like M subdwarfs using color-color selection techniques picks up many of the children objects and requires additional vetting.

Some related questions are:

  • How could one get positions and magnitudes for the parent object? (use case 1)
  • Since only children are reported in catalogs, what identifier should be used for the parent object (particularly in external reference and publication scenarios) and how can it be retrieved in a reproducible way? (use case 1)
  • Is there a flag that can be used to trace back to the original footprint/centroid to do forced measurements? (use case 1 & 2)
  • Is there a flag that can mark if an object in the catalogs is near a bright saturated object or near a known bright Gaia object, for example? (use case 2)

Here are some examples I’ve found so far:
Ex 1:
Nearby (56pc) early M dwarf Gaia EDR3 19636113736531072 is reported as 4 different Objects in DP1 that all have unique objectId’s but share a single parentObjectId (650018973554837957)

Ex 2:
Nearby (100pc) K dwarf Gaia EDR3 5057367254247434880 is split into 7 different children detections with the same parentObjectId (609780833707887489). One looks to coincide with the center of the object, but in the object table appears no different from the other 6 objects. I would be hesitant to use the position and magnitudes of the centermost object.

Example 3:
Nearby (92pc) mid/late M dwarf Gaia EDR3 5057398796487218432 is not blended and does not encounter the same issue as in examples 1 and 2. It has one LSST Object table entry.

I can answer some of your questions. parentObjectId gives the ID of the parent that sources were deblended from. For isolated sources (that were not deblended) this will be zero. For deblended sources this will be non-zero and gives the id of the blend. If you also look up the tract and patch in the catalog In DP1 you can load all of the blend models for that tract and patch using

scarlet_models = butler.get("object_scarlet_models", tract=tract, patch=patch)

You can load the data for the blend using

blend = scarlet_models.blends[blendId]

where blendId is parentObjectId that you found earlier.

There are keys that can help with identifying if a given source had saturated pixels (<band>_pixelFlags_saturatedCenter, where band can be any of ugrizy). So in theory you should be able to select all of the sources with the same parentObjectId and check if any of them have any of the <band>_pixelFlags_saturatedCenter keys set.

Note: in DP2 and future data releases there will also be an object_parent catalog containing information about deblending but that data product was not ready for DP1.

As for trying to do astrometry on saturated objects, that is a difficult problem and I’m not sure that we have any mechanisms for that right now. Someone else can chime in and correct me.