typically on these cameras the lens is mounted and focused by a screw thread. there is not usually an 'infinity stop' because the mount is very simple, so i would expect the lens may be mechanically positioned outside the useful focus range. a 110 degree FoV is a very wide lens, so the useful screw range may be quite mechanically narrow, but when positioned properly it will have a very deep in-focus field, capturing near objects and far objects clearly.
the datasheet doesn't say much about focus, but it looks like the rim of the lens is knurled for grip, so try rotating the lens. 'screw out' will bring focus nearer, 'screw in' will push focus farther. i would suggest indexing your start position with a paint pen for easy return, and then index the correct position if you find it.
if all else fails, you could place a small aperture in front of the lens. this will reduce light transmission but also improve the focus field, like squinting your eyes.
My experience with small QR code readers like this on ESP32 boards is that without a viewfinder, they lose a lot of utility. The feedback loop that a viewfinder gives with positioning and knowing when the QR code is detected is invaluable.
All of the cheap camera based two-dimensional barcode modules that I see on AliExpress tend to ship with a white LED as well as a red LED. The white LED is for general flood illumination and the red LED has some sort of pattern and lens array that keeps it centered in the cameras field of view and appears sharp and focused when the barcode is at the optimal distance.
Camera detects motion, turns white LED and red LED on. Paper or screen with the QR code is now illuminated and humans can move up and down until the red Target appears in the center and in focus. Approximately a quarter of a second after that happens, you hear the beep noise indicating a successful read and decode
In places where QR payment is commonplace, readers without viewfinders often get round this issue with a pyramidal frame in front of the camera marking out its FOV, the rectangular opening indicating where the QR code should be aligned. From experience, the code often reads before you even finish approaching the reader.
Aliexpress listings can have multiple different items, and the price displayed in the search results will be that of the first of those (in your case, probably just an antenna) rather than the actual item you searched for or even the item image shown on the results page.
Not just the first, seems like the cheapest. I did a quick search and one result listed the second object's price, which was some permanent adapter board. But it's hard to fix such a thing. For example what if you really did want to buy another antenna for the device? Ok so maybe you require the listed price be the maximum. But what about like a raspberry pi kit where maybe you don't want the case or high capacity sd card or RAM, which could bring down the cost dramatically.
Especially when there is strong incentive to work around any such fix. Individual sellers do it deliberately often to make their listings appear more attractive, if this is "fixed" they'll find another way to be deceptive about the price that appears in searches, bitch & moan, or (much less likely) actually leave in favour of another marketplace, or some mix of the above. It is one of the reasons I simply ignore such places (others including delivery times and reliability: will I actually get the right thing that I think I'm ordering, or anything at all?) - yes, there might be genuine bargains to be had, but if you count the time and effort to find them amongst the deliberately deceptive listings, and the other concerns, I've found that I'm better off not bothering.
It isn't just on marketplace type sites like AliExpress, Amazon, and such, it is also often done on individual sales pages in order to game shopping search engines like google's, though it is more common, to the point of being ubiquitous, on Ali and their ilk.
One answer is that the individual products should be there own listing in the search so if I'm searching for the whole thing it is easy to see the price of that, same if I just want an individual part or add-on. If showing the lowest price, make sure any image is of that list price item not the more expensive one most likely being searched for. But that requires the sellers to properly file the listing details, and good luck enforcing that when they have competitive incentive not to.
There is also the issue of very similar items: the same thing in different materials/colours/etc (things like 3D printer filament) where the price might vary. In that case perhaps an answer is to display a range on the search results ("from £x to £y") though that becomes a new problem to solve when the user selects to order by price.
Somewhat incidentally, is there an actual description of how a low-tech QR code reader would work? I’ve looked for this a few years ago and all solutions I could find were of two flavours: (1) use ZXing (“Zebra Crossing”, a now-unmaintained library[1] for every 1D and 2D barcode under the sun); (2) use OpenCV. Nowhere could I find any discussion of how one would actually deal with the image-processing part by hand. And yet QR codes are 1994 tech, so they should hardly require fancy computer-vision stuff to process.
You can roughly divide barcode reading into a "frontend" and a "backend". The backend is the most well understood (but not necessarily trivial) part: you take a binary image, with each pixel corresponding to one little square in the QR code, and decode its payload. It doesn't need computer vision. The "frontend" is the part that takes the raw image containing the barcode and tries to find the barcode, and convert the barcode it finds into a nice, clean binary image for the backend. This is a computer vision problem and you can arbitrarily fancy, including up to using the latest trends in ML vision models. However, this isn't necessarily needed in most cases; after all, barcodes are designed to be easy to read for machines. With a large, sufficiently well focused and well exposed image of a barcode you can get away with simple classical computer vision algorithms like histogram-based binarization and some heuristics to identify the spatial extent of the barcode (for example, most barcode symbologies mandate "quiet space" (blank space) to be around the barcode, and have start and stop markers; QR codes have those prominent concentric squares on the corners).
As for implementation, Zxing-cpp [1] is still maintained, and pretty good as far as open source options go. At this point I'm not sure how related it is to the original zxing, as it has gone substantial development. It has python bindings which may be easier to use.
On mobile, Google MLkit and Apple vision also have barcode reading APIs, not open source but otherwise "free" as in beer.
I think many places roll their own. QR codes have a finder pattern of alternating black and white with relative spacing of 1-1-3-1-1 for any line that goes through the center of it. This has a low false positive rate so this step is the most important for performance. Since orientation doesn’t change the pattern horizontal scans are sufficient, once the center, scale, and rotation has been found the rest is fairly straight forward. There isn’t really a good reason why this set up couldn’t be rotation invariant, the processing power required is pretty low.
You could have a look at the ISO spec on QR Codes to get the authoritative source on what kind of processing required.
Alternatively (and what I would recommend), is grab a library that is dedicated to QR Code reading (I‘ve used Quirc, for example) and just read the code.
Typically you threshold an image to get a binary representation (1: black, 0: white). Then you detect the finder patterns by looking for 1-1-3-1-1 runs of black/white. Once you have a bunch of finder patterns localized, you form triplets and decode the binary matrix that they span.
That’s not what I’m asking about: once you’ve found the QR code in the bag of pixels you got from your camera and converted it to a boolean array of module colours, then yes, all you have left is a bit error-correction math and some amusingly archaic Japanese character encoding schemes—definitely some work, but ultimately just some work. (For that matter, the Wikipedia article on QR codes contains enough detail to do this.)
What has thus far remained a mystery to me is going from a bag of noisy pixels with a blurry photo of a tattoo on a hairy arm surrounded by random desk clutter to array of booleans. I meant “by hand” as in “without libraries”, not “using a human”, as in the latter case the human’s visual cortex does the interesting part! And the open-source Android apps that I’ve looked at just wrap ZXing, which is huge (so a sibling commenter’s suggestion of looking at a different, QR-code-specific library is helpful).
You can examine the code of zxing-cpp (which is fairly nice IMO) for a simple, "classical computer vision" approach to this. It's not the most robust implementation but it is pretty functional.
But in general, you can divide the problem more or less like this (not necessarily in this order)
1. find the rough spatial region of the barcode. Crop that out and only focus on this
2. Correct ("rectify") for any rotation or perspective skew of the barcode, turn it into a frontoparallel version of the barcode
3. Binarize the image from RGB or grayscale into pure black and white
4. Normalize the size so that each pixel is the smallest spatial unit of the barcode.
> What has thus far remained a mystery to me is going from a bag of noisy pixels [...] to array of booleans.
Ah, OK. You can use software like ImageMagick to partition images into levels of gray or just black and white. I have some examples somewhere I played with some time ago, but not accessible online right now, sorry. If the contrast of the original image is high enough, just the qrcode would remain to be parsed.
Here's an example to start with: ImageMagick's -threshold or -adaptive-threshold (depending on the image's lighting) are what you want to look at, e.g. try something like
And if you wanna go even lower, you'll "raw" read the image pixel by pixel to normalise colour to black/white and then read that matrix for the QR pattern.
And then, cause there are some inverted colour QRs, flip and scan again.
I've had a recurring idea in my head of a sensor you could mount in your car, and then be able to read QR codes from the side of the road, and get an index of all the businesses you'd be driving by for later lookup. Not sure how feasible or useful it'd actually be...
That seems easier to do by using OpenStreetMaps and a GPS trace. You would need the businesses to cooperate by putting a QR code out, so they might as well cooperate and keep a maps listing up to date.
I could imagine maybe OCRing the results from a line-scan camera. That would read all the business signs and street names as you drive by them.
”Attractions along the route” must have been a standard feature on satnavs since the very first standalone TomTom sucked onto your windscreen. Newer cars having Google Maps built in make this even richer.
Why would I want to have this? No idea, but if I did I probably would use a modern dashcam (these can easily do 4K HDR with 60 fps nowadays) and later analyze the recording with OpenVC.
Some viofo dashcams even allow the connection of two secondary cams (those only FullHD) so you could scan to the left and right simultaneously to the front.
Reminds me of one of the ideas I heard about for how to do road navigation before GPS - you paint a bunch of barcodes on the road that your car reads as you drive over them, and then your computer figures out where you are (you would probably use dead reckoning with your car's speed and time, too).
positioning limit may be a focus issue.
typically on these cameras the lens is mounted and focused by a screw thread. there is not usually an 'infinity stop' because the mount is very simple, so i would expect the lens may be mechanically positioned outside the useful focus range. a 110 degree FoV is a very wide lens, so the useful screw range may be quite mechanically narrow, but when positioned properly it will have a very deep in-focus field, capturing near objects and far objects clearly.
the datasheet doesn't say much about focus, but it looks like the rim of the lens is knurled for grip, so try rotating the lens. 'screw out' will bring focus nearer, 'screw in' will push focus farther. i would suggest indexing your start position with a paint pen for easy return, and then index the correct position if you find it.
if all else fails, you could place a small aperture in front of the lens. this will reduce light transmission but also improve the focus field, like squinting your eyes.
That's inexpensive enough to be the basis for a modern recreation of the CueCat:
https://en.wikipedia.org/wiki/CueCat
beat me to it. was thinking the same.
#Qcat?
Sadly, Useful Sensors seems to have pivoted to other edge AI tech and no longer sells this or their person detector.
Yeah, that is a shame. Couldn't find something similar unfortunately.
My experience with small QR code readers like this on ESP32 boards is that without a viewfinder, they lose a lot of utility. The feedback loop that a viewfinder gives with positioning and knowing when the QR code is detected is invaluable.
All of the cheap camera based two-dimensional barcode modules that I see on AliExpress tend to ship with a white LED as well as a red LED. The white LED is for general flood illumination and the red LED has some sort of pattern and lens array that keeps it centered in the cameras field of view and appears sharp and focused when the barcode is at the optimal distance.
Camera detects motion, turns white LED and red LED on. Paper or screen with the QR code is now illuminated and humans can move up and down until the red Target appears in the center and in focus. Approximately a quarter of a second after that happens, you hear the beep noise indicating a successful read and decode
In places where QR payment is commonplace, readers without viewfinders often get round this issue with a pyramidal frame in front of the camera marking out its FOV, the rectangular opening indicating where the QR code should be aligned. From experience, the code often reads before you even finish approaching the reader.
I wonder if you could project some red LEDs instead, like barcode scanners?
You can, and it still results in a subpar experience. There are products out there that do exactly that.
Can also do this with an esp-32 camera module which are cheap and all-in-one https://github.com/alvarowolfx/ESP32QRCodeReader
Just checked and the cost for a (non aliexpress) seller ESP32-CAM dev board is around £5-£6 or less than £1 from aliexpress
Aliexpress listings can have multiple different items, and the price displayed in the search results will be that of the first of those (in your case, probably just an antenna) rather than the actual item you searched for or even the item image shown on the results page.
Not just the first, seems like the cheapest. I did a quick search and one result listed the second object's price, which was some permanent adapter board. But it's hard to fix such a thing. For example what if you really did want to buy another antenna for the device? Ok so maybe you require the listed price be the maximum. But what about like a raspberry pi kit where maybe you don't want the case or high capacity sd card or RAM, which could bring down the cost dramatically.
> But it's hard to fix such a thing.
Especially when there is strong incentive to work around any such fix. Individual sellers do it deliberately often to make their listings appear more attractive, if this is "fixed" they'll find another way to be deceptive about the price that appears in searches, bitch & moan, or (much less likely) actually leave in favour of another marketplace, or some mix of the above. It is one of the reasons I simply ignore such places (others including delivery times and reliability: will I actually get the right thing that I think I'm ordering, or anything at all?) - yes, there might be genuine bargains to be had, but if you count the time and effort to find them amongst the deliberately deceptive listings, and the other concerns, I've found that I'm better off not bothering.
It isn't just on marketplace type sites like AliExpress, Amazon, and such, it is also often done on individual sales pages in order to game shopping search engines like google's, though it is more common, to the point of being ubiquitous, on Ali and their ilk.
One answer is that the individual products should be there own listing in the search so if I'm searching for the whole thing it is easy to see the price of that, same if I just want an individual part or add-on. If showing the lowest price, make sure any image is of that list price item not the more expensive one most likely being searched for. But that requires the sellers to properly file the listing details, and good luck enforcing that when they have competitive incentive not to.
There is also the issue of very similar items: the same thing in different materials/colours/etc (things like 3D printer filament) where the price might vary. In that case perhaps an answer is to display a range on the search results ("from £x to £y") though that becomes a new problem to solve when the user selects to order by price.
I even found them on Amazon with Prime shipping for ~$8/each. Curious how challenging parsing a QR code would be with that?
Somewhat incidentally, is there an actual description of how a low-tech QR code reader would work? I’ve looked for this a few years ago and all solutions I could find were of two flavours: (1) use ZXing (“Zebra Crossing”, a now-unmaintained library[1] for every 1D and 2D barcode under the sun); (2) use OpenCV. Nowhere could I find any discussion of how one would actually deal with the image-processing part by hand. And yet QR codes are 1994 tech, so they should hardly require fancy computer-vision stuff to process.
[1] https://github.com/zxing/zxing
You can roughly divide barcode reading into a "frontend" and a "backend". The backend is the most well understood (but not necessarily trivial) part: you take a binary image, with each pixel corresponding to one little square in the QR code, and decode its payload. It doesn't need computer vision. The "frontend" is the part that takes the raw image containing the barcode and tries to find the barcode, and convert the barcode it finds into a nice, clean binary image for the backend. This is a computer vision problem and you can arbitrarily fancy, including up to using the latest trends in ML vision models. However, this isn't necessarily needed in most cases; after all, barcodes are designed to be easy to read for machines. With a large, sufficiently well focused and well exposed image of a barcode you can get away with simple classical computer vision algorithms like histogram-based binarization and some heuristics to identify the spatial extent of the barcode (for example, most barcode symbologies mandate "quiet space" (blank space) to be around the barcode, and have start and stop markers; QR codes have those prominent concentric squares on the corners).
As for implementation, Zxing-cpp [1] is still maintained, and pretty good as far as open source options go. At this point I'm not sure how related it is to the original zxing, as it has gone substantial development. It has python bindings which may be easier to use.
On mobile, Google MLkit and Apple vision also have barcode reading APIs, not open source but otherwise "free" as in beer.
[1] https://github.com/zxing-cpp/zxing-cpp
I think many places roll their own. QR codes have a finder pattern of alternating black and white with relative spacing of 1-1-3-1-1 for any line that goes through the center of it. This has a low false positive rate so this step is the most important for performance. Since orientation doesn’t change the pattern horizontal scans are sufficient, once the center, scale, and rotation has been found the rest is fairly straight forward. There isn’t really a good reason why this set up couldn’t be rotation invariant, the processing power required is pretty low.
You could have a look at the ISO spec on QR Codes to get the authoritative source on what kind of processing required.
Alternatively (and what I would recommend), is grab a library that is dedicated to QR Code reading (I‘ve used Quirc, for example) and just read the code.
Typically you threshold an image to get a binary representation (1: black, 0: white). Then you detect the finder patterns by looking for 1-1-3-1-1 runs of black/white. Once you have a bunch of finder patterns localized, you form triplets and decode the binary matrix that they span.
Using https://duckduckgo.com/?q=qrcode%20decode%20by%20hand gives me a number of results like
http://blog.qartis.com/decoding-small-qr-codes-by-hand/
https://beck-thompson.github.io/QRcodewebsite/
Reading QR codes without a computer! https://qr.blinry.org/
And then there are a number of OSS implementations for Android (check fdroid.orgl, Debian/Ubuntu, etc. Maybe study the code?
That’s not what I’m asking about: once you’ve found the QR code in the bag of pixels you got from your camera and converted it to a boolean array of module colours, then yes, all you have left is a bit error-correction math and some amusingly archaic Japanese character encoding schemes—definitely some work, but ultimately just some work. (For that matter, the Wikipedia article on QR codes contains enough detail to do this.)
What has thus far remained a mystery to me is going from a bag of noisy pixels with a blurry photo of a tattoo on a hairy arm surrounded by random desk clutter to array of booleans. I meant “by hand” as in “without libraries”, not “using a human”, as in the latter case the human’s visual cortex does the interesting part! And the open-source Android apps that I’ve looked at just wrap ZXing, which is huge (so a sibling commenter’s suggestion of looking at a different, QR-code-specific library is helpful).
You can examine the code of zxing-cpp (which is fairly nice IMO) for a simple, "classical computer vision" approach to this. It's not the most robust implementation but it is pretty functional.
But in general, you can divide the problem more or less like this (not necessarily in this order) 1. find the rough spatial region of the barcode. Crop that out and only focus on this 2. Correct ("rectify") for any rotation or perspective skew of the barcode, turn it into a frontoparallel version of the barcode 3. Binarize the image from RGB or grayscale into pure black and white 4. Normalize the size so that each pixel is the smallest spatial unit of the barcode.
> What has thus far remained a mystery to me is going from a bag of noisy pixels [...] to array of booleans.
Ah, OK. You can use software like ImageMagick to partition images into levels of gray or just black and white. I have some examples somewhere I played with some time ago, but not accessible online right now, sorry. If the contrast of the original image is high enough, just the qrcode would remain to be parsed.
Here's an example to start with: ImageMagick's -threshold or -adaptive-threshold (depending on the image's lighting) are what you want to look at, e.g. try something like
And if you wanna go even lower, you'll "raw" read the image pixel by pixel to normalise colour to black/white and then read that matrix for the QR pattern.
And then, cause there are some inverted colour QRs, flip and scan again.
There's zxing-cpp that is a fork of zxing and actively maintained: https://github.com/zxing-cpp/zxing-cpp
If you pair this with a eink display you could send messages back and forth with another device https://remotehack.space/QR-TX/
Great for bridging air-gaps....
A fridge-mounted ESP32 barcode integration would be pretty awesome for tracking fridge inventory
I've had a recurring idea in my head of a sensor you could mount in your car, and then be able to read QR codes from the side of the road, and get an index of all the businesses you'd be driving by for later lookup. Not sure how feasible or useful it'd actually be...
That seems easier to do by using OpenStreetMaps and a GPS trace. You would need the businesses to cooperate by putting a QR code out, so they might as well cooperate and keep a maps listing up to date.
I could imagine maybe OCRing the results from a line-scan camera. That would read all the business signs and street names as you drive by them.
”Attractions along the route” must have been a standard feature on satnavs since the very first standalone TomTom sucked onto your windscreen. Newer cars having Google Maps built in make this even richer.
Why would I want to have this? No idea, but if I did I probably would use a modern dashcam (these can easily do 4K HDR with 60 fps nowadays) and later analyze the recording with OpenVC.
Some viofo dashcams even allow the connection of two secondary cams (those only FullHD) so you could scan to the left and right simultaneously to the front.
Reminds me of one of the ideas I heard about for how to do road navigation before GPS - you paint a bunch of barcodes on the road that your car reads as you drive over them, and then your computer figures out where you are (you would probably use dead reckoning with your car's speed and time, too).
Would you genuinely want this? I personally can't see why. Perhaps at conventions it could be useful as it's hard to visit every table.
Anyone who knows of a cheap sensor that works in Linux and can read Digikey bag barcodes?
I'm unclear about a specific sensor, but it looks like the format you want to decode would be "Data Matrix ECC 200"
https://forum.digikey.com/t/digikey-product-labels-decoding-...
I think a smartphone and custom app would be the worst case scenario in terms of cost, and that could be pretty cheap.
I love these. Kinda insane they got it packaged so cheaply.
A cheap android phone would perform better and for much cheaper.
Where are you getting android phones for $7?
Free. Friends go through android phones all the time. You can pick up $20 ones new or cheaper ones on ebay or whatever.
How are you getting the chip, micro controller, extra electrical components, breadboard/proto board, and power supply for $7?