jsQR
jsQR copied to clipboard
cozmo
Multiple QR codes in the same document
There is some complexity here, but makes sense as something to support.
Once we finish rewriting the ported code (#31 etc) we can investigate what it would look like to support multiple QRs in a performant way.
Also happy to accept PRs for this if anyone wants to take a stab at it.
We have now merged the rewritten locator code as part of #40, so this is easier than it was before. Still would love help with this if anyone is interested.
@cozmo would breaking the current API to have it return an array instead of a single item be acceptable?
We could certainly change the API and just bump the major version, or alternatively just export another method called locateMultiple or something, either approach seems reasonable. I think the first step is updating the locator code to search and return multiple and since that is an internal method we can do whatever with that method signature.
I would like to take a swing at this, I've got a copy of the QR standard and if we use their pattern-finder location method it should be able to easily pull out multiple QR codes from one BitMatrix.
Let me see what I can come up with this week, I'll make a pull request when I'm done and we can look at the success rate compared to the existing location method to see if its even worth it.
@cozmo, if you have some time this week I would love to do a quick web-meeting to discuss your current locator. It seems really close to the ISO method but from what I can tell not 100%, could just be I'm not as familiar with your style....
let me know!
Awesome! I'd love to hop on a meeting, maybe with @jefff too (who wrote a lot of the locator code). Wanna shoot me an email to figure out scheduling? My email is in my profile.
Any progress in this direction? Were there any blockers you discovered that another contributor should be aware of before working on this?
Haven't chatted with @gomjabar6 for awhile. Last time I think we were struggling with performance and general optimization, which I think is always going to be the issue here.
I think the general if anyone has a good idea around how they want to change locator to output multiple candidate QR codes without the performance growing unbounded, then I'd be happy to discuss. I still believe this issue is very solvable with the current architecture, but locator is already the most performance intensive step of the pipeline, so may be difficult to do in a performant way.
Has there been any progress on this front? Really looking for a scatter-gun approach to scan multiple QR codes at once.
Hey Everyone,
Sadly I have not made progress on this front! I ended up getting super tied town with optimizing the configuration options around how a QR is identified. As @cozmo mentioned, the locator is very optimized the way it is. My solution could find multiple QRs appropriately but some test cases blew it up and put it into terrible loops. Trying to dial in the settings to work on a majority of test cases ended up being the sticking point.
That said it has been a couple years since i last attempted this, perhaps with hindsight I could get it working better. I am sorry for not being more communicative lately. Let me take another look and I'll share my approach here soon.
Thanks for the update. I look forward to your follow up.
On 10 Mar 2020, at 6:16 pm, Garrett Curtis [email protected] wrote:
Hey Everyone,
Sadly I have not made progress on this front! I ended up getting super tied town with optimizing the configuration options around how a QR is identified. As @cozmo mentioned, the locator is very optimized the way it is. My solution could find multiple QRs appropriately but some test cases blew it up and put it into terrible loops. Trying to dial in the settings to work on a majority of test cases ended up being the sticking point.
That said it has been a couple years since i last attempted this, perhaps with hindsight I could get it working better. I am sorry for not being more communicative lately. Let me take another look and I'll share my approach here soon.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.
Yea, this seems like an issue that has a lot of clear value, and community excitement behind it. I'd love if jsQR supported it, but it's a non trivial amount of work, and will involve basically rewriting the locator, or at least changing it drastically.
I can't imagine the next version of jsQR shipping without support for this, but I don't personally have any plans to ship the next version soon (would consider the current version pretty stable/feature complete).
One other idea I've toyed around with is taking an image in and dividing it into regions that "smell like a QR code*" vs regions that don't, and then discarding the regions that don't. Assuming this could be done efficiently it could bring general performance enhancements since it would mean the binarizer/locator (which make up the majority of the work of detection) could be run on much smaller images. A side effect of this could be if there are multiple regions that "smell like a QR" then we could run each of them through the rest of the pipeline, thereby detecting multiple codes without needing to change locator much.
*They key here is how we define "smelling" like a QR. I think some sort of measure of how many similar colored square/straight lined regions exist nearby would be close, but the devil is in the details..
I had toyed around with this idea previously. My approach to that would be greatly reducing the resolution (maybe a factor of 10) and looking for "smells like QR" regions from there. That way you are not spending so much time iterating over huge pixel counts. Decided to stick with my "triangles" approach for now.
Well, I currently have a workaround for this. I look for a QR, when found, I erase that area with white color and run the search again.
