[fprint] elan patch + poc 0x903 and 0x0C03

Sat Feb 10 22:44:47 UTC 2018

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 <timo at teemze.de> 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:fprint-bounces at lists.freedesktop.org] *On Behalf
> Of *TeEmZe
> *Sent:* Friday, 9 February 2018 23:48
> *To:* 'Igor Filatov' <ia.filatov at gmail.com>; fprint at lists.freedesktop.org
>
>
> *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:fprint-bounces at lists.freedesktop.org
> <fprint-bounces at lists.freedesktop.org>] *On Behalf Of *Igor Filatov
> *Sent:* Friday, 9 February 2018 20:43
> *To:* fprint at 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.
>
>
>
>
>
> 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:fprint-bounces at lists.freedesktop.org] *On Behalf
> Of *wp12880529-timo wp12880529-timo
> *Sent:* Friday, 9 February 2018 03:30
> *To:* Hans de Goede <hdegoede at redhat.com>; Sebastien Bechet <
> sebastien.bechet at osinix.com>; Igor Filatov <ia.filatov at gmail.com>
> *Cc:* fprint at 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
>
>
>
> Timo
>
> Igor Filatov <ia.filatov at 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 know.
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/fprint/attachments/20180210/80c2ea2f/attachment-0001.html>