How can I create animated GIF images in MATLAB?
1,897 views (last 30 days)
Show older comments
MathWorks Support Team
on 27 Jun 2009
Edited: MathWorks Support Team
on 26 Jun 2023
I would like to know if there is MATLAB functionality to create an animated GIF in MATLAB.
Accepted Answer
MathWorks Support Team
on 26 Jun 2023
Edited: MathWorks Support Team
on 28 Mar 2022
In MATLAB 2022a, export to GIF format is supported by the exportgraphics function using the ‘Append’ option. For example:
x = 0:0.01:1;
p = plot(nan,nan);
p.XData = x;
for n = 1:0.5:5
p.YData = x.^n;
exportgraphics(gcf,'testAnimated.gif','Append',true);
end
For releases prior to R2022a, follow the example "Write Animated GIF" on the imwrite reference page.
7 Comments
Walter Roberson
on 8 Sep 2021
prefix = 'abc_20190304'
dinfo = dir( [prefix '*.png']);
filenames = {dinfo.name};
for K = 1 : length(filenames)
work with file name in filenames{K}
end
Adam Danz
on 1 Jul 2022
exportgraphics does not currently have an option to control frame rate of GIFs.
The documentation for exportgraphics > Append argument suggests to use imwrite for more elaborate graphics. Also see Write Animated GIF.
More Answers (2)
Alec
on 19 Dec 2013
So it appears that `imwrite` now supports writing animated grayscale GIFs "When writing multiframe GIF images, X should be an 4-dimensional M-by-N-by-1-by-P array, where P is the number of frames to write."
But if I try to pass it an M-by-N-by-3-by-P it seems to treat each RGB color channel as a separate grayscale frame. Is there now way to write an animated color GIF without a for loop over the frames?
1 Comment
DGM
on 25 Jul 2022
Edited: DGM
on 5 Apr 2023
MIMT gifwrite() works to write I/IA/RGB/RGBA and indexed color images from 4D arrays. MIMT gifread() can read the image with minimal hassle.
Pay attention to the synopsis if you intend to read GIF files in versions newer than R2018a -- regardless of what tools you're using. If you're using a newer version, you will not be able to correctly read most multiframe color GIF files unless you make that effort.
Stitching the frames together to generate a colormap is a bad idea, since it means that no frame can have a unique optimized local color table. The more dynamic the color content is over the sequence, the worse the entire image will look.
EDIT: I think my claim should be obvious, but let's demonstrate it anyway. I'm going to use MIMT tools here, because why would I make things harder for myself?
Let's start with a short imageset where the colors vary a lot.
% read six colored images and stack into a 4D array
inpict = mimread('wide*.png');
inpict = imstacker(inpict,'padding',0);
% write the RGB images as (mostly) usual
% each frame gets its own optimized local color table (LCT)
% in this example, gifwrite() is internally modified to call
% rgb2ind(...,'nodither') for purposes of making the artifacts clear
gifwrite(inpict,'uniqueCT.gif',0.5)
% instead of converting each frame independently,
% tile the frames, convert, and then detile
% again, i'm using 'nodither' so that the effects are clearly visible
inpict = imtile(inpict,[3 2]);
[inpict,map] = rgb2ind(inpict,256,'nodither');
inpict = imdetile(inpict,[3,2]);
% write the indexed images to create a garbage GIF
% in this image, all the LCTs are identical copies of the same 256 colors
gifwrite(inpict,map,'pseudoglobalCT.gif',0.5)
These are the two GIFs produced. Note that they are significantly different.
But you might notice that we're trying to span all of RGB with this GIF. Surely this little error won't cause any issues if the interframe variation were small. Let's try the same thing, only using a much narrower color swing.
While pageload will pretty much ensure that the two GIFs aren't synchronized here, you may notice that they don't appear to even have the same number of frames. Let's look into that.
% read the images back
G1 = gifread('uniqueCT.gif');
G2 = gifread('pseudoglobalCT.gif');
% calculate the MSE between adjacent frames
mse1 = zeros(1,5);
mse2 = zeros(1,5);
for f = 1:5
mse1(f) = immse(G1(:,:,:,f),G1(:,:,:,f+1));
mse2(f) = immse(G2(:,:,:,f),G2(:,:,:,f+1));
end
% note that for two cases, the effect is large enough that adjacent frames
% which were once unique are now identical.
mse1
mse1 =
56.3333 48.0000 56.3333 48.0000 56.3333
mse2
mse2 =
120.3333 0 208.3333 0 120.3333
So yes, we actually lost two frames of information. This is a bad idea even when interframe variation is small.
Again, this example uses MIMT tools, specifically gifread() and gifwrite(), though the lessons here are not unique to those tools. Before you decide to test these examples yourself, understand that MIMT gifread() and all other tools require significant workarounds to correctly read multiframe GIFs in current versions. If you do not make your own effort to fix that, the results you get from gifread()/imread() will be either subtly or wildly wrong, leaving you with a misunderstanding of the file's actual content. See the link.
See Also
Categories
Find more on Animation in Help Center and File Exchange
Products
Community Treasure Hunt
Find the treasures in MATLAB Central and discover how the community can help you!
Start Hunting!