Legacy ImageMagick Discussions Archive

Start with this 1.0-megabyte 720-page PDF†, which is to be converted to an endless 720-frame GIF animation of not-too-great size.

Method 1
• Open in GraphicConverter;
• Say to 720 GIF files;
• Use File > Convert & Modify… to join into an animation, endless, 0.06 second delay;
• Open in GIMP and resave.
This results in a 4.6 megabyte animation with a nastily distracting flickering background.

So I seek help, and ImageMagick is suggested, version 6.4.6 being downloaded and installed (though convert -version returns “Version: ImageMagick 6.3.3 03/06/07 Q16”).

Method 2 takes about 40 minutes to make a flicker-free (nice!) animation, but of 5.1 megabytes. Using optimise-plus did no better. Switching the order of optimisation and the single-colour-table-ification also fails to shrink the size.

Please, how can I shrink this further? At least as far as GIMP shrunk it (though without GIMP’s flicker imperfection), and ideally, much much smaller?

† For those foolish enough to care, the PDF was generated by a 5.6kb PostScript file the first few lines of which define the controlling parameters. And yes, I know, PostScript isn’t the obvious environment in which to do transformations of the complex plane—but that isn’t the problem here.

Repost of my answer to this problem...

I took a look and the postscript contains a HUGE number of frames.

I would suggest a heavy reduction in the overall number of frames used for your final GIF animation. This will achieve a enormous amount of saving without detrimental effects. If frame reduction is not an option GIF is the wrong file format, you will need to go to a video format instead, but video formats do not 'loop'. A Flash video format may be suitable for web use. Flash could generate this animation directly as a vector image rather than as a raster image.

For color optimization I would generate a common color map from the images. It shouldn't be too big a problem. say the 7 colors, background, black, and a few colors between those and the background, plus transparency for optimization. This color map may need to be generated. I would not use any 'dither' (turn it off) so as to avoid any 'dither speckle'.

And while frame optimization will not generate much saving (though some is to be had (whole image is changing from frame to frame) transparency (compression) optimization should improve the overall result. This is all part of the default -layers Optimize operation in IM.

Addendum....

The flickering artifacts in GIMP will be caused by the disposal method use, The large size of the GIF animated images, and the need to overwrite the frames faster that a GIF animation can readily archive. Basically the GIF animation can not render the frames fast enough. Some animators may be able to do this, but you are basically going beyond what is typical of GIF animations.

Reduce the number of frames, and optimize the animation to get a better GIF disposal and optimization.

Thank you for the help. I didn’t see the first post of which this is the “repost”, so thank you for reposting.

The cute property proved by the Möbius transform is that, if the coloured circles fit between the black rings, then they fit whatever the starting position of the first coloured circle to be placed. Demonstration of that requires numerous starting positions, and hence the 720 frames. Using fewer colours would allow fewer frames, as a small proportion of 360° would have to be traced before looping. Might try that.

GIMP’s flicker problem appeared to be variation in the background grey: presumably caused by one colour table per frame. But that makes its half-meg saving all the more impressive.

Flash eh? Hi ho, hi ho, it’s off to google I go.

First ‘post’ found in my spambox—for which belated thanks.