Some context: The dithering pattern for the DEEP COSMOS field is tight, so artifact rejection is hard/impossible. Accordingly, there are many regions showing artifacts that bleed into the coadd and typically I see no source detections around these areas. This is not surprising as the footprints around these areas would understandably end up quite large and would be skipped according to the config parameter:
maxFootprintArea = pexConfig.Field(dtype=int, default=1000000, doc=("Maximum area for footprints before they are ignored as large; non-positive means no threshold applied"))
However, the size and extension of these areas looked a bit extreme to me, so I wanted to make sure I was interpreting this correctly. If this was indeed the case, the NOT_DEBLENDED mask should have been set for all pixels in the affected area.
I became suspicious/puzzled when I looked into the logs and did not find any warnings about footprints getting skipped. It turns out, the message from the deblender is at the log.trace level, so does not get printed to the logs. So, I set it to manually to WARN and reran multiband. Indeed I saw one instance:
multiBandDriver.deblendCoaddSources.singleBandDeblend WARN: Parent 43159138515025921: skipping large footprint (area: 2018438)
But only the one…and there seemed to be many “isolated” areas that I thought would also be affected. So I put a break in the deblender to display this one footprint before it skips over it:
The following shows the (large indeed!) footprint for this skipped source:
This monster parent source is indeed the catalog and can be identified by the deblend_skipped flag being set. So this should also turn up in the NOT_DEBLENDED mask plane. However, this is a look at some of the mask planes (along with all detections in the upper-right "ALL MASKS") for that image:
Doh! Looks like the NOT_DEBLENDED mask is empty.
1. The NOT_DEBLENDED mask plane does not seem to be getting set correctly.
2. We push the log level up to WARN for the footprint skipping so that someone looking in the logs (as I first did...) will see it easily.
I will make tickets to address these two issues.