Support for processing GIF animations

[jonnor]

Currently GIF is not supported. Adding plain support for GIF is not hard, just additional encoding/decoding support in GEGL/noflo-canvas.

Animations however is a different story. Each input file. In the simple case one processes the whole file (all frames) and outputs this to a new .GIF including all the modified frames. However, one might want to:

• Output the animation to .mp4, or XNG (#2) for optimized file size
• Extract only a couple of frames
• Process different frames with different graphs/parameters

[bergie]

See also https://imgur.com/blog/2014/10/09/introducing-gifv/

[forresto]

GIF quality is generally bad (or if good, takes a lot of care), so any processing will make it worse. Twitter's mp4 process totally murders quality. Over a certain file $ize optimization is understandable.

[jonnor]

GEGL can do processing by preserving the original GIF palette, which can be beneficial. Of course when doing a lot of filtering this is no longer possible (palette might not have required colors). If the image is not animated, might be better to output to JPG/PNG even if input is GIF.

[jonnor]

GEGL now can load GIF (or video) using ff-load, but saving animated GIF is not supported. Recommented way is to save out a video (using ff-save), then post-process it into a GIF with ffmpeg: http://blog.pkh.me/p/21-high-quality-gif-with-ffmpeg.html

[jonnor]

Considering to treat GIF inputs normally as video. Animations have time dimensions, and really, non-animated GIF should hopefully be extremely rare. Tricky thing is that in general consumers often don't know whether file is animated or not. And that right now, we actually don't either (no analysis of the input files before we hand them to GEGL).

[bergie]

The party creating the imgflo URL should know, though, since caliper provides animated: true.

[jonnor]

Out of scope