#25 GraphicsMagick rejects certain types of animated GIFs

[Steve Salevan]

We're working on replacing an ImageMagick deployment with the latest release version of GraphicsMagick (1.3.16), and I wanted to shoot a message out to this group to see if anyone's ever run into issues processing animated GIF files. We're finding that there are certain types of animated GIFs which can be identified and resized by ImageMagick that are rejected by GraphicsMagick as corrupt. From a bit of debugging, it looks as if the following lines in coders/gif.c are triggering a return status of MagickFail to be set:

coders/gif.c, line 279 (triggers occasionally):

if (available > MaxStackSize)
{
status=MagickFail;
break;
}

coders/gif.c, line 355 (triggers each time):

if (x < (long) image->columns)
{
status=MagickFail;
break;
}

note: in the images I've tried, this always seems to be triggered when the y variable == 30

Here are several examples of running ImageMagick and GraphicsMagick with the supplied images with the -debug all option enable:

http://hastebin.com/xagogefuqo.coffee

[Steve Salevan]

Image 1 rejected by GM

[Steve Salevan]

Image 2 rejected by GM

[Steve Salevan]

Image 3 rejected by GM

[Bob Friesenhahn]

Since what GraphicsMagick is doing is technically valid, but it is desirable to be able to extract a correct image, I am moving this to the "feature requests" bucket.

[Tianyu Lang]

Hi Bob,
I ran into the same problem. And it turns out ImageMagick is able to handle GIFs with abnormally long LZW table gracefully. So I took ImageMagick's gif.c code and ported it to GraphicsMagick. After this change, GraphicsMagick is able to handle those GIFs. Here is the modified coders/gif.c: http://pastebin.com/nbX0NJY3
Hope this can help.
Thank you.

[Tianyu Lang]

Hi Bob,
I ran into the same problem. And it turns out ImageMagick is able to handle GIFs with abnormally long LZW table gracefully. So I took ImageMagick's gif.c code and ported it to GraphicsMagick. After this change, GraphicsMagick is able to handle those GIFs. Here is the modified coders/gif.c: http://pastebin.com/nbX0NJY3
Hope this can help.
Thank you.

[Bob Friesenhahn]

On Mon, 14 Nov 2016, Tianyu Lang wrote:

I ran into the same problem. And it turns out ImageMagick is able to
handle GIFs with abnormally long LZW table gracefully. So I took
ImageMagick's gif.c code and ported it to GraphicsMagick. After this
change, GraphicsMagick is able to handle those GIFs. Here is the
modified coders/gif.c: http://pastebin.com/P98cR8mA Hope this can
help.

It is good that ImageMagick has this fixed. It was also broken when
the problem was first noticed.

I don't intend that GraphicsMagick loses its MIT-X11 style license so
we will not pick up changes originating in ImageMagick source code.
Someone who contributes changes to ImageMagick could also contribute
similar changes to GraphicsMagick and then there would be no problem.

There is no problem for someone else to maintain a fork of
GraphicsMagick (e.g. at Github) with such changes.

Bob

[Tianyu Lang]

I see.
I tried to fix the code in GraphicaMagick but I am too new to the codebase to make it work.
But thank you anyways for the fast reply!

[Tianyu Lang]

Hi Bob,
Update on the issue. I managed to fix the issue and did a test.
Here is the code: http://pastebin.com/XCYDJTpV
Sorry I never used hg so did not create a pull request; my change is quite small, less than 30 lines.
I passed all the "make check" GIF related tests.
Also, I have a collection of LZW table overflow GIF to test against, and my change successfully identify/convert those GIFs.
Here is 11 of them https://drive.google.com/open?id=0B5MabZgM8lcVYlRIMDZ0ZmRYa0k

Please let me know if you insist I go through the patch submission process. Then I will make sure I follow the procedure.

Thanks,
Tianyu

[Bob Friesenhahn]

I have applied Tianyu Lang's fixes as Mercurial changeset 14965:ecfd062a75ca.