np.asarray(PIL.Image) returns a read-only copy as of 9.2.0

[FirefoxMetzger]

I'm not sure if this is a bug or intended behavior, but as of v9.2.0 a snippet like the following produces an array (baz) which is read-only:

>>> from PIL import Image
>>> import numpy as np
>>> foo = np.ones((255, 255, 3), dtype=np.uint8)
>>> Image.fromarray(foo).save("tmp.png") 
>>> bar = Image.open("tmp.png")
>>> baz = np.asarray(bar)
>>> baz.flags
  C_CONTIGUOUS : True
  F_CONTIGUOUS : False
  OWNDATA : False
  WRITEABLE : False
  ALIGNED : True
  WRITEBACKIFCOPY : False
  UPDATEIFCOPY : False

In v9.1.0 the same snippet produces a writable array:

>>> from PIL import Image          
>>> import numpy as np
>>> foo = np.ones((255, 255, 3), dtype=np.uint8)
>>> Image.fromarray(foo).save("tmp.png")
>>> bar = Image.open("tmp.png")
>>> baz = np.asarray(bar)
>>> baz.flags
  C_CONTIGUOUS : True
  F_CONTIGUOUS : False
  OWNDATA : True
  WRITEABLE : True
  ALIGNED : True
  WRITEBACKIFCOPY : False
  UPDATEIFCOPY : False

I was wondering if this change was intentional, i.e., if we should rely on the new behavior. If it was, could you share what the motivation for it was? (so that I can see what we may need to update downstream.)

[radarhere]

This is a side-effect of #6394, which reverted a temporary change from Pillow 8.3.0 to workaround a bug in NumPy.

So as far as the Pillow side of the code is concerned, yes, I think the new behaviour is reliable.

[radarhere]

@FirefoxMetzger did that answer your question?

[FirefoxMetzger]

@radarhere Yes, that helps :) We can close this issue if you want.

Sorry for letting this slide; my PhD defense is coming up very soon and I am prioritizing that, so I am a bit behind on other projects recently.