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