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]
*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>>> 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>>]
> 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>>>; Igor Filatov <ia.fila...@gmail.com
<mailto:ia.fila...@gmail.com> <mailto:ia.fila...@gmail.com <mailto:ia.fila...@gmail.com>>>
> Cc: TeEmZe <t...@teemze.de <mailto:t...@teemze.de> <mailto:t...@teemze.de <mailto:t...@teemze.de>>>;
konachan....@gmail.com <mailto:konachan....@gmail.com> <mailto:konachan....@gmail.com <mailto:konachan....@gmail.com>>;
fprint@lists.freedesktop.org <mailto:fprint@lists.freedesktop.org> <mailto: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> <mailto: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
