Image effect (GIF support)

[Aircoookie]

A very versatile advanced effect mode for displaying .gif images (could be extended to other filetypes like .bmp or .fseq in the future) on matrices and 1D strips.

• full animation and static image support
• upload GIF to LittleFS (/edit) and set the filename as the segment name
• speed is adjustable

Limitations

• the effect can only be used on one segment at a time
• no image is displayed during effect transitions
• As 23kB RAM are required while the effect is running, this is ESP32 only
• each animation frame only redraws the pixels that are actually updated. This can lead to uneven brightness if ABL kicks in. I highly recommend enabling global buffer to solve this :)

[blazoncek]

Now we will really need to start working on SD card support. 😄

[blazoncek]

Is the removal of mqtt.cpp intentional or accidental?
Eh! Disregard. I see that entire file was changed. Probably CRLF.

[constant-flow]

Now we will really need to start working on SD card support. 😄

SD support is already implemented and merged as usermod

[blazoncek]

Finally had a bit of time to go through the code. Sorry for the delay.

There are a few of Serial.print() still present but that's minor.
I am a bit intrigued by the addition of endImagePlayback(this); into resetIfRequired(). That is something we need to add to Segment handling in general as the effect functions never receive any notification that they will no longer run and cannot clean-up anything. Everything now relies on deallocateData() which is a bit of shame really.
I would also move the content of renderImageToSegment() into mode_image() as it is more "tightly" connected to actual Segments. Perhaps the entire image_loader.cpp could be encapsulated within a class inside mode_image() in a similar way as 1D expansion is done.

[Aircoookie]

Thanks!
Yeah, I don't like endImagePlayback() in resetIfRequired() either. It would probably be a good idea to add some callback for cleanup when effect is changed. To avoid requiring an extra 4 bytes for the pointer in each segment, this could also just call the mode function with a bool parameter cleanup though.
Regarding image_loader.cpp, I would keep it this way. FX.cpp is already over 8k lines and putting functionality into separate files when it makes sense eases maintainability imo.

[dosipod]

We have been testing this branch a lot as that is a door for a very simple way to create custom effects even if that is not the intended purpose

So that is why we think that gifs could be a way to enhance wled even in ways no one thought of .The size at the moment is a show stopper without at least SD card support being linked to that as we could only load few small gifs in our tests .
For a while now we have been testing a usermod that has a gif client and a server ( public and private )
https://github.com/hughc/wled-pixelart-client https://github.com/hughc/pixel-art-server

If @Aircoookie is no longer interested in this ( this is more alarming in a lot of ways which is not related to gifs as your presence is a motivation to a lot of the guys) then we want to try to borrow the logic from the usermod to simplify the gifs loading either from a shared SMB folder on a local PC or a folder on github without the use of any code on a server just to make that more user friendly as much as possible which we are not sure of at this point . ( We work with students on a variety of projects and we are not wled devs and do not wish to do something others may have in mind or planned in a more polished way but we will give it a shot ) . Hope you get the point

[Manut38]

@dosipod I have also been testing this branch quite a lot while developing my small GIF player web interface at https://github.com/Manut38/WLED-GIFPlayer-html
for which I also opened a pull request at #3921.

I honestly don't see SD Card support as a show stopper for this feature necessarily.
I've been uploading my 16x16 .gif files with my tool and solely been using the ESP file system. I export my GIFs from the Divoom Android App and then shrink them to the adequate 16x16 pixels and they barely take up any space then. Using this method I can easily fit dozens of animations just on the onboard file system. Even the longest animations don't surpass 20KB.
I am aware of course aware, that with the bigger pixel count of larger matrices this size increases quite quickly.
However I still think that it is very usable this way, with the big note that says you shouldn't upload files with greater dimensions than the ones of your pixel array. But you shouldn't do that anyway, because the live decoder quickly slows down when it you serve it huge GIFs.

Granted, the littleFS and the attached web server of course are not the fastest or most stable things ever, especially when uploading a new image using the /edit endpoint.
While developing I noticed how accessing multiple gif files for rendering in the web interface at the same time causes the ESP to crash, most likely because of a full heap. That is the reason why I forced a strict image caching in my web interface, so the images need to be sent to the browser few times as possible.

[oOJoshOo]

@dosipod @Manut38 How do i get the binary?

I tried to compile it myself, but it always fails.

Ok got it now but my littlefs seems to only have 61 kb of storage. And after i uploaded and deleted some Gifs it doea not empty anymore.

[dosipod]

@oOJoshOo
Just fork and compile the gif branch , i have just compiled that here
dosipod@f41476c
and the CI run with the bins are here https://github.com/dosipod/WLED/actions/runs/10037498528
I see healthy fs so try the same

[oOJoshOo]

@dosipod still the same Problem, to exclude faulty flash i tried three diffrent ESP32 Boards from wich are two the same type of Dev Board.
What ive noticed is that I alwas get this error right after flashing:

Showing logs: [12:27:59].pio/libdeps/esp32dev/LittleFS_esp32/src/lfs.c:1076:error: Corrupted dir pair at {0x0, 0x1} [12:27:59]Ada

And after i Uploaded one gif with 8kb of Size, and i try to upload another anout the same size i get this log;
[12:31:04].pio/libdeps/esp32dev/LittleFS_esp32/src/lfs.c:566:error: No more free space 27

To see the free Space, i used @Manut38 's Tool, its always 61kb. When i install it on the normal Beta then it (obviuosly) does not work, but it shows me the about 1mb i should have.

[dosipod]

@oOJoshOo Corrupted dir pair is normal after you install for the first time . Just use the bins I linked to here https://github.com/dosipod/WLED/actions/runs/10037498528 ( you can OTA that )
Once you do you can check the files under wled-ip/edit to see if you have a lot of them see the info page for fs size .
And might be github is not the correct place for setup issues so please use discord for that as the gif branch works on multiple setups and with multiple guys testing that

[oOJoshOo]

Ok thank you for your patience, and will to help me solve my Problem, i wrote in the discord.

It still did not work on my device, Info and edit dont lock abnormal to me.

Thank you.
If it doesn't work out, I'll just have to wait for the release.