But we should also check the dims of the array?

Indeed. This is more difficult than I thought, and possibly, our API is not consistent:

• For PointCollection (e.g. created by scatter()) `get_array() is None if explicit colors are given:

  import matplotlib.pyplot as plt
  import numpy as np
  
  x = np.random.random(10)
  y = np.random.random(10)
  c = np.random.random((10, 3))
  
  pc = plt.scatter(x, y, c=c)
  print(pc.get_array())
  plt.colorbar()
  

• For AxesImage (e.g. created by imshow(), the array exists:

  data = np.random.random((10, 10, 3))
  
  im = plt.imshow(data)
  print(im.get_array())
  plt.colorbar()
  

This means we likely need some can_be_mapped() method to abstract away that mess. In any case, one needs to check every scalar mappable subclass how they handle things currently.

If anybody wants to pick this up, please post here. I'm not clear if I will have time to investigate in time for 3.5.

If get_array is None we aren't doing a colormapping?

For AxesImage the array exists, but its dims are >2, whereas if it is colormapped they are 2.

Just a note that I do sometimes make empty ScalarMappables just to make a defined colorbar without explicit linking to an image, so I'm not sure demanding an array should be a requirement.

sm = mpl.cm.ScalarMappable(norm=norm, cmap=cmap)
fig.colorbar(sm)

I do vaguely remember I used to have to force the array to something in the past (sm.set_array([]), but that requirement was lifted somewhat recently I think...

OK, so maybe there is something we can detect when we create the scalar mappable. In that case you have well-defined the norm and cmap. For an RGBA image the user could define those, but probably is not.

@jklymak

If get_array is None we aren't doing a colormapping?

I can't really say but I suppose it not a simple 1:1 relationship. In the two above examples only one has an array, but neither is colormapped. There's also special-casing for ContourSets in the code (but I didn't look into that).

@greglucas

Just a note that I do sometimes make empty ScalarMappables just to make a defined colorbar without explicit linking to an image

Indeed after looking up, this is the documented solution. There is however the possibility for Colorbar(ax, norm=norm, cmap=cmap) without a mappable, which creates a dummy ScalarMappable internally (actually thats the only reason Colorbar has parameters norm and cmap). Unfortunately, this is not accessible via Figure.colorbar() because that requires a mappable.

The current code is not clear as we can see from the confusion on get_array(), the inconsistent APIs between fig.colorbar() and Colorbar. And upon further inspection: Who owns the cmap and the norm? The ScalarMappable carries them around and the colorbar stores that internally, but it also stores norm and cmap again in its own attibutes. Posssibly, we should have a thourough look on the whole machinery.

And upon further inspection: Who owns the cmap and the norm? The ScalarMappable carries them around and the colorbar stores that internally, but it also stores norm and cmap again in its own attibutes. Posssibly, we should have a thourough look on the whole machinery.

Yes, getting all this sorted out before something like #19515 seems important.

Currently if we just do

norm = mpl.colors.Normalize(vmin=-1, vmax=1)

fig, ax = plt.subplots()
pc = ax.pcolormesh(np.random.randn(20, 20), norm=norm)
fig.colorbar(pc)
norm.vmin = 0
plt.show()

3.4.2

Master

I prefer the master behaviour, but the limits of the colorbar are not modified at draw time. Anyhow just an example of how this stuff is not properly sorted out for playing around with in real time.

Yes, updates / change events is a whole additional dimension.

See #19553 for the updates portion of this discussion ;) With that PR, the Colorbar norm gets updated to reflect the vmin and there are no lower ticks.