Problems when resizing cinemagraphs (animated GIFs)

Question

I'm having issues resizing cinemagraphs. If you don't know, they are gifs where only a portion of the image is animated, compared to a regular gif where the entire image is animated. Here is a node.js example:

// ![http://i.imgur.com/Qb1m0.gif][1]

var gm = require('gm')

var file = 'Qb1m0.gif',
    frags = file.split('.')

gm(file)
  //.noProfile()
  //.quality(80)
  .resize(200, 200)
  .write(frags[0] + '_200.' + frags[1], function(err) {
    if (err) console.error(err)
  })

// Result:
// ![http://i.imgur.com/eFqak.gif][2]

And equivalent cmd line code is:

gm convert Qb1m0.gif -resize 200x200 cinema_200.gif

Know what's going on?

Original animated GIF:

Resized animated GIF:

Answer 1

I do know ImageMagick better than GraphicsMagick. For ImageMagick the following statements apply:

• It is next to impossible to directly resize animated GIFs with a simple command line (such as the one you gave), if the GIF contains transparency.

• It is even difficult to do that if the animated GIF does not contain transparency.

I assume this is the same for GraphicsMagick, really.

Background explanation

If you look at your original GIF with identify, you'll see that not each frame has the same dimensions:

identify Qb1m0.gif
 Qb1m0.gif[1]  GIF 720x416 720x416+0+0    8-bit PseudoClass 256c 920KB 0.000u 0:00.009
 Qb1m0.gif[1]  GIF 471x122 720x416+160+75 8-bit PseudoClass 256c 920KB 0.000u 0:00.009
 Qb1m0.gif[2]  GIF 471x121 720x416+160+76 8-bit PseudoClass 256c 920KB 0.000u 0:00.009
 Qb1m0.gif[3]  GIF 471x123 720x416+160+75 8-bit PseudoClass 256c 920KB 0.000u 0:00.009
 Qb1m0.gif[4]  GIF 471x123 720x416+160+75 8-bit PseudoClass 256c 920KB 0.000u 0:00.009
 Qb1m0.gif[5]  GIF 471x123 720x416+160+75 8-bit PseudoClass 256c 920KB 0.000u 0:00.009
 Qb1m0.gif[6]  GIF 471x123 720x416+160+75 8-bit PseudoClass 256c 920KB 0.000u 0:00.009
 Qb1m0.gif[7]  GIF 471x123 720x416+160+75 8-bit PseudoClass 256c 920KB 0.000u 0:00.009
 Qb1m0.gif[8]  GIF 471x122 720x416+160+76 8-bit PseudoClass 256c 920KB 0.000u 0:00.009
 Qb1m0.gif[9]  GIF 471x123 720x416+160+75 8-bit PseudoClass 256c 920KB 0.000u 0:00.009
 Qb1m0.gif[10] GIF 471x123 720x416+160+75 8-bit PseudoClass 256c 920KB 0.000u 0:00.000
 Qb1m0.gif[11] GIF 471x123 720x416+160+75 8-bit PseudoClass 256c 920KB 0.000u 0:00.000
 Qb1m0.gif[12] GIF 471x123 720x416+160+75 8-bit PseudoClass 256c 920KB 0.000u 0:00.000
 Qb1m0.gif[13] GIF 471x122 720x416+160+76 8-bit PseudoClass 256c 920KB 0.000u 0:00.000
 Qb1m0.gif[14] GIF 471x123 720x416+160+75 8-bit PseudoClass 256c 920KB 0.000u 0:00.000
 Qb1m0.gif[15] GIF 471x123 720x416+160+75 8-bit PseudoClass 256c 920KB 0.000u 0:00.000

These variations in the dimensions are the result of frame optimizing the animated GIF has been subjected to in order to reduce file size.

There are other optimizations at play too, which do reduce the number of colors used. Both these types of optimizations don't combine well with the -resize operation.

-resize is designed for single images, and to make the resulting single image look as good as possible. This very often adds new color values to the image. This does contradict what GIF is designed for: using a strictly limited color table (maximum of 256 colors). In an animation sequence, the next image/frame's -resize may result in a completely different color table than the previous one produced -- but for a well working animation you'd need a common color table across all frames.

-resize handles each and every frame image totally separately from the other images and does not take into account 'frame optimizations' (which have the tendency to create a different width+height for each frame that's placed on the common canvas with its own offset).

Thus the resized images are far from ideal for saving to the limited GIF file format for single images, let alone for multiple frames of an animated GIF. Heavy color reductions in the resized images are the result.

Then there is the transparency problem: most animated GIFs do make heavy use of transparency. Transparency is frequently used to even achieve compression optimizations where normally the image's appearance wouldn't require transparency at all.

What happens in this case is this: -resize creates semi-transparent pixels in the overlay images. When the images are saved back to the GIF file format, these pixels are then converted to either full transparency or full opacity: both produce a heavy color distortion for the resulting animation, away from the original color.

General procedure

Generally the best procedure to resize animated GIFs is this:

1. Coalesce (de-optimize) the animation. This will create individual images of equal size for all frames of the animation.

2. Undergo a complete GIF optimization sequence for the animation: not just for frame optimization, but also for color optimization.

'Simple' command

To still try your luck with running a 'simple' resize command, you could try this:

convert                        \
  http://i.imgur.com/Qb1m0.gif \
 -coalesce                     \
 -resize 200x200               \
  cinema_200.gif

Result:

 

This command would work around the frame optimization problems. It would correct problems resulting from this, at the cost of increased file size.

However, it may still display 'staircase' artifacts when it comes to edges, because the resized frames will be horribly aliased. This is because anti-aliasing would require semi-transparent colors around the edges, but GIF cannot save the semi-transparent colors generated by the -resize operator.

Answer 2

You can also try to add -layers optimize For more details https://imagemagick.org/script/command-line-options.php#layers

Answer 3

There is also very nice unrelated to ImageMagick solution using gifsicle tool, it produces much smaller resulting gifs plus doesn't have any flickering problems, also has no special command-line args hence very simple, also works much faster. Use it like this:

gifsicle --scale 0.25 -i input.gif > output.gif 

or

gifsicle --resize 24x24 -i input.gif > output.gif