<div dir="ltr">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. <div> </div><div>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).</div><div> </div><div>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...</div><div> </div></div> <div class="gmail_quote"><div dir="ltr">On Tue, Jan 30, 2018 at 2:40 AM Vasily Khoruzhick <<a href="mailto:anarsoul@gmail.com">anarsoul@gmail.com</a>> wrote: </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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 <<a href="mailto:hdegoede@redhat.com" target="_blank">hdegoede@redhat.com</a>> 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. >> >> <a href="https://github.com/iafilatov/libfprint" rel="noreferrer" target="_blank">https://github.com/iafilatov/libfprint</a> > > > 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 <<a href="mailto:timo@teemze.de" target="_blank">timo@teemze.de</a> >> <mailto:<a href="mailto:timo@teemze.de" target="_blank">timo@teemze.de</a>>> 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:<a href="mailto:hdegoede@redhat.com" target="_blank">hdegoede@redhat.com</a> >> <mailto:<a href="mailto:hdegoede@redhat.com" target="_blank">hdegoede@redhat.com</a>>] >> Sent: Thursday, 18 January 2018 16:14 >> To: Sebastien Bechet <<a href="mailto:sebastien.bechet@osinix.com" target="_blank">sebastien.bechet@osinix.com</a> >> <mailto:<a href="mailto:sebastien.bechet@osinix.com" target="_blank">sebastien.bechet@osinix.com</a>>>; Igor Filatov <<a href="mailto:ia.filatov@gmail.com" target="_blank">ia.filatov@gmail.com</a> >> <mailto:<a href="mailto:ia.filatov@gmail.com" target="_blank">ia.filatov@gmail.com</a>>> >> Cc: TeEmZe <<a href="mailto:timo@teemze.de" target="_blank">timo@teemze.de</a> <mailto:<a href="mailto:timo@teemze.de" target="_blank">timo@teemze.de</a>>>; >> <a href="mailto:konachan.700@gmail.com" target="_blank">konachan.700@gmail.com</a> <mailto:<a href="mailto:konachan.700@gmail.com" target="_blank">konachan.700@gmail.com</a>>; >> <a href="mailto:fprint@lists.freedesktop.org" target="_blank">fprint@lists.freedesktop.org</a> <mailto:<a href="mailto:fprint@lists.freedesktop.org" target="_blank">fprint@lists.freedesktop.org</a>> >> 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?). >> > >> > <a href="https://github.com/sbechet/elanfp" rel="noreferrer" target="_blank">https://github.com/sbechet/elanfp</a> >> > >> > 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, <<a href="mailto:hdegoede@redhat.com" target="_blank">hdegoede@redhat.com</a> >> <mailto:<a href="mailto:hdegoede@redhat.com" target="_blank">hdegoede@redhat.com</a>>> >> >> >> 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](<a href="https://github.com/sbechet/elanfp/blo" rel="noreferrer" target="_blank">https://github.com/sbechet/elanfp/blo</a> >> >>> 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 > <a href="mailto:fprint@lists.freedesktop.org" target="_blank">fprint@lists.freedesktop.org</a> > <a href="https://lists.freedesktop.org/mailman/listinfo/fprint" rel="noreferrer" target="_blank">https://lists.freedesktop.org/mailman/listinfo/fprint</a> </blockquote></div>