KeyError: 'WEBP' when trying to write animated WebP file

[jd20]

What did you do?

Attempt to save an image sequence to a *.webp file using save_all=True.

What did you expect to happen?

Write an animated WebP file. Looking at WebPImagePlugin.py, it's clear support hasn't been added for writing WebP image sequences yet, not sure if this is on the roadmap already or is terribly difficult to add, if it's pretty straightforward I might be able to contribute a PR for it.

What actually happened?

Receive an error: "KeyError: 'WEBP'"

What versions of Pillow and Python are you using?

Pillow 4.2.1, Python 3.6.0

Code to reproduce:

from PIL import Image
im = Image.open('image.png')
im.save('image.webp', save_all=True)

[hugovk]

I don't think anyone's planning on doing this (pipe up if you are), so PRs are welcome!

Edit: note there are some WebP rewrite PRs sitting around (https://github.com/python-pillow/Pillow/search?q=webp&state=open&type=Issues&utf8=%E2%9C%93) but they're not really moving.

[jd20]

Thanks for the links, doesn't look like any of those added support for animation anyway. I did get support for writing animated WebP files working locally, trying to add support for reading now, so I can write some tests.

One thing I'm wondering, does it make sense to have the WebP plugin implicitly convert unsupported formats (like L/P)? For example, to convert an animated GIF to WebP, it'd be nice to just do:

im = Image.open("test.gif")
im.save("test.webp", save_all=True)

But currently, that's not possible, since the WebP plugin throws on P mode, nor is it as simple as calling im.convert("RGBA") because then you lose all frames except the first one. So instead, the user has to extract each frame with seek(), convert it, and then pass it in to save(). There doesn't seem to be consensus on the proper behavior, the GIF plugin will automatically convert to P mode, and I see #2609, but some plugins still throw on unsupported modes. Thoughts?

[jd20]

I'm thinking to use the WebPAnimEncoder / Decoder API's for both single-frame and animated images, if libwebp is compiled with mux support. This will simplify the code significantly (the original code that calls the simpler API's will still get used if compiled without mux support), shouldn't have any negative effect on performance or compression (will need to confirm still, but the libwebp code seems to do the right things when only a single frame is present), and will also allow for incremental decoding, fixing #2483.