FLTK logo

Re: [fltk/fltk] Fl_GIF_Image decoder bug (#274)

FLTK matrix user chat room
(using Element browser app)   FLTK gitter user chat room   GitHub FLTK Project   FLTK News RSS Feed  
  FLTK Apps      FLTK Library      Forums      Links     Login 
 All Forums  |  Back to fltk.issues  ]
 
Previous Message ]New Message | Reply ]Next Message ]

Re: [fltk/fltk] Fl_GIF_Image decoder bug (#274) Albrecht Schlosser Sep 20, 2021  
 

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 ]
 
     
Previous Message ]New Message | Reply ]Next Message ]
 
 

Comments are owned by the poster. All other content is copyright 1998-2024 by Bill Spitzak and others. This project is hosted by The FLTK Team. Please report site problems to 'erco@seriss.com'.