On the "Random Thought": The GIF doesn't need to be animated. A GIF is made of multiple frames and each frame contains multiple image blocks. Each image block has its own coördinates and color table. You should be to use multiple image blocks in one frame (GCE block) to get one frame with 24-bit color.<p>For historical reasons most browsers don't respect a frame delay of 0 (computers used to be slow enough that even a 0 delay was good enough for animation; as they got faster browsers added extra delays to make old animations work correctly), but I think some renderers will correctly treat it as one frame (at least <a href="http://slbkbs.org/jsgif/" rel="nofollow">http://slbkbs.org/jsgif/</a> does! It has other problems with tricky GIFs, though -- the disposal method code is broken, for one).<p>Of course, you should just use PNG.
LZW compression is primitive. Even in simplest case of all transparent pixels it can only do "repeat previous pattern and add 1 pixel to it" and has to start over every 4K repetitions.<p>But it's also easy to hack! I've developed lossy GIF compressor: <a href="http://pornel.net/lossygif" rel="nofollow">http://pornel.net/lossygif</a><p>it's still worse than PNG, but would be awesome for animations. Anyone wants to help? <a href="https://github.com/pornel/giflossy/" rel="nofollow">https://github.com/pornel/giflossy/</a>
Good article, but all of the GIF formats are certainly newer than CDs. Even LZW is newer. CDs have been around widely since 1982 while GIF 87a & 89a came out in ... Well you can guess that.<p>And the thing it's famous for, the "Netscape looping extension" (NAB) ... that's from 1995 (Netscape Navigator 2.0b4). Yes, there was a time when IE would only play a GIF once and Netscape would loop it.
Oh, you kids and your high-bit-depth graphics. I remember a time when having GIFs with different palettes would cause the colour lookup table for the whole graphics card to be overwritten (last image loaded wins), and much ugliness and hilarity would ensue.
on the subject of GIF animations, they're still the best method for doing very compact animations / demos when few colors are needs. in my case i needed to produce some image scan pattern animations for online docs and what i ended up with after many iterations of screen recording software, codecs and compressors was:<p>screen-record using a free lossless codec eg <a href="http://lags.leetcode.net/codec.html" rel="nofollow">http://lags.leetcode.net/codec.html</a><p>i used Virtualdub which can produce and AVI, but also an animated GIF. then compress the result using <a href="http://www.lcdf.org/gifsicle/" rel="nofollow">http://www.lcdf.org/gifsicle/</a><p>result is extremely tiny filesizes for animations that can be embedded in any web page. hopefully this saves someone a lot of sleuthing work.
The article doesn't really explain why the GIFs appear spotty, as far as I understand it. The first frame in an animated GIF surely has to be complete; after all there's no previous frame to partially update. Then, a GIF viewer that didn't handle animation would show the first frame only - which wouldn't have any odd pixels and gaps in it.