Details
-
Type:
Story
-
Status: Done
-
Resolution: Done
-
Fix Version/s: None
-
Component/s: ip_diffim, pipe_tasks
-
Labels:
-
Story Points:10
-
Epic Link:
-
Sprint:AP F18-4
-
Team:Alert Production
Description
Frequency regularization in dcrAssembleCoadd.py is designed to suppress positive/negative sidelobes around bright sources, while not zeroing-out the noise. However, the sidelobe suppression leaves some sidelobes in place that I would naively expect to be reduced. These residual sidelobes may be affecting source measurement, and the regularization should be improved.
Attachments
Activity
mostly everything looks good. Random comments to address Ff there were plots you could attach to demonstrate you were able to do what you set out to do, that would be very helpful to review the conceptual part of the algorithm. If it proves very time consuming to do that, it is not strictly necessary.
Added two snapshots of DcrCoadds, before and after this change.
Before:
https://jira.lsstcorp.org/secure/attachment/34199/BEFORE%20DM-15636.png
After:
https://jira.lsstcorp.org/secure/attachment/34198/AFTER%20DM-15636.png
In each snapshot, a region of the reddest g-band subfilter is shown on the left, and the same subregion of the bluest subfilter on the right. The important detail to notice is that the negative/positive sidelobes see in the "before" images are significantly reduced in the "after" images.
Some of the stars look significantly rounder (which round stars are usually good) but I wanted to be sure that this modification is ok and expected. It seems to be the smoothing consequence of eroding then dilating the image. Will this smoothing have any implications i.e. will it make it hard to compare to images or something?
To be clear, the erosion and dilation is not operating on the subfilter images, but on boolean arrays that flag whether a given pixel exceeds a threshold. The threshold is relative to the average flux for that pixel across all subfilters, and any clipped pixels are set to that threshold value. So, the erosion and dilation simply ensures that there is a significant cluster of pixels all exceeding the threshold, and each pixel that remains flagged has it's flux set to the average flux in that pixel across al subfilters, times the clamp factor.
Thanks, that clears up my understanding of the code significantly! I am fine with you merging what you have anytime you are ready. For my understanding, what makes the stars much rounder is that the sides get evened out the by the averaged pixel value in each image?
Please note that this ticket also includes a pull request for pipe_tasks, which no longer shows up in Jira.