feat: quicker scans by faster number aggregation#32
feat: quicker scans by faster number aggregation#32m-schmoock wants to merge 1 commit intocard-io:masterfrom
Conversation
|
Ping @dgoldman-ebay and @josharian. Any assistance here would be greatly appreciated. :) |
|
I'm not comfortable advising you guys on this one; I'd have to delve back into the code more than I currently have time for. Also, this is an area the @josharian worked on a lot, back in the day. Probably he Knows Stuff that would be helpful. |
|
The right way to make decisions like this is with lots of data. I no longer have access to my test data sets, so I can't say anything definitely. And as part of open-sourcing we removed our analytics code, so we can't really gather data from the field. @m-schmook (or anyone else!), if you have a big install base and want to do some instrumentation, try an a/b test, and come back with some data, it'd make it much easier to go for this. I do recall that there are definitely cards for which we get occasional bad 15 vs 16 decisions from vseg. Just taking the first thing that comes across the board will increase false positives. The user experience for false positives is much worse than for slower scans, so we generally skew towards slow. |
|
Okay, I will do some more testing and documentation. Also, I'm thinking to change |
|
Sadly the test data in question is credit card images, so they can't really be released. :( |
I think we can get rid of the minimal 3 frames requirement by simplifying the 15/16 number score aggregation:
aggregated.sum()for decision instead of waiting at least three framesI tested it with all my cards. It did not increase false positives, but it did decreases scan time quite noticeable. The code is simpler and I think more effective.
Please give it a try.