Aircoookie
Image effect (GIF support)
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 :)
~~Is the removal of mqtt.cpp intentional or accidental?~~
Eh! Disregard. I see that entire file was changed. Probably CRLF.
Now we will really need to start working on SD card support. 😄
SD support is already implemented and merged as usermod
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.
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.
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
@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.
@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.
@oOJoshOo Just fork and compile the gif branch , i have just compiled that here https://github.com/dosipod/WLED/commit/f41476c48cf6ad7f97937e6f4106c0d25e412aee 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
@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.
@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
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.
The gif tree https://github.com/Aircoookie/WLED/tree/gif still lacks support for 16MB ESP32 Devices "esp32s3dev_16MB_opi". Can it be added easily?
It still did not work on my device, Info and edit dont lock abnormal to me.
@oOJoshOo In fact your "filesystem" info looks extremely abnormal. Did you use ESP Home Flasher? This tool is well-known for creating corrupted WLED installations.
Your filesystem size is only 61kb, while it should be more than 900. Its a miracle that anything worked at all.
That was the problem i tried to install it OTA which bugged it out, after flashing it with ESP Home Flasher it worked.
That was the problem i tried to install it OTA which bugged it out, after flashing it with ESP Home Flasher it worked.
"corrupted WLED installation" includes "WLED runs after installing, but you will have problems later"
Our main documentation say "Please consider using WLED ESP Flasher, or the official web-based installer , or this alternative web installer".
So you mean the ota had problems, because i installed wled with esp home flasher in the first place?
Hello, I've been working on the rebase it is available in my fork. https://github.com/Liliputech/WLED/tree/gif
What is the status of this PR @Aircoookie? What is still outstanding in getting this merged?
The main issue is increase of code size. Last time I checked it was beyond 10kB which would be problematic if any usermods are included (or when debugging).
So just needs to be optional via build flags and only included then on the images with larger flash
It is possible to disable by adding the "-D WLED_DISABLE_GIF" flag but this is not by default and not so obviously documented. I'd say it may be better to have it disabled by default, like a usermod (like ANIMartrix effects for examples). Having it in core makes it more efficient than usermod though, as some of the image_loader functions could be useful to other effects or usermod as well.