Open im-vignesh opened 1 year ago
Hey @im-vignesh! Can I take a look at the GIF you're talking about?
Sure. Here it's @DarthSim - https://bafybeia7php3h3jiuinc27vrxozrsjerb6v2upfw5idtz2mte3qgf3miua.ipfs.dweb.link/Team%20Airstack.gif
Well, I made some work but I didn't come to any solution. But I can explain why this happens.
The first thing is that the GIF you've sent is most probably compressed using lossy LZW. The libraries used by imgproxy don't support lossy LZW, and they probably won't as lossy LZW produces pretty nasty artifacts. You may not notice them on the provided GIF but if you'd compare it with the original, you'd probably do.
The second thing is that GIFs are poorly resized in general. GIF is limited to 256 colors but resizing produces new colors. This leads to additional dithering which regrades compression.
Thus it's recommended to convert GIFs to WebP or MP4.
We have a somewhat similar situation - and while we're working to replace large animated GIFs, until then, we've set IMGPROXY_SKIP_PROCESSING_FORMATS = "gif"
which sidesteps this issue. Not sure if that helps @im-vignesh !
As I said before, it's recommended to save animations as WebP or MP4. Using WebP is probably the easiest way to solve the file size issue. All the modern browsers support WebP, so you'll probably never need to serve GIFs to your users.
I've got a gif composing 192 frames of dimension 300x300 sizing 1.8mb. When it is downsized to 250 x250 it's increased to 3.9mb rather falling below its original size. I have not set any processing options other than resize of fit and IMGPROXY_MAX_ANIMATION_FRAMES = 200.
Am i missing anything?