image/gif: check rejection of this gif

[gopherbot]

by kballard:

The attached GIF is rendered successfully by both Chrome and Firefox. It probably has
some sort of corruption though, because Safari and Preview render it as corrupt (though
it still does render). GraphicConverter also renders it as corrupt, though in a
different fashion.

However, Go doesn't render it at all. It just returns the error "lzw: invalid
code".

Mac OS X 10.7.3, go version go1.

Attachments:

1. GGUVZ.gif (9997027 bytes)

[rsc]

Comment 1:

This could be a feature.  Now that I've looked at it in Chrome, I can't unsee that gif.

Labels changed: added priority-later, removed priority-triage.

Owner changed to @nigeltao.

Status changed to Accepted.

[gopherbot]

Comment 3 by kballard:

For the record, Safari/Preview on Mountain Lion render this GIF correctly now as well.

[rsc]

Comment 4:

Labels changed: added go1.1maybe.

[rsc]

Comment 5:

[The time for maybe has passed.]

Labels changed: removed go1.1maybe.

[gopherbot]

Comment 6 by jeff.allen:

I looked into this a bit. I found that when the invalid code is found:
code 639
litwidth 8
width 12
clear 256
eof 257
hi 90
ovf 4096
last 98
Because 639 < 90 (d.hi), it fails. I'll trace through another gif decoder and try to
see what they do when receiving a code like this.

[gopherbot]

Comment 7 by jeff.allen:

Another GIF that causes Go problems:
https://bug525326.bugzilla.mozilla.org/attachment.cgi?id=409291
Don't know if it is the same problem yet, if not, I'll file a new bug.

[gopherbot]

Comment 8 by jeff.allen:

I suspect this code in Webkit shows the way to making Go's gif decoder more lenient:
http://trac.webkit.org/browser/trunk/Source/WebCore/platform/image-decoders/gif/GIFImageReader.cpp?rev=131831#L322
More later.

[gopherbot]

Comment 9 by jeff.allen:

A fix for this would involve making compress/lzw tolerant of incorrectly encoded
streams. This seems like a bad idea in general. So a correct fix would need to add to
the API of compress/lzw a boolean for "tolerate errors?".
An API change to compress/lzw before Go 1.1 is not going to happen, so I think punting
on this is the right call.
The image in comment #7 is something else (issue #5050).

[gopherbot]

Comment 10 by jeff.allen:

I think closing this as Won't Fix would be a good idea. Thanks.

[nigeltao]

Comment 11:

Status changed to WorkingAsIntended.