Skip to content

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

Closed
wants to merge 5 commits into from

Conversation

keflavich
Copy link
Contributor

(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.

@dmcdougall
Copy link
Member

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 CustomNorm(np.sqrt, vmin=1, vmax=10).

@keflavich
Copy link
Contributor Author

That would be my preference too

@dmcdougall
Copy link
Member

@keflavich I am in agreement with you. The general 'take a callable' approach is more robust to changing requirements.

@tacaswell
Copy link
Member

+1 for this (this being the callable method).

@Tillsten
Copy link
Contributor

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):

Copy link
Member

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.

@pelson
Copy link
Member

pelson commented Apr 18, 2013

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?

@keflavich
Copy link
Contributor Author

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

@NelleV
Copy link
Member

NelleV commented Apr 18, 2013

@keflavich autopep8 really doesn't work well: you might have to recheck everything by hand.
On the other hand, the pep8 tool is very strict, but very useful.

@pelson
Copy link
Member

pelson commented Jan 9, 2014

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,

@pelson pelson closed this Jan 9, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants