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 <t...@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:hdego...@redhat.com] > Sent: Tuesday, 30 January 2018 10:39 > To: TeEmZe <t...@teemze.de>; 'Igor Filatov' <ia.fila...@gmail.com> > Cc: konachan....@gmail.com; 'Sebastien Bechet' < > sebastien.bec...@osinix.com>; fprint@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.fila...@gmail.com <ia.fila...@gmail.com>] > > > *Sent:* Monday, 29 January 2018 20:26 > > > *To:* Hans de Goede <hdego...@redhat.com> > > > *Cc:* konachan....@gmail.com; Sebastien Bechet > > > <sebastien.bec...@osinix.com>; TeEmZe <t...@teemze.de>; > > > fprint@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 > ). > > > > > > 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/) so > why not? > > > > > > On Mon, Jan 29, 2018 at 5:38 PM Hans de Goede <hdego...@redhat.com > <mailto:hdego...@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 > > > > > > 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 <t...@teemze.de > <mailto:t...@teemze.de> <mailto:t...@teemze.de <mailto:t...@teemze.de > <t...@teemze.de%20%3cmailto:t...@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:hdego...@redhat.com > <mailto:hdego...@redhat.com> <mailto:hdego...@redhat.com > <mailto:hdego...@redhat.com>> > <hdego...@redhat.com%20%3cmailto:hdego...@redhat.com%3e%20%3cmailto:hdego...@redhat.com%20%3cmailto:hdego...@redhat.com%3e%3e> > ] > > > > Sent: Thursday, 18 January 2018 16:14 > > > > To: Sebastien Bechet <sebastien.bec...@osinix.com > <mailto:sebastien.bec...@osinix.com> <mailto:sebastien.bec...@osinix.com > <mailto:sebastien.bec...@osinix.com > <sebastien.bec...@osinix.com%20%3cmailto:sebastien.bec...@osinix.com>>>>; > Igor Filatov <ia.fila...@gmail.com <mailto:ia.fila...@gmail.com> > <mailto:ia.fila...@gmail.com > <mailto:ia.fila...@gmail.com > <ia.fila...@gmail.com%20%3cmailto:ia.fila...@gmail.com>>>> > > > > Cc: TeEmZe <t...@teemze.de <mailto:t...@teemze.de> > > <mailto:t...@teemze.de > <mailto:t...@teemze.de <t...@teemze.de%20%3cmailto:t...@teemze.de>>>>; > konachan....@gmail.com <mailto:konachan....@gmail.com > <konachan....@gmail.com>> <mailto:konachan....@gmail.com > <mailto:konachan....@gmail.com > <konachan....@gmail.com%20%3cmailto:konachan....@gmail.com>>>; > fprint@lists.freedesktop.org <mailto:fprint@lists.freedesktop.org > <fprint@lists.freedesktop.org>> <mailto:fprint@lists.freedesktop.org > <mailto:fprint@lists.freedesktop.org > <fprint@lists.freedesktop.org%20%3cmailto:fprint@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 > > > > > > > > > > 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, > > <hdego...@redhat.com > <mailto:hdego...@redhat.com> <mailto:hdego...@redhat.com > <mailto:hdego...@redhat.com > <hdego...@redhat.com%20%3cmailto:hdego...@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 > > > > >>> 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 > > > > > > > >
_______________________________________________ fprint mailing list fprint@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/fprint
