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!
If anyone’s interested to see this in action, I tested Larry’s JPEGDEC library and recorded a little video. Here’s the YouTube link.
https://www.youtube.com/watch?v=nwVwjh3ztBY
Thanks for that video! You’re also reading the images off the SD card for that “full speed” demo, right? So there’s read time in there too.
Could you make a JPEG video? How many frames per second?
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
I’m considering supporting Motion-JPEG (MJPG) playback. There are multiple container formats, but it’s not a big leap from the current code to make it work.
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.
Is it a 600MHz Cortex M7 MCU ?
The Teensy 4.1 is a “turbo charged” CPU. Here’s the same code running on a more humble 120Mhz ATSAMD51 (PyPortal)
https://youtu.be/2ghiB-sj4Bg
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 ?
How well does this library do with ill-formed data, either mistakenly or intentionally? (ie, is it a security risk?)
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”.