Puzzles About GIF DelayTime
[TLDR: To create a fast GIF animation using imwrite, use a DelayTime of 0.02 instead of 0.]
In my 28-Feb-2022 post, I showed some code that created an animated GIF file using a DelayTime of 0.
im = rand(750,750)>0.8;
for k=1:500
t = conv2(im(:,:,k),[2,2,2;2,1,2;2,2,2],'same');
im(:,:,1,k+1) = (t > 4) & (t < 8);
end
imwrite(~im,'life.gif','DelayTime',0,'LoopCount',1)
In response, reader Mikhail commented that one shouldn't use a DelayTime of 0 for the purpose of creating fast GIF animations. He pointed me to an blog post by Ben Phelps called "The Fastest GIF Does Not Exist." (Note: If you visit this site, you may get a security warning in your browser. Apparently, the site's certificate expired a few days ago. Visit at your own risk. I have attempted to contact the author to let them know.)
Many years ago (about 25!), I used to work on image file format support in MATLAB, so I usually start investigating such questions by looking at the specification for the format in question. The relevant spec is GIF89a, and here's the key paragraph:
Notice that this language doesn't specify exactly what is supposed to happen if the Delay Time is 0.
One thing I've learned by experience is that the actual behavior of commonly used software applications sometimes varies from the spec, and implementers must pay attention to that. Ben has looked at the publicly available source code for several browsers and other applications and discovered a Delay Time of 0 or 1 (1/100 s) is generally not honored. Instead, for various practical and historical reasons, a very low Delay Time like 0 or 1 is often bumped up arbitrarily to a value of 10 (1/10 s).
Therefore, setting Delay Time to 0 is not going to give you the fastest possible animation! I tested this in Safari, the browser I use on my Mac, and this does appear to be true.
This GIF was generated using DelayTime of 0:
This one was generated using a DelayTime of 0.02 (imwrite uses seconds instead of hundredths of seconds for this parameter):
Indeed, the second version does animate much more quickly.
One implication is that we may need to change the imwrite documentation, which specifically says to use DelayTime of 0 to get the fastest animation:
I actually think it may be time to change the imwrite interface. Perhaps we could give this parameter a name, such as FrameRate, (in frames per second) and document a maximum value of 50 (which corresponds to a DelayTime of 0.02 s (or 2 hundredths of a second).
I will make both suggestions to the development team responsible for imwrite.
Comments
To leave a comment, please click here to sign in to your MathWorks Account or create a new one.