Added alpha_quality argument when saving WebP images

[radarhere]

Resolves #7868

Adds alpha_quality argument when saving WebP images, as per https://developers.google.com/speed/webp/docs/api

[mzealey]

I'm not 100% sure if this is actually working and it's a little difficult to tell as unknown save flags are silently dropped.

I'm installing like:

git+https://github.com/python-pillow/Pillow.git#64c8c272711a0604f806b52941510ee4636fbae2=pillow 

and a grep of the PIL directory shows alpha_quality is matching in the webp binary file output.

I run a small script like

from PIL import Image image = Image.open("t.png") image.save("alpha_trans.webp", "WEBP", quality=60, method=6, exif=b"", alpha_quality=50)

with something with significant alpha such as http://moya-discover-assets.moya.app/moya/icons/sport/sportsbetting.png results in output like:

$ webpinfo -summary alpha_trans.webp  File: alpha_trans.webp ... Chunk ALPH at offset 30, length 4960 Chunk VP8 at offset 4990, length 2874 ...

Whereas with cwebp:

$ cwebp -alpha_q 50 -q 60 -m 6 t.png -o cwebp.webp $ webpinfo -summary cwebp.webp  Chunk ALPH at offset 30, length 1952 Chunk VP8 at offset 1982, length 2874

So I suspect somehow the flag is not making it through to the underlying library or there is some other variable that also needs tweaking if not going for alpha_quality==100?

[radarhere]

When I install this PR and run that code with that image, I get

Chunk ALPH at offset 30, length 1952 

So my theory would be this is working, but it's simply not installed correctly on your machine. If you run import PIL; print(PIL.__version__) with this PR, you should get 10.3.0.dev0. If you don't, it means you're using another version of Pillow.

Would it help if I put together a wheel of this for you? What OS/Python version are you using?

[mzealey]

So here's basically the setup that I'm using:

Dockerfile:

FROM python:3.12-slim-bookworm RUN apt update && \ DEBIAN_FRONTEND=noninteractive apt install --no-install-recommends --no-install-suggests -y nginx curl jq git openssh-client libcairo2 libnginx-mod-http-brotli-static libnginx-mod-http-brotli-filter && \ echo StrictHostKeyChecking=accept-new >> /etc/ssh/ssh_config # Extra for installing custom pillow version which includes support for webp # alpha compression. TODO: Remove this when pillow with # https://github.com/python-pillow/Pillow/pull/7872 merged is released. # This package list is taken from https://github.com/python-pillow/docker-images/blob/main/debian-12-bookworm-amd64/Dockerfile RUN DEBIAN_FRONTEND=noninteractive apt install --no-install-recommends --no-install-suggests -y \ gcc \ cmake \ libfreetype6-dev \ libfribidi-dev \ libharfbuzz-dev \ libjpeg-turbo-progs \ libjpeg62-turbo-dev \ liblcms2-dev \ libopenjp2-7-dev \ libtiff5-dev \ libwebp-dev \ libssl-dev \ meson \ netpbm \ zlib1g-dev WORKDIR /app COPY requirements.txt ./ RUN pip3 install --no-cache-dir -r requirements.txt

with requirements.txt having

git+https://github.com/python-pillow/Pillow.git#64c8c272711a0604f806b52941510ee4636fbae2=pillow 

I added the version printing to the test script and it's outputting the correct version as you say but still not compressing the alpha which seems really strange.

I'd assume library version doesn't make much of a difference but just in case:

root@f911fa2c381c:/app# dpkg -l |grep webp ii libwebp-dev:amd64 1.2.4-0.2+deb12u1 amd64 Lossy compression of digital photographic images ii libwebp7:amd64 1.2.4-0.2+deb12u1 amd64 Lossy compression of digital photographic images ii libwebpdemux2:amd64 1.2.4-0.2+deb12u1 amd64 Lossy compression of digital photographic images. ii libwebpmux3:amd64 1.2.4-0.2+deb12u1 amd64 Lossy compression of digital photographic images 

[radarhere]

I ran the Docker scenario you described, and received the same filesize output whether I specified alpha_quality or not.

Then I tried changing the pip requirement to

pillow @ git+https://github.com/radarhere/Pillow.git@webp_alpha_quality 

and the output file size changed.

I don't know why one requirement works and the other doesn't, but give that a try.

[mzealey]

Yes thank you this fixes it. Very strange - I'm sure the #commit approach worked with some other projects but it could perhaps be because of the dev on a different repo. All lgtm.