Alternate Cosmic Ray Rejection Option#2095
Conversation
- When present, should be an int/float threshold for cosmic ray rejection - Overrides default LACosmic routine - Makes cosmic ray mask by thresholding, and expanding by one pixel
the LA Cosmic cosmic ray finding algorithm, and instead identifies CR contaminated pixels as everything above a certain level
96ab8c4 to
dc7d8b8
Compare
kbwestfall
left a comment
There was a problem hiding this comment.
Thanks, @jhod0 ! I'm fine with adding this. My only request is some clarification in the parameter definition.
|
|
||
| from astropy.io import fits | ||
|
|
||
| import os |
| saturation = self.map_detector_value('saturation') | ||
| nonlinear = self.map_detector_value('nonlinear') | ||
|
|
||
| # crthresh = os.environ.get('PYPEIT_CRTHRESH') |
| defaults['crthresh'] = None | ||
| dtypes['crthresh'] = [int, float] | ||
| descr['crthresh'] = 'Crude threshold to detect cosmic rays. Overrides ' \ | ||
| 'other options and skips LA Cosmic' |
There was a problem hiding this comment.
I'd add a bit more to this.
- Specify that this just sets a threshold pixel value such that any value above this threshold is masked. You're using it to remove cosmic rays, but it's actually more general than that.
- Specify the context of the value the user should provide. I.e., can users simply set the value based on what they see in a ds9 inspection of the raw frame, or do they need to account for the gain, bias subtraction, etc.
- Make clear that the
growparameter is still used to grow the mask. I.e., "skips LA Cosmic" doesn't mean that all the L.A.Cosmic parameters are ignored.
|
just want to add that LA Cosmic also struggles mightily with Binospec data thanks to Binospec's thicc detectors. iirc, KCRM also uses thicc deep-depletion detectors for higher QE in the red. looking at the KCRM data in the dev suite confirms my suspicion. for science frames, we try to be strict about observers taking at least 3, preferably 5 or more, so that median-combining/sigma-clipping takes care of CRs. the main issue is with arc frames where the exposures are long enough to capture a lot of CRs (yes, our HeNeAr lamp is too faint), but there is usually only one per observing block. we are moving towards sharing configurations/calibrations between blocks so that multiple arc exposures can be taken at the end of the night. however, that's a bit complicated for a few reasons and there has been some pushback. i've worked up a scheme that does median filter across rows and then runs LA Cosmic on the residuals. this works great for arc frames (which just contain lines) and for Binospec (which has very straight lines). it also works great for long-slit and Binospec's IFU data, but MOS will require some more work/tuning. i think for MOS and KCRM the play will be to just median filter across the slits, but i need to test that idea in practice. am hoping to have at least a draft PR later this week. |
This PR adds a ProcessImagesPar parameter called
crthresh, which when present bypasses the LA Cosmic CR detection algorithm and identifies CR contamination as all pixels above a certain threshold.This is a crude approach, and is probably a "bad idea" 99% of the time. My use case for this is for KCRM, where LA Cosmic really struggles. I'm not sure what is unique about KCRM or its detector, but I invested more time than I would like trying to tune LA Cosmic to work well without finding a satisfying solution. The best LA Cosmic configurations I found erroneously rejected lots of good data, while still allowing some CR-contaminated pixels through. This
crthreshis the best approach I have found with my data. I can share comparisons of how this performs on my data set later.As this is a crude approach, I understand if the PypeIt devs would prefer not to allow this option. The implementation was very small and straightforward, so I figured I should make it available for discussion.