Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Add symmetric norm for colormaps #1806

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
endolith opened this issue Mar 4, 2013 · 11 comments
Closed

Add symmetric norm for colormaps #1806

endolith opened this issue Mar 4, 2013 · 11 comments
Milestone

Comments

@endolith
Copy link
Contributor

endolith commented Mar 4, 2013

There was previously discussion about this but I don't think it ever happened:

Yes, that is exactly what I have in mind. I have a branch started to do this, but it is not ready yet. I am thinking of a kwarg called "vmid" to go with "vmin" and "vmax", the idea being that if it is not None then it expands any specified or autoscaled range in the manner you describe.

#875 (comment)

Just wanted to note here that I have a SymmetricNorm class which auto-scales evenly around a centre point.
It sounds like it could do the trick (and potentially avoid mutually exclusive keywords) and I'd be happy to share.

https://github.com/SciTools/iris/blob/master/lib/iris/palette.py#L164

@phobson
Copy link
Member

phobson commented Dec 11, 2013

I implemented this another way for my own use:
https://gist.github.com/phobson/7916777

Personally, I think a vcenter kwarg would be great -- especially if it could propagate to all the methods already using vmin and vmax. That sounds like a pretty big effort, however.

@tacaswell
Copy link
Member

@endolith @phobson If either of you want to get a PR together, we can try to get this in 1.4, otherwise, I have tagged this for 1.5

@phobson
Copy link
Member

phobson commented Jan 24, 2014

@tacaswell do you think that simply trying to add a vcenter kwarg to colors.Normalize is a good place to start?

The other question is what would this PR really being trying to accomplish? More specifically, is doing something like this notebook without having to create a totally new colormap the desired end result? http://nbviewer.ipython.org/gist/phobson/7916777

@tacaswell
Copy link
Member

I think the simplest thing to add is @efiring suggestion to, if vcenter in passed in push out which ever of vmin and vmax is closer to make the range symmetric (to basically accomplish the upper-right graph from your notebook).

@phobson
Copy link
Member

phobson commented Jan 25, 2014

@tacaswell taking a stab at this now.

@tacaswell
Copy link
Member

@phobson Did anything come of this?

@tacaswell tacaswell modified the milestones: unassigned, v1.5.x Nov 26, 2014
@phobson
Copy link
Member

phobson commented Nov 26, 2014

I've got an outdated branch on a machine and I could never get all of my edge cases to pass their tests. Basically all I'm trying to do. 

Knowing what I know now about MPL's internals, I think a separate subclass would be best and could probably take a look at that tonight. The other option is to add the "vcenter" kwarg to the main Norm class. But that seems like a bad idea. Thoughts?


Sent from Mailbox

On Wed, Nov 26, 2014 at 2:25 PM, Thomas A Caswell
[email protected] wrote:

@phobson Did anything come of this?

Reply to this email directly or view it on GitHub:
#1806 (comment)

@tacaswell
Copy link
Member

On one hand, a new class would be the least disruptive change, on the other hand, I think it would basically be the Normalize class with slightly different __init__.

On balance, I think a sub-class with arguments like SymNorm(center, half_width) is probably the best way to go because

  • no chance of breaking existing code
  • simple (minimal complicated logic, over-specified arguments)
  • intuitive to find with out having to understand said complicated logic/precedence rules

@tacaswell tacaswell modified the milestones: v1.5.x, unassigned Nov 26, 2014
@phobson
Copy link
Member

phobson commented Nov 27, 2014

#3858

@petehuang
Copy link
Contributor

Tracing related PRs, it seems like the most current related work sits in #7294

@tacaswell tacaswell modified the milestones: 2.1 (next point release), 2.2 (next next feature release) Oct 3, 2017
@jklymak jklymak modified the milestones: needs sorting, v3.4.0 Jul 28, 2020
@QuLogic QuLogic modified the milestones: v3.4.0, v3.5.0 Jan 27, 2021
@QuLogic
Copy link
Member

QuLogic commented Jul 8, 2021

Implemented in #17709.

@QuLogic QuLogic closed this as completed Jul 8, 2021
@QuLogic QuLogic modified the milestones: v3.5.0, v3.4.0 Jul 8, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants