[fprint] elan patch + poc 0x903 and 0x0C03
Igor Filatov
ia.filatov at gmail.com
Tue Jan 30 18:31:12 UTC 2018
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> 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]
> Sent: Tuesday, 30 January 2018 10:39
> To: TeEmZe <timo at teemze.de>; 'Igor Filatov' <ia.filatov at gmail.com>
> Cc: konachan.700 at gmail.com; 'Sebastien Bechet' <
> sebastien.bechet at osinix.com>; 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 <ia.filatov at gmail.com>]
>
> > *Sent:* Monday, 29 January 2018 20:26
>
> > *To:* Hans de Goede <hdegoede at redhat.com>
>
> > *Cc:* konachan.700 at gmail.com; Sebastien Bechet
>
> > <sebastien.bechet at osinix.com>; TeEmZe <timo at teemze.de>;
>
> > 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
> ).
>
> >
>
> > 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 <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
>
> >
>
> > 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 <timo at teemze.de
> <mailto:timo at teemze.de> <mailto:timo at teemze.de <mailto:timo at teemze.de
> <timo at teemze.de%20%3cmailto: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
> <mailto:hdegoede at redhat.com> <mailto:hdegoede at redhat.com
> <mailto:hdegoede at redhat.com>>
> <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>
> ]
>
> > > Sent: Thursday, 18 January 2018 16:14
>
> > > To: Sebastien Bechet <sebastien.bechet at osinix.com
> <mailto:sebastien.bechet at osinix.com> <mailto:sebastien.bechet at osinix.com
> <mailto:sebastien.bechet at osinix.com
> <sebastien.bechet at osinix.com%20%3cmailto:sebastien.bechet at osinix.com>>>>;
> Igor Filatov <ia.filatov at gmail.com <mailto:ia.filatov at gmail.com> <mailto:ia.filatov at gmail.com
> <mailto:ia.filatov at gmail.com
> <ia.filatov at gmail.com%20%3cmailto:ia.filatov at gmail.com>>>>
>
> > > Cc: TeEmZe <timo at teemze.de <mailto:timo at teemze.de> <mailto:timo at teemze.de
> <mailto:timo at teemze.de <timo at teemze.de%20%3cmailto:timo at teemze.de>>>>;
> konachan.700 at gmail.com <mailto:konachan.700 at gmail.com
> <konachan.700 at gmail.com>> <mailto:konachan.700 at gmail.com
> <mailto:konachan.700 at gmail.com
> <konachan.700 at gmail.com%20%3cmailto:konachan.700 at gmail.com>>>;
> fprint at lists.freedesktop.org <mailto:fprint at lists.freedesktop.org
> <fprint at lists.freedesktop.org>> <mailto:fprint at lists.freedesktop.org
> <mailto:fprint at lists.freedesktop.org
> <fprint at lists.freedesktop.org%20%3cmailto: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
>
> > > >
>
> > > > 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, <hdegoede at redhat.com
> <mailto:hdegoede at redhat.com> <mailto:hdegoede at redhat.com
> <mailto:hdegoede at redhat.com
> <hdegoede at redhat.com%20%3cmailto: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
>
> > > >>> 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/20180130/b974ecc0/attachment-0001.html>
More information about the fprint
mailing list