Last week I wrote a photo walkthrough about a collapsible storage box, and I had combined the eight step shots into one long image. More than half the comments said the third step in the middle was impossible to read. So I switched to an animated image and hit a fresh set of problems. The first version was 720×540 with sixteen frames and exported at a bit over 4MB; when I tried to open it on the metro it spun for four or five seconds before anything moved. The second version ran too fast, flipping on before my hand reached the spot. In the third version the sizes were not consistent, so the picture jumped and shrank toward the top-left corner on every frame. Four rounds in, I had to admit that a GIF is not a picture that moves. It is something decided by three numbers at once: order, duration and size. Get any one of them wrong and the work is wasted.
1. When a GIF is the right choice, and when it is not
| Format | Good for | The cost |
|---|---|---|
| GIF | 3-12 step how-tos, a single looping motion, reaction memes | A palette of only 256 colours; size grows linearly with dimensions and frame count |
| Long image | More than twelve steps, close inspection, possible printing | Readers scroll back and forth and cannot see continuous motion |
| Short video | Over 10 seconds, needs sound, needs true colour | Lots of platform rules; readers watch muted by default |
My dividing line: if motion carries the message, it can be told in two or three loops, and it needs no sound, use a GIF. Past twelve steps, stick to a long image with numbered captions; animation only makes it messier.
2. What each of the three settings decides
Order decides whether readers can follow cause and effect, the frame interval decides whether they have time to see it, and dimensions plus frame count decide the file size. The interval turned out to have a huge range in practice: the options run from 100ms to 3000ms per frame, but 100ms flickers like a ghost and 3000ms feels like a stall. I ended up on two values: about 800ms for text steps and about 200ms for hand movements.
| What I ran this time | Size | Frames | Interval | Output size |
|---|---|---|---|---|
| First version | 720×540 | 16 | 250ms | About 4MB |
| Second version | 540×405 | 10 | 800ms | About 1.4MB |
| Third version | 480×360 | 8 | 250ms | About 700KB |
| Control version | 480×360 | 8 | 1200ms | About 700KB |
Running the same set of images gives a clear answer: size is essentially set by dimensions times frame count, and stretching the hold time saves almost nothing. So to slim a file down, cut frames first, then shrink the dimensions, and do not count on the interval. This table is also the first thing I look at when someone tells me an animated image is too big.
3. My current workflow for one animated image
- First make every image the same width. A phone shot at 4032×3024 mixed with a 1440×900 desktop screenshot makes the frame jitter on every slide during composition. I use Image Resizer to lock the width at 540, tick proportional scaling and let it work out the height from the original ratio.
- Upload the images in step order and drag them into sequence on the thumbnails. This has to be finished before export; changing the order afterwards means starting over.
- Run the preview at 800ms first, then speed it up as long as the motion still reads. Once it stops being legible, go back one notch. I got there by trying previews, not by working out a formula.
- While previewing, watch two things: whether the first and last frames join up, because a jump in the loop breaks the illusion, and whether near-duplicate shots slipped in, because two burst frames a few pixels apart just waste size.
- After export, open it once on my phone over mobile data, let it load completely, and only then decide whether to cut more frames.
4. What to do about greyish colour and dirty text edges
A GIF has a 256-colour palette, so gradient backgrounds and real photographs band very easily, and dark text picks up a grey halo. I deal with it in three steps: change the background from a gradient to a flat colour; make the text one weight bolder and a size larger; avoid using real photographs as the main frame, and use line drawings where they will do. If colour is the whole point of the material, a before-and-after grade for instance, then a GIF is the wrong format; no amount of compression fixes that.
5. Frame counts and intervals by motion type
I used to set the interval by feel and only discover afterwards that a step went too fast or dragged. Now I fix the frame count and interval before I even start shooting, using the values below, all of them ranges that came out of one walkthrough after another:
- Continuous hand motion (pulling, folding, twisting a lid): 8-12 frames at 200ms. Fewer and the motion breaks, more and the size climbs fast.
- State change (a lid opening, a buckle clicking, an indicator changing colour): 3-5 frames at 400-600ms. What matters here is that the frame showing the result holds long enough.
- Text card (one sentence per step): one frame per screen at 800-1200ms. I tried 500ms and readers said they could not finish reading.
- Loop seam: keep one neutral pose at each end, the frame where the hand leaves the picture. Without it, the hand flashes into view when the loop restarts.
- One idea per image: an animated image should explain one thing. If I have two things to say, I make two images instead of piling up twenty-odd frames.
The most valuable of these is the last one. My first version failed not because the settings were wrong but because I tried to cram three motions, folding the side wall, fastening the buckle and inserting the liner, into one 4MB loop. All readers saw was a jittering mess.
6. Common questions
Q: Why is my GIF file so large?
Check dimensions and frame count first, not the interval. Sixteen frames at 720×540 being five or six times larger than eight frames at 480×360 is entirely normal, because every frame stores its own complete picture.
Q: How do the frame interval and the frame rate convert?
The interval is how long each frame stays. 250ms equals four frames per second, while 800ms is only 1.25 frames per second. For tutorial motion I usually land between two and five frames per second; reaction memes can be faster and text must be slower.
Q: The captions in my animated image are always hard to read. What can I do?
Do not expect the interval to rescue them. Composition only handles order and duration, so captions have to be built into the frames beforehand, at around 8% of the output width. On a 540-wide image, caption text under 40 pixels is hard to read on a phone.
Q: Can burst photos from a phone become an animated image directly?
Yes, it is essentially sequential playback. Two conditions: the sizes must match, and the number of frames must stay modest. Dropping a dozen burst shots in, where the differences are tiny, doubles the size while readers see no change.
Q: What if I upload the wrong image, or one too many?
At the preview stage it can still be fixed: remove the extras, reorder by number and export again. Once the file is out there is no partial edit, only a rebuild, which is why I check the numbers against my list at the upload stage.
Q: What if I want to change a few frames in the finished file?
Rather than picking frames apart in an animated image editor, split the whole thing. GIF Frame Extractor exports every frame as a still image, so I fix the two or three that need work and recompose. It costs less than you would think.
Q: Are my images uploaded?
No, composition happens in the browser. Unreleased company footage cannot leave the internal network, and for us that is the condition for using a tool at all.
That walkthrough ended up using the 540×405, ten-frame, 800ms version at about 1.4MB, and the comments finally stopped saying step three was unreadable. Looking back at those four rounds, the first thing I should have done was fix the dimensions and the frame count, not worry about how fast the animation ran.