ORIGINAL
Hmm … I did a couple of more tests, using this image as a base …
Resized and optimized
When I resize it down to 60x60, it looks like frame 0 has been butchered a bit…
Here’s frame 0
Resized, not optimized
If I resize it to 60 without optimization then frame 0 isn’t butchered…
Resized, optimized using gifsicle
I figured that there must be a way to have your banana and eat it too … so how about not using imagemagick for optimization, but gifsicle for optimization…
FYI, the command used to optimize using gifsicle
$ gifsicle -O2 banananoopt.gif -o bananagifsicleO2.gif
Please note that you can resize using gifsicle, but gifsicle doesn’t worry about quality as much as imagemagick.
What about the optimization sizes?
Let’s take a look:
$ ll banana*
-rw-r--r-- 1 sigurdur sigurdur 73623 maí 9 2012 banana.gif
-rw-r--r-- 1 sigurdur sigurdur 13911 feb 24 17:02 bananagifsicleO2.gif
-rw-r--r-- 1 sigurdur sigurdur 14093 feb 24 16:53 banananoopt.gif
-rw-r--r-- 1 sigurdur sigurdur 8832 feb 24 16:43 bananaopt.gif
So, it looks like imagemagick is able to compress the most, but butchers the images.
If we resize with imagemagick and optimize with gifsicle then we get an image that looks right and is optimized for size … 36% bigger than the butchered image in this case though …
If we resize with imagemagick and skip the optimization then we get an image that is 37% bigger than the optimized image, but we save some cpu cycles.
Conclusion
I say we should remove the optimization flag from the convert command.
Adding gifsicle will require a modification to the docker and added cpu cycles when a user uploads an image, only for saving 182 Bytes … not worth it IMHO at this moment.
What do you say @zogstrip?