[fprint] elan patch + poc 0x903 and 0x0C03
Igor Filatov
ia.filatov at gmail.com
Tue Jan 30 09:06:00 UTC 2018
>From what I understand, you need to compare big images to big images for
the minutiae algo to work good. If the verification images are small, they
simply won't have enough minutiae.
I think Hans had a good point when he mentioned that the existing stitching
code could be used. libfprint has the advantage that it doesn't guarantee
interoperability between different scanners - that you can enroll with one
scanner and verify with another. It doesn't need to have a very generic
algorithm like the ones that academic papers focus on. The same device (and
we're not even talking about the same model - it's the same physical
device) produces very similar images all the time. There is already a
method to score an overlap of 2 images that's used for stitching. If the
rotation is taken care of, the rest should be possible. I was at some point
thinking whether minutiae can be used as sort of "anchor points" to find
approximate coordinates and angle (e.g. we have 3 similar minutiae which is
not enough to compare but we can match their coordinates on 2 scans and use
them to check for overlap).
This would still benefit greatly from an improved enrollment procedure,
though. I imagine the one where you tap the sensor instead of swiping, as
swiping stretches the skin and distorts the image. Such enrollment would
also need to compare frames along x, y and account for rotation...
On Tue, Jan 30, 2018 at 2:40 AM Vasily Khoruzhick <anarsoul at gmail.com>
wrote:
> I suggest improving enrollment procedure. It should stitch big image
> from several small images and use it later for comparison (using
> whatever algorithm - minutiae algo also may work).
>
> On Mon, Jan 29, 2018 at 7:38 AM, Hans de Goede <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>> 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>]
> >> Sent: Thursday, 18 January 2018 16:14
> >> To: Sebastien Bechet <sebastien.bechet at osinix.com
> >> <mailto:sebastien.bechet at osinix.com>>; Igor Filatov <
> ia.filatov at gmail.com
> >> <mailto:ia.filatov at gmail.com>>
> >> Cc: TeEmZe <timo at teemze.de <mailto:timo at teemze.de>>;
> >> konachan.700 at gmail.com <mailto:konachan.700 at gmail.com>;
> >> fprint at lists.freedesktop.org <mailto: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>>
> >>
> >> >> 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 at lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/fprint
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/fprint/attachments/20180130/f6982cdf/attachment-0001.html>
More information about the fprint
mailing list