Fix image vlim clipping again #17636
Merged
Conversation
This file contains hidden or 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
We use the Agg resampling routines to resample the user supplied data to the number of pixels we need in the final rendering. The Agg routines require that the input be in the range [0, 1] and it aggressively clips input and output to that range. Thus, we rescale the user data to [0, 1], pass it to the resampling routine and then rescale the result back to the original range. The resampled (shape wise) data is than passed to the user supplied norm to normalize the data to [0, 1] (again), and then onto the color map to get to RBGA. Due to float precision, the first re-scaling does not round-trip exactly in all casses. The error is extremely small (8-16 orders of magnitude smaller than the data) but for values that are exactly equal to the user supplied vmin or vmax this can be enough to push the data out of the "valid" gamut and be marked as "over" or "under". The colormaps default to using the top/bottom color for the over/under color so this is not visible, however if the user sets the over/under colors of the cmap this issue will be visible. closes matplotlib#16910
There are 7 pixels in the bi-linear interpolation that have changed by at most 1 bit per channel.
anntzer
approved these changes
Jun 15, 2020
|
postci |
jklymak
approved these changes
Jun 15, 2020
tacaswell
added a commit
to tacaswell/matplotlib
that referenced
this pull request
Sep 11, 2020
closes matplotlib#18415 We need to special case when rescaling the user input for interpolation with LogNorm. The issue is that due to the inherent precision limits of floating point math we can end up with errors on the order if 1e-18 of the overall data range when rescaling. If the bottom vlim is close to 0 and the top is order 10e20 than this error can result in the rescaled vmin being negative which then fails when we (temporarily) change the vmin/vmax on the norm. We started adjusting the vmin/vmax to work around the same issue with float precision in matplotlib#17636 / 3dea5c7 to make sure that values exactly equal to the limits did not move across the boundary and get erroneously mapped is over/under. Long term we may want to add the ability for the norms to suggest to their clients what the constraints on the vmin/vmax are, but hard-coding a special case for LogNorm is the pragmatic solution.
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.
PR Summary
We use the Agg resampling routines to resample the user supplied data
to the number of pixels we need in the final rendering. The Agg
routines require that the input be in the range [0, 1] and it
aggressively clips input and output to that range. Thus, we rescale
the user data to [0, 1], pass it to the resampling routine and then
rescale the result back to the original range. The resampled (shape
wise) data is than passed to the user supplied norm to normalize the
data to [0, 1] (again), and then onto the color map to get to RBGA.
Due to float precision, the first re-scaling does not round-trip
exactly in all casses. The error is extremely small (8-16 orders of
magnitude smaller than the data) but for values that are exactly equal
to the user supplied vmin or vmax this can be enough to push the data
out of the "valid" gamut and be marked as "over" or "under". The
colormaps default to using the top/bottom color for the over/under
color so this is not visible, however if the user sets the over/under
colors of the cmap this issue will be visible.
closes #16910
PR Checklist