New Arduino JPEG Library Focuses On Speed

Working with graphics on microcontrollers has always meant focusing on making the most of limited resources. Particularly in the 8-bit era, all manner of tricks were used to get low-performance chips to achieve feats beyond their lowly station. However, these days, we’re blessed with 32-bit workhorses with clock speeds in the tens, or even hundreds, of MHz and many kilobytes of RAM to match. It’s these higher performance chips [Larry] had in mind when writing his JPEGDEC library.

As [Larry] discusses in a blog post on the topic, JPEG libraries already exist for the Arduino platform. However, many of these are aimed at 8-bit platforms with tiny amounts of RAM. While it’s possible to decode JPEGs piece by piece with some intelligent code under these conditions, it’s possible to go much faster when you’ve got a little more headroom. [Larry] does a great job of explaining the variety of optimizations he’s developed in the two decades since writing his first JPEG decoder back in 1994. From eliminating unnecessary marker checks to ignoring unneeded data for scaled-down output, it all adds up to get the job done faster. The library targets the Cortex-M0+, or any chip with a minimum of 20K of RAM, as its bare minimum to operate. Faster chips with higher clock rates naturally do better, and [Larry] provides benchmark decoding times for various common hardware using the library.

We’ve featured [Larry]’s GIF decoder for the Arduino platform before, again a useful library that’s optimised for good performance. If you’ve got your own neat tricks for image processing on microcontrollers, you know how to call!

10 thoughts on “New Arduino JPEG Library Focuses On Speed

      1. I was playing around with the library last night, I was only decoding tiny images (64×64) but using an esp32 I was reading them from spiffs, decoding them and displaying them on a HUB75 matrix in about 30mS

      2. Yes, you’re right, this demo used very simple code where the SD card and SPI-based display communication are blocking. Sending the pixels to the display seems to be the slowest part. But honestly, I didn’t put much work (yet) into benchmarking. It was all done quickly in the simplest way to get an initial look at Larry’s new library, kind of like an “unboxing” video.

      1. I was precisely trying to find a solution to the bandwidth limitation of “reading from SD card and displaying on a screen, all through SPI interface”, it would seem that based on benchmark data that this should be perfectly possible to store image in JPG, read/decode/display at probably around 10FPS, if I’m not mistaken ?

  1. With so many LCD panels available for use with small or tiny computers this type of library could prove very useful. BTW, at the end of the article I wonder if meant to say “you know who to call” and not “… how to call”.

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.