"LZW table token overflows the frame" is reported

[kisvegabor]

We are using your fantastic library in LVGL, however with a specific gif we get "LZW table token overflows the frame" errors.

I've tried reconverting it on ezgif.com but it didn't help. Do you have any idea what could be the problem?

The gif that we are testing with:

[lecram]

Hi @kisvegabor, thanks for reporting this. After looking into it a bit I haven't found the root cause yet. Here's my progress so far.

The error "LZW table token overflows the frame" is triggered when a particular frame in the GIF seems to contain data for more pixels than expected based on the width and height of that frame. Each LZW token read is decompressed into one or more pixels. Inside the function read_image_data() the variable frm_size is set to width * height as read from the frame header and the variable frm_off ("frame offset") keeps track of the number of pixels decoded so far. When frm_off exceeds frm_size - a condition that should never occur - the error is reported. Note that this error is not explicitly reported by gifdec upstream code, only by the modified version used inside LVGL.

I've tested the GIF above with gifdec using the example SDL2 GIF viewer and no fatal error occurs. There are some visible issues with transparency and background color that I believe are due to an unrelated bug in gifdec (I'll be working on that as well). Adding some printf()s inside read_image_data() I noticed that the value of frm_off never exceeds frm_size. At this point I noticed that the code for that function has significant differences between upstream gifdec and the modified version used inside LVGL, perhaps because of the constrained environments LVGL needs to support? Anyway it is hard to inspect the issue without running the LVGL version myself.

My next step would be debugging this issue in LVGL itself but I'll have to learn the basics of building and running a minimal LVGL program. :)

[kisvegabor]

Hi @lecram,

Thank you so much looking into it. It's great that the issue doesn't happen in the upstream gifdec version. Yes, we have changed the upstream version a little for better integration with LVGL.

It'd be awesome, if you could try the LVGL version too. 🙏 Let me know if you need any help from our side.

I wonder if you would be open to update gifdec to make it easier to integrate to other libs (e.g. LVGL). I think the 2 main changes that we have added are the support for opening GIFs from data (array) and some assembly accelerations.

[Satnet]

What is the progress of this issue? :)