Guys! Is here anybody who successfully got images from SD card?
I’m trying to get images from SD card and send it to addressable LED strip… So i’m trying to parse GIF files from SD into array. To send later this array into leds.
And i’m stuck.
All that i’ve found is one C program, which get one frame GIF and send it’s to display. I’ve rewriten this into C++ class, and it’s not fit memory My local compiler tells, that program will not fit RAM, and doesn’t compile it. Maybe someone already have script to parse GIF from SD? Or maybe there is another formats to send animation to leds from SD, wich will better fit this hardware…?
Not having your code, it’s just a guess, but I think your promblem is not the logic to parse the img, but the RAM you need to buffer the img.
Maybe you’d need to load smaller chunks of the img at a time, push this chunk out to your display, to free the RAM and move on to the next chunk - or you buffer your parsed data somewhere else and push the data out from there.
Fact is: RAM is not thick on the Core (I think max. 20KB of which up to 14K might by taken by FW, leaving you with 6K to play with).
ekbduffy, ScurffR is correct in that seeing your code would help a lot. He is also correct in saying that there is about 6KB of RAM available for programs so managing how you pull data from the SD is crucial.
I found an arduino sketch that pre-processes .bmp images in rows and writes the data back to the SD. It then reads the pre-processed SD file and sends stips to a neopixel array. That approach keeps the memory requirement low since most of the work is done in the SD buffers. So there are many ways of doing this and finding the one that works is the trick.
As i can see here http://www.arturocampos.com/ac_lzw_gif.html#Gif decoding it must be.
Is there any methods to parse GIF file by pixels? Maybe somebody know method, which will work on STM32?
bko, the max size is set to 100, making that array “theoretically” 32100 = 600 bytes in size. The only problem is I don’t know if the compiler allocates 2 or 4 bytes for a type “short”?
Nonetheless, 600 bytes is a “chunk-o-change” when you have RAM shortage.
This eats up another 256 x 3 COLOR g_GlobalColorTable[256];
I’m not sure how much the SD library is eatin up, and I’m guessing you have more code that deals with the NeoPixels that allocates the bulk of the memory. How many pixels are you running?
Right you are on the dictionary size! I was looking at the comment which lists the largest possible dictionary size for the LZW compression engine. This code will not work on some GIFs with only 100 entries but it should work on most. About a lifetime ago, I wrote a GIF creator for taking screenshots on an early handheld device.
Yes, you need the LZW dictionary–there is no real way around that. The current linked list approach may not be the most space efficient data structure to use. If you are up for the challenge, you could change this to use a more efficient data structure. Particularly if the dictionary size is limited to 100 entries, you could change nextCode and prevCode to be 8-bit instead of 16-bit.
Another thing to consider: can you change the image at the source? Can you have the source do some decoding for you or make your life easier by limiting colors or something?
If you know you are displaying the GIFs on a black and white or 8-bit display, you might be able to make the GIF decoder more memory efficient.
and put that in flash in a const array in your program. Then just read past these bytes doing nothing.
I looked at my GIF creating code from long ago and I used a 5003 location hash table (5003 is 4096 + 7 for overflow) which is not going to work on the Spark core right now.
Does the file format have to be GIF? You can turn off compression completely for BMP files if you have control over the file.
I’ve thinked many time about file format. And preffered GIF as maximum compatible format, which can be viewed on standard computer, smartphone etc, and in future i’ve planned to make uploading this to Core by WLAN, or by attaching it’s SD card to uploading device…
So for now - i will have server in my infrastructure, and that server can send commands to Spark Core. As i see - better way is to get gif files by server, decode it in RGB array and send command to core to download it from server and put on SD…
It’s sad, because i’m loosing possibility to upload GIF files into SD directly, but i don’t see any way to do correct parsing…