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

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.