Why "standard" fingerprint templates are a bad idea

Organizations like ANSI or ISO promise that their fingerprint template formats are "standard" and "open" and that they promote "interoperability" and "compatibility" between systems from different vendors, which should allow customers to combine the best feature extractors with the best matchers. This sounds good in the ear of a naive customer, but it is a lie and these "standards" actually accomplish the opposite. They cause proliferation of numerous effectively closed formats and limit competition from smaller vendors, especially opensource. They also damage recognition accuracy. Let me explain.

Pretending there is a standard

Let's draw a line between formal standards and effective standards. Effective standards are valued, because they simplify everything. You can assume that nearly everything on the market complies with the standard. Formal standards on the other hand bring no advantage to end users. They are only necessary as an intermediate stage on the path to becoming effective standards and they sometimes linger around when they fail to become effective standards.

The problem with fingerprint template "standards" like ANSI 378 and ISO 19794-2 is that they are not effective standards and they were never intended to become effective standards. They add complexity to the market instead of removing it. Entertainingly, even different versions of the same format are hopelessly incompatible with each other. ANSI/ISO committees just redesign the whole format every time instead of ensuring backward compatibility. There is clearly no intention to establish an effective standard.

Promoting closed formats as "open"

Organizations like ANSI and ISO were the way things were done in the open in the 20th century. I understand that. This is age of opensource though, not to mention the Internet. By opensource definition of openness, fingerprint template formats defined by ANSI and ISO are closed. You cannot just go to a website and read the spec. You have to spend between 50€ and 200€ per version of the format to get a PDF under restrictive single seat license that won't even let you show the PDF to coworkers sitting next to you.

An opensource project cannot be really open if it implements specification only available under such restrictive license. This is why this whole website was created—to enable opensource implementations that are truly open by publishing functionally complete summaries of these formats under permissive license. There is however nothing stopping ANSI or ISO from publishing new versions of their formats that obsolete information published here.

Excluding smaller vendors and opensource

While the above could be explained away as ANSI/ISO being behind the times, I want to draw attention to features of these formats that appear to be specifically designed to limit competition. ANSI 378 has a mandatory field for vendor ID. It turns out you have to pay $500 to some obscure industry association to obtain this ID, which is otherwise utterly useless. You might ask why didn't they just include a UTF-8 field for vendor's domain name or made the field optional? Well, that's most likely because such solution wouldn't allow for exclusion of smaller market players, especially opensource, and it won't allow for extortion of additional fees.

Fortunately, this scam was recently subverted by Lisa Rajchel (who works for ISO) by registering vendor named "Vendor Unknown", which should be accepted everywhere. Before that, there was a special value for testing, but one was never sure whether some software downstream won't throw an exception on it. Payment is still necessary to make use of some other fields in ANSI 378, which can be fortunately left blank without losing full compliance.

Loss of information

Fingerprint templates defined by ANSI and ISO have several variants, but the most commonly used ANSI 378 and ISO 19794-2 templates carry only minutiae with some small extras. They completely omit ridge shapes, which can significantly boost accuracy of matchers. There are many other useful fingerprint features that cannot be represented. Feature extractors have to discard them and matchers cannot use them to boost scores, which hurts especially in cases where the two fingerprints have small overlap.

Loss of accuracy

Fingerprint template formats are fundamentally different from formats used by more traditional software. For example, use of standard email headers only causes loss of some features and some performance. With fingerprint template formats however, there is a non-trivial loss of matching accuracy.

This is because ANSI/ISO template formats split fingerprint recognition into totally separate feature extractor and matcher with only the template communicated between the two. But even though the template tells the matcher a lot about the fingerprint, it says nothing interesting about the feature extractor the template came from.

To see why this is a problem, consider that two feature extractors might have different distributions of errors, for example in determining minutia angles. Matcher that has no knowledge of the source feature extractor is unable to adjust its tolerance ranges to accommodate these differences between feature extractors. If the matcher was developed against feature extractor from the same vendor, as is usually the case, it will embed assumptions about that feature extractor or even embed probability distributions measured on the feature extractor. When used with another feature extractor, its assumptions and probability calculations will be wrong, which will result in some loss of accuracy.

This loss of accuracy motivates customers to build their systems from components produced by the same vendor, because accuracy loss is smallest between components from the same vendor, which have been tuned together or even designed by the same person. This goes against the spirit of having common template format and it gives unfair advantage to incumbent vendors.

Prescriptive requirements

Spec editors try to deal with this issue by tightening requirements for feature extractors. That inevitably makes the format more prescriptive, requiring feature extractors to implement specific algorithms. Some specs go as far as requiring exact values for algorithm parameters.

Worse yet, different formats or even different versions of the same format have mutually incompatible prescriptive requirements. The only way to implement all of these formats in one feature extractor is to inform the feature extractor upfront about which format to target and thus which algorithms to use. It is no longer possible to use custom (possibly superior) feature extractor algorithms to generate internal templates and then just convert them to one of the ANSI/ISO formats. Algorithms must be designed for conformance, compromising other design goals.

In practice, nobody observes the strict requirements for feature extractors. It is way easier for implementors to break the rules, use their custom algorithm, and then perform conversion to ANSI/ISO format as well as possible but never perfectly. Most feature extractors claiming conformance aren't really conforming to any format spec. They are just doing best effort conversion from internal template format.

It is easy to blame implementors for being sloppy, but they are just doing their best to fit foreign template formats on their unique feature extractor. This is instead an inherent flaw of the ANSI/ISO template formats, because these formats cannot accommodate natural diversity in feature extractor algorithms.

Fingerprint images are the future

There is one well-known and truly compatible standard for interchange of fingerprints: plain images. You can opt for either lossless (PNG) and lossy (JPEG) compression. Common image formats (PNG, JPEG, or even BMP) are widely supported. Even JPEG, originally a closed format, has its specification published online. 500dpi fingerprint images are small enough for today's storage devices and networks.

Most importantly, fingerprint images are fully compatible with all fingerprint recognition software. Images provide the software with plenty of freedom in choosing the best algorithms and evolving these algorithms over time. Images preserve all useful details, even with lossy compression. There is no need to compromise on accuracy.

But what about embedded systems?

You can encounter ANSI/ISO templates mostly when capturing fingerprints on embedded hardware where the fingerprint reader comes bundled with image processor and its own feature extractor algorithm. This is largely legacy hardware though. High-performance embedded systems are getting cheaper in terms of cost and power consumption. It rarely makes sense to accept the complexity, limitations, and risks of a bundled feature extractor.

On the software side, feature extractors can be and should be fast enough to run imperceptibly fast on modern embedded hardware. While my own algorithm, SourceAFIS, is not fast enough yet, I am sufficiently knowledgeable about feature extractors to be sure it can be optimized to run within performance limits of passively cooled ARM processors.

Embedded systems are often asymmetrically equipped with weak compute hardware and fast, reliable networking. In these situations, it makes sense to send the fingerprint image to the cloud and run feature extractor and matcher there. If cloud really becomes a utility service with reliability and availability comparable to electricity, running everything in the cloud will be the ultimate future of all software.

But what about security and privacy?

Some people mistakenly believe that fingerprint templates are better at protecting biometric data than fingerprint images. They think that since the template loses information, it is impossible to reconstruct the original fingerprint from it. While this is technically true, the protection it affords is quite useless.

Templates preserve all relevant information. It is possible to reconstruct a fingerprint that, while being somewhat different, will be similar enough to match the original fingerprint template. If fingerprint templates are used universally for identification instead of fingerprint images, as some people imagine, the original fingerprint loses value from security perspective and all attacks on biometric systems can be performed with leaked fingerprint templates alone.

Conclusion

I hope I have persuaded you to avoid the so-called "standard" templates. Ignore template format references in product specs and always ask the vendor for image API. Avoid adding template format requirements to specs for government and business information systems and instead require capture and long-term storage of fingerprint images. Avoid fingerprint templates in all communication protocols and transfer images instead.