I'm pretty sure it would need to be in C. You shouldn't need to REwrite a lot of code. It would depend on the algorithm but I'm guessing libfprint would interface with it pretty much like it does with nbis: get image from driver, submit image to nbis to get minutiae, compare to saved minutiae ( https://github.com/iafilatov/libfprint/blob/elan/libfprint/img.c#L270 and on). So assuming your algo is based on some kind of image similarity, you'd need to, in a similar fashion, know how to build a reference image (that covers a large area of the finger) and how to compare other images with it (assuming you need to move and/or rotate).
On Mon, Jan 29, 2018 at 10:52 PM TeEmZe <t...@teemze.de> 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? > > > > Kind regards, > > > > Timo > > > > *From:* Igor Filatov [mailto: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> 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>> 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>] > > Sent: Thursday, 18 January 2018 16:14 > > To: Sebastien Bechet <sebastien.bec...@osinix.com <mailto: > sebastien.bec...@osinix.com>>; Igor Filatov <ia.fila...@gmail.com <mailto: > ia.fila...@gmail.com>> > > Cc: TeEmZe <t...@teemze.de <mailto:t...@teemze.de>>; > konachan....@gmail.com <mailto:konachan....@gmail.com>; > fprint@lists.freedesktop.org <mailto: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>> > > >> 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
