Bogus Tests/images/lena_webp_write.ppm?

[manisandro]

Running test_file_webp.py failed when comparing with Tests/images/lena_webp_write.ppm regenerating lena_webp_write.ppm with the command specified in the test script, i.e.

dwebp -ppm temp.webp -o lena_webp_write.ppm

resulted in a different (and, as far as the test is concerned, correct) file. Both webp and pillow are compiled with gcc 4.8 as available in fedora rawhide. Running the dwebp command with gcc 4.7 from fedora 18 resulted in the same file as with gcc 4.8. The md5sum of the (from what I can see) correct case is

$ cat lena_webp_write.ppm | md5sum
eb665b395973f41ceee62a8adc5f68ba

Are there other platform configurations on which the test with the shipped image passes?

[aclark4life]

I'm not sure I understand the issue, but the Travis-CI tests are passing FWIW: https://travis-ci.org/python-imaging/Pillow/builds

[manisandro]

The issue is that the shipped lena_webp_write.ppm causes the test to fail, and that regenerating lena_webp_write.ppm as described in the comment in test_file_webp.py results in a different file. It would be interesting to know what compiler travis is using, to check whether it is really a compiler issue.

[wiredfool]

It passes on Ubuntu 12.04. What it's trying to test is if we write out a webp file, do we get what we expect. If its failing on fedora, then the version of webp there is writing different bits for the same settings.

It's a bit of a trick to test if we're getting the right output from a lossy compression system. I wonder if we could do some measure of 'close' that would take the rms difference of two images, rather than requiring it to be identical?

[manisandro]

Or otherwise one could have the test require that libwebp-tools (providing the dwebp command) is installed (or otherwise skip the test) and then make the test create the reference image via a subprocess command. Not terribly elegant, but somewhat robuster.

[manisandro]

Thanks, that fixed the issue.