Details
-
Type:
RFC
-
Status: Implemented
-
Resolution: Done
-
Component/s: DM
-
Labels:None
Description
Our current star selectors return a list of PsfCandidate s instead of source records. This makes them clumsy for many operations.
I propose the following changes:
- Add a base class for star selectors. Have this base class provide a method that turns a source catalog into a list of PsfCandidate. The default implementation will probably suffice in all cases, but if not, this offers natural way to override it.
- Change the selectStars method to return an lsst.pipe.base.Struct that contains a catalog of sources that are believed to be stars.
- Make star selectors into tasks. They are already configurable objects. This has several advantages, including adding a log object and eliminating the need for a registry. I suggest that the primary method retain the name selectStars, but if people prefer to rename it to run I don't mind.
- Eliminate the star selector registry, unless it is still wanted.
Note that there are alternatives to returning a source catalog that might do just as well, though I think a catalog is more natural:
- Have the task flag stars. This is somewhat clumsy because it requires that the star selector add a field (whose name will presumably be a config parameter) and users must then scan the catalog to find stars. It does have the advantage of saving space, and users can easily find stars or non-stars equally easily. Which brings up a point discussed below.
- Return a list of source IDs. This is somewhat clumsy for users but saves space.
Will users ever want an easy want to identify non stars? Neither the current interface nor my proposed changes support. Obvious options include:
- Set a flag in the catalog instead of returning a catalog, as mentioned above.
- Return two two catalogs: stars and non-stars.
- Have a flag that controls whether the output is stars or non-stars.
Note that lsst.ip.diffim.DiaCatalogSourceSelector already returns a list of sources (an ordinary python list) rather than a list of PsfCandidate. It should be made the same as the others, and probably renamed from ...SourceSelector to ...StarSelector.
Implementing the code in
DM-5532brought up a few issues that I would like feedback on.Some stars may be rejected when making PSF candidates (is this usually due to inadequate selection, or inherent?). Thus by not always making PSF candidates we lose some suitability information. If this is important, it can be ameliorated by making run create the candidate list, which could down-select the star catalog and flag only the final stars.
At the other extreme, if we don't care about the fact that some stars cannot be made into good PSF candidates when selecting stars, then makePsfCandidates does not seem to be a natural method of star selectors. It uses two config parameters that are not needed by any star selector (except the second moment star selector, which also makes PSF candidates while selecting stars). To me it makes more sense for this to be a method of PSF determiners (e.g. implemented in a base class, and have the main method accept a star catalog), but that would expand the scope of this RFC. It could also be added to MeasurePsfTask or become standalone code. If it is added to PSF determiners then I'd be tempted to give them the same treatment as star selectors: a base class that is a task.
Every star selector seems to have its own set of bad flags used to reject sources as unsuitable. Why the disparity? Can we reduce or eliminate it (which will change behavior)? This could be done in
DM-5532or on another ticket.Note that reneged on keeping the star selector registry because we have no nice way to make subtasks from a registry; the constructor is called with too little information. In the long term we may want to implement subtask registries, since it would let us group related subtasks.
I think making PSF candidates should be simpler, so I filed DM-5578. That is not meant to be part of this RFC, I'm just noting it.