Mark Vytlacil wrote:
> I have been experimenting with the microsoft reader for a while now and have
> been getting a lot of false rejections. Cleaning the reader and more care in
> pressing help, but not that much. The minutiae are not very consistant in
> position or number. I was puzzled that Daniel reported such good results.
If you enable libfprint debug log messages at configure time, it will
print out bozorth3 match scores on the console. The default threshold is
40 (so score >=40 is match). I'd be interested to hear what kinds of
scores you get for false rejectances, and also in comparison to scores
you get when purposely scanning 2 different fingers.
I wouldn't rely on the visual results too much. With a very dirty
sensor, I get many false minutiae being detected around the edge of my
finger, which change in position on each scan. Yet for some reason, the
matching accuracy is still very high.
> Comparing my image to the sample image on the wiki shows that mine is
> much "muddier". I have gaps in the ridges, smeary areas, and various unclear
> spots. Many of these make for minutiae that are really artifacts rather than
> true ridge patterns. I considered that my reader was defective and captured a
> blurry image.
Are these "muddy" features persistent? For example, on my fingers, I
have a couple of "skin creases" in various places. However these creases
seem to be persistent. Even though fprint detects various minutiae at
these points where there truthfully aren't any, the fact that these
features are persistent means that matching is very accurate regardless.
> Then I got my son (age 22) to try it. His fingerprint is as clear as the
> sample on the wiki! I could clearly see all of the true minutiae on his
> print. I hate to think that I am getting old and my fingerprint is getting
> soft, but I guess so.
Interesting. I'm 21. While a population size of 3 isn't enough to make
reliable conclusions here, this is an interesting observation.
> The windows software works well for me, but it captures the same finger 4
> times to enroll a print. We could do the same and just enroll the subset of
> minutiae that consistantly match. For verification, we would consider the
> proportion of enrolled minutiae that matched. It is easy to make suggestions
> like this, but not so easy to do the implementation work. Looking at the
> code, I can see that you would have to bring some match data out of the
> bozorth library routines or add some functionality to them to generate this
> subset and use it. As it is now, the main match function just returns a
> score.
There are more simplistic things we can do first. Firstly on the driver
level:
uru4000 samples the finger immediately as it is detected. In real life,
pressing your finger on a sensor is not an atomic process, so if we were
to take several samples of the finger and use one of the later samples
instead, we'd have a more complete (and maybe a 'more settled') print.
Secondly on the library level:
- take say 3 enrollment prints
- use NIST's fingerprint image quality algorithm to pick the best
one(s)
- if NFIQ provided more than 1 best prints, choose the one with the
most minutiae, or the highest 'confidence per minutiae' average, or
something like that.
It's hard to say how much this will improve things, but it is quite
realistic to be able to implement these without too much trouble. This
is planned but I've got a lot of other stuff to do before I can focus on
this.
Thanks,
Daniel
_______________________________________________
fprint mailing list
[email protected]
http://lists.reactivated.net/mailman/listinfo/fprint
