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 <[email protected]> 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 < [email protected] > mailto:[email protected] > 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 < [email protected] > > mailto:[email protected] > 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:[email protected] > > > mailto:[email protected] ] > > > Sent: Tuesday, 30 January 2018 10:39 > > > To: TeEmZe <[email protected] mailto:[email protected] >; 'Igor > > > Filatov' <[email protected] mailto:[email protected] > > > > Cc: [email protected] mailto:[email protected] ; > > > 'Sebastien Bechet' <[email protected] > > > mailto:[email protected] >; [email protected] > > > mailto:[email protected] > > > 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:[email protected] > > > mailto:[email protected] ] > > > > > > > *Sent:* Monday, 29 January 2018 20:26 > > > > > > > *To:* Hans de Goede <[email protected] > > > mailto:[email protected] > > > > > > > > *Cc:* [email protected] mailto:[email protected] > > > ; Sebastien Bechet > > > > > > > <[email protected] > > > mailto:[email protected] >; TeEmZe <[email protected] > > > mailto:[email protected] >; > > > > > > > [email protected] > > > mailto:[email protected] > > > > > > > *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 > > > <[email protected] <mailto:[email protected] > > > mailto:[email protected]%20%3cmailto:[email protected] >> 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 > > > <[email protected] <mailto:[email protected] > > > mailto:[email protected]%20%3cmailto:[email protected] > <mailto:[email protected] > > > <mailto:[email protected] mailto:[email protected]%20%3cmailto:[email protected] > > > >>> 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:[email protected] > > > <mailto:[email protected]> <mailto:[email protected] > > > <mailto:[email protected]>> > > > mailto:[email protected]%20%3cmailto:[email protected]%3e%20%3cmailto:[email protected]%20%3cmailto:[email protected]%3e%3e > > > ] > > > > > > > > Sent: Thursday, 18 January 2018 16:14 > > > > > > > > To: Sebastien Bechet > > > <[email protected] <mailto:[email protected] > > > mailto:[email protected]%20%3cmailto:[email protected] > > > > <mailto:[email protected] > > > <mailto:[email protected] > > > mailto:[email protected]%20%3cmailto:[email protected] > > > >>>; Igor Filatov <[email protected] <mailto:[email protected] > > > mailto:[email protected]%20%3cmailto:[email protected] > > > > <mailto:[email protected] <mailto:[email protected] > > > mailto:[email protected]%20%3cmailto:[email protected] >>> > > > > > > > > Cc: TeEmZe <[email protected] > > > <mailto:[email protected] mailto:[email protected]%20%3cmailto:[email protected] > > > > <mailto:[email protected] <mailto:[email protected] > > > mailto:[email protected]%20%3cmailto:[email protected] >>>; > > > [email protected] mailto:[email protected] > > > <mailto:[email protected] mailto:[email protected] > > > > <mailto:[email protected] <mailto:[email protected] > > > mailto:[email protected]%20%3cmailto:[email protected] >>; > > > [email protected] mailto:[email protected] > > > <mailto:[email protected] mailto:[email protected] > > > > <mailto:[email protected] > > > <mailto:[email protected] > > > mailto:[email protected]%20%3cmailto:[email protected] > > > >> > > > > > > > > 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, > > > <[email protected] <mailto:[email protected] > > > mailto:[email protected]%20%3cmailto:[email protected] > > > > <mailto:[email protected] <mailto:[email protected] > > > mailto:[email protected]%20%3cmailto:[email protected] >>> > > > > > > > > >> 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 > > > > > > > > > > > > > > > > > > > > > > > > > >
_______________________________________________ fprint mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/fprint
