Thanks again for your comments. I agree that decrementing FreeCode is wrong.
Meanwhile I'm pretty sure that your fix is correct because I tried to understand the code and learned more about LZW (de)compression. There's one tiny bit I'd change though. It doesn't really matter in the end but it looks wrong in the resultant code after your patch: the increment of FreeCode should be inside the conditional code as follows:
if (OldCode != ClearCode) {
if (FreeCode < 4096) {
Prefix[FreeCode] = (short)OldCode;
Suffix[FreeCode] = FinChar;
FreeCode++;
}
Reasoning: it doesn't make sense to increment FreeCode if we don't store another value in the arrays. It wouldn't do any harm though because FreeCode would be reset when the next ClearCode is received.
I fear apart from accurate code review from several people there is no other way than testing various images, like here: https://github.com/robert-ancell/pygif/tree/master/test-suite
Thanks for this link. Meanwhile I tested several hundred GIF images with success (not yet complete) and I'll download and test the images of this test suite as well.
Today I found another image that created an infinite loop when decoding with FLTK's decoder. Other image viewers issued an error message. It turned out that the image is incomplete (truncated) but we don't notice this fact; the effect is likely the same as with your test image posted at issue #271. We definitely need to fix both of these issues and I'm working on it.
As I see it, this is an encoder issue also, because to me it makes no sense to store more "words in the dictionary" than the decoder can handle...
The effect is (as I understand it) that the encoder stores such "words" in the data stream as is, i.e. w/o compression, and the decoder reads them as-is. AFAICT this can make sense in some cases if the dictionary is filled with "good" codes and most of the new "words" can be compressed effectively rather than clearing the entire dictionary and building it again from fresh data. The encoder is obviously free to do that.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android.
[ Direct Link to Message ] |