Skip to content
Call us for support

1800 123 456

$0.00 USD

OpenMV Cam RT1062, H7 Plus, and more!

Posted by Kwabena Agyeman on

Hi all,

We finally shipped out half of our order backlog! OpenMV Cam RT1062's are on their way now! Hopefully, we should be able to clear out the remainder of our backlog over next week. Also, the OpenMV Cam RT1062 is now in stock on the online store and available to purchase!


As mentioned before, we are sampling second-revision versions of shields for the OpenMV Cam RT1062, which we will be able to roll out next year.

Anyway, please buy your OpenMV Cam RT1062 now!

OpenMV Cam H7 Plus Production Status

As for the 5000 OpenMV Cam H7 Plus units we are building, the factory has completed about 20% of the order so far and will start making partial shipments to our shipping warehouse soon. We expect to be able to start shipping OpenMV Cam H7 Plus units in about two weeks. Once we have them in stock, we will allow you to purchase them again.

OpenMV IDE and Firmware Updates

Other than getting units back in stock, we were working hard on firmware and software updates. Here's what's new:

OpenMV IDE Example Filtering

With the latest release of OpenMV IDE, we significantly improved the user experience with our examples. The IDE now filters examples by the connected board and sensor type. Now, only what is relevant and runnable on your OpenMV Cam is shown (there's a checkbox under tools to see everything if you want, though).

OpenMV IDE Focus Metric

Ever wanted to know how sharply focused your lens was? Now, OpenMV IDE displays a focus metric heuristic of the whole scene or selected area in the frame buffer. How do we compute a focus metric? By JPEG compression! It turns out that the JPEG file size produced by an image is more or less correlated to how sharp the image is. Anyway, OpenMV IDE now displays a score on how sharp your image is. Use this feature to get your focus to the best it can be.

MP Parse All Support Added to most OpenMV Functions

Have you ever passed a keyword argument to a function, and nothing happened because you misspelled the argument? Well, not anymore. You're going to get an error now! Ibrahim spent the last couple of weeks updating quite literally hundreds of functions in our firmware to use MicroPython's Parse All function which detects if there are errant unused keyword arguments and lets you know your code is bad instead of silently ignoring the issue.

But, we've still got a lot of work to do. We updated everything but the image module, which we will start on next after some refactoring work on it.

Fun with Transpose

Our draw_image() backend has been improved to support transpose in addition to hmirror and vflip! Using combinations of these flags you can now rotate images by 90, 180, and 270 degrees.

We improved support here for the Arduino Giga, which has a screen that's rotated by 90 degrees. Originally, transpose on images was only available via our set/assign/replace operator. However, now with it built into our draw_image() backend, transpose is now available for many different functions.

It took some effort to make this feature work well. While the concept behind transpose is simple, swap x and y pixel locations, it turns out that this is incredibly harsh on memory data access. Doing a transpose of an image brings SDRAM to its knees.

So, how did we overcome this? Well, it turns out the processor SRAM can be used as a cache. So, we transpose an image in SDRAM by splitting it into chunks which can be written to SRAM. This allows us to use fast row access on the image in SDRAM while writing it via columns into SRAM (this is the expensive operation... one pixel per row - e.g. a column) before writing back out the columns as rows into SDRAM.

Couldn't follow that? Doesn't matter, all you need to know is that we got a 5X (which is huge) performance improvement by doing this. This means transpose is so fast now it's pretty much free to use - meaning image rotations by 90, 180, and 270 are now free to use.

Smart Scaling Too

But, that's not all, the draw_image() backend now supports scaling hints to simplify drawing scaled images too. We added the hints CENTER, SCALE_ASPECT_KEEP, SCALE_ASPECT_EXPAND, and SCALE_ASPECT_IGNORE.

CENTER allows you to center an image being draw on another image or canvas. 

SCALE_ASPECT_KEEP will then scale that image to fit inside another image or canvas.

Or, if you want to fill the image completely and don't care about cropping, you can use SCALE_ASPECT_EXPAND.

Finally, SCALE_ASPECT_IGNORE is available for folks who just want to scale an image up while ignoring the aspect ratio blindly (this will stretch the image, though).

And Finally, In Function Image Loading

And last but not least, Ibrahim refactored our file management code which had not been touched much since the old M4 days. We now support directly drawing images on other images and displays via a file path. E.g.

display.write("arduino_logo.png", hint=image.CENTER|image.SCALE_ASPECT_KEEP|image.ROTATE_90)

Which will display the Arduino logo centered, scaled, and rotated directly from a file path on the Arduino Giga's screen.

Just think about how much code is running under the hood to make the above one function call.

As we build out the draw_image() backend, we plan to add ARGB8888 support too, so you can handle PNGs with alpha layers to blend logos onto live video.

Also, if there's demand, we can actually make almost any function accept a file path now for its image source. However, we don't want to encourage terrible code, so we will not add this feature everywhere except where it makes sense. From a performance standpoint, using the disk as RAM is not a great idea. Since we're an MCU, we don't buffer the file system in RAM like Linux does. So, you don't want to use image file path loading in a loop if you care about performance.

Anyway, that's all, folks!