-
Notifications
You must be signed in to change notification settings - Fork 174
JP-3622 Update refpix step for NIR detectors to use convolution kernel #8726
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #8726 +/- ##
===========================================
- Coverage 76.89% 66.87% -10.03%
===========================================
Files 497 377 -120
Lines 45656 38099 -7557
===========================================
- Hits 35108 25478 -9630
- Misses 10548 12621 +2073
☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
This PR should be coordinated with spacetelescope/stdatamodels#321 |
@penaguerrero - This implementation looks pretty faithful to the example notebook we were given, but I think with a little more effort, we can integrate it more smoothly into the existing code base. This correction is intended to replace the rolling median in the side reference pixel correction, if d 8000 esired. I think it was probably implemented as a totally separate correction just to make it possible to call it as a post-hook for the step. What would be more natural for our code is to keep the existing side pixel identification and signal subtraction structure, and just add an alternate method that does the convolution, to sub in for the median_filter function as needed. That is, modify the calculate_side_ref_signal function here: jwst/jwst/refpix/reference_pixels.py Line 1021 in 0e86465
to check for a "use convolution" option. If desired, then an optimized convolution filter is called. If not, the median_filter function is called as usual. That is, we are not turning off side pixel correction and adding in a whole new correction, we're just replacing the low-level median filter for the side pixels with the convolution filter instead. Does that make sense? |
matching documentation with algorithm name change Co-authored-by: Melanie Clarke <mclarke@stsci.edu>
removing this to clear up description
Co-authored-by: Melanie Clarke <mclarke@stsci.edu>
Co-authored-by: Melanie Clarke <mclarke@stsci.edu>
I reran the full regtest set here: There are many failures, but I think they are all because of differences between CRDS test and ops. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this is now ready to go, pending merge of the stdatamodels PR and any coordination that needs to happen with CRDS.
@tapastro - I'm setting the build milestone back to 11.2, assuming we can sort out the remaining coordination issues for this build. |
Resolves JP-3622
Closes #
This PR addresses the addition of an optimized convolution kernel to the REFPIX step
Checklist for PR authors (skip items if you don't have permissions or they are not applicable)
CHANGES.rst
within the relevant release sectionHow to run regression tests on a PR