Support for Pillow v10.1 (re: setting image.mode)

[tcompa]

Hi there, and thanks for your support.

In https://github.com/imageio/imageio/blob/master/imageio/plugins/pillow.py#L312, the mode attribute of a PIL.Image object is set directly, as in

image.mode = desired_mode

I think this is not working any more as of the recent Pillow v10.1:

If you attempt to set the mode of an image directly, e.g. im.mode = "RGBA", you will now receive an AttributeError. This is not about removing existing functionality, but instead about raising an explicit error to prevent later consequences. The convert method is the correct way to change an image’s mode.
(https://pillow.readthedocs.io/en/stable/releasenotes/10.1.0.html#setting-image-mode)

---

The minimal failing example would be something like

from imageio.plugins.pillow import Image

img = Image.Image()
img.mode = "RGBA"

This example goes through with Pillow v10.0, but with Pillow v10.1 if fails as in:

Traceback (most recent call last):
  File "/tmp/x.py", line 4, in <module>
    img.mode = "RGBA"
AttributeError: can't set attribute 'mode'

EDIT: the test above is with imageio 2.31.5

---

(original issue in our repo, for the record: fractal-analytics-platform/fractal-tasks-core#570)

[FirefoxMetzger]

👍 good find. This does break our pillow plugin in a few places, because we have reasons to want those later consequences.

In a nutshell, the convert function from pillow doesn't allow raw modes as input; however, using them allows us to do certain performance optimizations. For example:

imageio/imageio/plugins/pillow.py

Lines 289 to 312 in 0bbf196

	elif image.format == "PNG" and image.mode == "I":
	# By default, pillows unpacks 16-bit grayscale PNG into 32-bit
	# integers due to limited 16-bit support in pillow itself. However,
	# recent versions can directly unpack into a 16-bit buffer, which is
	# more correct (and more efficient) in our scenario.
	if sys.byteorder == "little":
	desired_mode = "I;16"
	else: # pragma: no cover
	# can't test big-endian in GH-Actions
	desired_mode = "I;16B"
	try:
	Image._getdecoder(desired_mode, "raw", "I;16B")
	except ValueError:
	warnings.warn(
	"Loading 16-bit (uint16) PNG as int32 due to limitations "
	"in pillow's PNG decoder. This will be fixed in a future "
	"version of pillow which will make this warning dissapear.",
	UserWarning,
	)
	else: # pragma: no cover
	# Let pillow know that it is okay to return 16-bit
	image.mode = desired_mode

I need to see if/how we can keep this functionality given the recent changes.

[FirefoxMetzger]

I tried to "sidestep" the Image.mode problem by setting Image._mode instead until there is a better solution available.

Unfortunately, I found some additional problems related to GIF writing (among other things, one of our test images is now detected as a "compression bomb" by Pillow) and noticed that the JPEG writer is flakey on my local Mac (produces non-deterministic results that cause sporadic test failures).

Long story short, I will pin Pillow to v10.0.0 until I can take a better look at all the changes introduced by pillow v10.1 (PR lives here #1046).

[mgorny]

Ping. Have you been able to make any progress? Given the history of security vulnerabilities in pillow, we're a bit nervous about the pin. FWICS the newest vulnerability is in <10 but this can change at any moment.

[FirefoxMetzger]

A little, but it is still not done. I found a solution for the problems that Pillow v10.1.0 causes in our old Pillow plugin. Now all tests pass locally on my Windows workstation but still break on CI on Linux, so I'm currently looking into those.

[FirefoxMetzger]

@mgorny Done. ImageIO once again works with all recent pillow versions and I've removed the pin. Will be part of Monday's release :)

[mgorny]

Thank you!

[GaetanLepage]

@mgorny Done. ImageIO once again works with all recent pillow versions and I've removed the pin. Will be part of Monday's release :)

Thanks so much @FirefoxMetzger ! Do you know if the next release will happen soon ?

[FirefoxMetzger]

Thanks for the ping @GaetanLepage . It should have been released on Monday, but was blocked by failing tests on CD (the same tests passed in CI so this is an interesting failure).

I will have a look and trigger a release after I fixed the problem :)

Edit: the reason for the failure is that pyav has released a new version major over the weekend and this is breaking one of our tests :)