This is a complete description of fingerprint template format defined in ANSI INCITS 378-2009[R2014] spec, often abbreviated ANSI 378-2009 or ambiguously ANSI 378, except for the following changes:
- All content is distributed under permissive CC BY 4.0 license.
- Normative content was completely rewritten from scratch to avoid infringing copyrights.
- Non-normative commentary was dropped. Author added his own non-normative comments.
- Special notes were added for opensource and in-house software developers.
- Differences from other formats and other versions of this format were documented.
This format summary is complete in the sense that implementations written according to this document are also fully conforming implementations of ANSI INCITS 378-2009[R2014]. There is no guarantee though and you should consult the original ANSI INCITS 378-2009[R2014] spec if in doubt.
This document was written by Robert Važan as part of his work on SourceAFIS fingerprint matcher using his legally obtained copy of ANSI INCITS 378-2009[R2014]. Author has no affiliation with ANSI. This format summary is distributed free of charge under Creative Commons Attribution 4.0 International License to enable truly open implementation of the format in opensource software. Nevertheless, author discourages use of ANSI 378 and other so-called "standard" templates in favor of plain fingerprint images.
Human fingerprint recognition is usually performed in two separate steps: feature extraction and matching. Feature extraction takes fingerprint image (also called fingerprint sample), usually obtained from fingerprint reader (or fingerprint sensor) hardware, and produces so-called fingerprint template filled with fingerprint features useful for matching. Matching takes two fingerprint templates on input, compares fingerprint features contained in them, and produces similarity score on output, which is then compared to a threshold to produce match or non-match decision. There are many kinds of fingerprint features: minutiae (especially ridge endings and bifurcations), core and delta points, ridge shapes or patterns, orientation and ridge frequency fields, edges between minutiae, and many others.
Most fingerprint recognition systems have their own native fingerprint template format. Some people however insist on exchange of fingerprint templates between fingerprint recognition systems even though it is almost always a bad idea. ANSI 378-2009 is one of several fingerprint template formats that can be used for this purpose.
ANSI 378-2009 mainly encodes minutiae, including their position, angle, and type (ending, bifurcation, or other). It can optionally encode ridge counts on edges between minutiae and information about cores and deltas. It carries some fingerprint metadata, notably finger position (thumb, index, ...), resolution, and image size. It permits encoding several fingerprints in a single template.
This template format supersedes earlier version defined in ANSI 378-2004. A small update to this format is described in Amendment 1. All versions can be differentiated by looking at the VERSION field, which is "030\0" for this version, " 20\0" for previous version, and "035\0" for Amendment 1.
When embedded in CBEFF (Common Biometric Exchange Framework Format, ANSI/INCITS 398-2008), CBEFF Format Type should be set to 0x203, which is registered by INCITS. Previous version of this format used CBEFF Format Type of 0x201 or 0x202. The original spec for this version of ANSI 378 doesn't state it explicitly (contrary to the previous version), but CBEFF Format Owner should be set to INCITS Technical Committee M1, which is registered as biometric organization under code 0x1B (decimal 27).
Changes made to the format since the last version (ANSI 378-2004) are listed below:
- VERSION field was changed from " 20\0" to "030\0".
- Image size and resolution fields were moved from HEADER to FINGERPRINT record.
- Multiple views of the same finger must appear together in the template.
- Fields TOTALBYTES, DEVSTAMP, DEVID, VIEWOFFSET, SAMPLETYPE have different size.
- Fields QVENDOR and QALGO were added.
- DEVSTAMP references newer version of FBI's Electronic Biometric Transmission Specification.
- Allowed values for SAMPLETYPE and FPQUALITY were expanded.
- Minutia type (MINTYPE) "other" was replaced with type "either".
- Minutia angle (MINANGLE) is more precisely defined. If MINANGLE cannot be calculated, the minutia cannot be included in the template.
- Meaning of (MINQUALITY) values has changed.
- Ridge count extension must consider all minutiae as central minutiae for the purpose of ridge counting if STARTYPE is set to quadrants (code 1) or octants (code 2).
- In ridge count extension, quadrant and octant alignment to minutia direction is now specified (see STARTYPE).
- Value of the RIDGECOUNT field is higher by one.
- Original spec states that ridge count extension must contain at least one edge, but this is impossible for null templates with no minutiae, so this format summary ignores this change.
- Core and delta extension (COREDELTA) has precise definition of location (COREX, COREY, DELTAX, DELTAY) and angle (COREANGLE, DELTAANGLE) of cores and deltas.
- CORENUM may be zero.
- CBEFF Format Type is 0x203 rather than 0x201/0x202.
The template is a binary file consisting of simple fields arranged in field groups. Fields or field groups may repeat. There are no keys or tags and fields are identified only by their position in the template. Numbers are in big-endian byte order.
There are two predefined extensions blocks. When EXTTYPE is 1, EXTDATA contains ridge count extension.
When EXTTYPE is 2, EXTDATA contains core and delta extension.
Fields and field groups
Template header (HEADER)
Header contains information common to all fingerprints in the template:
- template format identification: MAGIC, VERSION, VENDOR, SUBFORMAT,
- sensor information: DEVID, DEVSTAMP,
- total size of the template: TOTALBYTES, and
- number of fingerprints in the template: FPCOUNT.
Compared to previous version of this template format (ANSI 378-2004), image size and resolution fields have been moved into FINGERPRINT record, which makes it possible to mix fingerprints from different sources in one template. Sensor type is however still present, although it can be left blank when mixing fingerprints from different sources. Fields TOTALBYTES, DEVID, and DEVSTAMP have different size.
File signature / magic number (MAGIC)
First four bytes of the template contain constant string "FMR\0" where '\0' stands for zero byte. This is a magic number (or file signature) that helps biometric software to automatically distinguish this format from other file formats. All other versions of this template format share the same magic number. Somewhat confusingly, ISO 19794-2 uses the same magic number.
Format version (VERSION)
Version field contains 4-byte constant string "030\0" where '\0' stands for zero byte. Other versions of this format use different version string, which makes it easy to distinguish the versions.
Unfortunately, ISO 19794-2:2011 uses the same version string "030\0" along with identical MAGIC. One way to distinguish the two formats is to check whether ISO 19794-2's FPBYTES add up to TOTALBYTES (taking into account HEADER size). This is of course a completely ridiculous workaround. Spec authors apparently rely too much on external format identification. Either that or there is some format war going on between ANSI and ISO.
Total template length in bytes (TOTALBYTES)
Total length in bytes is redundant, because the template simply ends after the last FINGERPRINT section. It might be nevertheless useful to easily find the end of the template in a stream of bytes.
Template length is encoded in 4 bytes as a big-endian unsigned 32-bit number. TOTALBYTES smaller than 21 bytes is invalid, because it cannot accommodate even the template header.
This field's size and structure has changed since ANSI 378-2004 where it was either 2 or 6 bytes long depending on the size of the template.
Vendor ID (VENDOR)
A big-endian unsigned 16-bit number identifying the vendor of the sensor or application that produced the template. This field corresponds to the two most significant bytes of CBEFF Product ID. This field cannot be zero and it must contain valid vendor ID. Yes, you are reading that right: you cannot be just anybody to implement this format. You must be somebody, specifically somebody with a vendor ID.
You might be wondering where do you get such an ID? Well, this field could be just as well called "opensource disqualification field" or "small business handicap field" for the ridiculous cost of the ID. The original spec states the ID must be obtained from IBIA, an obscure industry association. IBIA will happily issue you this otherwise utterly useless ID for mere $500. Yes, you are reading that right. $500 to join the exclusive club of businesses that are allowed to create ANSI 378 templates. This has got to be the most entertaining field in the whole spec.
Luckily, Lisa Rajchel from ISO has registered vendor named "Vendor Unknown" with ID 0x103 (or 259 in decimal). I have no idea how "Vendor Unknown" came to be and how on Earth did IBIA allow it, but I guess ISO needed some fallback value in one of their own specs. Opensource, in-house, and small business implementations of this format are now free to use this loophole to avoid the ridiculous $500 fee. Aside from vendor ID 0x103 "Vendor Unknown", there is also vendor ID 0xfffe "Reserved for Testing", but that one is more likely to irritate some fussy decoders.
Vendor-specified subformat (SUBFORMAT)
A big-endian unsigned 16-bit number. The original spec is not entirely clear about the contents of this field, but author's understanding is that this is an extraction algorithm identifier tied to the vendor ID issued by IBIA as explained above under VENDOR field. The identifier doesn't have to be registered with IBIA since it's entirely vendor-defined. It effectively defines new subformat of this template format by indicating what features and extension blocks are included in the fingerprint template. Fortunately, this field can be left zeroed, which is the recommended practice for opensource implementations.
Sensor compliance (DEVSTAMP)
Top bit of this 8-bit field indicates the fingerprint reader has certificate of compliance with Appendix F (IAFIS Image Quality Specifications) of IAFIS-Doc-01078-8.001 (FBI's Electronic Biometric Transmission Specification, October 2007). Other bits are reserved. Opensource implementations should leave this field zeroed.
This field was expanded from 4 bits in ANSI 378-2004 to a full byte. Reference to FBI's image quality specification was updated to its latest version.
Sensor ID (DEVID)
The 16-bit big-endian unsigned number is an ID of the fingerprint reader used to capture fingerprints in the template. Sensor IDs are assigned by the vendor identified in VENDOR field. Value of zero is allowed and it means unknown fingerprint reader. Opensource implementations should leave this field zeroed.
This field was expanded from 12 bits in ANSI 378-2004 to 16 bits.
Number of fingerprints (FPCOUNT)
An unsigned 8-bit number that indicates the number of FINGERPRINT blocks in the template. FPCOUNT may be zero, in which case the template contains no fingerprints. Since every fingerprint must have a unique combination of POSITION and VIEWOFFSET, there cannot be more than 11 x 16 = 176 fingerprints.
A single fingerprint view, essentially a single scan from fingerprint reader. Fingerprint section contains MINUTIA records and some metadata about the fingerprint, notably finger's POSITION on hands and image dimensions necessary to interprent minutia positions (WIDTH, HEIGHT, RESOLUTIONX, RESOLUTIONY). Fingerprint section can optionally contain EXTENSION blocks, including ridge count data (RCOUNTEXT) and core/delta data (COREDELTA).
Single template can contain multiple FINGERPRINT sections. Their number is indicated by the FPCOUNT field. It is permitted to construct a template with no FINGERPRINT sections (zero FPCOUNT). Such template represents biometric system enrollee for whom fingerprint capture failed.
All fingerprint sections in the template must have unique combination of POSITION and VIEWOFFSET. If there are multiple FINGERPRINT sections with the same POSITION, then unique VIEWOFFSET is assigned to each and they must appear in the template together and ordered by VIEWOFFSET.
Image dimensions were moved from template header in ANSI 378-2004 to FINGERPPRINT section in this version of the format, which permits mixing fingerprints from multiple sources in the same template and simplifies transformative applications like template fusion. ANSI 378-2004 also missed the requirement to list FINGERPRINT sections with the same POSITION together in the template. This version of the format introduces new metadata fields QVENDOR and QALGO.
Finger position on hands (POSITION)
An unsigned 8-bit number encoding hand position of the finger. It must be in range 0-10 with meaning of allowed codes explained by the table below.
Finger view number (VIEWOFFSET)
If multiple fingerprints with the same POSITION are present in the template, unique VIEWOFFSET must be assigned to each, starting with zero and incrementing with each view of the same finger. If there is only one fingerprint with given POSITION, its VIEWOFFSET is zero. VIEWOFFSET is an unsigned 8-bit number with allowed range of 0-15, which limits every finger position to 16 finger views. All finger views of one finger must be listed in the template together and ordered by VIEWOFFSET.
This field was expanded from 4 bits in ANSI 378-2004 to a full byte even though its value range didn't change. ANSI 378-2004 also missed the requirement to list fingerprints with the same POSITION together in the template.
Impression type (SAMPLETYPE)
This unsigned 8-bit number indicates how the fingerprint was captured. Contrary to the vendor-defined DEVID, this field is actually useful, because its values are specified. Matching algorithms can use this information to adjust error tolerances and other parameters. Allowed values in range 0-3, 8, 10-11, and 20-29 are described in the table below.
This field was expanded from 4 bits in ANSI 378-2004 to a full byte. List of allowed codes received numerous updates:
- Codes 0-3 for plain and rolled prints were supplemented with new codes 10-11 for palm prints.
- Codes 0-3 have received specialized variants 20-27, which indicate sensor technology (optical or otherwise) and contact vs. contactless scan.
- Code 9 for contactless scans was dropped and replaced with codes 24-27 that specify more detail.
- Fallback values 28 and 29 were added.
- Swipe scans (code 8) were clarified to be vertical.
Code 29 "Unknown" is a reasonable default for implementations that have no knowledge of the source sensor.
Fingerprint quality (FPQUALITY)
An 8-bit unsigned number indicating overall fingerprint quality. Note that there is also a per-minutia quality in the MINQUALITY field. Quality ranges between 0 and 100 with 0 meaning lowest quality and 100 highest quality. Special value 254 stands for unreported quality and 255 for failure to measure quality. Quality should be interpreted according to the value of QALGO field.
Opensource implementations should set this field to 254 unless they use some well-known quality measurement algorithm that can be referenced in QALGO.
Values 254 and 255 are new in this version of the format. ANSI 378-2004 provided no way to indicate missing fingerprint quality. This version of the format also gives clear meaning to fingerprint quality through the QVENDOR and QALGO fields.
Quality algorithm vendor (QVENDOR)
Similar to VENDOR, this is a big-endian 16-bit unsigned number identifying IBIA-registered organization that defined the quality algorithm referenced in QALGO and used to interpret values of FPQUALITY.
IBIA's ridiculous fees apply here too, just like in the VENDOR field, except that it is very rare for opensource implementations to be wishing to register new quality algorithms. It is much more common to reuse one of the published fingerprint quality algorithms or to not report fingerprint quality at all.
When fingerprint quality is unreported (FPQUALITY is 254), this field should be set to 0x0103 "Vendor Unknown" and QALGO to 0x0001 "Product Unknown". When NIST's NFIQ 1.0 is used, this field should be set to NIST's vendor code 0x000f.
Quality algorithm (QALGO)
This is a big-endian 16-bit unsigned number identifying the algorithm used to measure fingerprint quality recorded in the FPQUALITY field. Quality algorithm ID is namespaced under QVENDOR, i.e. each vendor has its own algorithm IDs. Quality algorithm can be optionally registered in IBIA's quality algorithm directory.
QVENDOR registration is hostile to opensource, but opensource implementations can just reuse one of the already defined quality algorithms. Unfortunately, nearly all registered quality algorithms require purchase of an additional specification from ISO. There is however one publicly documented quality algorithm: NIST's NFIQ 1.0, defined in NISTIR 7151, which can be used in this field. NFIQ 1.0 has QVENDOR code 0x000f (NIST) and QALGO code 0x377d. It is however not clear how NFIQ's 5-level scale maps to values in FPQUALITY field that are in range 0-100.
Image width (WIDTH)
Image width in pixels encoded as a big-endian unsigned 16-bit number.
Image height (HEIGHT)
Image height in pixels encoded as a big-endian unsigned 16-bit number.
Horizontal pixel density (RESOLUTIONX)
Image resolution (commonly called DPI), specifically its horizontal component, is stored in this field in units of pixels per centimeter. It is encoded as a non-zero big-endian unsigned 16-bit number. If sensor resolution is fractional, it is rounded to the nearest integer. The common resolution of 500dpi is equal to 197px/cm after rounding.
Vertical pixel density (RESOLUTIONY)
Number of minutiae (MINCOUNT)
An unsigned 8-bit number that indicates the number of MINUTIA records that follow. MINCOUNT may be zero, which means the feature extractor failed to find any minutiae.
Minutiae are interesting points on the fingerprint. While there are many kinds of minutiae, this format only supports ridge endings and bifurcations.
MINUTIA records span 6 bytes each and carry minutia position (MINX, MINY), angle (MINANGLE), type (MINTYPE), and optionally quality (MINQUALITY). Field MINCOUNT contains the number of MINUTIA records present. There could be no MINUTIA records if the feature extractor failed to find any minutiae.
Minutia type (MINTYPE)
Minutia type is packed in the top two bits of the first byte occupied by the MINX field. Three minutia types are supported:
|00||Either ending or bifurcation|
The "either" type (code 00) is for borderline cases when it is not clear whether the minutia is an ending or a bifurcation. Feature extractors should try hard to choose between ending and bifurcation while matchers should work correctly even if all minutiae are of type "either".
Code 00 used to mean implementation-defined "other" minutia type in ANSI 378-2004. It was repurposed as "either" minutia type in this version of the format.
Minutia X position (MINX)
Location of the minutia on the fingerprint in pixel units along X axis. Pixels are counted left-to-right, starting with zero. Minutia is in the center of the pixel specified by MINX and MINY.
MINX is a 14-bit unsigned number that is stored in the lower 14 bits of the big-endian 16-bit number that also contains MINTYPE.
In order to determine minutia position, feature extractor first constructs ridge skeleton by thinning ridges down to one pixel wide lines. Valley skeleton is constructed similarly by thinning valleys. Ridge endings lie at forking points of the valley skeleton. Similarly, ridge bifurcations lie at forking points of the ridge skeleton.
Previous version of this format, ANSI 378-2004, did not constrain minutia leg length. It also allowed implementations to define position for "other" minutia type, which was supported by ANSI 378-2004.
Minutia Y position (MINY)
Like MINX above but for Y axis. Pixels on Y axis are counted top-down, starting with zero. MINY is stored in a 16-bit unsigned big-endian field, but only the lower 14 bits of this field are used for MINY. Upper 2 bits are zero.
Minutia angle (MINANGLE)
In order to keep angle calculations consistent across implementations, the original spec prescribes an algorithm for calculating the minutia angle, which is shown below. The algorithm describes calculation for ridge ending angle using valley skeleton. Bifurcation angle is calculated similarly using ridge skeleton.
- Consider ridge ending minutia positioned at forking point of the valley skeleton as described under MINX field above.
- Valley skeleton lines extending from this forking point are minutia's three legs.
- Pick leg distance measurement method: travel distance or flying distance. The original spec is not clear about which method is right, but it seems simpler and more reliable to measure flying distance. The rest of this algorithm will use flying distance.
- When measuring flying distance, ridge curvature causes several points to have the same flying distance. In these cases, pick the point with shortest travel distance.
- Calculate leg length as distance to the pixel furthest from the minutia.
- If any leg is shorter than 0.51mm, the minutia is not eligible for inclusion in the template. Skip it.
- If any leg is longer than 1.63mm, shorten it to 1.63mm.
- Bisect the angle between two closest legs to determine minutia direction.
- Calculate minutia angle. Zero angle points to the right and angles increase counterclockwise.
MINANGLE is an 8-bit unsigned number in range 0-179. Floating-point angle calculated above is quantized as follows.
- Convert angle units to floating-point degrees in range 0-360.
- Divide the angle by two.
- Round it up to integer value.
- If the result is 180, change it to 0 in order to keep the angle in range 0-179.
MINANGLE can be dequantized by reversing the process and centering the result in angle's quantization slot:
- Multiply the angle by two.
- Subtract one to center the angle in its quantization slot.
- If the result is -1, change it to 359 in order to keep the angle in range 0-360.
Angles for minutiae of type "either" are implementation-defined.
MINANGLE definition has changed significantly since ANSI 378-2004. The algorithm for angle calculation has been switched from inter-skeleton direction to single-skeleton leg bisection algorithm. The new algorithm is more stable and less dependent on feature extractor. The downside is that a single feature extractor cannot support both versions of the format without being informed upfront about which format to target. The new algorithm also requires minutiae to be excluded from the template if they don't have long enough legs.
Minutia quality (MINQUALITY)
An 8-bit unsigned number encoding minutia quality from 0 (lowest quality) to 100 (highest quality). Special value 254 stands for unreported quality and 255 for failure to measure minutia quality. Meaning of minutia quality depends on feature extractor that is identified in the SUBFORMAT field. Opensource implementations should set this field to 254.
Range of quality values has changed from 1-100 in ANSI 378-2004 to 0-100 in this version of the format. Missing quality information is indicated with special values 254 and 255 instead of zero.
Total length of extension data (EXTBYTES)
A big-endian 16-bit unsigned number holding the total size of all extensions in bytes. If EXTBYTES is zero, there are no extension blocks. If it is non-zero, one or more EXTENSION blocks follow. In that case, EXTBYTES is the sum of EXTLEN fields of all EXTENSION blocks.
Extension data block (EXTENSION)
If EXTBYTES is non-zero, one or more EXTENSION blocks are attached to the fingerprint. Every extension has two compulsory fields: EXTTYPE and EXTLEN. EXTLEN lets implementations skip over unrecognized extensions without having to parse them. EXTTYPE informs the implementation about internal structure of the extension, so that appropriate parser can be chosen. Actual extension data is stored in the EXTDATA field.
There are two predefined extensions: ridge count extension (RCOUNTEXT) and core and delta extension (COREDELTA). Extensions are intended to store data that cannot be expressed otherwise. Implementations must not abuse extensions to introduce alternative encoding for data that can be already encoded in documented fields of this format, including the predefined extensions.
Extension type (EXTTYPE)
Two bytes encode extension type according to the table below.
|Byte 1||Byte 2||Description|
|0||1||Ridge count extension (RCOUNTEXT)|
|0||2||Core and delta extension (COREDELTA)|
Implementation-defined extension codes are namespaced under VENDOR code. Since opensource implementations usually don't have assigned vendor ID, they should not include any custom extension blocks.
Length of extension data (EXTLEN)
Length of the whole EXTENSION block, including the EXTTYPE field and EXTLEN field itself, is stored in a big-endian 16-bit unsigned number. EXTLEN must be therefore at least 4. Implementations can use this field to skip over unrecognized extensions.
Extension data (EXTDATA)
Actual extension data. This field has length of EXTLEN minus the 4 bytes needed for EXTTYPE and EXTLEN. Internal structure of the EXTDATA field depends on the value of EXTTYPE field. This format specifies only structure of ridge count extension (RCOUNTEXT) and core and delta extension (COREDELTA).
Ridge count extension (RCOUNTEXT)
Minutia set defined in MINUTIA records can be annotated with ridge counts. Ridges are counted on a line (or edge) connecting two minutiae. Edge's ridge count is the number of ridges crossed by the edge plus one as precisely defined in RIDGECOUNT field. RCOUNTEXT extension encodes this ridge count data. RCOUNTEXT has EXTTYPE of 0x0001.
Not all edges in the template need to have ridge count data.
Edge picking method is specified in STARTYPE field.
Information about every picked edge is then stored in EDGEDEF records that follow.
The number of EDGEDEF records can be derived from the length of this extension block (EXTLEN)
(EXTLEN - 5) / 3.
Ordering of EDGEDEF records depends on STARTYPE.
Value of the RIDGECOUNT field is higher by one compared to ANSI 378-2004. RIDGECOUNT thus cannot be zero for valid edges, which disambiguates placeholder records (see below) that set RIDGECOUNT to zero.
Edge picking method (STARTYPE)
This template format recognizes three edge picking methods: quadrants, octants, and custom. STARTYPE field contains an 8-bit unsigned code according to the table below.
Custom edge picking (code 0) simply means the implementation is free to choose edges however it wants. It can also choose how to order EDGEDEF records.
Quadrant (code 1) and octant (code 2) edge picking involves splitting the area around central minutia into four or eight sectors respectively. Quadrants and octants are aligned to minutia's direction (MINANGLE) differently. For quadrants, minutia's direction lies between two quadrants. For octants, minutia's direction bisects some octant. For every sector, ridge count is recorded for the edge to the nearest minutia in that sector. Quadrant and octant picking places strict requirements on presence, ordering, and contents of EDGEDEF records as explained below.
Quadrant and octant alignment to minutia direction was added in this version of the format. ANSI 378-2004 didn't specify it.
Edge between minutiae (EDGEDEF)
The 3-byte EDGEDEF record contains ridge count (stored in RIDGECOUNT field)
for a single edge between minutiae identified by EDGEFROM and EDGETO fields.
The number of EDGEDEF records is derived from EXTLEN as
(EXTLEN - 5) / 3.
Field STARTYPE determines which edges are present. If STARTYPE is quadrants (code 1) or octants (code 2), every minutia in the template is considered as central minutia and ridge counts to its neighbors are recorded. If STARTYPE is custom (code 0), implementation is free to choose which edges to include and some minutiae might have no edges recorded.
EDGEDEF record ordering depends on STARTYPE:
- If STARTYPE is custom (code 0), EDGEDEF records are ordered first by EDGEFROM and then by EDGETO.
- If STARTYPE is set to quadrants (code 1) or octants (code 2), EDGEDEF records for single central minutia are listed together. There are no other ordering constraints for neither central nor neighbor minutiae.
If STARTYPE is set to quadrants (code 1) or octants (code 2), the structure of EDGEDEF records is defined in more detail. EDGEFROM identifies the central minutia while EDGETO identifies the neighbor minutia. If some quadrant or octant does not have any minutiae, implementation must emit a placeholder record with EDGETO and RIDGECOUNT fields zeroed, thus padding edge list for every central minutia to four or eight records respectively.
Note that the original spec is unclear about the ordering of edges in ridge count extension. For maximum compatibility, template encoders should sort everything by EDGEFROM and then by EDGETO while decoders should accept arbitrary ordering.
ANSI 378-2004 was ambiguous as to whether every minutia should be considered as central minutia when STARTYPE is set to quadrants (code 1) or octants (code 2). This version of the format clarifies that all minutiae are indeed considered as central minutiae and their ridge counts are recorded.
Starting minutia of the edge (EDGEFROM)
An 8-bit unsigned offset into the list of MINUTIA records. It identifies minutia that is on one end of the edge leading to EDGETO. If STARTYPE is quadrants (code 1) or octants (code 2), EDGEFROM is the central minutia.
Ending minutia of the edge (EDGETO)
An 8-bit unsigned offset into the list of MINUTIA records. It identifies minutia that is on the other end of the edge starting in EDGEFROM. If STARTYPE is quadrants (code 1) or octants (code 2), EDGETO is the neighbor minutia. If the current EDGEDEF record is a placeholder for quadrant or octant devoid of minutiae, EDGETO is zero.
Number of ridges the edge crosses (RIDGECOUNT)
In order to count ridges, implementation must first construct ridge and valley skeletons by thinning ridges and valleys to a single pixel wide line. Ridge is crossed when it is crossed in the ridge skeleton, not when it is merely "touched" in the fingerprint image, i.e. the edge must pass through the center of the ridge. Edge can cross curved ridges more than once, but single ridge is still counted only once with the following exception. If the ridge is curved so severely that the edge passes through valley skeleton line between two crossings of the same ridge, then the second ridge crossing is counted too.
If the current EDGEDEF record is a placeholder for quadrant or octant devoid of minutiae, RIDGECOUNT is zero, which is otherwise an invalid value.
Value of this field is higher by one compared to ANSI 378-2004. RIDGECOUNT thus cannot be zero for valid edges, which disambiguates placeholder records that set RIDGECOUNT to zero. This version of the format also clarifies what counts as ridge crossing.
Core and delta extension (COREDELTA)
Besides normal minutiae defined in MINUTIA records, this format permits encoding of cores and deltas, which can be thought of as very special minutiae. COREDELTA extension encodes information about cores and deltas found on the fingerprint. COREDELTA extension has EXTTYPE of 0x0002. COREDELTA extension has two parts: COREDATA and DELTADATA.
Cores and deltas are identified by analyzing the flow of ridges. Core is the focal point of the innermost curved ridge. This definition works well for all basic core types: circular whorl, elongated whorl (one core on each side), loop, and tented arch. For plain arch, core is at the focal point of the ridge with highest curvature. Delta is recognized where three distinct ridge flows meet and the delta point doesn't clearly belong to any of them. Fingerprints may contain a combination of cores and deltas that forms one of the many combined patterns.
Previous version of this format, ANSI 378-2004, didn't define cores nor deltas. This version provides more detail, but some ambiguity remains.
Core data (COREDATA)
COREDATA, the first part of COREDELTA extension, contains a list of cores found on the fingerprint. See COREDELTA for definition of a core. Every core is defined in a COREDEF record. Number of cores is specified by CORENUM field. Presence or absence of COREANGLE field is indicated by CHASANGLE flag.
Core angle presence flag (CHASANGLE)
Number of cores (CORENUM)
Previous version of this format, ANSI 378-2004, required non-zero core count.
Core point (COREDEF)
COREDEF describes one core found on the fingerprint. COREDEF record repeats CORENUM times. Its structure is somewhat similar to MINUTIA record. Every core has position (COREX, COREY). If CHASANGLE is set, every COREDEF also contains COREANGLE.
Core X position (COREX)
Equivalent of MINX for cores. Core is the focal point of the innermost curved ridge. Except for arch that has core at the focal point of the ridge with highest curvature.
Previous version of this format, ANSI 378-2004, didn't specify where exactly is core located.
Core Y position (COREY)
Core angle (COREANGLE)
- Circular whorl has no angle. CHASANGLE must be cleared.
- Elongated whorl's angle is the angle of the line connecting its two cores. If this angle is higher than 180 degrees, then it is lowered by 180 degrees. This transformation ensures that both cores of the elongated whorl have the same angle.
- Loop's angle is calculated as follows. Two arms of the innermost ridge around the core are identified. Point on each arm that is 0.064 inches away from the core is identified. Rays originating in the core and passing through these two points are bisected to determine loop's angle.
- Tented arch angle is calculated similarly to loop angle.
- Plain arch angle is calculated similarly to loop angle, but ridge with highest curvature is used instead of the innermost ridge.
Previous version of this format, ANSI 378-2004, didn't specify what should be recorded in this field.
Delta data (DELTADATA)
DELTADATA, the second and last part of COREDELTA extension, contains a list of deltas found on the fingerprint. See COREDELTA for definition of a delta. Every delta is defined in a DELTADEF record. Number of deltas is specified by DELTANUM field. Presence or absence of DELTAANGLE fields is indicated by DHASANGLE flag.
Delta angle presence flag (DHASANGLE)
This 1-bit field occupies bit 6 (lowest bit has number 0, highest 7) of the byte it shares with DELTANUM field. If it is set, three repeats of the DELTAANGLE field are present. If it is zero, no DELTAANGLE is recorded.
Number of deltas (DELTANUM)
Delta point (DELTADEF)
DELTADEF describes one delta found on the fingerprint. DELTADEF record repeats DELTANUM times. Its structure is somewhat similar to MINUTIA record. Every delta has position (DELTAX, DELTAY). If DHASANGLE is set, every DELTADEF also contains three repeats of the DELTAANGLE field.
Delta X position (DELTAX)
Equivalent of MINX for deltas. The three ridge flows forming the delta meet in three directions, which can be thought of as three rays coming from the delta. Delta is located at the intersection of these three rays.
Previous version of this format, ANSI 378-2004, didn't specify where exactly is delta located.
Delta Y position (DELTAY)
Delta angle (DELTAANGLE)
This field is present three times if DHASANGLE flag is set and zero times otherwise. The field contains an angle encoded in the same way as MINANGLE, but its meaning is different. Delta angles correspond to the three rays that separate the three ridge flows forming the delta. The three delta angles are sorted counterclockwise starting with the angle that is closest to 90 degrees.
Previous version of this format, ANSI 378-2004, didn't specify what should be recorded in this field.