Bdtyktl

I am using ImageMagick to turn a collection of pngs into a single gif. I want this gif to loop as quickly as possible.

This is approximately the output I expect (courtesy of Wikipedia):

This is the output I actually get:

On my browser (Firefox 17), the expected gif runs more than twice as fast as the actual gif. This surprises me, because I specified that each frame should have 0 delay.

First I created 36 pngs by exploding the gif borrowed from Wikipedia:

--caution: command generates 36 pngs

convert.exe newton.gif newton_%d.png

Then I used coalesce to recombine the pngs into one gif.

convert.exe -dispose none -delay 0 newton_%d.png[0-35] -coalesce output.gif

identify confirms that each frame has no delay:

identify.exe -format "%T, " output.gif

0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,

This is, in fact, less delay than the original:

identify.exe -format "%T, " newton.gif

5, 2, 2, 2, 2, 2, 2, 2, 2, 4, 2, 2, 2, 2, 2, 2, 2, 2, 5, 2, 2, 2, 2, 2, 2, 2, 2, 4, 2, 2, 2, 2, 2, 2, 2, 2,

The actual gif has less delay than the expected gif. So why is the expected gif twice as fast as the actual gif?

I experimented and created the 10ms (delay = 1) version.

It seems that programs that render gifs tend to not honor the 0 hundredths of a second delay rates. Instead, they use a value that is much greater than the small value that you chose.

I can't truly comment on the reasons why they do this. I've come across more than one reason, and it's possible that its all speculation.

In general, I would recommend that you use a delay of at least two hundreds of a second in all cases.

Sources (that demonstrate how there seem to be multiple reasons for this. Some are relatively old):

• http://blogs.msdn.com/b/ieinternals/archive/2010/06/08/animated-gifs-slow-down-to-under-20-frames-per-second.aspx


• http://humpy77.deviantart.com/journal/Frame-Delay-Times-for-Animated-GIFs-214150546


• https://bugzilla.mozilla.org/show_bug.cgi?id=139677

It looks like @DavidMah is right. On my Linux system, the minimum delay is 0.5:

convert -dispose none -delay 0.4 newton_%d.png[0-35] -coalesce output0.4.gif

convert -dispose none -delay 0.5 newton_%d.png[0-35] -coalesce output0.5.gif

convert -dispose none -delay 1 newton_%d.png[0-35] -coalesce output1.gif

For some reason the images seem not to be displayed properly in my browser. Using a local image viewer (eom), the 1st image is as slow as the one in the original question and both the others are faster than the wikipedia's. I am posting anyway in case it is a problem specific to my browser. In any case, you should get better speeds if your try the commands posted above.

UPDATE: There seem to be 2 problems. Browsers (at least y firefox and chromium running on Linux) cannot display gifs created with a delay <1.5. 1.5 works fine, 1.4 is slow. My image viewer can deal with delays of 0.5 and above. Try downloading one of the above images and opening it in your favorite image viewer. Also, have a look at these:

convert -dispose none -delay 1.4 newton_%d.png[0-35] -coalesce output1.4.gif

convert -dispose none -delay 1.5 newton_%d.png[0-35] -coalesce output1.5.gif

UPDATE2: @DavidMah points out in the comments below that decimal values are rounded to the nearest integer. So, 1.4 is rounded to 1 which is too slow while 1.5 is rounded to 2 which is OK.

I've had more success using the XxY delay notation, essentially the x is like a /, so if you specify -delay 1x20, the frame is displayed for 1/20th of a second.