Jono Woodhouse wrote: > I too have been working on using the libfprint library on an embedded > (cris) architecture, and as of last night now have a working model, > where a fingerprint is read on an embedded cris Linux machine and send > it to a Linux i386 machine which performs the identification, the > results are then sent back to the cris Linux machine. > The cris machine is too slow to perform the identification process by > itself - partly because it runs at 100MHz and even more so because it > has no Floating Point Unit - (doubles are used heavily by the bozorth3 > and mindtct algorithms in the nbis code).
Purely out of curiosity, have you timed how long it takes? > Since this is primarily Daniel's project, it makes sense to see if all > the changes that embedded developers are making could be folded back > into either the main source line, or branched sources for each version > that Daniel releases. > Daniel, is this option, or would you prefer a new separate embedded > project altogether (although this seems a pity)? 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/...). As for removing glib: no objections, just will probably wait until the libusb-1.0 rework is completed before doing this. 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. So, the aes4000 driver would require ImageMagick, and the dependency would exist in that case. But if the aes4000 driver is excluded, then ImageMagick does not get pulled in. aes4000 is the only driver that requires ImageMagick, and hopefully that's only a temporary thing. 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. > 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? > - look into seeing if you can have a sig_atomic_t that is checked in the > fingerprint capture loop code, so that it's possible to abort a > fingerprint capture even while you are say await_finger_on(). 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. > - investigate the interrupt of Death - which I still sometimes get using > the uru4000 I get that sometime as well, but only on some devices. > - investigate profiling of the nbis code - although I am guessing the > coders at NIST have done this. There is some low hanging fruit here - 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) - Combining files has some similar effects - Some read-only data could be marked const for runtime reductions. - More space saving through eliminating unused code (quite a few functions...) - Stack usage can be much improved, using more dynamic data structures (mindtct minutiae sets have big fixed static size) The above is all doable and realistic - although my short term focuses are admittedly elsewhere. At the very least, if that were all implemented, your "fork" would be far less intrusive. The one remaining issue is the matter of capturing images on one system and feeding them in on another. The main reason I have avoided this functionality up to this point is the concern that this effectively allows people to write proprietary drivers for libfprint, which I suspect vendors would go ahead and do assuming libfprint gets decent adoption from their direct customers. That's where the model falls over... But, you have definitely highlighted a technical reason why this functionality is quite important - when the device doesn't have enough computing power to do the processing itself. So maybe I should reconsider this. I could also ask the SFLC if there are any licensing approaches that would eliminate the dangers of closed sourced drivers... > Daniel, thanks again for a fantastic project. Well done. I hope your > lectures give you top marks. Thanks for your feedback. Daniel _______________________________________________ fprint mailing list [email protected] http://lists.reactivated.net/mailman/listinfo/fprint
