Private forks of SourceAFIS
SourceAFIS is opensource and free to use and it will always be this way. There are however circumstances where a feature is suitable for some application but unsuitable for the opensource project. Other times a business urgently needs a feature that is not yet implemented. In these situations, it is possible to pay for custom development of software derived from or supplementing SourceAFIS.
SourceAFIS was almost exclusively developed by Robert Važan who will be also responsible for your custom development project. If you are interested, contact me via email robert.vazan@tutanota.com.
This page lists features that are often requested. This is not meant to imply that these features will be added only if someone pays for them. I can at any time choose to implement any of the features listed below for free and include them in opensource code. Custom development contract merely accelerates development of features that are of particular interest to you. You may of course request development of your own idea for a feature or an entirely custom application-specific code.
If custom development involves a feature that is also a candidate for inclusion in opensource code, the contract will come standard with non-publishing clause that gives you 6 to 36 months of headway in case the feature is a competitive advantage for your business. After the non-publishing clause expires, the code may be opensourced. There is however no guarantee that any sponsored code appears in opensource version of SourceAFIS. Only features deemed desirable by the community and having high-quality implementation are opensourced.
Projects are usually developed for fixed price against fixed deadline with the exception of application-specific code, which may be billed per hour. Prices for most SourceAFIS features on this page range from 1,000 EUR to 10,000 EUR with documentation on the lower end, biometric features and algorithm accuracy and speed on the higher end, and compatibility in the middle. There are exceptions though and prices also vary with many factors, including time pressure, my preferences for the feature, possibly partial implementation, and special requirements. Contact me for a quote.
Contents
Compatibility
While the core biometric technology in SourceAFIS could use improvements too, many users of SourceAFIS face the more mundane issue of how to interface with SourceAFIS from their preferred programming language or platform. While building your own REST/RPC bridge is not that hard, official port has the advantage of higher correctness and better future support, perhaps even better performance and better usability. Users of official ports also have their forum questions answered and their bugreports / issues addressed.
Rust port
Rust is a promising alternative to C/C++ that is safe and secure and yet fast, lightweight, and close to the metal. This is particularly interesting for embedded device development since Rust is much more lightweight than either Java or .NET. Rust port would involve complete rewrite of SourceAFIS in Rust language plus automated tests that verify consistency with other language ports.
Server with REST API
While library version of SourceAFIS is the easiest to use, it limits SourceAFIS to sufficiently fast languages. Wrapping SourceAFIS in a server with clean REST API would allow development of client libraries for numerous programming languages. The server would be most likely distributed as both a docker image and a java console app. There would be a limited login-free cloud version that would be used in tutorials, unit tests, and for local development to spare developers of the need to run local server. Self-hosted server (perhaps just running on localhost next to the app) would be however necessary for production use. Over time, cloud server could be upgraded to make self-hosting of the server entirely optional.
Python port
If the above described Rust port is done first, Python port can be implemented as a thin wrapper around native binaries produced by Rust. C++ is the more common native backend for Python, but Rust has the advantage of higher stability and security. Native binaries would be provided for all common platforms and Python wrapper would automatically use the right one. Python port could be also done as a client for SourceAFIS server, but a wrapper around native library is more common in Python world and it can provide better API, better performance, and easier deployment. Python wrapper would include wrapper code, build scripts, an official Python package, and documentation.
Other programming languages
Some languages can be added as a full port if the language is fast enough, which would involve about the same amount of work as the Rust port above. Slower languages can have a wrapper around native library like Python port above or they can have a client library for SourceAFIS server.
Documentation
While you could simply buy some consulting time to have things explained to you personally, it might be preferable to instead sponsor documentation on the topic of interest, because documentation writing has more predictable cost, usually higher final quality, better permanent record, and a prospect of future updates.
Security analysis
Security report should shed light on several security topics inlcuding comparison to passwords, effective bit length of fingerprints, stealing, leaks, and long-term accumulation of fingerprints, resistance to physical imitations, fingerprint template invertibility, exfiltration via similarity score, timing, or other side channels, crafting fingerprints that are universal unlockers, hiding backdoors in algorithm parameters, DoS attacks on SourceAFIS code, safety of the underlying language (especially timing side channels), build security. Description of every security issue should include practical advice on defense.
Algorithm guide
There is a brief summary of how the algorithm works and something can be inferred from documentation for transparency data. Still, detailed description of the algorithm would be desirable.
Having deep understanding of SourceAFIS algorithm is necessary if your application requires significant changes to the algorithm or even development of entirely custom algorithm. Understanding of the algorithm would also help you to make good use of algorithm transparency data. Finally, if you are already in the business of algorithm development, perhaps for you own sensor or device, or perhaps for some special application, you could pick a trick or two from SourceAFIS.
Algorithm guide would describe the inner workings of the algorithm, including informative visualizations, but perhaps more importantly, it would explain why something is done the way it is done, perhaps supporting design choices with data or other evidence. It would also include some critical evaluation of the algorithm and a short comparison to other publicly available algorithms.
Biometric features
Biometric features change the algorithm without directly aiming to improve accuracy or speed. They add new capabilities that are qualitatively different from what the algorithm is doing now.
Fingerprint quality
Fingerprint quality can mean many things: surface area touching the sensor, visual quality (contrast, noise) of the capture, or probability that the fingerprint will successfully match another high-quality scan. Here the fingerprint quality means surface area of the finger that is visible to the sensor. This metric is used to check whether the user has placed his finger on the sensor correctly or even to detect whether there is any finger touching the sensor at all.
Fingerprint quality in the sense of surface area can be already inferred from fingerprint mask that is part of algorithm transparency data. The work that needs to be done includes exposing this information through standard API in a simple and consistent way, not forcing full feature extraction just to evaluate fingerprint surface area, and benchmarking and improving accuracy of the reported surface area.
Template fusion
SourceAFIS was originally built for optical fingerprint readers that have large scanning surface. Proliferation of small handheld devices unfortunately led to current widespread use of tiny fingerprint sensors that capture fingerprint images poor in matchable features. Some sensors are so small that two random scans might have no overlap at all.
While this can be addressed in many cases by just matching new scans against all (or many) prior scans, it is more convenient for users and more efficient for the device to fuse several initial scans and then match against the fused fingerprint.
Fingerprint template fusion in SourceAFIS can be implemented by first matching the two input templates, using the match to align minutiae, dropping likely duplicates (close but non-matched), and keeping the rest. If fingerprint quality above is implemented, template fusion must also merge fingerprint surface area, which is important to know when to stop asking the user for more scans to fuse.
Scale-invariant matcher
SourceAFIS is a rotation-invariant and translation-invariant algorithm. SourceAFIS however requires specification of DPI of input images and it is very sensitive to errors in the provided DPI. Scale-invariant matcher would make SourceAFIS more tolerant of differences in DPI between images. This would make it more practical to use SourceAFIS for images captured with camera where DPI varies and in situations where DPI is not even known.
Scale-invariant matcher would start by matching randomly picked scale-invariant features like length-free edges defined by minutia angles alone or triangles of minutiae. This would be done efficiently by modifying edge hash that is currently used to match three-valued edges with length and two angles. Once the initial scale-invariant feature is matched, it is used to pick a pair of root minutiae like in the current matcher and also to derive scaling factor that would be used during the rest of the matching to bring both fingerprints to the same scale.
Approximate DPI value would be still needed for feature extractor to perform well and exact DPI value would provide matcher with small performance boost. Approximate DPI can be estimated in many applications, for example by providing visual feedback to encourage correct finger placement in front of the camera. If the fingerprint is known to cover most of the image, approximate DPI can be derived from image size.
Camera image processing
SourceAFIS was designed for traditional fingerprint readers, which is reflected in its image filtering pipeline that often completely eliminates otherwise recognizable fingerprints from camera images. Better processing of camera images would ease development of applications that make use of the widespread cameras in phones for fingerprint capture.
Camera images require smarter segmentation by color and ridge patterns instead of the current contrast-based segmentation. Camera images also need much more aggressive image equalization, because ridge patterns are more subtle on camera input.
Even with such improvements and the above described scale-invariant matcher, SourceAFIS would still lack full camera support, because fingers in front of the camera can be rotated in 3D space, which is not well tolerated in current matcher design. There are workarounds though and specialized camera image processing is best seen as a way to reduce the number of workarounds needed for camera input.
Accuracy and speed
In order to make optimizations of accuracy and speed safer and more predictable, optimizations are offered as halving challenges. Halving challenge is a bet that I make with you that I will be able to drive selected metric down by 50% for fixed price and before deadline without worsening any other metric too much (say, not more than 10%).
If I succeed, you get your optimization and I get my money. If I fail, you get a full refund and I am free to publish whatever code I have developed so far. Price and deadline are chosen in such a way that successful development is likely, which means low project risk for you.
Specific changes to the algorithm are a matter of developer's discretion. They wouldn't even come up during negotiation. This makes investments in speed and accuracy possible for investors with little or no understanding of SourceAFIS algorithm.
Halving feature extraction time
Feature extraction (or template construction) currently takes a significant fraction of a second. All interactive applications would benefit from improvement, especially applications running on embedded hardware where feature extraction can take more than a second.
Single-threaded feature extraction time can be reduced by half or more just by optimizing the most expensive parts of the algorithm: reducing complexity of oriented smoothing from O(w*h*r) to O(w*h*log2(r)), and replacing orientation detector, currently costing O(w*h*q), with a more sensitive and smarter detector with complexity O(w*h).
Parallelized feature extractor
Feature extractor (part of the algorithm that creates fingerprint templates) in latest SourceAFIS is single-threaded. Older versions of SourceAFIS for .NET had parallelized feature extractor, but this parallelization was disabled after it was discovered that it is causing unexplainable random changes in the output. With newer test infrastructure, it is possible to safely reintroduce parallelization into feature extractor.
Not all parts of the feature extractor can be parallelized, but some parallelization is natural in separate processing of ridge and valley skeletons and in vertical loops over image data that perform only one write. Care must be taken to minimize inter-core data transfers, cache thrashing, and to avoid race rules.
Halving non-match time
Halving non-match time effectively equals doubling matching speed, because large database matching is dominated by comparisons of probe fingerprint to non-matching candidate fingerprints. This optimization is therefore interesting for applications that need to search large databases of fingerprints.
Non-match time can be reduced by half or more by shortening unfruitful search for root pairs. Further improvements are possible in angular math, object allocation, and in fine-tuning parts of the matcher.
Halving matching errors
Matching errors in SourceAFIS manifest predominantly as false non-matches (failure to recognize a fingerprint) rather than false matches (treating non-matching fingerprint as a match). In other words, SourceAFIS has negligibly low FMR (false match rate) with low but perceptible FNMR (false non-match rate). This optimization targets reduction in FNMR, which is equivalent to improving recognition rates (true match rate). That means fewer retries by users in practice. This would be particularly useful on small sensors that produce images poor in matchable features.
FNMR (at some chosen FMR) can be reduced by half or more by aggressively exploiting existing biometric features, for example by scoring on a curve rather than over a threshold, scoring minutia quality, and with smarter pairing prioritization. If that is not enough, it is possible to introduce ridge matcher as an additional source of evidence for a match that would be included in similarity score.
Application-specific code
Application-specific code is written according to client requirements. I am very flexible when it comes to application development, but I prefer to focus on the part of the application that requires my expertise.
Fingerprint backend development
Fingerprint backend development is mostly about writing specialized code for fingerprint-related functionality in your application including correct persistency, caching, enrollment policy, image encoding and preprocessing, multi-finger policy, multi-threaded matching, multi-server matching, security precautions, exploiting algorithm transparency data, and dealing with difficult circumstances like small or unusual sensor, camera input, or children's fingerprints.
Fingerprint backend development may also include collection and analysis of field data and handling various issues that may arise in processing fingerprints at scale or in specialized niches, for example incompatible sensors, spurious matches, poor recognition rate, or slow matching.
Biometrics, computer vision, and artificial intelligence
Development of SourceAFIS brought with it experience in computer vision, statistics, artificial intelligence, and biometrics. This experience is partially transferable to other projects that require similar expertise.