Hi Timo, 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.
On Sat, Feb 10, 2018 at 11:12 PM TeEmZe <[email protected]> wrote: > Hi, > > > > 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. > > 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. > > So I’d be happy if some people could test it so that we can soon implement > the algorithm into the actual tool. > > > > Kind regards > > > > Timo > > > > *From:* fprint [mailto:[email protected]] *On Behalf > Of *TeEmZe > *Sent:* Friday, 9 February 2018 23:48 > *To:* 'Igor Filatov' <[email protected]>; [email protected] > > > *Subject:* Re: [fprint] elan patch + poc 0x903 and 0x0C03 > > > > 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 > 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. > > 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 > > > > Timo > > > > *From:* fprint [mailto:[email protected] > <[email protected]>] *On Behalf Of *Igor Filatov > *Sent:* Friday, 9 February 2018 20:43 > *To:* [email protected] > *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. > > > > > > Hi, > > > > > > 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 > > > > Timo > > > > *From:* fprint [mailto:[email protected]] *On Behalf > Of *wp12880529-timo wp12880529-timo > *Sent:* Friday, 9 February 2018 03:30 > *To:* Hans de Goede <[email protected]>; Sebastien Bechet < > [email protected]>; Igor Filatov <[email protected]> > *Cc:* [email protected] > > > *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 > > > > Timo > > Igor Filatov <[email protected]> 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 know. > > > >
_______________________________________________ fprint mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/fprint
