NISTIR 7791
 

Conformance Test Architecture and 

Test Suite for ANSI/NIST-ITL 1-2007
 

Fernando L. Podio 

Dylan Yaga 

Christofer J. McGinnis 
NISTIR 7791
 

Conformance Test Architecture and 

Test Suite for ANSI/NIST-ITL 1-2007
 

Fernando L. Podio 

Dylan Yaga 

Christofer J. McGinnis 

June 2011 

. 

U.S. Department of Commerce 

Gary Locke, Secretary 

National Institute of Standards and Technology 

Patrick D. Gallagher, Director 
Reports on Computer Systems Technology 

The Information Technology Laboratory (ITL) at the National Institute of Standards and Technology 

(NIST) promotes the U.S. economy and public welfare by providing technical leadership for the 

Nation’s measurement and standards infrastructure. ITL develops tests, test methods, reference data, 

proof of concept implementations, and technical analysis to advance the development and productive 

use of information technology. ITL’s responsibilities include the development of technical, physical, 

administrative, and management standards and guidelines for the cost-effective security and privacy 

of sensitive unclassified information in Federal computer systems. This Interagency Report 

discusses ITL’s research, guidance, and outreach efforts in computer security, and its collaborative 

activities with industry, government, and academic organizations. 

National Institute of Standards and Technology Interagency Report 

76 pages (2011) 

Certain commercial entities, equipment, or materials may be identified in 

this document in order to describe an experimental procedure or concept 

adequately. Such identification is not intended to imply recommendation 

or endorsement by the National Institute of Standards and Technology, nor 

is it intended to imply that the entities, materials, or equipment are 

necessarily the best available for the purpose. 

iii 
Abstract 

The Computer Security Division of NIST/ITL supports the development of biometric conformance 

testing methodology standards and other conformity assessment efforts through active technical 

participation in the development of these standards and the associated conformance test architectures 

and test suites. The ANSI/NIST-ITL standard "Data Format for the Interchange of Fingerprint, Facial 

& Other Biometric Information" is used by law enforcement, intelligence, military, and homeland 

security organizations throughout the world. The current version specified in its Traditional Format, 

is Part 1: ANSI/NIST-ITL 1-2007. Although a revised and augmented version of the standard is 

under development, the 2007 version is still widely used. The Conformance Test Architecture and 

Test Suite described in this publication are designed to test implementations of ANSI/NIST ITL 1­

2007. The code (Beta 0.4) is currently designed to support testing of selected record types of the 

standard but can be extended to support other record types as required. A high-level overview of the 

architecture and test suite as well as software details and the code structure are provided. A quick 

start user guide and a comprehensive table of the standard’s requirements and the associated 

implemented conformance test assertions (over five-hundred and thirty) are included. 

Disclaimer 

Statements made in this paper should not be interpreted as standards, guidelines, best practices, or 

recommendations for specific changes to any other NIST publications. 

Acknowledgment 

The authors would like to acknowledge Mark Jerde from ID Technology Partners (NIST contractor 

for this project) as the principal software developer of the Conformance Test Architecture/Test Suite 

addressed in this publication. 

Sponsor 

The work described in this document was sponsored by The Department of Homeland Security/USVISIT Program. 

Feedback 

The Conformance Test Architecture (CTA)/Test Suite (CTS), sample data and documentation can be 

downloaded from the following web site: 

http://www.nist.gov/itl/csd/biometrics/biocta_download.cfm. 

Feedback on the CTA/CTS, the sample data and documentation are welcome. Please send comments 

to csdbiomcta@nist.gov. 

iv 
Table of Contents 

1 Introduction.................................................................................................................... 1
 

1.1 Background............................................................................................................... 1
 

1.2 Need for Conformance Testing to Biometric Standards ........................................... 1
 

1.3 Support for the ANSI/NIST- ITL 1-2007 Standard .................................................... 2
 

1.4 Requirements in the Standard and Conformance Test Assertions .......................... 2
 

1.5 Hierarchy of Conformance Tests .............................................................................. 3
 

1.6 Target Audience ....................................................................................................... 4
 

2 CTA/CTS Overview ........................................................................................................ 5
 

2.1 High-Level Architecture ............................................................................................ 5
 

2.2 Software Details........................................................................................................ 6
 

3 Quick Start...................................................................................................................... 7
 

3.1 Installation................................................................................................................. 7
 

3.2 Loading and Running Implementations .................................................................... 8
 

4 Test Results ................................................................................................................. 10
 

4.1 Overall Results........................................................................................................ 10
 

4.2 Detailed Results...................................................................................................... 10
 

Annex A - Code Structure .................................................................................................. 16
 

Annex B - References ........................................................................................................ 19
 

Annex C - Standard Requirements and Conformance Test Assertions ....................... 20
 

List of Figures and Tables 

Figure 2-1: CTA/CTS High-Level Architecture ................................................................... 5
 

Figure 3-1: CTA/CTS Welcome ............................................................................................ 7
 

Figure 3-2: ANSI/NIST-ITL 1-2007 Test Window ................................................................ 8
 

Figure 4-1: Pass/Fail Results ............................................................................................. 10
 

Figure 4-2: ANSI/NIST-ITL 1-2007 Detailed Results ........................................................ 11
 

Figure 4-3: Output Options ................................................................................................ 11
 

Figure 4-4: Header Sample ................................................................................................ 12
 

Figure 4-5: TOC Sample..................................................................................................... 12
 

Figure 4-6: Type Selection Menu ...................................................................................... 12
 

v 
Figure 4-7: Type Selection Menu ...................................................................................... 13
 

Figure 4-8: Field-Level Parse Test Sample ...................................................................... 13
 

Figure 4-9: L1, L2 Tests Sample........................................................................................ 14
 

Figure 4-10: File-Level Results Sample ............................................................................ 14
 

Figure 4-11: Record-Level Results Sample...................................................................... 14
 

Figure 4-12: Field-Level Results Sample.......................................................................... 15
 

Figure 4-13: Fields Option Not Selected .......................................................................... 15
 

Figure A-1: Class Diagram for the An107 File Class ....................................................... 17
 

Figure A-2: Class Diagram for the Data Types ................................................................ 18
 

Table C-1 – Operators Use in Table C-4 Test Assertions ............................................... 20
 

Table C-2 - Description of the Operands Used in Table C-4 Test Assertions .............. 21
 

Table C-3 Terms Used in Table C-4 Test Assertions ...................................................... 22
 

Table C-4 - Requirements and Conformance Test Assertions ...................................... 23
 

vi 
 

1 Introduction 

1.1 Background 

The ANSI/NIST-ITL standard "Data Format for the Interchange of Fingerprint, Facial & Other 

Biometric Information" is used by law enforcement, intelligence, military, and homeland security 

organizations throughout the world. The first version of the standard dates to 1986. Over the years, 

it has been updated and expanded to cover more biometric modalities beyond the original record type 

of fingerprint minutiae. Current modalities are: 

• Fingerprint minutiae 

• Fingerprint image (flat/plain, rolled and latent) 

• Scars, marks and tattoos 

• Facial image 

• Iris image 

• Palmprint image 

The current version of the ANSI/NIST-ITL standard is: 

Part 1 – (ANSI/NIST-ITL 1-2007) in Traditional Format [1]
 

Part 2 – (ANSI/NIST-ITL 2-2008) in NIEM-conformant XML format [2] 

In addition, there is an extension to the table of finger position codes in both parts of the standard to 

handle multiple-finger captures: ANSI/NIST-ITL 1a-2009 [3].
 

The standard is now in the process of being revised. A workshop was held July 27-29, 2010 at NIST 

to determine what new biometric modalities and associated data should be included in a new version 

of the standard. Working groups established at this workshop provided input for the updated 

standard. Two drafts were developed (the first draft incorporated the output of the working groups). 

The second draft incorporated changes based on comments received after the first draft was issued. 

A second workshop, to discuss this draft was held on March 1-3, 2011 at NIST in Gaithersburg, 

MD., USA. A third draft was developed after the second workshop. At the time of this writing a 

new draft (fourth draft) was made available for review and comment. The fourth draft can be 

downloaded from the ANSI/NIST-ITL Standard Homepage [4].
 

1.2 Need for Conformance Testing to Biometric Standards 

The existence of biometric standards alone is not enough to demonstrate that products meet the 

technical requirements specified in the standards. Conformance testing captures the technical 

description of a specification and measures whether an implementation faithfully implements the 

specification. The Computer Security Division (CSD) of NIST/ITL supports the development of 

biometric conformance testing methodology standards and other conformity assessment efforts 

through active technical participation in the development of biometric standards and the development 

of associated conformance test architectures and test suites. NIST/ITL CSD develops these 

conformance test tools to support users that require conformance to selected biometric standards and 

to also support product developers interested in conforming to biometric standards by using the same 

testing tools available to users. These efforts support the possible establishment of conformity 

1 
 

 

assessment programs to validate conformance to biometric standards. Conformance testing provides 

developers, users, and purchasers with increased levels of confidence in product quality and increases 

the probability of successful interoperability. A Conformance Test Architecture (CTA) as well as 

Conformance Test Suites (CTS) designed to test implementations of selected biometric data 

interchange formats developed by Technical Committee M1- Biometrics [5] of the InterNational 

Committee for Information Technology Standards (INCITS) and Subcommittee 37 (SC 37) – 

Biometrics of the Joint Technical Committee 1 (JTC 1) of ISO and IEC [6] are available for 

download at a NIST/ITL CSD web page [7]. 

1.3 Support for the ANSI/NIST- ITL 1-2007 Standard 

Although a revised and augmented version of the standard is under development, the 2007 version is 

still widely used. NIST/ITL CSD developed a CTA/CTS (Beta version 0.4) designed to test 

implementations of selected Record Types of ANSI/NIST-ITL 1-2007, Data Format for the 

Interchange of Fingerprint, Facial, & Other Biometric Information – Part 1. These Record Types 

were considered the first-priority tier. In addition to testing Record Type 1, “Transaction 

Information Record”, the selected records supported by the CTA/CTS are: 

• Type 4, High-resolution grayscale fingerprint image 

• Type 10, Facial and SMT image 

• Type 13, Variable-resolution latent image 

• Type 14, Variable-resolution fingerprint image 

• Type 17, Iris image 

Over five-hundred and thirty test assertions were implemented. The software code can be extended 

to support other record types as required. The tool is designed to detail a transaction’s level of 

conformance to the standard. The granularity of the output information in the test results is provided 

in section 4. The CTA/CTS can also be used as an analysis tool for determining which parts of the 

transaction (e.g., non-conformant fields, records) do not conform to the standard and to analyze the 

reason for their nonconformance. For unsupported Record Types only the length of the record is 

reported during testing, and no determination of conformance is made for these records. In addition 

to stating whether a file passes or fails, the messages provided include warnings and notes. 

1.4 Requirements in the Standard and Conformance Test Assertions 

The CTA/CTS code implements the assertions required to test all of the mandatory, conditional and 

optional requirements for Record Type 1 and the other supported Record Types1

. One or more 

assertions are required to adequately test conformance for a given requirement. Section 1.5, below, 

briefly describes Levels 1, 2 and 3 test assertions; more detail is available in the standards identified 

in the footnote 22

. In addition to parsing tests which are initially performed, over five-hundred Level 

1 Although the standard specifies the Record Type fields as either being Mandatory or Optional, many of the Optional fields are 

conditional to the content of other fields/requirements. 

2

 The concepts addressed in sections 1.4 and 1.5 are based on definitions and discussions included in the following standards: 

ISO/IEC 29109-1:2009, Conformance testing methodology for biometric data interchange formats defined in ISO/IEC 19794 – 

Biometric Data Format Standard - Part 1: Generalized conformance testing methodology and the 7th draft of Conformance testing 

methodology for ANSI/NIST- ITL 1- 2011 developed by the ANSI/NIST-ITL Conformance Working Group, February 22, 2011. 

2 
 

 

1 and 2 assertions were implemented in the code. The assertions also apply to a particular scope, 

with the scope being “File”, “Record” or “Field.”. Level 3 assertions were not implemented. 

Table C-3 of Appendix C documents the requirements and test assertions for the selected Record 

Types. Requirements in the standard that are not tested in the current CTA/CTS release version 

(Beta Version 0.4) are noted in the table. They include: (a) requirements related to International 

Character Sets; (b) image-based requirements where the image metadata required to implement the 

assertion is not defined in the image standard; and (c) four assertions related to the alternate finger 

segment position(s) (ASEG) specified in field 14.025. The required algorithms to implement these 

assertions are under research. 

1.5 Hierarchy of Conformance Tests 

Three levels of conformance testing are defined below: 

Level 1 – Checking internal content 

In Level 1 testing, an ANSI/NIST-ITL 1-2007 transaction(s) is checked for field-by-field, subfieldby-subfield and information item–by information item conformance with the specification of the 

standard, both in terms of ranges, character types, and cardinality. Since Level 1 testing can be 

performed by a simple field-by-field, subfield-by-subfield and information item–by information item 

reading of the standard and comparison to known values, and their encoding, performing this level of 

conformance testing only requires a transaction or a set of ANSI/NIST transactions (as opposed to a 

computer algorithm or a set of hardware and software). Therefore, any hardware or software 

components of the implementation being tested do not have to come into the possession of the testing 

lab. Only ANSI/NIST-ITL 1-2007 transactions created with those components need to be available. 

Level 2 – Internal consistency checking 

In Level 2 testing, an ANSI/NIST-ITL 1-2007 transaction(s) is checked to determine if it is internally 

consistent. This is achieved by relating values from one or more fields, subfields, or information 

items within a transaction to other values within the same transaction. Level 2 tests involve 

interactions between multiple values from different parts of the ANSI/NIST-ITL 1-2007 standard and 

sometimes from implicit assumptions that are not explicitly stated in the base standard. Thus, Level 2 

tests require more complex validation than Level 1. Similar to Level 1 testing, Level 2 conformance 

testing only requires an ANSI/NIST-ITL 1-2007 transaction(s). To ensure that all (or almost all) 

possible internal consistency checks are tested, tests are performed whenever possible with a large 

number of transactions representing as many as possible different structural variants. 

Level 3 – Content checking 

A Level 3 test is intended to test whether an ANSI/NIST-ITL 1-2007 transaction under test is a 

faithful representation of the original biometric data and that it satisfies those requirements of the 

standard that are not simply a matter of syntax and format. This level of conformance testing for 

some requirements might be significantly difficult or even impossible to test. 

3 
 

1.6 Target Audience 

Although this publication is written for users of the Architecture/Conformance Test Suite, technical 

details of the architecture, operations, and the code structure are provided for more technicallyinclined readers. 

4 
 

 

AN2007 Module 

2 CTA/CTS Overview 

2.1 High-Level Architecture 

The high-level architecture implemented for the CTA/CTS can be described using four key 

components. As depicted in Figure 2-1, each of these components addresses different testing levels. 

These components are identified as Pre-Parse testing and Field, Record and File-level testing. 

AN2007 

File Pre-Parsing Record-Level 

Testing 

Structure 

Discovery/Field 

Testing 

File-Level 

Testing 

Field 

definitions 

(XML) 

Test 

Report 

Figure 2-1: CTA/CTS High-Level Architecture 

Pre-Parsing Operations 

This operation verifies that the file exists (e.g., it’s not NULL) and that the proper arguments are sent 

to the software. In addition, the file is opened and tests are performed to verify that the first two 

characters in the file are “1.” since every ANSI/NIST-ITL 1-2007 transaction must start with Record 

Type 1. 

Structure Discovery/Field Testing 

During structure discovery, the Table of Contents (TOC) in Record Type 1 is read and the file is 

parsed based on the TOC. As the software parses the file, it builds an array containing all fields that 

are found in each of the records in the transaction. Level 1 testing is then performed for these fields, 

using the Field definitions (XML file) shown in Figure 2-1. The field definitions file includes 

metadata on each field such as: 

• Type/fields number 

• Length min and max 

• Min and max occurrences 

• Required Level 1 tests 

5 
Level 1 test messages (errors, warning, notes, etc.) are maintained with the corresponding fields 

within the structure data in memory. 

Once this operation is performed and the structure is built, record-level testing is ready to be 

performed as detailed below. The structure discovery module is designed to allow the parsing 

method to change based on the type of data present (e.g., binary, ASCII, ASCII/binary). This 

flexible approach allows also for future revisions of the test tool to allow additional data types to be 

parsed. The structure discovery/fields testing module includes information on all Level 1 assertions, 

messages, and message types that will be included in a test report. 

Record-Level Testing 

In this module, initial Level 2 tests are performed such as: 

• Does the record length equal the number of bytes read? 

• Are the correct Record types included in each record? 

• For each record, is field 1 first, field 2 second and field 999 last? 

Final record Level 2 tests are performed such as checking whether all mandatory and conditional 

fields are present and whether the field occurrences are correct. 

File-Level Testing 

Level 2 tests that include fields of more than one record are performed within this module, such as 

the requirements associated with the Image Designation Character (IDC) values for each record. 

2.2 Software Details 

The code is developed in C# under the Microsoft® .NET 4.0 Framework. The code structure uses 

interfaces that allow the CTS to treat every Record Type in the same manner while testing. This 

allows the high-level structure in the code that pertains to all Record Types to be expanded to other 

Record Types (not supported in this CTA/CTS version) without having redundant code for this level 

of testing. Derived classes from these interfaces can implement specific tests required for each 

supported Record Type. Annex A provides a description and class diagram for the code structure, 

and is oriented towards readers interested in technical details of the code structure. 

6 
3 Quick Start 

3.1 Installation 

Run the installation program NIST ITL CSD CTA Beta 0.4.exe, and follow the on 

screen prompts. The CTA/CTS runs in a Windows environment. It is developed under .NET 

v 4.0. 

After installation, the loaded application should resemble the image below: 

Figure 3-1: CTA/CTS Welcome 

7 
3.2 Loading and Running Implementations 

The “ANSI/NIST-ITL 1-2007” tab must be selected before files can be loaded. An image 

of the test window is shown in Figure 3-2. 

Figure 3-2: ANSI/NIST-ITL 1-2007 Test Window 

Loading Files 

There are two options for loading files: 

1.	 Click the “AN1” button to specify the file path. If this option is used, the 

selected files will be loaded but the tests will not run until the “Run” button is 

selected. 

2.	 Drag and drop one or many files into the window. If this method is chosen, the tests 

will automatically run and display as passed or failed. 

8 
 

 

If necessary, click the “C” (Clear) button to remove the loaded files. 

Running Tests 

Click the “Run” button to run the tests. The files loaded in the window will display as 

passed or failed, indicated by a green or red circle respectively. 

Sample Data Location 

The sample data is available from the following locations for these versions of Microsoft® 

Windows®: 

•	 XP: C:\Documents and Settings\All Users\Documents\ ANSI NIST-ITL 1-2007 

Sample Files 

•	 Vista: C:\Users\Public\Documents\ANSI NIST-ITL 1-2007 Sample Files 

•	 7: C:\Users\Public\Documents\ANSI NIST-ITL 1-2007 Sample Files 

9 
4 Test Results 

To generate the test results, specify the file path using the “AN1” button and click the “Run” 

button to run the tests. Alternatively, drag and drop the files into the GUI and the tests will 

run automatically. 

4.1 Overall Results 

After running the tests using one of the methods mentioned previously, the overall pass/fail 

results of the tests will be displayed in the “ANSI/NIST-ITL 1-2007” window. An example 

of the pass/fail results is shown below, with red (darker) circles representing failures and 

green circles representing successes. 

Figure 4-1: Pass/Fail Results 

The complete file path to the implementation is also listed for reference. In addition to these 

overall results, a detailed summary is also displayed in a separate window. The detailed 

summary is discussed in the next section. 

4.2 Detailed Results 

The detailed results are displayed in a new window titled “ANSI/NIST-ITL 1-2007”, with the 

tab titled “Full”. The contents of this window are defined by the “Output Options” that are 

selected before running the tests. These options may also be selected after running the tests 

to update the detailed results dynamically. The image below depicts the detailed summary 

window with sample results. 

10 
Figure 4-2: ANSI/NIST-ITL 1-2007 Detailed Results 

The “Save” button, shown in Figure 4-2 below the “ANSI/NIST-ITL 1-2007” tile bar, may 

be clicked to save the test results to a text file. After clicking the “Save” button, a Windows 

Explorer browser window will open to allow a file location and name to be selected. 

Output Options 

On the “ANSI/NIST-ITL 1-2007” tab depicted in Figure 3-2, several options are available for 

formatting the test results detailed output as shown in Figure 4-3 below. 

Figure 4-3: Output Options 

11 
 

• Header 

The “Header” option displays general information about the implementation including the 

pass/fail status and the file path. A sample header is shown below for a passing 

implementation. 

Figure 4-4: Header Sample 

• TOC 

The “TOC” option displays a table of contents describing all of the content for a given 

implementation, including Type, IDC, Offset, and Length. The number preceding each line 

in the TOC (such as #01 shown in Figure 4-5) is an identifier assigned to each record found 

inside of the file as it is sequentially parsed. This identifier clarifies the ordering of record 

types found within each file. 

Figure 4-5: TOC Sample 

• Type Selection 

The type selection window allows the user to select which Record Types should be 

displayed, including Record Types 1, 4, 10, 13, 14, and 17 (or all record types included in the 

file). Only the option selected will be displayed in the results. For the unsupported Record 

Types (any type other than those shown in Figure 4-6), only the name and length of the 

record will be displayed in the results. 

Figure 4-6: Type Selection Menu 

For example, the implementation below contains multiple types as shown in the TOC, but 

only the selected type (14) is shown in the results. 

12 
 

 

Figure 4-7: Type Selection Menu 

• Parse Tests 

The “Parse Tests” option displays parse test results (i.e., tests that are executed during 

parsing of the file, before the testing of L1 and L2 assertions). The “File Level Results” 

checkbox must be selected to view the parse tests. See Figure 4-8 for an example of parse 

tests in the file level results. 

Figure 4-8: Field-Level Parse Test Sample 

• L1 Tests/ L2 Tests 

The “L1 Tests” and “L2 Tests” options display L1 and/or L2 test results at the File, Record, 

and Field levels. The "Fields" checkbox and at least one of the File, Record, or Field Level 

checkboxes must be selected to view these results. 

13 
 

Figure 4-9: L1, L2 Tests Sample 

• File Level Results 

The “File Level Results” option displays results related to the file contents. 

Figure 4-10: File-Level Results Sample 

• Record Level Results 

The “Record Level Results” option displays a summary of test results for the record. 

Figure 4-11: Record-Level Results Sample 

Since some Record Types are not supported, the presence of these Records in a file or 

transaction is noted but no action on the content of the record is taken. The Record length is 

stated in the test result. 

14 
 

• Field Level Results 

The “Field Level Results” option displays all test results for each field. Figure 4-12 depicts a 

sample of the Field Level Results. 

Figure 4-12: Field-Level Results Sample 

• Fields 

The “Fields” option displays the fields within each test. If this option is not selected, “Field 

Level Results” will not be displayed. The image below shows the output when the “Fields” 

option is not selected, and thus no fields are displayed. 

Figure 4-13: Fields Option Not Selected 

• Hide Ok 

The “Hide Ok” option removes all tests results that return the status "Ok" from the detailed 

summary with the exception of Records/Fields in error. 

• Field Range 

Specifies which fields of the existing Record Types are displayed by the selected lower and 

upper bounds in these windows. 

15 
 

 

 

Annex A - Code Structure 

This Annex discusses the elements of the code structure depicted in Figures A-1 and A-2 

below. 

The An107File Class is the entry point into the CTA/CTS module. It contains a list of all 

the Record Types encountered in a given transaction (file). After determining that the file 

exists, the parsing operation begins. As each Record in the file is parsed, it is added to the 

list of Records within the An107File Class. 

IRecordType is an interface that defines required methods and attributes. There is a base 

Class that derives from this interface called “RecordBase” that performs all common 

Level 1 and Level 2 assertions for each Record. From RecordBase specific 

implementations for each Record Type to perform Record Type-specific parsing/testing can 

be derived. Parsing at this level could, as required, override the general parsing performed at 

the RecordBase level. 

IField is the interface for fields which describes the content of fields in the file under test. 

IRecordType contains a list of IFields. FieldBase is a specific implementation of 

IField. 

After each test is performed the code updates the list of results at every testing level (File, 

Record, Field, Subfield, and Subfield data). Possible results, listed in order of increasing 

severity are: (a) “Ok”; (b) “Note”; (c) “Warning”; (d) “Error”; and “Critical Error3

”. There is 

also an overall result, once all tests have been completed. A Transaction is determined to be 

“passing” or “failing” in the OverallResult. 

3

 The module tries to run all assertions on all applicable data. That is, processing continues after results of 

Ok, Note, Warning and Error. But the result Critical Error means processing cannot continue because the 

next valid data element (field or record) could not be parsed successfully. 

16 
Figure A-1: Class Diagram for the An107 File Class 

17 
Figure A-2: Class Diagram for the Data Types 

18 
 

 

 

 

 

Annex B - References 

[1]	 NIST Special Publication 500-271, ANSI/NIST-ITL 1-2007 (Revision of ANSI/NISTITL 1-2000), American National Standard for Information Systems — Data Format for 

the Interchange of Fingerprint Facial, & Other Biometric Information – Part 1 

[2]	 NIST Special Publication 500-275, ANSI/NIST-ITL 2-2008 (XML Version of 

ANSI/NIST-ITL 1-2007), American National Standard for Information Systems — Data 

Format for the Interchange of Fingerprint Facial, & Other Biometric Information – Part 

2: XML Version 

[3]	 Update to “Data Format for the Interchange of Fingerprint, Facial & Other Biometric 

Information” for multiple finger capture designations ANSI/NIST ITL 1a-2009 

[4]	 ANSI/NIST Standard Homepage - http://www.nist.gov/itl/iad/ig/ansi_standard.cfm 

[5]	 INCITS M1 – Biometrics Public Homepage - 

http://standards.incits.org/a/public/group/m1 

[6] ISO/IEC JTC1/SC 37 – Biometrics Public Homepage - 

http://www.iso.org/iso/jtc1_sc37_home 

[7] NIST/ITL CSD Biometric Conformance Test Architectures and Test Suites 

Downloads Web Page: http://www.nist.gov/itl/csd/biometrics/biocta_download.cfm 

19 
Annex C - Standard Requirements and Conformance Test Assertions 

Test assertions documented in Table C-4 below are expressed according to the operators and operands included in Tables C-1 for those instances where the assertion cannot be clearly or easily represented in a mathematical format. Table C-3 includes t

table. In the tool implementation all image-related assertions associated with compressed image types are tested against the im

against the image itself. Even though Logical Record types 3 to 6 are not ASCII data, and are not represented in implementat4.001), they are represented as such in this table to make it easier to understand. For assertions formulated from several sectioassertion is listed once on the first requirement encountered. 

Table C-1 – Operators Use in Table C-4 Test Assertions 

Operator Description 

EQ Equal. Tests for equality between two values. 

NEQ Not Equal. Tests for non-equality between two values. 

GTE Greater Than or Equal To. Tests if the first value is greater than or equal to the second v

LTE Less Than or Equal To. Tests if the first value is less than or equal to the second value. 

GT Greater Than. Tests if the first value is greater than the second value. 

LT Less Than. Tests if the first value is less than the second value. 

MO Member Of. Tests if the value is a contained within the set. 

AND Logical And. Tests if both values are true. 

OR Logical OR. Tests if any values are true. 

NOT Negate. Negates any operator or calculation that follows. 

ST Such That. For example, (X,Y) ST X GTE 0 AND Y LTE 10 

IF Logical IF. Tests if the condition is true. 

IFF IF and Only IF. Tests that the condition guarantees another. 

MOD The modulo operator. X MOD Y = the remainder of a X divided by Y 

# All. Represents all legal values. 

: Data Element Selector. X:N selects the Nth data element in X. 

in The selector operator. X in Y selects only those X found in Y. to Range Selector. X to Y provides set of values Z ST Z GTE X AND Z LTE Y 

, Range concatenation. X,Y provides the set of values X AND Y. 

20 
Table C-2 - Description of the Operands Used in Table C-4 Test Assertions 

Operand Description 

Present(Value) Determines if Value is present. 

Present(X in Y) Determines if X is present in Y. 

Sum(Values) The summation of Values. 

Count(Value) The number of occurrences of Value. 

Count(X in Y) The number of X found in Y. 

{X} Value of X. 

Bytes(Value) All of the byte data contained within Value. 

MinOccurrences(Value) The minimum number of occurrences allowed. 

MaxOccurrences(Value) The maximum number of occurrences allowed. 

MinSize(Value) The minimum size allowed per occurrence. 

MaxSize(Value) The maximum size allowed per occurrence. 

Min(Value)= The minimum of the set represented by Value. 

Length(Value) The length of the Value. 

First(X in Y) The first X found in Y. 

Second(X in Y) The second X found in Y. 

Last(X in Y) The last X found in Y. Type(Value) The type of Record represented by Value. 

FieldNumber(Value) The value of the field number for the field represented by V

ForEach(X in Y) {Expression(s)} Evaluate Expression for every X in Y. 

Valid(X) A set of all valid values for X as defined by the requireme

Note: When a data range is used in a calculation, the calculation is applied independently for each data element in the range. expression: Count(Subfields in 1.001,1.002) EQ 0 is equivalent to: Count(Subfields in 1.001) EQ 0 AND Count(Subfields in 1.002) EQ 0 

21 
Table C-3 Terms Used in Table C-4 Test Assertions 

Term Description 

NULL Control character with no value. 

NA Not Applicable 

Table C-4 includes the requirements (or a summary of the requirements) specified in ANSI/NIST-ITL 1-2007 standard and asconformance test assertions. Although references are included for all Record Types when appropriate (for example when a re“tagged-filed records”), the table focuses on requirements and assertions for the Record Types of interest: Record Type 1 and and 17. Explanations of the heading for each column in the table are included below. Table C-4 can be used for conformance test tool developers, implementers of the standard, and end-users as well as testing lab

Field-level requirements and assertions are included. The table includes the following headings4: 

• Requirement ID: Defines a unique identifier for the requirement and associated assertion or set of assertions. It provides 

requirement (e.g., file, record, and field). It could refer to more than one Record Type. 

• Reference in the standard: Identifies the clause where the requirement is included in the standard. In some cases the refer

information such as a Table number. 

• Requirement Summary: Provides a summary of the requirement detailed as textual information or an interpretation of the 

It carries the essentials of the requirement but may not provide all the text necessary to understand it. 

• Level: Indicates whether Level 1 or Level 2 conformance testing is required to address the requirement in the previous co

conformance test are not included. A single cell is included for each assertion. 

• Status: Reflects the status specified in the standard (Mandatory (M) or Optional (O)) for each field. It might also indicate 

the standard (e.g., field content, presence of field) is considered Mandatory or Optional. Conditional requirements (e.g., cinformation items) are tested according to the requirements but are not indicated as such in this column. 

• Assertion ID: Defines an identifier of a specific test assertion within the set of test assertions associated with a requiremen

4 The table headings are derived from the tables of requirements and conformance test assertions specified in ISO/IEC 29109-1:2009, Conformance testing meth

formats defined in ISO/IEC 19794 – Biometric Data Format Standard - Part 1: Generalized conformance testing methodology and the 7th draft of the Conforman

ANSI/NIST- ITL 1-2011 developed by the ANSI/NIST-ITL Conformance Working Group, February 22, 2011. 

22 
• Test assertion: Provides, whenever possible, a mathematical equation or a procedure. Plain text is included whenever a m

simple procedure cannot be detailed. 

• Test Note: Contains a number of a note included below the table. The test note may include a test procedure when the co

does not allow this procedure to be included in the test assertion column. It could also include an explanatory note related 

implementation. 

• Implementation support: Denotes a supplier’s implementation support of a particular requirement (“Y”/”N”). A note can 

providing more details of implementation support (or the lack of it) is required. 

• Supported Range: Indicates a range of values supported, especially when it is different than the full range of values speci

information item is specified as a single value, or does not address a range of values, a N/A should be used. 

• Test Result: This column is used to denote the test results. For file and record-level results the results are either “Pass” or 

should be indicated as “Ok”“Error”, “Warning” and “Note”. Explanatory notes can be added below the table. 

Table C-4 - Requirements and Conformance Test Assertions 

Requirement

ID

Reference in

Base

Standard

Requirement

Summary

Level Status Assertion

ID

Test

Assertion

Tes

Not

File‐Level Requirements and Assertions

7_Bit_ASCII 7,

Table 4

7.1

The standard defines logical records,some of which include ASCII taggedtextual fields. The data in the Type‐1record shall always be recorded invariable length fields using 7‐bit ASCII.Text data in the Type‐2, Type‐9 andtagged‐field records will normally use 7‐bit ASCII encoding. Mechanisms forusing character sets other than 7‐bitASCII are given in section 8.2.3,International Character Sets.

1 M 7‐Bit_Ascii::1.001 to

1.015

{ 1.001 to 1.015} LT 128

1 M 7‐Bit_Ascii::10.001

to 10.013

{10.001 to 10.013} LT 128

1 M 7‐Bit_Ascii::10.016,

10.017

{10.016, 10.017} LT 128

1 M 7‐Bit_Ascii::10.020

to 10.030

{10.020 to 10.030} LT 128

1 M 7‐Bit_Ascii::10.040

to 10.043

{10.040 to 10.043} LT 128

1 M 7‐Bit_Ascii::13.001

to 13.017

{13.001 to 13.017} LT 128

1 M 7‐Bit_Ascii::13.020,

13.024

{13.020, 13.024} LT 128

1 M 7‐Bit_Ascii::14.001

to 14.018

{14.001 to 14.018} LT 128

1 M 7‐Bit_Ascii::14.020

to 14.025

{14.020 to 14.025} LT 128

1 M 7‐Bit_Ascii::14.030 {14.030} LT 1281 M 7‐Bit_Ascii::17.001 {17.001 to 17.026} LT 128

23 
to 17.026

1 M 7‐Bit_Ascii::17.030 {17.030} LT 128

(1,2,9).001‐Fld1First 7.1 The first field in all tagged‐field records

(Types 1, 2 and 9) shall be labeled asfield "1".

2 M 1,2,9.001‐Fld1First See 1.001‐First (handled in Record

Type assertions)

(1,2,9).002‐Fld2Second

7.1 The second field in all tagged‐field

records (Types 1, 2 and 9) shall belabeled as field "2".

2 M 1.002‐Fld2Second See 1.002‐Second (handled in Record

Type assertions)

(1,2,9).001‐

RecBytes

7.1 The first field in all tagged‐field records

shall contain the length in bytes of therecord.

2 M 1.001‐RecBytes {1.001} EQ Length(Record)

(3‐6, 8).Contents 7.1 For the binary image Type‐3, Type‐4,

Type‐5, Type‐6, and Type‐8 logicalrecords, the content and order of therecorded fields are specified by thisstandard. With the exception of the firsttwo fields, the remaining fields of theType‐7 logical image record are all user‐defined. All fields and data in theserecord types shall be recorded as binaryinformation.

2 M 3‐6,8.#‐Contents

The test assertions are included belowunder field testing for Record Type 4

(3‐6, 8).Field_Order 7.1,

11.1

For the binary image Type‐3, Type‐4,Type‐5, Type‐6, and Type‐8 logicalrecords, the content and order of therecorded fields are specified by thisstandard. With the exception of the firsttwo fields, the remaining fields of theType‐7 logical image record are all user‐defined. All fields and data in theserecord types shall be recorded as binaryinformation.Within each logical record, entries shallbe provided in nine ordered andunnumbered fieldsTable 10 lists the contents of each of thenine fields (for Type‐3 through Type‐6).

2 M Type‐4.‐

Fields_In_Order

IF Type(Record) EQ 4 THENCount(Fields) EQ 9 AND Fields:1 toFields: 9 must be ordered.

File‐OneType‐1 7.2 Files to be exchanged are required to

contain one and only one Type‐1 logicalrecord per transaction.

2 M File‐OneType‐1 Count(Records ST Type(Records) EQ 1)

EQ 1

File‐Type‐1_First 7.2 The Type‐1 logical record shall always be

the first logical record within the file.

2 M File‐Type‐1_First Type(First(Record in Transaction)) EQ 1

XX(‐1).002‐IDCRqd 7.4 With the exception of the Type‐1 logical

record, each of the remaining logicalrecords present in a file shall include aseparate field containing the Image

2 M 4.002‐HasIdc Present(4.002)2 M 10.002‐HasIdc Present(10.002)2 M 13.002‐HasIdc Present(13.002)2 M 14.002‐HasIdc Present(14.002)

24 
Designation Character (IDC). 2 M 17.002‐HasIdc Present(17.002)

Valid IDC 7.4 The IDC shall be used to relate

information items in the file contentfield of the Type‐1 record to each logicalrecord.

2 M See Below

1.003‐

CNT_ListsRecs

The test assertion is addressed for eachindividual supported Record Typebelow

002‐IDC_‐Sequence 7.4 The value of the IDC shall be a

sequentially assigned positive integerstarting from zero and incremented byone (up to a maximum of 255).

2 M 002‐IDC_ZeroFirst

{First(Field in Transaction) STFieldNumber(Field) EQ 2} EQ 0

2 M 002‐IDC_Zero_Min‐

_Value

{#.002} GTE 0

2 M 002‐IDC_255_Max‐

_Value

{#.002} LTE 255

2 M 002‐IDC_IncByOne Each new IDC is one greater than the

previous maximum IDC value.

002‐RelatedIDCs 7.4

The IDC shall be used to properlyidentify and link together logical recordsthat pertain to the same entity such as aparticular finger or face.

2 M IDC_Entity_‐

Supported_Types_

Only

Type(Record) MO [1,4,10,13,14, 17]

2 M IDC_Entity_Has_IDC Type(Record) MO [4, 10,13,14,17]2 M IDC_Entity_‐

Choose_‐

Biometric_And_‐

Comparison_Id

Record Type 

Field 10.003 

Biometric Field For 

Comparison ID 

4 NA FINGE 

R 

Byte 1 of 4.004 

10 FACE FACE NA 10 SCAR SCAR (1,1) of 

10.040 

10 MARK MARK (1,1) of 

10.040 

10 TATTO 

O 

TATTO O 

(1,1) of 10.040 

13 NA FINGE 

R 

(1,1) of 13.013 

14 NA FINGE 

R 

(1,1) of 14.013 

17 NA IRIS 17.003 

IF 17.003 = 1 Or 2 

First Record 

Second Record 

Compar ison IDs 

Result 

FINGE R 

FINGE R 

Same Ok 

FINGE R 

FINGE R 

Differen t 

Error 

FINGE R 

NEQFI NGER 

NA Error 

FACE FACE NA Ok FACE NEQ 

FACE 

NA Error 

IRIS IRIS Both = 

1 Or Both = 2 

Ok 

IRIS IRIS Not 

(Both = 1 Or Both = 2) 

Error 

IRIS NEQ NA Error 

2 M IDC_Entity_‐

Compare_Records_

With_The_Same_‐

IDC_Value

25 
IRIS 

SCAR SCAR Same Ok SCAR SCAR Differen 

t 

Warning 

SCAR MARK 

Or TATTO O 

Same or Differen t 

Warning 

SCAR FINGE 

R, FACE Or IRIS 

NA Error 

MARK MARK Same Ok MARK MARK Differen 

t 

Warning 

MARK SCAR 

Or TATTO O 

Same or Differen t 

Warning 

MARK FINGE 

R, FACE Or IRIS 

NA Error 

TATTO O 

TATTO O 

Same Ok 

TATTO O 

TATTO O 

Differen t 

Warning 

TATTO O 

SCAR Or MARK 

Same or Differen t 

Warning 

TATTO O 

FINGE R, FACE Or IRIS 

NA Error 

Record‐Level Requirements and Assertions

File::OneOrMoreRe

cs

8.2 A transaction file shall consist of one or

more logical records.

2 M File::One‐

OrMoreRecs

Count(Records in Transaction) GTE 1 ??

AppropriateFields‐

PerRecord

8.2 For each logical record contained in the

file, several information fieldsappropriate to that record type shall bepresent.

2 M AppropriateFields These test assertions are included in

the tests for the supported RecordTypes below.

No_Subfields 8.2,

8.2.1,

Various sub‐

sections of

9.1,

15.1,18.1,19.1,

22.2

Sections 8.2 and 8.2.1 describe themechanism that enables a field tocontain multiple information itemsknown as subfields. The following fieldsare defined to have a single informationfield and contain no subfields:1.001, 1.002, 1.004 to 1.012, 1.01410.001 to 10.013, 10.016, 10.017,10.020, 10.021, 10.027, 10.03013.001 to 13.012, 13.016, 13.01713.02014.001 to 14.012, 14.016, 14.017,14.020, 14.030

1 M Single_NoSubFields:

:1.001, 1.002

Count(Subfields in 1.001, 1.002 ) EQ 0

1 M Single_NoSubFields:

:1.004 to 1.012

Count(1.Subfields in 004 to 1.012 ) EQ0

1 M Single_NoSubFields:

:1.014

Count(Subfields in 1.014 ) EQ 0

1 M Single_NoSubFields:

:10.001 to 10.013

Count(Subfields in 10.001 to 10.013 )EQ 0

1 M Single_NoSubFields:

:10.016, 10.017

Count(Subfields in 10.016, 10.017 ) EQ0

1 M Single_NoSubFields:

:10.020, 10.021

Count(Subfields in 10.020, 10.021 ) EQ0

1 M Single_NoSubFields:

:10.027

Count(Subfields in 10.027 ) EQ 0

1 M Single_NoSubFields:

:10.030

Count(Subfields in 10.030 ) EQ 0

1 M Single_NoSubFields:

:13.001 to 13.012

Count(Subfields in 13.001 to 13.012 )EQ 0

26 
17.001 to 17.015, 17.017, 17.018,

17.020 to 17.023, 17.025, 17.026,17.030

1 M Single_NoSubFields:

:13.016, 13.017

Count(Subfields in 13.016, 13.017 ) EQ0

1 M Single_NoSubFields:

:13.020

Count(Subfields in 13.020 ) EQ 0

1 M Single_NoSubFields:

:14.001 to 14.012

Count(Subfields in 14.001 to 14.012 )EQ 0

1 M Single_NoSubFields:

:14.016, 14.017

Count(Subfields in 14.016, 14.017 ) EQ0

1 M Single_NoSubFields:

:14.020, 14.030

Count(Subfields in 14.020, 14.030 ) EQ0

1 M Single_NoSubFields:

:17.001 to 17.015

Count(Subfields in 17.001 to 17.015 )EQ 0

1 M Single_NoSubFields:

:17.017, 17.018

Count(Subfields in 17.017, 17.018 ) EQ0

1 M Single_NoSubFields:

:17.020 to 17.023

Count(Subfields in 17.020 to 17.023 )EQ 0

1 M Single_NoSubFields:

:17.025, 17.026

Count(Subfields in 17.025, 17.026 ) EQ0

1 M Single_NoSubFields:

:17.030

Count(Subfields in 17.030 ) EQ 0

Valid_Record_Type 8.2.2 For tagged‐field logical records each

field shall begin with the logical recordtype number chosen from Table 4.

1 M RecordTypeValid::1.

001 to 1.015

IF Type(Record) EQ 1 THENType(1.001 to 1.015) EQ 1

1 M RecordTypeValid::1

0.001 to 10.013

IF Type(Record) EQ 10 THENType(10.001 to 10.013) EQ 10

1 M RecordTypeValid::1

0.016, 10.017

IF Type(Record) EQ 10 THENType(10.016,10.017) EQ 10

1 M RecordTypeValid::1

0.020 to 10.030

IF Type(Record) EQ 10 THENType(10.020 to 10.030) EQ 10

1 M RecordTypeValid::1

0.040 to 10.043

IF Type(Record) EQ 10 THENType(10.040 to 10.043) EQ 10

1 M RecordTypeValid::1

0.999

IF Type(Record) EQ 10 THENType(10.999) EQ 10

1 M RecordTypeValid::1

3.001 to 13.017

IF Type(Record) EQ 13 THENType(13.001 to 13.017) EQ 13

1 M RecordTypeValid::1

3.020, 13.024

IF Type(Record) EQ 13 THENType(13.020, 13.024) EQ 13

1 M RecordTypeValid::1

3.999

IF Type(Record) EQ 13 THENType(13.999) EQ 13

1 M RecordTypeValid::1

4.001 to 14.018

IF Type(Record) EQ 14 THENType(14.001 to 14.018) EQ 14

1 M RecordTypeValid::1

4.020 to 14.025

IF Type(Record) EQ 14 THENType(14.020 to 14.025) EQ 14

1 M RecordTypeValid::1

4.030

IF Type(Record) EQ 14 THENType(14.030) EQ 14

1 M RecordTypeValid::1

4.999

IF Type(Record) EQ 14 THENType(14.999) EQ 14

1 M RecordTypeValid::1 IF Type(Record) EQ 17 THEN

27 
7.001 to 17.026 Type(17.001 to 17.026) EQ 17

1 M RecordTypeValid::1

7.030

IF Type(Record) EQ 17 THENType(17.030) EQ 17

1 M RecordTypeValid::1

7.999

IF Type(Record) EQ 17 THENType(17.999) EQ 17

(1,2,9)‐FsAtEnd 8.2.2 The ASCII File Separator ASCII FS control

character (signifying the end of thelogical record or transaction) shall followthe last byte of ASCII information foreach Type‐1, Type‐2, and Type‐9 record.

2 M 1‐FsAtEnd Last(Byte in Record) EQ ASCII FS

(1,2,9)‐LenInclEndFs 8.2.2 The ASCII File Separator ASCII FS control

character (signifying the end of thelogical record or transaction) shall followthe last byte of ASCII information andshall be included in the length of therecord for each Type‐1, Type‐2, andType‐9 record.

2 M 1‐LenInclEndFs Length(Record) EQ Sum(Field Lengths)

+ 1The last byte, ASCII FS, is included inthe Record Length

(3‐8).001‐Length 8.2.2 The entire length of the record shall be

recorded in the first four‐byte binaryfield of each Type‐3 through Type‐8record.

2 M 4.001‐Length {4.001} EQ Length(Record)

(10,13‐

17,99).999Last

8.2.2 The last physical field in a tagged‐field

image record (Types 10, 13, 14, 15, 16,17 & 99) shall always be numbered"999".

2 M 10.999Last FieldNumber(Last (Field in Record)) EQ

999

2 M 13.999Last FieldNumber (Last (Field in Record)) EQ

999

2 M 14.999Last FieldNumber (Last (Field in Record)) EQ

999

2 M 17.999Last FieldNumber (Last (Field in Record)) EQ

999

(10,13‐17,99)‐

FsAtEnd

8.2.2 The ASCII File Separator ASCII FS control

character shall follow the last byte of thecompressed or uncompressed imagedata in a tagged‐field image record(Types 10, 13, 14, 15, 16, 17 & 99).

2 M 10‐FsAtEnd Last(Byte in Record) EQ ASCII FS2 M 13‐FsAtEnd Last(Byte in Record) EQ ASCII FS2 M 14‐FsAtEnd Last(Byte in Record) EQ ASCII FS2 M 17‐FsAtEnd Last(Byte in Record) EQ ASCII FS

(10,13‐17,99)‐

LenInclEndFs

8.2.2 The ASCII FS character shall signify the

end of the logical record or transactionand shall be included as part of therecord length of a tagged‐field imagerecord (Types 10, 13, 14, 15, 16, 17 &99).

2 M 10‐LenInclEndFs Length(Record) EQ Sum(Field Lengths)

+ 1The last byte, ASCII FS, is included inthe Record Length

2 M 13‐LenInclEndFs Length(Record) EQ Sum(Field Lengths)

+ 1The last byte, ASCII FS, is included inthe Record Length

2 M 14‐LenInclEndFs Length(Record) EQ Sum(Field Lengths)

+ 1The last byte, ASCII FS, is included in

28 
the Record Length

2 M 17‐LenInclEndFs Length(Record) EQ Sum(Field Lengths)

+ 1The last byte, ASCII FS, is included inthe Record Length

Intn’l Char Sets 8.2.3 NA NA NA NA Not supported in this version 1

Type 1 Requirements and Assertions

Length_Minimum_

Tagged_Field

9.1

(Table 8),

15.1

(Table 17),

18.1

(Table 31),

19.1

(Table 33),

22.1

(Table 37)

This requirement is inferred from theTables describing the Minimum Fieldsize per occurrence and Minimum Occurcount values for each record type. Thelength of the data shall be greater thanor equal to the field's min size peroccurrence times the min Occur count.

1 M LengthMin::1.001

to 1.015

Length(1.001 to 1.015) GTEMinSize(1.001 to 1.015) *MinOccurrences(1.001 to 1.015)

1 M LengthMin::10.001

to 10.013

Length(10.001 to 10.013) GTEMinSize(10.001 to 10.013) *MinOccurrences(10.001 to 1.013)

1 M LengthMin::10.016,

10.017

Length(10.016,10.017) GTEMinSize(10.016, 10.017) *MinOccurrences(10.016, 10.017)

1 M LengthMin::10.020

to 10.030

Length(10.020 to 10.030) GTEMinSize(10.020 to 10.030) *MinOccurrences(10.020, 10.030)

1 M LengthMin::10.040

to 10.043

Length(10.040 to 10.043) GTEMinSize(10.040, to 10.043) *MinOccurrences(10.040 to 10.043)

1 M LengthMin::10.999 Length(10.999) GTE MinSize(10.999) *

MinOccurrences(10.999)

1 M LengthMin::13.001

to 13.017

Length(13.001 to 13.017) GTEMinSize(13.001 to 13.017) *MinOccurrences(13.001 to 13.017)

1 M LengthMin::13.020 Length(13.020) GTE MinSize(13.020) *

MinOccurrences(13.020)

1 M LengthMin::13.024 Length(13.024) GTE MinSize(13.024) *

MinOccurrences(13.024)

1 M LengthMin::13.999 Length(13.999) GTE MinSize(13.999) *

MinOccurrences(13.9999)

1 M LengthMin::14.001

to 14.018

Length(14.001 to 14.018) GTEMinSize(14.001 to 14.018) *MinOccurrences(14.001 to 14.018)

1 M LengthMin::14.020

to 14.025

Length(14.020 to 14.025) GTEMinSize(14.020 to 14.025) *MinOccurrences(14.020 to 14.025)

1 M LengthMin::14.030 Length(14.030) GTE MinSize(14.030) *

MinOccurrences(14.030)

1 M LengthMin::14.999 Length(14.999) GTE MinSize(14.999) *

MinOccurrences(14.999)

1 M LengthMin::17.001

to 17.026

Length(17.001 to 17.026) GTEMinSize(17.001 to 17.026) *MinOccurrences(17.001 to 17.026)

1 M LengthMin::17.030 Length(17.030) GTE MinSize(17.030) *

29 
MinOccurrences(17.030)

1 M LengthMin::17.999 Length(17.999) GTE MinSize(17.999) *

MinOccurrences(17.999)

Length_Maximum_

Tagged _Field

9.1

(Table 8),

15.1

(Table 17),

18.1

(Table 31),

19.1

(Table 33),

22.1

(Table 37)

This requirement is inferred from theTables describing the Maximum Fieldsize per occurrence and Maximum Occurcount values for each record type. Thelength of the data shall be less than orequal to the field's max size peroccurrence times the max Occur count.

1 M LengthMax::1.001

to 1.015

Length(1.001 to 1.015) LTEMaxSize(1.001 to 1.015) *MaxOccurrences(1.001 to 1.015)

1 M LengthMax::10.001

to 10.013

Length(10.001 to 10.013) LTEMaxSize(10.001 to 10.013) *MaxOccurrences(10.001 to 1.013)

1 M LengthMax::10.016,

10.017

Length(10.016,10.017) LTEMaxSize(10.016, 10.017) *MaxOccurrences(10.016, 10.017)

1 M LengthMax::10.020

to 10.030

Length(10.020 to 10.030) LTEMaxSize(10.020 to 10.030) *MaxOccurrences(10.020, 10.030)

1 M LengthMax::10.040

TO 10.043

Length(10.040 to 10.043) LTEMaxSize(10.040, to 10.043) *MaxOccurrences(10.040 to 10.043)

1 M LengthMax::10.999 Length(10.999) LTE MaxSize(10.999) *

MaxOccurrences(10.999)

1 M LengthMax::13.001

TO 13.017

Length(13.001 to 13.017) LTEMaxSize(13.001 to 13.017) *MaxOccurrences(13.001 to 13.017)

1 M LengthMax::13.020 Length(13.020) LTE MaxSize(13.020) *

MaxOccurrences(13.020)

1 M LengthMax::13.024 Length(13.024) LTE MaxSize(13.024) *

MaxOccurrences(13.024)

1 M LengthMax::13.999 Length(13.999) LTE MaxSize(13.999) *

MaxOccurrences(13.9999)

1 M LengthMax::14.001

TO 14.018

Length(14.001 to 14.018) LTEMaxSize(14.001 to 14.018) *MaxOccurrences(14.001 to 14.018)

1 M LengthMax::14.020

TO 14.025

Length(14.020 to 14.025) LTEMaxSize(14.020 to 14.025) *MaxOccurrences(14.020 to 14.025)

1 M LengthMax::14.030 Length(14.030) LTE MaxSize(14.030) *

MaxOccurrences(14.030)

1 M LengthMax::14.999 Length(14.999) LTE MaxSize(14.999) *

MaxOccurrences(14.999)

1 M LengthMax::17.001

TO 17.026

Length(17.001 to 17.026) LTEMaxSize(17.001 to 17.026) *MaxOccurrences(17.001 to 17.026)

1 M LengthMax::17.030 Length(17.030) LTE MaxSize(17.030) *

MaxOccurrences(17.030)

1 M LengthMax::17.999 Length(17.999) LTE MaxSize(17.999) *

MaxOccurrences(17.999)

CharType_Numbers Table 8,

Table 17,Table 31,Table 33,

This requirement is inferred from theTables describing the Char type for eachrecord type. The following fields shallcontain only numbers (ASCII 0x30

1 M CharType_Numbers

::1.001, 1.002

Bytes(1.001,1.002) MO [0 to 9]

1 M CharType_Numbers

::1.005, 1.006

Bytes(1.005,1.006) MO [0 to 9]

30 
Table 37 through 0x39):

1.001,1.002,1.005,1.00610.001,10.002,10.005 to10.009,10.013,10.016,10.01713.001 to 13.003, 13.005 to 13.010,13.012,13.013,13.016,13.01714.001 to 14.003, 14.005 to 14.010,14.012, 14.016,14.01717.001 to 17.003, 17.005 to 17.010,17.012, 17.020, 17.022, 17.023, 17.025,17.026

1 M CharType_Numbers

::10.001, 10.002

Bytes(10.001,10.002) MO [0 to 9]

1 M CharType_Numbers

::10.005 to 10.009

Bytes(10.005 to 10.009) MO [0 to 9]

1 M CharType_Numbers

::10.013

Bytes(10.013) MO [0 to 9]

1 M CharType_Numbers

::10.016,10.017

Bytes(10.016,10.017) MO [0 to 9]

1 M CharType_Numbers

::10.017

Bytes(10.017) MO [0 to 9]

1 M CharType_Numbers

::13.001 to 13.003

Bytes(13.001 to 13.003)MO [0 to 9]

1 M CharType_Numbers

::13.005 to 13.010

Bytes(13.005 to 13.010) MO [0 to 9]

1 M CharType_Numbers

::13.012, 13.013

Bytes(13.012, 13.013) MO [0 to 9]

1 M CharType_Numbers

::13.016, 13.017

Bytes(13.016,13.017) MO [0 to 9]

1 M CharType_Numbers

::14.001 to 14.003

Bytes(14.001 to 14.003) MO [0 to 9]

1 M CharType_Numbers

::14.005 to 14.010

Bytes(14.005 to 14.010) MO [0 to 9]

1 M CharType_Numbers

::14.012

Bytes(14.012) MO [0 to 9]

1 M CharType_Numbers

::14.016, 14.017

Bytes(14.016,14.017) MO [0 to 9]

1 M CharType_Numbers

::17.001 to 17.003

Bytes(17.001 to 17003) MO [0 to 9]

1 M CharType_Numbers

::17.005 to 17.010

Bytes(17.005 to 17.010) MO [0 to 9]

1 M CharType_Numbers

::17.012

Bytes(17.012) MO [0 to 9]

1 M CharType_Numbers

::17.020

Bytes(17.020) MO [0 to 9]

1 M CharType_Numbers

::17.022, 17.023

Bytes(17.022, 17.023) MO [0 to 9]

1 M CharType_Numbers

::17.025, 17.026

Bytes(17.025, 17.026) MO [0 to 9]

1 M CharType_Numbers

::17.030

Bytes(17.030) MO [0 to 9]

1.001‐First 9.1 Within a Type‐1 logical record, entries

shall be provided in numbered fields. Itis required that the first two fields of therecord are ordered.1.001 must be thefirst field.

2 M 1.001‐First IF Type(Record) EQ 1 THEN

FieldNumber (First(Field in Record)) EQ1

1.002‐Second 9.1 Within a Type‐1 logical record, entries

shall be provided in numbered fields. Itis required that the first two fields of therecord are ordered. 1.002 must be thesecond field.

2 M 1.002‐Second IF Type(Record) EQ 1 THEN

FieldNumber(Second(Field in Record))EQ 2

31 
1.xxx‐Mandatory

1.xxx‐

MaxOccurances

Version=0400

CharType_Numbers

_Subfields

Subfields_Nx2

9.1

Table 8

9.1

Table 8

9.1.2

9.1.3,

15.1.22,15.1.23,15.1.31,18.1.21,19.1.13,

19.1.21 to

19.1.25,22.2.16,

22.2.24

9.1.3,

18.1.14,19.1.18,

19.1.22

1.003‐ 9.1.3

Table 8 lists the “condition code” asbeing mandatory “M” or optional “O”

The “Occur count Max” column of Table

8 lists the maximum number of times a

field can occur in a Type‐1 record.

The entry for this 2007 version of the

approved standard shall be '0400'.

The following fields shall only contain

numbers (ASCII 0x30 through 0x39),ASCII US (0x1F) and ASCII RS (0x1E):

1.00310.024, 10.025, 10.04113.02414.013, 14.021 to 14.02517.016, 17.024The following fields shall contain one or

more RS_Subfields, which each contain

two US_Subfields:13.014, 14.018, 14.022Field 1.003 shall contain two or more

RS_Subfields, which each contain twoUS_SubfieldsField 1.003, File Content (CNT) shall list

2211111111111112

MMMMMMMMMMMMMMMM

1.xxx‐Mandatory

1.xxx‐

MaxOccurances

Value_0400::1.002

CharType_Numbers

_US_RS::1.003

CharType_Numbers

_US_RS::10.024,

10.025

CharType_Numbers

_US_RS::10.041

CharType_Numbers

_US_RS::13.024

CharType_Numbers

_US_RS::14.013

CharType_Numbers

_US_RS::14.021 to

14.025

CharType_Numbers

_US_RS::17.016

CharType_Numbers

_US_RS::17.024

Nx2::1.003

Nx2::13.014Nx2::14.018Nx2::14.022

1.003‐

Present(Mandatory Fields)Count(1.xxx) LTEMaxOccurrences(1.xxx){1.002} EQ 0400

Bytes(1.003) MO [0 to 9, ASCII US,

ASCII RS]Bytes(10.024,10.025) MO [0 to 9, ASCII

US, ASCII RS]Bytes(10.041) MO [0 to 9, ASCII US,

ASCII RS]Bytes(13.024) MO [0 to 9, ASCII US,ASCII RS]Bytes(14.013) MO [0 to 9, ASCII US,ASCII RS]Bytes(14.021 to 14.025) MO [0 to 9,

ASCII US, ASCII RS]

Bytes(17.016) MO [0 to 9, ASCII US,

ASCII RS]

Bytes(17.024) MO [0 to 9, ASCII US,ASCII RS]Count(RS_Subfields in 1.003 ) GTE 2ANDForEach(RS_Subfield in 1.003 ){Count(US_Subfields) EQ 2}Count(RS_Subfields in 13.014 ) GTE 1ANDForEach(RS_Subfield in 13.014 ){Count(US_Subfields) EQ 2}Count(RS_Subfields in 14.018 ) GTE 1ANDForEach(RS_Subfield in 14.018 ){Count(US_Subfields) EQ 2}Count(RS_Subfields in 14.022 ) GTE 1

ANDForEach(RS_Subfield in 14.022 ){Count(US_Subfields) EQ 2}Field 1.003, File Content (CNT) shall list

2222

32 
CNT_ListsRecs

1.003‐Num‐

Following‐

Recs=Num‐

FollowingSubfields

1.003‐

CNT_IDCsMatchRec

s

Unspecified Data

33 

and identify each of the logical recordsin the file by record type. It also specifiesthe order in which the remaining logicalrecords shall appear in the file.Each of the subfields after the firstsubfield of Field 1.003 relate to a singleType‐2 through Type‐99 logical recordcontained in the file. Two informationitems shall comprise each subfield. Thefirst information item shall be the recordidentifier character(s) chosen from Table4 that identifies the record type. Thisidentifier must match the record type ofthe corresponding record in the field.

CNT_ListsRecs and identify each of the logical records

in the file by record type. It alsospecifies the order in which theremaining logical records shall appearin the file.Each of the subfields after the firstsubfield of Field 1.003 relate to a singleType‐2 through Type‐99 logical recordcontained in the file. Two informationitems shall comprise each subfield. Thefirst information item shall be therecord identifier character(s) chosenfrom Table 4 that identifies the recordtype. This identifier must match therecord type of the correspondingrecord in the field.

9.1.3 The second information item of the first

subfield of Field 1.003 (CNT) shall be thesum of the Type‐2 through Type‐99logical records contained in this file.This number is also the number ofremaining subfields in the CNT field.

2 M 1.003‐Num‐

Following‐

Recs=Num‐

FollowingSubfields

The second information item of thefirst subfield of Field 1.003 (CNT) shallbe the sum of the Type‐2 throughType‐99 logical records contained inthis file. This number is also thenumber of remaining subfields in theCNT field.

9.1.3 Each of the subfields after the first

subfield of Field 1.003 relate to a singleType‐2 through Type‐99 logical recordcontained in the file. Two informationitems shall comprise each subfield. Thesecond item shall be the IDC associatedwith the logical record pertaining to thatsubfield.

2 M 1.003‐CNT_IDCs‐

MatchRecs

Each of the subfields after the firstsubfield of Field 1.003 relate to a singleType‐2 through Type‐99 logical recordcontained in the file. Two informationitems shall comprise each subfield. Thesecond item shall be the IDC associatedwith the logical record pertaining tothat subfield.

9.1.1,

Various sub‐

sections of

9.1,

11.2,15.1,

18.1

19.1,

22.2

This requirement is not explicitly stated,but instead is a generalization for allfields where the content cannot bechecked against any known value. Forall such fields that allow unspecifieddata, the content of the field is alwaysaccepted. These fields include:1.001, 1.004, 1.007 to 1.0134.001, 4.002, 4.006, 4.007, 4.00910.001, 10.002, 10.004, 10.006, 10.007,10.009, 10.010, 10.016, 10.017, 10.025,10.026, 10.04113.001, 13.002, 13.004, 13.006 to13.010, 13.016, 13.01713.020

1 M Opaque::1.001 True1 M Opaque::1.004 True1 M Opaque::1.007 to

1.013

True

1 M Opaque::4.001,

4.002

True

1 M Opaque::4.006,

4.007

True

1 M Opaque::4.009 True1 M Opaque::10.001,

10.002

True

1 M Opaque::10.004 True1 M Opaque::10.006,

10.007

True

1 M Opaque::10.009,

10.010

True

1 M Opaque::10.016,

10.017

True
14.001, 14.002, 14.004, 14.006, 14.007,

14.009, 14.010, 14.016, 14.017, 14.02017.001, 17.002, 17.004, 17.006, 17.007,17.009, 17.010, 17.014, 17.015, 17.018,17.019, 17.021 to 17.024, 17.026

1 M Opaque::10.025,

10.026

True

1 M Opaque::10.041 True1 M Opaque::13.001,

13.002

True

1 M Opaque::13.004 True1 M Opaque::13.006 to

13.010

True

1 M Opaque::13.016,

13.017

True

1 M Opaque::13.020 True1 M Opaque::14.001,

14.002

True

1 M Opaque::14.004 True1 M Opaque::14.006,

14.007

True

1 M Opaque::14.009,

14.010

True

1 M Opaque::14.016,

14.017

True

1 M Opaque::14.020 True1 M Opaque::17.001,

17.002

True

1 M Opaque::17.004 True1 M Opaque::17.006,

17.007

True

1 M Opaque::17.009,

17.010

True

1 M Opaque::17.014,

17.015

True

1 M Opaque::17.018,

17.019

True

1 M Opaque::17.021 to

17.024

True

1 M Opaque::17.026 True

AlphaNumeric 9.1

(Table 8),

15.1

(Table 17),

18.1

(Table 31),

19.1

(Table 33),

22.1

(Table 37)

The field shall only contain alphanumericcharacters (ASCII 0x20 through 0x7E).

1 M AlphaNumeric::1.00

4

Bytes(1.004) MO [0x20 to 0x7E]

1 M AlphaNumeric::1.00

7 to 1.010

Bytes(1.007 to 1.010) MO [0x20 to0x7E]

1 M AlphaNumeric::1.01

4

Bytes(1.014) MO [0x20 to 0x7E]

1 M AlphaNumeric::10.0

03, 10.004

Bytes(10.003, 10.004) MO [0x20 to0x7E]

1 M AlphaNumeric::10.0

10 to 10.012

Bytes(10.010 to 10.012) MO [0x20 to0x7E]

1 M AlphaNumeric::10.0

20

Bytes(10.020) MO [0x20 to 0x7E]

1 M AlphaNumeric::10.0

27

Bytes(10.027) MO [0x20 to 0x7E]

34 
1 M AlphaNumeric::10.0

30

Bytes(10.030) MO [0x20 to 0x7E]

1 M AlphaNumeric::13.0

04

Bytes(13.004) MO [0x20 to 0x7E]

1 M AlphaNumeric::13.0

11

Bytes(13.011) MO [0x20 to 0x7E]

1 M AlphaNumeric::13.0

20

Bytes(13.020) MO [0x20 to 0x7E]

1 M AlphaNumeric::14.0

04

Bytes(14.004) MO [0x20 to 0x7E]

1 M AlphaNumeric::14.0

11

Bytes(14.011) MO [0x20 to 0x7E]

1 M AlphaNumeric::14.0

20

Bytes(14.020) MO [0x20 to 0x7E]

1 M AlphaNumeric::14.0

30

Bytes(14.030) MO [0x20 to 0x7E]

1 M AlphaNumeric::17.0

04

Bytes(17.004) MO [0x20 to 0x7E]

1 M AlphaNumeric::17.0

11

Bytes(17.011) MO [0x20 to 0x7E]

1 M AlphaNumeric::17.0

13 to 17.015

Bytes(17.013 to 17.015) MO [0x20 to0x7E]

1 M AlphaNumeric::17.0

17, 17.018

Bytes(17.017, 17.018) MO [0x20 to0x7E]

YYYYMMDD_Valid 9.1.5,

15.1.5,18.1.5,19.1.5,

22.2.5

The date shall appear as eight digits inthe format YYYYMMDD.

1 M YYYYMMDD_Valid::

1.005

{1.005} MO Valid(YYYYMMDD)

1 M YYYYMMDD_Valid::

10.005

{10.005} MO Valid(YYYYMMDD)

1 M YYYYMMDD_Valid::

13.005

{13.005} MO Valid(YYYYMMDD)

1 M YYYYMMDD_Valid::

14.005

{14.005} MO Valid(YYYYMMDD)

1 M YYYYMMDD_Valid::

17.005

{17.005} MO Valid(YYYYMMDD)

YYYYMMDD_NotFu

ture

9.1.5 The transaction date shall not be future. 1 M YYYYMMDD_NotFu

ture::1.005

{1.005} LTE Date.Today

Values_1To9 9.1.6 The value shall be in the range 1 to 9. 1 O Values_1To9::1.006 {1.006} MO [1 to 9]

1.011‐NSR_‐

ZeroIfNoBinaryRecs

9.1.11 For transactions that do not contain

Type‐3 through Type‐7 fingerprint imagerecords, field 1.011 (NSR) shall be set to“00.00”.

2 M 1.011‐NSR_‐

ZeroIfNoBinaryRecs

If NOT Present(Type 3 to Type 7) Then{1.011} EQ “00.00”

AlphaNumeric_Subf

ields

9.1

(Table 8),

9.1.13,9.1.15,

15.1.20,15.1.21,15.1.26,15.1.30,

The field shall only contain alphanumericcharacters (ASCII 0x20 through 0x7E),ASCII US (0x1F) and ASCII RS (0x1E).

1 M AlphaNumeric_US_

RS::1.013

Bytes(1.013) MO [0x20 to 0x7E, ASCII

US, ASCII RS]

1 M AlphaNumeric_US_

RS::1.015

Bytes(1.015) MO [0x20 to 0x7E, ASCII

US, ASCII RS]

1 M AlphaNumeric_US_

RS::10.022, 10.023

Bytes(10.022,10.023) MO [0x20 to

0x7E, ASCII US, ASCII RS]

1 M AlphaNumeric_US_

RS::10.028, 10.029

Bytes(10.028,10.029) MO [0x20 to

0x7E, ASCII US, ASCII RS]

35 
15.1.32,

15.1.33,18.1.14,18.1.15,19.1.14,19.1.15,19.1.18,

22.2.19

1 M AlphaNumeric_US_

RS::10.040

Bytes(10.040) MO [0x20 to 0x7E, ASCII

US, ASCII RS]

1 M AlphaNumeric_US_

RS::10.042, 10.043

Bytes(10.042,10.043) MO [0x20 to

0x7E, ASCII US, ASCII RS]

1 M AlphaNumeric_US_

RS::13.014, 13.015

Bytes(13.014,13015) MO [0x20 to

0x7E, ASCII US, ASCII RS]

1 M AlphaNumeric_US_

RS::14.014,14.015

Bytes(14.014,14.015) MO [0x20 to

0x7E, ASCII US, ASCII RS]

1 M AlphaNumeric_US_

RS::14.018

Bytes(14.018) MO [0x20 to 0x7E, ASCII

US, ASCII RS]

1 M AlphaNumeric_US_

RS::17.019

Bytes(17.019) MO [0x20 to 0x7E, ASCII

US, ASCII RS]

Numbers2Dot2 9.1.11,

9.1.12

The field shall consist of two numbersfollowed by a period followed by twonumbers.

1 M Numbers2Dot2::1.0

11, 1.012

{1.011, 1.012} MO '##.##'

1.012‐NTR_‐

ZeroIfNoBinaryRecs

9.1.12 For transactions that do not contain

Type‐3 through Type‐7 fingerprint imagerecords, field 1.012 (NTR) shall be set to“00.00”.

2 M 1.012‐NTR_‐

ZeroIfNoBinaryRecs

If NOT Present(Type 3 to Type 7) Then{1.012} EQ “00.00”

GMT 9.1.14 The GMT is represented as

YYYYMMDDHHMMSSZ, a 15‐characterstring that is the concatenation of thedate with the GMT and concludes with aZ.

1 O GMT_Valid::1.014 {1.014} Valid(YYYYMMDDHHMMSSZ)

GMT_NotFuture 9.1.14 The GMT shall not exceed the current

date.

1 O GMT_NotFuture::1.

014

{1.014} LTE {Date Today}

1.014‐

GMT_NotFuture

9.1.14 The complete GMT date shall not exceed

the current date.

2 M 1.014‐

GMT_NotFuture

{1.014} LTE {Current DateTime}

SubFields 9.1.13,

9.1.15,

15.1.27,15.1.32,

19.1.25

The field shall contain subfields. 1 O SubFields

Expected::1.013

Present( Subfield in 1.013)

1 O SubFields

Expected::1.015

Present(Subfield in 1.015 )

1 O SubFields

Expected::10.029

Present(Subfield in 10.029 )

1 O SubFields

Expected::10.042

Present(Subfield in 10.042 )

1 O SubFields

Expected::14.025

Present(Subfield in 14.025 )

NotSupported 9.1.15 The field is not supported. 1 O NotSupported::1.01

5

True

1.015‐DCS 9.1.15 Not supported in this version 1

(Not Needed) 9.2 Immediately following the last

information field in the Type‐1 logicalrecord, an ASCII FS separator charactershall be used to separate it from thenext logical record. This ASCII FScharacter shall replace the “GS”character that is normally used between

information fields.

2 M See Above

1‐FsAtEnd

Last(Byte in Record) EQ ASCII FS

Type 4 Requirements and Assertions

36 
4::MandatoryFields 11.1 In a Type 4 record, entries shall be

provided in nine ordered andunnumbered fields. The data recorded isin binary form – no ASCII data. The firsteight fields are fixed length and totaleighteen bytes. These fields precede theimage data contained in field nine.Table 10 lists the contents of each of thenine fields.

2 M 4::MandatoryFields In a Type 4 record, entries shall be

provided in nine ordered andunnumbered fields. The data recordedis in binary form – no ASCII data. Thefirst eight fields are fixed length andtotal eighteen bytes. These fieldsprecede the image data contained infield nine. Table 10 lists the contentsof each of the nine fields.

4::LenData=LEN‐18 11.1 In a Type‐4 record the size of the ninth

field is eighteen bytes less than thevalue specified in the LEN field.

2 M 4::LenData=LEN‐18 Length(4.009) EQ Length(Record) ‐ 18

Length_Maximum_

Binary _Field

11.2

(Table 10)

The field length shall be as specified. 1 M LengthMax::4.001

to 4.009

Length(4.001 to 4.009) LTE{Length.Max}

Length_Minimum_

Binary_Field

11.2

(Table 10)

The field length shall be as specified. 1 M LengthMin::4.001 Length(4.001 to 4.009) GTE

{Length.Min}

4.001::RecBytes 11.2.1 The mandatory four‐byte binary LEN

field shall occupy bytes one through fourof each record type. It shall contain thelength of the logical record specifyingthe total number of bytes, includingevery byte of all nine fields contained inthe record.

2 M 4.001::RecBytes Length(Record) EQ {4.001}

4.002‐

CNT_IDCsMatchRec

s

11.2.2 The mandatory one‐byte binary IDC field

shall be a binary representation of theIDC found in the file content (CNT) fieldof the Type‐1 record.

2 M 4.003‐

CNT_IDCsMatchRec

s

See Above1.003‐CNT_IDCsMatchRecs

Table_11_Finger 11.2.3 The field value shall be selected from

Table 11.

1 M Table_11_Finger::4.

003

{4.003} MO Table 11

Table_12_0To14 11.2.4 The field value shall be selected from

Table 12.

1 M Table_12_0‐

14_Binary::4.004

{4.004} MO [0 to 14]

Values_0To1 11.2.5 The value shall be 0 or 1. 1 M 0‐1_Binary::4.005 {4.005} MO [0, 1]

4.006‐HLL 11.2.6 Field 4.006 shall be used to specify the

number of pixels contained on a singlehorizontal line of the transmitted image.

2 M 4.006‐JPEGB‐JPEGL‐

HLL

{4.006} EQ {Image Width} 3

2 M 4.006‐WSQ‐HLL {4.006} EQ {Image Width} 3

4.007‐VLL 11.2.7 Field 4.007 shall be used to specify the

number of horizontal lines contained inthe transmitted image.

2 M 4.007‐JPEGB‐JPEGL‐

VLL

{4.007} EQ {Image Height} 3

2 M 4.007‐WSQ‐VLL {4.007} EQ {Image Height} 3

Table_1_No_4‐6 11.2.8 The field value shall be selected from

Table 1. Values 4 through 6 are notvalid.

1 M Table_1_No_4‐

6::4.008

{4.008} NOT MO [4‐6] AND {4.008} MOTable 1

4.008‐

ConfirmedCGA

11.2.8 Field 4.008 shall be used to specify the

type of compression used (if any). Forthe Type‐4 logical record, the WSQ orthe JPEG standard algorithms arerecommended.

2 M 4.011‐JPEGB‐JPEGL {4.008} corresponds to {SOF marker} 32 M 4.011‐WSQ Present(SOF, Image Height, Image

Width)

3

4.009‐ValidImage 11.2.9 Field 4.009 shall contain the image data. 2 M 4.009‐Valid‐

Uncomp

Length(4.009) EQ {4.006} * {4.007}

37 
2 M 4.009‐Valid‐JPEGB‐

JPEGL

Present(SOI, SOF, EOI) 3

2 M 4.009‐Valid‐WSQ Present(SOI, SOF, SOB, EOI) 3

Type 10 Requirements and Assertions

10::FixedPositionFi

elds

15.1 It is required that the first two fields of

the Type‐10 record are ordered, and thefield containing the image data shall bethe last physical field in the record.

2 M 10:001::LEN_First First(Field in Record) ST Type(Record)

EQ 10 AND Field EQ 10.001

2 M 10:002::IDC_Second Second(Field in Record) ST

Type(Record) EQ 10 AND Field EQ10.002

2 M 10:999::DATA_Last Last(Field in Record) ST Type(Record)

EQ 10 AND Field EQ 10.999 in a Type‐10 record.

10::MandatoryField

s

15.1,

(Table 17)

For each field of the Type‐10 record,Table 17 lists the "condition code" asbeing mandatory "M" or optional"O"...and occurrence limits.

2 M 10::CondCode_M IF "Cond code" EQ "M" in Table 17,

Present(Field in Record)

2 M 10.xxx‐

MaxOccurances

Count(10.xxx) LTEMaxOccurrences(10.xxx)

2 M 10.xxx‐

MinOccurances

Count(10.xxx) GTEMinOccurrences(10.xxx)

10::IMG=FAC_Fields 15.1 Fields with “FAC” in the “IMG” column

of Table 17 apply to mugshot or facialimage Type‐10 records.

2 M 10::IMG=FAC_

FaceOK

Fields with “FAC” in the “IMG” columnof Table 17 apply to mugshot or facialimage Type‐10 records.

2 M 10::IMG=FAC_

SmtBad

Fields with “SMT” in the “IMG” columnof Table 17 do not apply to mugshot orfacial image Type‐10 records.

10::IMG=SMT_Field

s

15.1 Fields with “SMT” in the “IMG” column

of Table 17 apply to scar, mark or tattooimage Type‐10 records

2 M 10::IMG=SMT_‐

SmtOk

Fields with “SMT” in the “IMG” columnof Table 17 apply to scar, mark ortattoo image Type‐10 records.

2 M 10::IMG=SMT_‐

FaceBad

Fields with “FAC” in the “IMG” columnof Table 17 do not apply to scar, markor tattoo image Type‐10 records.

10::Len=Bytes 15.1.1 Field 10.001: Logical record length (LEN)

This mandatory ASCII field shall containthe total count of the number of bytes inthe Type‐10 logical record. Field 10.001shall specify the length of the recordincluding every character of every fieldcontained in the record and theinformation separators.

2 M 10.001::Len=Bytes

{10.001} EQ Length(Record)

10::IDC=CNT_IDC 15.1.2 Field 10.002: Image designation

character (IDC)This mandatory ASCII field shall be usedto identify the facial or SMT image datacontained in the record. This IDC shallmatch the IDC found in the file content(CNT) field of the Type‐1 record.

2 M 10.002::IDC=CNT_‐

IDC {10.002} EQ {1.003}

38 
FaceScarMarkTatto The value shall be FACE, SCAR, MARK or

o

15.1.315.1.6

15.1.6,15.1.7,18.1.6,18.1.7,19.1.6,19.1.7,22.2.6,

22.2.715.1.7

15.1.8,19.1.8,22.2.3,

22.2.815.1.815.1.9

TATTOO.

10.006‐HLL Field 10.006 shall contain the number of

pixels contained on a single horizontalline of the transmitted image.

NotifyOnZero If the field value is zero note this fact in

the output.

10.007‐VLL Field 10.007 shall contain the number of

horizontal lines contained in thetransmitted image.

Values_0To2 The value shall be 0, 1 or 2.

10.008‐SLC Field 10.008 shall specify the units used

to describe the image sampling

frequency (pixel density).

10.009‐HPS Field 10.010 shall specify the integer

pixel density used in the horizontal

direction of the transmitted image if the

SLC field contains a 1 or 2. Otherwise, itindicates the horizontal component of

the pixel aspect ratio.

1222111122211112222222

MMMMMMMMMMMMMMMMMMMMMM

FaceScarMarkTatto

o::10.003

10.006‐JPEGB‐

JPEGL‐HLL

10.006‐JP2‐JP2L‐

HLL

10.006‐PNG‐HLL

NotifyOnZero::10.0

06, 10.007

NotifyOnZero::13.0

06, 13.007

NotifyOnZero::14.0

06, 14.007

NotifyOnZero::17.0

06, 17.007

10.007‐JPEGB‐

JPEGL‐VLL

10.007‐JP2‐JP2L‐

VLL

10.007‐PNG‐VLL

Values_0To2::10.00

8

Values_0To2::14.00

8

Values_0To2::17.00

3

Values_0To2::17.00

8

10.008‐JPEGB‐

JPEGL‐SLC

10.008‐JP2‐JP2L‐

SLC

10.008‐PNG‐SLC

10.009‐JPEGB‐

JPEGL

10.009‐JP2‐JP2L‐

HPS

10.009‐PNG‐HPS

10.009‐JPEGB‐

39 

{10.003} MO ['FACE', 'SCAR', 'MARK',

'TATTOO']{10.006} EQ {Image Width}{10.006} EQ {Image Width}{10.006} EQ {Image Width}{10.006,10.007} NEQ 0{13.006, 13.007} NEQ 0{14.006, 14.007} NEQ 0{17.006,17.007} NEQ 0{10.007} EQ {Image Height}{10.007} EQ {Image Height}{10.007} EQ {Image Height}{10.008} MO [0‐2]{14.008} MO [0‐2]

{17.003} MO [0‐2]{17.008} MO [0‐2]IF Present(JFIF Header) THEN{10.008} EQ {Sampling Units}Not ImplementedIF Present(PHYS chunk) THENIF {10.008} EQ “1” OR “2” THEN{Sampling Units} EQ 1, ELSE IF {10.008}EQ 0 THEN{Sampling Units} EQ 0

IF {10.008} EQ “1” OR “2”, THEN

IF Present(JFIF Header) THEN

{10.009} EQ {Horizontal Density}No ImplementationIF Present(PHYS Chunk) THENIF {10.008} EQ “1”, THEN{10.009} EQ {Horizontal Density} *0.0254 (meters/inch)ELSE IF {10.008} EQ “2”, THEN

{10.009} EQ {Horizontal Density} * 0.01(meters/cm)IF {13.008} NEQ “1” OR “2”, THEN

3433433
JPEGL‐HorzAspect {13.009} EQ {Horizontal Density} /

{Vertical Density}

2 M 10.009‐JP2‐JP2L‐

HorzAspect

No Implementation 4

2 M 10.009‐PNG‐

HorzAspect

IF Present(PHYS Chunk), THENIF {10.008} NEQ “1” OR “2”, THEN{10.009} EQ {Horizontal Density} /{Vertical Density}

3

10.010‐VPS 15.1.10 Field 10.010 shall specify the integer

pixel density used in the verticaldirection of the transmitted image if theSLC field contains a 1 or 2. Otherwise, itindicates the vertical component of thepixel aspect ratio.

2 M 10.010‐JPEGB‐

JPEGL‐VPS

IF {10.008} EQ “1” OR “2”, THENIF Present(JFIF Header) THEN

{10.010} EQ {Vertical Density}

3

2 M 10.010‐JP2‐JP2L‐

VPS

No Implementation 4

2 M 10.010‐PNG‐VPS IF Present(PHYS Chunk) THEN

IF {10.008} EQ “1”, THEN{10.010} EQ {Vertical Density} * 0.0254(meters/inch)ELSE IF {10.008} EQ “2”, THEN{10.010} EQ {Vertical Density} * 0.01(meters/cm)

3

2 M 10.010‐JPEGB‐

JPEGL‐VerAspect

IF {10.008} NEQ “1” OR “2”, THEN{10.010} EQ {Horizontal Density} /{Vertical Density}

3

2 M 10.010‐JP2‐JP2L‐

VerAspect

No Implementation 4

2 M 10.010‐PNG‐

VerAspect

IF Present(PHYS Chunk), THENIF {10.008} NEQ “1” OR “2”, THEN{10.010} EQ {Horizontal Density} /{Vertical Density}

3

Table_1_No_WSQ 15.1.11 The field value shall be selected from

Table 1. WSQ is not valid.

1 M Table_1_No_WSQ::

10.011

{10.011} NOT WSQ AND {10.011} MOTable 1

10.011‐

ConfirmedCGA

15.1.11 Field 10.011 shall contain an entry from

Table 1 (other than WSQ) to specify thealgorithm used to compress thetransmitted grayscale images.

2 M 10.011‐JPEGB‐

JPEGL‐CGA

{10.011} corresponds to {SOF marker} 3

2 M 10.011‐JP2‐JP2L‐

CGA

{5th parameter of ImgBox} EQ “7” 3

2 M 10.011‐PNG‐CGA Present(IHDR) 3

Table_3 15.1.12,

22.2.13

The field value shall be selected fromTable 3.

1 M Table_3::10.012 {10.012} MO Table 31 M Table_3::17.013 {17.013} MO Table 3

10.012‐CSP 15.1.12 Field 15.012 shall contain an entry from

Table 3 to identify the color space used.If the color space for an RGB imagecannot be determined, an entry of“RGB” shall be entered.

2 M 10.012‐JPEGB‐

JPEGL‐CSP

No Implementation 4

2 M 10.012‐JP2‐JP2L‐

CSP

IF Present(Colour Specification box),THEN {10.012} corresponds to {CSP}

3

2 M 10.012‐PNG‐CSP {10.012} corresponds to {CSP} 3

Table_18 15.1.13 The field value shall be selected from

Table 18.

1 M Table_18::10.013 {10.013} MO [0, 1, 10, 11, 12, 13, 14,

15, 20, 30, 40, 50, 51]

5

10.003::IMT=FACE_

SAP_Mandatory

15.1.13 Field 10:013, the Subject Acquisition

Profile (SAP), is mandatory when field10.003 contains "FACE”.

2 M 10.003::IMT=FACE_

SAP_Mandatory

Field 10:013, the Subject AcquisitionProfile (SAP), is mandatory when field10.003 contains "FACE”.

40 
RESERVED_FIELDS 15.1.14 Fields 10.014 and 10.015 are reserved

for definition and inclusion in futurerevisions of this standard. None of thesefields are to be used at this revisionlevel. If any of these fields are present,they are to be ignored.

‐ ‐ 10.014::Reserved Present(10.014)‐ ‐ 10.015::Reserved Present(10.015)

RESERVED_FIELDS 15.1.17 Fields 10.018 and 10.019 are reserved

for definition and inclusion in futurerevisions of this standard. None of thesefields are to be used at this revisionlevel. If any of these fields are present,they are to be ignored.

‐ ‐ 10.018::Reserved Present(10.018)‐ ‐ 10.019::Reserved Present(10.019)

SubjectPose_Table_

19

15.1.18 The value shall be selected from Table

19.

1 O SubjectPose::10.02

0

{10.020} MO ['F', 'R', 'L', 'A', 'D']

‐180_To_180 15.1.19 The offset angle shall be measured from

the full‐face pose position and have arange of values from ‐180 degrees to+180 degrees.

1 O ‐

180_To_180::10.02

1

{10.021} LTE 180 AND {10.021} GTE ‐180

5

10.021::POS=A_‐

POA_Mandatory

15.1.19 Field 10.021, Pose offset angle (POA),

shall only be used for the exchange offacial image data if Field 10.020 (POS)contains an "A" to indicate an angledpose of the subject. This field should beomitted for a full face or a profile. If theentry in the POS field is an "F", "L", or"R", the contents of this field areignored.

2 O 10.021::POS=A_‐

POA_Mandatory

IF{10.020} EQ “A” THENPresent(10.021)

Photo_Description 15.1.20 This optional ASCII field, retained for

legacy systems, is used for the exchangeof facial image data. When present, itshall consist of one or more subfieldsand shall describe special attributes ofthe captured facial image. Attributesassociated with the facial image may beselected from Table 20 and entered inthis field as one or more subfieldsseparated by the ASCII RS separatorcharacter between the items. Physicalcharacteristics, such as FRECKLES may beentered as a subfield consisting of twoinformation items. The first is PHYSICALfollowed by the ASCII US separator,followed by the characteristic as listed inthe Ninth (or current) Edition of theNCIC Code Manual, December, 2000.The OTHER category is used to enterunlisted or miscellaneous attributes ofthe facial image. This information shallbe entered as a two‐information itemsubfield. The first is OTHER followed bythe ASCII US separator, followed by the

1 O Photo_Descriptors::

10.022

{10.022} MO Table 20

41 
unformatted text used to describe the

attribute. Multiple attributes andsubfields may be listed but must beseparated by the ASCII RS character.

Table_21 15.1.21 The field value shall be selected from

Table 21.

1 O 10.023_Table_21::1

0.023

{10.023} MO Table 21

Subfields_1x[1,2] 15.1.21 The field shall be single or have two

subfields. The subfields shall beseparated by ASCII US.

1 O 1x1_Or_1x2::10.02

3

Count(US_Subfields in 10.023 ) EQ 0ORCount(US_Subfields in 10.023 ) EQ 2

2

10.023::SAP>=40_‐

PAS_Mandatory

15.1.21 Field 10.023, Photo acquisition source

(PAS), is mandatory if the SAP entry(Field 10.013) is "40" or greater.

2 O 10.023::SAP>=40_‐

PAS_Mandatory

IF {10.013} GTE 40 THENPresent(10.023)

SubFields_Nx3 15.1.22,

22.2.24

Each subfield shall contain threeinformation items separated by theASCII US separator character. The fieldshall contain one or more rows ofsubfields.

1 O SubFields_Nx3::10.

024

ForEach(Subfield in 10.024 ){Count(items) EQ 3}

1 O SubFields_Nx3::17.

024

ForEach(Subfield in 17.024 ){Count(items) EQ 3}

Subject_Quality_Sc

ore

15.1.22 This optional ASCII field shall specify

quality score data for facial imagesstored in this record. Each subfield shallcontain three information itemsseparated by the ASCII US separatorcharacter. They identify a quality scoreand the algorithm used to create thequality score. This information is usefulto enable the recipient of the qualityscore to differentiate between qualityscores generated by different algorithmsand adjust for any differences inprocessing or analysis as necessary.1. The first information item shall be aquantitative expression of the predictedmatching performance of the biometricsample. This item contains the ASCIIrepresentation of the integer imagequality score between 0 and 100assigned to the image data by a qualityalgorithm. Higher values indicate betterquality. An entry of 255 shall indicate afailed attempt to calculate a qualityscore. An entry of 254 shall indicate thatno attempt to calculate a quality scorewas made. The use of additional valuesto convey other information should beharmonized with ISO/IEC 19794standards.2. The second information item shallspecify the ID of the vendor of thequality algorithm used to calculate the

1 O Subject_Quality_Sc

ore::10.024

ForEach(RS_Subfield in 14.024){Count(US_Subfield) EQ 3AND{US_Subfield:1} GTE 0 AND{US_Subfield:1} LTE 100 OR{US_Subfield:1} MO [254,255]AND{US_Subfield:2} MO [IBIA VendorRegistry]AND{US_Subfield:3} GTE 1 AND{US_Subfield:3} LTE 65535 OR}

2

42 
quality score. This 4‐digit hex value is

assigned by IBIA and expressed as fourASCII characters. The IBIA shall maintainthe Vendor Registry of CBEFF BiometricOrganizations that will map the value inthis field to a registered organization.3. The third information item shallspecify a numeric product code assignedby the vendor of the quality algorithm,which may be registered with the IBIA,but it is not required to be registered. Itindicates which of the vendor’salgorithms was used in the calculation ofthe quality score. This field contains theASCII representation of the integerproduct code and should be within therange 1 to 65,535.

IBIA_Quality_‐

Vendor

15.1.22 Field 10.024: Subject quality score (SQS)

This optional ASCII field shall specifyquality score data for facial imagesstored in this record. ...2. The second information item shallspecify the ID of the vendor of thequality algorithm used to calculate thequality score. This 4‐digit hex value isassigned by IBIA and expressed as fourASCII characters. The IBIA shall maintainthe Vendor Registry of CBEFF BiometricOrganizations that will map the value inthis field to a registered organization.....

2 O 10.024::IBIA_‐

Quality_Vendor

The code exists in the IBIA VendorRegistry of CBEFF BiometricOrganizations.

10.025::POS=D_‐

SPA_Mandatory

15.1.23 Field 10.025, Subject pose angles (SPA),

is mandatory when Field 10.020 (POS)contains a "D".

2 O 10.025::POS=D_‐

SPA_Mandatory

IF{10.020} EQ “D” THENPresent(10.025)

Single_Or_SubField

s

15.1.20,15.1.24,15.1.30,

15.1.33

The field can have one or moresubfields.

1 O SingleOrSubFields::

10.022

True

1 O SingleOrSubFields::

10.026

True

1 O SingleOrSubFields::

10.040

True

1 O SingleOrSubFields::

10.043

True

AlphaNumeric_RS 15.1.24 The field shall only contain alphanumeric

characters (ASCII 0x20 through 0x7E)and ASCII RS (0x1E).

1 O AlphaNumeric_RS::

10.026

Bytes(10.026) MO [0x20‐0x7E, ASCIIRS]

43 
10.026::SAP_>=_40

_Mandatory

15.1.24 Field 10.026, Subject facial description

(SXS), is mandatory if the SAP entry(Field 10.013) is "40" or greater.

2 O 10.026::SAP_>=_40

_Mandatory

IF {10.013} GTE “40” THENPresent(10.026)

EyeColor 15.1.25 The field value shall be selected from

Table 23.

1 O EyeColor::10.027 {10.027} MO Table 301 O EyeColor::17.020 {17.020} MO Table 30

10.027::SAP_>=_40

_Mandatory

15.1.25 Field 10.027, Subject eye color (SEC), is

mandatory if the SAP entry (Field10.013) is "40" or greater.

2 O 10.027::SAP_>=_40

_Mandatory

IF{10.013} GTE “40” THENPresent(10.027)

Subfields_[1,2]x1 15.1.26 The field shall be single or have two

subfields. The subfields shall beseparated by ASCII RS.

1 O 1x1_Or_2x1::10.02

8

Count(Subfields in 10.028 ) EQ 0 ORCount(Subfields in 10.028 ) EQ 2

Subject_Hair_Color 15.1.26 This optional ASCII field shall be used for

the exchange of facial image data. Thisfield is mandatory if the SAP entry (Field10.013) is 40 or greater. When present,it shall contain an entry form Table 24that describes the hair color of thesubject as seen in the photograph. Forunusual or unnatural colors not listed inthe table, or the real color cannot beascertained, the hair color should belabeled as XXX. If the subject iscompletely bald, or has a completelyshaved head, then the hair color shall belabeled as BAL. When the subject ispredominantly bald, but hair color isdiscernable, then the appropriate haircolor attribute code shall follow BAL(separated by the ASCII RS character).

1 O Subject_Hair_Color:

:10.028

{10.028} MO Table 24

10.028::SAP_>=_40

_Mandatory

15.1.26 Field 10.028, Subject hair color (SHC), is

mandatory if the SAP entry (Field10.013) is "40" or greater.

2 O 10.028::SAP_>=_40

_Mandatory

IF {10.013} GTE “40” THENPresent(10.028)

10.028::Bald_2nd_C

olor

15.1.26 Field 10.028: Subject hair color (SHC)

If the subject is completely bald, or has acompletely shaved head, then the haircolor shall be labeled as “BAL”. Whenthe subject is predominantly bald, buthair color is discernable, then theappropriate hair color attribute codeshall follow “BAL” (separated by theASCII RS).

2 O 10.028::Bald_2nd_‐

Color

IF (1,1) = “BAL”

(2,1) = {NULL Or {All Color Attributes

Except “BAL”}}

FeaturePoint 15.1.27 The optional ASCII field shall be used for

the exchange of facial image data. Whenpresent, it shall describe specialattributes of manually or automaticallydetected facial feature points of thecaptured facial image. This informationshall be entered as a four‐informationitem feature point block as described inTable 25. The first information item is

1 O Subject_Feature_Po

ints::10.029 ForEach(RS_Subfield in 10.029)

{US_Subfield:1 EQ 1ANDUS_Subfield:2 EQ A.B ST A.B MO Figure5 AND A.B NOT MO [Prior A.B]

2

44 
feature point type. For this version of

the standard the only allowable value is1which is followed by the ASCII USseparator character. The second isfeature point code, followed by theASCII US separator character. The thirdis the X coordinate of a feature point,followed by the ASCII US separatorcharacter. The fourth and final item isthe Y coordinate of a feature point in thefacial image. Multiple facial points maybe listed using these four informationitems. But each feature block must beseparated by the ASCII RS separatorcharacter. The maximum number offeature points shall be 88, with the useof 84 MPEG4 feature points and 4additional eye and nostril center featurepoints.

AND{US_Subfield:3} > 0 ANDLength(US_Subfield:3) MO [1,2,3,4]

AND

{US_Subfield:4} > 0 ANDLength(US_Subfield:4) MO [1,2,3,4]}

10.029::No_‐

Duplicate_‐

Feature_Points

15.1.27 Field 10.029: Facial feature points (FFP)

The optional ASCII field shall be used forthe exchange of facial image data. ...The maximum number of feature pointsshall be 88, with the use of 84 MPEG4feature points and 4 additional eye andnostril center feature points.

2 O 10.029::No_‐

Duplicate_‐

Feature_Points

All Facial Feature Points (FPP) (X,Y) areunique.

Table_27 15.1.28,

19.1.27,22.2.28,

Table 27

The field value shall be selected fromTable 27.

1 O Table_27::10.030 {10.030} MO Table 271 O Table_27::14.030 {14.030} MO Table 271 O Table_27::17.030 {17.030} MO Table 27

RESERVED_FIELDS 15.1.29 Field 10.031‐039: Reserved for future

definition (RSV)These fields are reserved for definitionand inclusion in future revisions of thisstandard. None of these fields are to beused at this revision level. If any of thesefields are present, they are to beignored.

‐ ‐ 10.031‐039::‐

Reserved

Present(10.031 to 10.039)

NCIC_Designation_

Code

15.1.30 This field is mandatory for a Type‐10

record containing SMT image data. It isused to identify a general location of thecaptured scar, mark, tattoo, or othercharacteristic (including piercings) in animage. The contents of this field will bean entry chosen from the December,2000 ninth (or current) edition of theNCIC Code Manual. The captured imagecan encompass an area larger than that

1 O NCIC_Designation_

Code::10.040

{10.040} MO [NCIC Designation Codes] 5

45 
specified by a single NCIC body part

code for the particular image type. Thissituation can be accommodated bylisting multiple NCIC codes separated bythe ASCII RS separator character. In thiscase the primary code is listed first. Forthe marks category, the NCIC manuallists the common locations for needletrack marks. For other body partlocations not listed under the markscategory, use the body location codeslisted for scars.

10.040::SMT_‐

Image_Data_‐

SMT_Field_‐

Mandatory

15.1.30 Field 10.040, NCIC designation code

(SMT), is mandatory for a Type‐10record containing SMT image data.

2 O 10.040::SMT_‐

Image_Data_‐

SMT_Field_‐

Mandatory

Field 10.040, NCIC designation code(SMT), is mandatory for a Type‐10record containing SMT image data.

Subfields_1x2 15.1.31,

19.1.14

The field shall have two subfieldsseparated by ASCII US.

1 O 1x2::10.041 Count(Subfields in 10.041 ) EQ 21 O 1x2::14.014 Count(Subfields in 14.014 ) EQ 2

SMT_Descriptors 15.1.32 This optional field is used to describe the

content of the SMT image. It shallconsist of one or more subfields. Eachsubfield shall contain three or fourinformation items that provideprogressively detailed informationdescribing the total image or a portionof the image. The first information itemof each subfield shall identify the sourceof the image as being a scar, a mark, or atattoo. It shall contain SCAR to indicatehealed scar tissue that was the result anaccident or medical procedure. An entryof MARK shall be used for the patternresulting from needle or track marks. Foreither case the second and thirdinformation items shall contain OTHERand MISC and the fourth informationitem shall contain a textual descriptionor other information concerning the scaror mark pattern. For deliberately appliedor drawn images, the first informationitem will contain TATTOO to indicate acommon tattoo or indelible imageresulting from the pricking of the skinwith a coloring matter; CHEMICAL if theimage was created by the use ofchemicals to burn the image into theskin; BRANDED if the image was burnedinto the skin using a branding iron orother form of heat; or CUT if the imagewas caused by incision of the skin.

1 O SMT_Descriptors::1

0.042 ForEach(RS_Subfield in 10.042)

{US_Subfield:1 MO [‘SCAR’, ‘MARK’,‘TATTOO’, ‘CHEMICAL’, ‘BRANDED’,‘CUT’]ANDIF US_Subfield:1 MO [‘SCAR’,’MARK’]THEN{US_Subfield:2 EQ ‘OTHER’ ANDUS_Subfield:3 EQ ‘MISC’}ELSE{US_Subfield:2 MO Table 28 ANDUS_Subfield:3 MO Table 29 a to h}}

2

15.1.32 Field 10.042: SMT descriptors (SMD) 2 O 10.042::SCAR_‐ IF (N,1) = “SCAR”

46 
10.042::SCAR_‐

MARK_OTHER_‐

MISC_Text

10.042::SCAR_‐

MARK_(1x4)

10.042::TATTOO

MARK_OTHER_‐ (N,2) = “OTHER”

This optional field is used to describe the MISC_Text (N,3) = “MISC”content of the SMT image. It shall (N,4) = Text

consist of one or more subfields. Eachsubfield shall contain three or fourinformation items that provideprogressively detailed informationdescribing the total image or a portionof the image.The first information item of eachsubfield shall identify the source of the

image as being a scar, a mark, or atattoo. It shall contain “SCAR” to

indicate healed scar tissue that was theresult an accident or medical procedure.An entry of “MARK” shall be used for the

pattern resulting from needle or track

marks. For either case the second andthird information items shall contain“OTHER” and “MISC” and the fourth

information item shall contain a textualdescription or other information

concerning the scar or mark pattern.

For deliberately applied or drawnimages, the first information item will

contain "TATTOO" ...

47 

15.1.32 The first information item of each

subfield shall identify the source of theimage as being a scar, a mark, or atattoo. It shall contain “SCAR” toindicate healed scar tissue that was theresult an accident or medical procedure.An entry of “MARK” shall be used for thepattern resulting from needle or trackmarks. For either case the second andthird information items shall contain“OTHER” and “MISC” and the fourthinformation item shall contain atextual description or other informationconcerning the scar or mark pattern.

2 O 10.042::SCAR_‐

MARK_(1x4)

IF(N,1) = “SCAR”

Row N is (N,4)

15.1.32 Field 10.042: SMT descriptors (SMD)

This optional field is used to describe thecontent of the SMT image...The first information item of eachsubfield shall identify the source of theimage as being a scar, a mark, or a

2 O 10.042::TATTOO IF(N,1) In {“TATTOO”, “CHEMICAL”,

“BRANDED”, “CUT”}

(N,2) In {Table 28}(N,3) In {Table 29}(N,4) In {NULL, Text}
tattoo. It shall contain “SCAR” ...

For deliberately applied or drawnimages, the first information item willcontain "TATTOO" to indicate a commontattoo or indelible image resulting fromthe pricking of the skin with a coloringmatter; "CHEMICAL" if the image wascreated by the use of chemicals to burnthe image into the skin; "BRANDED" ifthe image was burned into the skinusing a branding iron or other form ofheat; or “CUT” if the image was causedby incision of the skin.The second information item shall bethe general class code of tattoo chosenfrom Table 28. For each general class oftattoo, there are several definedsubclasses. The third information item ofthe subfield shall be the appropriatesubclass code selected from Table 29 a‐hwhich lists the various subclasses oftattoos for each of the general classes.The final and optional information itemin this subfield shall be an ASCII textstring that provides additional qualifiersto describe the image or portion of theimage. For example, to fully describe atattoo, there may be a class descriptionof "ANIMAL", with a subclass descriptionof "DOG", and qualified by "goldenretriever with an overbite". The ASCII USseparator character will be usedbetween information items.

15.1.32 Field 10.042: SMT descriptors (SMD)

This optional field is used to describe thecontent of the SMT image...The first information item of eachsubfield shall identify the source of theimage as being a scar, a mark, or atattoo. It shall contain “SCAR” ...For deliberately applied or drawnimages, the first information item willcontain "TATTOO" to indicate a ...The final and optional information

2 O 10.042::TATTOO_‐

(1x3)_Or_(1x4)

IF (N,1) In {“TATTOO”, “CHEMICAL”,“BRANDED”, “CUT”}

(N,2) Is Not NULL(N,3) Is Not NULL(N,4) Is NULL Or Not NULL

(Optional)

10.042::TATTOO_‐

(1x3)_Or_(1x4)

48 
item in this subfield shall be an ASCII

text string that provides additionalqualifiers to describe the image orportion of the image. For example, tofully describe a tattoo, there may be aclass description of "ANIMAL", with asubclass description of "DOG", andqualified by "golden retriever with anoverbite". The ASCII US separatorcharacter will be used betweeninformation items.

Color_Tattoo 15.1.33 This optional field shall contain one

subfield corresponding to each subfieldcontained in Field 10.042. Each subfieldshall contain one or more informationitems that list the color(s) of the tattooor part of the tattoo. For each subfield,the first information item in the subfieldshall be the predominant color chosenfrom Table 30. Additional colors for thesub‐field shall be entered as informationitems in the subfield separated by theASCII US separator character.

1 O Color::10.043 {10.043} MO Table 30

10.043::Num‐

Subfields

15.1.33 Field 10.043: Color (COL)

This optional field shall contain onesubfield corresponding to each subfieldcontained in Field 10.042.

2 O 10.043::Num‐

Subfields

IF Present(10.043) THENCount(Subfields in10.043) EQCount(Subfields in 10.042)

RESERVED_FIELDS 15.1.34 Field 10.044‐199: Reserved for future

definition (RSV)These fields are reserved for definitionand inclusion in future revisions of thisstandard. None of these fields are to beused at this revision level. If any of thesefields are present, they are to beignored.

‐ ‐ 10:044‐199::‐

Reserved

Present(10.044 to 10.199)

Binary_Tagged_Fiel

d

15.1.36, Binary data is opaque. 1 M BinaryData::10.999 True

1 M BinaryData::13.999 True1 M BinaryData::14.999 True1 M BinaryData::17.999 True

10.999‐ValidImage 15.1.36 Field 10.999 shall contain all of the

grayscale or color image data from aface, scar, mark, tattoo, or other image.

2 M 10.999‐Valid‐

Uncomp

Length(10.999) EQ {10.006} * {10.007}

2 M 10.999‐Valid‐

JPEGB‐JPEGL

Present(SOI, SOF, EOI)

2 M 10.999‐Valid‐JP2‐

JP2L

Present(SigBox, HeadBox, ImgBox)

2 M 10.999‐Valid‐PNG Present(PNGSIG, IHDR, IDAT, IEND)

49 
10::FsAtEnd 15.2 End of Type‐10 logical record 2 M 10::FsAtEnd Last(Byte in Record) EQ ASCII FS

For the sake of consistency, immediatelyfollowing the last byte of data from field10.999 an ASCII FS separator shall be

used to separate it from the next logicalrecord. This separator must be included

in the length field of the Type‐10 record.

Type 13 Requirements and Assertions

13::MandatoryField

s

18.1,

Table 31

For each field of the Type‐13 record,Table 31 lists the "condition code" asbeing mandatory "M" or optional"O"...and occurrence limits.

2 M 13::CondCode_M IF "Cond code" EQ "M" in Table 31, the

Field must be present in the record.

2 M 13.xxx‐

MaxOccurrences

Count(13.xxx) LTEMaxOccurrences(13.xxx)

2 M 13.xxx‐

MinOccurrences

Count(13.xxx) GTEMinOccurrences(13.xxx)

13::FixedPosition‐

Fields

18.1 It is required that the first two fields of

the record are ordered, and the fieldcontaining the image data shall be thelast physical field in the record.

2 M 13.001::LEN_First First(Field in Record) ST Type(Record)

EQ 13 AND Field EQ 13.001

2 M 13.002::IDC_Second Second(Field in Record) ST

Type(Record) EQ 13 AND Field EQ13.002

2 M 13.999::DATA_Last Last(Field in Record) ST Type(Record)

EQ 13 AND Field EQ 13.999

13::Len=Bytes 18.1.1 Field 13.001: Logical record length (LEN)

This mandatory ASCII field shall containthe total count of the number of bytes inthe Type‐13 logical record. Field 13.001shall specify the length of the recordincluding every character of every fieldcontained in the record and theinformation separators.

2 M 13:001::Len=Bytes {13.001} EQ Length(Record)

13::IDC=CNT_IDC 18.1.2 Field 13.002: Image designation

character (IDC)This mandatory ASCII field shall be usedto identify the latent image datacontained in the record. This IDC shallmatch the IDC found in the file content(CNT) field of the Type‐1 record.

2 M 13.002::IDC=CNT_‐

IDC

The IDC matches the value of thecorresponding CNT field of the Type‐1record.

Table_11_LatentFn

grPlm

18.1.3 The field value shall be selected from

Table 11.

1 M Table_11_LatentFin

gerPalm::13.003

{13.003} MO [4‐7, 12‐15]

13.006‐HLL 18.1.6 Field 13.006 shall contain the number of

pixels contained on a single horizontalline of the transmitted image.

2 M 13.006‐JPEGL‐HLL {13.006} EQ {Image Width} 32 M 13.006‐JP2L‐HLL {13.006} EQ {Image Width} 32 M 13.006‐PNG‐HLL {13.006} EQ {Image Width} 3

13.007‐VLL 18.1.7 Field 13.007 shall contain the number of

horizontal lines contained in the

2 M 13.007‐JPEGL‐VLL {13.007} EQ {Image Height} 32 M 13.007‐JP2L‐VLL {13.007} EQ {Image Height} 3

50 
transmitted image. 2 M 13.007‐PNG‐VLL {13.007} EQ {Image Height} 3

13.008‐SLC 18.1.8 Field 13.008 shall specify the units used

to describe the image samplingfrequency (pixel density).

2 M 13.008‐JPEGL‐SLC IF Present(JFIF Header) THEN

{13.008} EQ {Sampling Units}

2 M 13.008‐JP2L‐SLC No Implementation 42 M 13.008‐PNG‐SLC IF Present(PHYS Chunk) THEN

IF {13.008} EQ 1 OR 2 THEN{Sampling Units} EQ 1, ELSE IF {13.008}EQ 0 THEN{Sampling Units} EQ 0

3

13.009‐HPS 18.1.9 Field 13.010 shall specify the integer

pixel density used in the horizontaldirection of the transmitted image if theSLC field contains a 1 or 2. Otherwise, itindicates the horizontal component ofthe pixel aspect ratio.

2 M 13.009‐JPEGL‐HPS IF {13.008} EQ “1” OR “2”, THEN

IF Present(JFIF Header) THEN

{13.009} EQ {Horizontal Density}

3

2 M 13.009‐JP2L‐HPS No Implementation 42 M 13.009‐PNG‐HPS IF Present(PHYS Chunk) THEN

IF {13.008} EQ “1”, THEN{13.009} EQ {Horizontal Density} *0.0254 (meters/inch)ELSE IF {13.008} EQ “2”, THEN{13.009} EQ {Horizontal Density} * 0.01(meters/cm)

3

2 M 13.009‐JPEGL‐

HorzAspect

IF {13.008} NEQ “1” OR “2”, THEN{13.009} EQ {Horizontal Density} /{Vertical Density}

3

2 M 13.009‐JP2L‐

HorzAspect

No Implementation 4

2 M 13.009‐PNG‐

HorzAspect

IF Present(PHYS Chunk), THENIF {13.008} NEQ “1” OR “2”, THEN{13.009} EQ {Horizontal Density} /{Vertical Density}

3

13.010‐VPS 18.1.10 Field 13.010 shall specify the integer

pixel density used in the verticaldirection of the transmitted image if theSLC field contains a 1 or 2. Otherwise, itindicates the vertical component of thepixel aspect ratio.

2 M 13.010‐JPEGL‐VPS IF {13.008} EQ “1” OR “2”, THEN

IF Present(JFIF Header) THEN

{13.010} EQ {Vertical Density}

3

2 M 13.010‐JP2L‐VPS No Implementation 42 M 13.010‐PNG‐VPS IF Present(PHYS Chunk) THEN

IF {13.008} EQ “1”, THEN{13.010} EQ {Vertical Density} * 0.0254(meters/inch)ELSE IF {13.008} EQ “2”, THEN{13.010} EQ {Vertical Density} * 0.01(meters/cm)

3

2 M 13.010‐JPEGL‐

VerAspect

IF {13.008} NEQ “1” OR “2”, THEN{13.010} EQ {Horizontal Density} /{Vertical Density}

3

2 M 13.010‐JP2L‐

VerAspect

No Implementation 4

2 M 13.010‐PNG‐

VerAspect

IF Present(PHYS Chunk), THENIF {13.008} NEQ “1” OR “2”, THEN{13.010} EQ {Horizontal Density} /{Vertical Density}

3

Table_1_No_Lossy 18.1.11 The field value shall be selected from 1 M Table_1_No_Lossy:: {13.011} MO [“NONE”, “JPEGL”, “JP2L”, 3

51 
Table 1. Lossy algorithms are not valid. 13.011 “PNG”]

13.011‐

ConfirmedCGA

8.1.10,

18.1.11

The variable‐resolution latent imagedata contained in the Type‐13 logicalrecord shall be uncompressed or may bethe output from a lossless compressionalgorithm.Field 13.011 shall specify the algorithmused to compress the transmittedgrayscale images.

2 M 13.011‐JPEGL‐CGA {13.011} corresponds to {SOF }2 M 13.011‐JP2L‐CGA {5th parameter of Image Header box}

EQ “7”

3

2 M 13.011‐PNG‐CGA Present(IHDR) 3

Bits_Per_Pixel 18.1.12,

19.1.12,

22.2.12

This mandatory ASCII field shall containthe number of bits used to represent apixel. This field shall contain an entry of8 for normal grayscale values of 0 to255. Any entry in this field greater than8 shall represent a grayscale pixel withincreased precision.

1 M Table_BPX_ASCII::1

3.012

{13.012} MO [8‐16]

1 M Table_BPX_ASCII::1

4.012

{14.012} MO [8‐16]

1 M Table_BPX_ASCII::1

7.012

{17.012} MO [8‐16]

13.012‐

ConfirmedBPX

18.1.12 Field 13.012 shall contain the number of

bits used to represent a pixel.

2 M 13.012‐JPEGL‐CBPX {13.012} EQ {BPX} 32 M 13.012‐JP2L‐CBPX IF {4th parameter of Image Header box}

NEQ “255”, THEN {13.012} EQ {BPX}

3

2 M 13.012‐PNG‐CBPX {13.012} EQ {BPX} 3

Finger_Palm_Positi

on

18.1.13 This mandatory tagged field shall

contain one or more possible finger orpalm positions that may match thelatent image. The decimal code numbercorresponding to the known or mostprobable finger position shall be takenfrom Table 12 or the most probablepalm position from Table 35 and enteredas a one‐ or two‐character ASCIIsubfield. Additional finger and/or palmpositions may be referenced by enteringthe alternate position codes as subfieldsseparated by the ASCII RS separatorcharacter. The code 0, for 'UnknownFinger', shall be used to reference everyfinger position from one through ten.The code 20, for 'Unknown Palm', shallbe used to reference every listedpalmprint position. Code 19 shall beused to reference one or more parts ofan EJI or tip.

1 M Finger_Palm_Positi

on::13.013

{13.013} MO Table 12 OR {13.013} MOTable 35

Subfields_Nx1 18.1.13,

19.1.13

The field shall contain one or moresubfields. Subfields are separated byASCII RS.

1 M Nx1::13.013 Count(RS_Subfields in 13.013 ) GTE 1 21 M Nx1::14.013 Count(RS_Subfields in 14.013 ) GTE 1 2

13.013::Finger_‐

Palm_Position

18.1.13

This mandatory tagged field shallcontain one or more possible finger orpalm positions that may match thelatent image. The decimal code numbercorresponding to the known or mostprobable finger position shall be taken

2 M 13.013::Finger_‐

Palm_Position

ForEach(RS_Subfield in 13.013){{RS_Subfield} MO [Table12, Table35]}

52 
from Table 12 or the most probable

palm position from Table 35 and enteredas a one‐ or two‐character ASCII

subfield. Additional finger and/or palmpositions may be referenced by enteringthe alternate position codes as subfields

separated by the ASCII RS separator

character.

Search_Position_De

scriptors

13.014::Search_‐

Position_‐

Descriptors_‐

Present

Subfields_Nx6

PPC

53 

18.1.14 This ASCII field shall be present if and

only if the finger position code 19appears in Field 13.013. It is used tonarrow the search of the latent image inthis record against a database. This fieldshall consist of two mandatoryinformation items. The first is theprobable decimal finger position code(0‐10) taken from Table 12. A “0”indicates that all the fingers of a possiblecandidate should be searched. Thesecond information item is the codetaken from Table 32 to indicate theportion of the EJI or tip image in thedatabase to search. Latent images offull‐length fingers use codes FV1 throughFV4 as defined in Table 32. Figure 7 is anillustration of the Entire Joint Image fora middle finger with each of the fullfinger views and constituent partsidentified. The EJI code is used for thecase where all four finger images are tobe considered. For the case where thelatent is to be compared to proximal,distal, or medial segments of a finger,this information item will contain theappropriate finger segment character.Multiple portions of the EJI can be listedand separated by the ASCII RS separatorcharacter.

1 O Search_Position_De

scriptors::13.014

US_SubField:1 GTE 0 ANDUS_SubField:1 LTE 10ANDUS_SubField:2 MO Table 32

2,5

18.1.14 Field 13.014: Search Position Descriptors

(SPD)This ASCII field shall be present if andonly if the finger position code "19"appears in Field 13.013.

2 O 13.014::Search

_

‐

Position_‐

Descriptors_‐

Present

IF {13.013} EQ “19” THENPresent(13.014)

18.1.15,

19.1.15

The field shall contain one or more rowsof six subfields.

1 O Nx6::13.015 Count(Subfields in 13.015 ) MOD 6 EQ

0 AND Count(Subfields in 13.015 ) GT 0

5

1 O Nx6::14.015 Count(Subfields in 14.015 ) MOD 6 EQ

0 AND Count(Subfields in 14.015 ) GT 0

5

18.1.15,

19.1.15

If finger position code 19 appears in field13.013 or 14.013, this field containsoffsets to the locations for the bounding

1 O Print_Position_Coor

dinates::13.015

Count(US_Subfields in 13.015 ) EQ 6ANDUS_Subfield:1 MO

5
box of the EJI, each of the full finger

views, or segments within the EJI. Whenused, this field shall consist of six (6)mandatory information items todescribe the type or portion of thelatent image contained in this recordand its location within an entire jointimage. The first information item is thenumber of the full finger view withvalues of FV1 through FV4. Values of FV1to FV4 specify the bounding coordinatesfor each full finger view. The secondinformation item is used to identify thelocation of a segment within a full fingerview. It will contain the not applicablecode NA if the image portion refers to afull finger view or to the entire jointimage locations. It shall contain PRX,DST, MED for a proximal, distal, ormedial segment.

[‘FV1’,’FV2’,’FV3’,’FV4’]ANDUS_Subfield:2 MO[‘NA’,’PRX’,’DST’,’MED’]

1 O Print_Position_Coor

dinates::14.015

Count(US_Subfields in 14.015 ) EQ 6ANDUS_Subfield:1 MO[‘FV1’,’FV2’,’FV3’,’FV4’]ANDUS_Subfield:2 MO[‘NA’,’PRX’,’DST’,’MED’]

2,5

PPC_Numbers 18.1.15,

19.1.15

The next four information items are thehorizontal and vertical offsets relative tothe origin positioned in the upper leftcorner of the image. The horizontaloffsets (X) are the pixel counts to theright, and the vertical offsets (Y) are thepixel counts down. The location of theimage portion is defined by thesequence of X coordinates (LEFT, RIGHT)and the Y coordinates (TOP, BOTTOM),of its bounding box.

1 O PPC_Numbers::13.0

15

{US_Subfield:3 to 6 in 13.015} GTE 0 5

1 O PPC_Numbers::14.0

15

{US_Subfield:3 to 6 in 14.015} GTE 0 5

RESERVED_FIELDS 18.1.18 Field 13.018‐019: Reserved for future

definition (RSV)These fields are reserved for definitionand inclusion in future revisions of thisstandard. None of these fields are to beused at this revision level. If any of thesefields are present, they are to beignored.

‐ ‐ 13.018‐019::‐

Reserved

Present(13.018 to 13.019)

RESERVED_FIELDS 18.1.20 Field 13.021‐023: Reserved for future

definition (RSV)These fields are reserved for definitionand inclusion in future revisions of thisstandard. None of these fields are to beused at this revision level. If any of thesefields are present, they are to beignored.

‐ ‐ 13.021‐023::‐

Reserved

Present(13.021 to 13.023)

Latent_Quality_Me

tric

18.1.21 This optional ASCII field is used to

specify one or more different metrics of

1 O Latent_Quality_Met

ric::13.024

ForEach(RS_Subfield in 13.024){

2

54 
latent image quality score data for the Count(US_Subfield) EQ 4

image stored in this record. Themeaning attributed to this metric must AND

be defined and interpreted by the

producer of the scoring algorithm or by US_Subfield:1 MO Table12 or Table 35

the person or system used to assign the

metric to the latent image. The metric AND

may be a predictor of AFIS matcher

accuracy performance or a different US_Subfield:2 GTE 0 AND

metric to indicate a value associated US_Subfield:2 LTE 100 OR

with the quality of the latent image for a US_Subfield:2 MO [254,255]

particular function.

AND

This field may contain one or moresubfields, each consisting of four US_Subfield:3 MO [IBIA Vendorinformation items separated by the "US" Registry]separator character. The firstinformation item is the code as chosen ANDfrom Table 12 or Table 35.

US_Subfield:4 GTE 1 AND

The other three items identify a quality US_Subfield:4 LTE 65535

score and the algorithm used to create }the quality score. This information is

useful to enable the recipient of thequality score to differentiate betweenquality scores generated by differentalgorithms and adjust for anydifferences in processing or analysis asnecessary.

The second information item shall be a

quantitative expression of the predicted

matching performance of the biometric

sample. This item contains the ASCII

representation of the integer imagequality score between 0 and 100

assigned to the image data by a quality

algorithm. Higher values indicate betterquality. An entry of “255” shall indicate a

failed attempt to calculate a qualityscore. An entry of “254” shall indicatethat no attempt to calculate a quality

score was made. The use of additional

values to convey other information

should be harmonized with ISO/IEC19794 standards.

The third information item shall specify

the ID of the vendor of the quality

algorithm used to calculate the qualityscore. This 4‐digit hex value is assignedby IBIA and expressed as four ASCII

55 
characters. The IBIA shall maintain the

Vendor Registry of CBEFF BiometricOrganizations that will map the value inthis field to a registered organization.The fourth information item shall specifya numeric product code assigned by thevendor of the quality algorithm, whichmay be registered with the IBIA, butregistration is not required. It indicateswhich of the vendor’s algorithms wasused in the calculation of the qualityscore. This field contains the ASCIIrepresentation of the integer productcode and should be within the range 1to 65,535.

Subfields_Nx4 18.1.21,

19.1.23,

19.1.24

The field shall contain one or more rowsof four subfields.

1 O Nx4::13.024 Count(Subfields in 13.024 ) MOD 4 EQ

0 AND Count(Subfields in 13.024 ) GT 0

1 O Nx4::14.023 Count(Subfields in 14.023 ) MOD 4 EQ

0 AND Count(Subfields in 14.023 ) GT 0

1 O Nx4::14.024 Count(Subfields in 14.024 ) MOD 4 EQ

0 AND Count(Subfields in 14.024 ) GT 0

IBIA_Quality_‐

Vendor

18.1.21 Field 13.024: Latent quality metric

(LQM)This optional ASCII field is used tospecify one or more different metrics oflatent image quality score data for theimage stored in this record. ...The third information item shall specifythe ID of the vendor of the qualityalgorithm used to calculate the qualityscore. This 4‐digit hex value is assignedby IBIA and expressed as four ASCIIcharacters. The IBIA shall maintain theVendor Registry of CBEFF BiometricOrganizations that will map the value inthis field to a registered organization.

2 O 13.024::IBIA_‐

Quality_Vendor

The code exists in the IBIA VendorRegistry of CBEFF BiometricOrganizations.

RESERVED_FIELDS 18.1.22 Field 13.025‐199: Reserved for future

definition (RSV)These fields are reserved for definitionand inclusion in future revisions of thisstandard. None of these fields are to beused at this revision level. If any of thesefields are present, they are to beignored.

‐ ‐ 13.025‐199::‐

Reserved

Present(13.025 to 13.199)

13.999‐ValidImage 18.1.24 Field 13.999 shall contain all of the data

from a captured latent image.

2 M 13.999‐Valid‐

Uncomp

Length(Field 13.999) EQ {13.006} *{13.007}

2 M 13.999‐Valid‐JPEGL Present(SOI, SOF, EOI)

56 
2 M 13.999‐Valid‐JP2L Present(SigBox, HeadBox, Image

Header box)

2 M 13.999‐Valid‐PNG Present(PNGSIG, IHDR, IDAT, IEND)

13::FsAtEnd 18.2 End of Type‐13 variable‐resolution latent

image recordFor the sake of consistency, immediatelyfollowing the last byte of data from field13.999 an ASCII FS separator shall beused to separate it from the next logicalrecord. This separator must be includedin the length field of the Type‐13 record.

2 M 13::FsAtEnd Last(Byte in Record) EQ ASCII FS

Type 14 Requirements and Assertions

14::MandatoryField

s

19.1,

Table 33

For each field of the Type‐14 record,Table 33 lists the "condition code" asbeing mandatory "M" or optional"O"...and occurrence limits.

2 M 14::CondCode_M IF "Cond code" EQ "M" in Table 33, the

Field must be present in the record.

2 M 14.xxx‐

MaxOccurrences

Count(14.xxx) LTEMaxOccurrences(14.xxx)

2 M 14.xxx‐

MinOccurrences

Count(14.xxx) GTEMinOccurrence(14.xxx)

14::FixedPositionFi

elds

19.1 It is required that the first two fields of

the record are ordered, and the fieldcontaining the image data shall be thelast physical field in the record.

2 M 14.001::LEN_First First(Field in Record) ST Type(Record)

EQ 14 AND Field EQ 14.001

2 M 14.002::IDC_Second Second(Field in Record) ST

Type(Record) EQ 14 AND Field EQ14.002

2 M 14.999::DATA_Last Last(Field in Record) ST Type(Record)

EQ 14 AND Field EQ 14.999

14::Len=Bytes 19.1.1 Field 14.001: Logical record length (LEN)

This mandatory ASCII field shall containthe total count of the number of bytes inthe Type‐14 logical record. Field 14.001shall specify the length of the recordincluding every character of every fieldcontained in the record and theinformation separators.

2 M 14.001::Len=Bytes {14.001} EQ Length(Record)

14::IDC=CNT_IDC 19.1.2 Field 14.002: Image designation

character (IDC)This mandatory ASCII field shall be usedto identify the fingerprint image datacontained in the record. This IDC shallmatch the IDC found in the file content(CNT) field of the Type‐1 record.

2 M 14.002::IDC=CNT_‐

IDC

The IDC matches the value of thecorresponding CNT field of the Type‐1record.

Table_11_Finger_T

agFld

19.1.3 The field value shall be selected from

Table 11.

1 M Table_11_Finger::1

4.003

{14.003} MO Table 11

14.006‐HLL 19.1.6 Field 14.006 shall contain the number of

pixels contained on a single horizontal

2 M 14.006‐JPEGB‐

JPEGL‐HLL

{14.006} EQ { Image Width} 3

57 
line of the transmitted image. 2 M 14.006‐JP2‐JP2L‐

HLL

{14.006} EQ { Image Width} 3

2 M 14.006‐PNG‐HLL {14.006} EQ { Image Width} 32 M 14.006‐WSQ‐HLL {14.006} EQ { Image Width} 3

14.007‐VLL 19.1.7 Field 14.007 shall contain the number of

horizontal lines contained in thetransmitted image.

2 M 14.007‐JPEGB‐

JPEGL‐VLL

{14.007} EQ { Image Height } 3

2 M 14.007‐JP2‐JP2L‐

VLL

{14.007} EQ { Image Height } 3

2 M 14.007‐PNG‐VLL {14.007} EQ { Image Height } 32 M 14.007‐WSQ‐VLL {14.007} EQ { Image Height } 3

14.008‐SLC 19.1.8 Field 14.008 shall specify the units used

to describe the image samplingfrequency (pixel density).

2 M 14.008‐JPEGB‐

JPEGL‐SLC

IF Present(JFIF Header) THENField 14.008 EQ {Sampling Units}

3

2 M 14.008‐JP2‐JP2L‐

SLC

No Implementation 4

2 M 14.008‐PNG‐SLC IF Present(PHYS Chunk) THEN

IF {14.008} EQ 1 OR 2 THEN{Sampling Units} EQ 1, ELSE IF {14.008}EQ 0 THEN{Sampling Units} EQ 0

3

2 M 14.008‐WSQ‐SLC No Implementation 4

14.009‐HPS 19.1.9 Field 14.009 shall specify the integer

pixel density used in the horizontaldirection of the transmitted image if theSLC field contains a 1 or 2. Otherwise, itindicates the horizontal component ofthe pixel aspect ratio.

2 M 14.009‐JPEGB‐

JPEGL‐HPS

IF {14.008} EQ “1” OR “2”, THEN

IF Present(JFIF Header) THEN

{14.009} EQ {Horizontal Density}

3

2 M 14.009‐JP2‐JP2L‐

HPS

No Implementation 4

2 M 14.009‐PNG‐HPS IF Present(PHYS Chunk) THEN

IF {14.008} EQ “1”, THEN{14.009} EQ {Horizontal Density} *0.0254 (meters/inch)ELSE IF {14.008} EQ “2”, THEN{14.009} EQ {Horizontal Density} * 0.01(meters/cm)

3

2 M 14.009‐WSQ‐HPS No Implementation 42 M 14.009‐JPEGB‐

JPEGL‐HorzAspect

IF {14.008} NEQ “1” OR “2”, THEN{14.009} EQ {Horizontal Density} /{Vertical Density}

3

2 M 14.009‐JP2‐JP2L‐

HorzAspect

No Implementation 4

2 M 14.009‐PNG‐

HorzAspect

IF Present(PHYS Chunk), THENIF {14.008} NEQ “1” OR “2”, THEN{14.009} EQ {Horizontal Density} /{Vertical Density}

3

2 M 14.009‐WSQ‐

HorzAspect

No Implementation 4

14.010‐VPS 19.1.10 Field 14.010 shall specify the integer

pixel density used in the verticaldirection of the transmitted image if theSLC field contains a 1 or 2. Otherwise, itindicates the vertical component of thepixel aspect ratio.

2 M 14.010‐JPEGB‐

JPEGL‐VPS

IF {14.008} EQ “1” OR “2”, THENIF Present(JFIF Header) THEN

{14.010} EQ {Vertical Density}

3

2 M 14.010‐JP2‐JP2L‐

VPS

No Implementation 4

2 M 14.010‐PNG‐VPS IF Present(PHYS Chunk) THEN 3

58 
IF {14.008} EQ “1”, THEN

{14.010} EQ {Vertical Density} * 0.0254(meters/inch)ELSE IF {14.008} EQ “2”, THEN{14.010} EQ {Vertical Density} * 0.01(meters/cm)

2 M 14.010‐WSQ‐VPS No Implementation 42 M 14.010‐JPEGB‐

JPEGL‐VerAspect

IF {14.008} NEQ “1” OR “2”, THEN{14.010} EQ {Horizontal Density} /{Vertical Density}

3

2 M 14.010‐JP2‐JP2L‐

VerAspect

No Implementation 4

2 M 14.010‐PNG‐

VerAspect

IF Present(PHYS Chunk), THENIF {14.008} NEQ “1” OR “2”, THEN{14.010} EQ {Horizontal Density} /{Vertical Density}

3

2 M 14.010‐WSQ‐

VerAspect

No Implementation 4

Table_1_ASCII 19.1.11 The field value shall be selected from

Table 1.

1 M Table_1_ASCII::14.0

11

{14.011} MO Table 1

14.011‐

ConfirmedCGA

19.1.11 Field 14.011 shall specify the algorithm

used to compress the color or grayscaleimage.

2 M 14.011‐JPEGB‐

JPEGL‐CGA

{14.011} corresponds to {SOF} 3

2 M 14.011‐JP2‐JP2L‐

CGA

{5th parameter of Image Header box}EQ “7”

2 M 14.011‐PNG‐CGA Present(IHDR) 32 M 14.011‐WSQ‐CGA Present(SOF) AND Present(4th and 5th

parameters not counting the SOFmarker)

3

14.012‐

ConfirmedBPX

19.1.12 Field 14.012 shall contain the number of

bits used to represent a pixel.

2 M 14.012‐JPEGB‐

JPEGL‐CBPX

{14.012} EQ {BPX} 3

2 M 14.012‐JP2‐JP2L‐

CBPX

IF {4th parameter of Image Header box}NEQ “255”, THEN {14.012} EQ {BPX}

3

2 M 14.012‐PNG‐CBPX {14.012} EQ {BPX} 32 M 14.012‐WSQ‐CBPX No Implementation 4

Table_12_Subfields 19.1.13 The field value shall be selected from

Table 12.

1 M Table_12_Subfields:

:14.013

{14.013} MO Table 12

14.013::FGP++ 19.1.13 Field 14.013: Finger position (FGP)

Additional finger positions may bereferenced in the transaction byentering the alternate finger positions assubfields separated by the ASCII RSseparator character.

2 M 14.013::FGP++ Additional finger positions may be

referenced in the transaction byentering the alternate finger positionsas subfields separated by the ASCII RSseparator character.

Print_Position_Des

criptors

19.1.14 This ASCII field shall be present if and

only if the finger position code 19appears in Field 14.013. This field shallconsist of two mandatory informationitems. The first is the probable decimalfinger position code (0‐10) taken fromTable 12. The second information item is

1 O Print_Position_Desc

riptors::14.014

{US_Subfield:1} GTE 0 AND{US_Subfield:1} LTE 10AND{US_Subfield:2} MO Table 32

2,5

59 
the code taken from Table 32 to indicate

the portion of the EJI or tip image that isstored as a single image in the database.There may be up to 17 such images for asingle finger. Images of full‐lengthfingers use codes FV1 through FV4 asdefined in Table 32. Figure 7 is anillustration of the Entire Joint Image fora middle finger with each of the fullfinger views and constituent partsidentified.

14.014::Print_‐

Position_‐

Descriptors_‐

Present

19.1.14 Field 14.014: Print Position Descriptors

(PPD)This ASCII field shall be present if andonly if the finger position code "19"appears in Field 14.013.

2 O 14.014::Print_‐

Position_‐

Descriptors_‐

Present

IF {14.013} EQ “19” THENPresent(14.014)

Amputated_Or_Ba

ndaged

19.1.18 The value shall be XX or UP. 1 O Amputated_Or_Da

maged::14.018

{14.018} MO [XX, UP]

RESERVED_FIELDS 19.1.19 Field 14.019: Reserved for future

definition (RSV)These fields are reserved for definitionand inclusion in future revisions of thisstandard. None of these fields are to beused at this revision level. If any of thesefields are present, they are to beignored.

‐ ‐ 14.019::Reserved Present(14.019)

Subfields_Nx5 19.1.21 The field shall contain one or more rows

of five subfields.

1 O Nx5::14.021 Count(Subfields in 14.021 ) MOD 5 EQ

0 AND Count(Subfields in 14.021 ) GT 0

Finger_Segment_Po

sitions

19.1.21 This optional ASCII field shall contain

offsets to the locations of imagesegments containing the individualfingers within the flat images of the foursimultaneous fingers from each hand orthe two simultaneous thumbs. Theoffsets are relative to the originpositioned in the upper left corner ofthe image. The horizontal offsets (X) arethe pixel counts to the right, and thevertical offsets (Y) are the pixel countsdown. A finger segment is defined bythe FINGER NUMBER, the X coordinates(LEFT, RIGHT) and the Y coordinates(TOP, BOTTOM), of its bounding box.The five information items within afinger segment definition are separatedby the ASCII US separator character.Individual finger segment definitions are

1 O Finger_Segment_Po

sitions::14.021

ForEach(RS_Subfield in 14.021){Count(US_Subfield) EQ 5AND{US_Subfield:1} MO Table 12AND{US_Subfield:2 to 5} GTE 0}

2

60 
separated by the ASCII RS separator

character.. If more than one algorithm isused to segment the image, successive

sets finger segmentation positions shallbe formatted as above and immediatelyfollow the previous set.

NIST_Quality_Metri

c

Segmentation_Qual

ity_Metric

61 

19.1.22 This optional ASCII field shall contain the

NIST Fingerprint Image Quality (NFIQ)scores for the individual finger(s) derivedfrom the slap impressions or individualrolled fingerprints. It consists of twoinformation items. The first item is thefinger number between one and ten aschosen from Table 12. The second itemis the quality score which is aquantitative expression of the predictedAFIS matcher accuracy performance ofthe fingerprint image. The scores rangefrom 1 for the best quality image, to 5for the worst quality image. A 254indicates that no score was evercomputed while an entry of 255 shallindicate a failed attempt to calculate theimage quality metric. These twoinformation items are separated by theASCII US separator character. Individualfinger quality definitions are separatedby the ASCII RS separator character.

1 O NIST_Quality_Metri

c::14.022

ForEach(RS_Subfield in 14.022){{US_Subfield:1} GTE 1 AND{US_Subfield:1} LTE 10 AND{US_Subfield:2} MO[1,2,3,4,5,254,255]}

2

19.1.23 This optional ASCII field provides a

measure of estimated correctnessregarding the accuracy of the location ofthe segmented finger within the right orleft four finger or two thumbs slapimage. For each segmented finger, thisfield shall contain four information itemsseparated by the ASCII US separatorcharacter. The first information item isthe finger number between one and tenas chosen from Table 12. The otherthree items identify a quality score andthe algorithm used to create the qualityscore. This information is useful toenable the recipient of the quality scoreto differentiate between quality scoresgenerated by different algorithms andadjust for any differences in processingor analysis as necessary. The secondinformation item shall be a measure ofestimated correctness regarding theaccuracy of the location of thesegmented finger. This item contains theASCII representation of the integer

1 O Segmentation_Qual

ity_Metric::14.023

ForEach(RS_Subfield in 14.023){Count(US_Subfield) EQ 4AND{US_Subfield:1} GTE 1 AND{US_Subfield:1} LTE 10AND{US_Subfield:2} GTE 0 AND{US_Subfield:2} LTE 100 OR{US_Subfield:2} MO [254,255]AND{US_Subfield:3} MO [IBIA VendorRegistry]AND{US_Subfield:4} GTE 1 AND{US_Subfield:4} LTE 65535 OR

2
62 

image quality score between 0 and 100assigned to the image data by a qualityalgorithm. Higher values indicate betterquality. An entry of 255 shall indicate afailed attempt to calculate a qualityscore. An entry of 254 shall indicate thatno attempt to calculate a quality scorewas made. The use of additional valuesto convey other information should beharmonized with ISO/IEC 19794standards. The third information itemshall specify the ID of the vendor of thequality algorithm used to calculate thequality score. This 4‐digit hex value isassigned by IBIA and expressed as fourASCII characters. The IBIA shall maintainthe Vendor Registry of CBEFF BiometricOrganizations that will map the value inthis field to a registered organization.The fourth information item shall specifya numeric product code assigned by thevendor of the quality algorithm, whichmay be registered with the IBIA, butregistration is not required. It indicateswhich of the vendor’s algorithms wasused in the calculation of the qualityscore. This field contains the ASCIIrepresentation of the integer productcode and should be within the range 1to 65535. This subfield is repeated foreach segmented finger whosecoordinates appear in field 14.021. TheASCII RS separator character, separateseach set of four information items. Forthe case where more than onesegmentation algorithm is applied to amulti‐finger plain image, the set ofsegmentation information items foreach finger shall be orderedcorresponding to the entries in field14.021.

19.1.23 Field 14.023: Segmentation quality

metric (SQM)The third information item shall specifythe ID of the vendor of the qualityalgorithm used to calculate the qualityscore. This 4‐digit hex value is assignedby IBIA and expressed as four ASCIIcharacters. The IBIA shall maintain theVendor Registry of CBEFF BiometricOrganizations that will map the value in

2 O 14.023::IBIA_‐

IBIA_Quality_‐ Quality_Vendor

Vendor

}The code exists in the IBIA VendorRegistry of CBEFF BiometricOrganizations.
this field to a registered organization.

Fingerprint_Quality

_Metric

19.1.24 This optional ASCII field is used to

specify one or more different metrics offingerprint image quality score data forthe image stored in this record. Themeaning attributed to this metric mustbe defined and interpreted by theproducer of the scoring algorithm or bythe person or system used to assign themetric to the fingerprint image. Themetric may be a predictor of AFISmatcher accuracy performance or adifferent metric to indicate a valueassociated with the quality of thefingerprint image for a particularfunction.

1 O Fingerprint_Quality

_Metric::14.024

ForEach(RS_Subfield in 14.024){Count(US_Subfield) EQ 4AND{US_Subfield:1} GTE 1 AND{US_Subfield:1} LTE 10AND{US_Subfield:2} GTE 0 AND{US_Subfield:2} LTE 100 OR{US_Subfield:2} MO [254,255]AND{US_Subfield:3} MO [IBIA VendorRegistry]AND{US_Subfield:4} GTE 1 AND{US_Subfield:4} LTE 65535 OR}

2

IBIA_Quality_‐

Vendor

19.1.24 Field 14.024: Fingerprint quality metric

(FQM)The third information item shall specifythe ID of the vendor of the qualityalgorithm used to calculate the qualityscore. This 4‐digit hex value is assignedby IBIA and expressed as four ASCIIcharacters. The IBIA shall maintain theVendor Registry of CBEFF BiometricOrganizations that will map the value inthis field to a registered organization.

2 O 14.024::IBIA_‐

Quality_Vendor

The code exists in the IBIA VendorRegistry of CBEFF BiometricOrganizations.

ASEG_1‐4_Subfields 19.1.25 The field shall consist of 1 to 4 subfields. 1 O ASEG_1_To_4_Subf

ields::14.025

Count(Subfields in 14.025 ) MO [1‐4]

ASEG_3To99 19.1.25 This field uses an n‐vertex polygon to

encompass each finger image segment,where 'n' is between 3 and 99.

1 O ASEG_3_To_99_Seg

ments::14.025

Count(Subfield Vertices in 14.025 ) MO[3 to 99]

ASEG_FingerNum 19.1.25 Each subfield shall consist of a finger

number between 1 and 10, the totalnumber of vertices of the polygonencompassing the finger, and the set ofconsecutive vertices.

1 O ASEG_Finger_Numb

er_1‐10::14.025

ForEach(ASCII RS_Subfield in Record){First(US_Subfield in RS_Subfield) MO [1to 10]}

ASEG_Order 19.1.25 The order of the vertices must be in 1 O ASEG_Consecutive_ Angle.Direction.First EQ ((X,Y).1 To

63 
their consecutive order around the

perimeter of the polygon, eitherclockwise or counterclockwise.

Order::14.025 (X,Y).2).Angle.Direction; ((X,Y).2 To N‐

1 to (X,Y).3 To N).Angle.Direction EQAngle.Direction.First; ((X,Y).N To(X,Y).1).Angle.Direction EQAngle.Direction.First

ASEG_XY_GE_Zero 19.1.25 Each vertex shall be represented as

horizontal and vertical pixel offsetsrelative to the origin positioned in theupper left corner of the image. Thehorizontal offsets (X) are the pixelcounts to the right, and the verticaloffsets (Y) are the pixel counts downfrom the origin.

1 O ASEG_XY_GE_Zero::

14.025

(X,Y) ST X GTE 0 AND Y GTE 0

14.025 ASEG 19.1.25 The order of the vertices must be in

their consecutive order around theperimeter of the polygon, eitherclockwise or counterclockwise.

2 O ASEG_Consecutive_

Order

Not supported in this version 6

14.025 ASEG 19.1.25 No two vertices may occupy the same

location.

2 O ASEG_No_Duplicate

_Vertices

Each Vertex (X, Y) is unique

14.025 ASEG 19.1.25 The polygon must be a simple, plane

figure with no sides crossing and nointerior holes.

2 O ASEG_Simple_Plane

_Figure

No implementation 6

14.025 ASEG 19.1.25 2 O ASEG_No_Sides_‐

Crossing

No implementation 6

14.025 ASEG 19.1.25 2 O ASEQ_No_‐

Interior_Holes

No implementation 6

14.025 ASEG 19.1.25 This field shall consist of one to four

subfields.

2 O ASEG_Num_Sub‐

fields

1 LTE Count( Subfields) LTE 4

14.025 ASEG 19.1.25 Each subfield shall consist of a finger

number between 1 and 10, the totalnumber of vertices of the polygonencompassing the finger, and the set ofconsecutive vertices. A minimum ofthree points is required to describe afinger location.

1 O ASEG_Finger‐

Number

1 LTE Finger Number LTE 10

1 O ASEG_3_To_99_‐

Segments

3 LTE Segments LTE 99

2 O ASEG_Expected_‐

Information_Items

Expected Cols EQ 1 (Finger #) + 1 (#Vertices) + (2 * # Vertices ((x, y) pairs))ExpectedCols = 2 + 2 * # Vertices

14.025 ASEG 19.1.25 Each vertex shall be represented as

horizontal and vertical pixel offsetsrelative to the origin positioned in theupper left corner of the image.The horizontal offsets (X) are the pixelcounts to the right, and the verticaloffsets (Y) are the pixel counts downfrom the origin.

2 O

ASEG_XY_Offsets_G

E_Zero

For Each (X, Y)

X GTE 0 ANDY GTE0

14.025 ASEG 19.1.25 An ASCII US separator character shall be

used to separate the finger number, thenumber of vertices, each X coordinate,and each Y coordinate.

2 O 14.025‐US Character separator between finger

number, the number of vertices, eachX coordinate, and each Y coordinate EQ“US”

14.025 ASEG 19.1.25 Subfields representing each finger are

delimited by the ASCII RS separator

2 O 14.025‐RS Character separator between subfields

representing each finger EQ ASCII RS

64 
character.

RESERVED_FIELDS 19.1.26 Field 14.026‐029: Reserved for future

definition (RSV)These fields are reserved for definitionand inclusion in future revisions of thisstandard. None of these fields are to beused at this revision level. If any of thesefields are present, they are to beignored.

‐ ‐ 14.026‐029::‐

Reserved

Present(14.026 to 14.029)

RESERVED_FIELDS 19.1.28 Field 14.031‐199: Reserved for future

definition (RSV)These fields are reserved for definitionand inclusion in future revisions of thisstandard. None of these fields are to beused at this revision level. If any of thesefields are present, they are to beignored.

‐ ‐ 14.031‐199::‐

Reserved

Present(14.031 to 14.199)

14.999‐ValidImage 19.1.30 Field 14.999 shall contain all of the data

from a captured tenprint image.

2 M 14.999‐Valid‐

Uncomp

Length(Field 14.999) EQ {14.006} *{14.007}

2 M 14.999‐Valid‐

JPEGB‐JPEGL

Present(SOI, SOF, EOI) 3

2 M 14.999‐Valid‐JP2‐

JP2L

Present(SigBox, HeadBox, ImageHeader box)

3

2 M 14.999‐Valid‐PNG Present(PNGSIG, IHDR, IDAT, IEND) 32 M 14.999‐Valid‐WSQ Present(SOI, SOF, SOB, EOI) 3

14::FsAtEnd 19.2 End of Type‐14 variable‐resolution

fingerprint image recordFor the sake of consistency, immediatelyfollowing the last byte of data from field14.999 an ASCII FS separator shall beused to separate it from the next logicalrecord. This separator must be includedin the length field of the Type‐14 record.

1 M 14::FsAtEnd Last(Byte in Record) EQ ASCII FS

Type 17 Requirements and Assertions

65 

17::FixedPositionFi

elds

22.2 It is required that the first two fields of

the record are ordered, and the fieldcontaining the iris binary data shall bethe last physical field in the record.

2 M 17.001::LEN_First First(Field in Record) ST Type(Record)

EQ 17 AND Field EQ 17.001

2 M 17.002::IDC_Second Second(Field in Record) ST

Type(Record) EQ 17 AND Field EQ17.002

2 M 17.999::DATA_Last Last(Field in Record) ST Type(Record)

EQ 17 AND Field EQ 17.999

17::MandatoryField

s

22.2,

Table 37

For each field of the Type‐17 record,Table 37 lists the "condition code" asbeing mandatory "M" or optional"O"...and occurrence limits.

2 M 17::CondCode_M IF "Cond code" EQ "M" in Table 37, the

Field must be present in the record.

2 M 17.xxx‐

MaxOccurrences

Count(17.xxx) LTEMaxOccurrences(17.xxx)
2 M 17.xxx‐

MinOccurrences

Count(17.xxx) GTEMinOccurrences(17.xxx)

17::Len=Bytes 22.2.1 Field 17.001: Logical record length (LEN)

This mandatory ASCII field shall containthe total count of the number of bytes inthe Type‐17 logical record. Field 17.001shall specify the length of the recordincluding every character of every fieldcontained in the record and theinformation separators.

2 M 17.001::‐

Value=Bytes

{17.001} EQ Length(Record)

17::IDC=TOC_IDC 22.2.2 Field 17.002: Image designation

character (IDC)This mandatory ASCII field shall be usedto identify the iris image data containedin the record. This IDC shall match theIDC found in the file content (CNT) fieldof the Type‐1 record.

2 M 17.002::IDC=TOC_‐

IDC

The IDC value matches thecorresponding IDC value in the content(CNT) field in the Type‐1 record.

17.006‐HLL 22.2.6 Field 17.006 shall contain the number of

pixels contained on a single horizontalline of the transmitted image.

2 M 17.006‐JPEGB‐

JPEGL‐HLL

{17.006} EQ {Image Width} 3

2 M 17.006‐JP2‐JP2L‐

HLL

{17.006} EQ {Image Width} 3

17.007‐VLL 22.2.7 Field 17.007 shall contain the number of

horizontal lines contained in thetransmitted image.

2 M 17.007‐JPEGB‐

JPEGL‐VLL

{17.007} EQ {Image Height} 3

2 M 17.007‐JP2‐JP2L‐

VLL

{17.007} EQ {Image Height} 3

17.008‐SLC 22.2.8 Field 17.008 shall specify the units used

to describe the image samplingfrequency (pixel density).

2 M 17.008‐JPEGB‐

JPEGL‐SLC

IF Present(JFIF Header) THEN{17.008} EQ {Sampling Units}

3

2 M 17.008‐JP2‐JP2L‐

SLC

No Implementation 4

17.009‐HPS 22.2.9 Field 17.009 shall specify the integer

pixel density used in the horizontaldirection of the transmitted image if theSLC field contains a 1 or 2. Otherwise, itindicates the horizontal component ofthe pixel aspect ratio.

2 M 17.009‐JPEGB‐

JPEGL‐HPS

IF {17.008} EQ “1” OR “2”, THEN

IF Present(JFIF Header) THEN

{17.009} EQ {Horizontal Density}

3

2 M 17.009‐JP2‐JP2L‐

HPS

No Implementation 4

2 M 17.009‐JPEGB‐

JPEGL‐HorzAspect

IF {17.008} NEQ “1” OR “2”, THEN{17.009} EQ {Horizontal Density} /{Vertical Density}

3

66 
2 M 17.009‐JP2‐JP2L‐

HorzAspect

No Implementation 4

17.010‐VPS 22.2.10 Field 17.010 shall specify the integer

pixel density used in the verticaldirection of the transmitted image if theSLC field contains a 1 or 2. Otherwise, itindicates the vertical component of thepixel aspect ratio.

2 M 17.010‐JPEGB‐

JPEGL‐VPS

IF {17.008} EQ “1” OR “2”, THENIF Present(JFIF Header) THEN

{17.010} EQ {Vertical Density}

3

2 M 17.010‐JP2‐JP2L‐

VPS

No Implementation 4

2 M 17.010‐JPEGB‐

JPEGL‐VerAspect

IF {17.008} NEQ “1” OR “2”, THEN{17.010} EQ {Horizontal Density} /{Vertical Density}

3

2 M 17.010‐JP2‐JP2L‐

VerAspect

No Implementation 4

Table_1_No_WSQ_

PNG

22.2.11 The field value shall be selected from

Table 1. WSQ and PNG are not valid.

1 M Table_1_No_WSQ_

PNG::17.011

{17.011} NOT MO [‘WSQ’, ‘PNG’] AND{17.011} MO Table 1

17.011‐

ConfirmedCGA

22.2.11 Field 17.011 shall specify the algorithm

used to compress the color or grayscaleimage.

2 M 17.011‐JPEGB‐

JPEGL‐CGA

{17.011} corresponds to {SOF} 3

2 M 17.011‐JP2‐JP2L‐

CGA

{5th parameter of Image Header box}EQ “7”

3

17.012‐

ConfirmedBPX

22.2.12 Field 17.012 shall contain the number of

bits used to represent a pixel.

2 M 17.012‐JPEGB‐

JPEGL‐CBPX

{17.012} EQ {BPX} 3

2 M 17.012‐JP2‐JP2L‐

CBPX

IF {4th parameter of Image Header box}NEQ “255”, THEN {17.012} EQ {BPX}

4

17.013‐CSP 22.2.13 Field 17.013 shall contain an entry from

Table 3 to identify the color space used.

2 M 17.013‐JPEGB‐

JPEGL‐CSP

No Implementation 3

2 M 17.013‐JP2‐JP2L‐

CSP

IF Present(Colour Specification box),THEN {17.013} corresponds to {CSP}

3

SubFields_1x3 22.2.16,

22.2.19

The field shall contain three subfieldsseparated by an ASCII US separatorcharacter.

1 O SubFields_1x3::17.0

16

(Rows, Cols) ST Rows EQ 1 AND Cols EQ3

1 O SubFields_1x3::17.0

19

Count(Subfields in 17.019 ) EQ 3

DeviceUniqueID 22.2.17 This optional field shall contain a 1 O DeviceUniqueID::17 First(Byte in 17.017) MO [D, M, P] OR

67 
sixteen‐byte string uniquely identifying

the device or source of the data. Thisdata can be one of: (1) Device Serialnumber, identified by the first character“D”, (2) Host PC Mac address, identifiedby the first character “M”, (3) Host PCprocessor ID, identified by the firstcharacter “P”, and (4) No serial number,identified by all zero’s.

.017 Sum(Bytes(17.017)) EQ 0

IBIA_Quality_‐

Vendor

22.2.24 Field 17.024: Image Quality Score (IQS)

... The second information item shallspecify the ID of the vendor of thequality algorithm used to calculate thequality score. This 4‐digit hex value isassigned by IBIA and expressed as fourASCII characters. The IBIA shall maintainthe Vendor Registry of CBEFF BiometricOrganizations that will map the value inthis field to a registered organization.

2 O 17.024::IBIA_‐

Quality_Vendor

The value is in the IBIA Vendor Registryof CBEFF Biometric Organizations.

NirVisOther 22.2.25 This optional field indicates the lighting

spectrum used in capturing the irisimage. Values shall be one of thefollowing: NIR for near‐infraredillumination (~700‐850nm), VIS forvisible full spectrum illumination (~380‐740nm), or OTHER for otherillumination.

1 O NIR_VIS_OTHER::17

.025

{17.025} MO [‘NIR’, ‘VIS’, ‘OTHER’]

17.026‐IRD 22.2.26,

Table 37

Field 17.026 shall specify the expectediris diameter in pixels.

2 O 17.026‐IRD {17.026} LTE Min({17.006},{17.007})

17.999‐ValidImage 22.2.31 Field 17.999 shall contain the iris image. 2 M 17.999‐Valid‐

Uncomp

Length(F13.999) EQ {13.006} * {13.007}

2 M 17.999‐Valid‐

JPEGB‐JPEGL

Present(SOI, SOF, EOI)

2 M 17.999‐Valid‐JP2‐

JP2L

Present(SigBox, HeadBox, ImgBox)

Test Notes: 1. Requirements related to International Character Sets are not tested in this version of the CTS. 2. Subfields are defined as follows: • RS_Subfield:N= Any subfield that uses the ASCII RS separator character. If N is specified, N represents the Nth such su

• US_Subfield:N = Any subfield that uses the ASCII US separator character. If N is specified, N represents the Nth such su

• Subfield(s) = If a prefix is not specified (US or RS), then the type of subfield should be clear from the context of the requ

68 
3. The table lists assertions for multiple image format types, however, based upon the compression algorithm specified in the 

are to be tested in different ways. Features of the image metadata are defined as follows: • Image Width 

o JPEG, JPEGL: 4th parameter of the Frame Header not counting the SOF marker 

o JP2,JP2L: 2nd parameter of Image Header box 

o PNG: 1st parameter of IHDR chunk 

o WSQ: 5th parameter of SOF not counting the SOF marker 

• Image Height 

o JPEG, JPEGL: 3rd parameter of the Frame Header not counting the SOF marker 

o JP2,JP2L: 1st parameter of Image Header box 

o PNG: 2nd parameter of IHDR chunk 

o WSQ: 4th parameter of SOF not counting the SOF marker 

• Image metadata markers 

o JPEG, JPEGL: SOI – Start of Image, SOF – Start of Frame, EOI – End of Image o JP2, JP2L: SigBox – JP2 Signature box, HeadBox – JP2 Header box, ImgBox – Image Header box o PNG: PNGSig – PNG Signature, IHDR – IHDR Chunk, IDAT – IDAT Chunk, IEND – IEND Chunk 

o WSQ: SOI – Start of Image, SOF – Start of Frame , SOB – Start of Block, EOI – End of Image 

• Sampling Units 

o JPEG, JPEGL: 4th parameter in JFIF Header not counting the APP0 Marker 

o JP2, JP2L: Undefined o PNG: 3rd parameter of PHYS chunk 

o WSQ: Undefined 

• Horizontal Density 

o JPEG, JPEGL: 5th parameter in JFIF Header not counting the APP0 Marker 

o JP2, JP2L: Undefined o PNG: 1st parameter in PHYS Chunk 

o WSQ: Undefined 

• Vertical Density 

o JPEG, JPEGL: 6th parameter in JFIF Header not counting the APP0 Marker 

o JP2, JP2L: Undefined o PNG: 2nd parameter in PHYS Chunk 

o WSQ: Undefined 

• BPX 

69 
o JPEG, JPEGL: 2nd parameter of the Frame Header not counting the SOF marker 

o JP2, JP2L: 7 LSB of 4th parameter of Image Header box + 1 

o PNG: 3rd parameter of IHDR chunk 

o WSQ: Undefined 

• CSP 

o JPEG,JPEGL: Undefined o JP2, JP2L: 4th parameter of Colour Specification box 

o PNG: 4th parameter of IHDR chunk 

o WSQ: Undefined 

4. The image metadata required to implement the assertion is not defined in the image standard documentation. 5. While the ANSI/NIST-ITL 1-2007 standard defines only the “M” and “O” statuses for each field, this field is conditional u

field(s). 6. The required algorithm for this assertion is under research. 

70