ANSI INCITS 378:2009/AM 1:2010[R2015] Summary
This is a complete description of fingerprint template format defined in ANSI INCITS 378:2009/AM 1:2010[R2015] spec, often abbreviated as ANSI 378-2009/AM1 or just Amendment 1 or ambiguously ANSI 378-2009 or 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/AM 1:2010[R2015]. There is no guarantee though and you should consult the original ANSI INCITS 378:2009/AM 1:2010[R2015] 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/AM 1:2010[R2015]. 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.
Introduction
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/AM1 is one of several fingerprint template formats that can be used for this purpose.
ANSI 378-2009/AM1 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.
Related formats
This template format is a small incremental backwards-compatible update to ANSI 378-2009. Versions of this format can be differentiated by looking at the VERSION field, which is "035\0" for ANSI 378-2009/AM1 and "030\0" for ANSI 378-2009.
When embedded in CBEFF (Common Biometric Exchange Framework Format, INCITS 398-2008), CBEFF Format Type should be set to 0x203, which is registered by INCITS. The 2004 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 initial 2004 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
Changes made to the format since the last version (ANSI 378-2009) are listed below:
- VERSION field was changed from "030\0" to "035\0".
- At least one fingerprint must be present. FPCOUNT must be non-zero.
- Fingerprint count (FPCOUNT) can be up to 255.
- Field POSITION may contain additional values for multi-finger prints.
- Ridge count extension doesn't have to use every minutia as the center minutia in ridge count data. It can use any subset of minutiae as center minutiae in ridge count data.
Layout
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:
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:2005 uses the same magic number.
Format version (VERSION)
Version field contains 4-byte constant string "035\0" where '\0' stands for zero byte. Other versions of this format use different version string, which makes it easy to distinguish the versions.
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 40 bytes is invalid, because at least one fingerprint must be present.
Minimum value of TOTALBYTES has changed since ANSI 378-2009 where it was 21, because templates without any fingerprints are invalid in this version.
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.
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.
Number of fingerprints (FPCOUNT)
An unsigned 8-bit number that indicates the number of FINGERPRINT blocks in the template. FPCOUNT cannot be zero. There must be at least one fingerprint in the template.
This field's allowed value range has changed since ANSI 378-2009 from 0-176 to 1-255. This is because of expanded value range for POSITION field and also due to disallowing of empty, fingerprint-less templates.
Fingerprint (FINGERPRINT)
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. At least one fingerprint must be present in the template. This is a change since ANSI 378-2009, which allowed templates with no fingerprints.
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.
Finger position on hands (POSITION)
An unsigned 8-bit number encoding hand position of the finger. It must be in range 0-10, 13-15, or 40-50 with meaning of allowed codes explained by the two tables below.
| Code | Hand | Finger |
|---|---|---|
| 0 | Unknown | Unknown |
| 1 | Right | Thumb |
| 2 | Right | Index |
| 3 | Right | Middle |
| 4 | Right | Ring |
| 5 | Right | Little |
| 6 | Left | Thumb |
| 7 | Left | Index |
| 8 | Left | Middle |
| 9 | Left | Ring |
| 10 | Left | Little |
Codes in the table below are an addition defined by this version of the format. They were not present in ANSI 378-2009.
| Code | Count | Combination |
|---|---|---|
| 13 | 4 | Right index, middle, ring, and little |
| 14 | 4 | Left index, middle, ring, and little |
| 15 | 2 | Left and right thumbs |
| 40 | 2 | Right index and middle |
| 41 | 2 | Right middle and ring |
| 42 | 2 | Right ring and little |
| 43 | 2 | Left index and middle |
| 44 | 2 | Left middle and ring |
| 45 | 2 | Left ring and little |
| 46 | 2 | Left and right index |
| 47 | 3 | Right index, middle, and ring |
| 48 | 3 | Right middle, ring, and little |
| 49 | 3 | Left index, middle, and ring |
| 50 | 3 | Left middle, ring, and little |
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.
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.
| Code | Liveness | Technology | Contact | Size |
|---|---|---|---|---|
| 0 | Live | Plain | ||
| 1 | Live | Rolled | ||
| 2 | Non-live | Plain | ||
| 3 | Non-live | Rolled | ||
| 8 | Live | Swipe (vertical) | ||
| 10 | Live | Palm | ||
| 11 | Non-live | Palm | ||
| 20 | Live | Optical | Contact | Plain |
| 21 | Live | Optical | Contact | Rolled |
| 22 | Live | Non-optical | Contact | Plain |
| 23 | Live | Non-optical | Contact | Rolled |
| 24 | Live | Optical | Contactless | Plain |
| 25 | Live | Optical | Contactless | Rolled |
| 26 | Live | Non-optical | Contactless | Plain |
| 27 | Live | Non-optical | Contactless | Rolled |
| 28 | Other | |||
| 29 | Unknown | |||
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.
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.
Implementations wishing to avoid reporting of fingerprint quality can set FPQUALITY to 254, QVENDOR to 0x0103 "Vendor Unknown" and QALGO to 0x0001 "Product Unknown".
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)
Like RESOLUTIONX above but for vertical resolution. It's usually equal to RESOLUTIONX.
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.
Minutia (MINUTIA)
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:
| Bits | Type |
|---|---|
| 01 | Ridge ending |
| 10 | Ridge bifurcation |
| 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".
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. Minutia can be included in the template only if all legs used to calculate MINANGLE are at least 0.51mm long.
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.
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.
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 | 0 | Reserved |
| 0 | 1 | Ridge count extension (RCOUNTEXT) |
| 0 | 2 | Core and delta extension (COREDELTA) |
| 0 | 3-255 | Reserved |
| 1-255 | 0 | Reserved |
| 1-255 | 1-255 | Implementation-defined extension |
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)
using expression (EXTLEN - 5) / 3.
Ordering of EDGEDEF records depends on STARTYPE.
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.
| Code | Method |
|---|---|
| 0 | Custom |
| 1 | Quadrants |
| 2 | Octants |
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.
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), implementation picks a subset of minutiae that are considered as central minutiae and records ridge counts to their neighbors. 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.
This version of the format allows recording ridge count information for a subset of all minutiae. ANSI 378-2009 required ridge count data to be recorded for all minutiae.
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)
An 8-bit unsigned number containing the number of ridges crossed by the edge plus one. Ridge count does not include ridges connected to either EDGEFROM or EDGETO minutiae.
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.
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.
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)
This 1-bit field occupies bit 6 (lowest bit has number 0, highest 7) of the byte it shares with CORENUM field. If it is set, COREANGLE field is present. If it is zero, COREANGLE is not recorded.
Number of cores (CORENUM)
A 4-bit unsigned number that occupies the lowest 4 bits of the byte it shares with CHASANGLE field. CORENUM contains the number of COREDEF records in the COREDELTA extension.
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.
Core Y position (COREY)
Core angle (COREANGLE)
This field is present only if the CHASANGLE flag is set. It contains an angle encoded in the same way as MINANGLE, but its meaning is different. Core angle depends on pattern type:
- 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.
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)
A 4-bit unsigned number that occupies the lowest 4 bits of the byte it shares with DHASANGLE field. DELTANUM contains the number of DELTADEF records in the COREDELTA extension.
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.
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.