Revert np.nan_to_num usage on rayleigh correction array #159
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Use a correction of NaN instead of a correction of 0
This was referenced Oct 6, 2022
Codecov Report
@@ Coverage Diff @@
## main #159 +/- ##
==========================================
- Coverage 88.03% 87.98% -0.05%
==========================================
Files 22 22
Lines 2473 2464 -9
==========================================
- Hits 2177 2168 -9
Misses 296 296
Flags with carried forward coverage won't be shown. Click here to find out more.
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. |
adybbroe
approved these changes
Oct 10, 2022
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
As discussed on slack, the usage of
np.nan_to_numthat is being changed in this PR was probably originally added with the idea that "if the correction calculations went wrong then we don't want to mask pixels, we just want to not correct them". The problem with this logic in some recent real world cases is that it is more "jarring" to see uncorrected pixels next to corrected pixels instead of black/transparent/masked pixels. See this MERSI-2 case where the angles at 1000m resolution do not go as far west as the band data pixels at 250m (for some reason) and this results in a 0 correction for these 5 or so pixels on the left side of the swath:If we use this PR's changes (and the way it was before PR #140) then these pixels are simply masked away as invalid pixels:
Note: The gray background in the first image was me playing around with the fill value.
I will work on making an issue to further investigate
np.nan_to_num's usage in Rayleigh correction at terminator regions.pytest pyspectralflake8 pyspectral