Some PCX files trigger OSError since 8.1.0

[glx22]

What did you do?

In OpenTTD/nml we use pillow to manipulate images, mainly cropping, but I also tested with show() and save().

I think it's related to 2f40926

What did you expect to happen?

I expect the images to be loaded as they were with previous (<8.1.0) pillow versions.

What actually happened?

Depending on the used file it fails to load with OSError: buffer overrun when reading image file or OSError: image file is truncated (0 bytes not processed). But not all images fail to load.

What are your OS, Python and Pillow versions?

• OS: Any (tested on Ubuntu, MacOS and Windows)
• Python: >3.5 (tested on 3.6, 3.7, 3.8)
• Pillow: 8.1.0

This is a simple test case with images that used to load fine. One still works, the two others trigger the different OSError

from PIL import Image

files = ["arctic_railwagons.pcx", "opengfx_generic_trams1.pcx", "opengfx_trains_start.pcx"]

for file in files:
    try:
        with Image.open(file) as im:
            print("{}:{} {} {}".format(file,im.format, im.size, im.mode))
            im.save(file + ".png")
    except OSError as e:
        print("Failed with '{}'".format(str(e)))

Images and test code in pillow-test.zip

[radarhere]

Hi. Thanks for being detailed in your report. Are we able to add any of those images to our test suite, and distribute them under the Pillow license?

[glx22]

Sorry for the delay, I had to check with the original author of the images.
You can use any of the images in your test suite and distribute them under the Pillow license.

[radarhere]

The specification states that 'BytesPerLine' 'MUST be an EVEN number.'
The two images that are failing here list the BytesPerLine as 371 and 409. So technically, they are malformed.

I've created PR #5214 to float the idea of reading them anyway.

[glx22]

It has been pointed to me that the BytesPerLine issue was fixed in GIMP 2 years ago. So re exporting pcx files is enough to fix them.

Anyway, even if the idea of reading them anyway seems to look nice, it may be better to just detect odd BytesPerLine and error with a nice message, instead of failing later while reading the data.