I was looking at the properties of a sample of galaxies and I removed the
detect_isPrimary flag from the query, as I also wanted to see possible blended objects.
I noticed the appearance of multiple detections on the same galaxy with exactly the same parameters. The example attached is an extreme case with up to 4 detection on the same coordinates, but I noticed that at least one
children source is very often present also on bright-isolated galaxies.
Could someone explain to me why this is happening?
We have someone looking into this and should have some information soon. Thanks - Tina
Hi @Vincenzo, I’m wondering if you can post your query, so I can investigate further? Or feel free to send in a direct message. Thank you!
It is just a cone search around a certain set of coordinates.
This query should return the galaxies from the above example:
results = service.search("SELECT coord_ra, coord_dec, tract, patch, objectId, i_kronRad, "
"scisql_nanojanskyToAbMag(i_kronFlux) AS i_kronMag, "
"scisql_nanojanskyToAbMagSigma(i_kronFlux, i_kronFluxErr) AS i_kronMagErr, "
"detect_isPrimary, refExtendedness "
"FROM dp02_dc2_catalogs.Object "
"WHERE CONTAINS(POINT(‘ICRS’, coord_ra, coord_dec), "
"CIRCLE(‘ICRS’, 56.116475, -29.772755, 0.0015)) = 1 "
"AND shape_flag = 0 AND xy_flag = 0 AND i_kronFlux_flag = 0 ") ##“AND detect_isPrimary = 1”)
results = results.to_table().to_pandas()
Anyway, it is something happening very often and the only difference with the queries I usually do is the removal of the
All the “strange” detections are not detected as primary sources (i.e.,
detect_isPrimary = False)
Thanks Vincenzo! I think there are two issues here. The detect_isPrimary flag also has a subtlety that it forces the query to return only sources that are in the inner parts of a given tract/patch on the sky. Removing it means you might retrieve the same source(s) twice if they have been observed near the edge on a second tract/patch
that covers the same area (I think you see this in your sources with ID 1999853321250152633 and 2090400302820754014, which have detect_isPrimary = False and have essentially the same ra/dec.) This is one source of duplicate sources in your query.
However, it looks from your plot that you still see duplicate sources within just one patch/tract (e.g. the IDs 1999853321250187848 and 1999853321250152633). Is this the duplicate set you are asking about? If so, I think this happens when there is a child source whose centroid is very close to the peak of the parent blend (i.e. the source whose detect_isPrimary = False, and flag deblend_nChild is also not 0. In this case, detect_isPrimary = False indicates it is the “parent” blended source, and deblend_nChild holds the number of child sources that are produced by deblending it). One thing you can do to use a different set of flags. If you set detect_isDeblendedSource = True, it will return sources that: 1) have already been deblended (i.e. have no children themselves, thus excluding the parent blend duplicate) and 2) are in the inner region of a coadd patch/tract (i.e. no duplicates from two different images). The result is a set of galaxies that includes only unblended isolated sources or deblended children (i.e. the centroid of the nearest deblended child to the blended parent will be returned instead of the sometimes duplicate properties of the blended parent itself). Returning the parentObjectId can help keep track of this, since it is a unique ID for the parent blended source (and will be 0 for the blend itself).
I’ve attached the following code snippet that will let you separate the parent blend (for example your blended
parent with objID = 1999853321250152633) from the deblended children, allowing you to visualize these separately in your plot:
objID = 1999853321250152633 # this is the ID where your query returned detect_isPrimary = False & deblend_nChild > 0
wh_parent = np.where(results['ObjectId'] == objID)
wh_child = np.where(results['parentObjectId'] == objID)
Please let us know if this resolves your issue or if there’s a separate duplication issue that needs explanation!
Hi @ChristinaWilliams, thank you for digging deep into the issue!
I think removing the sources detected near the edges of patches/tractes solves most of the problems.
I still see possible spurious detections sometimes (even with the detect_isPrimary flag on). I understand that deblending is a complicated task and it is not exactly my field of experties. I am not doing a deep analysis how when it fails and why, but maybe I could show a list with some of these problems at next Stack Club/DP0 Assembly and we could discuss them.
Thanks for this thread, both.
@ChristinaWilliams I marked your response as the solution because I think it covers the bulk of the issue, as best we can for now.
@Vincenzo this would be great to raise in a future Stack Club or Delegate Assembly breakout. The next Stack Club is scheduled for Jan 13, but as always, feel free to start a new topic with more detailed deblender questions if/when you have them and we can keep digging.