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:

• ForPointCollection (e.g. created byscatter()) `get_array() is None if explicit colors are given:

  import matplotlib.pyplot as pltimport numpy as npx = 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()

• ForAxesImage (e.g. created byimshow(), 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 somecan_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.

Ifget_array isNone we aren't doing a colormapping?

ForAxesImage 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 usercould define those, but probably is not.

@jklymak

Ifget_array isNone 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 forContourSets 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 forColorbar(ax, norm=norm, cmap=cmap) without a mappable, which creates a dummy ScalarMappable internally (actually thats the only reasonColorbar has parametersnorm andcmap). Unfortunately, this is not accessible viaFigure.colorbar() because that requires a mappable.

The current code is not clear as we can see from the confusion onget_array(), the inconsistent APIs betweenfig.colorbar() andColorbar. 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=0plt.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.