Consider changing standard test image size

[wiredfool]

I know we've just gone through a huge test update, but I think we should change the test image a bit more. (or at least, test with odd image sizes)

We're currently testing with a 128x128 image. There are at least 2 classes of (potential) bug that aren't hit by this:

• Always getting the x,y order right, and checking the right bounds. If they're the same, we're never going to notice. If we're doing it backwards and the sizes are different, something should error.
• There are some line size and padding code bits that are tickled with non aligned bits_samples_pixels.

I think it might be worth cropping the output of hopper to something like (121,127) and see what fails.

It's likely that a lot of the comparisons to the various hopper.* images would fail. It's probably not worth a changes that invalidates all of them.

Thoughts?

[hugovk]

Yes, can do.

It's likely that a lot of the comparisons to the various hopper.* images would fail. It's probably not worth a changes that invalidates all of them.

Can you clarify that?

[wiredfool]

Clarification -- I'd like to make a quick/small change to the output of hopper() to potentially tickle some bugs. I don't really want to get into redoing all the images again, nor touching all the tests.

[hugovk]

There we go:

https://travis-ci.org/hugovk/Pillow/builds/37319230

[wiredfool]

Interesting. There are definitely a few that look suspicious, like test_trns_p, test_extrema, and TestImageSpider.test_save, along with a bunch that are clearly just more fragile checks for the exact pixels in the image.

[hugovk]

This one is due to an assumption that the test image is square:

FAIL: TestNumpy.test_to_array
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/travis/build/hugovk/Pillow/Tests/test_numpy.py", line 112, in test_to_array
    _to_array(*mode)
  File "/home/travis/build/hugovk/Pillow/Tests/test_numpy.py", line 95, in _to_array
    self._test_img_equals_nparray(img, np_img)
  File "/home/travis/build/hugovk/Pillow/Tests/test_numpy.py", line 78, in _test_img_equals_nparray
    self.assertEqual(img.size, np.shape[0:2])
AssertionError: Tuples differ: (121, 127) != (127, 121)
First differing element 0:
121
127
- (121, 127)
?    ^    ^
+ (127, 121)
?    ^    ^

Can be made more robust by changing:

    def _test_img_equals_nparray(self, img, np):
        self.assertEqual(img.size, np.shape[0:2])

To:

    def _test_img_equals_nparray(self, img, np):
        np_size = np.shape[1], np.shape[0]
        self.assertEqual(img.size, np_size)

---

And possibly by changing:

        def _to_array(mode, dtype):
            img = hopper(mode)

To:

        def _to_array(mode, dtype):
            img = hopper(mode)

            # Resize to non-square
            img = img.crop((3, 0, 124, 127))
            self.assertEqual(img.size, (121, 127))

Worth changing either of those?

[hugovk]

A quick look into TestImageConvert.test_trns_p:

ERROR: TestImageConvert.test_trns_p
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/travis/build/hugovk/Pillow/Tests/test_image_convert.py", line 65, in test_trns_p
    l = im.convert('L')
  File "/home/travis/build/hugovk/Pillow/PIL/Image.py", line 864, in convert
    trns_im.putpalette(self.palette)
  File "/home/travis/build/hugovk/Pillow/PIL/Image.py", line 1472, in putpalette
    data = "".join(chr(x) for x in data)
TypeError: 'NoneType' object is not iterable

This can be minimally reproduced (using the original hopper()) with:

    def test_convert_after_crop(self):
        im = hopper('P')
        self.assertIsNotNone(im.palette)

        im = im.crop((0, 0, 127, 127))    # Triggers problem
        # self.assertIsNotNone(im.palette)  # im.palette is now None

        im.info['transparency'] = 0
        l = im.convert('L')

So after crop() (crop size doesn't matter) im.palette is None.

im.convert('L') succeeds if im.info['transparency'] = 0 is commented out, otherwise the same TypeError occurs.

[aclark4life]

Status? Looks like maybe this was merged. Please reopen if still an issue.

[hugovk]

Re-opening. This was some testing that identified a few things that still need addressing.

[aclark4life]

Roger that, thanks