[TLDR: To create a fast GIF animation using imwrite, use a DelayTime of 0.02 instead of 0.]
im = rand(750,750)>0.8;
for ok=1:500
t = conv2(im(:,:,ok),[2,2,2;2,1,2;2,2,2],‘identical’);
im(:,:,1,ok+1) = (t > 4) & (t < 8);
finish
imwrite(~im,‘life.gif’,‘DelayTime’,0,‘LoopCount’,1)
Discover that this language does not specify precisely what is meant to occur if the Delay Time is 0.
One factor I’ve realized by expertise is that the precise habits of generally used software program purposes generally varies from the spec, and implementers should take note of that. Ben has regarded on the publicly out there supply code for a number of browsers and different purposes and found a Delay Time of 0 or 1 (1/100 s) is usually not honored. As a substitute, for numerous sensible and historic causes, a really low Delay Time like 0 or 1 is usually bumped up arbitrarily to a worth of 10 (1/10 s).
Subsequently, setting Delay Time to 0 is just not going to provide the quickest potential animation! I examined this in Safari, the browser I exploit on my Mac, and this does look like true.
This GIF was generated utilizing DelayTime of 0:
This one was generated utilizing a DelayTime of 0.02 (imwrite makes use of seconds as a substitute of hundredths of seconds for this parameter):
Certainly, the second model does animate way more rapidly.
One implication is that we may have to vary the imwrite documentation, which particularly says to make use of DelayTime of 0 to get the quickest animation:
I really suppose it might be time to vary the imwrite interface. Maybe we might give this parameter a reputation, akin to FrameRate, (in frames per second) and doc a most worth of fifty (which corresponds to a DelayTime of 0.02 s (or 2 hundredths of a second).
I’ll make each ideas to the event crew liable for imwrite.
