[fprint] == fprint issue UrU 4000/4000B ==

[Daniel Drake]

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