ASCII ‘art’ for Camera Calibration Python Script

Working on a python script for a focus calibration (software based) routine for a computer vision camera, in order to spruce it up a bit I decide to add a nice ASCII introduction! #Friday


ExifTool truncates ASCII MakerNote data

ExifTool can be used to output a specific Exif MakerNote from your images’ metadata by using the following command:

This will output makernote Id 0x13, however if the makernote that you are interested is long, then ExifTool may truncate it and output only the start with […] at the end!

To have ExifTool output the full makernote, use the -b (binary) option like this:

Using a Virtual USB Serial Port from a Guest OS on VirtualBox

Here is a decent set of instructions on how to access normal COM ports as well as USB Virtual com ports from you Guest OS running on VirtualBox – Thankfully it worked for me but I had to install the FTDI drivers on the Guest for rs232, I got them from here.

Thanks jorgensen!

Have ExifTool Display Maker Notes

Phil Harvey’s ExifTool is a fantastic software tool for displaying and interacting with image Exif data, however by default it doesn’t display maker notes and I always forget the command line options to persuade it to list them, so here it is – the -u option gets exiftool to display ‘unknown’ tags and theses include maker notes!

The makernotes will be listed as unknown items by their hex ids.

Happy days – Thanks Phil!

exiftool display maker notes


I2C1_Wr / I2C1_Rd functions hang with MikroC for PIC – Need Timeout

In some cases both the MikroC i2c functions I2C1_Wr() and I2C1_Rd() can hang or lockup indefinitely until the PIC is reset. This can happen if the I2C bus isn’t properly terminated, for example if a connection breaks or similar (broken wire or solder joint etc). Having your PIC lockup during operation is generally not very desirable if your are trying to develop a stable software system – if for some reason an i2c device hasn’t been properly connected your system will just lockup for good!

Different posts discuss this problem and its various causes:


MikroC provided the code to their functions so that software developers (us) could work around the problem, this library implements versions of I2C1_Wr() and I2C1_Rd() that timeout rather than hang, a timeout values is passed as a parameter:

The library doesn’t implement a C version, so inspired by it (thanks Danny!) I have ported the functions into C, and added some comments – use at your own risk, it works well for me on PIC18F family chips but hasn’t been exhaustively tested!

I have declared the timeouts as constants rather than allowing the timeout to be passed in as a parameter – this is so that the functions can be used as drop-in replacements without having to modify client code.

And to Read:

This works for the first i2c device, it is left as an exercise for the reader to convert it for a second i2c device, i.e. I2C2_Wr() and I2C2_Rd()

libpng – Changing compression level when writing PNG Image

This took me a bit of time to find, but I have been experimenting with libpng for writing software to save 16bit grayscale images and wanted to switch off compression to see if libpng would save the images out any faster than it normally does. When you call png_set_IHDR() you have to set the compression type to PNG_COMPRESSION_TYPE_DEFAULT, there is no alternative (e.g. there is no value like PNG_COMPRESSION_TYPE_NONE), this threw me for a bit…

Anyway after a spell of RTFMing, I eventually found out that you can alter then compression level, and indeed switch it off via a call to:

Setting a value of 0 in your code switches off compression, while setting it to 9 causes the lib to use maximum compression. Quick testing revealed that the time taken to save a PNG does decrease as you reduce this value towards 0 (and the saved image size increases!).

PNG is a good file format option for saving 16bit images, it is lossless and faithfully represents grayscale rather than fudging it into an RGB structure, and as it turns out, supports adjustable compression levels. As more cameras natively support higher bit-depth images, formats and software tools that support the greater precision will become more important so that Computer Vision and Machine Vision software can take full advantage.

PS Viewing 16bit grayscale images is harder than you might think, most software tools seem to down-sample them to 8bit grayscale, So far, I have found that good options are a.) ImageJ b.) Gimp 2.9 (not yet released, have to use a development build). These tools allow you to view the images and properly sample the 16bit pixel values etc…

Raspberry Pi and GPS for Testing Camera Image Timestamps with NTP and PPS


An image time-stamp will tell you when an image was acquired by its camera, they are typically donated in Coordinated Universal Time (UTC) – accurate time-stamps are very often important in Computer Vision Applications especially those that involve observing or analyzing change over time.

Implementing such time-stamp functionality on a camera is very hard and typically involves both hardware and software support – testing the functionality to make sure that the time-stamps are accurate is nearly even harder!

A time-stamp’s accuracy is partly dependent on how well the camera’s time is synchronized, if it’s time is well synchronized by the Network Time Protocol (NTP) then an accuracy of a few milliseconds can be expected, if full pulse-per-second (PPS) synchronization is used then (with care) an accuracy of tens of microseconds can be achieved.

In order to test time-stamp accuracy it is necessary to have an accurate time source to act as a test base-line for comparison purposes, multiple cameras can the then be synchronized to this via their acquisition triggers and NTP or PPS and their images and image time-stamps can be compared.

To this end we have been prototyping a Stratum 1 time source built using a Raspberry Pi with a GPS shield. This will take its time reference from GPS and provide the following for testing cameras:

+ NTP time server (stratum 1) – Raspberry Pi & NTP syncs its time to GPS time via PPS signal and time packets (ZDA packets), the cameras’ NTP clients can use this for synchronizing their clocks (purley software based synchronization).

+ Electrical PPS output – Can be used by camera for syncing it’s time via PPS and for triggering acquisition on second boundaries

+ Re-transmit PPS time packets (ZDA) via UDP – Can be used by cameras for syncing their time via PPS (software & hardware synchronization)

To build the time source we are following this excellent article which explains the various steps involved:

Many thanks to David Taylor, it is a rather complex subject with lots of software setup on the Pi, it hurts our heads but we are making progress, and the initial prototype has already been very helpful in characterizing camera triggering and time-stamping behavior. We expect great things.

In terms of hardware we are using:

Uptronics Raspberry Pi+ GPS Expansion Board – with the GPS Timing Antenna

Raspberry Pi 3

Image Processing with Intel’s SSE SIMD instructions for 12-bit images

Over the last few days I have been working on implementing some low-level 12-bit image processing functions using Intel’s SIMD instruction set – SSE. The aim here is to increase processing time performance as much as possible – initial results are very encouraging, those 128bit register really get things to scream along!

It has been a while since I have done such work on Intel devices (ARM and hence ARM NEON is more common on IoT projects), the last time was before MMX ‘Intrinsics’ were invented and involved hand coding MMX instructions with associated support assembly language. Intrinsics really make coding this stuff so much simpler!

Very often it doesn’t pay for a software engineer to hand-code and optimise image processing algorithms, but when maximum performance is required, huge speed gains can be made with some careful coding on standard hardware!

Cross compiling libEXIF for ARM on Ubutnu

libexif is a software library that allows you to add EXIF tags to JPEG images, for example when saving JPEG images via libJPEG.

The following is a log of the steps taken to cross compile libexif on ubuntu for an ARM IoT device, you will need the arm-linux-gnueabi tool-chain installed on your build machine:

1.) Download the latest libexif source code from:

2.) uzip & untar the software:

3.) Execute the following from bash or similar:

This should put the output files into /home/me/build_exif/_install ready for copying onto your ARM device.

Code to test u-blox Binary GPS Packet Checksum

Here’s something random for a Thursday, the following is some simple C++ code for checking the checksum of a u-blox binary GPS packet, for some reason we get quite a few packet data errors, so it turns out that it is important to check the checksum!

There must be an unwritten (or written?) software engineering rule which states that you should always check a checksum if one’s provided??!?

Note: Make sure to pass only complete packets to this function, it assumes it has everything to work with!