Ugh. I hope that can be turned off. Should've been wired, but at the very least, it should be possible to opt out of cluttering up the radio environment with more wifi signals. It can be hard enough to get devices that actually need wifi to find some spare spectrum, without other stuff that could've easily been hard-wired using it up.

Thanks for the clarification. That does sound better, though it's also still good it can be turned off completely.

FWIW, I probably would've gone with a BLE implementation for something like that. Well, personally I would've included a wired option; anyone installing these, hooking up a few more cables with JST connectors isn't going to be a hardship at all. But for a purely wireless solution, BLE would be more appropriate and less worrisome to people before they get the full scoop on what you actually did (as you can see, just mentioning "wifi" sets off alarm bells for some people ).

I'm not entirely sure what the other suggestion was getting at. PNG and GIF are both compressed as well. They are just "non-lossy" formats, whereas JPEG is "lossy". With PNG and GIF you get exactly the same pixels back after compressing and decompressing, while JPEG will invariably involve subtle differences (but typically not noticeable to the human eye). With any of those formats, there will be a decompression step.

What kind of profiling tools are available for software dev on this platform? I've barely used Arduino myself, and don't have any experience with the ESP32 stuff. But if this were a regular PC platform, I would be using a debugger with a profiler to track down what's actually taking time.

That said, given that the rendered numerals work fine (if I understood your notes correctly), that suggests that the issue is either I/O from the SD card, which can vary considerably depending on what kind of media controller you're using, or compression. It seems you've determine it's the latter; hopefully it's by some means you consider reliable.

What is the RAM budget for the project? Is there even any separate RAM? I looked at what I think are the specs for the ESP32 kit you're using, and all I see are specs for flash RAM and 520 KiB of SRAM. And I don't see a separate RAM component on your materials list. Can you increase it considerably while keeping the whole project cost within your goals? Because it seems to me that if the rendered fonts are fine, the most obvious approach would be to just cache the uncompressed images in RAM.

Hence my note about using a profiler to gather actual data on the problem, instead of just making assumptions.

It's true that GIF can be smaller, assuming the image is well-suited for that format (i.e. no more than 256 colors). And if I/O is the bottleneck, then that could help. But there are assumptions built into that suggestion that if they happen not to hold, mean that GIF isn't going to be better than another format.