Uh oh!
There was an error while loading.Please reload this page.
- Notifications
You must be signed in to change notification settings - Fork7.9k
Fix twoslopenorm colorbar#20582
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 ourterms of service andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
Uh oh!
There was an error while loading.Please reload this page.
Conversation
bd4102c to78ddee0Compare
You could also write that |
Uh oh!
There was an error while loading.Please reload this page.
Uh oh!
There was an error while loading.Please reload this page.
78ddee0 to9ef1caaCompareAs a general question, do you actually want to add extrapolation to these functions, or should we just set the left/right bounds to -inf/+inf to not make any assumptions beyond the data interval? np.interp([self.vmin,self.vcenter,self.vmax], [0,0.5,1],left=-np.inf,right=np.inf) |
266eac6 toa2f5a77Compare@greglucas Yep, you are right, that works as well and is more elegant. |
a2f5a77 to38ad08eCompare| # defining your own norm. Note for the colorbar to work, you must | ||
| # define an inverse for your norm: |
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 wonder if it would make sense to create an abstract base class for Norms that raisesNotImplemented forinverse() so that it doesn't accidentally work with a colorbar? (I think right now it is inheriting the inverse from the standard "Linear"Normalize class. We could catch theNotImplemented in the Colorbar code and warn appropriately there that the inverse method needs to be implemented.
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 that would be sensible.
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.
#7320 seems related to that.
I feel like the custom norm example never intended the 0 to be in the middle; maybe it needs to be written another way? |
I wrote that example and indeed it's pretty common for water depths to have a different vertical scale than land relief. If you want the size of the color ranges to be proportionate you would make the color map disproportionate with more land colours than ocean colours. But that is the opposite of the desired effect here. |
Ah, I see that was mentioned in the |
The first sentence of the example says that it is the same as the TwoSlopeNorm example? |
Or I'm just blind today... |
PR Summary
Closes#20581
#20054 makes it so the scale on a colorbar is set via the norm, and the inverse of its norm. The problem with scales, and tickers, is that they seek ticks beyond the min/max of their axis. PreviouslyTwoSlopeNorm linearly interpolated between vmin and vcenter and vcenter and vmax, but anything beyond vmax or less than vmin was also mapped to 0 and 1. So in the broken example a tick was sought at -1000, with vmin =-500. The norm processed this as 0 instead of a negative number, and hence it showed up on the axis.
Here we fix that by simply doing some linear extrapolation on the TwoSlopeNorm and its inverse.
np.interpdoesn't have linear extrapolation by default, and we can't use scipy, so just do it by hand. (yes I know thatvcenter - 2 * (vcenter - vmin) = 2 * vmin - vcenter, but that is not as easy to parse).PR Checklist
pytestpasses).flake8on changed files to check).flake8-docstringsand runflake8 --docstring-convention=all).doc/users/next_whats_new/(follow instructions in README.rst there).doc/api/next_api_changes/(follow instructions in README.rst there).