Daniel Drake wrote :
> 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.
I've tried 30 but it was not enough. Anyway, this may change in the future.
>> 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.
Ok, I understand that.
> 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 hadn't seen. sorry! I should really explore the entire site!
>> 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.
Yes, I'll document this (as I've done for what I know about the rest of
the protocol)
> Some comments on the patch below:
> (please also use the -p flag to diff in future)
>
Ok
>> 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?
Yes, this is for that reason. I think I'll move it to the loop sooner or
later. For now, I leave it here as I'm not sure about the number of
strips we should capture between every gain adjustement. I'll fix it
with gain stuff. I think.
>> 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?
12 because this is the minimum to avoid the segfault. This is a dirty
fix! The segfault happens on line 132 of libfprint/nbis/mindtct/maps.c.
>> 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.
Don't know what happened. I'll check it the next time!
> Thanks!
> Daniel
>
_______________________________________________
fprint mailing list
[email protected]
http://lists.reactivated.net/mailman/listinfo/fprint
