Why is this restricted to images?
Why is this restricted to Normalize? (What about PowerNorm, LogNorm etc.?)

It probably shouldn't be restricted to images or Normalize. This is just a proof of concept quickly hacked together. So far, I didn't bother to check if it's straight forward to extend to other cases.

I think data is better than autoscale for the kwarg nam. I agree that this signature should be propagated to all of the Norm sub-classes.

I am less convinced by the class method.

How does auto normalization work now ( I’m away from my computer) If this goes in then it might be nice to make sure we don’t have multiple auto scaling algorithms.

Overall I’m not really sure this is needed but maybe has a small enough footprint to be useful.

• Parameter name autoscale changed to data.
• Added data parameters for Normalize subclasses (where it makes sense)

@jklymak auto normalization works via self.norm.auto_scale_None(self._A) in AxesImage. It's called when the image is created. By using the _None variant of the function we ensure that the scaling is determined by the first image that is connected to the Normalize instance. So the __init__() methods use exactly the same auto scaling algorithm.

As for the Normalize.apply_autoscale() class method, I use the global min/max of all supplied images as vmin/vmax. For the case of one supplied image, this is equivalent to giving the image data to the constructor. The generalization is straight forward. We don't have to bother with the None part vmin/vmax cannot be supplied externally (the image data are the only criterion here).

Remark on if this is needed

Normalize(data=...):

Probably I want to normalize to data more often than to vmin/vmax. One could argue, that I can calculate the respective values and just pass them to the existing parameters. From a minimalistic API point of view that is correct. However, matplotlib has a lot of redundant ways of doing things. Most of them for convenience (e.g. set line properties via kwargs, fmt-string, rc_context, on the created Line2D object).

I argue that this is such a case where convenience beats minimalism. In particular, normalizing to data feels quite straight forward.

Normalize.apply_autoscale():

I'm a bit divided if this method is necessary. On the one hand one can argue that Normalize(data=...) is very convenient and thus sufficient. The only disadvantage is that all the data need to be there before the first imshow so that I can construct the norm beforehand and pass it in. If that's not the case, it gets really cumbersome (5 lines of code just to get all images to the same scale).

So the question is: Are there significant real world cases in which I cannot use Normalize(data=...)? Or is it just the example which generates the data on the fly? If there are real-world cases (and I can imagine, people are loading and plotting data within a single loop), I would welcome a function that can autoscale and apply a norm to a number of images.

Probably I want to normalize to data more often than to vmin/vmax. One could argue, that I can calculate the respective values and just pass them to the existing parameters. From a minimalistic API point of view that is correct. However, matplotlib has a lot of redundant ways of doing things. Most of them for convenience (e.g. set line properties via kwargs, fmt-string, rc_context, on the created Line2D object).

I rarely want to normalize automatically by data (except for initial exploration), and if I do, I don't find doing it by hand too onerous. I don't see what's better about the list comprehension gather versus just a loop that checks for vmin/vmax. Worse, the gather seems memory intensive to me if I have a big data set.

Yes, we have lots of redundant ways to do the same thing. I'm not sure thats always a good thing 😉

Not 100% against this if there is really an audience, but it seems crufty to me.

It probably depends on your application if you want to normalize automatically. No point in arguing individual cases here (neither mine nor yours).

The "list comprehension" is actually a generator expression, and if anything less memory consuming and faster than a loop. That's actually what users should use if they have to do this themselves. 😉

Any additional feedback (positive or negative) on Normalize.apply_autoscale() from other devs would be helpful. If negative, I could remove that function to bring the merge of the data attribute part forward.

I think my very first comment still applies. Normalize is a general purpose class to normalize data. I'm not sure if it should handle AxesImages specifically. Or if it does, it should handle every mappable that has a get_array method (Why only images?).

Second, the norm is not updated when the images change. In that sense apply_autoscale is a one time only method. It may be more confusing than helping. Partially this may also be due to a classmethod named apply... (applying something should happen to the instance, but the instance does not store the images to apply anything.).

The new data argument seems sufficiently useful to devote an example to it (or change extend the existing one on that subject).

Ok, will remove apply_autoscale() later.

Unfortunately, the existing example does not benefit from the data argument, because the image data is generated on the fly while plotting. That was actually the motivation to have the apply_autoscale() class method.

The workaround would be to split the loop and first generate all the data, then create the norm and then plot all the data. But that's not an easy and natural workflow for the example either.

Maybe it's worth looking into why the following does not work:

import matplotlib.pyplot as plt
import numpy as np

fig, axes = plt.subplots(2,2)

data = []
norm = plt.Normalize(None,None)
for i, ax in enumerate(axes.flat):
    arr = np.random.rand(10,10)+i
    ax.imshow(arr, norm=norm)
    data.append(arr)
    
norm.autoscale_None(data)

plt.show()

If it was working as expected, there wouldn't be any need for the apply_autoscale() method I guess.

The docstring says

If vmin or vmax is not given, they are initialized from the minimum and maximum value respectively of the first input processed.

Probably, this is done when I pass the norm to Imshow. (Didn‘t check in the code)

• Removed Normalize.apply_autoscale()
• Rewrote the example to
  a) Start with a simple version using Normalize(data=...)
  b) Explain the more involved version when applying the norm after creating the images

What's new added.

I'm not seeing enough user-level simplification here to justify the PR. The example can be simplified a bit even without the PR, but I also find there is a bug in part of the example that is not related to the PR: the colorbar is not responding properly to changes in the clim unless applied to images[0]. I will make a new issue for that.

See #17052 for the bug report promised above.

Closing because there seems little approval of the idea. I'm not going to fight over it.