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:
// ![https://i.stack.imgur.com/fK3xn.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:
// ![https://i.stack.imgur.com/tv4Kq.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:
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: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
-resizeoperation.-resizeis 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-resizemay 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.-resizehandles 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:
-resizecreates 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:
Coalesce (de-optimize) the animation. This will create individual images of equal size for all frames of the animation.
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:
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
-resizeoperator.