Hi all, a couple of comments
I totally agree with Daniel on being able to include certain required libs for specific drivers, good way to aproach this! I have even designed the lib initialization for specific devices, for example I can now do: struct fp_dev *dev = capture_init(FDU2000) /* work with the dev*/ capture_exit(dev); So if we could customize the configure script to load libs according to drivers that would be super. As for feeding info between libraries, I base everything I can on unsigned char * types. So If I have previously captured an image (I don't care how), I can use the minutia library, for example: unsigned char *buff; struct fp_minutiae *min; buff = get_image_from_database(DB_QUERY); get_minutiae(buff, &min, heigh, width); /* do things with the minutiae */ Personally I think this is a wise approach (specially for embedded development). 2008/1/17, Daniel Drake <[EMAIL PROTECTED]>: > > 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 >
_______________________________________________ fprint mailing list [email protected] http://lists.reactivated.net/mailman/listinfo/fprint
