# Optimized / Resized GIFs lose all animation, become still frames

**URL:** https://meta.discourse.org/t/optimized-resized-gifs-lose-all-animation-become-still-frames/19714
**Category:** Feature
**Created:** [9월 6, 2014, 7:17오전 UTC](https://meta.discourse.org/t/optimized-resized-gifs-lose-all-animation-become-still-frames/19714 "2014-09-06T07:17:36Z")
**Posts on this page:** 5
**Page:** 1

<div class="post-metadata">

### Author: ![fysics](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/fysics/32/34080_2.png) [@fysics](https://meta.discourse.org/u/fysics)
#### Post date: [9월 6, 2014, 7:17오전 UTC](https://meta.discourse.org/t/optimized-resized-gifs-lose-all-animation-become-still-frames/19714/1 "2014-09-06T07:17:36Z")

</div>

The title says it all. When oversized animated gif files are resized, only the first frame is preserved.

After a bit of [research](http://webcache.googleusercontent.com/search?q=cache:GULQ0D2RZLoJ:https://fosswiki.liip.ch/display/BLOG/Resizing%2banimated%2bGIFs%2bwith%2bImageMagick%20&cd=1&hl=en&ct=clnk&gl=us), it looks like the solution is to first coalesce the gif before resizing it. This “fills out” the incomplete frames so they can be resized, retaining the animation, by ImageMagick.

Seemingly paradoxically, this usually results in a larger file size than you started with. The coalescing process can be effectively reversed by [optimizing](http://www.imagemagick.org/Usage/anim_opt/) the resized gif.

So, we have a few possible solutions:

1. Coalesce, resize, then optimize gifs rather than sending them through the same optimization process as other images.
2. Allow browsers to resize gifs client side.
3. Some more involved process resembling YouTube lazy embeds, where gifs don’t animate until you click / hover them. (See e.g. [9gag.com](http://9gag.com))

I’m definitely in favor of the first option.

---

<div class="post-metadata">

### Author: ![codinghorror](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/codinghorror/32/110067_2.png) [@codinghorror](https://meta.discourse.org/u/codinghorror)
#### Post date: [9월 6, 2014, 8:13오전 UTC](https://meta.discourse.org/t/optimized-resized-gifs-lose-all-animation-become-still-frames/19714/2 "2014-09-06T08:13:45Z")

</div>

1. I don’t think it’s actually the job of the server to resize a giant animated GIF that’s so large it doesn’t even fit in the viewport. That’s a lot of work, particularly if we are preserving animation, and as you noted it can munge the compression.

2. Resizing on the client is not a bad idea, provided we can hard-code the dimensions in the `width` and `height` attributes – resizing “on the fly” and letting the browser decide the width/height leads to bouncing of the page as it shifts to accommodate the unknown (until render time) dimensions).

3. This idea has some merit as well, but seems kind of harsh.. and would be dev work. Maybe if that only kicks in when the animated GIF is so large?

---

<div class="post-metadata">

### Author: ![fysics](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/fysics/32/34080_2.png) [@fysics](https://meta.discourse.org/u/fysics)
#### Post date: [9월 6, 2014, 8:38오전 UTC](https://meta.discourse.org/t/optimized-resized-gifs-lose-all-animation-become-still-frames/19714/3 "2014-09-06T08:38:36Z")

</div>

We have two definitions of “large” being used, one with regard to file size and one with regard to dimensions, so clarity is key.

1. I competely agree, so long as we’re talking solely about large _dimensions_. Resizing and compressing uploaded gifs seems _reasonable_ if it’s done to save bandwidth and storage space.
2. I thought this was already done automatically? I’ve always seen dimensions added to my image markup. The problem is that they’re being (as you put it) munged server-side based on those dimensions. (Or maybe not based on those dimensions… I haven’t looked at the code for that.)
3. Agreed, on all counts.

---

<div class="post-metadata">

### Author: ![lidel](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/lidel/32/115991_2.png) [@lidel](https://meta.discourse.org/u/lidel)
#### Post date: [9월 6, 2014, 10:54오전 UTC](https://meta.discourse.org/t/optimized-resized-gifs-lose-all-animation-become-still-frames/19714/4 "2014-09-06T10:54:54Z")

</div>

@fysics If you have a community with high use of gifs this may be a better way to go (for both speed and storage space required):

> [@Should Discourse convert GIFs to mp4 video files?](https://meta.discourse.org/t/should-discourse-convert-gifs-to-mp4-video-files/16739):
>
> Just read about this neat trick that Twitter is doing with GIFs: [http://blog.embed.ly/post/89265229166/what-twitter-isnt-telling-you-about-gifs](http://blog.embed.ly/post/89265229166/what-twitter-isnt-telling-you-about-gifs) Perhaps this is something Discourse would like to mimic in the future. And for the watercooler: If a video format does everything GIF does and more, and with better compression, are the days of the GIF numbered?

---

<div class="post-metadata">

### Author: ![chapoi](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/chapoi/32/537252_2.png) [@chapoi](https://meta.discourse.org/u/chapoi)
#### Post date: [12월 4, 2025, 11:32오전 UTC](https://meta.discourse.org/t/optimized-resized-gifs-lose-all-animation-become-still-frames/19714/5 "2025-12-04T11:32:23Z")

</div>


