Imshow does not copy data array but determines colormap values upon call

[kgabor]

The following code produces a horizontal gradient plot instead of a horizontal line:

import numpy as np
import matplotlib.pyplot as plt
import matplotlib.cm

Z=np.zeros((100,100))
Z[50]=100
fig=plt.figure()
ax=fig.add_subplot(1,1,1)
ax.imshow(Z,cmap=matplotlib.cm.Greys)
Z[...]= np.arange(100.)[np.newaxis,:]

plt.show() 

Please note that if we comment Z[50]=100 the issue is not apparent as an all white figure is created as expected, but e.g. in Qt4Agg backend, mouseover values shows the altered Z values.

This means that imshow does not copy the data array but sets the color scale at the ax.imshow() call.

If data is intentionally not copied, I'd suggest adding a big warning about this behavior in the documentation and then the colorscale determination should be deferred until the figure is actually drawn. Otherwise the data should be copied.

• pip installed Matplotlib: 1.5.0, numpy: 1.10.1
• Ubuntu 14.04 python: 3.4.3

[tacaswell]

Data should be copied.

[efiring]

_AxesImageBase.set_data simply passes the input array through cbook.safe_masked_invalid, which explicitly does not copy. I don't remember whether at some point, perhaps long ago, there was a decision to save time and memory by avoiding the copy, or whether this is just accidental. In any case, maybe the thing to do is add a 'copy' kwarg to safe_masked_invalid and then change its first line to use that flag in a call to array(..., subok=True, ...) in place of the present asanyarray.

I can make a PR for that today.

[tacaswell]

If you throw a fig.canvas.draw() between calling imshow and changing Z it works correctly. We are deferring some operation a bit too long.

[efiring]

To prevent the problem illustrated here, it is essential to copy Z in imshow, as I proposed above. The only remaining question is whether this means we can remove a copy somewhere else, on the grounds that now we know we are safe. We tend to view the question of copying from the standpoint that we don't want mpl to modify an array that is referenced from outside mpl; but the issue here is from a different standpoint, that we don't want an array used inside mpl to be modified from outside.

[efiring]

Closed by #6422