Recognizing Barcodes: Take 4

Earlier blogs on the barcode library can be found here.

The next task I set for myself for the OpenNETCF.Barcode library was detecting the bounds of a barcode.  My initial thought on how to achieve this was to use a Fast Fourier Transform, or FFT of the horizontal luminance lines I was already extracting.  The general idea would eb that I’d get an initial line across the middle of the image and make the assumption that this line crosses the barcode.  I then run an FFT for this data and look at the power spectrum (basically looking at what the highest frequencies are). 

The actual frequencies returned are not relevant.  My idea was that I could then “move” up and down from that line, say at 10 pixel spacings, and do an FFT on these lines.  If those FFTs lead to similar spectra, then we’re still on the barcode.  If the spectra changes dramatically, we’ve left the barcode.

Fortunately I’d done an FFT algorithm port for the SDF ages ago though this is the first real-world use of the class.  I had to add a bit of code to generate a power spectrum, but once that was done I was a bit surprised to see how well the code worked.  I updated the test UI to display both the current Y position used for decoding (in green) and a red box for the “detected” bounds on the barcode, then ran it against several new images I’d taken.

As you can see, the bounds detection is pretty good.  Next up will be figuring out how to actually use this information.

2 thoughts on “Recognizing Barcodes: Take 4”

  1. Hi Chris,
    how does your bounds detection mechanism handle sligtly rotated barcodes or situations where the device camera is not 100% paralel to the barcode, resulting in the barcode seeming bigger on the end closer to the camera. I suppose both situations may be frequent when you’re trying to focus a barcode so near the device.

    About the feedback to the user, I don’t know how long does your mechanism take to identify and process the bounds, based on other approaches, it would be great to, instead of having the user press the ‘take picture’ and then process the image, have a live preview window where as soon as the previewed image can be processed, give feedback to the user and close the live preview.


  2. Alberto, currently rotation and skew are not handled though I have thought about them (you can see in the images above many have those properties). It seems that it would be fairly easy to find the "slope" of the start and end bars to determine both of these and do manipulations based on these values when necessary.

    As far as speed goes, well I’m on a hefy desktop machine with loads of RAM, so it’s instantaneous. I’ve not even tried moving this to a device yet (nor have I really done much for optimization). My plan is to get it working reliably in an environment where testing is easy (desktop) and when I have it working, port it to the Compact Framework where all I have to worry about then is perf.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s