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):

expected output

This is the output I actually get:

actual output

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?

  • 1
    Out of curiousity, what happens if you set the delay to 1 rather than 0?
    – mgilson
    Commented Mar 22, 2013 at 14:50
  • 1
    looks like a frame-rate issue.
    – SnakeDoc
    Commented Mar 22, 2013 at 14:58
  • @mgilson, I have just tried that. The 0-delay image and 1-delay image appear to be perfectly synced. Which is odd, as the 1-delay image should lag behind 36/100ths of a second every loop.
    – Kevin
    Commented Mar 22, 2013 at 15:01
  • 1
    tl;dr on this question: Use -delay 2.
    – Matt M.
    Commented Sep 16, 2014 at 23:40

3 Answers 3


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

10ms delay example

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):

  • 1
    If the rendering program slows down all gifs that are too fast, then Wikipedia's gif would be just as slow as my own gif. But it isn't. Why can Wikipedia break the speed limit, and I can't?
    – Kevin
    Commented Mar 22, 2013 at 15:22
  • 2
    @Kevin: It slows down all GIFs that are too fast. Your GIFs are too fast. Wikipedia's GIFs are not too fast. You need to slow down so you won't be "too fast". Commented Mar 22, 2013 at 15:29
  • The frame delays for the Wikipedia gif range between 20 ms and 50 ms. If I set my own frame delay to 20 ms, it's still slower, even though theoretically it meets the same "not too fast" criteria as the Wikipedia gif.
    – Kevin
    Commented Mar 22, 2013 at 15:33
  • 2
    If, alongside a wikipedia image that has 20ms delays, you include a gif that you've created also with 20ms delays, I will take a look.
    – David Mah
    Commented Mar 22, 2013 at 15:37
  • 2
    I was mistaken. The 20 ms gif I created is indeed as fast as the Wikipedia gif.
    – Kevin
    Commented Mar 22, 2013 at 15:53

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

enter image description here

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

enter image description here

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

enter image description here

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

enter image description here

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

enter image description here

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.

  • 7
    Beware trying to assign delays to decimal values. Delay is stored in two bytes (the implications on this is that the largest frame delay is 655360ms) and is an unsigned integer. Convert is rounding your values to be the nearest integer. en.wikipedia.org/wiki/Graphics_Interchange_Format#Animated_GIF
    – David Mah
    Commented Mar 22, 2013 at 16:04
  • 3
    @DavidMah ah, that makes sense. So 1.5 works because it is rounded to 2 while 1.4 doesn't because it's rounded to 1.
    – terdon
    Commented Mar 22, 2013 at 16:06

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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .