Ask HN: What should I consider when designing a custom embedded graphics format?

3 points by denis_dolya 243 days ago | 4 comments

I am working on a new embedded graphics format that aims to be simple to parse, memory-efficient, and easily implemented on constrained devices without external libraries. The motivation for this project comes from years of experience working with existing formats. PNG is difficult to parse on embedded platforms without significant library support, and BMP, while simple, consumes too much memory for many constrained systems. I wanted to explore a solution that combines the simplicity of BMP with improved efficiency and a structure that is easy to implement directly in code.

I have considered raw-based formats with minimal headers, similar in some ways to PCX, but I want to explore alternatives that remain practical for long-term maintenance and extensibility.

What are the most important considerations you take into account when designing a custom data format for embedded systems that will likely need to be maintained and extended over the next 10–15 years? Specifically, I am interested in trade-offs between simplicity, memory efficiency, and potential future flexibility. Any experiences, lessons learned, or patterns to avoid would be very valuable.

andsoitis 243 days ago |

> simple to parse, memory-efficient, and easily implemented on constrained devices

have you considered (compressed) texture formats?

ASTC might very well meet your requirements, including performance on embedded hardware: https://en.wikipedia.org/wiki/Adaptive_scalable_texture_comp...

If not ATSC, also consider ETC and DXT.

denis_dolya 243 days ago | |

ASTC, ETC, and DXT are indeed efficient formats, especially when hardware support is available. In my case, the target devices are microcontrollers without GPUs and with very limited RAM. A software decoder for these formats would require more resources than are realistically available. That is why I am exploring a simpler format that can be implemented with minimal overhead and predictable performance, even on very constrained hardware.

flogflig 243 days ago |

What about PNG but with a constrained encoder and decoder that only supports a minimal subset of the specification?

denis_dolya 243 days ago | |

Restricting PNG to a smaller subset is a reasonable idea, and I did consider it. The challenge is that even a limited PNG still requires handling deflate compression and integrity checks, which add complexity to the parser. On many classes of microcontrollers, that creates unnecessary overhead and dependencies. My goal is to design a format that can be fully described on a single page of documentation and implemented from scratch in just a few hours, while remaining flexible enough to extend in the future.