-
-
Notifications
You must be signed in to change notification settings - Fork 7.9k
New colormap normalizations: sqrt, arcsinh #1780
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 our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
A question to the other developers: In the interest of preventing a combinatorial explosion by creating a class for each elementary mathematical function, would it be a better idea to have a class that will take a callable in its constructor, and have it normalise the data with respect to the underlying callable? For example, the user could call something like |
That would be my preference too |
@keflavich I am in agreement with you. The general 'take a callable' approach is more robust to changing requirements. |
+1 for this (this being the callable method). |
While preferable, It is not simple: the normalization classes also include the inverse function, else features like colorbar won't work right. |
self.nthroot = nthroot | ||
|
||
def __call__(self, value, clip=None, midpoint=None): | ||
|
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.
PEP8 compliance: there should only be one blank line here.
In principle, I think I'm in favour of this change. It definitely needs some tests though (they don't need to be pictorial). @keflavich - do you fancy trying to get this into v1.3? |
Yes, sounds like a good idea. I'll work on it. I guess I should start with autopep8 and then work on tests. When's the 1.3 deadline |
@keflavich autopep8 really doesn't work well: you might have to recheck everything by hand. |
Closing as the PR seems to have stalled. I love the idea of a callable in a Norm constructor though - if somebody wants to take that forwards I'd be more than happy to review. Cheers, |
(this may be best to regard as a feature request with sample code included; I doubt my code conforms to mpl standards)
Related to #1355, #1204, and #632, I think there should be more default normalizations available in matplotlib. This pull request includes two that I've made use of: a sqrt/n'th root normalization and an arcsinh normalization. The former is good for emphasizing values near 1 (e.g., ratios of like values) and the latter is useful for high dynamic range images where the low scales are to be emphasized (e.g., images of stars with nebulosity around them); it largely serves the same purposes as SymLogNorm but with a different shape.
In part, I often want to reproduce figures made by ds9, which includes a wider range of default normalizations.
If there's an easier way to accomplish what I'm doing - e.g. just wrapping a function in some
Normalize
subclass - please let me know; I'm not up to date on new features of matplotlib unless they're thoroughly exampled in the gallery.