Another example where this PR is relevant is as follows:

importmatplotlib.pyplotaspltimportnumpyasnpfig,axes=plt.subplots(1,3,figsize=(8,2))im0=axes[0].imshow(np.random.random((5,5)))colorizer=im0.colorizeraxes[1].imshow(2*np.random.random((5,5)),colorizer=colorizer)axes[2].imshow(0.5*np.random.random((5,5)),colorizer=colorizer)fig.colorbar(colorizer,ax=axes)

Where acolorizer object is used to synchronize the cmap+norm of all subplots, and in that case it follows naturally that the colorizer object should also be the input for the colorbar.

(This is similar tohttps://matplotlib.org/stable/gallery/images_contours_and_fields/multi_image.html , which I will make PR for following this PR)

Just to be sure: Is this correct? - Previously colorbar must reference a ScalarMappable. If norm limits were not fixed, we use the ScalarMappable's data (if available) to autoscale, i.e. fix norm limits). The Colorizer now behaves like a scalar mappable without data.

I'm not yet 100% convinced, we need colorbars to accept colorizers right now.

• Advantage: You can create a bare colorbar without the need for a "dummy" mappable. - But how often do you need this?
• Disadvantage: The API and code becomes a little less clean because you allow different types.
• I'm torn on the shared colorizer example. It's fundamentally desirable that you can share a colorizer. - But I would say we are not really sharing, we are re-using. Technically, the example will have the same result if you usefig.colorbar(im0, ax=axes). This is because there's a skew in that autoscaling is done on the first array only (it's part ofimshow(), which calls,im._scale_norm()). Passing the colorizer gives a false impression/desire that the colorbar does not specifically reflect the first data.
  I think accepting a colorbar primarily makes sense if we could get this to take into account all data:

  colorizer = mpl.colorizer.Colorizer()axes[0].imshow(np.random.random((5,5)), colorizer=colorizer)axes[1].imshow(2 * np.random.random((5,5)), colorizer=colorizer)axes[2].imshow(0.5 * np.random.random((5,5)), colorizer=colorizer)fig.colorbar(colorizer, ax=axes)

  But that's difficult. You cannot fix the scale in the fist imshow. But you also cannot defer to thecolorbar() call because we don't have the data there. The only way I see would be a rearchitecting that norms could "collect" autoscaling i.e. unless fixed by some event, they would expand their range. Though I suspect that has its own set of problems.
  Unless we can get there, I'm not sure accepting a colorizer is a real advantage.

@timhoffm Thank you for considering this.

While I would of course have like to see this included, I cannot fault the logic leading you to the conclusion that this is not required.

In light of this, I have opened a new PR here, which simply updates the examples and documentation, but makes no changes to the API:#30112

Regarding auto-setting the norm, I am not convinced that it is worthwhile to seek a new solution here when multiple subplots are used, as I believe that best use is to set the limits manually, as is done in the example in the docs:https://matplotlib.org/stable/gallery/images_contours_and_fields/multi_image.html

norm = colors.Normalize(vmin=np.min(datasets), vmax=np.max(datasets))...

And we are better served by steering users to that solution rather than complicating the default behavior.

My opinion on this matter is informed by the fact that I find the auto-scaler to be fine for prototyping, but whenever I need to make a publication-quality or complicated figure, I find that I have to manually set the limits anyways. (i.e. the autoscaler sets limits to 0.007373 to 0.99633 when 0 and 1 and much more reasonable limits.) The convenience of the auto-scaler is great for simple plots, but once I have multiple plots that need to share a colorbar, I would argue that it is no longer a simple plot and the user can be expected to know how to set the limits according to their needs.