On Sat, 2008-04-12 at 16:35 +0100, Daniel Drake wrote: Thank you Daniel for your reply.
Here is more information. I was talking about AES3500, it has 128x128 (small area) but has a better image, clear and crisp. > 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. For the thumb finger i get from 35 to 50 minutiae (valid) since the fingerprint covers all sensor area. For the index finger (attached), i get from 18 to 35 minutiae and 4 to 8 invalid. But at some point (after 30 or more tries) i got a match with 32 minutiae. > > 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. > Ok, i will try to compile it in debug mode, and tell you the results if i can. > 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. > Nice to hear it, but the same fingerprint and sensor i get good results on windows, and i don't have to pressure the finger as i do it on linux. nothing to do with OS, just comparing if the device is working properly. > 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. > As you can see on attached image, it is not a looser skin. > 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). > Perhaps the binarized image gets too much invalid minutia? Let's see the result then. > 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 have done many times this, without success. > > 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. > AES3500 are small but clear and crisp image. > The images from the Microsoft/DigitalPersona sensors are very very good. > Same for AES2501. > > Daniel > I will send you the fingerprint images, so you could get a clue, or give me directions on how to preceed. Best regards, xfinger =====
<<attachment: fingerprint_not_matched.png>>
_______________________________________________ fprint mailing list [email protected] http://lists.reactivated.net/mailman/listinfo/fprint
