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
_______________________________________________
fprint mailing list
[email protected]
http://lists.reactivated.net/mailman/listinfo/fprint
