Skip to content

Adding colorbar changes imshow plot color when vmin is close to vmax #5467

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.

Sign up for GitHub

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

Jump to bottom
Closed
IamJeffG opened this issue Nov 12, 2015 · 8 comments
Closed

Adding colorbar changes imshow plot color when vmin is close to vmax #5467

IamJeffG opened this issue Nov 12, 2015 · 8 comments
Labels
status: inactive Marked by the “Stale” Github Action topic: color/colorbar topic: images

Comments

@IamJeffG
Copy link

I can't tell whether this is an intended feature or a bug, so I'm going to run it by the group.

f = plt.figure()
mappable = plt.gca().imshow([[42]])

Here, we gave a single pixel, so the entire plot is the same color.
With default jet colormap, that single color is dark blue (the bottom of the jet cmap). So far so good.

f.colorbar(mappable)

Here, observe that since vmin==vmax (effectively), the colorbar defaulted to the midpoint of the colormap, now green. Luckily, the Axes from imshow, containing the data, changed too!

On one hand, I like that the colorbar shows context around the singular value. (I think due to this line.) On the other hand, over in Geopandas we plot patches one-by-one with face_color values from a normalized colormap, but adding this renormalization means the colorbar no longer matches the cmap I passed it.

Thoughts? If you tell me this is intended I'm willing to find a workaround to my use case. (Frankly I'm not 100% sure what I would expect matplotlib to do here instead.) Just wanted to get a second opinion.
@mdboom
Copy link
Member

mdboom commented Nov 12, 2015

Cc: @efiring

@tacaswell tacaswell added this to the next major release (2.0) milestone Nov 12, 2015
@tacaswell
Copy link
Member

We probably should push the range expansion logic up (down?) into ColorMappable.

@IamJeffG You might be better performance if you use PatchCollection and we will do the color mapping for you.

@IamJeffG
Copy link
Author

@tacaswell Thanks for the PatchCollections tip, they do give better performance! But sometimes we'll have a GeoSeries with multiple geometry types, requiring multiple Collections. I can't find a way to have two different Collections share the same colormap using collection.set_array(), so I still end up explicitly setting the colors on each Collection to the result of mappable.to_rgba(values) -- which still has the bug mentioned above.

@tacaswell tacaswell modified the milestones: 2.0.1 (next bug fix release), 2.0 (style change major release) Feb 1, 2016
@tacaswell
Copy link
Member

@IamJeffG mappable.set_map(cm) does not work?

@IamJeffG
Copy link
Author

@tacaswell Each collection re-normalizes the colormap to its own range of values. So if collection1 has values in (0, 5) and collection2 has values in (20, 25), each with set_map('RdBu'), I wanted collection1 (low values) to be in the reds and collection2 (high values) to be in the blues.

I was able to do this by setting set_clim to the absolute min and max on both collections. Problem solved! (The behavior mentioned in the issue title is still a problem though.)

@IamJeffG IamJeffG mentioned this issue Jun 28, 2016
Merged
5 tasks
@QuLogic QuLogic modified the milestones: 2.0.1 (next bug fix release), 2.0.2 (next bug fix release) May 3, 2017
@tacaswell tacaswell modified the milestones: 2.1.1 (next bug fix release), 2.2 (next feature release) Oct 9, 2017
@github-actions
Copy link

github-actions bot commented Jun 5, 2023

This issue has been marked "inactive" because it has been 365 days since the last comment. If this issue is still present in recent Matplotlib releases, or the feature request is still wanted, please leave a comment and this label will be removed. If there are no updates in another 30 days, this issue will be automatically closed, but you are free to re-open or create a new issue if needed. We value issue reports, and this procedure is meant to help us resurface and prioritize issues that have not been addressed yet, not make them disappear. Thanks for your help!

@github-actions github-actions bot added the status: inactive Marked by the “Stale” Github Action label Jun 5, 2023
@IamJeffG
Copy link
Author

IamJeffG commented Jun 8, 2023

I still notice the behavior from the issue title ("adding colorbar changes imshow plot color") but I'm not convinced if this behavior is buggy. Let's let this go. Closing.

@IamJeffG IamJeffG closed this as not planned Won't fix, can't repro, duplicate, stale Jun 8, 2023
@tacaswell tacaswell removed this from the future releases milestone Jun 8, 2023
@tacaswell
Copy link
Member

Thanks @IamJeffG .

Re-reading this, I think I agree. We are in a bit of a bind. If you want a colorbar, the norm must not be singular so our options are to expand the norm or to raise and I think this is a case where expanding is reasonable.

Currently if you set the norm to be singular after the colorbar is added it will re-expand itself.

@tacaswell tacaswell mentioned this issue Jun 28, 2023
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
status: inactive Marked by the “Stale” Github Action topic: color/colorbar topic: images
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
5 participants
@mdboom @tacaswell @QuLogic @IamJeffG @oscargus