[fprint] fprint for embedded

[Jono Woodhouse]

Hi Daniel

Thanks for your reply
> Purely out of curiosity, have you timed how long it takes?
I haven't run the minutiae detection or the bozorth3 functions on the 
cris foxboard, but I did compile a small amount of the other nbis code 
(a good while back) and, from memory, one of the functions (image 
conversion) which was taking something like 0.05 seconds on an i386 
666MHz AMD Celeron was taking around 20 seconds on the foxbord (cris 
axis chip at 100MHz with no FPU). So the minutiae detection and bozorth3 
functions would be a whole boat-load worse.

Incidentally (and there maybe other stats that other people can 
contribute here):
Minutiae detection on:
1500MHz Via C7  = ~0.6 seconds (acceptable speed)
200Mhz Vertex86 = ~13 seconds (which is too slow for our use)

The 1500MHz Via C7 can bozorth3 all 10 items in a fingerprint gallery in 
about 0.1 second.
Taking into account that on average successful identification only needs 
to scan half the gallery (and less if you re-arranged the gallery into a 
more optimal order), then identifications on 200 images would average 1 
second.

> My thinking is that we should stay with one library, but it should be 
> heavily customizable which parts can be built. So we'd have 
> ./configure switches for excluding components (like minutiae 
> detection/matching/...).
That works with me.
>
> As for removing glib: no objections, just will probably wait until the 
> libusb-1.0 rework is completed before doing this.
>
Fair call. I think that removing the need for glib will hugely increase 
the portability of your project too. For example, I've tried compiling 
libfprint on a Fedora Core 3 machine, and it didn't have glib installed. 
It was a real nightmare as there were just too many missing (or 
outdated) dependencies that glib needed that I eventually stopped trying 
to compile glib. (Incidentally it works fine on Fedora Core 7 and Slax 6.0).

Did I read correctly that the new libusb-1.0 will require one of the 
latest linux kernels? This could be a real problem in the embedded 
world, where updating one's kernel is no small feat. For example the 
foxboard (currently using Linux 2.6.15) needs some crafty customisation 
to get a new kernel built otherwise USB stops working. (And then bad 
things happen to good people). So a kernel update for this embedded 
device is basically out of most peoples reach, and the kernel only 
updates when the device developers make a kernel update.
> As for removing ImageMagick: rather we should just make a way to 
> identify relationships between drivers and requirements, and create 
> configure flags where we can enable/disable building of certain drivers.
>
Excellent.
> uru4000 requires libcrypto from OpenSSL in order to do the 
> challenge-response authentication required to support the latest 
> generation of microsoft scanners. Again, the above system (identifying 
> driver dependencies on external libraries) would make it possible to 
> lose the OpenSSL dependency if uru4000 is not built. In this specific 
> case, we could also add AES code internally and have a configure flag 
> to use that instead of the systems libcrypto -- allowing for uru4000 
> to still be built and useful with no libcrypto, which embedded users 
> would probably appreciate.
>
Again some compile flags could override the normal behaviour if the 
developer knows the uru4000s are going to be the older models that don't 
require AES.
>> 9. I've then written some wrapper code (in my project - but I'm half 
>> tempted to put this back into the libfprint library code), that hacks 
>> together all the devices, drivers, usb_ids, discover devices, image 
>> drivers & images so that one can capture fingerprints without having 
>> to run fp_discover_devs() (which has glib dependencies).
>
> I'd be interested in further explanation here. Or is this simply to 
> avoid the code that uses GSLists?
>
Basically because I couldn't call fp_discover_devs() because of not 
having glib - yes for the GSLists - which seem to use every known glib 
function in the library :) -
So I had to manually open the usb devices, and then setup the 
fp_dscv_dev and fp_driver structs so that the behaved as if 
fp_discover_devs() had been called.

(On the i386 box) When it came to feeding a manually created image to 
fpi_img_to_print_data(), I also had to pass it an image device which I 
had to hack out of a fingerprint device, which I could get from a 
discovered device. Which seemed quite a convoluted approach. Maybe there 
is a better one?


> This problem will be solved with the next major release 
> (libfprint-0.1.0?) which will use libusb-1.0. The major difference 
> here is that libfprint will offer you an asynchronous API (one with no 
> blocking functions), and you can cancel an ongoing asynchronous scan 
> request whenever you feel like it.
>
Fantastic.
 From a portability point of view it may be good to offer people the 
choice to link to both libusb-0.1 or libusb-1.0 (and then having the 
added functionality).

>
>> - investigate profiling of the nbis code - although I am guessing the 
>> coders at NIST have done this.
>
> There is some low hanging fruit here
I've also been looking at the number of doubles that are used. And until 
it's been profiled there's no telling as to whether it will help, but 
there may be some performance increases to switching some doubles to 
ints (possibly multiplied by constant factors like 1000).

Also, as I mentioned earlier allowing a gallery to be re-ordered could 
also increase the efficiency of the identification.
In some cases "most recently used" at the top would be more efficient, 
or in other cases where someone who has just scanned is the least likely 
to scan again soon, the inverse may be better. (Possibly further 
optimised by still keeping prints that aren't being used at all 
regularly even lower down in the list).

> - NBIS has no static functions, but many are only used in one place.
>   Marking them static allows the compiler to do more optimizations and
>   inlining. I have done this a bit already, and it results in some
>   noticable differences (compiled code noticably smaller)
Did you see any noticeable speed performances too?
> - Stack usage can be much improved, using more dynamic data structures
>   (mindtct minutiae sets have big fixed static size)
Yeah, I think they always store something like 200 or 400 minutiae - 
which for high-quality scanned paper fingerprints or rolled-prints is 
probably about right, but for cheap fingerprint scanners is a little 
optimistic (and wasteful).

>
> The above is all doable and realistic - although my short term focuses 
> are admittedly elsewhere.
That's fully understandable. My ComSci university exams still bring back 
stressful memories!!

> I could also ask the SFLC if there are any licensing approaches that 
> would eliminate the dangers of closed sourced drivers...
>
You might find that once libfprint is being included in many of the 
Linux distros that it will have gained enough momentum, that the drivers 
being included just follow suit of all the other driver components and 
remain open. I would imagine that the majority of fingerprint devices 
manufacturers are making their money from the hardware devices, and not 
the software drivers.

>
> At the very least, if that were all implemented, your "fork" would be 
> far less intrusive.
>
Okay, well I will clean up my code on this side in the meantime. Maybe 
once your exams are done and you've progressed with libusb-1.0 we could 
merge in some changes.

It also sounds like Davidlohr and Andrei have some useful contributions.

All the best.

Cheers
Jono
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.reactivated.net/pipermail/fprint/attachments/20080117/c3137a2e/attachment-0001.html