Alexander wrote: > While working with libfprint (and fprint-demo), libfprint has a hard > time to match the same fingerprint. > I have to scan the same fingerprint several times (at least 10 times) to > have a match and i have to be precise in positioning the fingerprint. > I have 3 fingerprint (they are the same as you can see), the enrolled > and the matched fingerprint and the non matched. > We can see clearly (i hope it is attached correctly), they are the same, > and have slight offsets and libfprint cannot match. > I have tested it on Fedora core 7 (x86_64) and Ubuntu with the same > results, also the device works just fine on Vista. > I have noticed that the thumb fingerprint is easier to get matched, and > cover almost all sensor area.
You should look at the binarized prints with minutiae plotted. See how much damage the binarization is doing to the print. See if it detects a lot of invalid minutiae, or misses minutiae points. See how many minutiae are being detected. You can also compile libfprint with debug info in which case it will tell you the bz3 match score for each verification. The matching threshold is 40 for the uru4000 driver. I get excellent results with uru4000. With a good enroll scan, a good verification scan will get me a match score of well over 100, sometimes over 200. It is suspected that our matching code does not work so well with looser skin (i.e. age related). Perhaps you're running into that issue. The matching code is somewhat of an unknown factor in the codebase, it was adopted from elsewhere. I am not sure what the best way is to improve it (and that would be a bit tricky for me to judge given that I get such excellent results from it already). We can also improve the performance by taking a sample of the finger after the first one. This means more of the finger will be on the sensor and potentially a more appropriate amount of pressure applied. This will be much easier to achieve now that we have the asynchronous backend - patches accepted if you want to jump ahead :) > I wonder if someone has have the same problem with the authentec > sensors, since the aes image is far superior? These problems are quite common on the authentec sensors, because the image is far *inferior* there. AES1610 images are so small that our matching code doesn't do well. AES4000 images are small and poor quality. The images from the Microsoft/DigitalPersona sensors are very very good. Same for AES2501. Daniel _______________________________________________ fprint mailing list [email protected] http://lists.reactivated.net/mailman/listinfo/fprint
