looks like a proper bug to me.
goes back at least as far as 2.0.0.

Guess this is an issue w scatter. What happens with imagesc or pcolormesh?

@jklymak It is not. pcolormesh does exactly the same thing.

sc = plt.pcolormesh([[2, 2], [2, 2]], cmap='viridis')
plt.colorbar(sc)

sc = plt.pcolormesh([[2, 2], [2, 2]], cmap='viridis')

Although it is inconsistent/surprising behaviour, it's a consequence of how the colorbar deals with constant values:

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

Ok so the question is whether we should do that non singular expansion regardless of the presence of a colorbar.

Ah, yes, that's also a way to get it consistent.

Anything we do will not be backwards compatible so this needs discussion.

1. leave as is
2. apply non-singular expansion before a norm is used and either:
   a. keep centered as it is now
   b. offset so its just x and x*1.1.

As always, it would be nice to reuse the nonsingular expansion of scales here.

You mean a norm/scale refactor?

Yes.

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!

We let #5467 which is the same issue close due to inactivity recently.

Repeating the discussion a bit:

• if you want a colorbar, the norm must be non-singular (or the transform to make the colorbar don't work as it must be finite size)
• in every other case there is no reason that a norm has to be non-singular and we map all singular values to 0 (acd19a1 picked up a comment that maybe degenerate norms should give 0.5, but chasing this all the way back, the behavior of giving 0 goes back to e34a333 which is the first reliable commit we have for most of the library from 2004)
• the norm of the mappable and the colorbar is shared (so they stay in sync!)

Taken together this means if you create a colorbar with a singular norm then we have the options of:

1. expand the norm as we do now
2. raise

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.

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

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

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 PendingDeprecation to emit a warning if vmin == vmax during 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).

The associated PR #26307 has been re-milestoned. Applying the same here.