Showing images on a TFT or OLED display with a small AVR microcontroller can be a challenge as it requires significant storage space. One solution is to compress the images, but then you need more RAM to decompress it, and that’s a whole other problem. [David Johnson-Davies] of Technoblogy couldn’t find a GIF decoder that fit his needs, so he started writing his own.
We had previously seen a minimal GIF decoder aimed at a Cortex-M0+ that required 24 K of RAM, but this technique is running on an AVR with just 12 K of RAM. Along the way, [David] uses little tricks to shave down the requirements. Since the TFT he targets is a 5-6-5 color space, those 3-byte colors become 2 bytes. The LZW lookup table is encoded as 12-bit pointers to earlier entries plus an additional pixel. However, these savings come at a cost. Animated, local color tables, transparency, interlacing, or GIF87a formatted images aren’t supported. But he ports it over to the PyBadge, which is ATSAMD51 based.
[David] provides some sample code to display a GIF from program memory and an SD card. All the code is on GitHub under a CC By 4.0 license.
I remember that hackaday had a article about a image format that was like gif/png but used less resources, can someone link it so I can find it again?
Finally my search skills worked, after posting my previous post…
I was thinking of qoi https://qoiformat.org/ but the article was https://hackaday.com/2022/05/08/creating-an-image-format-for-embedded-hardware/ where the first comment was about qoi.
https://hackaday.com/2022/05/08/creating-an-image-format-for-embedded-hardware/
Why would GIF87 not be supported? It doesn’t look like the format changed in a way that wouldn’t be upwards-compatible…
It looks like they just didn’t bother, and hard coded the header string check. I’ve never even seen an 87a file in the wild anyway…
Any single image GIF89a, should be saved as a GIF87a. Only most idiot programmers don’t bother.