psphot fails to find PSF in uncrowded field with satellite trail

[rhl@…]

[This isn't a psmodules bug, but there's no bugzilla category for psphot].

psphot fails to find a PSF for the SDSS image 3225-g1-273. The image is uncrowded, but
has a satellite trail. I've added code to return a decent error message in this case [not just
print "error in code" followed by an assertion failure:

2006-08-21 14:37:14Z|apache2.astro.Princeton.EDU|A|apply_psf_model

error in radius

SIGABRT

but the underlying problem needs to be resolved. If I don't get to it, I can make the
data available. I'd attach it, but the FITS file's 6Mb.

[eugene]

yes, this is a problem because the peak finder ends up with a huge number of
detections along the trail, each of which has a similar shape, but not
appropriate to the PSF. I have a couple of parameters that can be used as a
hack (limiting the search space for the PSF clump). There are a couple of
better ways to handle this, though. One would be to detect and exclude lines of
peaks (which would exclude some other artifacts as well). Another would be to
do a better job on the peak finding (you've pointed out a couple of other
peak-finding issues that could be handled with slightly more intelligent
processing there).

thoughts?

[rhl@…]

Gene points out:

the psphotBasicDeblend does almost exactly what you describe (find common peaks above a

threshold).

It even happens before the PSF model is built, and it was my intention a while ago to use that
information to avoid the problem we are encountering. Looking at the code, though, it seems I

forgot

to ignore the blends when selecting possible PSF objects. Actually, it looks like the step
psphotBasicDeblend should come before psphotRoughClass, and the marked blends should just be
ignored when building the Sx,Sy plane

This is basically correct, but there are some bugs to be considered, namely that pmSourceRoughClass
sets the mode rather than ORing it into preexisting values (such as MODE_BLEND). With this change,
and a test in pmSourcePSFClump for MODE_BLEND, moving psphotBasicDeblend above
psphotRoughClass does allow this field to be processed.

N.b. If you set KEEP_PSF_CLUMP in psphot.config, the image used by pmSourceRoughClass is
kept in the metadata as PSF_CLUMP (and will be displayed by RHL's python wrappers).

[eugene]

moving so we can drop 'panpipes'

[eugene]

This type of failure mode is addressed by the footprint code. The entire trail is absorbed into a single footprint and not split up as it was. RHL should probably test this works on the failed image before closing.

[jhoblitt]

appears to be fixed