autoreduce/drizzle/combine.py's drizzle_kwargs_for (lines 33–38) sets driz_cr=multi, median=multi, blot=multi unconditionally whenever n_exposures > 1 — the classic AstroDrizzle route: reject a pixel by comparing each frame against a blotted-back median model. docs/design/hst_acs_pipeline.md Stage 3 documents this as the intended default ("cosmic-ray rejection (driz_cr, median-combine baseline)"), and there's currently no alternative CR method wired into TargetSpec/drizzle_kwargs_for.
The problem: on a steep flux gradient — a galaxy core, or any point source — the blotted median reference is systematically biased relative to any single dithered frame (sub-pixel registration differences shift where the peak lands frame-to-frame, so the "expected" median value at the true peak pixel reads low). driz_cr then flags genuine high-S/N core flux as a cosmic-ray hit and rejects it. We hit this directly reducing SLACS ACS/WFC F814W data: driz_cr destroyed ~37% of the deflector core flux, and loosening the rejection thresholds made it worse — the reference model is the fault, not the cut. Switching to LACosmic (van Dokkum 2001 Laplacian edge detection, run per-frame with no median reference needed) followed by a plain weighted-mean drizzle (median=False, blot=False, driz_cr=False) preserved the core essentially fully (peak 1.000, 1″ radius 0.979 of true flux) on the same data.
This isn't ACS/WFC3-UVIS-specific reasoning — it's inherent to comparing single frames against a blotted median at any steep gradient, so it should generalize to whatever instruments this affects here.
Suggested fix: make LACosmic-then-plain-mean an option (ideally the default) alongside driz_cr, similar to how final_pixfrac/final_kernel are already user-facing dials in TargetSpec.
Implementation trap to avoid (we hit this ourselves): if you add a LACosmic pass, resetbits must be 0 on it, not the AstroDrizzle default of 4096 — the default clears the very DQ bit the CR mask lives in, silently producing an unmasked drizzle that still looks plausible (our first attempt reported a flawless core=1.000 that turned out to be the no-CR image scored against itself).
Found while comparing against a sibling HST reduction pipeline; happy to share more detail on our measurement setup if useful.
autoreduce/drizzle/combine.py'sdrizzle_kwargs_for(lines 33–38) setsdriz_cr=multi, median=multi, blot=multiunconditionally whenevern_exposures > 1— the classic AstroDrizzle route: reject a pixel by comparing each frame against a blotted-back median model.docs/design/hst_acs_pipeline.mdStage 3 documents this as the intended default ("cosmic-ray rejection (driz_cr, median-combine baseline)"), and there's currently no alternative CR method wired intoTargetSpec/drizzle_kwargs_for.The problem: on a steep flux gradient — a galaxy core, or any point source — the blotted median reference is systematically biased relative to any single dithered frame (sub-pixel registration differences shift where the peak lands frame-to-frame, so the "expected" median value at the true peak pixel reads low).
driz_crthen flags genuine high-S/N core flux as a cosmic-ray hit and rejects it. We hit this directly reducing SLACS ACS/WFC F814W data:driz_crdestroyed ~37% of the deflector core flux, and loosening the rejection thresholds made it worse — the reference model is the fault, not the cut. Switching to LACosmic (van Dokkum 2001 Laplacian edge detection, run per-frame with no median reference needed) followed by a plain weighted-mean drizzle (median=False, blot=False, driz_cr=False) preserved the core essentially fully (peak 1.000, 1″ radius 0.979 of true flux) on the same data.This isn't ACS/WFC3-UVIS-specific reasoning — it's inherent to comparing single frames against a blotted median at any steep gradient, so it should generalize to whatever instruments this affects here.
Suggested fix: make LACosmic-then-plain-mean an option (ideally the default) alongside
driz_cr, similar to howfinal_pixfrac/final_kernelare already user-facing dials inTargetSpec.Implementation trap to avoid (we hit this ourselves): if you add a LACosmic pass,
resetbitsmust be0on it, not the AstroDrizzle default of4096— the default clears the very DQ bit the CR mask lives in, silently producing an unmasked drizzle that still looks plausible (our first attempt reported a flawlesscore=1.000that turned out to be the no-CR image scored against itself).Found while comparing against a sibling HST reduction pipeline; happy to share more detail on our measurement setup if useful.