

The Mystery of the Spotty Animated GIF - ashleyblackmore
http://smerity.com/articles/2013/animated_gif.html

======
shachaf
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.

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 <http://slbkbs.org/jsgif/> does! It has other problems
with tricky GIFs, though -- the disposal method code is broken, for one).

Of course, you should just use PNG.

~~~
rcxdude
There's an example of a true-colour GIF on this page:

<http://phil.ipal.org/tc.html>

~~~
Smerity
Thanks for pointing that example out! I should have searched when I wrote
about it, but it just tangentially dawned on me that true-colour GIFs were
possible as I was writing the article.

------
pornel
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.

But it's also easy to hack! I've developed lossy GIF compressor:
<http://pornel.net/lossygif>

it's still worse than PNG, but would be awesome for animations. Anyone wants
to help? <https://github.com/pornel/giflossy/>

~~~
Scaevolus
I never considered how LZW doesn't do RLE!

LZW was probably chosen over Deflate for simplicity reasons. Maybe webP's
complexity has been hurting its adoption?

How does giflossy work? I don't see an explanation on that page.

~~~
pornel
lossy is simple — in the "pick the longest matching string from the
dictionary" the match is allowed to be imperfect.

GIF lives because it's expected to work _everywhere_. WebP so far isn't even a
first-class citizen in Google's world :(

------
kristopolous
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.

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.

------
stan_rogers
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.

------
leeoniya
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:

screen-record using a free lossless codec eg
<http://lags.leetcode.net/codec.html>

i used Virtualdub which can produce and AVI, but also an animated GIF. then
compress the result using <http://www.lcdf.org/gifsicle/>

result is extremely tiny filesizes for animations that can be embedded in any
web page. hopefully this saves someone a lot of sleuthing work.

------
iopq
I'm just waiting for WebP to take over the world.

~~~
Smerity
You'll need to wait a while longer, then, I think. GIF really should have died
a long time ago. It's technologically inferior and lives in only the smallest
image niche of the web, animation.

WebP should win over GIF. It's smaller, can be either lossy or lossless,
supports full transparency, has animation, ... except for the fact that almost
all GIF usage is (a) "clipart", (b) forums/comments/emails or (c) raw links
(i.e. Imgur).

When I say clipart, I meant that most GIF image use would be people using GIFs
made by other people. The Internet has a large treasure trove of GIFs that
people will re-use from here to eternity. I doubt anyone will ever bother to
convert the GIF to WebP.

Even if they did, if your browser doesn't natively support WebP[1] then you
need a Javascript shim. Most people won't know what a shim is or won't be
allowed to arbitrarily inject JS into the forum/comment/email. With raw image
links, it's obviously not possibly to add a JS shim either.

I hate to say, but I think we're going to be stuck with GIF for a while
longer...

[1]: <http://en.wikipedia.org/wiki/WebP#Support>

~~~
oftenwrong
APNG is a viable replacement for animation. APNG animations have long been
supported in the release versions of firefox and opera, and there is an
extension to enable them for chrome. Browser that do not support it will still
render the first frame as a static image.

~~~
Smerity
I was going to mention APNG but honestly it's dead. The PNG Group itself
decided not to embrace APNG in April 2007. The format's years old now and even
if it were to make a comeback, it still faces all the same issues as WebP
except without backing from a single major party.

APNG's degraded support is possibly even worse for adoption. It has all the
same issues as WebP (see the shim discussion above) bundled with the fact that
people don't expect PNGs to move.

People either (a) don't know it's broken (i.e. think the single frame means
it's a static image) or (b) know it's broken and chide you for using PNG
instead of GIF.

------
joosters
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.

~~~
Smerity
Good point, I guess I didn't add an explicit explanation, instead building up
to it implicitly. I've fixed that now. Thanks for the feedback.

\----

When the GIF software decides to take a snapshot of the animation instead of
playing it, it grabs an individual frame from somewhere past the start (i.e.
movie trailers always start with a "boring" black frame).

This would generally be fine except that, as we've seen, GIFs use partial
frames to aid in compression. What we end up with is a partial frame that
appears "spotty" as it only contains the difference between the past frame and
the current one.

~~~
joosters
Then the problem lies with programs that _do_ understand animated GIFs, and
not those that don't!

If the GIF software can navigate multiple frames, then it must know how to
render them. Its only lazy programs that would export these incomplete frames
by just copying the bitstream. A properly written program would export a full
frame, made from the composites of the previous parts of the animation.

The programs that are viewing these single frame exports are rendering them
just fine, they were simply supplied with poor data.

------
defaultnamehere
I've always wondered about this!

------
Lord_DeathMatch
Smerity!

\- NCSS Student :D

