[fprint] elan patch + poc 0x903 and 0x0C03
TeEmZe
timo at teemze.de
Fri Feb 9 18:23:21 UTC 2018
Hi,
I might actually have another solution.
The fingerprint images, that are created by the swiping, are assembled out of multiple images, the reader got, right?
I now realized that each of those images seems to have about one or two rows of pixels at the top and at the bottom, which are simply black.
Those rows alter the image, so that similar fingers aren’t matching, as the rows are at different positions in the image if the finger was moved with a different speed – which is always the case.
So I think we should try changing the way we generate the image with the swipe movement by cropping each image, of which the final image is assembled, by two pixels at the top and the bottom.
I don’t know whether this solves all problems, but I can at imagine that it’d at least improve it.
I am however still working on an alternative algorithm, which uses cross correlation of field orientation, but I can imagine that this won’t be necessary anymore.
I don’t know the way you’re currently assembling the joined fingerprint image, so maybe someone who does could give this a try?
I’ll be happy to test it afterwards.
Kind regards
Timo
From: fprint [mailto:fprint-bounces at lists.freedesktop.org] On Behalf Of wp12880529-timo wp12880529-timo
Sent: Friday, 9 February 2018 03:30
To: Hans de Goede <hdegoede at redhat.com>; Sebastien Bechet <sebastien.bechet at osinix.com>; Igor Filatov <ia.filatov at gmail.com>
Cc: fprint at lists.freedesktop.org
Subject: Re: [fprint] elan patch + poc 0x903 and 0x0C03
Hi Igor,
I tried the new version, which doesn't seem to work significantly better - it detects about 50% of the tries. I think the best solution will be another algorithm, which I'm currently working on.
Kind regards
Timo
Igor Filatov <ia.filatov at gmail.com <mailto:ia.filatov at gmail.com> > hat am 4. Februar 2018 um 16:07 geschrieben:
Hi everybody,
Base on the new info I got I've updated the driver in a few places:
1. Frames are cropped to 30px by height. I've received some examples of images from 96px readers and it seems that the assembling procedure just doesn't work for frames of greater height. I _think_ this is largely because the skin stretches and deforms in a non-uniform way when you swipe. E.g. the same part of the print is slightly different when it's near the bottom of the frame than when it's near the top. Plus, there often seem to be sensor artifacts near the edges, so.
2. Sensor reset is out. Devices do it when they power up. I'm not entirely sure that it's absolutely not needed, though. I'm thinking about suspend & resume, for one. But anyway, I've used my reader for long without any reset and I'm suspending all the time and I haven't had any problems because of it.
3. Some changes around calibration. You can get a calibration status of 0x01 (ongoing) and 0x03 (completed) from the device. But I've noticed that very often the first response I get is 0x03, which later (~100 ms) changes to 0x01, then back to 0x03. So now to make sure it actually completes, the driver first wants to see 0x01 at least once and then it waits for 0x03.
4. KT has recommended a different frame extraction algo. First we subtract the background which we got during calibration. This helps quite significantly. Then we split values into 3 groups and apply a different transformation to each group (see comments for detail). And this seems to give slightly worse results on my reader than simple linear scaling like there was before. So I've left both methods and it's possible to configure the method for each device. YMMV.
Please see if it now works better/same/worse for you. I think verification is now slightly better on my device but I need to use it for a couple of days to know.
On Tue, Jan 30, 2018 at 8:31 PM Igor Filatov < ia.filatov at gmail.com <mailto:ia.filatov at gmail.com> > wrote:
Hi Timo,
Sure, give it a shot! And as I said earlier, remember that you don't need a generic algo for any 2 fingerprints. The prints always come from the same device.
On Tue, Jan 30, 2018 at 8:16 PM TeEmZe < timo at teemze.de <mailto:timo at teemze.de> > wrote:
Hi,
I'll give it a shot in C, but will switch to Java before desperation.
I'll try to implement the Fingerprint Identification Using Cross Correlation of Field Orientation – there are a few papers online.
I’ll write a library which receives two images (the enrolled and the one to verify) and returns a number between 0 and 100 (the percentage of the match), while above 70 is considered a match.
This might take a little bit of time, but I think I should be able to tackle this.
Later I’ll need a few people to test it, obviously, and maybe a bit of help including it into the main project.
Kind regards,
Timo
-----Original Message-----
From: Hans de Goede [mailto:hdegoede at redhat.com <mailto:hdegoede at redhat.com> ]
Sent: Tuesday, 30 January 2018 10:39
To: TeEmZe <timo at teemze.de <mailto:timo at teemze.de> >; 'Igor Filatov' <ia.filatov at gmail.com <mailto:ia.filatov at gmail.com> >
Cc: konachan.700 at gmail.com <mailto:konachan.700 at gmail.com> ; 'Sebastien Bechet' <sebastien.bechet at osinix.com <mailto:sebastien.bechet at osinix.com> >; fprint at lists.freedesktop.org <mailto:fprint at lists.freedesktop.org>
Subject: Re: [fprint] elan patch + poc 0x903 and 0x0C03
Hi,
On 29-01-18 21:52, TeEmZe wrote:
> Hi,
>
> Let’s assume I’d like to take a look at it (I am indeed quite interested).
> Would I have to write the algorithm in C (I am, as mentioned, not quite good in C and I don’t think that C is the perfect language for algorithmic)?
> And would I have to rewrite the existing code or could I just replace a library?
Ideally it would be in C and it would be stand-alone so that it can be added to libfprint as a second algorithm to use on low-res fp readers. But we don't need to get there in one step. If you are interested in working on this, and you can write something in say python which does a good job of matching and add some docs / comments clearly explaining all the steps of the algorithm you've come up with, then someone else can use that to implement the same algorithm in say C.
We should probably also consider adding an external (C-lib) dependency for this to libfprint, rather then implementing everything needed from scratch, but that is all something to worry about later really. First we need a clearly described / documented algorithm which does a good job of matching (with example code please). Once we have that we can worry about integrating it into libfprint (IMHO).
Regards,
Hans
>
> Kind regards,
>
> Timo
>
> *From:*Igor Filatov [ <mailto:ia.filatov at gmail.com> mailto:ia.filatov at gmail.com]
> *Sent:* Monday, 29 January 2018 20:26
> *To:* Hans de Goede < <mailto:hdegoede at redhat.com> hdegoede at redhat.com>
> *Cc:* <mailto:konachan.700 at gmail.com> konachan.700 at gmail.com; Sebastien Bechet
> < <mailto:sebastien.bechet at osinix.com> sebastien.bechet at osinix.com>; TeEmZe < <mailto:timo at teemze.de> timo at teemze.de>;
> <mailto:fprint at lists.freedesktop.org> fprint at lists.freedesktop.org
> *Subject:* Re: [fprint] elan patch + poc 0x903 and 0x0C03
>
> Well yes, treating these readers as swipe devices does seem awkward. But that was the only way of making it work short of implementing a new recognition algo, which seemed like too much at the time. In fact, the current one is also a 3rd party lib. The authors of libfprint have considered an alternative approach for smaller sensors but there weren't any usable libs ( <https://www.freedesktop.org/wiki/Software/fprint/libfprint/Imaging_performance/#possiblesolutions> https://www.freedesktop.org/wiki/Software/fprint/libfprint/Imaging_performance/#possiblesolutions).
>
> As for the stitching code, it assumes that frame height is small. A couple of px originally but works for a couple dozen px as well (but not *that* well). 96px is probably too much but you can try tweaking the frame margin. The height needs to be narrow enough for the stitching to work and wide enough to make sure there are no gaps, given the device's "frame rate". But even if that works, we're left with 96px of width which means you really need to make sure you enroll the same area of the finger which you verify...
>
> With a bit of getting used to, my 144x64 scanner works more or less ok for me. Could be better, but still. This is why I decided to keep working on this driver. But then, there's a driver for a 64x64 device ( <https://www.freedesktop.org/wiki/Software/fprint/libfprint/aes4000/> https://www.freedesktop.org/wiki/Software/fprint/libfprint/aes4000/) so why not?
>
> On Mon, Jan 29, 2018 at 5:38 PM Hans de Goede < <mailto:hdegoede at redhat.com%20%3cmailto:hdegoede at redhat.com> hdegoede at redhat.com <mailto:hdegoede at redhat.com>> wrote:
>
> Hi,
>
> On 23-01-18 22:58, Igor Filatov wrote:
> > I've updated the driver to support the devices known so far. Please see if it works for you. Please send me your logs if not. I've enabled all commands for all devices (except 0x4031 which I've enabled only on my 0x0907 -- no idea what it does, but the response is 0x01).
> >
> > There's a bit mask in each command which you can use to enable/disable commands for a particular device.
> >
> > As for calibration, the driver doesn't expect 0x03 because not all devices seem to return 0x03 or 0x01. Instead it will retry *only* if the response is 0x03 and until it's different.
> >
> > I've enabled reset & fuse load for my device. Although I haven't seen it done by the original driver, it doesn't seem to hurt. So please see if it cause problems for you. Let's disable it only for devices where it does.
> >
> > <https://github.com/iafilatov/libfprint> https://github.com/iafilatov/libfprint
>
> This works for me with both the 0c16 and 0c26 readers I've access too.
>
> But we really need someone (any takers?) to implement a different type
> of recognition algorithm for these, not using minutia and then not treat
> them as swipe readers. Basically what we need is some form of image correlation
> algorithm. Perhaps the stitching code (which does not seem to do a very good
> job IMHO) can be used, to see if 2 images can be made to mostly overlap
> with an acceptable shift.
>
> Note that when I last looking into this I did a quick duckduckgo search
> on low resolution fingerprint recognition and there are a number of
> academic papers on how this can be done using image correlation, so
> ideally some-one would go and implement something like this.
>
> Regards,
>
> Hans
>
> > On Fri, Jan 19, 2018 at 3:33 PM TeEmZe < <mailto:timo at teemze.de%20%3cmailto:timo at teemze.de> timo at teemze.de <mailto:timo at teemze.de> < <mailto:timo at teemze.de%20%3cmailto:timo at teemze.de> mailto:timo at teemze.de <mailto:timo at teemze.de>>> wrote:
> >
> > Hi,
> >
> > Sadly I won't be able to get the data until next week, as I currently don't have access to the Laptop. I'll notify you as soon as I manage to get the data.
> >
> > Regards,
> >
> > Timo
> >
> > -----Original Message-----
> > From: Hans de Goede [ <mailto:hdegoede at redhat.com%20%3cmailto:hdegoede at redhat.com%3e%20%3cmailto:hdegoede at redhat.com%20%3cmailto:hdegoede at redhat.com%3e%3e> mailto:hdegoede at redhat.com <mailto:hdegoede at redhat.com> <mailto:hdegoede at redhat.com <mailto:hdegoede at redhat.com>>]
> > Sent: Thursday, 18 January 2018 16:14
> > To: Sebastien Bechet < <mailto:sebastien.bechet at osinix.com%20%3cmailto:sebastien.bechet at osinix.com> sebastien.bechet at osinix.com <mailto:sebastien.bechet at osinix.com> < <mailto:sebastien.bechet at osinix.com%20%3cmailto:sebastien.bechet at osinix.com> mailto:sebastien.bechet at osinix.com <mailto:sebastien.bechet at osinix.com>>>; Igor Filatov < <mailto:ia.filatov at gmail.com%20%3cmailto:ia.filatov at gmail.com> ia.filatov at gmail.com <mailto:ia.filatov at gmail.com> < <mailto:ia.filatov at gmail.com%20%3cmailto:ia.filatov at gmail.com> mailto:ia.filatov at gmail.com <mailto:ia.filatov at gmail.com>>>
> > Cc: TeEmZe < <mailto:timo at teemze.de%20%3cmailto:timo at teemze.de> timo at teemze.de <mailto:timo at teemze.de> < <mailto:timo at teemze.de%20%3cmailto:timo at teemze.de> mailto:timo at teemze.de <mailto:timo at teemze.de>>>; <mailto:konachan.700 at gmail.com> konachan.700 at gmail.com < <mailto:konachan.700 at gmail.com> mailto:konachan.700 at gmail.com> < <mailto:konachan.700 at gmail.com%20%3cmailto:konachan.700 at gmail.com> mailto:konachan.700 at gmail.com <mailto:konachan.700 at gmail.com>>; <mailto:fprint at lists.freedesktop.org> fprint at lists.freedesktop.org < <mailto:fprint at lists.freedesktop.org> mailto:fprint at lists.freedesktop.org> < <mailto:fprint at lists.freedesktop.org%20%3cmailto:fprint at lists.freedesktop.org> mailto:fprint at lists.freedesktop.org <mailto:fprint at lists.freedesktop.org>>
> > Subject: Re: [fprint] elan patch + poc 0x903 and 0x0C03
> >
> > Hi,
> >
> > On 18-01-18 16:03, Sebastien Bechet wrote:
> > > Thank you Igor. Hans, you can try again with last version.
> >
> > Not tested, but looking at the code, it will loop in the calibration, my 2 devices both need a:
> >
> > if (result == 0x03) break;
> >
> > Directly after the:
> >
> > printf("Calibration Status: 0x%x\n", result);
> >
> > Line, currently the code only checks for result == 0x03 for the result of the get_cmd_status command, while it should check (for my devices) the result of the get_cmd_calibration command.
> >
> > Regards,
> >
> > Hans
> >
> >
> >
> > >
> > > I also tried to remove reset+fuseload then calibration not working
> > > anymore for 0x0903. It seems it is a part for calibration (same pdf
> > > file for reset _and_ calibration or .... reset _then_ calibration?).
> > >
> > > <https://github.com/sbechet/elanfp> https://github.com/sbechet/elanfp
> > >
> > > Konata and timo, can you give us width, height, firmware version and
> > > calibration status using elanfp.c please?
> >
> >
> > >
> > >
> > >
> > > Le jeudi 18 janvier 2018 à 14:02 +0000, Igor Filatov a écrit :
> > >>> square and seems to contain the image 3 times
> > >> Could be because convert is hardcoded at 96x96.
> > >>
> > >> On Thu, 18 Jan 2018, 12:04 Hans de Goede, < <mailto:hdegoede at redhat.com%20%3cmailto:hdegoede at redhat.com> hdegoede at redhat.com <mailto:hdegoede at redhat.com> < <mailto:hdegoede at redhat.com%20%3cmailto:hdegoede at redhat.com> mailto:hdegoede at redhat.com <mailto:hdegoede at redhat.com>>>
> > >> wrote:
> > >>> Hi,
> > >>>
> > >>> On 18-01-18 10:48, Sébastien Béchet wrote:
> > >>>> On 17-01-18 19:21, Igor Filatov wrote:
> > >>>>> We didn't have the spec before so I had no idea how different
> > >>> devices worked. Especially given that some commands which worked
> > >>> fine for me produced errors one other devices. Now that we have the
> > >>> docs I'll work on adapting the driver. Naturally, any info you have
> > >>> is welcome and so is any help with testing.
> > >>>>
> > >>>> I have done the [synthesis]( <https://github.com/sbechet/elanfp/blo> https://github.com/sbechet/elanfp/blo
> > >>> b/master/README.md) about all informations we have a prepare
> > >>> questions for KT.
> > >>>
> > >>> My 0x0c16 id reader has firmware version 1.56, resolution 96x96
> > >>>
> > >>> I also have bought a stand-alone USB reader for when I would find
> > >>> time to work on this, this has an usb-id of: 0x0c26.
> > >>>
> > >>> After aking these changes:
> > >>>
> > >>> --- elanfp.c~ 2018-01-18 10:58:59.919912347 +0100
> > >>> +++ elanfp.c 2018-01-18 11:01:50.346280668 +0100
> > >>> @@ -71,7 +71,8 @@
> > >>> (desc.idVendor == 0x04f3) && (desc.idProduct ==
> > >>> 0x0903) ||
> > >>> (desc.idVendor == 0x04f3) && (desc.idProduct ==
> > >>> 0x0907) ||
> > >>> (desc.idVendor == 0x04f3) && (desc.idProduct ==
> > >>> 0x0c03) ||
> > >>> - (desc.idVendor == 0x04f3) && (desc.idProduct ==
> > >>> 0x0c16) ) {
> > >>> + (desc.idVendor == 0x04f3) && (desc.idProduct ==
> > >>> 0x0c16) ||
> > >>> + (desc.idVendor == 0x04f3) && (desc.idProduct ==
> > >>> 0x0c26) ) {
> > >>> r0 = 0;
> > >>> printf("Device with vid %x pid %x found.\n",
> > >>> desc.idVendor, desc.idProduct);
> > >>> break;
> > >>> @@ -156,7 +157,7 @@
> > >>> printf("CMD Get Image Size sent\n");
> > >>> }
> > >>> r0 = libusb_bulk_transfer(handle, BULK_EP3_IN, img_buf, 4,
> > >>> &transferred, 0);
> > >>> - printf("Width x height = %dx%d\n", img_buf[0], img_buf[2]);
> > >>> + printf("Width x height = %dx%d\n", (unsigned char)img_buf[0],
> > >>> (unsigned char)img_buf[2]);
> > >>>
> > >>> /* calibration */
> > >>>
> > >>> @@ -180,6 +181,7 @@
> > >>> }
> > >>> r0 = libusb_bulk_transfer(handle, BULK_EP3_IN, &result,
> > >>> 1, &transferred, 0);
> > >>> printf("Calibration Status: 0x%x\n", result);
> > >>> + if (result == 0x03) break;
> > >>>
> > >>> r0 = libusb_bulk_transfer(handle, BULK_EP1_OUT,
> > >>> get_cmd_status, 2, &transferred, 0);
> > >>> if((r0 == 0) && (transferred == 2)) {
> > >>>
> > >>> This one works with the POC too, although for some reason the
> > >>> generated out.png is square and seems to contain the image 3 times?
> > >>>
> > >>> This one has firmware version 1.64, resolution 64x144 and as shown
> > >>> in the necessary changes this one does report a calibration status
> > >>> of 0x03 when it is done with the calibration, I think we should add
> > >>> an extra column for this to the hardware report table.
> > >>>
> > >>> Regards,
> > >>>
> > >>> Hans
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/fprint/attachments/20180209/3d4c6379/attachment-0001.html>
More information about the fprint
mailing list