[fprint] Verification help request (Egis Technology 1c7a:0570)

[Igor Filatov]

> Did i get you right, there is no way to use my device with libfprint
matching alorythm, unless I try to use my scanner as a swipe-type one?

No way it will work reliably every time. The used algo expects to find and
compare minutiae on the prints (https://www.uh.edu/engines/epi2529.htm)
which there are little to be found when the scan area is small. For ex, I
can see only 1 on scans/finger_avg_167. You need to reliably get 30+
(number based on my experience, not on a thorough evaluation of the algo).
And the number also depends on the area which you capture. For ex. the same
sized area of my finger can have 1-2, or it can have 20, depending on where
it is. Even if you manage to find such area on your finger and train
yourself to scan it all the time, other people won't be able to use your
driver.

> And i am curious why does it return several images instead of one?

This I don't know... It's possible that the pixels are not packed
row-after-row. E.g. the first row starts at idx 0 and ends at 113, the
second row starts at 114*57 and ends at 114*57 + 113 etc. Or it's just the
way your device works. However you chose to extract the image, make sure it
does NOT contain the same area more that once. Otherwise the scoring will
not work correctly and you can get many false positives.

On Wed, Feb 14, 2018 at 12:04 PM Indev <indev12 at gmail.com> wrote:

> Did i get you right, there is no way to use my device with libfprint
> matching alorythm, unless I try to use my scanner as a swipe-type one?
> That's exactly what you did with your Elan driver, right?
> The scan area is indeed very small.
> And i am curious why does it return several images instead of one?
> Isn't it simplier to process in any case, especially when it is press-type
> sensor? Just saying.
>
>
> 2018-02-12 4:57 GMT+07:00 Igor Filatov <ia.filatov at gmail.com>:
>
>> Hi,
>>
>> 1. You need to find out the correct format of returned data. By correct I
>> mean the one that allows to decode an image of a fingerprint. This is
>> necessary for the matching algorithm to work. The .pgm files in your repo
>> don't look like fingerprints, right? They look like noise because the
>> dimensions are incorrect.
>> 2. Raw data is not fine. I've tried a few variant and it looks like your
>> device returns 8bit 114x57 images. And it returns 5 of them together. Not
>> sure, maybe the driver is supposed to combine them in some way.
>> 3. libfrpint doesn't care that much about pixel dimensions. What is does
>> very much care about is the physical size of the fingerptint that a device
>> can scan. In your case it's very small. It won't work. Welcome to the
>> club... See the recent discussions in the mailing list about the Elan
>> driver I'm writing. It has the same problem tldr: libfprint uses a fp
>> matching algo that detects minutiae (notable elements of a fingerprint) and
>> needs to see 60+% of a print surface (from my observations, ymmv) to work
>> reliably. Your reader covers maybe 15%. That's not enough. Original drivers
>> for such devices for Windows, phones etc. probably have a different
>> matching algo.
>>
>> On Sun, Feb 11, 2018 at 1:25 PM Indev <indev12 at gmail.com> wrote:
>>
>>> Hello,
>>>
>>> I am writing a driver for Egis Technology Inc. sensor (ID 1c7a:0570),
>>> but having few problems.
>>> First of all, i have no idea what is the model of my sensor. I've
>>> checked USB.org product lists as well as manufacturer's website and Acer
>>> website (I am using Acer Swift 1 SF-113-31 with this sensor integrated).
>>> I failed to find any kind of information about my device and started to
>>> write driver without that.
>>> I was managed to recreate driver exchange process and get data from the
>>> sensor.
>>> This is the press-type sensor and it returns 32512 bytes of data in one
>>> packet, which seem to be raw image data.
>>> I don't know what is the size of the returned image, so i've picked up
>>> the most suitable one for libfprint driver.
>>> Couple days ago i finished libfprint driver and it works fine, except of
>>> the fact that the verify_live example from libfprint is not able to do
>>> correct verification. It can't recognize same finger again and allows to
>>> pass verification by another finger, which is kinda funny.
>>>
>>> I have absolutely no experience with fingerprint scanner and I was
>>> hoping that someone here could help me.
>>> This is the repository of my driver: https://github.com/indev29/egis0570
>>> The 'scans' directory contains examples of fingerprint scans converted
>>> into different sized .pgm images as well as raw binary data, received from
>>> sensor.
>>> Directories names ("scans/finger_avg_NUM") indicate average color value,
>>> which is more, when i press harder on sensor.
>>>
>>> My questions are:
>>> 1. Should i use this raw image data in my libfprint driver or should i
>>> process it somehow first?
>>> 2. If raw data is fine, why am i not able to do verification correctly?
>>> 3. Does libfprint care about image size? Can the wrong image size be the
>>> thing in my case (i am using 254x128)
>>>
>>> Thanks in advance,
>>> Indev
>>> _______________________________________________
>>> fprint mailing list
>>> fprint at lists.freedesktop.org
>>> https://lists.freedesktop.org/mailman/listinfo/fprint
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/fprint/attachments/20180214/3735d9c3/attachment.html>