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?

[cozmo]

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 😄)
• 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?

[samuelcolvin]

The last two options here would be really helpful.

Are there any plans to implement this?