<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=utf-8"><meta name=Generator content="Microsoft Word 15 (filtered medium)"><style></style></head><body lang=en-DE link=blue vlink=purple><div class=WordSection1>Hi Igor,<o:p></o:p><o:p> </o:p>I finally managed to test it. The results however weren’t that great. I made 15 random fingerprint scans of my right index finger and none matched with any of the other ones (the maximum was 64%, while the maximum of a few scans of my left index finger was 57%).<o:p></o:p>I assume that the problem is indeed caused by the fact, that the algorithm currently expects exactly the same region of the fingerprint.<o:p></o:p>I now have two solutions for this in my mind, however you might come up with a better one:<o:p></o:p><ol style='margin-top:0cm' start=1 type=1><li class=MsoListParagraph style='margin-left:0cm;mso-list:l0 level1 lfo1'>Assemble enrolled scans to one big print -> I imagine this to be quite difficult, as we’d have to assemble two dimensional, while we’re already struggling assembling one dimensional<o:p></o:p></li><li class=MsoListParagraph style='margin-left:0cm;mso-list:l0 level1 lfo1'>Extract common regions -> If I’m not mistaken you once suggested this, and it sounds for me like the best solution. I don’t know exactly how to do this, but I’ll take a look at it<o:p></o:p></li></ol>If you have a better idea, let me know.<o:p></o:p><o:p> </o:p>Regards<o:p></o:p>Timo<o:p></o:p><o:p> </o:p><div><div style='border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm'>From: fprint <fprint-bounces@lists.freedesktop.org> On Behalf Of TeEmZe Sent: Sunday, 11 February 2018 00:07 To: 'Igor Filatov' <ia.filatov@gmail.com> Cc: fprint@lists.freedesktop.org Subject: Re: [fprint] elan patch + poc 0x903 and 0x0C03<o:p></o:p></div></div><o:p> </o:p>Hi,<o:p></o:p><o:p> </o:p>Well, that’s the problem. Currently the orientations of blocks of 16x8 (those dimensions can be changed quite easily) pixels are compared. That means that the orientation of the top left block of the enrolled fingerprint is compared to the direction of the top left block of the verify fingerprint.<o:p></o:p>So it does work if you scan a slightly different area, but the bigger the difference, the lower the matching percentage. However, I think this can be solved by having like 10 images from the enrol process with different regions of the fingerprint. This would of course have to be tested and if 10 different regions of the finger aren’t enough, we’d probably have to find a different solution (for example you once suggested using the minutiae to extract common regions). But I already tried it with one fingerprint, which matched well, so I think another solution isn’t required.<o:p></o:p>Scanning multiple times and different regions of the fingerprint actually is quite common among other readers (like the ones of the mobile phones).<o:p></o:p><o:p> </o:p>I’ll try to manage to test it myself soon, so that we’ll see how well it actually works.<o:p></o:p><o:p> </o:p>Kind regards<o:p></o:p><o:p> </o:p>Timo<o:p></o:p><o:p> </o:p>From: Igor Filatov [<a href="mailto:ia.filatov@gmail.com">mailto:ia.filatov@gmail.com</a>] Sent: Saturday, 10 February 2018 23:45 To: TeEmZe <<a href="mailto:timo@teemze.de">timo@teemze.de</a>> Cc: <a href="mailto:fprint@lists.freedesktop.org">fprint@lists.freedesktop.org</a> Subject: Re: [fprint] elan patch + poc 0x903 and 0x0C03<o:p></o:p><o:p> </o:p><div>Hi Timo,<o:p></o:p><div><o:p> </o:p></div><div>I'll only be able to test closer to the end of next week... Although I'm not sure I understand what you mean by "same region" here. Will it work if the images have , say, 70% overlap? Because we can't expect users to scan the very same area all the time. <o:p></o:p></div></div><o:p> </o:p><div><div>On Sat, Feb 10, 2018 at 11:12 PM TeEmZe <<a href="mailto:timo@teemze.de">timo@teemze.de</a>> wrote:<o:p></o:p></div><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0cm;margin-bottom:5.0pt'><div><div>Hi,<o:p></o:p> <o:p></o:p>I fixed the issue with differently sized images and managed to test it with another fingerprint, which shouldn’t match, and got 48%. This is good, as it means that it didn’t match. <o:p></o:p>I think the algorithm is at a state, at which testing is required – all that’s left to do is some parameter optimizing, and those might already be optimized enough for the real world. Ok, that might not be 100% true, as the image still has to be from the same region of the fingerprint, but this could be solved by taking multiple images at the enrol process and check all enrolled images for a match.<o:p></o:p>So I’d be happy if some people could test it so that we can soon implement the algorithm into the actual tool.<o:p></o:p> <o:p></o:p>Kind regards<o:p></o:p> <o:p></o:p>Timo<o:p></o:p> <o:p></o:p><div><div style='border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm'>From: fprint [mailto:<a href="mailto:fprint-bounces@lists.freedesktop.org" target="_blank">fprint-bounces@lists.freedesktop.org</a>] On Behalf Of TeEmZe Sent: Friday, 9 February 2018 23:48 To: 'Igor Filatov' <<a href="mailto:ia.filatov@gmail.com" target="_blank">ia.filatov@gmail.com</a>>; <a href="mailto:fprint@lists.freedesktop.org" target="_blank">fprint@lists.freedesktop.org</a><o:p></o:p></div></div></div></div><div><div><div><div style='border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm'> Subject: Re: [fprint] elan patch + poc 0x903 and 0x0C03<o:p></o:p></div></div></div></div><div><div> <o:p></o:p>Hi Igor,<o:p></o:p> <o:p></o:p>I implemented the basis of an algorithm – you can take a look at it <a href="https://github.com/MetaColon/Libfprint/tree/master/Algorithm" target="_blank">here</a>. It is however far from finished or even optimised and is in need of some testing. I however don’t currently have the possibility to test it, so I’m asking you whether you could test it and maybe take a look at the todos written as comments in the source code.<o:p></o:p>I had one image to test it with, and the result was 75%, which is good, as the paper I used as a reference said that it’s a match as soon as the percentage is above 70%.<o:p></o:p> <o:p></o:p>Kind regards<o:p></o:p> <o:p></o:p>Timo<o:p></o:p> <o:p></o:p>From: fprint [<a href="mailto:fprint-bounces@lists.freedesktop.org" target="_blank">mailto:fprint-bounces@lists.freedesktop.org</a>] On Behalf Of Igor Filatov Sent: Friday, 9 February 2018 20:43 To: <a href="mailto:fprint@lists.freedesktop.org" target="_blank">fprint@lists.freedesktop.org</a> Subject: Re: [fprint] elan patch + poc 0x903 and 0x0C03<o:p></o:p> <o:p></o:p><div>Hi Timo,<o:p></o:p><div> <o:p></o:p></div><div>I've noticed this when working on the initial implementation - that rows at bottom and top are bad (and I've seen a number of scans sent by different people - it's never on the sides for some reason). That's why there was the frame_margin param which means "cut this many px from top and bottom". Actually, in recent commits this has changed and it just crops the frame to max 50px by height. Since assembly doesn't really work for frames higher than that.<o:p></o:p></div><div> <o:p></o:p></div><div>But ultimately libfprint needs a different algo for small sensors. No getting around it. Telling people they need to swipe even though they see have a touch sensor isn't feasible and seems to already be failing in practice. I've trained myself to swipe reliably but still... don't want to spoil my karma with a driver that pretends to work but is hardly usable.<o:p></o:p></div><div><div> <o:p></o:p></div><div> <o:p></o:p></div><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0cm;margin-bottom:5.0pt'><div><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0cm;margin-bottom:5.0pt'><div><div>Hi,<o:p></o:p> <o:p></o:p> <o:p></o:p>I might actually have another solution. <o:p></o:p>The fingerprint images, that are created by the swiping, are assembled out of multiple images, the reader got, right? I now realized that each of those images seems to have about one or two rows of pixels at the top and at the bottom, which are simply black. Those rows alter the image, so that similar fingers aren’t matching, as the rows are at different positions in the image if the finger was moved with a different speed – which is always the case. So I think we should try changing the way we generate the image with the swipe movement by cropping each image, of which the final image is assembled, by two pixels at the top and the bottom. I don’t know whether this solves all problems, but I can at imagine that it’d at least improve it. I am however still working on an alternative algorithm, which uses cross correlation of field orientation, but I can imagine that this won’t be necessary anymore.<o:p></o:p> <o:p></o:p>I don’t know the way you’re currently assembling the joined fingerprint image, so maybe someone who does could give this a try? I’ll be happy to test it afterwards.<o:p></o:p> <o:p></o:p> <o:p></o:p>Kind regards<o:p></o:p> <o:p></o:p>Timo<o:p></o:p> <o:p></o:p><div><div style='border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm'>From: fprint [mailto:<a href="mailto:fprint-bounces@lists.freedesktop.org" target="_blank">fprint-bounces@lists.freedesktop.org</a>] On Behalf Of wp12880529-timo wp12880529-timo Sent: Friday, 9 February 2018 03:30 To: Hans de Goede <<a href="mailto:hdegoede@redhat.com" target="_blank">hdegoede@redhat.com</a>>; Sebastien Bechet <<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>> Cc: <a href="mailto:fprint@lists.freedesktop.org" target="_blank">fprint@lists.freedesktop.org</a><o:p></o:p></div></div></div></div><div><div><div><div style='border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm'> Subject: Re: [fprint] elan patch + poc 0x903 and 0x0C03<o:p></o:p></div></div></div></div><div><div> <o:p></o:p>Hi Igor,<o:p></o:p> <o:p></o:p>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.<o:p></o:p> <o:p></o:p>Kind regards<o:p></o:p> <o:p></o:p>Timo<o:p></o:p><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'>Igor Filatov <<a href="mailto:ia.filatov@gmail.com" target="_blank">ia.filatov@gmail.com</a>> hat am 4. Februar 2018 um 16:07 geschrieben: <o:p></o:p><div>Hi everybody,<o:p></o:p><div> <o:p></o:p></div><div>Base on the new info I got I've updated the driver in a few places:<o:p></o:p></div><div> <o:p></o:p></div><div>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.<o:p></o:p></div><div> <o:p></o:p></div><div>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.<o:p></o:p></div><div> <o:p></o:p></div><div>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.<o:p></o:p></div><div> <o:p></o:p></div><div>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.<o:p></o:p></div><div> <o:p></o:p></div><div>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.<o:p></o:p></div> <o:p></o:p></div></blockquote></div></div></blockquote></div></blockquote></div></div></div></div></blockquote></div></div></body></html>