JP-1489: Allow calc_gwcs_pixmap to compute NaNs for drizzle #5217
Conversation
Codecov Report
@@ Coverage Diff @@
## master #5217 +/- ##
==========================================
- Coverage 52.45% 52.43% -0.03%
==========================================
Files 406 406
Lines 36335 36371 +36
Branches 5629 5630 +1
==========================================
+ Hits 19061 19072 +11
- Misses 16099 16124 +25
Partials 1175 1175
Flags with carried forward coverage won't be shown. Click here to find out more.
Continue to review full report at Codecov.
|
| # other value. -1 is not optimal and may have side effects. But this is | ||
| # what we've been doing up until now, so more investigation is needed | ||
| # before a change is made. Preferably, fix tblot in drizzle. | ||
| pixmap[np.isnan(pixmap)] = -1 |
There was a problem hiding this comment.
So have you seen any bad side effects from this addition, since the same thing was causing a problem in forward drizzling?
There was a problem hiding this comment.
Ah, of course now that I think about it a bit more, I guess this really isn't a new thing for blotting. It was already there due to the resetting of pixmap values in resample_utils? And hence all you're doing is preserving that pre-existing behavior for blotting?
There was a problem hiding this comment.
Well, this is what it was doing before for all pixmap creation. Since we don't want it generally, but need it specifically for blotting, I moved it out of calc_gwcs_pixmap and put it here for blotting only.
I think it would be good to look at this, but I think there are other issue in outlier detection that are preventing good testing of this at the moment. So basically this line of code just keeps the status quo for blotting in outlier detection, for good or bad.
There was a problem hiding this comment.
Yeah, that's what I figured out post-comment.
Replacing NaNs with -1 in the pixel mapping for
drizzlewas causing these artifacts. When this was originally implemented,drizzlepixmap barfed when there were NaNs in the pixmap.And of course the reason this is showing up only in NIRSpec, as that NIRSpec is the only instrument where the WCS produces NaNs for pixels in the WCS bounding box. This is why we did not see it elsewhere.
See below for what the fix does for single-resampled
s2dfiles incalwebb_spec2for NIRSpec MOS data:Resolves #5013 / JP-1489