autoreduce/psf/stars.py's find_stars() runs DAOStarFinder directly on the sci array passed in from pipeline.py's _psf(), which is whatever _combine() produced — currently always the driz_cr-rejected mosaic (see #61; there's no separate no-CR combine pass in the pipeline to draw from instead).
The problem: the same mechanism from #61 — a blotted-median reference reading low at a steep gradient — hits compact field-star PSFs even harder than extended galaxy cores, since their gradient is steeper. Stars get partially holed at the core or fully rejected before detection. We measured this directly: rebuilding our own ACS/WFC empirical PSFs from an un-CR-rejected pass (instead of the CR-rejected science pass) took the usable star count from 344 → 599 (+74%) across the sample, and for 4 lens/filter pairs it was the difference between falling back to a model PSF entirely and having a viable empirical build. The corrupted-star failure mode is particularly insidious because a star with a core hole can still pass a naive "peak is centred" sanity check while quietly biasing the ePSF shape.
Suggested fix: decouple "which pass is the delivered science product" from "which pass PSF stars are measured from." Even without changing the science-mosaic default, Tier-1 star extraction should prefer the least-CR-rejected pass available (a no-CR combine, if #61's fix adds one) — the built PSF kernel itself is pass-independent (point-source PSF shape doesn't depend on which CR pass produced the science image), so there's no correctness cost to sourcing stars differently than the shipped mosaic.
Depends on: #61, insofar as there's currently no no-CR pass to draw stars from at all — but worth tracking separately since "which pass feeds star-finding" is a distinct decision from "what CR method ships as the science default," and could regress again later even after #61 lands if nobody wires the two together.
Found while comparing against a sibling HST reduction pipeline; happy to share more detail on our measurement setup if useful.
autoreduce/psf/stars.py'sfind_stars()runsDAOStarFinderdirectly on thesciarray passed in frompipeline.py's_psf(), which is whatever_combine()produced — currently always thedriz_cr-rejected mosaic (see #61; there's no separate no-CR combine pass in the pipeline to draw from instead).The problem: the same mechanism from #61 — a blotted-median reference reading low at a steep gradient — hits compact field-star PSFs even harder than extended galaxy cores, since their gradient is steeper. Stars get partially holed at the core or fully rejected before detection. We measured this directly: rebuilding our own ACS/WFC empirical PSFs from an un-CR-rejected pass (instead of the CR-rejected science pass) took the usable star count from 344 → 599 (+74%) across the sample, and for 4 lens/filter pairs it was the difference between falling back to a model PSF entirely and having a viable empirical build. The corrupted-star failure mode is particularly insidious because a star with a core hole can still pass a naive "peak is centred" sanity check while quietly biasing the ePSF shape.
Suggested fix: decouple "which pass is the delivered science product" from "which pass PSF stars are measured from." Even without changing the science-mosaic default, Tier-1 star extraction should prefer the least-CR-rejected pass available (a no-CR combine, if #61's fix adds one) — the built PSF kernel itself is pass-independent (point-source PSF shape doesn't depend on which CR pass produced the science image), so there's no correctness cost to sourcing stars differently than the shipped mosaic.
Depends on: #61, insofar as there's currently no no-CR pass to draw stars from at all — but worth tracking separately since "which pass feeds star-finding" is a distinct decision from "what CR method ships as the science default," and could regress again later even after #61 lands if nobody wires the two together.
Found while comparing against a sibling HST reduction pipeline; happy to share more detail on our measurement setup if useful.