raise limits to skip webp alpha tests for libwebp <= 0.2.1

[frispete]

Dear Alex & friends,

in my public openSUSE python repo, I maintain a huge stack of python related packages.
One nice thing about build serrvice is the possibility to build the packages for various distributions.
For my own needs, I limit them to openSUSE releases of various ages (as distribution independant build specifications are a great PITA, even for rpm based systems).

https://build.opensuse.org/package/show/home:frispete:python/python-Pillow

The one, that failed consistently was 12.3:

[ 98s] FAIL: Can we write a RGBA mode file to webp without error.
[ 98s] ----------------------------------------------------------------------
[ 98s] Traceback (most recent call last):
[ 98s] File "/home/abuild/rpmbuild/BUILD/Pillow-2.7.0/Tests/test_file_webp_alpha.py", line 86, in test_write_rgba
[ 98s] self.assert_image_similar(image, pil_image, 1.0)
[ 98s] File "/home/abuild/rpmbuild/BUILD/Pillow-2.7.0/Tests/helper.py", line 105, in assert_image_similar
[ 98s] ave_diff, epsilon))
[ 98s]

Obviously, this is due to a failing libwebp version.
Since you already have a skip for version 0.1.3, question is, why not raise the limits for webp alpha tests. Side effect: the (rare) users of this lib are being warned that way, too, if they check WebPDecoderBuggyAlpha.

[landscape-bot]

Repository health increased by 0.95% when pulling dd2266d on frispete:master into 5fa52f8 on python-pillow:master.

• 46 new problems were found (including 1 error and 45 code smells).
• 75 problems were fixed (including 37 errors and 20 code smells).

[coveralls]

Changes Unknown when pulling dd2266d on frispete:master into * on python-pillow:master*.

[coveralls]

Changes Unknown when pulling dd2266d on frispete:master into * on python-pillow:master*.

[wiredfool]

I don't think that this is the right way to go about it.

With webp 0.1.3, attempting to write a RGBA image as lossless webp resulted in an RGB image, and reading a RGBA image failed completely.

With 0.2.3, it appears that the algorithm works, but is a little different from later versions. There is a little more variation from the expected image. In this case it appears a difference of 3 rather than 1, which is totally reasonable for a lossy format, especially with an early version knowing that later versions do it better.

[frispete]

On Donnerstag, 5. Februar 2015 22:17:14 wiredfool wrote:

I don't think that this is the right way to go about it.

With webp 0.1.3, attempting to write a RGBA image as lossless webp
resulted in an RGB image, and reading a RGBA image failed completely.

With 0.2.3, it appears that the algorithm works, but is a little different
from later versions. There is a little more variation from the expected
image. In this case it appears a difference of 3 rather than 1, which is
totally reasonable for a lossy format, especially with an early version
knowing that later versions do it better.

Sure, the primary question is, where do we want to draw the line concerning
the term buggy: do we want to test and handle those deviations specially, or
do we generally suppress testing alpha channel mode results for these early
lib versions. Nobody is going to test all released lib versions, hence it
potentially ends in broken builds for certain environments.

Anyway, I've reverted the fix, and supplied the former (IMHO uglier) approach.
Test build with 5 different lib versions and two archs were successful.