jsQR
jsQR copied to clipboard
cozmo
Equivalent feature to ZXing's TRY_HARDER?
I finally got around to actually testing some of the images I want to scan qr codes in and the success-rate with jsQR ends up being on the edge of unusably low for me. I decided to try the JS port of ZXing and it's success rate was around the same... until I turned on the TRY_HARDER hint, now it almost seems to be able to scan anything I throw at it. Any chance that's a feature that could be easily added to jsQR?
Here's some example images that fail for jsQR and ZXing without TRY_HARDER enabled but that works when it is:
Hunh... Doing a little more rigorous testing and there doesn't seem to be any super clear patterns. Sometimes jsQR can see things, some times only ZXing without TRY_HARDER can.
Another hour or so of playing around in, I've found that jsQR ends up working almost every time if I scale the image down by 3.5 if it doesn't find it the first time. Which bring me back to the original question, would it be reasonable to add a flag to make jsQR try a little harder (and maybe use some image manipulation)?
Hey! Thanks for the investigation.
We've talked about adding the equivalent to TRY_HARDER in the past, and would fully support it. I think #78 opens up the path towards that too, as it introduces the ability to disable a feature for speed. Ideally inverting would have been opt in, not opt out, but too late to change that now.
I do think one thing we'd probably do different than ZXing is have individual flags to configure, instead of one omnibus TRY_HARDER flag. This would give people more control and insight into how they're changing the scanning.
Off the top of my head these are the things we could tweak to make jsQR more aggressive
- Try to invert the image colors (already done :D)
- Try to scale down the image (seems like you've hit some success with this?)
- Increase the number of finder pattern candidates we search (right now hard coded to 4). 4 is pretty arbitrary but increasing it increases the total patterns looked at exponentially, so it has a large impact.
- The nuclear option would be to take every possible finder pattern group we found and pass them downstream through decoder etc, instead of just the best scoring one. This would also fix https://github.com/cozmo/jsQR/issues/24.
Not sure if you have any other ideas that you think would be helpful?
Those all some good to me. For scanning multiple QRs, would you expect the best scoring n finder pattern groups to correspond to n QR codes in the image (or would you get groups of finder patterns belonging to different QR codes)? If so, it might make sense to have an expected maximum number of QR codes option to drive both the number of finder pattern candidates and the number of finder pattern groups.
The last two options here would be really helpful.
Are there any plans to implement this?
