Changed error type to allow for incremental WebP parsing

[radarhere]

Resolves #4745

Running code from the issue on a test image,

from PIL import ImageFile

p = ImageFile.Parser()
with open("Tests/images/hopper.webp", "rb") as f:
    new_data = f.read(1024)
    while not p.image and new_data:
        p.feed(new_data)

an error is triggered.

Pillow/src/_webp.c

Line 398 in 45003b7

PyErr_SetString(PyExc_RuntimeError, "could not create decoder object");

This is effectively an error being raised because the the image is truncated, and most truncation errors are OSError. So if we change it to an OSError, then it is handled by feed().

Pillow/src/PIL/ImageFile.py

Lines 413 to 418 in 45003b7

	try:
	with io.BytesIO(self.data) as fp:
	im = Image.open(fp)
	except OSError:
	# traceback.print_exc()
	pass # not enough data

This fixes the problem.

[wiredfool]

We should really discourage using this interface. While it's faster in some cases, when it doesn't work, it doesn't work in O(n^2).

[radarhere]

That inefficiency should be apparent to the user though - our API doesn't do anything to obscure it.

Are you saying that we shouldn't improve Parser any further, closing the issue as a 'wontfix'?

[wiredfool]

I'm not sure.

I'm pretty sure for most of the more recent formats that use external libraries, like jpeg2k and webp, probably the avif are going to to require the whole image eventually. It's also not uncommon that tiff style images have IFDs that are at the end of the file.

In that case, you're calling the parser with the first 1k, then 2k, then 3k, then 4k, and so on.

Metadata only, maybe ok.

[hugovk]

We should really discourage using this interface. While it's faster in some cases, when it doesn't work, it doesn't work in O(n^2).

Shall we merge this improvement and then deprecate the API?

It can then be made private and/or removed in Pillow 10.0.0 (2023-01-02) (2023-07-01).