wxCover wrote:
> Hi!
> Here comes a patch that should solve a few problems with aes1610. The
> changelog:
> -Fixed seg fault when you don't move your finger on the sensor
> -bz threshold is now 10 (instead of 15). I think it is ok for the
> moment. If we manage to get higher image quality in the future, we'll
> change that.
I'm a little concerned at the increased risk of false acceptance, but
OK, this will do for now :)
> -max_frame is set to 350. 150 was too low => incomplete fingerprints
> -the driver was designed to stop the acquisition as soon as it gets a
> blank frame (=> incomplete fingerprints). Now it waits to have at least
> 50 blank frames before stopping.
50 seems a bit excessive, but I suppose it scans quite quickly.
> Daniel, I'd like to look at the image quality. Can you tell me what you
> think about that? What step do you think is problematic? I only have
> images from my reader so it's not very easy to see what is wrong and
> what is ok.
The image quality looks fine from what I could see before. Minutia
detection also seemed near perfect, i.e. my eyes could not do better.
The problem appears to be in the minutiae set comparison code which is
called bozorth3 (bz3).
The match score that bozorth3 produces is in some way related to the
number of minutiae that it could match up. So the fact that you are
getting only 10-15 minutia per scan makes achieving higher match scores
quite unrealistic.
The next steps are to investigate bozorth3 and see how we can adjust the
scoring system to be more appropriate here. It may turn out that it only
works well with large numbers of minutiae by-design, in which case we
could implement a separate matching algorithm for the smaller sensors.
As for images from other devices, each driver page of the wiki includes
an image (for the devices that I have which present images to the
computer), and there are various AES2501 prints on the fprint_demo wiki
page.
> I've begun working on the gain. I'm trying to understand how it works
> from my logs. I hope I'll be able to make a patch for this soon...
If you write some code as a result, please use inline comments to
document your understanding. It is likely that the solutions for aes2501
and aes4000 will be similar.
Some comments on the patch below:
(please also use the -p flag to diff in future)
> diff -aburN ../lib/libfprint/drivers/aes1610.c ./libfprint/drivers/aes1610.c
> --- ../lib/libfprint/drivers/aes1610.c 2007-11-26 16:43:27.000000000
> +0100
> +++ ./libfprint/drivers/aes1610.c 2007-11-26 16:41:59.000000000 +0100
> @@ -521,9 +504,7 @@
> memcpy(imgptr, buf + 1, 128*4);
> imgptr += 128*4;
>
> - for (nstrips = 0; nstrips < MAX_FRAMES; nstrips++) {
> - int threshold;
> -
> + for (nstrips = 2; nstrips < MAX_FRAMES - 2; nstrips++) {
Why 2? Is this because you captured 2 strips immediately before the
loop? If so, why aren't those initial 2 captures inside the loop?
> r = write_regv(dev, strip_scan_reqs,
> G_N_ELEMENTS(strip_scan_reqs));
> if (r < 0)
> goto err;
> @@ -585,6 +573,12 @@
> fp_dbg("reversed scan direction");
> }
>
> + // img->height must be >= 12 (if not, we get seg fault)
> + // img->height = 8 when we don't move the finger on the sensor
> + // We set it to 12 to avoid a crash.
> + if (img->height < 12)
> + img->height = 12;
> +
Why 12? Where does the segfault happen?
> for (i = 0; i < img->height * FRAME_WIDTH; i++)
> img->data[i] = (cooked[i] << 4) | 0xf;
>
> diff -aburN ../lib/patch_aes1610.patch ./patch_aes1610.patch
> --- ../lib/patch_aes1610.patch 1970-01-01 01:00:00.000000000 +0100
> +++ ./patch_aes1610.patch 2007-11-26 16:46:18.000000000 +0100
> @@ -0,0 +1,105 @@
> +diff -aburN ../lib/libfprint/drivers/aes1610.c ./libfprint/drivers/aes1610.c
> +--- ../lib/libfprint/drivers/aes1610.c 2007-11-26 16:43:27.000000000
> +0100
> ++++ ./libfprint/drivers/aes1610.c 2007-11-26 16:41:59.000000000 +0100
> +@@ -58,7 +58,7 @@
Looks like some junk was included in your patch.
Thanks!
Daniel
_______________________________________________
fprint mailing list
[email protected]
http://lists.reactivated.net/mailman/listinfo/fprint
