Hi Igor,


I implemented the basis of an algorithm – you can take a look at it here 
<https://github.com/MetaColon/Libfprint/tree/master/Algorithm> .
It is however far from finished or even optimised and is in need of some 
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.

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%.


Kind regards




From: fprint [mailto:fprint-boun...@lists.freedesktop.org] On Behalf Of Igor 
Sent: Friday, 9 February 2018 20:43
To: fprint@lists.freedesktop.org
Subject: Re: [fprint] elan patch + poc 0x903 and 0x0C03


Hi Timo,


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.


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.






I might actually have another solution. 

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.


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.



Kind regards




From: fprint [mailto:fprint-boun...@lists.freedesktop.org 
<mailto:fprint-boun...@lists.freedesktop.org> ] On Behalf Of wp12880529-timo 
Sent: Friday, 9 February 2018 03:30
To: Hans de Goede <hdego...@redhat.com <mailto:hdego...@redhat.com> >; 
Sebastien Bechet <sebastien.bec...@osinix.com 
<mailto:sebastien.bec...@osinix.com> >; Igor Filatov <ia.fila...@gmail.com 
<mailto:ia.fila...@gmail.com> >
Cc: fprint@lists.freedesktop.org <mailto:fprint@lists.freedesktop.org> 

Subject: Re: [fprint] elan patch + poc 0x903 and 0x0C03


Hi Igor,


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.


Kind regards



Igor Filatov <ia.fila...@gmail.com <mailto:ia.fila...@gmail.com> > hat am 4. 
Februar 2018 um 16:07 geschrieben: 

Hi everybody,


Base on the new info I got I've updated the driver in a few places:


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.


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.


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.


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.


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 


fprint mailing list

Reply via email to