Repository navigation
Inconsistent plot with and without colorbar #15566
Description
Bug report
Bug summary
Plotting without colorbar gives different colors than plotting with one if all plotted values are equal. While this might be expected behaviour, I find it a bit strange. Plotting colorbar alongside the plot should only show the legend to what is plotted, not change the plot itself, I would say. We ran into this recently with geopandas geopandas/geopandas#1163 . Is this the intended behaviour of matplotlib or is it something which should be changed?
Code for reproduction
Without:
sc = plt.scatter(range(3), range(3), c=[1, 1, 1], cmap='viridis')With:
sc = plt.scatter(range(3), range(3), c=[1, 1, 1], cmap='viridis')
plt.colorbar(sc)Actual outcome
Expected outcome
I would expect colors to be the same in both plots above.
Matplotlib version
- Operating system: macOS
- Matplotlib version: 3.1.1
- Matplotlib backend (
print(matplotlib.get_backend())): module://ipykernel.pylab.backend_inline - Python version: 3.7.3
- Jupyter version (if applicable): 1.0.0
- Other libraries:
Activity
anntzer commentedon Oct 29, 2019
looks like a proper bug to me.
goes back at least as far as 2.0.0.
jklymak commentedon Oct 29, 2019
Guess this is an issue w scatter. What happens with imagesc or pcolormesh?
martinfleis commentedon Oct 29, 2019
@jklymak It is not. pcolormesh does exactly the same thing.
jorisvandenbossche commentedon Oct 29, 2019
Although it is inconsistent/surprising behaviour, it's a consequence of how the colorbar deals with constant values:
matplotlib/lib/matplotlib/colorbar.py
Lines 979 to 982 in fadc7fc
So here +/- 10% is added to the range, to have an actual colorbar to show. So given that this is also useful, not sure there is a clear fix / better option. You could only add 10% (and not subtract), so the actual value is not in the middle of the colorbar range but at the beginning. That would ensure the color does not change, but on the other hand also gives an odd look I think (although it's a corner case anyway ..)
jklymak commentedon Oct 29, 2019
Ok so the question is whether we should do that non singular expansion regardless of the presence of a colorbar.
jorisvandenbossche commentedon Oct 29, 2019
Ah, yes, that's also a way to get it consistent.
jklymak commentedon Oct 29, 2019
Anything we do will not be backwards compatible so this needs discussion.
a. keep centered as it is now
b. offset so its just x and x*1.1.
anntzer commentedon Oct 29, 2019
As always, it would be nice to reuse the nonsingular expansion of scales here.
jklymak commentedon Oct 29, 2019
You mean a norm/scale refactor?
anntzer commentedon Oct 29, 2019
Yes.
github-actions commentedon Jun 28, 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!
tacaswell commentedon Jun 28, 2023
We let #5467 which is the same issue close due to inactivity recently.
Repeating the discussion a bit:
Taken together this means if you create a colorbar with a singular norm then we have the options of:
I do not think any of the 3 things above are really changeable and given the options of expanding or raising, I think expanding is the better choice.
Even if we were to push the non-singular expansion down to the auto-scaling (like suggested #5467 (comment) ) I don't think it would actually solve this problem. The exact case of the OP would be solved, but users could still manually set the limits to be singular and would have even more reason to report a bug ("I asked for a singular norm and the colorbar 'fixed' it!").
I am also going to close this as "can't-fix" as we are in a jam. If in early 2000's the choice had been made to map singular norms to 0.5 we would not have this problem, but I do not think the up-side of fixing this issue is worth the cost of changing the singular behavior.
anntzer commentedon Jun 28, 2023
I did not think much about this recently but is it clear that mapping singular norms to 0.5 (or perhaps even more generically, using the already existing scale expansion behavior for scale-derived norms) is really too disruptive a change? (Seems like something for which we can have a normal deprecation period.)
greglucas commentedon Jun 28, 2023
I have also wondered the same thing, so seems like it might be worth considering. More to the point, I'm actually wondering if we could go even one step further and deprecate singular norms altogether. We could even add a
PendingDeprecationto emit a warning ifvmin == vmaxduring calls and see if we get many complaints. I'm not sure how many users want vmin==vmax, versus it just being due to singular data they passed in autoscaling that way. If it is simply due to the data they passed in it seems like we could auto-expand the limits within the norm and the user wouldn't care either way as long as the plot is a single color (now the midpoint rather than the low end of colors).timhoffm commentedon Oct 28, 2024
The associated PR #26307 has been re-milestoned. Applying the same here.