AVR Freaks

Google "OpenCV" but don't expect to do this on a lowly AVR8. They are almost certainly using some 32bit ARM. While it's much easier to setup, experiment and develop with OpenCV in a hosted environment (and Linux may be "easier" than Windows) there are "embedded" implementations of OpenCV you can then take to lesser, non-hosted architectures (which probably describes just about anything that is doing any form of "image recognition").

 

A good starting point might be something like an RPi (not Pico) as you will find it very easy to find cameras that easily attach to such a board.

 

When you have a solution then look at scaling it down/industralizing it.

 

(which kind of describes the work I am involved in).

 

EDIT: I assume the kind of product you are talking about is something like:

 

https://www.amazon.co.uk/C-pen-F...

 

https://www.amazon.co.uk/NEWYES-...

 

these things retail at £150-£250 so there's a fair bet there's going to be some pretty powerful electronics in there.

 

(in fact see a post I made a few months back about a Linux board the size of an SD card - this might the perfect application for a board like that !)

Interesting:

 

https://www.renesas.com/us/en/pr...

 

So it's not a lot of "horsepower" for doing something as complex as dynamic (non aligned!) OCR !

 

(I have a sneaking suspicion it's gonna be a bit crap. One of those things you use for 5 minutes and are initially amazed but that is then locked in a drawer after the frustration factor sets in).

 

BTW why would one need something like this  - the "google goggles" function in most cameras can read the text in capture images anyway so most people have a "no cost" solution for this in their pocket already.

I did. However I used the more generic "teardown pen text reader" (didn't want to bias it necessarily to only include c-pen). Unfortunately my search was clearly too generic as I didn't hit anything useful looking :-(

 

You do know what the CV in OpenCV stands for don't you?

 

2 seconds is all it take to learn that...

 

 

 

Those are NOT "C-pen" but the cheaper (£150 rather than £250) one I linked to on Amazon in #4. As it's cheaper the chances are it's even lesser technology.

 

And as for OpenCV. Sure there are more dedicated/niche products for doing Computer Vision and things like character recognition but OpenCV has become something of an "industry standard" since Intel released it to the world. Rather ironically Intel developed it to "show off" the power of their silicon designs when they started to add things like SIMD and now other manufacturers (nVidia, MeidaTek, snapDragon, etc) are adding image processing to their silicon and giving it an OpenCV API interface/driver set so that generic OpenCV developed apps can be ported onto their silicon and benefit from their powerful functionality. I'm not sure this is what Intel really intended to happen when it was originally released - I think they just "got bored" or had no reason for it any more.

 

So these days the two main tools for any kind of image processing application are Matlab to develop targetted applications (probably later converting to C++ code for embedding) and OpenCV for doing all the "standard stuff" like Hough Lines, gaussian Blur, Lucas-Kanade motion tracking, character recognition, face recognition and so on.

 

The only thing about image processing (that works really well) is that it requires huge bandwidth, huge resources (code and RAM) and huge CPU power and none of those things really meld too well with "portable" apps where the thing has to run on very lower power from batteries. So compromises have to be made and I think these pens probably show some of those compromises being put into reality.

 

If you want pen swiping OCR that works really well get a very good camera, a very fast processor, a lot of high bandwidth memory and do it in the best tools: Matlab+OpenCV. 

 

If you want to make/sell a portable, battery powered gadget start introducing some compromises but accept that the accuracy/speed may not end up being so good. But you would probably still "prototype" in Matlab/OpenCV then embed/indutrialize the ideas later.

Presumably it was only reading black and white stripes? A bit trickier to make it read "the quick brown fox jumps over the lazy dog" ;-)

 

My word, there is such a word. I thought German was difficult!

 

I've looked at OCR over the years and played with a number of existing systems under Linux and one or two in Windows, but years ago... I have never come across a system which can do *exactly* what I want from an OCR: one which can reduce an existing page of scanned text to fundamental objects: I want to isolate paragraphs of text as a single unit; I want to identify bold and italic emphases, and I want to identify 'empty line' scene changes. (If you've ever read some of the ebooks available on t'interwebs, you'll see what I mean.)

 

One might expect that this is a 'simple' task, as we are often told that OCR is a 'solved problem', but instead, we get OCR systems which do their very best to replicate *exactly* the text layout on the image, as a high level word processor file, or which simply return a simple text file but without that semantic markup. Last time I looked, one of the best OCR programs for Linux was Tesseract, which had very low recognition errors but which couldn't cope with multicolumn text, or text with sidebars; it didn't provide any information about the semantics.

 

Abbyy did better but only at the cost of significant post-OCR automation: it can provide a plethora of output formats including an XML format which includes the position of each line... so an OCR'd paragraph consists of multiple XML entities, one per line, with position markers, with identified typeface and emphases marked. But one still has to look at the XML to reconstruct a paragraph, and finding the single-line scene change markers is usually possible but tricky. For some reason, people are much better at identifying something that isn't there - an empty line - than robots are.

 

It's been a few years since I looked at this and perhaps things have improved, but maybe I should start looking at it again. It was going to be a retirement project... :)

 

Neil

https://docs.opencv.org/

https://docs.opencv.org/master/d...

 

maybe also:

 

https://www.tutorialspoint.com/o...

 

But to a certain extent OpenCV is just a "toolkit". Sure it will do you an affine transform, a sobel edge detection, a lucas-kanade temporal motion detection, a Laplace transform, an Adaboost dictionary detection or whatever else but it won't tell you WHY you might want to do any of those things. An understanding of the concepts of image processing is assumed.

 

Most of the people we have using this stuff rather strangely are actually doctors of astrophysics. They've done 6 years of PhD trying to make something out of a bunch of dots in a black image and in the process know exactly why you might want to use Gaussian Blurs, Sobel, Hough, Lucas-Kanade, etc etc. They make the perfect vision processing engineers !

 

So if you really want to learn about this stuff consider a degree in Astrophysics (seriously!).

 

(me, I just picked up this stuff as I go along having been doing it for 12+ years, but I'm a "user" not a "designer" of the technology - you have to be really smart to design vision algos!)

Like I say 6 years of fairly intense PhD work is usually a "grounding" in vision processing and OpenCV etc.

 

We do, but for me it's usually coffee/gin/chocolate.

 

If I need to!

God grant me patience and do it now!