Legacy ImageMagick Discussions Archive

Hi,

I was trying to create an animated GIF at 30 FPS, so playout is mostly synchronized with the typical LCD refresh rate of 60 Hz.

convert.exe -delay 1x30 -loop 0 image%03d.pgm[0-1199] image.gif

GIF specifies the delay between frames in 1/100th's of a second. So I find that the generated 1200 frame animation replays at faster frame rates because the delay it introduces between frames is always 3/100ths of a second, resulting in 33.33 FPS

Is there a way to accomplish that ImageMagick uses 4/100ths and 2x 3/100ths seconds delay for each three consecutive frames, so that the average delay becomes 33.333ms and I do get 30 FPS exactly?

Christian

I believe this is correct, though not 100% sure. delay=1 is 1/100 sec per frame. So delay=100 = 1 sec per frame. So delay= 100/30 = 1sec/30frame. So you need a delay of 3.33 (100/30) to achieve 30f/sec.

P.S. if IM does not like fractional delays such as

-delay 3.33 (-delay 3.33,100)

then you can scale the delay and tics per second, such as

-delay 33,1000

0r

-delay 333,10000

From http://www.imagemagick.org/Usage/anim_basics/ :

GIF animation delays must be specified in hundredths of a second for correct working, which is why that is the default time unit.

It seems the metadata is stored in units of 1/100s, so "-delay 33x1000" etc will result in 3/100.

cbuchner1 wrote:Is there a way to accomplish that ImageMagick uses 4/100ths and 2x 3/100ths seconds delay for each three consecutive frames, so that the average delay becomes 33.333ms and I do get 30 FPS exactly?

Sure. Just list the frames with a "-delay" between them, eg: In practice, you could build the command in a script, reading each frame from one animated gif, writing to another gif.

snibgo wrote:GIF animation delays must be specified in hundredths of a second for correct working, which is why that is the default time unit.

Thanks, snibgo, for posting that. I had never knew that before. I see it now in the reference link you provided. I was only looking at -delay from the options page information.

Learned something new today!

I assume tics must be integers. Do you know if that is true?

I haven't looked at the GIF spec or IM's code, but playing with commands like ... ... I find the delay parameter is always rounded to an integer number of hundredths.

Actually it's truncated to an integer. -delay 1x30 and -delay 39x1000 both write a GIF with delay 3, while -delay 40x1000 writes delay 4.

True, "-delay 39x1000" becomes 3*. But (in v6.9.0-0) "3.9" becomes 4.

*EDIT: I wrote "4" but meant "3".

Right. The components of 39x1000 are rounded in constitute.c to 39 x1000, and 3.9 is rounded to 4 Then in gif.c the
integer calculation of 100*39/1000 yields 3 while the integer calculation of 100*4/100 yields 4.

Wouldn't it make sense to accumulate that rounding error, so that consecutive frames of an animation might use different delay values?