EDP2: blendedness is negative for ~85% of primary objects, and mostly unflagged

Forgive my post if I just completely messed something up!

In the EDP2 Object catalog, blendedness is negative far more often and far more extremely than
in DP1. It is defined as a flux fraction, so I expected it on [0, 1] apart from a small noise
floor. I would like to know whether this is known, and what to use for sample selection meanwhile.

I have data rights; everything below is aggregate counts from TAP at data.lsst.cloud. I am an
independent user, so please read this as a question rather than a data-quality report.

The comparison. 0.2 deg cone on ECDFS (53.13, −28.10), which both releases cover, restricted to
detect_isDeblendedModelSource = 1 so the populations are comparable. “Valued” excludes nulls.

Band Release Valued Negative % negative < −10
r DP1 44,588 115 0.3% 0
r DP2 21,140 17,854 84.5% 2,060
g DP1 44,194 162 0.4% 0
g DP2 21,389 17,874 83.6% 1,393

DP1 goes negative too — up to 39.5% of objects in the crowded Seagull field — but stays near zero,
which is what I would expect from a de-noised estimator where child and parent flux are nearly
equal. Across six DP1 fields (119,713 valued objects) none falls below −10. The most negative
DP2 value I have seen is −702,404. The TAP_SCHEMA description strings for blendedness and
blendedness_flag are byte-identical between the two releases, so I do not think I am comparing
different definitions.

The flag does not track it. r_blendedness_flag fires for only a third of the negatives, and
gets rarer as they get worse: 66% are unflagged below 0, 86% below −10, and 98.7% below −1000. So
the usual “filter on the failure flags” advice does not help here.

Why it matters. blendedness < 0.1 is a routine cleanliness cut, and because these values are
negative rather than large they pass it — the cut is inverted rather than merely noisy. In ECDFS,
24,949 DP2 objects pass it and 17,972 of those (72%) are negative. The same cut on DP1 is 1.7%
negative.

One lead. The extreme values track brightness, not blend size. The worst sit on bright objects
(r_psfFlux ~3e6 nJy, r ≈ 15), while parents with 39 peaks bottom out at −29 and parents with only
17 peaks reach −5568. For 1 − child/parent to reach −7151 on a child of 3.1e6 nJy, the parent’s
absolute-value-weighted flux would have to come out near 430 nJy — which looks like the parent half
of the ratio failing on bright objects rather than a deblending-topology problem. That is an
inference from the numbers; I have not looked at pixels.

-- swap dp2 for dp1 to see the control
SELECT COUNT(*) AS n FROM dp2.Object
WHERE CONTAINS(POINT('ICRS', coord_ra, coord_dec),
               CIRCLE('ICRS', 53.13, -28.10, 0.2)) = 1
  AND detect_isDeblendedModelSource = 1
  AND r_blendedness < 0

Caveats. ECDFS is common sky, but DP1 and EDP2 differ in camera (ComCam vs LSSTCam) as well as
pipeline version (v29 vs v30), so this is not a clean A/B on the deblender alone. I checked g and
r only — the sync TAP endpoint times out for me on the other bands. DP2 returns fewer objects and
more nulls in the same cone, so I have used fractions rather than raw counts throughout. EDP2 is
explicitly an early preview and this may be known or already fixed for the full release.

Possibly related: the saturation reported at the centres of bright galaxies in EDP2 deep coadds
(topic 12419). If bright-object footprints contain pixels masked or interpolated toward zero, a
parent flux measured over that footprint could come out far too small, which would produce exactly
this signature.

Questions

  1. Is this the downstream consequence of known issue 1 (poor deconvolution in crowded fields), or a
    separate problem in the blendedness measurement? The brightness correlation made me suspect the
    latter.
  2. Should blendedness_flag be catching these? The near-absence of flags below −100 is the part I
    find hardest to interpret.
  3. Is there a recommended way to select a clean sample from EDP2 meanwhile — a different column, or
    a blendedness BETWEEN 0 AND 0.1 style guard?

Happy to provide more detail if it would help: the full query set, the per-field breakdown across
all six DP1 fields, the unflagged-fraction table by severity, or counts for any other field or
band.