Details
-
Type:
Story
-
Status: In Progress
-
Resolution: Unresolved
-
Fix Version/s: None
-
Component/s: faro, meas_extensions_scarlet
-
Labels:None
-
Story Points:3
-
Epic Link:
-
Sprint:DRP S22B, DRP S23A
-
Team:Data Release Production
-
Urgent?:No
Description
Now that we've implemented procedures to skip blends based on size, saturation, number of children, etc., we should have metrics to keep track of the number of blends skipped for each cut to know how many blends and how many peaks are being cut.
The current metrics I'm thinking of are:
- total number of blends
- total number of detected peaks
- number of blends skipped because they were too large
- number of blends skipped because they had too many peaks
- number of blends skipped because they contained masked pixels
- number of peaks skipped because they contained masked pixels
- number of blends that failed
Feel free to add any other metrics that might be useful to calculate.
Attachments
Activity
Agreed about duplicate code/work. In this case I'm hoping to avoid this by creating a generic task to run measurements on a column (count the number of sources, calculate the mean, sum, etc) and create a selector to only choose parents. If that doesn't work out then I'll probably use the metric that you pointed to.
Note that blends never fail with the single-band deblender, so that column doesn't exist in the meas_deblender output catalog. The rest should work for both deblenders if you decide to implement them.
Fred Moolekamp
added a comment - Agreed about duplicate code/work. In this case I'm hoping to avoid this by creating a generic task to run measurements on a column (count the number of sources, calculate the mean, sum, etc) and create a selector to only choose parents. If that doesn't work out then I'll probably use the metric that you pointed to.
Note that blends never fail with the single-band deblender, so that column doesn't exist in the meas_deblender output catalog. The rest should work for both deblenders if you decide to implement them. 
Just found this issue. Do any of the metrics from
DM-27032(https://github.com/lsst/pipe_tasks/blob/main/python/lsst/pipe/tasks/metrics.py) help you? It would be nice to avoid duplicating work, where possible.(For that matter, Eric Bellm, do we want to use any of the metrics from Fred Moolekamp's list in ap_verify?)