Support for animated GIF images

[anvio]

Hi Chris,

After a long long night I finally managed to add support for animated GIF images to easy-thumbnails.

It uses images2gif.py to extract all frames as PIL images. These frame images get processed by the thumbnail processors like every other still image. After they have been processed they get merged into one animated GIF (see Thumbnailer.generate_thumbnail).

Some animated GIFs react very badly to "resample=Image.ANTIALIAS" when resized. Therefore, I had to add a new "resample" kwarg to the default scale_and_crop processor (see easy_thumbnails/processors.py:158). This kwarg can be used to override the default behavior of Image.ANTIALIAS to Image.NEAREST. The NEAREST resample mode gets set explicitly when a GIF is getting processed (see easy_thumbnails/files.py:301). The downside is that resized GIFs do not have the best quality but the compatibility is improved. Maybe this is something that the user can specify in the Django settings (quality or compatibility)?

I thought this feature would be nice to have in the official version of easy-thumbnails. So feel free to add it! If you have any questions, do not hesitate to contact me!

Cheers
Pascal

[anvio]

Oh, btw ... you have to set
THUMBNAIL_PRESERVE_EXTENSIONS = ('gif', )
in the settings file to make sure the image keeps the .gif extension.

[anvio]

Please consider this pull request as work in progress. I just noticed some problems:

• Some animations run at a faster speed than the original
• Some animations get displayed in the wrong color space
• There might be a memory leak. Just had a situation where my Gunicorn instances got unreachable.

[anvio]

I was able to solve a few problems:

• Animations do not run at a faster speed than the original anymore
• There are no more color space problems
• The "resample" kwarg in the default scale_and_crop processor is no longer needed and was removed

Further improvements:

• images2gif.py is no longer required to read the GIF images -> switched to default PIL functions

Still existing issues:

• Resizing the animations needs a lot of memory but I guess this is a general problem that comes with GIF processing. If someone has some ideas to reduce the memory footprint, feel free to contribute a patch

[Natim]

Nice feature to have :)

[SmileyChris]

This is great work, @pascal.beyeler

I wonder if this could be implemented as a source generator. I think it'd need some abstraction of the engine code too, but that would be a good thing.

The abstraction i was thinking of: making source processors smarter so they are used for saving the thumbs too (cycle through the classes, stopping at the first one that returns True from it's save method if it has one).

[siovene]

Hi, is there any chance of seeing this merged any time soon? I can't do without this feature.

[SmileyChris]

In it's current state, no. But with an abstraction of the engine code to allow source generators to save thumbs, and the base of this code added as a source generator, sure.

[anvio]

Hi Chris, please could you add the abstraction you are looking for? Afterwards, I will add the animated GIF support to the new structure.

[mkoistinen]

Hi all, how usable is this PR as-is today? I have a project that requires this functionality. Is there anything I can do to help it along? Documentation updates, perhaps?

[anvio]

@mkoistinen
Hi Martin, you could do some testing. This PR hasn't been used in production. I wouldn't start documenting this feature yet as it is not final. @SmileyChris seems to be a bit busy at the moment. So we may have to wait a bit longer until this PR finds its way into the master branch.

[SmileyChris]

Yeah, sorry that I've been a bit negligent of the project recently. Trying to catch up at the moment.

I really would like this to be abstracted rather than an integral part of the code. Maybe that will have to wait until my rewrite though - this has been an interesting bit to consider during my architecture of it. Currently my thinking is that images will have a wrapper that abstract both image processing and the save method. So there can be a separate source reader that finds an animated gif and returns an AnimatedGifWrapper that encapsulates any unique processing / saving logic.

[SmileyChris]

Ok, I put some more thought into this... so here's what needs to be done for this to be mergable.

There should be a separate source processor that checks if the image is an animated gif (otherwise it can just return and let the standard source processor do the work).

Instead of returning a PIL Image, it returns a wrapper class that contains all of the logic to split out the image to separate frames. Use a __getattr__ that passes PIL methods through to each frame and returns a new wrapper class with the altered frames (or if the method doesn't return an Image class, just return the first result [e.g. .size]). Override the save method to do the right thing.

Then you don't need to change much inside of easy-thumbnails core.

The trickiest part of this is that easy-thumbnails relies on the extension to find the image in cache rather than regenerating it (either thumbnail_extension or thumbnail_transparency_extention). My thoughts are at the moment that we should just save it using the thumbnail_transparency_extension (PNG by default) even though it's a gif. The browser should figure it out no matter what the extension anyway.

[SmileyChris]

There's a lot to change here. Reopen or create a new pull request when you're ready to resubmit.

[mkoistinen]

@anvio is this something you're still working on?

[anvio]

@mkoistinen Sorry, I am no longer working on this. We will soon move to a non-Python thumbnailing solution.

[benzkji]

a few years later: WIP PR #628