Ferneu - 2012-04-06

Hi there, I propose adding a parameter or an overloaded to DGifSlurp() in
order to make it a little less strict towards invalid LZW streams.

I have stumbled upon a couple of animated GIFs where the decoder complains
about invalid LZW data in some of the frames. But it does so only after
decoding part of the image. That means that even though we might end up with
some garbage, at least a little bit of the original frame is there.

If we are lucky, maybe the bytes that indicate the size of each LZW "block"
are still intact, so we could use use them to skip over to the end of the
"Table Based Image Data" (using GIF89a terminology), issue a warning to the
user and then continue processing what is left from the GIF stream.

Implementing such error handling scheme is pretty easy. It is just a matter of
saving the current stream position before the call to DGifGetLine() inside
DGifSlurp(). Then if DGifGetLine() returns GIF_ERROR, simply move the stream
back to that position we just saved, read the very next byte, which contains
the size of the LZW block, move the stream forward that amount of bytes (plus
1 of course) and rinse and repeat until the byte containing the LZW block size
is 0.

I have tried doing that and it works like a charm. Pretty useful for handling
some broken GIF streams downloaded from the internets.