Information Technology:

American National Standard for Information 

Systems— 

Data Format for the Interchange of Fingerprint 

Facial, & Other Biometric Information – Part 1

NIST Special Publication 500-271 ANSI/NIST-ITL 1-2007 

Revision of 

ANSI/NIST-ITL 1-2000

NIST Special Publication 500-271 

Information Technology:

American National Standard for 

Information Systems— 

Data Format for the Interchange of Fingerprint, 

Facial, & Other Biometric Information – Part 1 

R. Michael McCabe and Elaine M. Newton, Editors 

Sponsored by 

Information Access Division 

Information Technology Laboratory 

National Institute of Standards and Technology 

Gaithersburg, MD 20899-8940

May 2007 

U.S. Department of Commerce 

Carlos M. Gutierrez, Secretary 

Technology Administration 

Robert Cresanti, Under Secretary of Commerce for Technology 

National Institute of Standards and Technology 

William Jeffrey, Director 

ANSI/NIST-ITL 1-2007 

Revision of 

ANSI/NIST-ITL 1-2000

Approved April 20, 2007 

American National Standards Institute, Inc. 
Certain commercial entities, equipment, or materials may be identified in this document to assign field numbers 

to registered vendors or to describe a 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. 

National Institute of Standards and Technology 

Special Publication 500-271 

Natl. Inst. Stand. Technol. 

Spec. Publ. 500-271 

162 pages (May 2007) 

CODEN: NSPUE2 

Reports on Information Technology 

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

Technology (NIST) stimulates U.S. economic growth and industrial competitiveness through technical 

leadership and collaborative research in critical infrastructure technology, including tests, test methods, 

reference data, and forward-looking standards, to advance the development and productive use of 

information technology. To overcome barriers to usability, scalability, interoperability, and security in 

information systems and networks, ITL programs focus on a broad range of networking, security, and 

advanced information technologies, as well as the mathematical, statistical, and computational sciences. 

This Special Publication 500-series reports on ITL’s research in tests and test methods for information 

technology, and its collaborative activities with industry, government, and academic organizations. 

This document is a contribution of the National Institute of Standards and Technology and is 

not subject to copyright. Any organization interested in reproducing ANSI/NIST-ITL 1-2007 

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

1 is free to do so. However there shall be no alteration to any of the material contained in the 

document. NIST retains the sole right to submit this standard to any other forum for any 

purpose. 
Part 1 ANSI/NIST-ITL 1-2007

i

Contents 

Foreword .................................................................................................................vii

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

2 Scope, purpose, and conformance .......................................................................................... 1

2.1 Scope.................................................................................................................................. 1

2.2 Purpose .............................................................................................................................. 2

2.3 Conformance ...................................................................................................................... 2

3 Normative References.............................................................................................................. 2

4 Definitions................................................................................................................................. 4

5 Transmitted data conventions .................................................................................................. 6

5.1 Fingerprint Ridge Representation....................................................................................... 6

5.2 Byte and bit ordering .......................................................................................................... 6

5.3 Grayscale data ................................................................................................................... 6

5.4 Binary data.......................................................................................................................... 7

5.5 Color data ........................................................................................................................... 7

5.6 Compression algorithms..................................................................................................... 7

5.7 Color spaces....................................................................................................................... 9

5.8 Scan sequence................................................................................................................. 10

6 Image resolution requirements............................................................................................... 11

6.1 Scanner resolution requirement ....................................................................................... 11

6.2 Transmitting resolution requirement................................................................................. 12

7 File description ....................................................................................................................... 12

7.1 File format......................................................................................................................... 13

7.2 File contents ..................................................................................................................... 14

7.3 Implementation domains .................................................................................................. 14

7.4 Image designation character (IDC) .................................................................................. 15

8 Record description ................................................................................................................. 16
Part 1 ANSI/NIST-ITL 1-2007

ii

8.1 Logical record types ......................................................................................................... 16

8.2 Record format................................................................................................................... 20

9 Type-1 transaction information record ................................................................................... 23

9.1 Fields for Type-1 transaction information record.............................................................. 23

9.2 End of transaction information record Type-1 .................................................................. 28

10 Type-2 user-defined descriptive text record........................................................................... 28

10.1 Fields for Type-2 logical records.................................................................................. 28

10.2 End of Type-2 user-defined descriptive text record ..................................................... 28

10.3 Additional user-defined descriptive text records .......................................................... 28

11 Type-3 through Type-6 fingerprint image records.................................................................. 29

11.1 General......................................................................................................................... 29

11.2 Types 3-6 logical record field descriptions................................................................... 29

11.3 End of fixed-resolution fingerprint image record .......................................................... 32

11.4 Additional fixed-resolution fingerprint image records................................................... 32

12 Type-7 user-defined image record ......................................................................................... 32

12.1 Fields for Type-7 logical record.................................................................................... 33

12.2 End of Type-7 user-defined image record ................................................................... 33

12.3 Additional user-defined image records ........................................................................ 33

13 Type-8 signature image record .............................................................................................. 34

13.1 Fields for Type-8 logical record.................................................................................... 34

13.2 End of Type-8 signature image record......................................................................... 36

13.3 Additional signature...................................................................................................... 36

14 Type-9 minutiae data record .................................................................................................. 36

14.1 Minutiae and other information descriptors (Standard Format) ................................... 37

14.2 Fields for Type-9 logical record (Standard Format) ..................................................... 39

14.3 End of Type-9 logical record ........................................................................................ 43

14.4 Additional minutiae records.......................................................................................... 43

15 Type-10 facial & SMT image record....................................................................................... 43
Part 1 ANSI/NIST-ITL 1-2007

iii

15.1 Fields for Type-10 logical record.................................................................................. 43

15.2 End of Type-10 logical record ...................................................................................... 63

15.3 Additional facial & SMT image records ........................................................................ 63

16 Type-11 record reserved for future use.................................................................................. 63

17 Type-12 record reserved for future use.................................................................................. 63

18 Type-13 variable-resolution latent image record.................................................................... 63

18.1 Fields for the Type-13 logical record............................................................................ 64

18.2 End of Type-13 variable-resolution latent image record .............................................. 70

18.3 Additional variable-resolution latent image records ..................................................... 70

19 Type-14 variable-resolution fingerprint image record ............................................................ 70

19.1 Fields for the Type-14 logical record............................................................................ 71

19.2 End of Type-14 variable-resolution fingerprint image record....................................... 78

19.3 Additional variable-resolution fingerprint image records.............................................. 78

20 Type-15 variable-resolution palmprint image record.............................................................. 79

20.1 Fields for the Type-15 logical record............................................................................ 79

20.2 End of Type-15 variable-resolution palmprint image record ........................................ 85

20.3 Additional Type-15 variable-resolution palmprint image records................................. 85

21 Type-16 user-defined testing image record ........................................................................... 85

21.1 Fields for the Type-16 logical record............................................................................ 85

21.2 End of Type-16 user-defined testing image record...................................................... 90

21.3 Additional Type-16 user-defined testing image records............................................... 90

22 Type-17 Iris image record ...................................................................................................... 90

22.1 General......................................................................................................................... 90

22.2 Fields for the Type-17 logical record............................................................................ 90

22.3 End of Type-17 Iris Data Record.................................................................................. 96

22.4 Additional Type-17 Iris Data Records .......................................................................... 96

23 Type-99 CBEFF biometric data record .................................................................................. 97

23.1 Fields for the Type-99 logical record............................................................................ 97
Part 1 ANSI/NIST-ITL 1-2007

iv

23.2 End of Type-99 CBEFF Data Record......................................................................... 101

23.3 Additional Type-99 CBEFF Data Records ................................................................. 101

24 Another individual................................................................................................................. 101

Annex A 7-bit American Standard Code for Information Interchange (ASCII) ........................ 102

Annex B Use of information separator characters.................................................................... 103

Annex C Base-64 encoding scheme ........................................................................................ 104

Annex D JPEG file interchange format..................................................................................... 106

Annex E NCIC Codes for Scars, marks, tattoos, and other characteristics ............................. 113

Annex F Example transaction................................................................................................... 124

Annex G INCITS / M1 378 Minutiae Format............................................................................. 132

Annex H Best Practice Application Level 30 ............................................................................ 137

Annex I Best Practice Image Capture Requirements for SAP Levels 40, 50, and 51.............. 140

Annex J Face-Pose Values ...................................................................................................... 147

Annex K Bibliography ............................................................................................................... 150

Figures 

Figure 1 Byte and bit ordering ......................................................................................................... 6

Figure 2 Order of scanned image.................................................................................................. 11

Figure 3 Minutiae coordinate system ........................................................................................... 39

Figure 4 Examples of resolution for levels 30, 40, & 50/51.......................................................... 50

Figure 5 Feature point codes defined in ISO/IEC 14496-2 ........................................................... 58

Figure 6 Eye and nostril center feature points............................................................................... 59

Figure 7 Entire joint image............................................................................................................ 68
Part 1 ANSI/NIST-ITL 1-2007

v

Tables 

Table 1 Grayscale & color image compression codes ................................................................... 7

Table 2 Binary compression codes ................................................................................................ 9

Table 3 Color spaces...................................................................................................................... 9

Table 4 Logical record types ........................................................................................................ 13

Table 5 Number of logical records per transaction....................................................................... 15

Table 6 Resolution of Transmitted fingerprint image records ...................................................... 17

Table 7 Information separators..................................................................................................... 21

Table 8 Type-1 Transaction information record layout................................................................. 24

Table 9 Directory of character sets............................................................................................... 27

Table 10 Type 3-6 record layout................................................................................................... 29

Table 11 Finger & palm impression types .................................................................................... 30

Table 12 Finger position code & maximum image dimensions..................................................... 31

Table 13 Type-8 record layout...................................................................................................... 34

Table 14 Registered vendor minutiae blocks ............................................................................... 37

Table 15 Minutiae types ............................................................................................................... 37

Table 16 Pattern classification...................................................................................................... 41

Table 17 Type-10 facial and SMT record layout .......................................................................... 44

Table 18 Subject acquisition profiles............................................................................................ 47

Table 19 Subject pose.................................................................................................................. 51

Table 20 Photo descriptors........................................................................................................... 51

Table 21 Acquisition source type codes....................................................................................... 52

Table 22 Subject facial description codes .................................................................................... 54

Table 23 Eye color codes............................................................................................................. 55

Table 24 Hair color codes............................................................................................................. 55

Table 25 Subject feature point field.............................................................................................. 56

Table 26 Eye and nostril center feature point codes.................................................................... 57
Part 1 ANSI/NIST-ITL 1-2007

vi

Table 27 Device monitoring modes.............................................................................................. 57

Table 28 Tattoo classes ............................................................................................................... 60

Table 29 Tattoo subclasses.......................................................................................................... 60

Table 30 Color codes ................................................................................................................... 62

Table 31 Type-13 Variable-resolution latent record layout .......................................................... 65

Table 32 EJI and tip codes........................................................................................................... 67

Table 33 Type-14 Variable-resolution fingerprint record layout ................................................... 71

Table 34 Type-15 Variable-resolution palmprint record layout .................................................... 80

Table 35 Palm codes and dimensions ......................................................................................... 84

Table 36 Type-16 Variable-resolution user-defined testing image record layout......................... 86

Table 37 Type-17 Iris image record layout................................................................................... 91

Table 38 Type-99 CBEFF biometric data record layout............................................................... 98

Table 39 CBEFF Biometric type................................................................................................... 99
Part 1 ANSI/NIST-ITL 1-2007

vii

Foreword (This foreword is not part of American National Standard 

 ANSI/NIST-ITL 1-2007) 

Various levels of law enforcement and related criminal justice agencies as well as identity 

management organizations procure equipment and systems intended to facilitate the 

determination of the personal identity of a subject from fingerprint, palm, facial (mugshot), or other 

biometric information (including iris data). To effectively exchange identification data across 

jurisdictional lines or between dissimilar systems made by different manufacturers, a standard is 

needed to specify a common format for the data exchange. To this end, this standard has been 

developed. 

Fingerprint and palmprint images are acquired from flatbed scanners, Automated Fingerprint 

Identification Systems (AFIS), live-scan fingerprint and palmprint readers, and/or image storage 

and retrieval systems. An AFIS scans and stores the digital representations of fingerprint and 

palmprint images that are captured from inked cards, chemical cards, or live-scan readers that 

acquire the fingerprint and palmprint image data directly from the subject's fingers and hands. 

The scanned images are then processed to extract specific types of features from the images. 

Sources used for the electronic capture of a subject's facial image (mugshot) and scars, marks, 

and tattoos (SMTs) present include digital still and video cameras and other types of video 

recorders that capture images and produce digital image files directly from the subject's head and 

body. Scanners are used to digitize images from photographs, pictures, or sketches. The digital 

representations of these images consist of grayscale or color pixels depending on the application 

and equipment. 

These digital images may be stored in a compressed or uncompressed form in an image storage 

and retrieval system together with textual descriptive data and other information for each image. 

When required, specific images stored on a file can be retrieved from storage and be 

incorporated as part of an electronic mugshot book, or an electronic line-up. Images selected 

may be the result of textual filters based on physical descriptive or information fields associated 

with each image. Stored SMT images can also be retrieved as part of an identification process. 

Features from the scanned fingerprint, palmprint, facial, or other biometric images can be 

compared against a masterfile containing features extracted from previously scanned images. 

The result of these comparisons is a list of potential candidate identifications. A human examiner, 

using images retrieved from the system or fingerprint cards, then can identify a subject. 

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

Technology (NIST) sponsored the development of this American National Standards Institute 

(ANSI) approved American National Standard using the NIST Canvass Method to demonstrate 

evidence of consensus. This updated standard replaces ANSI/NIST-ITL 1-2000 that address the 

interchange of fingerprint, facial, and SMT data. 

The document that follows is the conventional ANSI/NIST standard, now known as Part 1. Part 2 

will be the Extensible Markup Language (XML) version of Part 1 and is currently being developed. 

Part 1 of this standard includes eleven annexes. Annex A is normative and contains the 7-bit 

American Standard Code for Information Interchange (ASCII). Annex B is informational and 

illustrates the use of the information separator characters. Annex C is normative and describes 

the base-64 encoding scheme. Annex D, a description of the Joint Photographic Experts Group 

(JPEG) File Interchange Format (JFIF), is normative and considered part of the standard. Annex 

E is normative and contains the current version’s (December 2000) codes from the National 

Crime Information Center (NCIC) Code Manual for describing the body locations of Scars, Marks, 

and Tattoos. Annex F is a comprehensive example of a transaction file containing several logical 

record types. The image exchange records contained in Annex F are formatted in accordance 
Part 1 ANSI/NIST-ITL 1-2007

viii

with this standard and are informative and not considered as part of the standard. Annex G is 

informative and contains the INCITS/M1 378 minutiae format specifications. Informative Annexes 

H and I contain best practices for mugshots for application levels 30 through 51, respectively. 

Annex J is also informative and contains various examples of face-pose value combinations. 

Annex K is a bibliography of informative references. 

Over the past several years, many data interchange and processing applications have converted 

to or are in the process of migrating toward an XML format approach for processing data. In 

order to provide the ability to directly interface with such applications, an XML alternative 

representation of the textual, image, and other biometric information is being developed. Part 2 

of this standard will contain the XML alternative for the conventional ANSI/NIST standard. The 

goal of Part 2 will be to describe a “one-to-one” correspondence of XML elements to the 

numerically tagged conventional elements described in Part 1. The subelements (separated by 

the US and RS characters in the conventional representation) are given XML counterparts in Part 

2. 

Suggestions for the improvement of this standard are welcome. They should be sent to the 

attention of R. M. McCabe, Fingerprint Standards, Information Access Division, Image Processing 

Group, NIST, 100 Bureau Dr, Mail Stop 8940, Gaithersburg, MD 20899-8940. 

The following organizations, recognized as having an interest in the standardization of the data 

format for the interchange of fingerprint, facial, SMT, and other biometric information, were 

contacted prior to the approval of this revision of the standard. Inclusion in this list does not 

necessarily imply that the organization concurred with the submittal of the proposed standard to 

ANSI. 

Arkansas State Police, AFIS/1D Bureau Cora Gentry 

 Terri Smith (Alt.) 

Aware, Inc. Robert Mungovan 

BAE Systems Information Technology Brian Finegold 

BIO-KEY International Charles Yanak 

Biometric Information Mgmt Michael Powers 

BSI 2000, Inc. Kevin Wilson 

Bundeskriminalamt Gerd Hardt 

 Christopher Schiel (Alt.) 

BWXT Y-12 Edmon Begoli 

 Mark Patterson (Alt.) 

Cherry Biometrics Michael Cherry 

Cogent Systems, Inc. Anne Wang 

Comnetix, Inc. Henri Schueler 

Cross Match Technologies Greg Cannon 

 Ralph Lessmann (Alt.) 

Daon Matt Swayze 

Dataworks Plus Rick Johnson 

 Todd Pastorini (Alt.) 

Delaware State Police Russell McNatt 

Department of Homeland Security Brad Wing 

DOJ/National Institute of Justice Christopher Miles 
Part 1 ANSI/NIST-ITL 1-2007

ix

FBI/CJIS Tom Hopper 

 John Manzo (Alt.) 

 B. Scott Swann (Alt.) 

 Patrice Yuh (Alt.) 

FBI/Lab Stephen Meagher 

Foray Technologies David Witzke 

Higgins-Hermansen Group, LLC Peter Higgins 

 Kathleen Higgins (Alt.) 

IAI AFIS Committee, Chair Peter Komarinski 

ID Networks, Inc. Doug Blenman, II 

ID Technology Partners, Inc. Mark Jerde 

 M. Paul Collier (Alt.) 

 Tom Greiner (Alt.) 

International Biometric Group (IBG) Brian Wong 

King County Sheriff's Office Marilyn Nault 

L-1 Identity Solutions Brian Martin 

 Kirsten Nobel (Alt.) 

Lockheed Martin David Hagan 

 Scott Rogers (Alt.) 

Los Angeles Co. Sheriff's Dept. Beatriz Calderon 

 T.J. Smith (Alt.) 

Mentalix, Inc. Dale Remmers 

MN Bureau of Criminal Apprehension Jerry Olson 

Motorola Artour Karaguiozian 

 Guy Cardwell (Alt.) 

MTG Management Consultants Charles Collins 

 Terrance Gough (Alt.) 

National Background Data LLC/ 

First Advantage 

Robert Holloran 

NEC Corporation of America Stephen Dunbar 

 Scott Murdock (Alt.) 

 M. Joe Notani (Alt.) 

Netherlands National Police Agency Bastiaan Zetstra 

NIST Michael Garris 

 Elaine Newton (Alt.) 

 Stan Janet, Jr. (Alt.) 

Noblis Austin Hicklin 

 John Mayer-Splain (Alt.) 

Nortel PEC Solutions, Inc Benjamin McDowell 

NYS Div. of Criminal Justice Services Nancy Campbell 

 Mary Ann Pelletier (Alt.) 

OIPC Interpol Mark Branchflower 

OK State Bureau of Investigation Ben Gherezgiher 
Part 1 ANSI/NIST-ITL 1-2007

x

Police I.T. Organization Geoff Whitaker 

 John Flahive (Alt.) 

Raytheon Teddy Ko 

Royal Canadian Mounted Police Mark Labonte 

Saber Bonny Scheier 

Sagem Morpho, Inc. Glen McNeil 

Schenk Consultants, Inc. Manfred Schenk 

SEARCH Catherine Plummer 

SPEX Forensics James Kearney 

 George Setola (Alt.) 

Steria JR Vanden Eynde 

TBS North America, Inc. William Long 

Texas Department of Public Safety Mike Lesko 

Toronto Police Service Newton Phoon 

Transport Canada John Ouellette 

United States Army Biometrics Task Force Dale Hapeman 

 Arun Vemury (Alt.) 

vIDentity Systems, Inc. Alan Viars 

Virginia State Police Julianna Wilson 

WI Dept. of Justice Gerry Coleman 
Part 1 ANSI/NIST-ITL 1-2007

1

1 Introduction 

The first version of this standard, ANSI/NBS-ICST 1-1986, was published by NIST (formerly the 

National Bureau of Standards) in 1986. It was a minutiae-based standard that required a 

minimum amount of memory for the exchange and storage of fingerprint information. 

In 1993 an updated version of the "Data Format for the Interchange of Fingerprint Information" 

standard (ANSI/NIST-CSL 1-1993) was approved by ANSI. While retaining the provision for 

minutiae data, the standard focused on formats for the exchange of fingerprint images rather than 

processed minutiae data. 

In 1997 an addendum was approved to provide for the interchange of facial ("mugshot") image 

data and captured image data from scars, marks, and tattoos. The addendum carried the ANSI 

designation of ANSI/NIST-ITL 1a-1997. 

A workshop convened in 1998 to review the standard and its addendum. This resulted in a new 

revision that merged the two documents, emphasized the tagged-field record, and introduced 

new record types for the exchange of recorded fingerprint, latent, and palm print images. The 

revision was titled “Data Format for the Interchange of Fingerprint, Facial, & Scar Mark & Tattoo 

(SMT) Information” and carried the ANSI designation of ANSI/NIST-ITL 1-2000. 

This current version of the standard is the result of agreements reached during two workshops 

held in April and December of 2005 to review the ANSI/NIST-ITL 1-2000 standard. During the 

first workshop, proposals to update the standard were introduced. The proposals were refined 

and presented for discussion and approval during the second workshop. The major 

enhancements in this revision include: 

• Image quality and segmentation data to support the processing of the "flat" images 

• Definition of a new block of minutiae fields to harmonize with the INCITS M1 minutiae 

standard 

• Best practice application levels for the capture of facial images 

• A new record type for the exchange of iris information 

• A new record type to contain biometric information not described in this standard but 

conformant to other registered biometric data format standards; and 

• An XML alternative representation for this standard. 

2 Scope, purpose, and conformance 

2.1 Scope

This standard defines the content, format, and units of measurement for the exchange of 

fingerprint, palmprint, facial/mugshot, scar mark & tattoo (SMT), iris, and other biometric sample 

information that may be used in the identification or verification process of a subject. The 

information consists of a variety of mandatory and optional items, including scanning parameters, 

related descriptive and record data, digitized fingerprint information, and compressed or 
Part 1 ANSI/NIST-ITL 1-2007

2

uncompressed images. This information is primarily intended for interchange among criminal 

justice administrations or organizations that rely on automated fingerprint and palmprint 

identification systems, or use facial/mugshot, SMT, iris, or other biometric data for identification 

purposes. 

This standard does not define the characteristics of the software that shall be required to format 

the textual information or to compress and reconstruct the associated digital fingerprint image 

information. Typical applications for this software might include, but are not limited to, computer 

systems associated with a live-scan fingerprinting system, a workstation that is connected to or is 

part of an Automated Fingerprint Identification System (AFIS), or an image storage and retrieval 

system containing fingerprints, facial/mugshot, SMT, or other biometric images. 

2.2 Purpose 

Information compiled and formatted in accordance with this standard can be recorded on 

machine-readable media or may be transmitted by data communication facilities. This information 

may have been gathered directly from a fingerprint scanner or camera in lieu of a fingerprint card, 

a latent fingerprint, facial/mugshot, or other types of photographs. Law enforcement, criminal 

justice agencies, and other organizations that process biometric data will use the standard to 

exchange fingerprint, palmprint, facial, iris, or other photographic images and related biometric 

identification data. 

2.3 Conformance 

Systems claiming conformance with this standard shall implement the transmitting and/or 

receiving of record types as defined by this standard. Systems claiming conformance are not 

required to implement every record type specified herein. At a minimum, they must be capable of 

transmitting and receiving Type-1 records. However, in order for a transaction to be meaningful, 

there must be at least one additional type of record included. The implementer must document 

the record types supported in terms of transmitting and/or receiving. Those record types not 

implemented shall be ignored by the conforming system receiving a transaction. 

3 Normative References 

The following standards contain provisions that, through reference in this text, constitute 

provisions of this American National Standard. At the time of publication, the editions indicated 

were valid. All standards are subject to revision, and parties that utilize this American National 

Standard are encouraged to investigate the possibility of applying the most recent editions of the 

standards indicated below. 

ANSI X3.4-1986 (R1992), Information Systems --- Coded Character Sets ---7-Bit American 

National Standard Code for Information Interchange (7-Bit ASCII).1

ANSI X3.172-1990, Information Systems --- Dictionary for Information Systems. 

 

1

 ANSI X3 Documents available from the American National Standards Institute, 11 West 42nd Street, New York, NY 

10036. 
Part 1 ANSI/NIST-ITL 1-2007

3

ANSI/EIA - 538-1988 Facsimile Coding Schemes and Coding Control Functions for Group 4 

Facsimile Equipment. 

ANSI/IAI 2-1988, Forensic Identification --- Automated Fingerprint Identification Systems --- 

Glossary of Terms and Acronyms.2

ANSI INCITS 378-2004, Finger Minutiae Format for Data Interchange.3

ANSI INCITS 398-2005, the Common Biometric Exchange Formats Framework (CBEFF) 

ANSI/NIST-ITL 1-2000, Information systems – Data Format for the Interchange of Fingerprint, 

Facial, and Scar Mark & Tattoo (SMT) Information.4

IAFIS-DOC-0178-7.1 Electronic Fingerprint Transmission Specification, Version 7.1, May 2, 

20055

. 

IAFIS-IC-0110 (V3) WSQ Gray-scale Fingerprint Image Compression Specification, December 

19, 1997. 

ISO 646-1983 7-Bit Coded Character Set for Information Interchange.6

ISO 8601-1988, Data Elements and Interchange Formats - Information Interchange 

Representation of Dates and Times. 

ISO/IEC International Standard 10918-1, Information Technology - Digital Compression and 

Coding of Continuous-Tone Still Images Part 1: Requirements and Guidelines. This is commonly 

referred to as the JPEG (Joint Photographic Experts Group) algorithm. 

ISO/IEC 14496-2, MPEG4 Feature Points, Annex C. 

ISO/IEC International Standard 15444-1, JPEG 2000, Information Technology - Digital 

Compression and Coding of Continuous-Tone Still Images Part 1: Requirements and Guidelines. 

MTR 04B0000022 (Mitre Technical Report), Margaret Lepley, Profile for 1000ppi Fingerprint 

Compression, Version 1.1, April 2004.7

 Available at: 

http://www.mitre.org/work/tech_papers/tech_papers_04/lepley_fingerprint/lepley_fingerprint.pdf

National Crime Information Center (NCIC) Code Manual, Ninth Edition, December, 2000. 

 

2

 Available from the International Association for Identification. 

3

 All INCITS documents available from http://www.incits.org 

4

 http://fingerprint.nist.gov/standard/index.html 

5

 All CJIS, IAFIS, and NCIC documents available from Criminal Justice Information Services Division, Federal Bureau of 

Investigation 935 Pennsylvania Avenue, NW, Washington, DC 20535. 

6

 All ISO documents available from the American National Standards Institute, 11 West 42nd Street, New York, NY 10036. 

7 http://www.mitre.org/work/tech_papers/tech_papers_04/lepley_fingerprint/lepley_fingerprint.pdf
Part 1 ANSI/NIST-ITL 1-2007

4

NIST Fingerprint Image Quality (NFIQ), NISTIR 7151 ed., National Institute of Standards and 

Technology, 2004.8

 Available at: 

http://fingerprint.nist.gov/NFIS/ir_7151.pdf 

4 Definitions 

The following definitions and those given in the American National Standard Automated 

Fingerprint Identification Systems --- Glossary of Terms and Acronyms, ANSI/IAI 2-1988, apply to 

this standard. 

4.1 AAMVA 

Abbreviation for the American Association of Motor Vehicle Administrators 

4.2 ANSI 

Abbreviation for the American National Standards Institute, Inc. 

4.3 aspect ratio 

The width-to-height ratio of the captured image. 

4.4 complete friction ridge exemplars 

See major case prints. 

4.5 effective scanning resolution 

The number of pixels per unit distance that remain after a captured image has been subsampled, 

scaled, or interpolated down to produce an image having a lower value of scanning resolution 

(fewer pixels per mm) than was used originally to capture the image. 

4.6 Entire Joint Image 

An exemplar image containing one rolled and three plain full finger views (full-length finger 

images) for a single finger. 

4.7 FAP 

Abbreviation Facial Animation Parameters 

4.8 IBIA 

Abbreviation for International Biometric Industry Association 

4.9 ICC 

Abbreviation for International Color Consortium. 

4.10 logical record 

A record independent of its physical environment; portions of one logical record may be located in 

different physical records, or several logical records or parts of logical records may be located in 

one physical record. 

 

8

 Also see: E. Tabassi, “A novel approach to fingerprint image quality” in IEEE International Conference on Image 

Processing ICIP-05, Genoa, Italy, September 2005. 
Part 1 ANSI/NIST-ITL 1-2007

5

4.11 major case prints 

A set of exemplar images of all finger and palm friction skin for an individual. Major case prints 

include full palm print images, as well as rolled fingerprints, plain fingerprints, entire joint images, 

and rolled tips for all fingers. They are also known as complete friction ridge exemplars. (Note 

that the term Major Case Prints may be deprecated for some uses because in legal contexts it 

can be incorrectly read as making an implication regarding the severity of the case.) 

4.12 minutia 

The point where a friction ridge begins, terminates, or splits into two or more ridges. Minutiae are 

friction ridge characteristics that are used to individualize a fingerprint image. 

4.13 mugshot 

Term used interchangeably with facial image. The term facial image usually implies a higher 

quality image than a mugshot. 

4.14 native scanning resolution 

The nominal scanning resolution used by a specific AFIS, live-scan reader, or other image 

capture device and supported by the originator of the transmission. 

4.15 nominal transmitting resolution 

The nominal number of pixels per unit distance (ppmm or ppi) of the transmitted image. The 

transmitting resolution may be the same as the scanning resolution for a particular image. On the 

other hand, the transmitting resolution may be less than the scanning resolution if the scanned 

image was subsampled, scaled, or interpolated down before transmission. 

4.16 NFIQ 

Abbreviation for NIST Fingerprint Image Quality. 

4.17 ppi 

Abbreviation for pixels per inch 

4.18 ppmm 

Abbreviation for pixels per millimeter 

4.19 RGB 

Red, Green, Blue used to represent color pixels comprised of a specified number of bits to 

represent each of these primary color components. 

4.20 ROI 

Abbreviation for region of interest. 

4.21 SMT 

Abbreviation used for scar, mark, and tattoo information. 

4.22 scanning resolution 

The number of pixels per unit distance at which an image is captured (ppmm or ppi). 

4.23 tagged-field record 

A logical record containing unique ASCII field identifiers for variable-length data fields that is 

capable of being parsed based on the field identifier and the data contents of each field. 

4.24 transaction 

A command, message, or an input record that explicitly or implicitly calls for a processing action. 

Information contained in a transaction shall be applicable to a single subject. 
Part 1 ANSI/NIST-ITL 1-2007

6

5 Transmitted data conventions 

5.1 Fingerprint Ridge Representation 

Ridges in fingerprint images shall be represented as “dark ridges” in either grayscale or binary 

image data. 

5.2 Byte and bit ordering 

Each information item, subfield, field, and logical record shall contain one or more bytes of data. 

Within a file, the order for transmission of both the ASCII and the binary representations of bytes 

shall be most significant byte first and least significant byte last otherwise referred to as BigEndian format. Within a byte, the order of transmission shall be the most significant bit first and 

the least significant bit last. Figure 1 illustrates the order of transmission of the bytes and bits 

within a file. 

Figure 1 Byte and bit ordering 

5.3 Grayscale data 

Depending on the record type, grayscale image data may be transmitted in either compressed or 

uncompressed form. The transmission of uncompressed grayscale images shall consist of 

pixels, each of which shall normally be quantized to eight bits (256 gray levels) and held in a 

single unsigned byte. Increased precision for pixel values greater than 255 shall use two 

unsigned bytes to hold sixteen-bit pixels with values in the range of 0-65635. For grayscale data, 

a true black pixel shall be represented by a zero. A true white pixel shall have all of its bits of 

precision set to “1”. Therefore, true white pixels quantized to eight bits shall have a value of 

“255”, while a value of “1023” shall be used for pixels quantized to ten bits. As explained in 5.2, 

grayscale values requiring less than 8 or 16 bits are expressed as one or two bytes, right justified 

and zero padded on the left. 

First Byte Last Byte

Byte of Data

Most Significant Byte Least Significant Byte

Most Significant Byte Within a Block Transmitted First

Most Significant Bit Within a Byte Transmitted First

Most

Significant

Bit

Least

Significant

Bit

MSB LSB MSB LSB

Most Significant Byte Least Significant Byte
Part 1 ANSI/NIST-ITL 1-2007

7

The transmission of compressed grayscale images shall be the output of the appropriate 

grayscale compression algorithm specified. Upon reconstruction of a compressed image the 

grayscale value for each pixel shall be the same (for lossless algorithms) or nearly the same (for 

lossy algorithms) as pixels in an uncompressed image. 

5.4 Binary data 

Binary image data may be transmitted in either compressed or uncompressed form. The 

transmission of uncompressed binary images shall consist of pixels, each of which shall be 

quantized to one of two levels (binary representation). A value of zero shall be used to represent 

a white pixel and a value of one shall be used to represent a black pixel. For transmission of 

uncompressed binary images, eight pixels shall be left justified and packed into a single unsigned 

byte. The most significant bit of the byte shall be the first of the eight pixels scanned. 

5.5 Color data 

It is assumed that the scanned images consist of nominal 24 to 48-bit RGB pixels for color facial, 

SMT, iris, or user-defined testing images. Color image data may be transmitted in either 

compressed or uncompressed form. The transmission of uncompressed color images shall 

consist of RGB pixels, each component of which shall be quantized to at least 256 levels (8 bits). 

For each pixel, the three components shall be sequentially formatted for transmission on a pixelby-pixel basis. 

5.6 Compression algorithms 

5.6.1 Color and grayscale compression algorithms 

Compressed image data shall adhere to the requirements of the algorithm used. Table 1 lists the 

binary (shown here in base 10) and ASCII codes to be used for the available compression 

methods for encoding grayscale and color images described by this standard. But the choice of 

compression algorithms is limited by the type of data being exchanged (fingerprint, face, etc.). 

The description for each type of data exchange lists the legitimate compression algorithms that 

can be used for that type and whether a binary or ASCII code should be used. 

Table 1 Grayscale & color image compression codes 

Algorithm Name Binary Code 

(in base 10) 

ASCII Code 

Uncompressed 0 NONE 

WSQ Version 2.0 1 WSQ20 

JPEG ISO/IEC 10918 (Lossy) 2 JPEGB 

JPEG ISO/IEC 10918 (Lossless) 3 JPEGL 

JPEG 2000 ISO/IEC 15444-1 (Lossy) 4 JP2 

JPEG 2000 ISO/IEC 15444-1 (Lossless) 5 JP2L 

Portable Network Graphics 6 PNG 
Part 1 ANSI/NIST-ITL 1-2007

8

The "JPEGB" algorithm indicates that the scanned or captured image was compressed using 

baseline JPEG. An entry of "JPEGL" indicates that the lossless mode of the JPEG algorithm was 

used to compress the image. If the image is captured in grayscale, then only the luminance 

component will be compressed and transmitted. For JPEG, the data shall be formatted in 

accordance with the JPEG File Interchange Format, Version 1.02 (JFIF)9

 as found in Annex D.10 

An entry of "JP2" indicates that the scanned or captured image was compressed using lossy 

JPEG 2000. (Conformance with ISO 15444-1 is provided through part 4 of the standard, ISO 

15444-4 “Conformance Testing”.) An entry of "JP2L" indicates that the lossless mode of the 

JPEG 2000 algorithm was used to compress the image. For JPEG 2000, the data shall be 

formatted in conformance with JP2 format as described in ISO 15444-1. 

Where JPEG 2000 is used for the compression of fingerprint images, specification/options 

contained in Profile for 1000ppi Fingerprint Compression (as listed in Section 3, Normative 

References) shall apply. This reference addresses the 9 quality layers between 0.015 bpp and 

0.55 bpp. 

Where JPEG 2000 is used for compression of facial images, the following conditions shall apply: 

• Filters: The 9-7 irreversible filters described in ISO 15444-1 should be used for lossy mode; 

however for handheld devices (fixed point processors), the 5-3 reversible filters may be used 

instead. The 5-3 reversible filters shall be used for lossless mode. A conformant decoder shall be 

able to decode code streams created through both filters. 

• Number of resolution levels: The image shall be encoded using enough resolution levels to 

ensure that a thumbnail with max(width, height) <= 64 is available in the image. Example: a 

640x480 image shall be encoded with 5 resolution levels, which enables sub-resolution decodes 

of 320x240, 160x120, 80x60, and 40x30. 

• Resolution as the dominant progression: JPEG 2000 allows five progression orders - LRCP, 

RLCP, RPCL, PCRL and CPRL. The RLCP progression order (resolution, layer, component, 

position) shall be used since it best facilitates decode and display of lower resolution derivative 

images by remote networked devices. Through the RLPC progression order, the code stream 

shall be formatted so that the resolution information of the image is the first data made available 

to a decoder in a streaming mode of operation. 

• Bits per Channel: The number of bits per channel for encoders and decoders shall be 8-16 bits. 

• Single tile images: Facial images shall be encoded using only single tile to avoid tiling artifacts. 

• JPEG 2000 quality layers: The image shall be encoded using at least 10 quality layers to enable 

quality progressive decoding or sub-quality image extraction. 

Region of Interest (ROI) Encoding is allowed: This encoding method is a useful way to compress 

a facial image to a small size, while retaining sufficient image quality within the specified ROI to 

perform either human or automated identification. 

 

9 Developed by C-Cube Microsystems, 1778 McCarthy Blvd., Milpitas, CA 95035.

10 Annex D specifies YCC as the standard color space to be used for JFIF. YCC is a linear combination of RGB 

components or channels. sRGB can be JPEG compressed and stored using JFIF, which is specified in Annex D. 
Part 1 ANSI/NIST-ITL 1-2007

9

5.6.2 Binary compression algorithms 

Table 2 lists the binary codes for the available compression schemes that can be used for 

encoding binary image data described by this standard. This standard does not use ASCII codes 

for describing compression methods for the exchange of binary images. 

Table 2 Binary compression codes 

Algorithm Name Binary Code ASCII Code Notes 

Uncompressed 0 ________ Image Packed 8 pixels/byte 

Facsimile ANSI/EIA 538-1988 1 ________ Lossless 

The transmission of compressed binary images shall be the output of the binary compression 

algorithm specified by ANSI/EIA-538-1988. Upon decompression, each pixel with a value of zero 

shall be considered to be white and each pixel with a value of one shall be considered to be 

black. 

5.7 Color spaces 

Table 3 lists the codes and their descriptions for each of the available color spaces used within 

this standard. All other color spaces are to be marked as undefined. 

Table 3 Color spaces 

Code Description 

UNK Undefined 

GRAY Grayscale (monochrome) 

RGB Undetermined color space for an RGB image 

SRGB sRGB (IEC 61966-2-1) 

YCC YCbCr (legacy) 

SYCC YCbCr (JPEG 2000 compressed) 

5.7.1 Backwards compatibility 

In previous versions of this standard, the term “color space” referred to device-dependent color 

information with a particular sequence and range for the three color channels. The choice was 

either RGB or an RGB-derivative space known as YCC. Neither space provides an objective 

definition of a particular color or relates to the way in which humans perceive color. 

Although sRGB is the preferred color space for compressed images for this version, in the 

previous version of this standard, it was stated that “the preferred color space for compressed 

images using baseline JPEG and JFIF is YCbCr to be coded as ‛YCC’,” while the color space for 

uncompressed color images was to be labeled RGB. Therefore, for backwards compatibility 

purposes, new systems must accommodate JPEG images that have been labeled as using the 
Part 1 ANSI/NIST-ITL 1-2007

10

YCC color space. Specifically, systems conformant with this standard must accept an entry of 

YCC and interpret it as meaning a (device-dependent) RGB color space. 

5.7.2 Color space sRGB 

To ensure that color images exchanged between differing systems can be correctly displayed or 

printed, images should be converted to the device-independent color space, sRGB11, before 

compression or transmission to another system. As defined by IEC 61966-2-1, sRGB is a nonlinear display profile that accommodates the voltage-to-color response characteristics of most 

high quality CRT monitors. The colors of the red, green, and blue phosphors (primaries) and the 

white point setting of an sRGB-conformant monitor are specified in the IEC document. 

The relationship between sRGB and a linear RGB space having the IEC-defined primaries and 

white point is as follows: 

divide/multiply by 255.

range of 0 to1). To convert from/to the range of 0 to 255,

R, G, or B value in non -linear space (also with a

(with a range of 0 to1) and is the corresponding

where is an R, G, or B value in linear RGBspace

1055 0 055 for 0 0031308

12 92 for 0 0031308

1 2 4

sRGB

value

value

. value . , value .

. value , value . value

sRGB

lin

lin

( / . )

lin

lin lin 

sRGB ⎩

⎨

⎧

− >

≤ =

Typically, modern digital cameras, desktop scanners, LCD monitors, and printers, although they 

don't inherently operate in sRGB space, are designed with circuitry or software to produce sRGB 

output or to accommodate sRGB as an input space. If an image acquisition device's color space 

is unknown, sRGB is usually a reasonable choice. If an acquisition device and its software 

cannot provide sRGB output, various color management products are available commercially that 

use its color profile, often available from its manufacturer, to convert images in its native color 

space to sRGB. 

5.8 Scan sequence 

Each color, grayscale, or binary image formatted in accordance with this standard shall appear to 

have been captured in an upright position and approximately centered horizontally in the field of 

view. The recorded image data shall appear to be the result of a scanning of a conventional 

inked impression of a fingerprint or photo of a face or iris. This is also equivalent to a live-scan 

capture of the finger, or a camera capture of a face or iris. The scanning sequence (and recorded 

data) shall appear to have been from left-to-right, progressing from top-to-bottom of the 

fingerprint, palm print, face, SMT, or iris. Figure 2 illustrates the recording order for the scanned 

fingerprint image. 

For the purpose of describing the position of each pixel within an image to be exchanged, a pair 

of reference axes shall be used. The origin of the axes, pixel location (0,0), shall be located at 

the upper left-hand corner of each image. The x-coordinate (horizontal) position shall increase 

 

11 For information on sRGB, see http://www.w3.org/Graphics/Color/sRGB or many of the white papers available at 

http://www.color.org. 
Part 1 ANSI/NIST-ITL 1-2007

11

positively from the origin to the right side of the image. The y-coordinate (vertical) position shall 

increase positively from the origin to the bottom of the image. 

Figure 2 Order of scanned image 

6 Image resolution requirements 

Image resolution requirements are applicable to fingerprint, palmprint, and signature images. 

Facial/ mugshot, SMT, and iris images rely on the total number of pixels scanned and transmitted 

and are not dependent on the specific scanning resolution used. 

6.1 Scanner resolution requirement 

Binary and grayscale fingerprint images to be exchanged shall be captured by an AFIS, live-scan 

reader, or other image capture device operating at a specific native scanning resolution. The 

minimum scanning resolution for this capture process shall be 19.69 ppmm plus or minus 0.20 

ppmm (500 ppi plus or minus 5 ppi). Scanning resolutions greater than this minimum value and 

with a device tolerance of plus or minus 1% may be used. Although a minimum scanning 

resolution is specified, a maximum value for scanning resolution is not specified by this standard. 

However, for latents images, the minimum scanning resolution (or effective scanning resolution) 

and transmission rate for latent images shall be 39.37 ppmm plus or minus 0.40 ppmm (1000 ppi 

plus or minus 10 ppi). 

The recommended migration path to higher scanning resolutions for image capturing devices with 

a native scanning resolution of 19.69 ppmm (500 ppi) shall be at a rate of 100% of the current 

native scanning resolution. The recommended migration path progresses from 19.69 ppmm to 

39.37 ppmm (500 ppi to 1000 ppi), from 39.37 ppmm to 78.74 ppmm (1000 ppi to 2000 ppi), etc. 

Capture devices with native scanning resolutions not in step with this migration path shall provide 

(through subsampling, scaling, or interpolating downward) an effective scanning resolution that 

matches the next lower interval in the migration path. For example a device with native scanning 

resolution of 47.24 ppmm (1200 ppi) shall be required to provide an effective resolution of 39.37 

ppmm (1000 ppi). 
Part 1 ANSI/NIST-ITL 1-2007

12

6.2 Transmitting resolution requirement 

Each image to be exchanged shall have a specific resolution associated with the transmitted 

data. This transmitting resolution does not have to be the same as the scanning resolution. 

However, the transmitting resolution shall be within the range of permissible resolution values for 

that record type. When an image is captured at a scanning resolution greater than the 

permissible upper limit of the transmitting resolution for that record type, the image shall be 

subsampled, scaled, or interpolated down. This processing to reduce the scanning resolution to 

a lower effective resolution must be performed before the transmission occurs. 

For high-resolution binary and grayscale images, the preferred transmitting resolution shall be the 

same as the minimum scanning resolution of 19.69 ppmm plus or minus 0.20 ppmm (500 ppi plus 

or minus 5 ppi). Any transmitting resolution within the range of the minimum scanning resolution 

to a value of 20.47 ppmm plus or minus 0.20 ppmm (520 ppi plus or minus 5 ppi) is permitted for 

the processing of high-resolution records. 

For low-resolution binary and grayscale images, the preferred transmitting resolution shall be half 

of the minimum scanning resolution or 9.84 ppmm plus or minus 0.10 ppmm (250 ppi plus or 

minus 2.5 ppi). Any transmitting resolution within the range of half of the minimum scanning 

resolution to a value of 10.24 ppmm plus or minus 0.10 ppmm (260 ppi plus or minus 2.5 ppi) is 

permitted for the processing of low-resolution records. 

For variable-resolution images, the preferred transmitting resolution is not specified, but must be 

at least as great as the high-resolution rate of 19.69 ppmm. At this time there is no upper limit on 

the variable-resolution rate for transmission. However, the recommended migration path to 

higher transmitting resolutions is the same as for the scanning resolutions. That is, to progress 

from 19.69 ppmm to 39.37 ppmm plus or minus 1% (500 ppi to 1000 ppi), from 39.37 ppmm to 

78.74 ppmm plus or minus 1% (1000 ppi to 2000 ppi), etc. For images captured at a native 

scanning resolution greater than the permissible upper limit of a transmitting resolution step in the 

migration path, it may be necessary to subsample, scale, or interpolate down. The result of this 

processing is to obtain an effective scanning resolution that conforms to a step in the 

transmission migration path. 

The transmitting resolution shall be contained in fields specified by the format for the variableresolution record. However, before transmitting variable-resolution records, the operational 

capabilities of the sending and receiving systems should be addressed, and prior agreement 

should be made with the recipient agency or organization before transmitting the image. 

7 File description 

This standard defines the composition of a transaction file that is transmitted to a remote site or 

agency. As specified in this standard, certain portions of the transmission shall be in accordance 

with definitions provided by the receiving agency. This file shall contain one or more logical 

records each corresponding to one of the defined available types. The logical records are 

intended to convey specific types of related information pertinent to the transaction itself or to the 

subject of the transaction. All of the logical records belonging to a single transaction shall be 

contained in the same physical file. 

The standard defines three logical records for the exchange of ASCII textual information fields, 

six logical records for the exchange of binary information and seven tagged-field record types 

designed for the exchange of a combination of ASCII and image data within a single 

logical record structure. These tagged-field records consist of ASCII tagged textual fields and 

binary, grayscale, or color image data. At the beginning of the record, a series of tagged fields 

shall be used to provide information required for processing the image data present in the last 

field of the logical record. 
Part 1 ANSI/NIST-ITL 1-2007

13

Two additional record types are reserved for inclusion in future revisions of this standard. The 

sixteen defined types of logical records together with the identifier for each type are listed in Table 

4. 

Table 4 Logical record types 

Record 

Identifier 

Logical record contents Type of data 

1 Transaction information ASCII 

2 User-defined descriptive text ASCII 

3 Low-resolution grayscale fingerprint image Binary 

4 High-resolution grayscale fingerprint image Binary 

5 Low-resolution binary fingerprint image Binary 

6 High-resolution binary fingerprint image Binary 

7 User-defined image Binary 

8 Signature image Binary 

9 Minutiae data ASCII 

10 Facial & SMT image ASCII/Binary 

11 Reserved for future use - 

12 Reserved for future use - 

13 Variable-resolution latent image ASCII/Binary 

14 Variable-resolution fingerprint image ASCII/Binary 

15 Variable-resolution palmprint Image ASCII/Binary 

16 User-defined variable-resolution testing Image ASCII/Binary 

17 Iris image ASCII/Binary 

18-98 Reserved for future use ASCII/Binary 

99 CBEFF Biometric data record ASCII/BInary 

7.1 File format 

A file shall contain one or more logical records pertaining to a single subject. The data in the 

Type-1 record shall always be recorded in variable length fields using the 7-bit American National 

Standard Code for Information Interchange (ASCII) as described in ANSI X3.4-1986 and Annex 

A. For purposes of compatibility, the eighth (leftmost) bit shall contain a value of zero. 

The text or character data in the Type-2, Type-9, and tagged-field records will normally be 

recorded using the 7-bit ASCII code in variable-length fields with specified upper limits on the size 

of the fields. For data interchange between non-English speaking agencies, character sets other 

than 7-bit ASCII may be used in textual fields contained in the Type-2, Type-9, and tagged-field 

records. UTF-8 is the preferred method of storing textual data that cannot be represented as 7-bit 

ASCII. This method supports international character sets for all user-defined fields in all record 

types. The mechanism to change character sets is described in Section 8.2.3, International 
Part 1 ANSI/NIST-ITL 1-2007

14

Character Sets. By definition UTF-8 and other international character exchange methods are not 

applicable to record Type 1 and Types 3-8. 

The first field in all tagged-field records shall be labeled as field "1" and contain the length in 

bytes of the record. The second field shall be labeled as field "2" and contain the image 

designation character as described in Section 7.4. The remaining textual fields may occur in any 

order and contain the information as described for that particular numbered field. For tagged-field 

image records, Type-10 through Type-17 and Type-99, the last and concluding field shall 

have a tagged ASCII field number identifier "999" followed by the image data. 

For the binary image Type-3, Type-4, Type-5, Type-6, and Type-8 logical records, the content 

and order of the recorded fields are specified by this standard. With the exception of the first two 

fields, the remaining fields of the Type-7 logical image record are all user-defined. All fields and 

data in these record types shall be recorded as binary information. 

7.2 File contents 

Files to be exchanged are required to contain one and only one Type-1 logical record per 

transaction. The Type-1 logical record shall always be the first logical record within the file. 

Depending on the usage and the number of fingerprint, palmprint, facial/mugshot, SMT, iris, or 

other biometric images available for processing, one or more additional records may be present 

in the file. 

Table 5 lists the typical range or the number of records that may be contained in a file. These 

record counts are shown by logical record types for common processing functions used for 

search inquiries, file maintenance, image request, and image responses. The record limits stated 

in the table are examples of typical transactions and should only be interpreted as a guideline. 

Receiving agencies may impose their own specific limit for each type of logical record depending 

on the application. The ranges listed specify the minimum and maximum number of logical 

records that may be contained in the file. The mandatory inclusion of a logical record is indicated 

by an entry of "1" in the table. An entry of "0" indicates the exclusion of that logical record type. 

The appearance of "0-N" in the table indicates that the standard imposes no limits on the number 

of records for that logical record type. An entry of "1-N" requires that at least one record be 

present with no upper limit on the number of records that may be present. 

7.3 Implementation domains 

The Type-2 record is composed of user-defined textual fields. Many of the information fields in 

the Type-2 record are used in the same way by local, state, and Federal agencies and require the 

same data and formatting. In order to establish a common basis for field numbering, meaning, 

and formatting, jurisdictions that use the same general set of data fields may subscribe to a 

common implementation domain. 

An implementation domain can be viewed as a group of agencies or organizations that have 

agreed to use specific pre-assigned groups of numbered tagged fields for exchanging information 

unique to their installations. Each tagged-field number shall also have a definition and format 

associated with it. The domain implementation name uniquely identifies field contents and avoids 

tag numbers with multiple Type-2 field definitions. Each domain created shall have a point of 

contact responsible for keeping the list of numbered tagged fields and assigning new numbered 

tagged fields to organizations within their domain. The contact shall serve as a registrar and 

maintain a repository including documentation for all the common and user-specific Type-2 fields 

contained in the implementation. As additional fields are required by specific agencies for their 

own applications, new field tag numbers and definitions can be registered and reserved to have a 

specific meaning. When this occurs, the domain registrar is responsible for registering a single 

definition for each tagged-field number used by different members of the domain. 
Part 1 ANSI/NIST-ITL 1-2007

15

Table 5 Number of logical records per transaction 

Type of 

logical 

record 

Master 

file 

inquiry 

Latent 

inquiry 

File 

maintenance 

Image 

request 

Search 

response 

Image 

request 

response 

1 1 1 1 1 1 1 

2 1-N 1-N 1-N 1 1 1 

3 0-14 0 0-14 0 0-14 0-14 

4 0-14 0-10 0-14 0 0-14 0-14 

5 0-14 0 0-14 0 0-14 0-14 

6 0-14 0-10 0-14 0 0-14 0-14 

7 0 0-N 0-N 0 0-N 0-N 

8 0-2 0 0-2 0 0-2 0-2 

9 0-10 0-N 0-N 0 0 0 

10 0-N 0-N 0-N 0 0-N 0-N 

13 0 0-N 0-N 0 0-N 0-N 

14 0-14 0 0-14 0 0-N 0-N 

15 0-8 0-N 0-8 0 0-N 0-N 

16 0 0 0-N 0 0-N 0-N 

17 0-2 0 0-2 0 0-2 0-2 

99 0 0 0-N 0 0-N 0-N 

The Criminal Justice Information Services (CJIS) Division of the Federal Bureau of Investigation 

(FBI) has established and maintains the North American Domain subscribed to by the Royal 

Canadian Mounted Police (RCMP), the FBI, and several state and Federal agencies in North 

America. The registrar for this domain assigns and accounts for a set of tagged fields to be used 

by its clients during the processing of transactions. Other domains also exist including those 

maintained by the United Kingdom (UK) and Interpol. These organizations have developed their 

own Type-2 record implementations tailored to their specific communities. 

7.4 Image designation character (IDC) 

With the exception of the Type-1 logical record, each of the remaining logical records present in a 

file shall include a separate field containing the Image Designation Character (IDC). The IDC 

shall be used to relate information items in the file content field of the Type-1 record to each 

logical record, and to properly identify and link together logical records that pertain to the same 

entity such as a particular finger or face. The value of the IDC shall be a sequentially assigned 

positive integer starting from zero and incremented by one. If two or more logical records that are 

different representations of the same subject matter are present in a file, each of those logical 

records shall contain the same IDC. For example, a high-resolution image record of a specific 

fingerprint and the corresponding minutiae record for the same finger would carry the same IDC 

number. 

Although there is no upper limit on the number of logical records that may be present in a file, 

generally a minimum of two and no more than 25 logical records will be present in a file. For 

example, a tenprint search inquiry transaction may consist of a Type-1 record, a Type-2 record, 

14 high-resolution Type-4 or variable-resolution Type-14 grayscale image records, two Type-8 

signature records, six Type-15 palmprint records, and a Type-10 facial/mugshot image of the 

subject. Additional mugshot, SMT, iris, or other biometric logical records may expand the file 

even more. For this file configuration, the IDC shall range from "0" to "24" which would include an 

IDC code for the Type-2 record. Within the same file, multiple logical record types may be 

present and represent the same image. For example, if core and delta location information for 
Part 1 ANSI/NIST-ITL 1-2007

16

the rolled impressions is requested, the transmission may also need to accommodate ten 

minutiae records within the same file. For each image representing the ten finger positions, the 

same IDC would be used in both the image and minutiae records. 

The IDC shall also be used to relate information items in the file contents field of the Type-1 

record to each facial, SMT, iris, or other biometric image record. It properly identifies and links 

together different logical record types created from the same face/mugshot or SMT image. 

Furthermore, zero or more Type-7 records may also be present. Each Type-7 logical record 

representing a specific sample shall have a unique IDC with an increment of one greater than the 

last IDC used. 

8 Record description 

8.1 Logical record types 

8.1.1 Type-1 Transaction information record 

A Type-1 logical record is mandatory and is required for each transaction. The Type-1 record 

shall provide information describing type and use or purpose for the transaction involved, a listing 

of each logical record included in the file, the originator or source of the physical record, and other 

useful and required information items. 

8.1.2 Type-2 User-defined descriptive text record 

Type-2 logical records shall contain user-defined textual fields providing identification and 

descriptive information associated with the subject of the transaction. Data contained in this 

record shall conform in format and content to the specifications of the domain name as listed in 

Domain Name field found in the Type-1 record. 

8.1.3 Type-3 through Type-6 fingerprint image records 

Logical record types 3-6 are used to exchange fingerprint image records originally scanned at the 

minimum scanning resolution of 19.69 ppmm plus or minus 0.20 ppmm (500 ppi plus or minus 5 

ppi) and transmitted at the nominal pixel density of 19.69 or 9.84 ppmm. The four record types 

differ according to the pixel density of the transmitted image and the type of data exchanged. 

Table 6 summarizes the differences between the four record types. 

The fingerprint image data contained in any of the logical records may be in compressed form. 

The WSQ algorithm has been generally used to compress grayscale images while the facsimile 

algorithm is used for the binary images. Typically, there may be up to 14 records of any of these 

logical types of fingerprint images in a file; ten rolled impressions of the individual fingers, two 

plain impressions of the thumbs, and two simultaneously obtained plain impressions of the four 

remaining fingers on each hand. 

When the image data is obtained from a live-scan reader, it shall be the grayscale or binary 

output (or subsampled, scaled down, or interpolated output) of the live-scan fingerprint scanner 

and not a rescan of a hard copy fingerprint image. 
Part 1 ANSI/NIST-ITL 1-2007

17

Table 6 Resolution of Transmitted fingerprint image records 

Preferred 

Pixel Density 

Maximum 

Pixel Density 

Record type Data type 

ppmm ppi ppmm ppi 

Type-3 Grayscale 9.84 250.00 10.34 252.50 

Type-4 Grayscale 19.69 500.00 20.67 525.00 

Type-5 Binary 9.84 250.00 10.34 252.50 

Type-6 Binary 19.69 500.00 20.67 525.00 

8.1.3.1 Type-3 Low-resolution grayscale fingerprint image 

Type-3 logical records shall contain and be used to exchange low-resolution grayscale fingerprint 

image data that was scanned at no less than the minimum scanning resolution and then 

subsampled, scaled down, or interpolated. Alternatively, provided that it is no less than the 

minimum scanning resolution, the native scanning resolution may be used and the image 

processed. The resultant transmitting resolution in either case shall be within the bounds of the 

permissible transmitting resolution requirement for low-resolution images. 

8.1.3.2 Type-4 High-resolution grayscale fingerprint image 

Type-4 logical records shall contain and be used to exchange high-resolution grayscale 

fingerprint image data that was scanned at no less than the minimum scanning resolution. 

Alternatively, the native scanning resolution may be used. But in either case, if the scanning 

resolution is greater than the upper limit of the permissible transmitting resolution, the scanned 

data shall be subsampled, scaled down, or interpolated. The resultant transmitting resolution 

shall be within the bounds of the permissible transmitting resolutions for high-resolution fingerprint 

images. 

8.1.3.3 Type-5 Low-resolution binary fingerprint image 

Type-5 logical records shall contain and be used to exchange low-resolution binary fingerprint 

image data that was scanned at no less than the minimum scanning resolution and then 

subsampled, scaled down, or interpolated. Alternatively, provided that it is no less than the 

minimum scanning resolution, the native scanning resolution may be used and the image 

processed. The resultant transmitting resolution in either case shall be within the bounds of the 

permissible transmitting resolution requirement for low-resolution images. 

8.1.3.4 Type-6 High-resolution binary fingerprint image 

Type-6 logical records shall contain and be used to exchange high-resolution binary fingerprint 

image data that was scanned at no less than the minimum scanning resolution. Alternatively, the 

native scanning resolution may be used. But in either case, if the scanning resolution is greater 

than the upper limit of the permissible transmitting resolution, the scanned data shall be 

subsampled, scaled down, or interpolated. The resultant transmitting resolution shall be within 

the bounds of the permissible transmitting resolutions for high-resolution fingerprint images. 
Part 1 ANSI/NIST-ITL 1-2007

18

8.1.4 Type-7 User-defined image record 

Type-7 logical records shall contain user-defined image data. Originally defined in 1993, this 

record type was designed for the exchange of binary image data that was not specified or 

described elsewhere in this standard. However, it is not intended that the use of the Type-7 

record is restricted by the existence of other record types in this standard. It was intended as a 

temporary measure to enable the exchange of binary image data that would be defined by 

specific record types in later versions of the standard. 

With the exception of the record length and IDC fields, the format, parameters, and types of 

images to be exchanged are undefined by this standard. These levels of required details shall be 

agreed upon between the sender and recipient. 

8.1.5 Type-8 Signature image record 

Type-8 logical records shall contain and be used to exchange scanned high-resolution binary or 

vectored signature image data. If scanned, the resolution of the image data shall be no less than 

the minimum scanning resolution. If necessary, the scanned image data shall be subsampled, 

scaled down, or interpolated to fall within the limits of the transmitting resolution requirement. 

The resultant transmitting resolution shall be within the bounds of the permissible transmitting 

resolutions for the high-resolution fingerprint images. Vectored signature data shall be expressed 

as a series of binary numbers. 

Typically, there may be up to two of these Type-8 signature records in a file. Each Type-8 record 

shall contain image data representing the signature of the person being fingerprinted or of the 

official taking the fingerprint. 

8.1.6 Type-9 Minutiae data record 

Type-9 logical records shall contain and be used to exchange geometric and topological minutiae 

templates and related information encoded from a finger or palm. Each record shall represent the 

processed image data from which the location and orientation descriptors of extracted minutiae 

characteristics are listed. The primary use of this record type shall be for remote searching of 

latent prints but may also be used for applications such as physical or logical access control. 

Each Type-9 logical record shall contain the minutiae data read from a fingerprint, palm, or latent 

image. 

8.1.7 Type-10 Facial & SMT image record 

Type-10 tagged-field image records shall contain and be used to exchange facial and image data 

from scars, marks, and tattoos (SMT) together with textual information pertinent to the digitized 

image. The source of the image data shall be the image captured from scanning a photograph, a 

live image captured with a digital camera, or a digitized “freeze-frame” from a video camera. 

8.1.8 Type-11 Reserved for future use 

8.1.9 Type-12 Reserved for future use 

8.1.10 Type-13 Variable-resolution latent image record 

Type-13 tagged-field image records shall contain and be used to exchange variable-resolution 

latent fingerprint or palmprint image data together with fixed and user-defined textual 

information fields pertinent to the digitized image. In all cases, the minimum scanning 

resolution (or effective scanning resolution) and transmission rate for latent images shall be 39.37 
Part 1 ANSI/NIST-ITL 1-2007

19

ppmm plus or minus 0.40 ppmm (1000 ppi plus or minus 10 ppi). The variable-resolution latent 

image data contained in the Type-13 logical record shall be uncompressed or may be the output 

from a lossless compression algorithm. There is no limit on the number of latent records that may 

be present in a transaction. The Type-13 record may be considered as the tagged-field version 

of the Type-7 record used for the exchange of latent images. 

8.1.11 Type-14 Variable-resolution fingerprint image record 

Type-14 tagged-field image records shall contain and be used to exchange variable-resolution 

fingerprint image data, segmented flat fingerprint data, or major case print data. Fixed and userdefined textual information fields pertinent to the digitized image may also be included. 

Fingerprint images can be either rolled or plain (including swiped) impressions. 

The scanning resolution is not specified for this record type. While the Type-14 record may be 

used for the exchange of 19.69 ppmm (500 ppi) images, it is strongly recommended that the 

minimum scanning resolution (or effective scanning resolution) for fingerprint images be 39.37 

ppmm plus or minus 0.40 ppmm (1000 ppi plus or minus 10 ppi). It should be noted that as the 

resolution is increased, more detailed ridge and structure information becomes available in the 

image. However, in all cases the scanning resolution used to capture a fingerprint image shall be 

at least as great as the minimum scanning resolution of 19.69 ppmm (500ppi). 

The variable-resolution fingerprint image data contained in the Type-14 logical record may be in a 

compressed form. Typically, there may be up to 14 of these Type-14 records in a file; ten rolled 

impressions of the individual fingers, two plain impressions of the thumbs or one plain impression 

of the two thumbs simultaneously, and two plain impressions of the four simultaneously obtained 

remaining fingers of each hand. The Type-14 record may be considered as the tagged-field 

variable-resolution version of the Type-4 record used for the exchange of rolled or flat fingerprint 

images. 

8.1.12 Type-15 Variable-resolution palmprint image record 

Type-15 tagged-field image records shall contain and be used to exchange variable-resolution 

palmprint image data together with fixed and user-defined textual information fields 

pertinent to the digitized image. 

The scanning resolution is not specified for this record type. While the Type-15 record may be 

used for the exchange of 19.69 ppmm (500 ppi) images, it is strongly recommended that the 

minimum scanning resolution (or effective scanning resolution) for palmprint images be 39.37 

ppmm plus or minus 0.40 ppmm (1000 ppi plus or minus 10 ppi). It should be noted that as the 

resolution is increased, more detailed ridge and structure information becomes available in the 

image. However, in all cases the scanning resolution used to capture a palmprint image shall be 

at least as great as the minimum scanning resolution of 19.69 ppmm (500ppi). 

The variable-resolution palmprint image data contained in the Type-15 logical record may be in a 

compressed form. The maximum number of occurrences of these Type-15 records in a file is 

eight. Different combinations may include: two writer’s palms to pair with two full palmprints; a 

writer's palm with an upper and lower palm from each hand; or a writer's palm with the thenar, 

hypothenar and interdigital areas from each hand. 

8.1.13 Type-16 User-defined variable-resolution testing image record 

The Type-16 tagged-field image record is intended as the tagged-field version of the Type-7 userdefined logical record. It is designed for developmental purposes and for the exchange of 

miscellaneous images. This tagged-field logical record shall contain and be used to exchange, 
Part 1 ANSI/NIST-ITL 1-2007

20

image data together with textual information fields pertinent to the digitized image. Such an 

image is usually not elsewhere specified or described in this Standard. 

A fixed scanning resolution is not specified for this record type. However where resolution is a 

factor in the captured image, it shall be at least as great as the minimum scanning resolution, that 

is, 19.69 ppmm (500ppi). Increases in the resolution used for capturing images should follow the 

recommended migration path to 39.37 ppmm (1000 ppi), 78.74 ppmm (2000 ppi), etc. It should 

be noted that as the resolution is increased, more detailed ridge and structure information 

becomes available in the image. 

The variable-resolution image data contained in the Type-16 logical record may be in a 

compressed form. With the exception of the tagged fields at the start of the record and the 

descriptors for the image data, the remaining details of the Type-16 record are undefined by this 

standard and shall be agreed upon between the sender and recipient. 

8.1.14 Type-17 Iris image record 

Type-17 tagged-field image records shall contain and be used to exchange iris image data. This 

record type was developed to provide a basic level of interoperability and harmonization with the 

ANSI INCITS 379-2004 Iris Image Interchange Format and the ISO/IEC 19794-6 iris image data 

interchange format. Generic iris images may be exchanged using the mandatory fields of this 

record type. Optional fields may also be used to exchange additional information. Although the 

iris standards provide for two alternative iris image interchange formats, the Type-17 record shall 

only address and establish provision for the rectilinear image storage format that may be a raw 

uncompressed array of intensity values or a compressed format of the raw data. 

8.1.15 Type-99 CBEFF biometric data record 

Type-99 logical records shall contain and be used to exchange biometric data that is not 

supported by other ANSI/NIST-ITL logical record types. This provides a basic level of 

interoperability and harmonization with the ANSI INCITS and other biometric interchange formats. 

This is accomplished by using a basic record structure that is conformant with ANSI INCITS 398-

2005, the Common Biometric Exchange Formats Framework (CBEFF) and a biometric data block 

specification registered with the International Biometrics Industry Association (IBIA)12. This 

logical record type supports and is intended to be used for biometric data types or formats that 

are not already represented by an existing ANSI/NIST data type. 

A CBEFF conformant Biometric Information Record (BIR) is made up of a Header, a Biometric 

Data Block (BDB), and an optional Signature Block. The Type-99 logical record does not use the 

Signature Block. Information required by the Header portion is encoded as tagged fields within 

the Type-99 record. The final tagged field of the Type-99 record will contain biometric data as 

specified by the BDB interchange format. 

8.2 Record format 

A transaction file shall consist of one or more logical records. For each logical record contained 

in the file, several information fields appropriate to that record type shall be present. Each 

information field may contain one or more basic single-valued information items. Taken together 

these items are used to convey different aspects of the data contained in that field. An 

information field may also consist of one or more information items grouped together and 

 

12 For more information, go to <http://www.ibia.org>. 
Part 1 ANSI/NIST-ITL 1-2007

21

repeated multiple times within a field. Such a group of information items is known as a subfield. 

An information field may therefore consist of one or more subfields of information items. 

8.2.1 Information separators 

In the tagged-field logical records (Type-1, Type-2, Type-9 through Type-17, and Type-99), 

mechanisms for delimiting information are implemented by use of the four ASCII information 

separators. The delimited information may be items within a field or subfield, fields within a 

logical record, or multiple occurrences of subfields. These information separators are defined in 

the referenced standard ANSI X3.4 whose code table is shown in Annex A. These characters are 

used to separate and qualify information in a logical sense. Viewed in a hierarchical relationship, 

the File Separator “FS” character is the most inclusive followed by the Group Separator “GS”, the 

Record Separator “RS”, and finally the Unit Separator “US” characters. Table 7 lists these ASCII 

separators, the column/row position in the ASCII table shown in Annex A, and a description of 

their use within this standard. 

Information separators should be functionally viewed as an indication of the type data that 

follows. The “US” character shall separate individual information items within a field or subfield. 

This is a signal that the next information item is a piece of data for that field or subfield. Multiple 

subfields within a field separated by the “RS” character signals the start of the next group of 

repeated information item(s). The “GS” separator character used between information fields 

signals the beginning of a new field preceding the field identifying number that shall appear. 

Similarly, the beginning of a new logical record shall be signaled by the appearance of the “FS”

character. 

Table 7 Information separators 

ASCII 

character 

Column / row 

position 

Description 

FS 1 / 12 Separates logical records of a file or is the 

terminating character of a transaction 

GS 1 / 13 Separates fields of a logical record 

RS 1 / 14 Separates multiple data entries (subfields) of an 

Information field 

US 1 / 15 Separates individual information items of the field or 

subfield 

These separators shall be in addition to any other symbols, punctuation, or delimiters as specified 

in this standard. Annex B illustrates the use of these characters, and Annex F provides examples 

of their use in the standard. 

The four characters are only meaningful when used as separators of data items in the fields of 

the ASCII text records. There is no specific meaning attached to these characters occurring in 

binary image records and binary fields – they are just part of the exchanged data. 

Normally, there should be no empty fields or information items and therefore only one separator 

character should appear between any two data items. The exception to this rule occurs for those 

instances where the data in fields or information items in a transaction are unavailable, missing, 

or optional, and the processing of the transaction is not dependent upon the presence of that 

particular data. In those instances, multiple and adjacent separator characters shall appear 

together rather than requiring the insertion of dummy data between separator characters. 
Part 1 ANSI/NIST-ITL 1-2007

22

Consider the definition of a field that consists of three information items. If the information for the 

second information item is missing, then two adjacent “US” information separator characters 

would occur between the first and third information items. If the second and third information 

items were both missing, then three separator characters should be used – two “US” characters 

in addition to the terminating field or subfield separator character. In general, if one or more 

mandatory or optional information items are unavailable for a field or subfield, then the 

appropriate number of separator character should be inserted. 

It is possible to have side-by-side combinations of two or more of the four available separator 

characters. When data are missing or unavailable for information items, subfields, or fields, there 

must be one fewer separator characters present than the number of data items, subfields, or 

fields required. 

8.2.2 Record layout 

For tagged-field logical records (Type-1, Type-2, Type-9, Type-10 through Type-17, and Type99), each information field that is used shall be numbered in accordance with this standard. The 

format for each field shall consist of the logical record type number (chosen from Table 4) 

followed by a period “.”, a field number followed by a colon “:”, followed by the information 

appropriate to that field. The tagged-field number can be any one to nine-digit number occurring 

between the period “.” and the colon “:”. It shall be interpreted as an unsigned integer field 

number. This implies that a field number of “2.123:” is equivalent to and shall be interpreted in 

the same manner as a field number of “2.000000123:”. 

NOTE: For purposes of illustration throughout this document, a three-digit number shall be used 

for enumerating the fields contained in each of the tagged-field logical records described herein. 

Field numbers will have the form of “TT.xxx:” where the “TT” represents the one- or two-character 

record type followed by a period. The next three characters comprise the appropriate field 

number followed by a colon. Descriptive ASCII information or the image data follows the colon. 

Logical Type-1, Type-2, and Type-9 records contain only ASCII textual data fields. The entire 

length of the record (including field numbers, colons, and separator characters) shall be recorded 

as the first ASCII field within each of these record types. The ASCII File Separator “FS” control 

character (signifying the end of the logical record or transaction) shall follow the last byte of ASCII 

information and shall be included in the length of the record. 

In contrast to the tagged-field concept, the Type-3 through Type-8 records contains only binary 

data recorded as ordered fixed-length binary fields. The entire length of the record shall be 

recorded in the first four-byte binary field of each record. For these binary records, neither the 

record number with its period, nor the field identifier number and its following colon, shall be 

recorded. Furthermore, as all the field lengths of these six records are either fixed and specified, 

none of the four separator characters (“US”, “RS”, ”GS”, or “FS”) shall be interpreted as anything 

other than binary data. For these binary records, the “FS” character shall not be used as a record 

separator or transaction terminating character. 

The Type-10 through Type-17 and Type-99 tagged-field image records combine ASCII fields with 

a single binary image field. Each ASCII field contains a numeric field identifier and its descriptive 

data. The last physical field in a tagged-field image record shall always be numbered "999" and 

shall contain the image data placed immediately following the colon (":") of the field identifier. 

The record length field shall contain the length of the record. The ASCII File Separator “FS”

control character shall follow the last byte of the compressed or uncompressed image data. The 

“FS” character shall signify the end of the logical record or transaction and shall be included as 

part of the record length. 
Part 1 ANSI/NIST-ITL 1-2007

23

8.2.3 International character sets 

All of the fields in the Type-1 transaction record must be recorded using the 7-bit ASCII code, 

which is the default character set code within a transaction. In order to affect data and 

transaction interchanges between non-English speaking or based agencies, a technique is 

available to encode information using character sets other than 7-bit ASCII. Fields from theType1 logical record and ASCII “LEN” and “IDC” text fields must still be encoded using 7-bit ASCII. 

But all other designated text fields can be encoded using alternate character sets. The general 

mechanism for accomplishing this provides for backward compatibility with existing readers, 

supports multiple character sets in a single text string, and handles internationally accepted 

character sets and text order conventions such as ISO character sets, UTF-8, and Unicode. 

To switch character sets within a transaction, the Type-1 record shall contain a field listing the 

Directory of Character Sets (DCS) used in the transaction. The DCS is an ordered list of triples, 

each consisting of 3 information items containing an identifying code, the name of an international 

character set, and its version. The code for a specific character set and other special codes shall 

be embedded in the transaction to signal the conversion to a different international character set. 

The ASCII Start-of-Text “STX” character (0x02) followed by the equal sign “=” is used to signal 

the change to an alternate character set defined by the specific DCS code that follows. The 

entire Start-of-Text sequence is terminated by a single instance of the ASCII End-of-Text “ETX” 

character (0x03). This alternate character set will remain active until a closing "ETX" character is 

encountered or the next ASCII information separator character is encountered. 

The base-64 encoding scheme, found in email, shall be used for converting non-ASCII text into 

ASCII form. Annex C describes the use of the base-64 system. By convention, any language or 

character set text string following the Start-of-Text character sequence will be base-64 encoded 

for subsequent processing. The field number including the period and colon, for example 

“2.001:”, in addition to the “US”, “RS”, “GS”, and “FS” information separators shall appear in the 

transaction as 7-bit ASCII characters without conversion to base-64 encoding. 

All text between the STX sequence and the closing ETX character shall be encoded in base-64 

notation. This is true even when the 7-bit ASCII character set is specified. 

Usage of UTF-8 is allowed as an alternative to the technique that requires the usage of the ASCII 

"STX" and "ETX" characters to signify the beginning or end of international characters. UTF-8 is 

only allowed to be used for user-defined fields of all the tagged-field records. Even though there 

is no overlap within the character sets used with UTF-8, it should be registered in the type 1 

record within DCS field 1.15 (Directory of Character Sets). 

9 Type-1 transaction information record 

9.1 Fields for Type-1 transaction information record 

The following paragraphs describe the data contained in each field of the transaction information 

record. Each field shall begin with the number of the record type followed by a period followed by 

the appropriate field number followed by a colon. Table 8 provides a list of the fields for the 

transaction information record. Within a Type-1 logical record, entries shall be provided in 

numbered fields. It is required that the first two fields of the record are ordered. For each of the 

fields, Table 8 lists the “condition code” as being mandatory “M” or optional “O”, the field number, 

the field name, character type, field size, and occurrence limits. Based on a three digit field 

number, the maximum byte count size for the field is given in the last column. The two entries in 

the “field size per occurrence” include all character separators used in the field. The “maximum 

byte count” includes the field number, the information, and all the character separators. An entry 
Part 1 ANSI/NIST-ITL 1-2007

24

containing an "*" indicate that there is no established limit. Annex F contains an example of the 

use of the standard that illustrates the layout for a Type-1 logical record. 

Table 8 Type-1 Transaction information record layout 

Ident Cond 

code 

Field 

number 

 Field name Char 

type

Field size per 

occurrence 

Occur 

count 

Max byte 

count 

 Min max min Max 

LEN M 1.001 LOGICAL RECORD LENGTH N 2 * 1 1 * 

VER M 1.002 VERSION NUMBER N 5 5 1 1 11 

CNT M 1.003 FILE CONTENT AN 4 6 2 * * 

TOT M 1.004 TYPE OF TRANSACTION A 4 5 1 1 11 

DAT M 1.005 DATE N 9 9 1 1 15 

PRY O 1.006 PRIORITY N 2 2 0 1 8 

DAI M 1.007 DESTINATION AGENCY 

IDENTIFIER 

N * * 1 1 * 

ORI M 1.008 ORIGINATING AGENCY 

IDENTIFIER 

N * * 1 1 * 

TCN M 1.009 TRANSACTION CONTROL 

NUMBER 

N * * 1 1 * 

TCR O 1.010 TRANSACTION CONTROL 

REFERENCE NUMBER 

N * * 0 1 * 

NSR M 1.011 NATIVE SCANNING 

RESOLUTION 

AN 6 7 1 1 13 

NTR M 1.012 NOMINAL TRANSMITTING 

RESOLUTION 

AN 6 7 1 1 13 

DOM O 1.013 DOMAIN NAME AN * * 0 1 * 

GMT O 1.014 GREENWICH MEAN TIME N 16 16 0 1 22 

DCS O 1.015 DIRECTORY OF CHARACTER 

SETS 

AN * * 0 * * 

Key for character type: N = Numeric; A = Alphabetic; AN = Alphanumeric; B = Binary 

9.1.1 Field 1.001: Logical record length (LEN) 

This mandatory ASCII field shall contain the total count of the number of bytes in this Type-1 

logical record. Field 1.001 shall begin with “1.001:” followed by the length of the record including 

every character of every field contained in the record and the information separators. The “GS”

separator character shall separate the length code of Field 1.001 from the next field. 

NOTE: Although it will not always be explicitly repeated in the remainder of this standard, use of 

separators within the Type-1, Type-2, and tagged-field logical records shall always be observed. 

The “US” separator shall separate multiple information items within a field or subfield, the “RS”
Part 1 ANSI/NIST-ITL 1-2007

25

separator shall separate multiple subfields, and the “GS” separator shall separate information 

fields. 

9.1.2 Field 1.002: Version number (VER) 

This mandatory four-byte ASCII field shall be used to specify the current version number of the 

standard implemented by the software or system creating the file. The format of this field shall 

consist of four numeric characters. The first two characters shall specify the major version 

number. The last two characters shall be used to specify the minor revision number. The initial 

revision number for a version shall be "00”. The entry in this field for the 2000 version is "0300" 

and the entry for this 2007 version of the approved standard shall be "0400". This version 

number addresses the optional inclusion of the tagged-field logical Type-10 through 

Type-17 and Type-99 image records. 

9.1.3 Field 1.003: File content (CNT) 

This mandatory field shall list and identify each of the logical records in the file by record type. It 

also specifies the order in which the remaining logical records shall appear in the file. It shall 

consist of two or more subfields. Each subfield shall contain two information items describing a 

single logical record found in the current file. The subfields shall be entered in the same order in 

which the logical records shall appear and be transmitted. The “RS” separator character shall be 

entered between the subfields. 

The first subfield shall relate to this Type-1 Transaction record. The first information item within 

this subfield shall be the single character "1" (selected from Table 4 ) indicating that this is a 

Type-1 record consisting of header information. The second information item of this subfield 

shall be the sum of the Type-2 through Type-99 logical records contained in this file. This 

number is also equal to the count of the remaining subfields of Field 1.003. The “US” separator 

character shall be entered between the first and second information items. 

Each of the remaining subfields of Field 1.003 relate to a single Type-2 through Type-99 logical

record contained in the file. Two information items shall comprise each subfield. The first 

information item shall be the record identifier character(s) chosen from Table 4 that identifies the 

record type. The second item shall be the IDC associated with the logical record pertaining to that 

subfield. The IDC shall be a positive integer equal to or greater than zero. The “US” character 

shall be used to separate the two information items. 

9.1.4 Field 1.004: Type of transaction (TOT) 

This mandatory field shall contain an identifier, which designates the type of transaction and 

subsequent processing that this file should be given. (Note: Type of Transaction shall be in 

accordance with definitions provided by the receiving agency.) The last character of this field 

shall be a “GS” separator character used to separate Field 1.004 from the next field. 

9.1.5 Field 1.005: Date (DAT) 

This mandatory field shall contain the date that the transaction was initiated. The date shall 

appear as eight digits in the format YYYYMMDD. The YYYY characters shall represent the year 

of the transaction; the MM characters shall be the tens and units values of the month; and the DD 

characters shall be the day in the month. For example, “20070103” represents January 3, 2007. 
Part 1 ANSI/NIST-ITL 1-2007

26

9.1.6 Field 1.006: Priority (PRY) 

This optional field shall contain a single information character to designate the urgency with which 

a response is desired. The values shall range from “1” to “9”, with "1" denoting the highest 

priority. The default value shall be defined by the agency receiving the transaction. 

9.1.7 Field 1.007: Destination agency identifier (DAI) 

This mandatory field shall contain the identifier of the administration or organization designated to 

receive the transmission. The size and data content of this field shall be user-defined and in 

accordance with the receiving agency. 

9.1.8 Field 1.008: Originating agency identifier (ORI) 

This mandatory field shall contain the identifier of the administration or organization originating 

the transaction. The size and data content of this field shall be user-defined and in accordance 

with the receiving agency. 

9.1.9 Field 1.009: Transaction control number (TCN) 

This mandatory field shall contain the Transaction Control Number as assigned by the originating 

agency. A unique alphanumeric control number shall be assigned to each transaction. For any 

transaction that requires a response, the respondent shall refer to this number in communicating 

with the originating agency. 

9.1.10 Field 1.010: Transaction control reference (TCR) 

This optional field shall be used for responses that refer to the TCN of a previous transaction 

involving an inquiry or other action that required a response. 

9.1.11 Field 1.011: Native scanning resolution (NSR) 

This mandatory field shall specify the native scanning resolution of the AFIS or other fingerprint or 

palmprint image capture device supported by the originator of the transmission. This field permits 

the recipient of this transaction to send response data at a transmitting resolution tailored to the 

NSR (if it is able to do so) or to the minimum scanning resolution. This field shall contain five 

bytes specifying the native scanning resolution in pixels per millimeter. The resolution shall be 

expressed as two numeric characters followed by a decimal point and two more numeric 

characters (e.g., 19.69). This field is needed because the interchange of fingerprint information 

between systems of the same manufacturer may, in some instances, be more efficiently done at 

a transmitting resolution equal to the native scanning resolution of the system rather than at the 

minimum scanning resolution specified in this standard. For transactions that do not contain 

Type-3 through Type-7 fingerprint image records, this field shall be set to “00.00”. 

9.1.12 Field 1.012: Nominal transmitting resolution (NTR) 

This mandatory field shall specify the nominal transmitting resolution for the fingerprint or 

palmprint image(s) being exchanged. This field shall contain five bytes specifying the transmitting 

resolution in pixels per millimeter. The resolution shall be expressed as two numeric characters 

followed by a decimal point and two more numeric characters (e.g., 19.69). The transmitting 

resolution shall be within the range specified by the transmitting resolution requirement. For 

transactions that do not contain Type-3 through Type-7 fingerprint image records, this field shall 

be set to “00.00”. 
Part 1 ANSI/NIST-ITL 1-2007

27

9.1.13 Field 1.013: Domain name (DOM) 

This optional field identifies the domain name for the user-defined Type-2 logical record 

implementation. If present, the domain name may only appear once within a transaction. It shall 

consist of one or two information items. The first information item will uniquely identify the 

agency, entity, or implementation used for formatting the tagged fields in the Type-2 record. An 

optional second information item will contain the unique version of the particular implementation. 

The default value for the field shall be the North American Domain implementation and shall 

appear as “1.013:NORAM{US}{GS}”. 

9.1.14 Field 1.014: Greenwich mean time (GMT) 

This optional field provides a mechanism for expressing the date and time in terms of universal 

Greenwich Mean Time (GMT) units. If used, the GMT field contains the universal date that will be 

in addition to the local date contained in Field 1.005 (DAT). Use of the GMT field eliminates local 

time inconsistencies encountered when a transaction and its response are transmitted between 

two places separated by several time zones. The GMT provides a universal date and 24-hour 

clock time independent of time zones. It is represented as "YYYYMMDDHHMMSSZ”, a 15-

character string that is the concatenation of the date with the GMT and concludes with a “Z”. The 

“YYYY” characters shall represent the year of the transaction, the “MM” characters shall be the 

tens and units values of the month, and the “DD” characters shall be the tens and units values of 

the day of the month, the “HH” characters represent the hour, the “MM” the minute, and the “SS” 

represents the second. The complete date shall not exceed the current date. 

9.1.15 Field 1.015: Directory of character sets (DCS) 

This optional field is a directory or list of character sets other than 7-bit ASCII that may appear 

within this transaction. This field shall contain one or more subfields, each with three information 

items. The first information item is the three-character identifier for the character set index 

number that references an associated character set throughout the transaction file. The second 

information item shall be the common name for the character set associated with that index 

number, the optional third information item is the specific version of the character set used. In the 

case of the use of UTF-8, the third optional information item can be used to hold the specific 

version of the character set used with UTF-8, so that the display terminal can be switched to the 

correct font family. Table 9 lists the reserved named character sets and their associated 3-

character index numbers. The “US” character shall separate the first information item from the 

second and the second from the third. The “RS” separator character shall be used between the 

subfields. 

Table 9 Directory of character sets 

Character 

set index 

Character 

set name 

Description 

000 ASCII 7-bit English (Default) 

001 ASCII 8-bit Latin 

002 UNICODE 16-bit 

003 UTF-8 8-bit 

004-127 ------------- Reserved for ANSI/NIST future use 

128-999 ------------- User-defined character sets 
Part 1 ANSI/NIST-ITL 1-2007

28

9.2 End of transaction information record Type-1 

Immediately following the last information field in the Type-1 logical record, an “FS” separator 

character shall be used to separate it from the next logical record. This “FS” character shall 

replace the “GS” character that is normally used between information fields. 

10 Type-2 user-defined descriptive text record 

Type-2 logical records shall contain textual information relating to the subject of the transaction 

and shall be represented in an ASCII format. This record may include such information as the 

state or FBI numbers, physical characteristics, demographic data, and the subject’s criminal 

history. Every transaction usually contains one or more Type-2 records which is dependent upon 

the entry in the Type-of-Transaction Field 1.004 (TOT). 

10.1 Fields for Type-2 logical records 

The first two data fields of the Type-2 record are mandatory, ordered, and defined by this 

standard. The remaining fields of the record(s) shall conform to the format, content, and 

requirements of the subscribed Domain Name (DOM) used by the agency to which the 

transmission is being sent. 

10.1.1 Field 2.001: Logical record length (LEN) 

This mandatory ASCII field shall contain the length of the logical record specifying the total 

number of bytes, including every character of every field contained in the record. 

10.1.2 Field 2.002: Image designation character (IDC) 

This mandatory field shall be used to identify the user-defined text information contained in this 

record. The IDC contained in this field shall be the IDC of the Type-2 logical record as found in 

the file content (CNT) field of the Type-1 record. 

10.1.3 Field 2.003 and above: User-defined fields 

Individual fields required for given transaction types, including field size and content, shall 

conform to the specifications set forth by the agency to whom the transmission is being sent. 

Each one to nine digit tagged-field number used in the Type-2 record and its format shall conform 

to the requirements contained in Section 8.2.2 Record Layout. 

10.2 End of Type-2 user-defined descriptive text record 

Immediately following the last information field in every Type-2 logical record, an “FS” separator 

shall be used to separate it from the next logical record. This “FS” character shall replace the 

“GS” character that is normally used between information fields. 

10.3 Additional user-defined descriptive text records 

Additional Type-2 records may be included in the file. For each additional user-defined 

descriptive text record present, the record length and IDC fields will be required together with 

additional Type-2 fields needed. 
Part 1 ANSI/NIST-ITL 1-2007

29

11 Type-3 through Type-6 fingerprint image records 

11.1 General 

As discussed in Section 8.1.3, the Type-3 through Type-6 logical records are based on the use of 

a captured fingerprint image obtained using a scanning resolution that is at least as great as the 

minimal scanning resolution of 19.69 ppmm (500 ppi). The records differ from each other based 

on the properties of the transmitted image - data type (grayscale or binary) and resolution 

(scanning resolution or half-resolution). 

All four of the logical records use the same field structure for the record and exchange of data. 

Within each logical record, entries shall be provided in nine ordered and unnumbered fields. The 

data recorded is in binary form – no ASCII data. The first eight fields are fixed length and total 

eighteen bytes. These fields precede the image data contained in field nine. The size of the ninth 

field is eighteen bytes less than the value specified in the LEN field. Table 10 lists the contents of 

each of the nine fields. 

11.2 Types 3-6 logical record field descriptions 

The following descriptions for each field in Table 10 are applicable to logical record types 3-6. 

Table 10 Type 3-6 record layout 

Field 

Number 

Tag Field Description Byte Count Byte Position 

1 LEN Logical record length 4 1-4 

2 IDC Image designation character 1 5 

3 IMP Impression type 1 6 

4 FGP Finger position 6 7-12 

5 ISR Image scanning resolution 1 13 

6 HLL Horizontal line length 2 14-15 

7 VLL Vertical line length 2 16-17 

8 GCA / BCA Compression algorithm 1 18 

9 DATA Image data <LEN> – 18 19 through <LEN> 

11.2.1 Logical record length (LEN) 

This mandatory four-byte binary field shall occupy bytes one through four of each record type. It 

shall contain the length of the logical record specifying the total number of bytes, including every 

byte of all nine fields contained in the record. 
Part 1 ANSI/NIST-ITL 1-2007

30

11.2.2 Image designation character (IDC) 

This mandatory one-byte binary field shall occupy the fifth byte of each record type. It shall be 

used to identify the image data contained in this record. The IDC contained in this field shall be a 

binary representation of the IDC found in the file content (CNT) field of the Type-1 record. 

11.2.3 Impression type (IMP) 

This mandatory one byte binary field shall occupy the sixth byte of each record type. The code 

selected from Table 11, describing the manner by which the fingerprint image information was 

obtained, shall be entered in this field. 

Table 11 Finger & palm impression types 

Description Code 

Live-scan plain 0 

Live-scan rolled 1 

Nonlive-scan plain 2 

Nonlive-scan rolled 3 

Latent impression 4 

Latent tracing 5 

Latent photo 6 

Latent lift 7 

Live-scan vertical swipe 8 

Live-scan palm 10 

Nonlive-scan palm 11 

Latent palm impression 12 

Latent palm tracing 13 

Latent palm photo 14 

Latent palm lift 15 

Live-scan optical contact plain 20 

Live-scan optical contact rolled 21 

Live-scan non-optical contact plain 22 

Live-scan non-optical contact rolled 23 

Live-scan optical contactless plain 24 

Live-scan optical contactless rolled 25 

Live-scan non-optical contactless plain 26 

Live-scan non-optical contactless rolled 27 

Other 28 

Unknown 29 

Note: Table 11 is also used to describe the manner by which palm image 

information was obtained. 

11.2.4 Finger position (FGP) 

This mandatory fixed-length field of six binary bytes shall occupy the seventh through twelfth byte 

positions of each record type. It shall contain possible finger positions beginning in the leftmost 

byte of the field (byte seven of the record). The decimal code number corresponding to the 

known or most probable finger position shall be taken from Table 12 (only finger numbers 0-14 

apply to Types 3-6) and entered as a binary number right justified and left zero filled within the 

eight-bit byte. Table 12 also lists the maximum image width and height dimensions for each of 
Part 1 ANSI/NIST-ITL 1-2007

31

the finger positions. Up to five additional finger positions may be referenced by entering the 

alternate finger positions in the remaining five bytes using the same format. 

Table 12 Finger position code & maximum image dimensions 

Finger position Finger 

code 

Width 

(mm) (in) 

Length 

(mm) (in) 

Unknown 0 40.6 1.6 38.1 1.5 

Right thumb 1 40.6 1.6 38.1 1.5 

Right index finger 2 40.6 1.6 38.1 1.5 

Right middle finger 3 40.6 1.6 38.1 1.5 

Right ring finger 4 40.6 1.6 38.1 1.5 

Right little finger 5 40.6 1.6 38.1 1.5 

Left thumb 6 40.6 1.6 38.1 1.5 

Left index finger 7 40.6 1.6 38.1 1.5 

Left middle finger 8 40.6 1.6 38.1 1.5 

Left ring finger 9 40.6 1.6 38.1 1.5 

Left little finger 10 40.6 1.6 38.1 1.5 

Plain right thumb 11 25.4 1.0 50.8 2.0 

Plain left thumb 12 25.4 1.0 50.8 2.0 

Plain right four fingers 13 81.3 3.2 76.2 3.0 

Plain left four fingers 14 81.3 3.2 76.2 3.0 

Left & right thumbs 15 81.3 3.2 76.2 3.0 

EJI or tip 19 114.3 4.5 127.0 5.0 

Note: Finger codes 15 and 19 apply to tagged-field fingerprint image records. 

If fewer than five finger position references are to be used, the unused bytes shall be filled with 

the binary equivalent of "255". The code "0", for "Unknown Finger", shall be used to reference 

every finger position from one through ten. 

11.2.5 Image scanning resolution (ISR) 

This mandatory one-byte binary field shall occupy the thirteenth byte of each record type. 

• For Type-3 or Type-5 logical records, it shall contain a binary value of “0” if half the minimum 

scanning resolution is used and a “1” if half the native scanning resolution is used; 

• For Type-4 or Type-6 logical records, it shall contain a binary value of “0” if the minimum 

scanning resolution is used and a “1” if the native scanning resolution is used. 

See Section 6.2 where it is stated that the preferred transmitting resolution shall be the same as 

the minimum scanning resolution. 
Part 1 ANSI/NIST-ITL 1-2007

32

11.2.6 Horizontal line length (HLL) 

This mandatory two-byte binary field shall occupy the fourteenth and fifteenth bytes of each 

record type. It shall be used to specify the number of pixels contained on a single horizontal line 

of the transmitted image. 

11.2.7 Vertical line length (VLL) 

This mandatory two-byte binary field shall occupy the sixteenth and seventeenth bytes of the 

each record type. It shall be used to specify the number of horizontal lines contained in the 

transmitted image. 

11.2.8 Compression algorithm (GCA / BCA) 

This mandatory one-byte binary field shall occupy the eighteenth byte of each record type. It 

shall be used to specify the type of compression algorithm used (if any). A binary zero denotes 

no compression. Otherwise, the contents of this byte shall be a binary representation of the 

number allocated to the particular compression technique used by the interchange parties. The 

specific code for each algorithm can be found in Table 1 or Table 2 or from the domain registrar 

who will maintain a registry relating these numbers to the compression algorithms. 

• For the Type-3 logical record, there is no recommendation for a commonly used grayscale 

compression algorithm; 

• For the Type-4 logical record, the Wavelet Scalar Quantization (WSQ), or the JPEG 10918 

standard alogithms are recommended for compressing the high-resolution grayscale data; 

• For Type-5 or Type 6 logical records, the Facsimile ANSI/EIA 538-1988 algorithm is 

recommended for the lossless compression and decompression of binary fingerprint images. 

11.2.9 Image data 

This mandatory final binary field shall contain the image data. Each pixel of the uncompressed 

grayscale image shall be quantized to eight bits (256 gray levels) contained in a single byte. For 

the exchange of an uncompressed binary image, eight pixels shall be left justified and packed 

into a single unsigned byte. The most significant bit of the byte shall be the first of the eight pixels 

scanned. If compression is used, the pixel data shall be compressed in accordance with the 

compression technique specified in the CGA / BCA field. 

11.3 End of fixed-resolution fingerprint image record 

Since each of these logical records is a defined and specified series of binary data fields, no 

additional bytes shall be transmitted to signify the end of this logical record type. This completes 

the description of a Type-3 through Type-6 fixed-resolution fingerprint image records. 

11.4 Additional fixed-resolution fingerprint image records 

Typically, for each of these logical record types, there may be up to thirteen additional images 

contained within the transaction file. For each additional image, a logical record is required. 

12 Type-7 user-defined image record 

Type-7 logical records shall contain user-defined binary image information relating to the 

transaction submitted for processing. This record type was originally defined to handle 

miscellaneous images such as those pertaining to mugshots, latent prints, palm prints, wrists, 
Part 1 ANSI/NIST-ITL 1-2007

33

toes, soles, etc. that were not addressed elsewhere in the standard. However, it is not intended 

that the use of the Type-7 record is restricted by the existence of other record types in this 

standard. 

Type-7 records are still commonly used for the exchange of latent fingerprints. But since its 

creation, tagged-field formatted record types have also been formally defined and are used by 

this standard to handle mugshots (Type-10), latent fingerprint images (Type-13), variableresolution fingerprint images (Type-14), palm print images( Type-15), and other user-defined 

image records (Type-16). 

These images shall consist of scanned pixels that may be either binary or grayscale output. Each 

grayscale pixel value shall be expressed as an unsigned byte. A value of “0” shall be used to 

define a black pixel and an unsigned value of “255” shall be used to define a white pixel. For 

binary pixels, a value of “0” shall represent a white pixel and a value of “1” shall represent a black 

pixel. If compression is used, the algorithm shall be the same as that specified for Type-3 

through Type-6 logical records. 

12.1 Fields for Type-7 logical record 

The Type-7 logical record is a binary record that shall not contain any ASCII data. The first two 

data fields of the Type-7 record are defined by this Standard. Remaining fields of the record shall 

conform to the requirements set forth by the agency receiving the transmission. 

The first two fields are fixed length and total five bytes. These fields shall precede one or more 

user-defined fields, including the image data, contained in the remainder of the record. 

12.1.1 Logical record length (LEN) 

This mandatory four-byte binary field shall occupy bytes one through four. It shall contain the 

length of the logical record specifying the total number of bytes, including every byte of all the 

fields contained in the record. 

12.1.2 Image designation character (IDC) 

This mandatory one-byte binary field shall occupy the fifth byte of a Type-7 record. It shall be 

used to identify the image data contained in this record. The IDC contained in this field shall be a 

binary representation of the IDC found in the file content (CNT) field of the Type-1 record. 

12.1.3 User-defined fields for Type-7 logical record 

The remaining fields of the Type-7 logical record shall be user-defined. Individual fields required 

for a given transaction, such as field description, size, and content shall conform to the 

specifications set forth by the agency to whom the transmission is being sent. 

12.2 End of Type-7 user-defined image record 

Since the Type-7 logical record is a defined and specified series of binary data fields, no 

additional bytes shall be transmitted to signify the end of this logical record type. 

12.3 Additional user-defined image records 

Additional images may be described within the file. For each additional image, a Type-7 logical 

record is required. 
Part 1 ANSI/NIST-ITL 1-2007

34

13 Type-8 signature image record 

Type-8 logical records shall contain either scanned or vectored signature data. Each Type-8 

record shall cover an area of up to 1000 mm2

. 

If scanned, the resolution shall be the minimum scanning resolution or the native scanning 

resolution, and the scan sequence shall be left to right and top to bottom. The scanned data shall 

be a binary representation quantized to two levels. 

If vectored signature data is present, it shall be expressed as a series of binary numbers. 

13.1 Fields for Type-8 logical record 

When one or two Type-8 logical records are used, entries shall be provided in eight ordered and 

unnumbered binary fields for each signature record. Table 13 provides a list of the fields for the 

Type-8 logical record. The first seven fields are fixed length and shall total twelve bytes. These 

fields shall precede the image data contained in field eight. The size of field eight is determined 

from the LEN field of the record itself. The image data field is 12 bytes less than the value 

specified in the LEN field. 

Table 13 Type-8 record layout 

Field 

Number 

Tag Field Description Byte Count Byte Position 

1 LEN Logical record length 4 1-4 

2 IDC Image designation character 1 5 

3 SIG Signature type 1 6 

4 SRT Signature representation type 1 7 

5 ISR Image scanning resolution 1 8 

6 HLL Horizontal line length 2 9-10 

7 VLL Vertical line length 2 11-12 

8 DATA Signature image data <LEN> – 12 13 through <LEN> 

13.1.1 Logical record length (LEN) 

This mandatory four-byte binary field shall occupy bytes one through four. It shall contain the 

length of the logical record expressed as the total number of bytes, including every byte of all 

eight fields contained in the record. 

13.1.2 Image designation character (IDC) 

This mandatory one-byte binary field shall occupy the fifth byte of the Type-8 record. It shall be 

used to identify the image data contained in the Type-8 record. The IDC contained in this field 

shall be a binary representation of the IDC found in the file content (CNT) field of the Type-1 

record. 
Part 1 ANSI/NIST-ITL 1-2007

35

13.1.3 Signature type (SIG) 

This mandatory one-byte binary field shall occupy the sixth byte of the Type-8 record. It shall 

contain a binary “0” for the signature image of the subject, or a binary “1” for the signature image 

of the official processing the transaction. 

13.1.4 Signature representation type (SRT) 

This mandatory one-byte binary field shall occupy the seventh byte of the Type-8 record. Its 

value shall be a binary “0” if the image is scanned and not compressed, a binary “1” if the image 

is scanned and compressed, and the binary equivalent of “2” if the image is vector data. 

13.1.5 Image scanning resolution (ISR) 

This mandatory one-byte binary field shall occupy the eighth byte of a Type-8 record. It shall 

contain a binary “0” if the minimum scanning resolution is used and a binary “1” if the native 

scanning resolution is used. A binary value of “0” shall also be used if the image is vector data. 

13.1.6 Horizontal line length (HLL) 

This mandatory two-byte binary field shall occupy the ninth and tenth bytes of the Type-8 record. 

For scanned signature data, this field shall be used to specify the number of pixels contained on a 

single horizontal line of the transmitted signature image. For vectored signature data, both bytes 

shall contain the binary value of “0”. 

13.1.7 Vertical line length (VLL) 

This mandatory two-byte binary field shall occupy the eleventh and twelfth bytes of the Type-8 

record. For scanned signature data, this field shall be used to specify the number of horizontal 

lines contained in the transmitted signature image. For vectored signature data, both bytes shall 

contain the binary value of “0”. 

13.1.8 Signature image data (DATA) 

This mandatory field shall contain uncompressed scanned image signature data, compressed 

scanned image signature data, or vectored image signature data. The entry contained in the 

SRT field shall indicate which form of the signature data is present. 

13.1.8.1 Uncompressed scanned image data 

If the SRT field contains the binary value of “0”, then this field shall contain the uncompressed 

scanned binary image data for the signature. In uncompressed mode, the data shall be packed 

at eight pixels per byte. 

13.1.8.2 Compressed scanned image data 

If the SRT field contains the binary value of “1”, then this field shall contain the scanned binary 

image data for the signature in compressed form using the ANSI/EIA-538-1988 facsimile 

compression algorithm. 
Part 1 ANSI/NIST-ITL 1-2007

36

13.1.8.3 Vectored image data 

If the SRT field contains the binary equivalent of “2”, then this field shall contain a list of vectors 

describing the pen position and pen pressure of line segments within the signature. Each vector 

shall consist of five bytes. 

The first two bytes of each vector shall contain the unsigned binary X coordinate of the pen 

position with the high order byte containing the most significant bits. The next two bytes shall 

contain the unsigned Y coordinate using the same convention to denote the most significant bits. 

Both the X and Y coordinates shall be expressed in units of .0254 mm (.001 inches) referenced 

from the bottom leftmost corner of the signature. Positive values of X shall increase from left-toright and positive values of Y shall increase from bottom-to-top. 

An unsigned binary number between “0” and “255” contained in the fifth byte shall represent the 

pen pressure. This shall be a constant pressure until the next vector becomes active. A binary 

value or pressure of “0” shall represent a "pen-up" (or no pressure) condition. The binary value of 

“1” shall represent the least recordable pressure for a particular device, while the binary 

equivalent of “254” shall represent the maximum recordable pressure for that device. To denote 

the end of the vector list the binary equivalent of “255” shall be inserted in this entry. 

13.2 End of Type-8 signature image record 

Since the Type-8 logical record is a defined and specified series of binary data fields, no 

additional bytes shall be transmitted to signify the end of this logical record type. 

13.3 Additional signature 

One more signature may be described within the file. For an additional signature, a Type-8 

logical record is required. 

14 Type-9 minutiae data record 

Type-9 records shall contain ASCII text describing minutiae and related information encoded from 

a finger or palm. For a tenprint search transaction, generally there may be up to ten of these 

Type-9 records in a file, each of which shall be for a different finger. There may be up to eight 

records for palmprint searches - each record representing a different area on one of the two 

palms. The Type-9 record shall also be used to exchange the minutiae information from latent 

finger or palm images between similar or different systems. 

Minutiae information may be extracted and encoded in any of several different manners 

depending on the system that is used to scan an image, extract minutiae, and encode the 

minutiae template. The “standard format” defines a common block of tagged fields 1-12 based 

on the conventions and parameters described below in Section 14.1. Additional reserved blocks, 

each consisting of several tagged fields, are registered and allocated for use by specific vendors. 

As these blocks may contain proprietary information, no detailed information is provided 

regarding the content of these vendor-defined fields aside from the range of field numbers in this 

standard. For detailed information on each of these tagged fields, the vendor must be contacted. 

These alternative blocks of reserved fields, beginning at Field-13, allow vendors to encode 

minutiae data and any additional required characteristic or feature data in accordance with their 

own system’s specific hardware and software configuration. The assignment of blocks of tagged 

fields to specific vendors is controlled by the domain registrar responsible for the implementation 

domain. By default this shall be the registrar for the North American Domain. Table 14 identifies 

the current vendor implementations and their assigned blocks of field numbers. 
Part 1 ANSI/NIST-ITL 1-2007

37

Table 14 Registered vendor minutiae blocks 

Fields Implementations 

1-4 ALL 

5-12 Standard Format Features 

13-30 IAFIS Features 

31-55 Cogent Systems Features 

56-70 Motorola Features 

71-99 Sagem Morpho Features 

100-125 NEC Features 

126-150 M1-378 Features 

151-175 Identix Features 

The M1-378 block is a special case as it adheres to the conventions defined and described by the 

ANSI INCITS 378-2004 standard. Annex G contains detailed descriptions of the fields used for 

the M1-378 features together with the required conventions and parameters. 

14.1 Minutiae and other information descriptors (Standard Format) 

14.1.1 Minutia type identification 

This standard defines four identifier characters that are used to describe the minutia type. These 

are listed in Table 15. A ridge ending shall be designated Type A. It occurs at the point on a 

fingerprint or palmprint that a friction ridge begins or ends without splitting into two or more 

continuing ridges. The ridge must be longer than it is wide. A bifurcation shall be designated 

Type B. It occurs at the point that a ridge divides or splits to form two ridges that continue past 

the point of division for a distance that is at least equal to the spacing between adjacent ridges at 

the point of bifurcation. A minutia shall be designated Type C, a compound type, if it is either a 

trifurcation (a single ridge that splits into three ridges) or a crossover (two ridges that intersect). If 

a minutia cannot be clearly categorized as one of the above three types, it shall be designated as 

undetermined, Type D. 

Table 15 Minutiae types 

Type Description 

A Ridge ending 

B Bifurcation 

C Compound (trifurcation or crossover) 

D Type undetermined 
Part 1 ANSI/NIST-ITL 1-2007

38

14.1.2 Minutia numbering 

Each minutia shall be identified by an index number that is assigned to it. The numbering shall 

begin at “1” and be incremented by “1” for as many times as there are minutiae encountered. 

This allows each minutia to be uniquely identified. The numbering of the minutiae shall be 

unordered. 

14.1.3 Minutiae ridge counts 

As required, ridge counts shall be determined from each minutia in a fingerprint or palmprint to 

certain other neighboring minutiae. When this occurs, ridge counts between designated minutiae 

shall be associated with the applicable index numbers so as to ensure maintenance of the proper 

relationships. Rules for identifying neighboring minutiae and the method to be used for counting 

the intervening ridge crossings is not part of this “standard format”. 

14.1.4 Minutiae coordinate system 

The relative position of minutiae entered in Type-9 records shall be expressed as positive 

integers in units of 0.01 mm (0.00039 in) in a Cartesian coordinate system located in Quadrant 1. 

In this coordinate system, values of X increase from left to right and values of Y increase from 

bottom to top. 

Note (Informative) – This standard follows the practice of placing the origin at the lower left-corner 

for describing the location of minutiae. This is in contrast to the placement of the origin in the 

upper left-hand corner which is conventionally used for images. 

For encoded minutiae from fingerprints, values for both X and Y are equal to or greater than 

"0000" and are less than "5000". This range of units converts to 5 cm (1.97”) in both the 

horizontal and vertical directions. If the conversion to this coordinate system is from a system 

that normally centers the fingerprint image during the registration process, that center position 

shall be assigned the values X = 2500, Y = 2500. Figure 3 illustrates the defined coordinate 

system for a fingerprint using the block of fields for the “standard format”. 

For encoded minutiae from a palmprint, values of both X and Y are equal to or greater than 

"0000" and are less than "14000" and “21000” respectively. This range of units converts to 14 cm 

(5.51”) in the horizontal and 21 cm (8.27”) in the vertical directions. 

The relative orientation, Theta, of a ridge ending or a bifurcation shall be expressed as positive 

integers in units of degrees from “0” to “359”. Theta is defined as the angle between the 

horizontal axis of the coordinate system and the direction that a ridge ending points, assuming 

that a ridge ending is analogous to a pointing finger. A ridge ending that is formed by a ridge 

lying parallel to the X axis, and ending in the direction of increasing values of X, shall have an 

orientation of zero degrees. Counterclockwise rotation of this ridge about the ridge ending shall 

cause the value of Theta to increase. A ridge ending pointing due east has a direction of zero 

degrees, due north 90 degrees and so forth. No orientation value shall be assigned to an 

undetermined or compound type of minutiae; therefore, a value of "000" shall be entered for 

Theta in the Type-9 logical record entry. 

A bifurcation may be converted to a ridge ending by logical inversion, i.e., transposing the identity 

of ridges and valleys. The orientation of a bifurcation is expressed as if this inversion had 

occurred. This convention causes no significant change in the orientation of a minutia if it 

appears as a ridge ending in one impression of a fingerprint and as a bifurcation in another 

impression of the same fingerprint. 
Part 1 ANSI/NIST-ITL 1-2007

39

Theta = 45 units

Y = 2500 units 

0 X-coordinate 5000

X = 2500 units

Minutia Data 

5000 

Theta

Units: 

X, Y, = 0.01mm 

Theta = 1° / unit 

Y-coordinate 

Figure 3 Minutiae coordinate system 

The exact features or characteristics of a minutia that are used to establish its position and 

orientation are system dependent and outside the scope of this standard. 

14.2 Fields for Type-9 logical record (Standard Format) 

All fields of the Type-9 records shall be recorded as ASCII text. No binary fields are permissible 

in this tagged-field record. The first twelve ASCII fields of the Type-9 logical record provide a 

common or generic manner of encoding minutiae and other characteristic data. These fields are 

formatted in accordance with the conventions described above. 

Although this logical record type can also be used to accommodate a variety of methods used by 

different AFIS vendors for encoding minutiae data according to their particular requirements, each 

vendor implementation must contain the first four fields described below. None of the fields from 

Field-5 through Field-12 described below are required to be present in specific vendor 

implementations. 

14.2.1 Field 9.001: Logical record length (LEN) 

This mandatory ASCII field shall contain the length of the logical record specifying the total 

number of bytes, including every character of every field contained in the record. 

14.2.2 Field 9.002: Image designation character (IDC) 

This mandatory field shall be used for the identification and location of the minutiae data. The 

IDC contained in this field shall match the IDC found in the file content (CNT) field of the Type-1 

record. 
Part 1 ANSI/NIST-ITL 1-2007

40

14.2.3 Field 9.003: Impression type (IMP) 

This mandatory one- or two-byte ASCII field shall describe the manner by which the fingerprint or 

palmprint image information was obtained. The ASCII value for the proper code as selected from 

Table 11 for finger impressions and palm impressions shall be entered in this field to signify the 

impression type. 

14.2.4 Field 9.004: Minutiae format (FMT) 

This mandatory one-byte field shall be used to indicate whether the information in the remainder 

of the record adheres to the standard format or is a user-defined format. This field shall contain 

an "S" to indicate that the minutiae are formatted as specified by the standard Type-9 logical 

record field descriptions using location information and other conventions described above. A 

standard Type-9 logical record will use Field-5 through Field-12 as described below. 

This field shall contain a "U" to indicate that the minutiae are formatted in vendor-specific or M1-

378 terms. More than one vendor representation of the same set of minutiae from one view of 

one finger could be present in a single Type 9 record when this field contains a “U”. Multiple 

blocks of vendor-specific data, which may include Field-5 through Field-12, can occur within a 

single Type-9 record when this field contains a “U”. Even though information may be encoded in 

accordance with a specific vendor’s implementation, all data fields of the Type-9 record must 

remain as ASCII text fields. 

14.2.5 Field 9.005: Originating fingerprint reading system (OFR) 

This optional field shall contain three information items relating to the originating fingerprint 

reading system. The originator's designation or name for the particular fingerprint or palmprint 

reading system that generated this record shall be placed in the first information item. The 

second information item of this field shall be a single character to indicate the method by which 

the minutiae data was read, encoded, and recorded. The following coding shall be used: (1) "A", 

if the data was automatically read, encoded, and recorded without any possibility of human 

editing; (2) "U", if human editing was possible but unneeded; (3) "E", if the data was automatically 

read but manually edited before encoding and recording; (4) "M", if the data was manually read. 

The third information item is an optional, two-character, user-generated subsystem designator 

that uniquely identifies the originator's equipment. 

14.2.6 Field 9.006: Finger position (FGP) 

This mandatory field shall contain the code designating the finger or palm position that produced 

information in this Type-9 record. If the exact finger or palm position cannot be determined, 

multiple finger positions may be entered, separated by the “RS” character. Table 12 and Table 

35 list the codes that shall be used for each fingerprint or palmprint position. 

14.2.7 Field 9.007: Fingerprint pattern classification (FPC) 

This field is mandatory when the minutiae are derived from a fingerprint image. It shall contain 

the fingerprint pattern classification code. If the minutiae are derived from a palmprint, this field 

shall not be present. The field shall contain two information items. The first information item shall 

indicate the source of the specific pattern classification code. The source may be Table 16 or a 

user-defined classification code. This item shall contain a "T" to indicate that the pattern 

classification code is from Table 16 or a "U" to indicate that the code is user-defined. The second 

information item of this field shall contain the pattern classification code chosen from Table 16 or 

a specific user-defined code. When it is not possible to uniquely identify the fingerprint class, 

reference fingerprint classes may be used and shall be separated by the “RS” character. 
Part 1 ANSI/NIST-ITL 1-2007

41

Table 16 Pattern classification 

Description Code 

Plain arch PA 

Tented arch TA 

Radial loop RL 

Ulnar loop UL 

Plain whorl PW 

Central pocket loop CP 

Double loop DL 

Accidental whorl AW 

Whorl, type not designated WN 

Right slant loop RS 

Left slant loop LS 

Scar SR 

Amputation XX 

Unknown or unclassifiable UN 

14.2.8 Field 9.008: Core position (CRP) 

If this eight-character field is used, it shall contain the X and Y coordinate position of the core of a 

fingerprint. The X and Y values shall be coded as a single 8-digit integer number comprised of 

the 4-digit X-coordinate concatenated with the 4-digit Y-coordinate using a format of XXXXYYYY. 

The “RS” separator shall separate multiple occurrences of core positions. 

14.2.9 Field 9.009: Delta(s) position (DLT) 

If this eight-character field is used, it shall contain the X and Y positional coordinates of each 

delta that is present on the fingerprint. The X and Y values shall be recorded in the same manner 

as was done for the core position coordinates. The “RS” separator shall separate multiple 

occurrences of delta positions. 

14.2.10 Field 9.010: Number of minutiae (MIN) 

This mandatory textual field shall contain the count of the number of minutiae recorded for this 

fingerprint or palmprint. 

14.2.11 Field 9.011: Minutiae ridge count indicator (RDG) 

This mandatory single-character field shall be used to indicate the presence of minutiae ridge 

count information. A "0" in this field indicates that no ridge count information is available. A "1" 

indicates that ridge count information is available. 
Part 1 ANSI/NIST-ITL 1-2007

42

14.2.12 Field 9.012: Minutiae and ridge count data (MRC) 

This mandatory variable-length field shall contain all of the individual minutiae and ridge count 

data associated with the current fingerprint or palmprint impression. It shall be comprised of as 

many subfields as there are minutiae stated in the minutiae count in Field 9.010. Each subfield 

shall be devoted to a single minutia and shall consist of multiple information items. The first two 

information items shall always appear; the appearance of others is system dependent. The 

information items are identified in the order that they shall appear. All information items shall be 

separated from the subsequent items by the “US” separator character. 

14.2.12.1 Index number 

The first information item shall be the index number, which shall be initialized to "1" and 

incremented by “1” for each additional minutia in the fingerprint. This index number serves to 

identify each individual minutia. 

14.2.12.2 X, Y, and theta values 

For minutiae encoded from fingerprints, the X and Y coordinates (two 4-digit values ranging from 

zero upward), and the Theta value (a 3-digit value between 000 and 359) shall comprise the 

second required information item. These three values shall be coded and recorded as a single 

11-digit integer number corresponding to the concatenated X, Y, and Theta values, in that order. 

For minutiae encoded from palmprints, the X and Y coordinates (two 5-digit values ranging from 

zero upward), and the three-digit Theta value shall comprise the second required information 

item. These three values shall be coded and recorded as a single 13-digit integer number 

corresponding to the concatenated X, Y, and Theta values, in that order. 

14.2.12.3 Quality measure 

If present, the third information item is an optional quality measure. Values shall range from "0" 

to "63". The value "0" shall indicate a manually encoded minutia. The value "1" shall indicate 

that no method of indicating a confidence level is available. Values between "2" and "63" shall 

indicate decreasing levels of confidence, with "2" meaning the greatest confidence. If the quality 

measure information item is not available for this minutia but the type and/or ridge count data is 

present, then a “US” information separator character must be included. 

14.2.12.4 Minutia type designation 

The fourth information item is an optional minutia type designation. This shall be a single 

alphabetic character as chosen from Table 15. If the minutia type information is not available for 

this minutia but ridge count data is present, then a “US” information separator character must be 

included. 

14.2.12.5 Ridge count data 

The fifth information item is optional ridge count data. It shall be formatted as a series of 

information items, each consisting of a minutia number and a ridge count. This information shall 

be conveyed by listing the identity (index number) of the distant minutia followed by a comma, 

and the ridge count to that distant minutia. The “US” character shall be used to separate these 

information items. These information items shall be repeated as many times as required for each 

minutia (subfield). 
Part 1 ANSI/NIST-ITL 1-2007

43

14.2.12.6 Record separator 

A Record Separator character, “RS”, shall be used at the end of the information items to 

introduce the first information item concerning data for the next minutia. The process shall be 

continued until all of the minutiae and ridge data have been entered into the field. 

14.3 End of Type-9 logical record 

Immediately following the last information field in the Type-9 logical record, an “FS” separator 

shall be used to separate it from the next logical record or signify the end of the transaction. This 

separator character must be included in the length field of the Type-9 record. 

14.4 Additional minutiae records 

Typically, up to nine more fingers may be described within the file. Alternatively, up to 7 more 

additional palm records may be described within the file. For each additional finger or palm, a 

Type-9 logical record and an “FS” separator is required. 

15 Type-10 facial & SMT image record 

Type-10 records shall contain facial and/or SMT image data and related ASCII information 

pertaining to the specific image contained in this record. It shall be used to exchange both 

grayscale and color image data in a compressed or uncompressed form. Annex F includes an 

example of the Type-10 facial image record. 

15.1 Fields for Type-10 logical record 

Table 17 lists each of the mandatory and optional fields present in a Type-10 logical record. The 

following paragraphs describe the data contained in each of the fields for the Type-10 logical 

record. 

Within a Type-10 logical record, entries shall be provided in numbered fields. It is required that 

the first two fields of the record are ordered, and the field containing the image data shall be the 

last physical field in the record. For each field of the Type-10 record, Table 17 lists the “condition 

code” as being mandatory “M” or optional “O”, the field number, the field name, character type, 

field size, and occurrence limits. Based on a three digit field number, the maximum byte count 

size for the field is given in the last column. As more digits are used for the field number, the 

maximum byte count will also increase. The two entries in the “field size per occurrence” include 

all character separators used in the field. The “maximum byte count” includes the field number, 

the information, and all the character separators. Fields containing entries in the “IMG” column 

are only applicable to that image type. An entry of “FAC” applies to a mugshot or facial image, 

and an entry of "SMT" applies to scar, a mark, or a tattoo image. 

15.1.1 Field 10.001: Logical record length (LEN) 

This mandatory ASCII field shall contain the total count of the number of bytes in the Type-10 

logical record. Field 10.001 shall specify the length of the record including every character of 

every field contained in the record and the information separators. 
Part 1 ANSI/NIST-ITL 1-2007

44

Table 17 Type-10 facial and SMT record layout 

Field size per 

occurrence 

Ident Cond Occur count 

code 

Field 

Number 

Field Name IMG Char 

type 

min max min max 

Max byte 

count 

LEN M 10.001 LOGICAL RECORD LENGTH N 4 8 1 1 15 

IDC M 10.002 IMAGE DESIGNATION 

CHARACTER 

 N 2 5 1 1 12 

IMT M 10.003 IMAGE TYPE A 5 7 1 1 14 

SRC M 10.004 SOURCE AGENCY / ORI AN 10 36 1 1 43 

PHD M 10.005 PHOTO DATE N 9 9 1 1 16 

HLL M 10.006 HORIZONTAL LINE LENGTH N 4 5 1 1 12 

VLL M 10.007 VERTICAL LINE LENGTH N 4 5 1 1 12 

SLC M 10.008 SCALE UNITS N 2 2 1 1 9 

HPS M 10.009 HORIZONTAL PIXEL SCALE N 2 5 1 1 12 

VPS M 10.010 VERTICAL PIXEL SCALE N 2 5 1 1 12 

CGA M 10.011 COMPRESSION ALGORITHM AN 4 6 1 1 14 

CSP M 10.012 COLOR SPACE A 4 5 1 1 12 

SAP M 10.013 SUBJECT ACQUISITION PROFILE FAC N 2 4 1 1 11 

RSV - 10.014 - 

10.015 

RESERVED FOR FUTURE 

DEFINITION 

 -- -- -- -- -- -- 

SHPS O 10.016 SCAN HOR PIXEL SCALE N 2 5 0 1 12 

SVPS O 10.017 SCAN VERT PIXEL SCALE N 2 5 0 1 12 

RSV - 10.018 - 

10.019 

RESERVED FOR FUTURE 

DEFINITION 

 -- -- -- -- -- -- 

POS O 10.020 SUBJECT POSE FAC A 2 2 0 1 9 

POA O 10.021 POSE OFFSET ANGLE FAC N 2 5 0 1 12 

PXS O 10.022 PHOTO DESCRIPTION FAC A 4 21 0 9 196 

PAS O 10.023 PHOTO ACQUISITION SOURCE FAC A 7 15 0 1 22 

SQS O 10.024 SUBJECT QUALITY SCORE FAC N 10 35 0 9 322 

SPA O 10.025 SUBJECT POSE ANGLES FAC N 9 23 0 1 30 

SXS O 10.026 SUBJECT FACIAL DESCRIPTION FAC A 6 21 0 50 1057 

SEC O 10.027 SUBJECT EYE COLOR FAC A 4 4 0 1 11 

SHC O 10.028 SUBJECT HAIR COLOR FAC A 4 8 0 2 15 

SFP O 10.029 FACIAL FEATURE POINTS FAC N 10 18 0 88 1591 

DMM O 10.030 DEVICE MONITORING MODE FAC A 8 11 0 1 18 

RSV - 10.031 - 

10.039 

RESERVED FOR FUTURE 

DEFINITION 

 -- -- -- -- -- --- 
Part 1 ANSI/NIST-ITL 1-2007

45

Field size per 

occurrence 

Ident Cond Occur count 

code 

Field 

Number 

Field Name IMG Char 

type 

min max min max 

Max byte 

count 

SMT M 10.040 NCIC DESIGNATION CODE SMT A 4 11 1 3 40 

SMS O 10.041 SCAR/MARK/TATTOO SIZE SMT N 4 6 0 1 13 

SMD O 10.042 SMT DESCRIPTORS SMT AN 16 51 0 9 466 

COL O 10.043 COLORS PRESENT SMT A 4 21 0 9 196 

RSV - 10.044 - 

10.199 

RESERVED FOR FUTURE 

DEFINITION 

 -- -- -- -- -- --- 

UDF O 10.200 - 

10.998 

USER-DEFINED FIELDS -- -- -- -- -- --- 

DATA M 10.999 IMAGE DATA B 2 (6*HLL* 

VLL)+1 

1 1 (6*HLL*VLL)+8

Key for character type: N = Numeric; A = Alphabetic; AN = Alphanumeric; B = Binary 

15.1.2 Field 10.002: Image designation character (IDC) 

This mandatory ASCII field shall be used to identify the facial or SMT image data contained in the 

record. This IDC shall match the IDC found in the file content (CNT) field of the Type-1 record. 

15.1.3 Field 10.003: Image type (IMT) 

This mandatory ASCII field is used to indicate the type of image contained in this record. It shall 

contain "FACE", "SCAR", "MARK", or "TATTOO" to indicate the appropriate image type. 

15.1.4 Field 10.004: Source agency / ORI (SRC) 

This mandatory ASCII field shall contain the identification of the administration or organization 

that originally captured the latent image contained in the record. Normally, the Originating 

Agency Identifier, ORI, of the agency that captured the image will be contained in this field. The 

SRC may contain up to 36 identifying characters and the data content of this field shall be defined 

by the user and be in accordance with the receiving agency. 

15.1.5 Field 10.005: Photo date (PHD) 

This mandatory ASCII field shall contain the date that the facial or SMT image contained in the 

record was captured. The date shall appear as eight digits in the format YYYYMMDD. The YYYY

characters shall represent the year the image was captured; the MM characters shall be the tens 

and units values of the month; and the DD characters shall be the tens and units values of the 

day in the month. For example, 20040229 represents February 29, 2004. The complete date 

must be a legitimate date. 

15.1.6 Field 10.006: Horizontal line length (HLL) 

This mandatory ASCII field shall contain the number of pixels contained on a single horizontal line 

of the transmitted image. 
Part 1 ANSI/NIST-ITL 1-2007

46

15.1.7 Field 10.007: Vertical line length (VLL) 

This mandatory ASCII field shall contain the number of horizontal lines contained in the 

transmitted image. 

15.1.8 Field 10.008: Scale units (SLC) 

This mandatory ASCII field shall specify the units used to describe the image sampling frequency 

(pixel density). A "1" in this field indicates pixels per inch, or a "2" indicates pixels per centimeter. 

A "0" in this field indicates no scale is given. For this case, the quotient of HPS/VPS gives the 

pixel aspect ratio. 

15.1.9 Field 10.009: Horizontal pixel scale (HPS) 

This mandatory ASCII field shall specify the integer pixel density used in the horizontal direction 

of the transmitted image providing the SLC contains a "1" or a "2". Otherwise, it indicates the 

horizontal component of the pixel aspect ratio. 

15.1.10 Field 10.010: Vertical pixel scale (VPS) 

This mandatory ASCII field shall specify the integer pixel density used in the vertical direction of 

the transmitted image providing the SLC contains a "1" or a "2". Otherwise, it indicates the 

vertical component of the pixel aspect ratio. 

15.1.11 Field 10.011: Compression algorithm (CGA) 

This mandatory ASCII field shall contain an entry from Table 1 (other than WSQ) to specify the 

algorithm used for compressing the color or grayscale image. An entry of "NONE" in this field 

indicates that the data contained in this record is uncompressed. The image shall be represented 

as an array of n rows by m columns by at least 8-bit pixels. Each pixel in a monochrome image 

shall be represented by eight or more bits. Color images shall be represented as a series of 

sequential samples of a red, green, and blue intensity for each pixel. The image shall be 

organized in row-major order, with the lowest address corresponding to the upper left corner of 

the image. For those images that are to be compressed, the method for the compression of facial 

and SMT images is specified by the baseline mode of the JPEG, JPEG 2000, or PNG algorithms. 

15.1.12 Field 10.012: Color space (CSP) 

This mandatory ASCII field shall contain an entry from Table 3 to identify the color space used to 

exchange the image data. If the color space for an RGB image cannot be determined, an entry of 

"RGB" shall be entered in field 10.012. 

For JPEG-compressed color image files (stored using the JFIF file format), the preferred 

(external) color space is sRGB and an entry of “SRGB” shall be used for Field 10.012. For all 

grayscale (monochrome) images, an entry of "GRAY" shall be used for Field 10.012. 

For JPEG 2000 images stored using the JP2 file format, the available enumerated color spaces 

are sRGB, sYCC, and grayscale, to be entered, respectively, as “SRGB”, “SYCC”, and “GRAY” in 

Field 10.012. The preferred (external) color space for color images is sRGB. If a photo 

acquisition device uses another ICC13 color profile, the acquisition system must convert the image 

 

13 International Color Consortium (ICC), http://www.color.org/ 
Part 1 ANSI/NIST-ITL 1-2007

47

data to one of these enumerated color spaces before the JP2 file may be embedded in a Type 10 

record. 

For uncompressed color images containing non-interleaved red, green, and blue pixels in that 

order, the preferred color space is sRGB and an entry of “SRGB” shall be used for Field 10.012. 

Note that the field codes do not determine if the image data is JPEG, JPEG 2000, or 

uncompressed color images. Field 10.011 will need to be examined to make that determination. 

15.1.13 Field 10.013: Subject Acquisition Profile (SAP) 

The Subject Acquisition Profile (SAP) is a mandatory ASCII text field when field 10.003 contains 

"FACE”. The intent of this field is to provide a general description of the criteria under which the 

facial image was captured. This field shall contain an ASCII character code selected from Table 

18 to indicate the numeric value of the acquisition profile and conditions used to acquire the 

image. Typically, the higher the value, the stronger the acquisition requirements become. 

Therefore, in the text below, the SAP value will also be denoted as a “level”. 

Together with Table 18 is a brief description of each of the levels. Note that levels 10 to 15 

denote transactions associated with image acquisition under the guidance of other facial 

standards or application profiles. Levels 30 to 51 reference best practice recommendations 

consisting of increasingly more stringent requirements that must be satisfied. Additional details 

and criteria for these levels are contained in Annex H and Annex I. 

Table 18 Subject acquisition profiles 

Subject Acquisition Profile Attribute Level Code 

Unknown profile 0 

Surveillance facial image 1 

Driver’s license image (AAMVA) 10 

ANSI Full Frontal facial image (ANSI 385) 11 

ANSI Token facial image (ANSI 385) 12 

ISO Full Frontal facial image (ISO/IEC 19794-5) 13 

ISO Token facial image (ISO/IEC 19794-5) 14 

PIV facial image (NIST SP 800-76) 15 

Legacy Mugshot 20 

Best Practice Application - Level 30 30 

Best Practice Application - Level 40 40 

Best Practice Application - Level 50 50 

Best Practice Application - Level 51 51 
Part 1 ANSI/NIST-ITL 1-2007

48

15.1.13.1 Level 0 (Unknown profile) 

This level denotes any case when the Subject Acquisition Profile is unknown. This value can be 

used to alert systems that the profile of the face image needs to be determined manually or via 

advanced face image quality evaluation techniques. 

 Level 1 (Surveillance facial image) 

This SAP denotes a surveillance facial image: a face image captured without specific regard to 

scene, photographic, or digital requirements. For example, an image of a face from commonly 

available surveillance video equipment is generally considered a surveillance facial image. 

Typically surveillance facial images are of relatively poor quality compared to mugshots, including 

significant pose angle used for the frontal view, poor image resolution, poor image contrast, etc. 

15.1.13.2 Levels 10-15 (Other application profiles) 

Levels 10-15 shall denote transaction associated with capture under the guidance of other facial 

standards or application profiles as defined below. 

• Level 10 denotes a driver license facial portrait described in the AAMVA International 

Specification – DL/ID Card Design 

• Level 11 denotes an ANSI facial image which meets requirements of the Full Frontal Image 

type defined in ANSI INCITS 385-2004 

• Level 12 denotes an ANSI facial image which meets requirements of the Token Face Image 

type defined in ANSI INCITS 385-2004 

• Level 13 denotes an ISO facial image that meets the requirements of the Full Frontal Image 

defined in International standard ISO/IEC 19794-5 

• Level 14 denotes an ISO facial image that meets the requirements of the Token Face Image 

type defined in International standard ISO/IEC 19794-5 

• Level 15 denotes a PIV facial image which meets requirements of Biometric Data 

Specification for Personal Identity Verification. 

 

Note that the facial images of Levels 13 and 14 may come from travel documents as described in 

“Deployment of Machine Readable Travel Documents’’, ICAO Technical Report, version 2.0 . 

15.1.13.3 Level 20 (Legacy facial mugshot) 

A transaction conforming to this application profile level shall be a mugshot formatted according 

to ANSI/NIST-ITL 2000, but not necessarily or known to be conforming to the best practice 

requirements given in profile 30 below. The subject pose(s) can be Frontal, Profile, or Angled. 

15.1.13.4 Best Practice Application Level 30 

A transaction conforming to a level 30 application profile shall include at least one mugshot 

record conforming to all best practice requirements (BPR) in Annex H. These mugshots shall 

adhere to strict background, lighting, and resolution requirements. In particular, the background 

is 18% gray, the lighting is three-point, and the image size is at least 480x600 pixels with an 

aspect ratio of 1:1.25. 
Part 1 ANSI/NIST-ITL 1-2007

49

15.1.13.5 Best Practice Application Level 40 

A facial image conforming to the level 40 application profile can be captured with an off-the-shelf 

1 megapixel camera. Annex I contains detailed information for the capture of level 40, 50, and 51 

facial images. Requirements for conformance with level 40 facial image capture include the 

following: 

• Conformance to the minimum requirements for the capture of level 30 facial images 

• At least one frontal face image shall be captured which conforms to the “face image capture 

requirements” 

• The minimum number of pixels in the electronic digital image shall be 768 pixels in the 

horizontal direction by 1024 pixels in the vertical direction and 

• Facial images shall conform to the “head and shoulders” composition detailed requirements. 

It should be noted that the image quality of the captured facial images will be improved as the 

number of pixels in both directions are increased. However, as images are captured with an 

increased number of pixels, the 3:4 (Width:Height) aspect ratio shall be maintained. 

15.1.13.6 Best Practice Application Level 50 and Level 51 

A transaction conforming to the level 50 and level 51 application profiles shall include “face image 

capture requirements” as described in Annex I. These profile levels are intended to allow for 

examination of up to forensic-level (10 ppmm) detail on a subject’s face. The only difference 

between levels 50 and 51 is that level 50 specifies the “head and shoulders” composition 

requirements while level 51 specifies the “head only” composition requirements. 

Identification applications require approximately 1700 pixels wide by 2515 pixels high on the face 

for the 99th percentile male in the U.S. population. Allocating 50% of the image width for the 

head requires approximately 3400 pixels for a “head and shoulders photo” image width. For a 

level 50 image capture profile, the minimum number of pixels in the electronic digital image shall 

be 3300 pixels in the horizontal direction by 4400 pixels in the vertical direction. Off-the-shelf 15 

(or more) megapixel digital cameras satisfy this requirement. 

As an alternative, allocating 70% of the image width for the head requires approximately 2400 

pixels for the “head only” facial capture. For a level 51 image capture profile, the minimum 

number of pixels in the electronic digital image shall be 2400 pixels in the horizontal direction by 

3200 pixels in the vertical direction. Off-the-shelf 8 megapixel digital cameras satisfy this 

requirement. 

The level 50 and level 51 SAPs allow for the encoding of very high resolution face images that 

are consistent with the discussion above and with the “face image capture requirements”. It 

should be noted that the image quality of the captured facial images may be improved as the 

number of pixels in both directions are increased. Figure 4 illustrates the improvement in image 

quality from levels 30 to 50/51. However, as images are captured with an increased number of 

pixels, the 3:4 (Width:Height) aspect ratio shall be maintained. 

15.1.14 Field 10.014-015: Reserved for future definition (RSV) 

These fields are reserved for definition and inclusion in future revisions of this standard. None of 

these fields are to be used at this revision level. If any of these fields are present, they are to be 

ignored. 
Part 1 ANSI/NIST-ITL 1-2007

50

 

a. Level 30 b. Level 40 c. Levels 50 and 51 

Figure 4 Examples of resolution for levels 30, 40, & 50/51 

15.1.15 Field 10.016: Scanned horizontal pixel scale (SHPS) 

This optional ASCII field shall specify the horizontal pixel density used for the scanning of the 

image providing the SLC field contains a "1" or a "2". Otherwise, it indicates the horizontal 

component of the pixel aspect ratio. 

15.1.16 Field 10.017: Scanned vertical pixel scale (SVPS) 

This optional ASCII field shall specify the vertical pixel density used for the scanning of the image 

providing the SLC field contains a "1" or a "2". Otherwise, it indicates the vertical component of 

the pixel aspect ratio. 

15.1.17 Field 10.018-019: Reserved for future definition (RSV) 

These fields are reserved for definition and inclusion in future revisions of this standard. None of 

these fields are to be used at this revision level. If any of these fields are present, they are to be 

ignored. 

15.1.18 Field 10.020: Subject pose (POS) 

This optional field is to be used for the exchange of facial image data. When included, this field 

shall contain one ASCII character code selected from Table 19 to describe the pose of the 

subject. For the angled pose entry "A", field 10.021 shall contain the offset angle from the full 

face orientation. For the determined 3D pose entry "D", Field 10.025 shall contain a set of 

determined 3D pose angles (i.e., Yaw, Pitch, and Roll angles) away from the full frontal face 

orientation. Note that the offset angle in Field 10.021 is opposite from the yaw angle in Field 

10.025 as indicated by a minus sign. 
Part 1 ANSI/NIST-ITL 1-2007

51

Table 19 Subject pose 

Pose description Pose code 

Full Face Frontal F 

Right Profile (90 degree) R 

Left Profile (90 degree) L 

Angled Pose A 

Determined 3D Pose D 

15.1.19 Field 10.021: Pose offset angle (POA) 

This field shall only be used for the exchange of facial image data if Field 10.020 (POS) contains 

an "A" to indicate an angled pose of the subject. This field should be omitted for a full face or a 

profile. This ASCII field specifies the pose position of the subject at any possible orientation 

within a circle. Its value shall be to a nearest degree. 

The offset angle shall be measured from the full-face pose position and have a range of values 

from -180 degrees to +180 degrees. A positive angle is used to express the angular offset as the 

subject rotates from a full-face pose to their right (approaching a left profile). A negative angle is 

used to express the angular offset as the subject rotates from a full-face pose to their left 

(approaching a right profile). If the entry in the POS field is an "F", "L", or "R", the contents of this 

field are ignored. 

15.1.20 Field 10.022: Photo description (PXS) 

This optional ASCII field, retained for legacy systems, is used for the exchange of facial image 

data. When present, it shall consist of one or more subfields and shall describe special attributes 

of the captured facial image. Attributes associated with the facial image may be selected from 

Table 20 and entered in this field as one or more subfields separated by the "RS" separator 

character between the items. 

Table 20 Photo descriptors 

Facial image attribute Attribute code 

Subject Wearing Glasses GLASSES 

Subject Wearing Hat HAT 

Subject Wearing Scarf SCARF 

Physical Characteristics PHYSICAL 

Other Characteristics OTHER 

Physical characteristics, such as "FRECKLES" may be entered as a subfield consisting of two 

information items. The first is "PHYSICAL" followed by the “US” separator, followed by the 

characteristic as listed in the Ninth (or current) Edition of the NCIC Code Manual, December, 

2000. The "OTHER" category is used to enter unlisted or miscellaneous attributes of the facial 

image. This information shall be entered as a two-information item subfield. The first is "OTHER" 
Part 1 ANSI/NIST-ITL 1-2007

52

followed by the “US” separator, followed by the unformatted text used to describe the attribute. 

Multiple attributes and subfields may be listed but must be separated by the “RS” character. 

Note: The Subject facial description (SXS), field 26, is intended as a replacement for this PXS 

field. Table 20 entries are now duplicated and expanded upon in Table 22. 

15.1.21 Field 10.023: Photo acquisition source (PAS) 

This optional field shall specify the classification of the source of the image contained in this 

record. This field is mandatory if the SAP entry (Field 10.013) is "40" or greater. When included, 

this field shall contain an ASCII character code selected from Table 21 to describe the source of 

captured image data. 

Table 21 Acquisition source type codes 

Acquisition source type attribute Attribute code 

Unspecified or unknown UNSPECIFIED 

Static photograph from an unknown source UNKNOWN PHOTO 

Static photograph from a digital still-image camera DIGITAL CAMERA 

Static photograph from a scanner SCANNER 

Single video frame from an unknown source UNKNOWN VIDEO 

Single video frame from an analogue video camera ANALOGUE VIDEO 

Single video frame from a digital video camera DIGITAL VIDEO 

Vendor Specific source VENDOR 

The "VENDOR" category is used to enter unlisted or miscellaneous source attributes of the facial 

image. This information shall be entered as a two-information item subfield. The first is 

"VENDOR" followed by the “US” separator, followed by the unformatted text used to describe the 

attribute. 

15.1.22 Field 10.024: Subject quality score (SQS) 

This optional ASCII field shall specify quality score data for facial images stored in this record. 

Each subfield shall contain three information items separated by the "US" separator character. 

They identify a quality score and the algorithm used to create the quality score. This information 

is useful to enable the recipient of the quality score to differentiate between quality scores 

generated by different algorithms and adjust for any differences in processing or analysis as 

necessary. 

1. The first 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 

image quality score between 0 and 100 assigned to the image data by a quality algorithm. Higher 

values indicate better quality. An entry of “255” shall indicate a failed attempt to calculate a quality 

score. An entry of “254” shall indicate that no attempt to calculate a quality score was made. The 

use of additional values to convey other information should be harmonized with ISO/IEC 19794 

standards. 
Part 1 ANSI/NIST-ITL 1-2007

53

2. The second information item shall specify the ID of the vendor of the quality algorithm 

used to calculate the quality score. This 4-digit hex value is assigned by IBIA and expressed as 

four ASCII characters. The IBIA shall maintain the Vendor Registry of CBEFF Biometric 

Organizations that will map the value in this field to a registered organization. 

3. The third information item shall specify a numeric product code assigned by the vendor of 

the quality algorithm, which may be registered with the IBIA, but it is not required to be registered. 

It indicates which of the vendor’s algorithms was used in the calculation of the quality score. This 

field contains the ASCII representation of the integer product code and should be within the range 

1 to 65,535. 

15.1.23 Field 10.025: Subject pose angles (SPA) 

This optional ASCII field shall be present when Field 10.020 (POS) contains a "D" to indicate a 

set of determined 3D pose angles of the same subject. If the entry in the POS Field is an "F", "L", 

or "R", the contents of this field are ignored. When present, this information shall be entered as 

three or six information items. 

The first is the Yaw angle (rotation about the vertical 'y' axis) followed by the “US” separator, 

followed by the Pitch angle (rotation about 'x' horizontal axis), followed by the “US” separator, 

followed by the Roll angle (rotation about the 'z' axis). The fourth, fifth and sixth information items 

denote the uncertainty degrees for the Yaw, Pitch, and Roll angles respectively. If the second 

triple of angles is not present, then the uncertainty in the angles is not determined, but the 

additional three “US” separators shall still be included. 

The first three items specify the pose of the subject estimated or measured at constrained 

possible orientations within a sphere. Each angle value shall be to the nearest integer degree. 

If both field 10.021 and this field are present, the Yaw angle of this field shall supersede the offset 

angle contained in Field 10.021. Note that the Yaw angle of this field has the opposite sign of the 

offset angle contained in Field 10.021. Annex J contains, additional information, details, and 

examples of the subject pose angles. 

15.1.24 Field 10.026: Subject facial description (SXS) 

This optional ASCII field shall be used for the exchange of facial image data. This field is 

mandatory if the SAP entry (Field 10.013) is "40" or greater. When present, it shall describe the 

facial expression of the subject and other attributes associated with the subject's captured facial 

image. This field may have one or more subfields each containing a single information item. 

Attributes associated with the facial image may be selected from Table 22 and entered in this 

field. For "Physical Characteristic", enter a characteristic as listed in the Ninth(or current) Edition 

of the NCIC Code Manual, December, 2000. For the "Other Characteristic" enter unlisted or 

miscellaneous attributes as unformatted text used to describe the attribute. Multiple attributes 

may be listed but must be separated by the “RS” character. 

15.1.25 Field 10.027: Subject eye color (SEC) 

This optional ASCII field shall be used for the exchange of facial image data. This field is 

mandatory if the SAP entry (Field 10.013) is "40" or greater. When present, it shall describe the 

eye color of the subject as seen in the photograph. If unusual or unnatural such as may be the 

case when colored contact lenses are present and the “real” eye color cannot be ascertained, 

then the color should be labeled as “XXX”. Eye color attributes and attribute codes are given by 

Table 23. 
Part 1 ANSI/NIST-ITL 1-2007

54

Table 22 Subject facial description codes 

Facial description attribute Attribute code 

Expression unspecified UNKNOWN 

Neutral (non-smiling) with both eyes open and 

mouth closed) 

NEUTRAL 

Smiling where the inside of the mouth and/or teeth 

is not exposed (closed jaw). 

SMILE 

Subject Having Mouth open MOUTH OPEN 

Having Teeth visible TEETH VISIBLE 

Raising eyebrows RAISED BROWS 

Frowning FROWNING 

Looking away from the camera EYES AWAY 

Squinting SQUINTING 

Subject Wearing Left Eye Patch LEFT EYE PATCH 

Subject Wearing Right Eye Patch RIGHT EYE PATCH 

Subject Wearing Clear Glasses CLEAR GLASSES 

Subject Wearing Dark or Visible Colored Glasses 

(medical) 

DARK GLASSES 

Head covering/hat HAT 

Wearing Scarf SCARF 

Having Moustache MOUSTACHE 

Having Beard BEARD 

Ear(s) obscured by hair NO EAR 

Blinking (either or both eyes closed) BLINK 

Having Distorting Medical Condition impacting 

Feature Point detection 

DISTORTING CONDITION 

Physical Characteristics <From NCIC Code Manual> 

Other Characteristics <Unformatted Text> 

Note: This field is intended to replace the photo description field (PXS) and to 

enhance the content with additional descriptive information. As such, photo 

descriptors found in Table 20 also appear in Table 22. 

15.1.26 Field 10.028: Subject hair color (SHC) 

This optional ASCII field shall be used for the exchange of facial image data. This field is 

mandatory if the SAP entry (Field 10.013) is "40" or greater. When present, it shall contain an 

entry form Table 24 that describes the hair color of the subject as seen in the photograph. For 

unusual or unnatural colors not listed in the table, or the "real" color cannot be ascertained, the 

hair color should be labeled as “XXX”. 
Part 1 ANSI/NIST-ITL 1-2007

55

If the subject is completely bald, or has a completely shaved head, then the hair color shall be 

labeled as “BAL”. When the subject is predominantly bald, but hair color is discernable, then the 

appropriate hair color attribute code shall follow “BAL” (separated by the “RS” character). 

Table 23 Eye color codes 

Eye color attribute Attribute code 

Black BLK 

Blue BLU 

Brown BRO 

Gray GRY 

Green GRN 

Hazel HAZ 

Maroon MAR 

Multicolored MUL 

Pink PNK 

Unknown XXX 

Table 24 Hair color codes 

Hair color attribute Attribute code 

Unspecified or unknown XXX 

Bald BAL 

Black BLK 

Blonde or Strawberry BLN 

Brown BRO 

Gray or Partially Gray GRY 

Red or Auburn RED 

Sandy SDY 

White WHI 

Blue BLU 

Green GRN 

Orange ONG 

Pink PNK 

Purple PLE 
Part 1 ANSI/NIST-ITL 1-2007

56

15.1.27 Field 10.029: Facial feature points (FFP) 

The optional ASCII field shall be used for the exchange of facial image data. When present, it 

shall describe special attributes of manually or automatically detected facial feature points of the 

captured facial image. This information shall be entered as a four-information item feature point 

block as described in Table 25. The first information item is feature point type. For this version of 

the standard the only allowable value is "1" which is followed by the “US” separator character. 

The second is feature point code, followed by the “US” separator character. The third is the X

coordinate of a feature point, followed by the “US” separator character. The fourth and final item 

is the Y coordinate of a feature point in the facial image. Multiple facial points may be listed using 

these four information items. But each feature block must be separated by the “RS” separator 

character. The maximum number of feature points shall be 88, with the use of 84 MPEG4 feature 

points and 4 additional eye and nostril center feature points. 

Table 25 Subject feature point field 

Feature points shall be included in the record format if they have been accurately determined, 

thereby providing the option that that these parameters do not have to be re-determined when the 

image is processed for face recognition tasks. 

Typically a computer algorithm will either accurately determine the position of the feature point or 

completely fail and provide either clearly erroneous or no landmark information. Therefore, a 

method for accurate determination is the use of computer-automated feature point determination 

followed by human verification and potential override of the computer determined feature points. 

15.1.27.1 MPEG4 Feature points 

The feature point code item shall specify the feature point that is stored in the feature point block. 

The codes for the feature points are taken from the MPEG4 standard and defined as MPEG4 

feature points. Each feature point code is represented by a notation A.B using a major (A) and a 

minor (B) value. The encoding of the feature point code is given by the numeric ASCII 

representation of the value of A.B. The period is required, and the maximum size of this entry 

shall be 5 characters. 

Item Size Value Notes 

Feature Point Type 1 character 1 Denotes a 2D Feature 

Point. 

 All other values are 

reserved. 

Feature Point Code 3-5 characters A.B in ASCII text 

A and B are described in 

15.1.27.1. 

The maximum value of A is 

12 and of B is 15. 

X coordinate 1-4 characters Horizontal pixel count from 

upper left pixel. 

Count starts at 0. 

Y coordinate 1-4 characters Vertical pixel count from 

upper left pixel. 

Count starts at 0. 
Part 1 ANSI/NIST-ITL 1-2007

57

Figure 5 denotes the feature point codes associated with feature points as given by Annex C of 

ISO/IEC 14496-2. Each code is given by major value A and minor value B. For example, the 

code for the left corner of the left eye is given by major value 3 and minor value 7. 

15.1.27.2 Eye and nostril centre Feature Points 

The eye center feature points 12.1 (left) and 12.2 (right) are defined to be the horizontal and 

vertical midpoints of the eye corners (3.7, 3.11) and (3.8, 3.12) respectively. The left nostril center 

feature point 12.3 is defined to be the midpoint of the nose feature points (9.1, 9.15) in the 

horizontal direction and (9.3, 9.15) in the vertical direction. Similarly, the right nostril center 

feature point 12.4 is defined to be the midpoint of the nose feature points (9.2, 9.15) in the 

horizontal direction and (9.3, 9.15) in the vertical direction. Both the eye center and nostril center 

Feature points are shown in Figure 6 and values given in Table 26. 

Table 26 Eye and nostril center feature point codes 

Center Feature Point Midpoint of Feature Points Feature Point code 

Left Eye 3.7, 3.11 12.1 

Right Eye 3.8, 3.12 12.2 

Left Nostril Horizontal Vertical 

9.1, 9.15 9.3,9.15 

12.3 

Right Nostril Horizontal Vertical 

9.2, 9.15 9.3,9.15 

12.4 

An example transaction for representing two feature points of eye centers is 

“10.029:1US12.2US120US130 RS1US12.1US240US129GS”. 

15.1.28 Field 10.030: Device monitoring mode (DMM) 

This optional field provides information describing the level of human monitoring for the image 

capture device. This field will contain an entry from Table 27 to indicate the monitoring mode of 

the biometric sample capture device. 

Table 27 Device monitoring modes 

CONDITION DESCRIPTION 

CONTROLLED Operator physically controls the subject to acquire biometric sample 

ASSISTED Person available to provide assistance to subject submitting the biometric 

OBSERVED Person present to observe operation of the device but provides no assistance 

UNATTENDED No one present to observe or provide assistance 

UNKNOWN No information is known 
Part 1 ANSI/NIST-ITL 1-2007

58

x y

z

11.5

11.4

11.2

10.2

10.4

10.10

10.8

10.6

2.14

7.1

11.6 4.6

4.4

4.2

5.2

5.4

2.10

2.12 2.1

11.1

Tongue

6.2 6.4 6.3

6.1 Mouth

8.1 8.9 8.10 8.5 8.3

8.7

8.2

8.8

8.4

8.6

2.2

2.3

2.6

2.9 2.8

2.5 2.7 2.4

2.1

2.12 2.11

2.14

2.10

2.13

10.6 10.8

10.4

10.2

10.10

5.4

5.2

5.3

5.1

10.1

10.9

10.3

10.5 10.7

4.1 4.3

4.6 4.5

4.4 4.2

11.2 11.1 11.3

11.4

11.5

x

y

z

Nose

9.6 9.7

9.14 9.13

9.12

9.2

9.4 9.15 9.5

9.3

9.1

Teeth

9.10 9.11

9.8

9.9

Feature points affected by FAPs

Other feature points

Right eye Left eye

3.13

3.7

3.9

3.5

3.1

3.3

3.11

3.14

3.10

3.12 3.6

3.4

3.2

3.8

Figure 5 Feature point codes defined in ISO/IEC 14496-2 

15.1.29 Field 10.031-039: Reserved for future definition (RSV) 

These fields are reserved for definition and inclusion in future revisions of this standard. None of 

these fields are to be used at this revision level. If any of these fields are present, they are to be 

ignored. 

15.1.30 Field 10.040: NCIC designation code (SMT) 

This field is mandatory for a Type-10 record containing SMT image data. It is used to identify a 

general location of the captured scar, mark, tattoo, or other characteristic (including piercings) in 
Part 1 ANSI/NIST-ITL 1-2007

59

Figure 6 Eye and nostril center feature points 

an image. The contents of this field will be an entry chosen from the December, 2000 ninth (or 

current) edition of the NCIC Code Manual. The captured image can encompass an area larger 

than that specified by a single NCIC body part code for the particular image type. This situation 

can be accommodated by listing multiple NCIC codes separated by the “RS” separator character. 

In this case the primary code is listed first. 

For the "marks" category, the NCIC manual lists the common locations for needle track marks. 

For other body part locations not listed under the "marks" category, use the body location codes 

listed for scars. 

15.1.31 Field 10.041: SMT size (SMS) 

This optional field shall contain the dimensions of the scar, mark or tattoo. It shall consist of two 

information items. The height shall be the first information item followed by the “US” separator 

character followed by the width. Each dimension shall be entered to the nearest centimeter. 

15.1.32 Field 10.042: SMT descriptors (SMD) 

This optional field is used to describe the content of the SMT image. It shall consist of one or 

more subfields. Each subfield shall contain three or four information items that provide 

progressively detailed information describing the total image or a portion of the image. 

The first information item of each subfield shall identify the source of the image as being a scar, a 

mark, or a tattoo. It shall contain “SCAR” to indicate healed scar tissue that was the result 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 and third information items shall contain 

“OTHER” and “MISC” and the fourth information item shall contain a textual description or other 

information concerning the scar or mark pattern. 

For deliberately applied or drawn images, the first information item will contain "TATTOO" to 

indicate a common tattoo or indelible image resulting from the pricking of the skin with a coloring 

matter; "CHEMICAL" if the image was created by the use of chemicals to burn the image into the 

skin; "BRANDED" if the image was burned into the skin using a branding iron or other form of 

heat; or “CUT” if the image was caused by incision of the skin. 
Part 1 ANSI/NIST-ITL 1-2007

60

The second information item shall be the general class code of tattoo chosen from Table 28. For 

each general class of tattoo, there are several defined subclasses. The third information item of 

the subfield shall be the appropriate subclass code selected from Table 29 a-h which lists the 

various subclasses of tattoos for each of the general classes. 

Table 28 Tattoo classes 

Class description Class code 

Human Forms and Features HUMAN 

Animals and Animal Features ANIMAL 

Plants PLANT 

Flags FLAG 

Objects OBJECT 

Abstractions ABSTRACT 

Insignias & Symbols SYMBOL 

Other Images OTHER 

Table 29 Tattoo subclasses 

Table 29a Human tattoo subclasses 

Subclass Subclass 

code 

Male Face MFACE 

Female Face FFACE 

Abstract Face ABFACE 

Male Body MBODY 

Female Body FBODY 

Abstract Body ABBODY 

Roles (Knight, Witch, man, etc.) ROLES 

Sports Figures (Football Player, 

Skier, etc.) 

SPORT 

Male Body Parts MBPART 

Female Body Parts FBPART 

Abstract Body Parts ABBPART 

Skulls SKULL 

Miscellaneous Human Forms MHUMAN 

Table 29b Animal tattoo subclasses 

Subclass Subclass 

code 

Cats & Cat Heads CAT 

Dogs & Dog Heads DOG 

Other Domestic Animals DOMESTIC 

Vicious Animals (Lions, etc.) VICIOUS 

Horses (Donkeys, Mules, etc.) HORSE 

Other Wild Animals WILD 

Snakes SNAKE 

Dragons DRAGON 

Birds (Cardinal, Hawk, etc.) BIRD 

Spiders, Bugs, and Insects INSECT 

Abstract Animals ABSTRACT 

Animal Parts PARTS 

Miscellaneous Animal Forms MANIMAL 
Part 1 ANSI/NIST-ITL 1-2007

61

Table 29c Plant tattoo subclasses 

Subclass Subclass 

code 

Narcotics NARCOTICS 

Red Flowers REDFL 

Blue Flowers BLUEFL 

Yellow Flowers YELFL 

Drawings of Flowers DRAW 

Rose ROSE 

Tulip TULIP 

Lily LILY 

Miscellaneous Plants, Flowers, 

Vegetables 

MPLANT 

Table 29d Flags tattoo subclasses 

Subclass Subclass code 

American Flag USA 

State Flag STATE 

Nazi Flag NAZI 

Confederate Flag CONFED 

British Flag BRIT 

Miscellaneous Flags MFLAG 

Table 29e Objects tattoo subclasses 

Subclass Subclass 

code 

Fire FIRE 

Weapons(Guns, Arrows, etc.) WEAP 

Airplanes PLANE 

Boats, Ships, & Other Vessels VESSEL 

Trains TRAIN 

Cars, Trucks, and Vehicles VEHICLE 

Mythical (Unicorns, etc.) MYTH 

Sporting Objects (Football, Ski, 

Hurdles, etc.) 

SPORT 

Water & Nature Scenes(Rivers, 

Sky, Trees, etc.) 

NATURE 

Miscellaneous Objects MOBJECTS 

Table 29f Abstract tattoo subclasses 

Subclass Subclass code 

Figure(s) FIGURE 

Sleeve SLEEVE 

Bracelet BRACE 

Anklet ANKLET 

Necklace NECKLC 

Shirt SHIRT 

Body Band BODBND 

Head Band HEDBND 

Miscellaneous Abstract MABSTRACT 
Part 1 ANSI/NIST-ITL 1-2007

62

Table 29g Symbols tattoo subclasses 

Subclass Subclass code 

National Symbols NATION 

Political Symbols POLITIC 

Military Symbols MILITARY 

Fraternal Symbols FRATERNAL 

Professional Symbols PROFESS 

Gang Symbols GANG 

Miscellaneous Symbols MSYMBOLS 

Table 29h Other tattoo subclasses 

Subclass Subclass code 

Wording (Mom, Dad, Mary, 

etc.) 

WORDING 

Freeform Drawings FREEFRM 

Miscellaneous Images MISC 

Table 30 Color codes 

Color description Color code 

Black BLACK 

Brown BROWN 

Gray GRAY 

Blue BLUE 

Green GREEN 

Orange ORANGE 

Purple PURPLE 

Red RED 

Yellow YELLOW 

White WHITE 

Multi-colored MULTI 

Outlined OUTLINE 

The final and optional information item in this subfield shall be an ASCII text string that provides 

additional qualifiers to describe the image or portion of the image. For example, to fully describe 

a tattoo, there may be a class description of "ANIMAL", with a subclass description of "DOG", and 

qualified by "golden retriever with an overbite". The “US” separator character will be used 

between information items. 

An SMT image consisting of several parts or sub-images shall use multiple subfields, separated 

by the “RS” separator, to fully describe the various parts or features found in the total image. The 

first subfield shall describe the most predominant feature or sub-image contained in the SMT 

image. Subsequent subfields shall describe additional portions of the image that are not part of 

the main or central focal point of the image. For example, a tattoo consisting of a man with a 

snake on the arm being followed by a dog may contain three subfields - one describing the man, 

a second describing the snake, and a third describing the dog. 

15.1.33 Field 10.043: Color (COL) 

This optional field shall contain one subfield corresponding to each subfield contained in Field 

10.042. Each subfield shall contain one or more information items that list the color(s) of the 

tattoo or part of the tattoo. For each subfield, the first information item in the subfield shall be the 

predominant color chosen from Table 30. Additional colors for the sub-field shall be entered as 

information items in the subfield separated by the US separator character. 
Part 1 ANSI/NIST-ITL 1-2007

63

15.1.34 Field 10.044-199: Reserved for future definition (RSV) 

These fields are reserved for definition and inclusion in future revisions of this standard. None of 

these fields are to be used at this revision level. If any of these fields are present, they are to be 

ignored. 

15.1.35 Field 10.200-998: User-defined fields (UDF) 

These fields are user-definable fields. Their size and content shall be defined by the user and be 

in accordance with the receiving agency. If present they shall contain ASCII textual information. 

15.1.36 Field 10.999: Image data (DATA) 

This mandatory field shall contain all of the grayscale or color image data from a face, scar, mark, 

tattoo, or other image. It shall always be assigned field number 999 and must be the last physical 

field in the record. The field number designation "10.999:" is followed by the image data in a 

binary representation. 

Each pixel of uncompressed grayscale data shall be quantized to eight bits (256 gray levels) and 

shall occupy a single byte. Uncompressed color image data shall be expressed as 24 or 48 bit 

sRGB pixels. For the 24-bit sRGB, the first byte shall contain the eight bits for the red component 

of the pixel, the second byte shall contain the eight bits for the green component of the pixel, and 

the third byte shall contain the last eight bits for the blue component of the pixel. For the 48-bit 

sRGB pixel, each color component will occupy two bytes. If compression is used, the pixel data 

shall be compressed in accordance with the compression technique specified in the CGA field. If 

the JPEG algorithm is to be used to compress the data, this field shall be encoded using the JFIF 

format specification. 

15.2 End of Type-10 logical record 

For the sake of consistency, immediately following the last byte of data from field 10.999 an “FS” 

separator shall be used to separate it from the next logical record. This separator must be 

included in the length field of the Type-10 record. 

15.3 Additional facial & SMT image records 

Additional Type-10 records may be included in the file. For each additional facial or SMT image, 

a complete Type-10 logical record together with the “FS” separator is required. 

16 Type-11 record reserved for future use 

17 Type-12 record reserved for future use 

18 Type-13 variable-resolution latent image record 

The Type-13 tagged-field logical record shall contain image data acquired from latent fingerprint 

or palmprint images. These images are intended to be transmitted to agencies that will 

automatically extract or provide human intervention and processing to extract the desired feature 

information from the images. Information regarding the scanning resolution used, the image size, 
Part 1 ANSI/NIST-ITL 1-2007

64

and other parameters required to process the image, are recorded as tagged fields within the 

record. 

18.1 Fields for the Type-13 logical record 

The following paragraphs describe the data contained in each of the fields for the Type-13 logical 

record. 

Within a Type-13 logical record, entries shall be provided in numbered fields. It is required that 

the first two fields of the record are ordered, and the field containing the image data shall be the 

last physical field in the record. For each field of the Type-13 record, Table 31 lists the “condition 

code” as being mandatory “M” or optional “O”, the field number, the field name, character type, 

field size, and occurrence limits. Based on a three digit field number, the maximum byte count 

size for the field is given in the last column. As more digits are used for the field number, the 

maximum byte count will also increase. The two entries in the “field size per occurrence” include 

all character separators used in the field. The “maximum byte count” includes the field number, 

the information, and all the character separators including the “GS” character. 

18.1.1 Field 13.001: Logical record length (LEN) 

This mandatory ASCII field shall contain the total count of the number of bytes in the Type-13 

logical record. Field 13.001 shall specify the length of the record including every character of 

every field contained in the record and the information separators. 

18.1.2 Field 13.002: Image designation character (IDC) 

This mandatory ASCII field shall be used to identify the latent image data contained in the record. 

This IDC shall match the IDC found in the file content (CNT) field of the Type-1 record. 

18.1.3 Field 13.003: Impression type (IMP) 

This mandatory one- or two-byte ASCII field shall indicate the manner by which the latent image 

information was obtained. The appropriate latent code choice selected from Table 11 for finger or 

palm shall be entered in this field. 

18.1.4 Field 13.004: Source agency / ORI (SRC) 

This mandatory ASCII field shall contain the identification of the administration or organization 

that originally captured the latent image contained in the record. Normally, the ORI of the agency 

that captured the image will be contained in this field. The SRC may contain up to 36 identifying 

characters and the data content of this field shall be defined by the user and be in accordance 

with the receiving agency. 

18.1.5 Field 13.005: Latent capture date (LCD) 

This mandatory ASCII field shall contain the date that the latent image contained in the record 

was captured. The date shall appear as eight digits in the format YYYYMMDD. The YYYY

characters shall represent the year the image was captured; the MM characters shall be the tens 

and units values of the month; and the DD characters shall be the tens and units values of the 

day in the month. For example, 20040229 represents February 29, 2004. The complete date 

must be a legitimate date. 
Part 1 ANSI/NIST-ITL 1-2007

65

Table 31 Type-13 Variable-resolution latent record layout 

Ident Cond 

code 

Field 

number 

 Field name Char 

type 

Field size per 

occurrence 

Occur count Max byte 

count 

 Min max min Max 

LEN M 13.001 LOGICAL RECORD LENGTH N 4 8 1 1 15 

IDC M 13.002 IMAGE DESIGNATION 

CHARACTER 

N 2 5 1 1 12 

IMP M 13.003 IMPRESSION TYPE N 2 2 1 1 9 

SRC M 13.004 SOURCE AGENCY / ORI AN 10 36 1 1 43 

LCD M 13.005 LATENT CAPTURE DATE N 9 9 1 1 16 

HLL M 13.006 HORIZONTAL LINE LENGTH N 4 5 1 1 12 

VLL M 13.007 VERTICAL LINE LENGTH N 4 5 1 1 12 

SLC M 13.008 SCALE UNITS N 2 2 1 1 9 

HPS M 13.009 HORIZONTAL PIXEL SCALE N 2 5 1 1 12 

VPS M 13.010 VERTICAL PIXEL SCALE N 2 5 1 1 12 

CGA M 13.011 COMPRESSION ALGORITHM AN 4 6 1 1 14 

BPX M 13.012 BITS PER PIXEL N 2 3 1 1 10 

FGP M 13.013 FINGER / PALM POSITION N 2 3 1 6 25 

SPD O 13.014 SEARCH POSITION 

DESCRIPTORS 

A/N 6 7 0 9 82 

PPC O 13.015 PRINT POSITION COORDINATES A/N 15 28 0 12 343 

SHPS O 13.016 SCANNED HORIZONTAL PIXEL 

SCALE 

N 2 5 0 1 12 

SVPS O 13.017 SCANNED VERTICAL PIXEL 

SCALE 

N 2 5 0 1 12 

RSV 13.018 - 

13.019 

RESERVED FOR FUTURE 

DEFINITION 

-- -- -- -- -- -- 

COM O 13.020 COMMENT AN 2 128 0 1 135 

RSV 13.021 - 

13.023 

RESERVED FOR FUTURE 

DEFINITION 

-- -- -- -- -- -- 

LQM O 13.024 LATENT QUALITY METRIC N 12 38 0 4 156 

RSV 13.025 - 

13.199 

RESERVED FOR FUTURE 

DEFINITION 

-- -- -- -- -- -- 

UDF O 13.200 - 

13.998 

USER-DEFINED FIELDS -- -- -- -- -- -- 

DATA M 13.999 IMAGE DATA B 2 -- 1 1 -- 

Key for character type: N = Numeric; A = Alphabetic; AN = Alphanumeric; B = Binary 
Part 1 ANSI/NIST-ITL 1-2007

66

18.1.6 Field 13.006: Horizontal line length (HLL) 

This mandatory ASCII field shall contain the number of pixels contained on a single horizontal line 

of the transmitted image. 

18.1.7 Field 13.007: Vertical line length (VLL) 

This mandatory ASCII field shall contain the number of horizontal lines contained in the 

transmitted image. 

18.1.8 Field 13.008: Scale units (SLC) 

This mandatory ASCII field shall specify the units used to describe the image sampling frequency 

(pixel density). A "1" in this field indicates pixels per inch, or a "2" indicates pixels per centimeter. 

A "0" in this field indicates no scale is given. For this case, the quotient of HPS/VPS gives the 

pixel aspect ratio. 

18.1.9 Field 13.009: Horizontal pixel scale (HPS) 

This mandatory ASCII field shall specify the integer pixel density used in the horizontal direction 

of the transmitted image providing the SLC contains a "1" or a "2". Otherwise, it indicates the 

horizontal component of the pixel aspect ratio. 

18.1.10 Field 13.010: Vertical pixel scale (VPS) 

This mandatory ASCII field shall specify the integer pixel density used in the vertical direction of 

the transmitted image providing the SLC contains a "1" or a "2". Otherwise, it indicates the 

vertical component of the pixel aspect ratio. 

18.1.11 Field 13.011: Compression algorithm (CGA) 

This mandatory ASCII field shall specify the algorithm used to compress the transmitted 

grayscale images. An entry of "NONE" in this field indicates that the data contained in this record 

is uncompressed. For those images that are to be losslessly compressed, this field shall contain 

the code from Table 1 to indicate the compression method used for the latent fingerprint images. 

See Section 5.6.1. for additional information on the usage of JPEG 2000 for the compression of 

fingerprint images. The domain registrar shall maintain a registry of acceptable compression 

techniques and corresponding codes that may be used as they become available. 

18.1.12 Field 13.012: Bits per pixel (BPX) 

This mandatory ASCII field shall contain the number of bits used to represent a pixel. This field 

shall contain an entry of “8” for normal grayscale values of “0” to “255”. Any entry in this field 

greater than “8” shall represent a grayscale pixel with increased precision. 

18.1.13 Field 13.013: Finger / palm position (FGP) 

This mandatory tagged field shall contain one or more possible finger or palm positions that may 

match the latent image. The decimal code number corresponding to the known or most probable 

finger position shall be taken from Table 12 or the most probable palm position from Table 35 and 

entered as a one- or two-character ASCII subfield. Additional finger and/or palm positions may 

be referenced by entering the alternate position codes as subfields separated by the “RS”

separator character. The code "0", for "Unknown Finger", shall be used to reference every finger 

position from one through ten. The code “20”, for “Unknown Palm”, shall be used to reference 
Part 1 ANSI/NIST-ITL 1-2007

67

every listed palmprint position. Code "19" shall be used to reference one or more parts of an EJI 

or tip. 

18.1.14 Field 13.014: Search Position Descriptors (SPD) 

This ASCII field shall be present if and only if the finger position code "19" appears in Field 

13.013. It is used to narrow the search of the latent image in this record against a database. 

This field shall consist of two mandatory information items. The first is the probable decimal 

finger position code (0-10) taken from Table 12. A "0" indicates that all the fingers of a possible 

candidate should be searched. The second information item is the code taken from Table 32 to 

indicate the portion of the EJI or tip image in the database to search. Latent images of full-length 

fingers use codes FV1 through FV4 as defined in Table 32. Figure 7 is an illustration of the Entire 

Joint Image for a middle finger with each of the full finger views and constituent parts identified. 

The EJI code is used for the case where all four finger images are to be considered. For the case 

where the latent is to be compared to proximal, distal, or medial segments of a finger, this 

information item will contain the appropriate finger segment character. Multiple portions of the 

EJI can be listed and separated by the “RS” separator character. 

Table 32 EJI and tip codes 

TYPE OF IMAGE IMAGE CODE 

Entire Joint Image EJI 

Rolled Tip TIP 

Full Finger Rolled Image FV1 

Full Finger Plain Image – left side FV2 

Full Finger Plain Image – center FV3 

Full Finger Plain Image – right side FV4 

Proximal, Distal, or Medial Segments PRX, DST, MED 

NOTE: Fields 13.014 and 13.015 are included to make the standard flexible enough to 

accommodate many different scenarios and applications. These two fields facilitate searching of 

latents formatted within Type-13 records against Type-14 records contained in the various 

database files. The search of a database by a latent can be narrowed with the use of additional 

information such as finger position, finger segment, or full finger view. It is unlikely that an entire 

EJI will ever be left at the scene of a crime. But a latent can be searched against the EJIs in an 

image or features file based on a specific finger segment or full finger view. This can be 

accomplished for a portion of the latent described by the X and Y coordinates. 

18.1.15 Field 13.015: Print Position Coordinates (PPC) 

If finger position code “19” appears in field 13.013, this field contains offsets to the locations for 

the bounding box of the EJI, each of the full finger views, or segments within the EJI. When 

used, this field shall consist of six (6) mandatory information items to describe the type or portion 

of the latent image contained in this record and its location within an entire joint image. The first 

information item is the number of the full finger view with values of "FV1" through "FV4". Values 

of “FV1” to “FV4” specify the bounding coordinates for each full finger view. The second 

information item is used to identify the location of a segment within a full finger view. It will 
Part 1 ANSI/NIST-ITL 1-2007

68

contain the not applicable code “NA” if the image portion refers to a full finger view or to the entire 

joint image locations. It shall contain “PRX”, “DST”, “MED” for a proximal, distal, or medial 

segment. The next four information items are the horizontal and vertical offsets relative to the 

origin positioned in the upper left corner of the image. The horizontal offsets (X) are the pixel 

counts to the right, and the vertical offsets (Y) are the pixel counts down. The location of the 

image portion is defined by the sequence of X coordinates (LEFT, RIGHT) and the Y coordinates 

(TOP, BOTTOM), of its bounding box. For the case of a fingertip, the first information item shall 

be “TIP”, and the second information item shall be “NA”. The next four information items are the 

horizontal and vertical offsets as defined above. The six information items within the field are 

separated by five “US” separators. This information will describe either the location of the entire 

joint image, one full finger view, or segment. Individual full finger or segment definitions may be 

repeated as subfields separated by the “RS” separator. 

Figure 7 Entire joint image 

18.1.16 Field 13.016: Scanned horizontal pixel scale (SHPS) 

This optional ASCII field shall specify the horizontal pixel density used for the scanning of the 

original impression providing the SLC field contains a "1" or a "2". Otherwise, it indicates the 

horizontal component of the pixel aspect ratio. 

18.1.17 Field 13.017: Scanned vertical pixel scale (SVPS) 

This optional ASCII field shall specify the vertical pixel density used for the scanning of the 

original impression providing the SLC field contains a "1" or a "2". Otherwise, it indicates the 

vertical component of the pixel aspect ratio. 

 Distal 

 Medial 

 Proximal 

FV1 FV2 FV3 FV4 
Part 1 ANSI/NIST-ITL 1-2007

69

18.1.18 Field 13.018-019: Reserved for future definition (RSV) 

These fields are reserved for definition and inclusion in future revisions of this standard. None of 

these fields are to be used at this revision level. If any of these fields are present, they are to be 

ignored. 

18.1.19 Field 13.020: Comment (COM) 

This optional field may be used to insert comments or other ASCII text information with the latent 

image data. 

18.1.20 Field 13.021-023: Reserved for future definition (RSV) 

These fields are reserved for definition and inclusion in future revisions of this standard. None of 

these fields are to be used at this revision level. If any of these fields are present, they are to be 

ignored. 

18.1.21 Field 13.024: Latent quality metric (LQM) 

This optional ASCII field is used to specify one or more different metrics of latent image quality 

score data for the image stored in this record. The meaning attributed to this metric must be 

defined and interpreted by the producer of the scoring algorithm or by the person or system used 

to assign the metric to the latent image. The metric may be a predictor of AFIS matcher accuracy 

performance or a different metric to indicate a value associated with the quality of the latent 

image for a particular function. 

This field may contain one or more subfields, each consisting of four information items separated 

by the "US" separator character. The first information item is the code as chosen from Table 12 

or Table 35. 

The other three items identify a quality score and the algorithm used to create the quality score. 

This information is useful to enable the recipient of the quality score to differentiate between 

quality scores generated by different algorithms and adjust for any differences in processing or 

analysis as necessary. 

• 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 image quality score between 0 and 100 assigned to the image data by a quality 

algorithm. Higher values indicate better quality. An entry of “255” shall indicate a failed 

attempt to calculate a quality score. An entry of “254” shall indicate that no attempt to 

calculate a quality score was made. The use of additional values to convey other 

information should be harmonized with ISO/IEC 19794 standards. 

• The third information item shall specify the ID of the vendor of the quality algorithm used 

to calculate the quality score. This 4-digit hex value is assigned by IBIA and expressed 

as four ASCII characters. The IBIA shall maintain the Vendor Registry of CBEFF 

Biometric Organizations that will map the value in this field to a registered organization. 

• The fourth information item shall specify a numeric product code assigned by the vendor 

of the quality algorithm, which may be registered with the IBIA, but registration is not 

required. It indicates which of the vendor’s algorithms was used in the calculation of the 

quality score. This field contains the ASCII representation of the integer product code and 

should be within the range 1 to 65,535. 
Part 1 ANSI/NIST-ITL 1-2007

70

This subfield is repeated for each latent image and quality algorithm used, separated by the “RS” 

character. 

18.1.22 Field 13.025-199: Reserved for future definition (RSV) 

These fields are reserved for definition and inclusion in future revisions of this standard. None of 

these fields are to be used at this revision level. If any of these fields are present, they are to be 

ignored. 

18.1.23 Fields 13.200-998: User-defined fields (UDF) 

These fields are user-definable fields. Their size and content shall be defined by the user and be 

in accordance with the receiving agency. If present they shall contain ASCII textual information. 

18.1.24 Field 13.999: Image data (DATA) 

This mandatory field shall contain all of data from a captured latent image. It shall always be 

assigned field number 999 and must be the last physical field in the record. The field number 

designation "13.999:" is followed by the image data in a binary representation. 

Each pixel of uncompressed grayscale data shall normally be quantized to eight bits (256 gray 

levels) contained in a single byte. If the entry in BPX Field 13.012 is greater than “8”, the number 

of bytes required to represent a pixel will be different. If compression is used, the pixel data shall 

be compressed in accordance with the compression technique specified in the CGA field. 

18.2 End of Type-13 variable-resolution latent image record 

For the sake of consistency, immediately following the last byte of data from field 13.999 an “FS” 

separator shall be used to separate it from the next logical record. This separator must be 

included in the length field of the Type-13 record. 

18.3 Additional variable-resolution latent image records 

Additional Type-13 records may be included in the file. For each additional latent image, a 

complete Type-13 logical record together with the “FS” separator is required. 

19 Type-14 variable-resolution fingerprint image record 

The Type-14 tagged-field logical record shall contain and be used to exchange fingerprint image 

data from a rolled tenprint, an identification flat, or a major case print (also referred to as a 

complete friction ridge exemplar). All fingerprint impressions shall be acquired from a tenprint 

card, a major case print card, or from a live-scan device. Captured images are intended to be 

transmitted to agencies that will automatically extract the desired feature information from the 

images for matching purposes. Textual information regarding the scanning resolution, the image 

size and other parameters or comments required to process the image are recorded as tagged 

fields within the record. 

The Type-14 record is also used to exchange identification flats (simultaneous plain impressions 

captured on a platen) for civil background checks. Rolled images are generally not used for this 

application. Three Type-14 image records are used to contain the flat fingerprint impressions. 

Two of the image records contain the left and right simultaneous four fingers, and the third 

contains the two thumbs. Offsets to the locations of image segments containing the individual 

fingers are included with the image records. Additional fields are defined to contain the NIST 
Part 1 ANSI/NIST-ITL 1-2007

71

Fingerprint Image Quality (NFIQ) metric, alternate image quality metrics, and metrics for 

predicting the correctness of the segmentation. 

19.1 Fields for the Type-14 logical record 

The following paragraphs describe the data contained in each of the fields for the Type-14 logical 

record. 

Within a Type-14 logical record, entries shall be provided in numbered fields as illustrated in 

Table 33. It is required that the first two fields of the record are ordered, and the field containing 

the image data shall be the last physical field in the record. 

For each field of the Type-14 record, Table 33 lists the “condition code” as being mandatory “M” 

or optional “O”, the field number, the field name, character type, field size, and occurrence limits. 

Based on a three digit field number, the maximum byte count size for the field is given in the last 

column. As more digits are used for the field number, the maximum byte count will also increase. 

The two entries in the “field size per occurrence” include all character separators used in the field. 

The “maximum byte count” includes the field number, the information, and all the character 

separators including the “GS” character. 

Table 33 Type-14 Variable-resolution fingerprint record layout 

 Ident Cond 

code 

Field 

number 

 Field name Char 

type 

Field size per 

occurrence 

Occur 

count 

Max byte 

count 

 min Max min Max 

LEN M 14.001 LOGICAL RECORD LENGTH N 4 8 1 1 15 

IDC M 14.002 IMAGE DESIGNATION CHAR. N 2 5 1 1 12 

IMP M 14.003 IMPRESSION TYPE N 2 2 1 1 9 

SRC M 14.004 SOURCE AGENCY / ORI AN 10 36 1 1 43 

FCD M 14.005 FINGERPRINT CAPTURE DATE N 9 9 1 1 16 

HLL M 14.006 HORIZONTAL LINE LENGTH N 4 5 1 1 12 

VLL M 14.007 VERTICAL LINE LENGTH N 4 5 1 1 12 

SLC M 14.008 SCALE UNITS N 2 2 1 1 9 

HPS M 14.009 HORIZONTAL PIXEL SCALE N 2 5 1 1 12 

VPS M 14.010 VERTICAL PIXEL SCALE N 2 5 1 1 12 

CGA M 14.011 COMPRESSION ALGORITHM AN 4 6 1 1 14 

BPX M 14.012 BITS PER PIXEL N 2 3 1 1 10 

FGP M 14.013 FINGER POSITION N 2 3 1 6 25 

PPD O 14.014 PRINT POSITION DESCRIPTORS A/N 6 7 0 1 14 

PPC O 14.015 PRINT POSITION COORDINATES A/N 15 28 0 12 343 

SHPS O 14.016 SCANNED HORIZONTAL PIXEL 

SCALE 

N 2 5 0 1 12 

SVPS O 14.017 SCANNED VERTICAL PIXEL N 2 5 0 1 12 
Part 1 ANSI/NIST-ITL 1-2007

72

 Ident Cond 

code 

Field 

number 

 Field name Char 

type 

Field size per 

occurrence 

Occur 

count 

Max byte 

count 

 min Max min Max 

SCALE 

AMP O 14.018 AMPUTATED OR BANDAGED A 5 6 0 4 31 

RSV 14.019 RESERVED FOR FUTURE 

DEFINITION 

-- -- -- -- -- -- 

COM O 14.020 COMMENT AN 2 128 0 1 135 

SEG O 14.021 FINGERPRINT SEGMENTATION 

POSITION(S) 

N 10 23 0 * * 

NQM O 14.022 NIST QUALITY METRIC N 4 7 0 4 35 

SQM O 14.023 SEGMENTATION QUALITY 

METRIC 

N 16 76 0 * * 

FQM O 14.024 FINGERPRINT QUALITY METRIC N 16 76 0 * * 

ASEG O 14.025 ALTERNATE FINGER SEGMENT 

POSITION(S) 

N 16 -- 0 4 -- 

RSV 14.026 - 

14.029 

RESERVED FOR FUTURE 

DEFINITION 

-- -- -- -- -- -- 

DMM O 14.030 DEVICE MONITORING MODE A 8 11 0 1 18 

RSV 14.031 - 

14.199 

RESERVED FOR FUTURE 

DEFINITION 

-- -- -- -- -- -- 

UDF O 14.200 - 

14.998 

USER-DEFINED FIELDS -- -- -- -- -- -- 

DATA M 14.999 IMAGE DATA B 2 -- 1 1 -- 

Key for character type: N = Numeric; A = Alphabetic; AN = Alphanumeric; B = 

Binary 

19.1.1 Field 14.001: Logical record length (LEN) 

This mandatory ASCII field shall contain the total count of the number of bytes in the Type-14 

logical record. Field 14.001 shall specify the length of the record including every character of 

every field contained in the record and the information separators. 

19.1.2 Field 14.002: Image designation character (IDC) 

This mandatory ASCII field shall be used to identify the fingerprint image data contained in the 

record. This IDC shall match the IDC found in the file content (CNT) field of the Type-1 record. 
Part 1 ANSI/NIST-ITL 1-2007

73

19.1.3 Field 14.003: Impression type (IMP) 

This mandatory one- or two-byte ASCII field shall indicate the manner by which the fingerprint 

image information was obtained. The appropriate code choice selected from Table 11 for finger 

or palm shall be entered in this field. 

19.1.4 Field 14.004: Source agency / ORI (SRC) 

This mandatory ASCII field shall contain the identification of the administration or organization 

that originally captured the fingerprint images contained in the record. Normally, the ORI of the 

agency that captured the image will be contained in this field. The SRC may contain up to 36 

identifying characters and the data content of this field shall be defined by the user and be in 

accordance with the receiving agency. 

19.1.5 Field 14.005: Fingerprint capture date (FCD) 

This mandatory ASCII field (formerly named “Tenprint Capture Date” (TCD)) shall contain the 

date that the fingerprint image contained in the record was captured. The date shall appear as 

eight digits in the format YYYYMMDD. The YYYY characters shall represent the year the image 

was captured; the MM characters shall be the tens and units values of the month; and the DD

characters shall be the tens and units values of the day in the month. For example, 20040229 

represents February 29, 2004. The complete date must be a legitimate date. 

19.1.6 Field 14.006: Horizontal line length (HLL) 

This mandatory ASCII field shall contain the number of pixels contained on a single horizontal line 

of the transmitted image. 

19.1.7 Field 14.007: Vertical line length (VLL) 

This mandatory ASCII field shall contain the number of horizontal lines contained in the 

transmitted image. 

19.1.8 Field 14.008: Scale units (SLC) 

This mandatory ASCII field shall specify the units used to describe the image sampling frequency 

(pixel density). A "1" in this field indicates pixels per inch, or a "2" indicates pixels per centimeter. 

A "0" in this field indicates no scale is given. For this case, the quotient of HPS/VPS gives the 

pixel aspect ratio. 

19.1.9 Field 14.009: Horizontal pixel scale (HPS) 

This mandatory ASCII field shall specify the integer pixel density used in the horizontal direction 

of the transmitted image providing the SLC contains a "1" or a "2". Otherwise, it indicates the 

horizontal component of the pixel aspect ratio. 

19.1.10 Field 14.010: Vertical pixel scale (VPS) 

This mandatory ASCII field shall specify the integer pixel density used in the vertical direction of 

the transmitted image providing the SLC contains a "1" or a "2". Otherwise, it indicates the 

vertical component of the pixel aspect ratio. 
Part 1 ANSI/NIST-ITL 1-2007

74

19.1.11 Field 14.011: Compression algorithm (CGA) 

This mandatory ASCII field shall specify the algorithm used to compress the transmitted 

grayscale images. An entry of "NONE" in this field indicates that the data contained in this record 

is uncompressed. For those images that are to be compressed, this field shall contain the code 

from Table 1 to indicate the compression method used for this record type. The preferred 

methods for the compression of fingerprint images are WSQ for those images scanned or 

transmitted at 500 ppi or JPEG 2000 for those images scanned and transmitted at 1000 ppi. See 

Section 5.6.1. and the Profile for 1000 ppi Fingerprint Compression for additional information on 

the usage of JPEG 2000 for the compression of fingerprint images. The domain registrar 

maintains a registry of acceptable compression techniques and corresponding codes that may be 

used as they become available. 

19.1.12 Field 14.012: Bits per pixel (BPX) 

This mandatory ASCII field shall contain the number of bits used to represent a pixel. This field 

shall contain an entry of “8” for normal grayscale values of “0” to “255”. Any entry in this field 

greater than “8” shall represent a grayscale pixel with increased precision. 

19.1.13 Field 14.013: Finger position (FGP) 

This mandatory tagged field shall contain the finger position that matches the tenprint image. The 

decimal code number corresponding to the known or most probable finger position shall be taken 

from Table 12 and entered as a one- or two-character ASCII subfield. Table 12 also lists the 

maximum image dimensions that can be transmitted for each of the sixteen possible finger 

positions. Additional finger positions may be referenced in the transaction by entering the 

alternate finger positions as subfields separated by the “RS” separator character. The code "0", 

for "Unknown Finger", shall be used to reference every finger position from one through ten. 

Code "19" shall be used to reference one or more parts of an EJI or tip. 

19.1.14 Field 14.014: Print Position Descriptors (PPD) 

This ASCII field shall be present if and only if the finger position code "19" appears in Field 

14.013. This field shall consist of two mandatory information items. The first is the probable 

decimal finger position code (0-10) taken from Table 12. The second information item is the code 

taken from Table 32 to indicate the portion of the EJI or tip image that is stored as a single image 

in the database. There may be up to 17 such images for a single finger. Images of full-length 

fingers use codes FV1 through FV4 as defined in Table 32. Figure 7 is an illustration of the Entire 

Joint Image for a middle finger with each of the full finger views and constituent parts identified. 

19.1.15 Field 14.015: Print Position Coordinates (PPC) 

If finger position code “19” appears in field 14.013, this field contains offsets to the locations for 

the bounding box of the EJI, each of the full finger views, or segments within the EJI. When 

used, this field shall consist of six (6) mandatory information items to describe the type or portion 

of the image and its location within an entire joint image. The first information item is the number 

of the full finger view with values of "FV1" through "FV4". Values of “FV1” to “FV4” specify the 

bounding coordinates for each full finger view. The second information item is used to identify the 

location of a segment within a full finger view. It will contain the not applicable code “NA” if the 

image portion refers to a full finger view or to the entire joint image locations. It shall contain 

“PRX”, “DST”, “MED” for a proximal, distal, or medial segment. The next four information items 

are the horizontal and vertical offsets relative to the origin positioned in the upper left corner of 

the image. The horizontal offsets (X) are the pixel counts to the right, and the vertical offsets (Y) 

are the pixel counts down. The location of the image portion is defined by the sequence of X 

coordinates (LEFT, RIGHT) and the Y coordinates (TOP, BOTTOM), of its bounding box. For the 
Part 1 ANSI/NIST-ITL 1-2007

75

case of a fingertip, the first information item shall be “TIP”, and the second information item shall 

be “NA”. The next four information items are the horizontal and vertical offsets as defined above. 

The six information items within the field are separated by five “US” separators. This information 

will describe either the location of the entire joint image, one full finger view, or segment. 

Individual full finger or segment definitions may be repeated as subfields separated by the “RS” 

separator. 

19.1.16 Field 14.016: Scanned horizontal pixel scale (SHPS) 

This optional ASCII field shall specify the horizontal pixel density used for the scanning of the 

original impression providing the SLC field contains a "1" or a "2". Otherwise, it indicates the 

horizontal component of the pixel aspect ratio. 

19.1.17 Field 14.017: Scanned vertical pixel scale (SVPS) 

This optional ASCII field shall specify the vertical pixel density used for the scanning of the 

original impression providing the SLC field contains a "1" or a "2". Otherwise, it indicates the 

vertical component of the pixel aspect ratio. 

19.1.18 Field 14.018: Amputated or bandaged (AMP) 

This optional ASCII field shall specify if one or more fingers are amputated or bandaged. This 

field shall consist of one subfield for each amputated or missing finger. Each subfield shall 

contain two information items separated by the “US” separator. The first item is the finger 

number between one and ten as chosen from Table 12. The second item is the amputated or 

bandaged code (AMPCD). The following is a list of allowable indicators for the AMPCD: 

Descriptor AMPCD

Amputation XX 

Unable to print (e.g., bandaged) UP 

Multiple finger positions shall be separated by the “RS” separator. This field is to be used 

anytime there are fewer than expected printable fingers in a submission (e.g., less than four in a 

left or right slap or less than two in a two-thumb slap). A partially scarred finger should be 

printed. 

19.1.19 Field 14.019: Reserved for future definition (RSV) 

These fields are reserved for definition and inclusion in future revisions of this standard. None of 

these fields are to be used at this revision level. If any of these fields are present, they are to be 

ignored. 

19.1.20 Field 14.020: Comment (COM) 

This optional ASCII field may be used to insert comments or other ASCII text information with the 

image data. 

19.1.21 Field 14.021: Finger segment position(s) (SEG) 

This optional ASCII field shall contain offsets to the locations of image segments containing the 

individual fingers within the flat images of the four simultaneous fingers from each hand or the two 
Part 1 ANSI/NIST-ITL 1-2007

76

simultaneous thumbs. The offsets are relative to the origin positioned in the upper left corner of 

the image. The horizontal offsets (X) are the pixel counts to the right, and the vertical offsets (Y) 

are the pixel counts down. A finger segment is defined by the FINGER NUMBER, the X 

coordinates (LEFT, RIGHT) and the Y coordinates (TOP, BOTTOM), of its bounding box. The 

five information items within a finger segment definition are separated by the “US” separator. 

Individual finger segment definitions are separated by the “RS” separator. If more than one 

algorithm is used to segment the image, successive sets finger segmentation positions shall be 

formatted as above and immediately follow the previous set. 

19.1.22 Field 14.022: NIST quality metric (NQM) 

This optional ASCII field shall contain the NIST Fingerprint Image Quality (NFIQ) scores for the 

individual finger(s) derived from the slap impressions or individual rolled fingerprints. It consists 

of two information items. The first item is the finger number between one and ten as chosen 

from Table 12. The second item is the quality score which is a quantitative expression of the 

predicted AFIS matcher accuracy performance of the fingerprint image. The scores range from 

"1" for the best quality image, to "5" for the worst quality image. A "254" indicates that no score 

was ever computed while an entry of "255" shall indicate a failed attempt to calculate the image 

quality metric. These two information items are separated by the “US” separator. Individual 

finger quality definitions are separated by the “RS” separator. 

19.1.23 Field 14.023: Segmentation quality metric (SQM) 

This optional ASCII field provides a measure of estimated correctness regarding the accuracy of 

the location of the segmented finger within the right or left four finger or two thumbs slap image. 

For each segmented finger, this field shall contain four information items separated by the "US" 

separator character. The first information item is the finger number between one and ten as 

chosen from Table 12. 

The other three items identify a quality score and the algorithm used to create the quality score. 

This information is useful to enable the recipient of the quality score to differentiate between 

quality scores generated by different algorithms and adjust for any differences in processing or 

analysis as necessary. 

• The second information item shall be a measure of estimated correctness regarding the 

accuracy of the location of the segmented finger. This item contains the ASCII 

representation of the integer image quality score between 0 and 100 assigned to the 

image data by a quality algorithm. Higher values indicate better quality. An entry of 

“255” shall indicate a failed attempt to calculate a quality score. An entry of “254” shall 

indicate that no attempt to calculate a quality score was made. The use of additional 

values to convey other information should be harmonized with ISO/IEC 19794 standards. 

• The third information item shall specify the ID of the vendor of the quality algorithm used 

to calculate the quality score. This 4-digit hex value is assigned by IBIA and expressed 

as four ASCII characters. The IBIA shall maintain the Vendor Registry of CBEFF 

Biometric Organizations that will map the value in this field to a registered organization. 

• The fourth information item shall specify a numeric product code assigned by the vendor 

of the quality algorithm, which may be registered with the IBIA, but registration is not 

required. It indicates which of the vendor’s algorithms was used in the calculation of the 

quality score. This field contains the ASCII representation of the integer product code and 

should be within the range 1 to 65535. 

This subfield is repeated for each segmented finger whose coordinates appear in field 14.021. 

The “RS” character separates each set of four information items. For the case where more than 
Part 1 ANSI/NIST-ITL 1-2007

77

one segmentation algorithm is applied to a multi-finger plain image, the set of segmentation 

information items for each finger shall be ordered corresponding to the entries in field 14.021. 

19.1.24 Field 14.024: Fingerprint quality metric (FQM) 

This optional ASCII field is used to specify one or more different metrics of fingerprint image 

quality score data for the image stored in this record. The meaning attributed to this metric must 

be defined and interpreted by the producer of the scoring algorithm or by the person or system 

used to assign the metric to the fingerprint image. The metric may be a predictor of AFIS 

matcher accuracy performance or a different metric to indicate a value associated with the quality 

of the fingerprint image for a particular function. 

This field may contain one or more subfields, each consisting of four information items items 

separated by the "US" separator character. The first information item is the finger number as 

chosen from Table 12. 

The other three items identify a quality score and the algorithm used to create the quality score. 

This information is useful to enable the recipient of the quality score to differentiate between 

quality scores generated by different algorithms and adjust for any differences in processing or 

analysis as necessary. 

• 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 image quality score between 0 and 100 assigned to the image data by a quality 

algorithm. Higher values indicate better quality. An entry of “255” shall indicate a failed 

attempt to calculate a quality score. An entry of “254” shall indicate that no attempt to 

calculate a quality score was made. The use of additional values to convey other 

information should be harmonized with ISO/IEC 19794 standards. 

• The third information item shall specify the ID of the vendor of the quality algorithm used 

to calculate the quality score. This 4-digit hex value is assigned by IBIA and expressed 

as four ASCII characters. The IBIA shall maintain the Vendor Registry of CBEFF 

Biometric Organizations that will map the value in this field to a registered organization. 

• The fourth information item shall specify a numeric product code assigned by the vendor 

of the quality algorithm, which may be registered with the IBIA, but registration is not 

required. It indicates which of the vendor’s algorithms was used in the calculation of the 

quality score. This field contains the ASCII representation of the integer product code and 

should be within the range 1 to 65535. 

This subfield is repeated for each finger image and quality algorithm used, separated by the “RS” 

character. 

19.1.25 Field 14.025: Alternate Finger segment position(s) (ASEG) 

This optional ASCII field is an alternate approach to describing the locations for each of the image 

segments of the individual fingers within a flat image containing the capture of four simultaneous 

fingers or two simultaneous thumbs. This field uses an n-vertex polygon to encompass each 

finger image segment, where “n” is between 3 and 99. The order of the vertices must be in their 

consecutive order around the perimeter of the polygon, either clockwise or counterclockwise. No 

two vertices may occupy the same location. The polygon side defined by the last subfield and the 

first subfield shall complete the polygon. The polygon must be a simple, plane figure with no 

sides crossing and no interior holes. 
Part 1 ANSI/NIST-ITL 1-2007

78

This field shall consist of one to four subfields. Each subfield shall consist of a finger number 

between 1 and 10, the total number of vertices of the polygon encompassing the finger, and the 

set of consecutive vertices. Each vertex shall be represented as horizontal and vertical pixel 

offsets relative to the origin positioned in the upper left corner of the image. The horizontal 

offsets (X) are the pixel counts to the right, and the vertical offsets (Y) are the pixel counts down 

from the origin. A minimum of three points is required to describe a finger location. A "US" 

character shall be used to separate the finger number, the number of vertices, each X coordinate, 

and each Y coordinate. Subfields representing each finger are delimited by the "RS" separator 

character. 

19.1.26 Field 14.026-029: Reserved for future definition (RSV) 

These fields are reserved for definition and inclusion in future revisions of this standard. None of 

these fields are to be used at this revision level. If any of these fields are present, they are to be 

ignored. 

19.1.27 Field 14.030: Device monitoring mode (DMM) 

This optional field provides information describing the level of human monitoring for the image 

capture device. This field will contain an entry from Table 27 to indicate the monitoring mode of 

the biometric sample capture device. 

19.1.28 Field 14.031-199: Reserved for future definition (RSV) 

These fields are reserved for definition and inclusion in future revisions of this standard. None of 

these fields are to be used at this revision level. If any of these fields are present, they are to be 

ignored. 

19.1.29 Fields 14.200-998: User-defined fields (UDF) 

These fields are user-definable fields. Their size and content shall be defined by the user and be 

in accordance with the receiving agency. If present they shall contain ASCII textual information. 

19.1.30 Field 14.999: Image data (DATA) 

This mandatory field shall contain all of the data from a captured tenprint image. It shall always 

be assigned field number 999 and must be the last physical field in the record. The field number 

designation "14.999:" is followed by the image data in a binary representation. 

Each pixel of uncompressed grayscale data shall normally be quantized to eight bits (256 gray 

levels) contained in a single byte. If the entry in BPX Field 14.012 is greater than “8”, the number 

of bytes required to contain a pixel will be different. If compression is used, the pixel data shall be 

compressed in accordance with the compression technique specified in the CGA field. 

19.2 End of Type-14 variable-resolution fingerprint image record 

For the sake of consistency, immediately following the last byte of data from field 14.999 an “FS”

separator shall be used to separate it from the next logical record. This separator must be 

included in the length field of the Type-14 record. 

19.3 Additional variable-resolution fingerprint image records 

Additional Type-14 records may be included in the file. For each additional fingerprint image, a 

complete Type-14 logical record together with the “FS” separator is required. 
Part 1 ANSI/NIST-ITL 1-2007

79

20 Type-15 variable-resolution palmprint image record 

The Type-15 tagged-field logical record shall contain and be used to exchange palmprint image 

data together with fixed and user-defined textual information fields pertinent to the digitized 

image. Information regarding the scanning resolution used, the image size, and other parameters 

or comments required to process the image are recorded as tagged fields within the record. 

Palmprint images transmitted to other agencies will be processed by the recipient agencies to 

extract the desired feature information required for matching purposes. 

The image data shall be acquired directly from a subject using a live-scan device, a palmprint 

card, a major case print card, or other media that contains the subject’s palmprints. 

Any method used to acquire the palmprint images shall be capable of capturing a set of images 

for each hand. This set shall include the writer’s palm as a single scanned image, and the entire 

area of the full palm extending from the wrist bracelet to the tips of the fingers as one or two 

scanned images. If two images are used to represent the full palm, the lower image shall extend 

from the wrist bracelet to the top of the interdigital area (third finger joint) and shall include the 

thenar, and hypothenar areas of the palm. The upper image shall extend from the bottom of the 

interdigital area to the upper tips of the fingers. This provides an adequate amount of overlap 

between the two images. The standard also has provision for encoding the interdigital, thenar, 

and hypothenar areas separately for each palm. By matching the ridge structure and details 

contained in this common area, an examiner can confidently state that both images came from 

the same palm. 

As a palmprint transaction may be used for different purposes, it may contain one or more unique 

image areas recorded from the palm or hand. A complete palmprint record set for one individual 

will normally include the writer’s palm and the full palm image(s) from each hand. Since a 

tagged-field logical image record may contain only one binary field, a single Type-15 record will 

be required for each writer’s palm and one to three Type-15 records for each full palm. 

Therefore, four to eight Type-15 records will be required to represent the subject’s palmprints in a 

normal palmprint transaction. 

20.1 Fields for the Type-15 logical record 

The following paragraphs describe the data contained in each of the fields for the Type-15 logical 

record. 

Within a Type-15 logical record, entries shall be provided in numbered fields as illustrated in 

Table 34. It is required that the first two fields of the record are ordered, and the field containing 

the image data shall be the last physical field in the record. 

For each field of the Type-15 record, Table 34 lists the “condition code” as being mandatory “M” 

or optional “O”, the field number, the field name, character type, field size, and occurrence limits. 

Based on a three digit field number, the maximum byte count size for the field is given in the last 

column. As more digits are used for the field number, the maximum byte count will also increase. 

The two entries in the “field size per occurrence” include all character separators used in the field. 

The “maximum byte count” includes the field number, the information, and all the character 

separators including the “GS” character. 

20.1.1 Field 15.001: Logical record length (LEN) 

This mandatory ASCII field shall contain the total count of the number of bytes in the Type-15 

logical record. Field 15.001 shall specify the length of the record including every character of 

every field contained in the record and the information separators. 
Part 1 ANSI/NIST-ITL 1-2007

80

Table 34 Type-15 Variable-resolution palmprint record layout 

Ident Cond 

code 

Field 

number 

 Field name Char 

type

Field size per 

occurrence 

Occur 

count 

Max byte 

count 

 Min max min max 

LEN M 15.001 LOGICAL RECORD LENGTH N 4 8 1 1 15 

IDC M 15.002 IMAGE DESIGNATION 

CHARACTER 

N 2 5 1 1 12 

IMP M 15.003 IMPRESSION TYPE N 2 2 1 1 9 

SRC M 15.004 SOURCE AGENCY / ORI AN 10 36 1 1 43 

PCD M 15.005 PALMPRINT CAPTURE DATE N 9 9 1 1 16 

HLL M 15.006 HORIZONTAL LINE LENGTH N 4 5 1 1 12 

VLL M 15.007 VERTICAL LINE LENGTH N 4 5 1 1 12 

SLC M 15.008 SCALE UNITS N 2 2 1 1 9 

HPS M 15.009 HORIZONTAL PIXEL SCALE N 2 5 1 1 12 

VPS M 15.010 VERTICAL PIXEL SCALE N 2 5 1 1 12 

CGA M 15.011 COMPRESSION ALGORITHM AN 4 6 1 1 14 

BPX M 15.012 BITS PER PIXEL N 2 3 1 1 10 

PLP M 15.013 PALMPRINT POSITION N 3 3 1 1 10 

RSV 15.014 - 

15.015 

RESERVED FOR FUTURE 

DEFINITION 

-- -- -- -- -- -- 

SHPS O 15.016 SCANNED HORIZONTAL 

PIXEL SCALE 

N 2 5 0 1 12 

SVPS O 15.017 SCANNED VERTICAL PIXEL 

SCALE 

N 2 5 0 1 12 

RSV 15.018 - 

15.019 

RESERVED FOR FUTURE 

DEFINITION 

-- -- -- -- -- -- 

COM O 15.020 COMMENT AN 2 128 0 1 135 

RSV 15.021 - 

15.023 

RESERVED FOR FUTURE 

DEFINITION 

-- -- -- -- -- -- 

PQM O 15.024 PALMPRINT QUALITY METRIC N 13 38 0 4 159 

RSV 15.025 - 

15.029 

RESERVED FOR FUTURE 

DEFINITION 

-- -- -- -- -- -- 

DMM O 15.030 DEVICE MONITORING MODE A 8 11 0 1 18 

RSV 15.031 - 

15.199 

RESERVED FOR FUTURE 

DEFINITION 

-- -- -- -- -- -- 

UDF O 15.200 - 

15.998 

USER-DEFINED FIELDS -- -- -- -- -- -- 

DATA M 15.999 IMAGE DATA B 2 -- 1 1 -- 

Key for character type: N = Numeric; A = Alphabetic; AN = Alphanumeric; B = Binary 
Part 1 ANSI/NIST-ITL 1-2007

81

20.1.2 Field 15.002: Image designation character (IDC) 

This mandatory ASCII field shall be used to identify the palmprint image data contained in the 

record. This IDC shall match the IDC found in the file content (CNT) field of the Type-1 record. 

20.1.3 Field 15.003: Impression type (IMP) 

This mandatory one- or two-byte ASCII field shall indicate the manner by which the palmprint 

image information was obtained. The appropriate code choice selected from Table 11 for palm 

shall be entered in this field. 

20.1.4 Field 15.004: Source agency / ORI (SRC) 

This mandatory ASCII field shall contain the identification of the administration or organization 

that originally captured the palmprint image contained in the record. Normally, the ORI of the 

agency that captured the image will be contained in this field. The SRC may contain up to 36 

identifying characters and the data content of this field shall be defined by the user and be in 

accordance with the receiving agency. 

20.1.5 Field 15.005: Palmprint capture date (PCD) 

This mandatory ASCII field shall contain the date that the palmprint image contained in the record 

was captured. The date shall appear as eight digits in the format YYYYMMDD. The YYYY

characters shall represent the year the image was captured; the MM characters shall be the tens 

and units values of the month; and the DD characters shall be the tens and units values of the 

day in the month. For example, 20040229 represents February 29, 2004. The complete date 

must be a legitimate date. 

20.1.6 Field 15.006: Horizontal line length (HLL) 

This mandatory ASCII field shall contain the number of pixels contained on a single horizontal line 

of the transmitted image. 

20.1.7 Field 15.007: Vertical line length (VLL) 

This mandatory ASCII field shall contain the number of horizontal lines contained in the 

transmitted image. 

20.1.8 Field 15.008: Scale units (SLC) 

This mandatory ASCII field shall specify the units used to describe the image sampling frequency 

(pixel density). A "1" in this field indicates pixels per inch, or a "2" indicates pixels per centimeter. 

A "0" in this field indicates no scale is given. For this case, the quotient of HPS/VPS gives the 

pixel aspect ratio. 

20.1.9 Field 15.009: Horizontal pixel scale (HPS) 

This mandatory ASCII field shall specify the integer pixel density used in the horizontal direction 

of the transmitted image providing the SLC contains a "1" or a "2". Otherwise, it indicates the 

horizontal component of the pixel aspect ratio. 
Part 1 ANSI/NIST-ITL 1-2007

82

20.1.10 Field 15.010: Vertical pixel scale (VPS) 

This mandatory ASCII field shall specify the integer pixel density used in the vertical direction of 

the transmitted image providing the SLC contains a "1" or a "2". Otherwise, it indicates the 

vertical component of the pixel aspect ratio. 

20.1.11 Field 15.011: Compression algorithm (CGA) 

This mandatory ASCII field shall specify the algorithm used to compress the transmitted 

grayscale images. An entry of "NONE" in this field indicates that the data contained in this record 

is uncompressed. For those images that are to be compressed, this field shall contain the code 

from Table 1 to indicate the compression method used for this record type. The preferred 

methods for the compression of palmprint images are WSQ for those images scanned or 

transmitted at 500 ppi or JPEG 2000 for those images scanned and transmitted at 1000 ppi. See 

Section 5.6.1. and the Profile for 1000 ppi Fingerprint Compression for additional information on 

the usage of JPEG 2000 for the compression of fingerprint images. The domain registrar 

maintains a registry of acceptable compression techniques and corresponding codes that may be 

used as they become available. 

20.1.12 Field 15.012: Bits per pixel (BPX) 

This mandatory ASCII field shall contain the number of bits used to represent a pixel. This field 

shall contain an entry of “8” for normal grayscale values of “0” to “255”. Any entry in this field 

greater than “8” shall represent a grayscale pixel with increased precision. 

20.1.13 Field 15.013: Palmprint position (PLP) 

This mandatory tagged field shall contain the palmprint position that matches the palmprint 

image. The decimal code number corresponding to the known or most probable palmprint 

position shall be taken from Table 35 and entered as a two-character ASCII subfield. 

20.1.14 Field 15.014-015: Reserved for future definition (RSV) 

These fields are reserved for definition and inclusion in future revisions of this standard. None of 

these fields are to be used at this revision level. If any of these fields are present, they are to be 

ignored. 

20.1.15 Field 15.016: Scanned horizontal pixel scale (SHPS) 

This optional ASCII field shall specify the horizontal pixel density used for the scanning of the 

original impression providing the SLC field contains a "1" or a "2". Otherwise, it indicates the 

horizontal component of the pixel aspect ratio. 

20.1.16 Field 15.017: Scanned vertical pixel scale (SVPS) 

This optional ASCII field shall specify the vertical pixel density used for the scanning of the 

original impression providing the SLC field contains a "1" or a "2". Otherwise, it indicates the 

vertical component of the pixel aspect ratio. 

20.1.17 Field 15.018-019: Reserved for future definition (RSV) 

These fields are reserved for definition and inclusion in future revisions of this standard. None of 

these fields are to be used at this revision level. If any of these fields are present, they are to be 

ignored. 
Part 1 ANSI/NIST-ITL 1-2007

83

20.1.18 Field 15.020: Comment (COM) 

This optional field may be used to insert comments or other ASCII text information with the 

palmprint image data. 

20.1.19 Field 15.021-023: Reserved for future definition (RSV) 

These fields are reserved for definition and inclusion in future revisions of this standard. None of 

these fields are to be used at this revision level. If any of these fields are present, they are to be 

ignored. 

20.1.20 Field 15.024: Palmprint quality metric (PQM) 

This optional ASCII field is used to specify one or more different metrics of palm image quality 

score data for the image stored in this record. The meaning attributed to this metric must be 

defined and interpreted by the producer of the scoring algorithm or by the person or system used 

to assign the metric to the palm print image. The metric may be a predictor of AFIS matcher 

accuracy performance or a different metric to indicate a value associated with the quality of the 

palm print image for a particular function. 

This field may contain one or more subfields, each consisting of four information items. The first 

information item is the palm code as chosen from Table 35. 

The other three items identify a quality score and the algorithm used to create the quality score. 

This information is useful to enable the recipient of the quality score to differentiate between 

quality scores generated by different algorithms and adjust for any differences in processing or 

analysis as necessary. 

• 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 image quality score between 0 and 100 assigned to the image data by a quality 

algorithm. Higher values indicate better quality. An entry of “255” shall indicate a failed 

attempt to calculate a quality score. An entry of “254” shall indicate that no attempt to 

calculate a quality score was made. The use of additional values to convey other 

information should be harmonized with ISO/IEC 19794 standards. 

• The third information item shall specify the ID of the vendor of the quality algorithm used 

to calculate the quality score. This 4-digit hex value is assigned by IBIA and expressed 

as four ASCII characters. The IBIA shall maintain the Vendor Registry of CBEFF 

Biometric Organizations that will map the value in this field to a registered organization. 

• The fourth information item shall specify a numeric product code assigned by the vendor 

of the quality algorithm, which may be registered with the IBIA, but registration is not 

required. It indicates which of the vendor’s algorithms was used in the calculation of the 

quality score. This field contains the ASCII representation of the integer product code and 

should be within the range 1 to 65535. 

This subfield is repeated for each quality algorithm used, separated by the “RS” character. 

20.1.21 Field 15.025-029: Reserved for future definition (RSV) 

These fields are reserved for definition and inclusion in future revisions of this standard. None of 

these fields are to be used at this revision level. If any of these fields are present, they are to be 

ignored. 
Part 1 ANSI/NIST-ITL 1-2007

84

Table 35 Palm codes and dimensions 

Palm 

Position 

Palm 

code 

Width 

(mm) (in) 

Height 

(mm) (in) 

Unknown Palm 20 139.7 5.5 203.2 8.0 

Right Full Palm 21 139.7 5.5 203.2 8.0 

Right Writer’s Palm 22 44.5 1.8 127.0 5.0 

Left Full Palm 23 139.7 5.5 203.2 8.0 

Left Writer’s Palm 24 44.5 1.8 127.0 5.0 

Right Lower Palm 25 139.7 5.5 139.7 5.5 

Right Upper Palm 26 139.7 5.5 139.7 5.5 

Left Lower Palm 27 139.7 5.5 139.7 5.5 

Left Upper Palm 28 139.7 5.5 139.7 5.5 

Right Other 29 139.7 5.5 203.2 8.0 

Left Other 30 139.7 5.5 203.2 8.0 

Right Interdigital 31 139.7 5.5 76.2 3.0 

Right Thenar 32 76.2 3.0 114.3 4.5 

Right Hypothenar 33 76.2 3.0 114.3 4.5 

Left Interdigital 34 139.7 5.5 76.2 3.0 

Left Thenar 35 76.2 3.0 114.3 4.5 

Left Hypothenar 36 76.2 3.0 114.3 4.5 

20.1.22 Field 15.030: Device monitoring mode (DMM) 

This optional field provides information describing the level of human monitoring for the image 

capture device. This field will contain an entry from Table 27 to indicate the monitoring mode of 

the biometric sample capture device. 

20.1.23 Field 15.031-199: Reserved for future definition (RSV) 

These fields are reserved for definition and inclusion in future revisions of this standard. None of 

these fields are to be used at this revision level. If any of these fields are present, they are to be 

ignored. 

20.1.24 Fields 15.200-998: User-defined fields (UDF) 

These fields are user-definable fields. Their size and content shall be defined by the user and be 

in accordance with the receiving agency. If present they shall contain ASCII textual information. 

20.1.25 Field 15.999: Image data (DATA) 

This mandatory field shall contain all of the data from a captured palmprint image. It shall always 

be assigned field number 999 and must be the last physical field in the record. The field number 

designation "15.999:" is followed by the image data in a binary representation. 

Each pixel of uncompressed grayscale data shall normally be quantized to eight bits (256 gray 

levels) contained in a single byte. If the entry in BPX Field 15.012 is greater than 8, the number 

of bytes required to contain a pixel will be different. If compression is used, the pixel data shall be 

compressed in accordance with the compression technique specified in the CGA field. 
Part 1 ANSI/NIST-ITL 1-2007

85

20.2 End of Type-15 variable-resolution palmprint image record 

For the sake of consistency, immediately following the last byte of data from field 15.999 an “FS”

separator shall be used to separate it from the next logical record. This separator must be 

included in the length field of the Type-15 record. 

20.3 Additional Type-15 variable-resolution palmprint image records 

Additional Type-15 records may be included in the file. For each additional palmprint image, a 

complete Type-15 logical record together with the “FS” separator is required. 

21 Type-16 user-defined testing image record 

The Type-16 tagged-field logical record shall contain and be used to exchange image data 

together with textual information fields pertinent to the digitized image. This logical record type 

allows the standard to provide the ability to exchange images not addressed by other record 

types in the standard. It is intended as the tagged-field user-defined logical record to be used for 

developmental or test purposes. 

The image data contained in the Type-16 logical record may be in a compressed form. With the 

exception of the tagged fields described below, the format, parameters, and types of images to be 

exchanged are undefined by this Standard and shall be agreed upon between the sender and 

recipient. 

21.1 Fields for the Type-16 logical record 

The following paragraphs describe the data contained in each of the fields for the Type-16 logical 

record. 

Within a Type-16 logical record, entries shall be provided in tagged numbered fields as described 

below. The logical record length, and the IDC must be provided as the first two ordered tagged 

fields with the image data contained in the last physical field of the record. Fields describing the 

physical parameters of the image size and resolution are mandatory and must also be provided. 

These fields and the remaining user-defined fields may be unordered. 

For each required field of the Type-16 record, Table 36 lists the “condition code” as being 

mandatory “M” or optional “O”, the field number, the field name, character type, field size, and 

occurrence limits. Based on a three digit field number, the maximum byte count size for the field 

is given in the last column. As more digits are used for the field number, the maximum byte count 

will also increase. The two entries in the “field size per occurrence” include all character 

separators used in the field. The “maximum byte count” includes the field number, the 

information, and all the character separators including the “GS” character. 

21.1.1 Field 16.001: Logical record length (LEN) 

This mandatory ASCII field shall contain the total count of the number of bytes in the Type-16 

logical record. Field 16.001 shall specify the length of the record including every character of 

every field contained in the record and the information separators. 
Part 1 ANSI/NIST-ITL 1-2007

86

Table 36 Type-16 Variable-resolution user-defined testing image record layout 

Ident Cond 

code 

Field 

number 

 Field name Char 

type

Field size per 

occurrence 

Occur 

count 

Max byte 

count 

 Min max Min Max 

LEN M 16.001 LOGICAL RECORD LENGTH N 4 8 1 1 15 

IDC M 16.002 IMAGE DESIGNATION 

CHARACTER 

N 2 5 1 1 12 

UDI M 16.003 USER-DEFINED IMAGE AN 2 36 1 1 43 

SRC M 16.004 SOURCE AGENCY / ORI AN 10 36 1 1 43 

UTD M 16.005 USER-DEFINED TESTING 

DATE 

N 9 9 1 1 16 

HLL M 16.006 HORIZONTAL LINE LENGTH N 4 5 1 1 12 

VLL M 16.007 VERTICAL LINE LENGTH N 4 5 1 1 12 

SLC M 16.008 SCALE UNITS N 2 2 1 1 9 

HPS M 16.009 HORIZONTAL PIXEL SCALE N 2 5 1 1 12 

VPS M 16.010 VERTICAL PIXEL SCALE N 2 5 1 1 12 

CGA M 16.011 COMPRESSION ALGORITHM AN 4 6 1 1 14 

BPX M 16.012 BITS PER PIXEL N 2 3 1 1 10 

CSP O 16.013 COLOR SPACE A 4 5 0 1 12 

RSV 16.014 - 

16.015 

RESERVED FOR FUTURE 

DEFINITION 

-- -- -- -- -- -- 

SHPS O 16.016 SCANNED HORIZONTAL 

PIXEL SCALE 

N 2 5 0 1 12 

SVPS O 16.017 SCANNED VERTICAL PIXEL 

SCALE 

N 2 5 0 1 12 

RSV 16.018 - 

16.019 

RESERVED FOR FUTURE 

DEFINITION 

-- -- -- -- -- -- 

COM O 16.020 COMMENT AN 2 128 0 1 135 

RSV 16.021 - 

16.023 

RESERVED FOR FUTURE 

DEFINITION 

-- -- -- -- -- -- 

UQS O 16.024 USER-DEFINED TESTING 

IMAGE QUALITY SCORE 

ANS 8 35 0 1 42 

RSV 16.025 - 

16.029 

RESERVED FOR FUTURE 

DEFINITION 

-- -- -- -- -- -- 

DMM O 16.030 DEVICE MONITORING MODE A 8 11 0 1 18 

RSV 16.031 - 

16.199 

RESERVED FOR FUTURE 

DEFINITION 

-- -- -- -- -- -- 

UDF O 16.200 - 

16.998 

USER-DEFINED FIELDS -- -- -- -- -- -- 

DATA M 16.999 IMAGE DATA B 2 -- 1 1 -- 

Key for character type: N = Numeric; A = Alphabetic; AN = Alphanumeric; B = 

Binary 
Part 1 ANSI/NIST-ITL 1-2007

87

21.1.2 Field 16.002: Image designation character (IDC) 

This mandatory ASCII field shall be used to identify the user-defined testing image data contained 

in the record. This IDC shall match the IDC found in the file content (CNT) field of the Type-1 

record. 

21.1.3 Fields 16.003: User-defined image (UDI) 

This mandatory field shall contain the type of user-defined image contained in this record. Its 

content shall be defined by the user and be in accordance with the receiving agency. 

21.1.4 Field 16.004: Source agency / ORI (SRC) 

This mandatory ASCII field shall contain the identification of the administration or organization 

that originally captured the user-defined testing image contained in the record. Normally, the ORI 

of the agency that captured the image will be contained in this field. The SRC may contain up to 

36 identifying characters and the data content of this field shall be defined by the user and be in 

accordance with the receiving agency. 

21.1.5 Field 16.005: User-defined testing date (UTD) 

This mandatory ASCII field shall contain the date that the user-defined testing image contained in 

the record was captured. The date shall appear as eight digits in the format YYYYMMDD. The 

YYYY characters shall represent the year the image was captured; the MM characters shall be 

the tens and units values of the month; and the DD characters shall be the tens and units values 

of the day in the month. For example, 20040229 represents February 29, 2004. The complete 

date must be a legitimate date. 

21.1.6 Field 16.006: Horizontal line length (HLL) 

This mandatory ASCII field shall contain the number of pixels contained on a single horizontal line 

of the transmitted image. 

21.1.7 Field 16.007: Vertical line length (VLL) 

This mandatory ASCII field shall contain the number of horizontal lines contained in the 

transmitted image. 

21.1.8 Field 16.008: Scale units (SLC) 

This mandatory ASCII field shall specify the units used to describe the image sampling frequency 

(pixel density). A "1" in this field indicates pixels per inch, or a "2" indicates pixels per centimeter. 

A "0" in this field indicates no scale is given. For this case, the quotient of HPS/VPS gives the 

pixel aspect ratio. 

21.1.9 Field 16.009: Horizontal pixel scale (HPS) 

This mandatory ASCII field shall specify the integer pixel density used in the horizontal direction 

of the transmitted image providing the SLC contains a "1" or a "2". Otherwise, it indicates the 

horizontal component of the pixel aspect ratio. 
Part 1 ANSI/NIST-ITL 1-2007

88

21.1.10 Field 16.010: Vertical pixel scale (VPS) 

This mandatory ASCII field shall specify the integer pixel density used in the vertical direction of 

the transmitted image providing the SLC contains a "1" or a "2". Otherwise, it indicates the 

vertical component of the pixel aspect ratio. 

21.1.11 Field 16.011: Compression algorithm (CGA) 

This mandatory ASCII field shall specify the algorithm used to compress the transmitted images. 

An entry of "NONE" in this field indicates that the data contained in this record is uncompressed. 

For those images that are to be compressed, this field shall contain the code from Table 1 to 

indicate the compression method used for this record type. 

21.1.12 Field 16.012: Bits per pixel (BPX) 

This mandatory ASCII field shall contain the number of bits used to represent a pixel. This field 

shall contain an entry of “8” for normal grayscale values of “0” to “255”. Any entry in this field 

greater than “8” shall represent a grayscale pixel with increased precision. 

21.1.13 Field 16.013: Color space (CSP) 

This optional ASCII field shall contain an entry from Table 3 to identify the color space used to 

exchange the image data. If the color space for an RGB image cannot be determined, an entry of 

"RGB" shall be entered in field 16.013. The description for field 10.012 as described in Section 

15.1.12 contains additional information on the color space field. 

21.1.14 Field 16.014-015: Reserved for future definition (RSV) 

These fields are reserved for definition and inclusion in future revisions of this standard. None of 

these fields are to be used at this revision level. If any of these fields are present, they are to be 

ignored. 

21.1.15 Field 16.016: Scanned horizontal pixel scale (SHPS) 

This optional ASCII field shall specify the horizontal pixel density used for the scanning of the 

original impression providing the SLC field contains a "1" or a "2". Otherwise, it indicates the 

horizontal component of the pixel aspect ratio. 

21.1.16 Field 16.017: Scanned vertical pixel scale (SVPS) 

This optional ASCII field shall specify the vertical pixel density used for the scanning of the 

original impression providing the SLC field contains a "1" or a "2". Otherwise, it indicates the 

vertical component of the pixel aspect ratio. 

21.1.17 Field 16.018-019: Reserved for future definition (RSV) 

These fields are reserved for definition and inclusion in future revisions of this standard. None of 

these fields are to be used at this revision level. If any of these fields are present, they are to be 

ignored. 

21.1.18 Field 16.020: Comment (COM) 

This optional field may be used to insert comments or other ASCII text information with the userdefined testing image data. 
Part 1 ANSI/NIST-ITL 1-2007

89

21.1.19 Field 16.021-023: Reserved for future definition (RSV) 

These fields are reserved for definition and inclusion in future revisions of this standard. None of 

these fields are to be used at this revision level. If any of these fields are present, they are to be 

ignored. 

21.1.20 Field 16.024: User-defined testing image quality score (UQS) 

This optional ASCII field shall specify a quality score data for the user-defined testing image 

stored in this record. Each subfield shall contain three information items separated by the "US" 

separator character. They identify a quality score and the algorithm used to create the quality 

score. This information is useful to enable the recipient of the quality score to differentiate 

between quality scores generated by different algorithms and adjust for any differences in 

processing or analysis as necessary. 

1. The first 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 

image quality score between 0 and 100 assigned to the image data by a quality algorithm. Higher 

values indicate better quality. An entry of “255” shall indicate a failed attempt to calculate a 

quality score. An entry of “254” shall indicate that no attempt to calculate a quality score was 

made. The use of additional values to convey other information should be harmonized with 

ISO/IEC 19794 standards. 

2. The second information item shall specify the ID of the vendor of the quality algorithm 

used to calculate the quality score. This 4-digit hex value is assigned by IBIA and expressed as 

four ASCII characters. The IBIA shall maintain the Vendor Registry of CBEFF Biometric 

Organizations that will map the value in this field to a registered organization. 

3. The third information item shall specify a numeric product code assigned by the vendor of 

the quality algorithm, which may be registered with the IBIA, but registration is not required. It 

indicates which of the vendor’s algorithms was used in the calculation of the quality score. This 

field contains the ASCII representation of the integer product code and should be within the range 

1 to 65535. 

21.1.21 Field 16.025-029: Reserved for future definition (RSV) 

These fields are reserved for definition and inclusion in future revisions of this standard. None of 

these fields are to be used at this revision level. If any of these fields are present, they are to be 

ignored. 

21.1.22 Field 16.030: Device monitoring mode (DMM) 

This optional field provides information describing the human monitoring operation of the image 

capture device. This field will contain an entry from Table 27 to indicate the monitoring mode of 

the biometric sample capture device. 

21.1.23 Field 16.031-199: Reserved for future definition (RSV) 

These fields are reserved for definition and inclusion in future revisions of this standard. None of 

these fields are to be used at this revision level. If any of these fields are present, they are to be 

ignored. 
Part 1 ANSI/NIST-ITL 1-2007

90

21.1.24 Fields 16.200-998: User-defined fields (UDF) 

These fields are user-definable fields. Their size and content shall be defined by the user and be 

in accordance with the receiving agency. If present they shall contain ASCII textual information. 

21.1.25 Field 16.999: Image data (DATA) 

This mandatory field shall contain all of the pixel data from a captured image. It shall always be 

assigned field number 999 and must be the last physical field in the record. For example, 

“16.999:” is followed by image data in a binary representation. 

21.2 End of Type-16 user-defined testing image record 

For the sake of consistency, immediately following the last byte of data from field 16.999 an “FS”

separator shall be used to separate it from the next logical record. This separator must be 

included in the length field of the Type-16 record. 

21.3 Additional Type-16 user-defined testing image records 

Additional Type-16 records may be included in the file. For each additional image, a complete 

Type-16 logical record together with the “FS” separator is required. 

22 Type-17 Iris image record 

22.1 General 

The Type-17 tagged-field logical record shall contain and be used to exchange generic iris image 

data using mandatory fields of this record type. Optional fields may be used to exchange 

additional information available in the INCITS 379-2004 – Iris Image Interchange Format standard 

and the ISO/IEC 19794-6 iris image data interchange format standard. Images may be 

monochrome or color with 256 or more intensity levels (grey or per-color component), and vary in 

size depending on field of view and compression. 

The iris standards specify two alternative image interchange formats for biometric authentication 

systems that utilize iris recognition. The first, which is represented in this record type, is based on 

a rectilinear image storage format that specifies a raw, uncompressed or compressed array of 

intensity values. The second is an image data format based on a polar image specification and is 

not represented in this logical record type. If such a polar representation is required for a specific 

application, a Type-99 CBEFF biometric data record may be used. 

22.2 Fields for the Type-17 logical record 

The following paragraphs describe the data contained in each of the fields for the Type-17 logical 

record. 

Within a Type-17 logical record, entries shall be provided in numbered fields as illustrated in 

Table 37. It is required that the first two fields of the record are ordered, and the field containing 

the iris binary data shall be the last physical field in the record. 

For each field of the Type-17 record, Table 37 lists the “condition code” as being mandatory “M” 

or optional “O”, the field number, the field name, character type, field size, and occurrence limits. 

Based on a three-digit field number, the maximum byte count size for the field is given in the last 

column. As more digits are used for the field number, the maximum byte count will also increase. 
Part 1 ANSI/NIST-ITL 1-2007

91

The two entries in the “field size per occurrence” include all character separators used in the field. 

The “maximum byte count” includes the field number, the information, and all the character 

separators including the “GS” character. 

Table 37 Type-17 Iris image record layout 

Ident Cond 

code 

Field 

number 

 Field name Char 

type

Field size per 

occurrence 

Occur 

count 

Max byte 

count 

 Min max Min Max 

LEN M 17.001 LOGICAL RECORD LENGTH N 4 8 1 1 15 

IDC M 17.002 IMAGE DESIGNATION 

CHARACTER 

N 2 5 1 1 12 

FID M 17.003 FEATURE IDENTIFIER N 2 2 1 1 9 

SRC M 17.004 SOURCE AGENCY/ORI AN 10 36 1 1 43 

ICD M 17.005 IRIS CAPTURE DATE N 9 9 1 1 16 

HLL M 17.006 HORIZONTAL LINE LENGTH N 4 5 1 1 12 

VLL M 17.007 VERTICAL LINE LENGTH N 4 5 1 1 12 

SLC M 17.008 SCALE UNITS N 2 2 1 1 9 

HPS M 17.009 HORIZONTAL PIXEL SCALE N 2 5 1 1 12 

VPS M 17.010 VERTICAL PIXEL SCALE N 2 5 1 1 12 

CGA M 17.011 COMPRESSION ALGORITHM AN 4 6 1 1 14 

BPX M 17.012 BITS PER PIXEL N 2 3 1 1 10 

CSP M 17.013 COLOR SPACE A 4 5 1 1 12 

RAE O 17.014 ROTATION ANGLE OF EYE AN 2 5 0 1 12 

RAU O 17.015 ROTATION UNCERTAINTY AN 2 5 0 1 12 

IPC O 17.016 IMAGE PROPERTY CODE N 6 6 0 1 13 

DUI O 17.017 DEVICE UNIQUE IDENTIFIER ANS 17 17 0 1 24 

GUI O 17.018 GLOBAL UNIQUE IDENTIFIER AN 17 17 0 1 24 

MMS O 17.019 MAKE/MODEL/SERIAL 

NUMBER 

ANS 6 153 0 1 160 

ECL O 17.020 EYE COLOR A 4 4 0 1 11 

COM O 17.021 COMMENT AN 2 128 0 1 135 

SHPS O 17.022 SCANNED HORIZONTAL 

PIXEL SCALE 

N 2 5 0 1 12 

SVPS O 17.023 SCANNED VERTICAL PIXEL 

SCALE 

N 2 5 0 1 12 

IQS O 17.024 IMAGE QUALITY SCORE ANS 8 35 0 1 42 

ALS O 17.025 ACQUISITION LIGHTING 

SPECTRUM 

A 3 3 0 1 10 

IRD O 17.026 IRIS DIAMETER N 1 5 0 1 12 

RSV O 17.027 - 

17.029 

RESERVED FOR FUTURE 

DEFINITION 

-- -- -- -- -- -- 
Part 1 ANSI/NIST-ITL 1-2007

92

Ident Cond 

code 

Field 

number 

 Field name Char 

type

Field size per 

occurrence 

Occur 

count 

Max byte 

count 

 Min max Min Max 

DMM O 17.030 DEVICE MONITORING MODE A 8 11 0 1 18 

RSV O 17.031 - 

17.199 

RESERVED FOR FUTURE 

DEFINITION 

-- -- -- -- -- -- 

UDF O 17.200 - 

17.998 

USER-DEFINED FIELDS -- -- -- -- -- -- 

DATA M 17.999 IRIS IMAGE DATA B 2 -- 1 1 -- 

Key for character type: N = Numeric; A = Alphabetic; AN = Alphanumeric; B = Binary 

22.2.1 Field 17.001: Logical record length (LEN) 

This mandatory ASCII field shall contain the total count of the number of bytes in the Type-17 

logical record. Field 17.001 shall specify the length of the record including every character of 

every field contained in the record and the information separators. 

22.2.2 Field 17.002: Image designation character (IDC) 

This mandatory ASCII field shall be used to identify the iris image data contained in the record. 

This IDC shall match the IDC found in the file content (CNT) field of the Type-1 record. 

22.2.3 Field 17.003: Feature Identifier (FID) 

This mandatory field shall contain an identifier for the eye represented by the image in the record. 

An entry of “0” in this field indicates that the image in this record is undefined. An entry of “1” in 

this field indicates that the image in this record is the subject's right eye. An entry of “2” in this 

field indicates that the image in this record is the subject's left eye. 

22.2.4 Field 17.004: Source agency / ORI (SRC) 

This mandatory ASCII field shall contain the identification of the administration or organization 

that originally captured the iris image contained in the record. Normally, the ORI of the agency 

that captured the image will be contained in this field. The SRC may contain up to 36 identifying 

characters and the data content of this field shall be defined by the user and be in accordance 

with the receiving agency. 

22.2.5 Field 17.005: Iris capture date (ICD) 

This mandatory ASCII field shall contain the date that the iris image contained in the record was 

captured. The date shall appear as eight digits in the format YYYYMMDD. The YYYY characters 

shall represent the year the image was captured; the MM characters shall be the tens and units 

values of the month; and the DD characters shall be the tens and units values of the day in the 

month. For example, 20040229 represents February 29, 2004. The complete date must be a 

legitimate date. 
Part 1 ANSI/NIST-ITL 1-2007

93

22.2.6 Field 17.006: Horizontal line length (HLL) 

This mandatory ASCII field shall contain the number of pixels contained on a single horizontal line 

of the transmitted image. 

22.2.7 Field 17.007: Vertical line length (VLL) 

This mandatory ASCII field shall contain the number of horizontal lines contained in the 

transmitted image. 

22.2.8 Field 17.008: Scale units (SLC) 

This mandatory ASCII field shall specify the units used to describe the image sampling frequency 

(pixel density). A "1" in this field indicates pixels per inch, or a "2" indicates pixels per centimeter. 

A "0" in this field indicates no scale is given. For this case, the quotient of HPS/VPS gives the 

pixel aspect ratio. 

22.2.9 Field 17.009: Horizontal pixel scale (HPS) 

This mandatory ASCII field shall specify the integer pixel density used in the horizontal direction 

of the transmitted image providing the SLC contains a "1" or a "2". Otherwise, it indicates the 

horizontal component of the pixel aspect ratio. 

22.2.10 Field 17.010: Vertical pixel scale (VPS) 

This mandatory ASCII field shall specify the integer pixel density used in the vertical direction of 

the transmitted image providing the SLC contains a "1" or a "2". Otherwise, it indicates the 

vertical component of the pixel aspect ratio. 

22.2.11 Field 17.011 Compression algorithm (CGA) 

This mandatory ASCII field shall specify the algorithm used to compress the color or grayscale 

image. Table 1 contains the codes for the compression methods. An entry of "NONE" in this field 

indicates that the data contained in this record is uncompressed. The image shall be represented 

as an array of n rows by m columns by at least 8-bit pixels. Each pixel in a monochrome image 

shall be represented by eight or more bits. Color images shall be represented as a sequential 

sample of a red, green, and blue intensity for each pixel. The image shall be organized in rowmajor order, with the lowest address corresponding to the upper left corner of the image. 

For those images that are to be compressed, the method for the compression of iris images is 

specified by the baseline mode of the JPEG algorithm or JPEG 2000. For best results, the 

compression ratio should not exceed 6:1. 

22.2.12 Field 17.012: Bits per pixel (BPX) 

This mandatory ASCII field shall contain the number of bits used to represent a pixel. This field 

shall contain an entry of “8” for normal grayscale values of “0” to “255” or each RGB color 

component. Any entry in this field greater than “8” shall represent a grayscale or color pixel 

component with increased precision. 

22.2.13 Field 17.013: Color Space (CSP) 

This mandatory ASCII field shall contain an entry from Table 3 to identify the color space used to 

exchange the image data. If the color space for an RGB image cannot be determined, an entry of 
Part 1 ANSI/NIST-ITL 1-2007

94

"RGB" shall be entered in field 17.013. The description for field 10.012 contains additional 

information on the color space field. 

22.2.14 Field 17.014: Rotation Angle of Eye (RAE) 

This optional field shall indicate the rotation angle of the eye. For rectilinear images, rotation 

angle = round (65536 * angle / 360) modulo 65536. The angle is measured in degrees from 

horizontal to the interpupillary line. The value “FFFF” indicates rotation angle of eye is undefined. 

22.2.15 Field 17.015: Rotation Uncertainty (RAU) 

This optional field shall indicate the rotation uncertainty. The rotation uncertainty is equal to 

[round (65536 * uncertainty / 180)]. The uncertainty is measured in degrees and is the absolute 

value of maximum error. The value “FFFF” indicates uncertainty is undefined. 

22.2.16 Field 17.016: Image Property Code (IPC) 

This optional field shall contain the image property code. It shall contain three information items. 

The first information item shall indicate the specific horizontal orientation. The second information 

item shall indicate the specific vertical orientation. The third information item shall indicate the 

specific scan type. Each information item shall be one character and be separated from the next 

by the “US” separator character. 

• Values for Horizontal Orientation shall be one of: “0” for Undefined, “1” for Base, or “2” for 

Flipped. “Base” orientation refers to images corresponding to the view facing the subject, 

where the nasal side of subject’s left eye or outer edge of the subject’s right eye is on the 

left side the of image. “Flipped” orientation refers to images where the orientation is 

opposite from that described for “Base”. 

• Values for Vertical Orientation shall be one of: “0” for Undefined, “1” for Base, or “2” for 

Flipped. “Base” orientation refers to images where the superior (top) edge of the eye is 

at the top of the image. “Flipped” orientation refers to images where the orientation is 

opposite from that described for “Base”. 

• Values for Scan Type shall be one of: “0” for Undefined, “1” for Progressive, “2” for 

Interlace Frame, or “3” for Interlace Field. “Progressive” indicates that the image was 

captured using progressive scanning, in which case all image lines are generated 

sequentially. “Interlace Frame” indicates that the image was captured using interlaced 

scanning, in which two fields are generated in sequence, the first composed of oddnumbered lines and the second of even-numbered lines. “Interlace Field” indicates that 

the image was captured using interlaced scanning, in which only one field is generated, 

and then each line is duplicated to produce a full size image. 

22.2.17 Field 17.017: Device Unique Identifier (DUI) 

This optional field shall contain a sixteen-byte string uniquely identifying the device or source of 

the data. This data can be one of: (1) Device Serial number, identified by the first character “D”, 

(2) Host PC Mac address, identified by the first character “M”, (3) Host PC processor ID, identified 

by the first character “P”, and (4) No serial number, identified by all zero’s. 

22.2.18 Field 17.018: Global Unique Identifier (GUI) 

This optional field shall contain a 16-byte string to indicate a GUID – a globally unique identifier. 
Part 1 ANSI/NIST-ITL 1-2007

95

22.2.19 Field 17.019: Make/Model/Serial Number (MMS) 

This optional field contains the make, model and serial number for the iris capture device. It shall 

consist of three information items. The make of the iris capture device shall be the first 

information item followed by the “US” separator character, the model of the iris capture device, a 

“US” separator character, and the serial number of the iris capture device. Each information item 

shall be 1 to 50 characters. Any or all information items may indicate that information is unknown 

with the value “0”. 

22.2.20 Field 17.020: Eye Color (ECL) 

This optional field shall specify the subject's eye color. When used, this field shall contain an 

entry chosen from Table 23. 

22.2.21 Field 17.021: Comment (COM) 

This optional field may be used to insert comments or other ASCII text information with the iris 

image data. 

22.2.22 Field 17.022: Scanned horizontal pixel scale (SHPS) 

This optional ASCII field shall specify the horizontal pixel density used for scanning providing the 

SLC field contains a "1" or a "2". Otherwise, it indicates the horizontal component of the pixel 

aspect ratio. 

22.2.23 Field 17.023: Scanned vertical pixel scale (SVPS) 

This optional ASCII field shall specify the vertical pixel density used for scanning providing the 

SLC field contains a "1" or a "2". Otherwise, it indicates the vertical component of the pixel 

aspect ratio. 

22.2.24 Field 17.024: Image Quality Score (IQS) 

This optional ASCII field shall specify a quality score data for the iris image stored in this record. 

Each subfield shall contain three information items separated by the "US" separator character. 

They identify a quality score and the algorithm used to create the quality score. This information 

is useful to enable the recipient of the quality score to differentiate between quality scores 

generated by different algorithms and adjust for any differences in processing or analysis as 

necessary. 

1. The first 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 

image quality score between 0 and 100 assigned to the image data by a quality algorithm. Higher 

values indicate better quality. An entry of “255” shall indicate a failed attempt to calculate a 

quality score. An entry of “254” shall indicate that no attempt to calculate a quality score was 

made. The use of additional values to convey other information should be harmonized with 

ISO/IEC 19794 standards. 

2. The second information item shall specify the ID of the vendor of the quality algorithm 

used to calculate the quality score. This 4-digit hex value is assigned by IBIA and expressed as 

four ASCII characters. The IBIA shall maintain the Vendor Registry of CBEFF Biometric 

Organizations that will map the value in this field to a registered organization. 

3. The third information item shall specify a numeric product code assigned by the vendor of 

the quality algorithm, which may be registered with the IBIA, but registration is not required. It 
Part 1 ANSI/NIST-ITL 1-2007

96

indicates which of the vendor’s algorithms was used in the calculation of the quality score. This 

field contains the ASCII representation of the integer product code and should be within the range 

1 to 65535. This subfield is repeated for each quality algorithm used, separated by the “RS” 

character. 

22.2.25 Field 17.025: Acquisition Lighting Spectrum (ALS) 

This optional field indicates the lighting spectrum used in capturing the iris image. Values shall be 

one of the following: “NIR” for near-infrared illumination (~700-850nm), “VIS” for visible fullspectrum illumination (~380-740nm), or “OTHER” for other illumination. 

22.2.26 Field 17.026: Iris Diameter (IRD) 

This optional field shall specify the expected iris diameter in pixels. 

22.2.27 Field 17.027-029: Reserved for Future Definition (RSV) 

These fields are reserved for definition and inclusion in future revisions of this standard. None of 

these fields are to be used at this revision level. If any of these fields are present, they are to be 

ignored. 

22.2.28 Field 17.030: Device monitoring mode (DMM) 

This optional field provides information describing the human monitoring operation of the image 

capture device. This field will contain an entry from Table 27 to indicate the monitoring mode of 

the biometric sample capture device. 

22.2.29 Field 17.031-199: Reserved for Future Definition (RSV) 

These fields are reserved for definition and inclusion in future revisions of this standard. None of 

these fields are to be used at this revision level. If any of these fields are present, they are to be 

ignored. 

22.2.30 Field 17.200-998: User-Defined Fields (UDF) 

These fields are user-definable fields. Their size and content shall be defined by the user and be 

in accordance with the receiving agency. If present, they shall contain ASCII textual information. 

22.2.31 Field 17.999: Image data (DATA) 

This mandatory field shall contain the iris image. It shall always be assigned field number 999 and 

must be the last physical field in the record. 

22.3 End of Type-17 Iris Data Record 

For the sake of consistency, immediately following the last byte of data from field 17.999 an “FS” 

separator shall be used to separate it from the next logical record. This separator must be 

included in the length field of the Type-17 record. 

22.4 Additional Type-17 Iris Data Records 

Additional Type-17 records may be included in the file. For each additional iris record, a complete 

Type-17 logical record together with the “FS” separator is required. 
Part 1 ANSI/NIST-ITL 1-2007

97

23 Type-99 CBEFF biometric data record 

The Type-99 tagged-field logical record shall contain and be used to exchange biometric data 

that is not supported by other ANSI/NIST-ITL logical records. This data is exchanged in a format 

that conforms to INCITS 398-2005, the Common Biometric Exchange Formats Framework. 

The CBEFF conformant Biometric Information Record (BIR) used by the Type-99 logical record 

includes a common Header and a Biometric Data Block (BDB). Two mandatory fields in the 

CBEFF Header are Format Owner and Format Type. The Format Owner field denotes the 

vendor, standards body, working group, or industry consortium that has defined the format of the 

biometric data (the data contained in the BDB). A CBEFF requirement is that format owners 

register with the IBIA for an assigned identifier of the format owner. The values used in the 

Format Type field are assigned by the format owner and represent a specific BDB format as 

specified by the format owner. This may be a non-standard, unpublished data format or a data 

format that has been standardized by an industry group, consortium, or standards body. It is the 

combined CBEFF Format Owner/Format Type value that uniquely identifies the BDB format. 

The Type-99 logical record provides the CBEFF fields necessary for users to send, receive, and 

interpret biometric data in any registered BDB format (with the exception of biometric data which 

is exchanged using the other logical records in this standard). The data carried in the Biometric 

Data Block field (99.999) is the BDB. The format of that data is identified by the field's BDB 

Format Owner and BDB Format Type as described by the CBEFF standard. 

23.1 Fields for the Type-99 logical record 

The following paragraphs describe the data contained in each of the fields for the Type-99 logical 

record. Within a Type-99 logical record, entries shall be provided in numbered fields. It is 

required that the first two fields of the record are ordered, and the field containing the CBEFF 

formatted binary data shall be the last physical field in the record. For each field of the Type-99 

record, Table 38 lists the “condition code” as being mandatory “M” or optional “O”, the field 

number, the field name, character type, field size, and occurrence limits. Based on a three-digit 

field number, the maximum byte count size for the field is given in the last column. As more digits 

are used for the field number, the maximum byte count will also increase. The two entries in the 

“field size per occurrence” include all character separators used in the field. The “maximum byte 

count” includes the field number, the information, and all the character separators including the 

“GS” character. Annex F provides an example that includes the Type-99 record. 

23.1.1 Field 99.001: Logical Record Length (LEN) 

This mandatory ASCII field shall contain the total count of the number of bytes in the Type-99 

logical record. This field shall specify the length of the record including every character of every 

field contained in the record and the information separators. 

23.1.2 Field 99.002: Image Designation Character (IDC) 

This mandatory ASCII field shall be used to identify the CBEFF data contained in the record. 

This IDC shall match the IDC found in the file content (CNT) field of the Type-1 record. 

23.1.3 Field 99.003: Reserved for Future Definition (RSV) 

This field is reserved for inclusion in future revisions of this standard. It is not to be used at this 

revision level. If a present, it is to be ignored. 
Part 1 ANSI/NIST-ITL 1-2007

98

Table 38 Type-99 CBEFF biometric data record layout 

Ident Cond

Code 

Field 

Number 

Field Name Char

Type 

Field size per 

occurrence 

min max 

Occur count 

min max 

Max byte 

count 

LEN M 99.001 LOGICAL RECORD LENGTH N 4 8 1 1 15 

IDC M 99.002 IMAGE DESIGNATION 

CHARACTER 

N 2 5 1 1 12 

RSV O 99.003 RESERVED FOR FUTURE 

DEFINITION 

-- -- -- -- -- -- 

SRC M 99.004 SOURCE AGENCY / ORI AN 10 36 1 1 43 

BCD M 99.005 BIOMETRIC CREATION 

DATE 

N 16 16 1 1 23 

RSV O 99.006 - 

99.099 

RESERVED FOR FUTURE 

DEFINITION 

-- -- -- -- -- -- 

HDV M 99.100 CBEFF HEADER VERSION N 5 5 1 1 12 

BTY M 99.101 BIOMETRIC TYPE N 9 9 1 1 16 

BDQ O 99.102 BIOMETRIC DATA QUALITY ANS 9 36 0 1 43 

BFO M 99.103 BDB FORMAT OWNER AN 5 5 1 1 12 

BFT M 99.104 BDB FORMAT TYPE AN 5 5 1 1 12 

RSV O 99.105 - 

99.199 

RESERVED FOR FUTURE 

DEFINITION 

-- -- -- -- -- -- 

UDF O 99.200 - 

99.998 

USER-DEFINED FIELDS -- -- -- -- -- -- 

BDB M 99.999 BIOMETRIC DATA BLOCK B 2 -- 1 1 -- 

Key for character type: N = Numeric; A = Alphabetic; AN = Alphanumeric; B = Binary 

23.1.4 Field 99.004: Source agency/ORI (SRC) 

This mandatory ASCII field shall contain the identification of the administration or organization 

that originally captured the biometric sample contained in the record. Normally, the ORI of the 

agency that captured the image will be contained in this field. The SRC may contain up to 36 

identifying characters and the data content of this field shall be defined by the user and be in 

accordance with the receiving agency. 

23.1.5 Field 99.005: Biometric creation date (BCD) 

This mandatory ASCII field shall contain the date and time that the biometric sample was 

captured. The date and time shall appear as fifteen digits in the format YYYYMMDDhhmmssZ. 

The YYYY characters shall represent the year the image was captured; the MM characters shall 

be the tens and units values of the month; the DD characters shall be the tens and units values of 

the day in the month; the hh characters shall be the tens and units values of the hour of the day in 

24-hour format; the mm characters shall be the tens and units values of the minute within the 

hour; the ss characters shall be the tens and units values of the second of the minute; and “Z” 

denotes Coordinated Universal Time, which is abbreviated UTC. For example, December 15, 

2000 at 5 AM, 35 minutes and 30 seconds is expressed as 20001215053530Z. The complete 

date must be a legitimate date. 
Part 1 ANSI/NIST-ITL 1-2007

99

23.1.6 Field 99.006-099: Reserved for Future Definition (RSV) 

These fields are reserved for inclusion in future revisions of this standard. None of these fields 

are to be used at this revision level. If any of these fields are present, they are to be ignored. 

23.1.7 Field 99.100: CBEFF Header Version (HDV) 

This mandatory ASCII field shall be used to identify the version of CBEFF specification that this 

record conforms to. The format is two characters for major version number followed by two 

characters for minor version. The current version of CBEFF is INCITS 398-2005 represented by 

the string ‘0101’ (major version ‘01’ and minor version ‘01’). 

23.1.8 Field 99.101: Biometric Type (BTY) 

This mandatory ASCII field shall be used to identify the type of biometric technology. This 

specification adopts the values presented in CBEFF with the addition of two leading zeros for 

future expansion. Table 39 lists the current biometric type codes. 

Table 39 CBEFF Biometric type 

Biometric Type 

Name 

Biometric Type 

Code 

No Information Given ‘00000000’ 

Multiple Biometrics Used ‘00000001' 

Facial Features ‘00000002' 

Voice ‘00000004' 

Fingerprint ‘00000008' 

Iris ‘00000010' 

Retina ‘00000020' 

Hand Geometry ‘00000040' 

Signature Dynamics ‘00000080' 

Keystroke Dynamics ‘00000100' 

Lip Movement ‘00000200' 

Thermal Face Image ‘00000400' 

Thermal Hand Image ‘00000800' 

Gait ‘00001000' 

Body Odor ‘00002000' 

DNA ‘00004000' 

Ear Shape ‘00008000' 

Finger Geometry ‘00010000' 

Palm Print ‘00020000' 

Vein Pattern ‘00040000' 

Foot Print ‘00080000’ 

23.1.9 Field 99.102: Biometric Data Quality (BDQ) 

This optional ASCII field shall specify a quality score data for the biometric data stored in the BDB 

in this record. Each subfield shall contain three information items separated by the "US" separator 

character. They identify a quality score and the algorithm used to create the quality score. This 
Part 1 ANSI/NIST-ITL 1-2007

100

information is useful to enable the recipient of the quality score to differentiate between quality 

scores generated by different algorithms and adjust for any differences in processing or analysis 

as necessary. 

1. The first 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 

image quality score between 0 and 100 assigned to the image data by a quality algorithm. Higher 

values indicate better quality. An entry of “255” shall indicate a failed attempt to calculate a 

quality score. An entry of “254” shall indicate that no attempt to calculate a quality score was 

made. The use of additional values to convey other information should be harmonized with 

ISO/IEC 19794 standards. 

2. The second information item shall specify the ID of the vendor of the quality algorithm 

used to calculate the quality score. This 4-digit hex value is assigned by IBIA and expressed as 

four ASCII characters. The IBIA shall maintain the Vendor Registry of CBEFF Biometric 

Organizations that will map the value in this field to a registered organization. 

3. The third information item shall specify a numeric product code assigned by the vendor of 

the quality algorithm, which may be registered with the IBIA, but registration is not required. It 

indicates which of the vendor’s algorithms was used in the calculation of the quality score. This 

field contains the ASCII representation of the integer product code and should be within the range 

1 to 65535. 

This subfield is repeated for each quality algorithm used, separated by the “RS” character. 

23.1.10 Field 99.103: BDB Format Owner (BFO) 

This mandatory ASCII field shall be used to denote the vendor, standards body, working group, or 

industry consortium that has defined the format of the biometric data (in the BDB). In a CBEFF 

structure the BDB Format Owner and Format Type, when used in combination, uniquely identify 

the specific format of the BDB content. The format and content of the BDB is “owned” by the 

CBEFF Client (see Clause 6.1 of the CBEFF standard). This BDB format definition may be 

published (public) or unpublished (non-public). 

A CBEFF requirement is that format owners register with IBIA for an assigned identifier of the 

format owner. The number is guaranteed to be unique. Refer to the CBEFF standard, Clause 6, 

“CBEFF Patrons and Clients,”, for registration information. 

The four hex digits assigned by IBIA shall be represented by a string of four ASCII characters. 

23.1.11 Field 99.104: BDB Format Type (BFT) 

This mandatory ASCII field shall be used to identify the value assigned by the format owner to 

represent the specific BDB Format as specified by the format owner. This may be a nonstandard, unpublished data format or a data format that has been standardized by an industry 

group, consortium, or standards body. The registration of the Format Type value is 

recommended but not required. Refer to the CBEFF standard, Clause 6, “CBEFF Patrons and 

Clients,” for registration information. 

The four hex digits assigned by the format owner shall be represented by a string of four ASCII 

characters. 
Part 1 ANSI/NIST-ITL 1-2007

101

23.1.12 Field 99.105-199: Reserved for Future Definition (RSV) 

These fields are reserved for inclusion in future revisions of this standard. None of these fields 

are to be used at this revision level. If any of these fields are present, they are to be ignored. 

23.1.13 Field 99.200-998: User-Defined Fields (UDF) 

These fields are user-definable fields. Their size and content shall be defined by the user and be 

in accordance with the receiving agency. If present, they shall contain ASCII textual information. 

23.1.14 Field 99.999: Biometric Data Block (BDB) 

This mandatory field shall contain the CBEFF Biometric Data Block (BDB). It shall always be 

assigned field number 999 and must be the last physical field in the record. For example, 99.999: 

is followed by a finger pattern BDB in a binary representation. 

23.2 End of Type-99 CBEFF Data Record 

For the sake of consistency, immediately following the last byte of data from field 99.999 an “FS” 

separator shall be used to separate it from the next logical record. This separator must be 

included in the length field of the Type-99 record. 

23.3 Additional Type-99 CBEFF Data Records 

Additional Type-99 records may be included in the file. For each additional CBEFF record, a 

complete Type-99 logical record together with the “FS” separator is required. 

24 Another individual 

If fingerprint or other biometric data for another individual is to be recorded or transmitted, a new 

file shall be generated for that individual using the same format as described previously. 
Part 1 ANSI/NIST-ITL 1-2007

102

Annex A 7-bit American Standard Code for Information Interchange (ASCII) 

(normative) 

B 7 = M S B →

 b 6 →

 b 5 →

0 

0 

0 

0 

0 

1 

0 

1 

0 

0 

1 

1 

1 

0 

0 

1 

0 

1 

1 

1 

0 

1 

1 

1

B 

i 

t 

s 

b 4 

↓

b 3 

↓

b 2 

↓

b 1 

↓

COLUMN 

 →

ROW ↓

0 1 2 3 4 5 6 7 

 0 0 0 0 0 N U L D L E S P 0 @ P  p 

 0 0 0 1 1 S O H D C 1 ! 1 A Q a q 

 0 0 1 0 2 S T X D C 2 " 2 B R b r 

 0 0 1 1 3 E T X D C 3 # 3 C S c s 

 0 1 0 0 4 E O T D C 4 $ 4 D T d t 

 0 1 0 1 5 E N Q N A K % 5 E U e u 

 0 1 1 0 6 A C K S Y N & 6 F V f v 

 0 1 1 1 7 B E L E T B  7 G W g w 

 1 0 0 0 8 B S C A N ( 8 H X h x 

 1 0 0 1 9 H T E M ) 9 I Y i y 

 1 0 1 0 10 L F S U B * : J Z j z 

 1 0 1 1 11 V T E S C + ; K [ K { 

 1 1 0 0 12 F F F S , < L \  | 

 1 1 0 1 13 C R G S - = M ] m } 

 1 1 1 0 14 S O R S . > N ^ n  ̃ 

 1 1 1 1 15 S I U S / ? O _ o D E L 
Part 1 ANSI/NIST-ITL 1-2007

103

Annex B Use of information separator characters 

(informative) 

FN is the number of a field (including record type) within a tagged-field record. 

IF is the information field associated with an FN. 

II is the information item belonging to an IF. 

SF is the subfield used for multiple entries of an II or an IF. 

S

F File separator character – separates logical records. 

G

S Group separator character – separates fields. 

S

R Record separator character – separates repeated subfields. 

S

U Unit separator character – separates information items. 

The G

S is used between fields – the S

F between logical records: 

FNj: IF G

S FNk : ... S

F FN1 : IF G

S ... S

F

For fields with more than one information item, the S

U is used: 

FNj : IIa S

U IIb

G

S FNk ... S

F

For fields with multiple subfields, the S

R is used:

FNj : IIa S

U IIb SR IIa SU IIb 

G

S FNk ... S

F

which can be expressed as:

FNj : SF1 S

R SF2

G

S FNk ... S

F
Part 1 ANSI/NIST-ITL 1-2007

104

Annex C Base-64 encoding scheme 

(normative) 

The base-64 Content-Transfer-Encoding is designed to represent arbitrary sequences of octets in 

a form that need not be humanly readable. The encoding and decoding algorithms are simple, but 

the encoded data are consistently only about 33 percent larger than the unencoded data. This 

encoding is virtually identical to the one used in Privacy Enhanced Mail (PEM) applications, as 

defined in RFC 1421. The base-64 encoding is adapted from RFC 1421, with one change: base64 eliminates the "*" mechanism for embedded clear text. 

A 65-character subset of US-ASCII is used, enabling 6 bits to be represented per printable 

character. (The extra 65th character, "=", is used to signify a special processing function.) 

NOTE: This subset has the important property that it is represented identically in all versions of 

ISO 646, including US ASCII and all characters in the subset are also represented identically in 

all versions of EBCDIC. Other popular encodings, such as the encoding used by the uuencode 

utility and the base-85 encoding specified as part of Level 2 PostScript, do not share these 

properties, and thus do not fulfill the portability requirements a binary transport encoding for mail 

must meet. 

The encoding process represents 24-bit groups of input bits as output strings of 4 encoded 

characters. Proceeding from left to right, concatenating 3 8-bit input groups forms a 24-bit input 

group. These 24 bits are then treated as 4 concatenated 6-bit groups, each of which is translated 

into a single digit in the base-64 alphabet. When encoding a bit stream via the base-64 encoding, 

the bit stream must be presumed to be ordered with the most significant bit first. That is, the first 

bit in the stream will be the high-order bit in the first byte, and the eighth bit will be the low-order 

bit in the first byte, and so on. 

Each 6-bit group is used as an index into an array of 64 printable characters. The character 

referenced by the index is placed in the output string. These characters, identified in Table C1, 

below, are selected so as to be universally representable, and the set excludes characters with 

particular significance to SMTP (e.g., ".", CR, LF) and to the encapsulation boundaries defined in 

this document (e.g., "-"). 

The output stream (encoded bytes) must be represented in lines of no more than 76 characters 

each. All line breaks or other characters not found in Table C1 must be ignored by decoding 

software. In base-64 data, characters other than those in Table C1, line breaks, and other white 

space probably indicate a transmission error, about which a warning message or even a 

message rejection might be appropriate under some circumstances. 
Part 1 ANSI/NIST-ITL 1-2007

105

Table C1 – Base-64 alphabet 

 Value Value Value Value 

Encoding Encoding Encoding Encoding 

 0 A 17 R 34 I 51 z 

 1 B 18 S 35 j 52 0 

 2 C 19 T 36 k 53 1 

 3 D 20 U 37 l 54 2 

 4 E 21 V 38 m 55 3 

 5 F 22 W 39 n 56 4 

 6 G 23 X 40 o 57 5 

 7 H 24 Y 41 p 58 6 

 8 I 25 Z 42 q 59 7 

 9 J 26 a 43 r 60 8 

 10 K 27 b 44 s 61 9 

 11 L 28 c 45 t 62 + 

 12 M 29 d 46 u 63 / 

 13 N 30 e 47 v 

 14 O 31 f 48 w (pad) = 

 15 P 32 g 49 x 

 16 Q 33 h 50 y 

Special processing is performed if fewer than 24 bits are available at the end of the data being 

encoded. A full encoding quantum is always completed at the end of a body. When fewer than 24 

input bits are available in an input group, zero bits are added (on the right) to form an integral 

number of 6-bit groups. Padding at the end of the data is performed using the '=' character. Since 

all base-64 input is an integral number of octets, only the following cases can arise: (1) the final 

quantum of encoding input is an integral multiple of 24 bits; here, the final unit of encoded output 

will be an integral multiple of 4 characters with no "=" padding, (2) the final quantum of encoding 

input is exactly 8 bits; here, the final unit of encoded output will be two characters followed by two 

"=" padding characters, or (3) the final quantum of encoding input is exactly 16 bits; here, the final 

unit of encoded output will be three characters followed by one "=" padding character. 

Because it is used only for padding at the end of the data, the occurrence of any '=' characters 

may be taken as evidence that the end of the data has been reached (without truncation in 

transit). No such assurance is possible, however, when the number of octets transmitted was a 

multiple of three. 

Any characters outside of the base-64 alphabet are to be ignored in base-64-encoded data. The 

same applies to any illegal sequence of characters in the base-64 encoding, such as "=====" 

.Care must be taken to use the proper octets for line breaks if base-64 encoding is applied 

directly to text material that has not been converted to canonical form. In particular, text line 

breaks must be converted into CRLF sequences prior to base-64 encoding. The important thing 

to note is that this may be done directly by the encoder rather than in a prior cannibalization step 

in some implementations. 

NOTE: There is no need to worry about quoting apparent encapsulation boundaries within base64-encoded parts of multipart because no hyphen characters are used in the base-64 encoding. 
Part 1 ANSI/NIST-ITL 1-2007

106

Annex D JPEG file interchange format 

(normative) 

Version 1.02 

September 1, 1992 

1 408 944-6300 

Fax: +1 408 944-6314 

E-mail: eric@c3.pla.ca.us 
Part 1 ANSI/NIST-ITL 1-2007

107

Why a file interchange format 

JPEG File Interchange Format (JFIF) is a minimal file format, which enables JPEG bitstreams to be 

exchanged between a wide variety of platforms and applications. This minimal format does not include 

any of the advanced features found in the TIFF JPEG specification or any application specific file format. 

The only purpose of this simplified format is to allow the exchange of JPEG compressed images. 

JPEG file interchange format 

• Uses JPEG compression 

• Uses JPBG interchange format compressed image representation 

• PC or Mac or UNIX workstation compatible 

• Standard color space: one or three components. For three components YCbCr (CCIR 601-256 levels) 

• APP0 marker used to specify Units, X pixel density, Y pixel density, thumbnail 

• APP0 marker also used to specify JFIF extensions 

• APP0 mater also used to specify application-specific information 

JPEG compression 

Although any JPEG process is supported by the syntax of the JFIF it is strongly recommended that the 

JPEG baseline process be used for the purposes of file interchange. This ensures maximum compatibility 

with all applications supporting JPEG. JFIF conforms to the JPEG Draft International Standard (ISO DIS 

10918-1). 

The JFIF is entirely compatible with the standard JPEG interchange format; the only additional 

requirement is the mandatory presence of the APP0 marker right after the SOI marker. Note that the 

JPEG interchange format requires (as does JFIF) all table specifications used in the encoding process be 

coded in the bitstream prior to their use. 

Compatible across platforms 

The JFIF is compatible across platforms: for example, it can use any resource forks supported by the 

Macintosh and by PCs or workstations, but not just one platform. 

Standard color space 

The color space to be used is YCbCr as defined by CCIR 601(256 levels). The RGB components 

calculated by linear conversion from YCbCr shall not be gamma corrected (gamma = 1.0). If only one 

component is used, that component shall be Y. 

APP0 marker is used to identify JPEG FIF 

• The APP0 marker is used to identify a JPEG FIF file. 

• The JPEG FIF APP0 marker is mandatory right after the SOI marker. 

• The JFIF APP0 marker is identified by a zero terminated string: “JFIF”. 

• The APP0 can be used for any other purpose by the application provided it can be distinguished from 

the JFIF APP0. 

• The JFIF APP0 marker provides information which is missing from the JPEG stream: version number, 

X and Y pixel density (dots per inch or dots per cm), pixel aspect ratio (derived from X and Y pixel 

density), thumbnail. 
Part 1 ANSI/NIST-ITL 1-2007

108

APP0 marker used to specify JFIF extensions 

Additional APP0 marker segment(s) can optionally be used to specify JFIF extensions. If used, these 

segments must immediately follow the JFIF APP0 marker. Decoders should skip any unsupported JFIF 

extension segments and continue decoding. 

The JFIF extension APP0 marker is identified by a zero terminated string: "JFXX". The JFIF extension 

APP0 marker segment contains a 1-byte code, which identifies the extension. This version, version 1.02, 

has only one extension defined: an extension for defining thumbnails stored in formats other than 24-bit 

RGB. 

APP0 marker used for application-specific information 

Additional APP0 marker segments can be used to hold application-specific information which does not 

affect the decodability or displayability of the JFIF file. Application-specific APP0 marker segments must 

appear after the JFIF APP0 and any JFXX APP0 segments. Decoders should skip any unrecognized 

application-specific APP0 segments. 

Application-specific APP0 marker segments are identified by a zero terminated string which identifies the 

application (not “JFlF” or "JFXX"). This string should be an organization name or company trademark. 

Generic strings such as dog, cat, tree, etc. should not be used. 

Conversion to and from RGB 

Y, Cb, and Cr are converted from R, G, and B as defined in CCIR Recommendation 601 but are 

normalized so as to occupy the full 256 levels of an 8-bit binary encoding. More precisely: 

Y = 256 * E'y 

Cb = 256 * [ E'Cb] + 128 

Cr= 256 * [ E'Cr] + 128 

where the E'y E'Cb and E'Cr are defined as in CCIR 601. Since values of E'y have a range of 0 to 1.0 and 

those for E'Cb and E'Cr have a range of -0.5 to +0.5, Y, Cb, and Cr must be clamped to 255 when they are 

maximum value. 

RGB to YCbCr conversion 

YCbCr (256 levels) can be computed directly from 8-bit RGB as follows: 

Y = 0.299 R + 0.587G + 0.114B 

Cb = -0.1687 R - 0.3313 G + 0.5 B + 128 

Cr = 0.5R - 0.4177 G - 0.0813 B + 128 

NOTE - Not all image file formats store image samples in the order R0, G0, B0, ... Rn, Gn, Bn. Be sure to 

verify the sample order before converting an RGB file to JFIF 

YCbCr to RGB conversion 

RGB can be computed directly from YCbCr (256 levels) as follows: 

R = Y + 1.402 (Cr - 128) 

G = Y-0.34414 (Cb - 128) - 0.71414 (Cr - 128) 

B = Y + 1.772 (Cb - 128) 
Part 1 ANSI/NIST-ITL 1-2007

109

Image orientation 

In JFIF files, the image orientation is always top-down. This means that the first image samples encoded 

in a JFIF file are located in the upper left hand corner of the image and encoding proceeds from left to 

right and top to bottom. Top-down orientation is used for both the full resolution image and the thumbnaiI 

image. 

The process of converting an image file having bottom-up orientation to JFIF must include inverting the 

order of all image lines before JPEG encoding. 

Spatial relationship of components 

Specification of the spatial positioning of pixel samples within components relative to the samples of other 

components is necessary for proper image post processing and accurate image presentation. In JFIF 

files, the position of the pixels in subsampled components are defined with respect to the highest 

resolution component. Since components must be sampled orthogonally (along rows and columns), the 

spatial position of the samples in a given subsampled component may be determined by specifying the 

horizontal and vertical offsets of the first sample, i.e. the sample in the upper left corner, with respect to 

the highest resolution component. 

The horizontal and vertical offsets of the first sample in a subsampled component, Xoffseti [0,0] and 

Yoffseti [0,0], are defined to be: 

Xoffseti

[0,0] = ((Nsamplesref / Nsamplesj) / 2) - 0.5 

Yoffseti[0,0] = ((Nlinesref / Nlinesi) / 2) - 0.5 

where 

Nsamplesref is the number of samples per line in the largest component; 

Nsamplesi is the number of samples per line in the ith component; 

Nlinesref is the number of lines in the largest component; 

Nlinesi is the number of lines in the ith component. 

Proper subsampling of components incorporates an anti-aliasing filter which reduces the spectral 

bandwidth of the full resolution components. Subsampling can easily be accomplished using a 

symmetrical digital filter with an even number of taps (coefficients). A commonly used filter for 2:1 

subsampling utilizes two taps (1/2,1/2). 

As an example, consider a 3 component image which is comprised of components having the following 

dimensions: 

Component 1: 256 samples, 288 lines 

Component 2: 128 samples, 144 lines 

Component 3: 64 samples, 96 lines 

In a JFIF file, centers of the samples are positioned as illustrated below: 

x x x x 

 

x x  x x 

x x x x 

 

x x x x 

where 

X Component 1 
Part 1 ANSI/NIST-ITL 1-2007

110

 Component 2 

 Component 3 

NOTE - This definition is compatible with industry standards such as Postscript Level 2 and QuickTime. 

This definition is not compatible with the conventions used by CCIR Recommendation 601-I and other 

digital video formats. For these formats, pre-processing of the chrominance components is necessary 

prior to compression in order to ensure accurate reconstruction of the compressed image. 

JPEG fiIe interchange format specification 

The syntax of a JFIF file conforms to the syntax for interchange format defined in Annex B of ISO DIS 

10918-1. In addition, a JFIF file uses APP0 marker segments and constrains certain parameters in the 

frame header as defined below. 

X'FF', SOI 

X’FF’, APP0, length, identifier, version, units, Xdensity, Ydensity, Xthumbnail, Ythumbnail, (RGB)n

Length (2 bytes) Total APP0 field byte count, 

including the 

byte count value (2 bytes), but excluding 

the APP0 marker itself 

identifier (5 bytes) = X'4A', X'46', X'49’, X’46', X'00' 

This zero terminated string ("JFIF") 

Uniquely identifies this APP0 marker. This 

string shall have zero parity (bit 7=0). 

version (2 bytes) = X'0102' 

The most significant byte is used for major 

revisions, the least significant byte for 

minor revisions. Version 1.02 is the 

current released revision. 

units (1 byte) Units for the X and Y densities 

units = 0: no units, X and Y specify the pixel 

units = 1: X and Y are dots per inch 

units = 2: X and Y are dots per cm 

Xdensity (2 bytes) Horizontal pixel density 

Ydensity (2 bytes) Vertical pixel density 

XthumbnaiI (1 byte) Thumbnail horizontal pixel count 

Ythumbnail (1 byte) Thumbnail vertical pixel count 

(RGB)n (3n bytes) Packed (24-bit) RGB values for 

the 

thumbnail pixels, n = XthumbnaiI * Ythumbnail 

[Optional JFIF extension APP0 marker segment(s) - see below]

• 

• 

• 

X 'FF', SOFn, length,. frame parameters

Number of components Nf = 1 or 3 

1st component C1 = 1 = Y component 
Part 1 ANSI/NIST-ITL 1-2007

111

2nd component C2 = 2 = Cb component 

3rd component C3 = 3 = Cr component 

• 

• 

• 

X 'FF', EOI 

JFIF Extension: APP0 marker segment 

Immediately following the JFIF APP0 marker segment may be a JFIF extension APP0 marker. This JFIF 

extension APP0 marker segment may only be present for JFIF versions 1.02 and above. The syntax of 

the JFIF extension APP0 marker segment is: 

X 'FF', APP0,. Length, identifier, extension code, extension data

length (2 bytes) Total APP0 field byte count, including 

the 

byte count value (2 bytes), but excluding 

the APP0 marker itself 

identifier (5 bytes) = X '4A', X ‘461

, X '58', X '58', X ‘00’

This zero terminated string ("JFXX") 

uniquely identifies this APP0 marker. This 

string shall have zero parity (bit 7 = 0). 

extension_code (1 byte) = Code which identifies the extension. In 

this version, the following extensions are 

defined: 

= X '10' Thumbnail coded using JPEG 

= X '11’ Thumbnail stored using 1 byte/pixel 

= X '13’ Thumbnail stored using 3 bytes/pixel 

extension_data (variable) = The specification of the remainder of the 

JFIF extension APP0 marker segment 

varies with the extension. See below for a 

specification of extension_data for each extension. 

JFIF Extension: Thumbnail coded using JPEG

This extension supports thumbnails compressed using JPEG. The compressed thumbnail immediately 

follows the extension-code (X ‘I0') in the extension_data field and the length of the compressed data must 

be included in the JFIF extension APP0 marker length field. 

The syntax of the extension_data field conforms to the syntax for interchange format defined in Annex B 

of ISO DIS 10917-1. However, no "JFIF" or "JFXX" marker segments shall be present. As in the full 

resolution image of the JFIF file, the syntax of extension_data constrains parameters in the frame header 

as defined below: 

X 'FF', SOI 

•

•

X'FF'. SOFn, length, frame parameters

Number of components Nf = 1 or 3 

1st component C1 = 1 = Y component 
Part 1 ANSI/NIST-ITL 1-2007

112

2nd component C2 = 2 = Cb component 

3rd component C3 = 3 = Cr component 

•

•

X 'FF', EOI 

JFIF Extension: ThumbnaiI stored using one byte per pixel 

This extension supports thumbnails stored using one byte per pixel and a color palette in the 

extension_data field. The syntax of extension_data is: 

Xthumbnail (I byte) Thumbnail horizontal pixel count 

Ythumbnail (1 byte) Thumbnail vertical pixel count 

Palette (768 bytes) 24-bit RGB pixel values for the 

color 

palette. The RGB values define the colors 

represented by each value of an 8-bit 

binary encoding (0 - 255). 

(pixel)n (n bytes) 8-bit values for the thumbnail 

pixels 

n = Xthumbnail * Ythumbnall 

JFIF Extension: Thumbnail stored using three bytes per pixel 

This extension supports thumbnails stored using three bytes per pixel in the extension_data field. The 

syntax of extension_data is: 

Xthumbnail (1 byte) Thumbnail horizontal pixel count 

Ythumbnail (1 byte) Thumbnail vertical pixel count 

(RGB)n (3n bytes) Packed (24-bit) RGB values for 

the thumbnail 

pixels, n = Xthumbnail * Ythumbnail 

Useful tips 

• You can identify a JFIF file by looking for the following sequence: X'FF’, SOI, X'FF', APP0, <2 bytes 

to be skipped>, "JFIF", X'00'. 

• If you use APP0 elsewhere, be sure not to have the strings "JFIF” or “JFXX” right after the APP0 

marker. 

• If you do not want to include a thumbnail, just program Xthumbnail = Ythumbnail = 0. 

• Be sure to check the version number in the special APP0 field. In general, if the major version 

number of the JFIF file matches that supported by the decoder, the file will be decodable. 

• If you only want to specify a pixel aspect ratio, put 0 for the units field in the special APP0 field. 

Xdensity and Ydensity can then be programmed for the desired aspect ratio. Xdensity = 1, Ydensity = 

1 will program a 1:1 aspect ratio. Xdensity and Ydensity should always be non-zero. 
Part 1 ANSI/NIST-ITL 1-2007

113

Annex E NCIC Codes for Scars, marks, tattoos, and other characteristics 

(normative) 

This annex contains codes based on portions of the Ninth edition (December, 2000) of the NCIC Code 

Manual for describing Scars, Marks, Tattoos, and other characteristics (alphabetized by code). The 

following list is intended to standardize entry of data in the SMT Field. Care must be taken to enter 

spaces exactly as shown. However, as the NCIC Code Manual gets updated, the latest edition shall be 

the governing document regarding valid SMT codes. 

Item/Location Code 

Arm, nonspecific, artificial ART ARM 

Breast, nonspecific, 

artificial 

ART BRST 

Breast implant, left and 

right 

ART BRSTS 

Ear, nonspecific, artificial ART EAR 

Artificial elbow joint ART ELB0W 

Eye, nonspecific, artificial ART EYE 

Foot, nonspecific, artificial ART F00T 

Hand, nonspecific, 

artificial 

ART HAND 

Artificial hip joint ART HIP 

Artificial knee joint ART KNEE 

Arm, left, artificial ART L ARM 

Breast implant, left ART L BRST 

Ear, left, artificial ART L EAR 

Left Elbow, artificial ART L ELB 

Eye, left, artificial ART L EYE 

Foot, left, artificial ART L FT 

Left Hip, artificial ART L HIP 

Hand, left, artificial ART L HND 

Left Knee, artificial ART L KNE 

Leg, left, artificial ART L LEG 

Left Shoulder, artificial ART L SHLD 

Artificial larynx ART LARYNX 

Leg, nonspecific, artificial ART LEG 

Arm, right, artificial ART R ARM 

Breast implant, right ART R BRST 

Ear, right, artificial ART R EAR 

Right Elbow, artificial ART R ELB 

Eye, right, artificial ART R EYE 

Foot, right, artificial ART R FT 

Right Hip, artificial ART R HIP 

Hand, right, artificial ART R HND 

Right Knee, artificial ART R KNE 

Leg, right, artificial ART R LEG 

Right Shoulder, artificial ART R SHLD 

Artificial shoulder joint ART SHLD 

Bald/Balding BALD 

Blind, both eyes BLIND 

Blind, one eye, 

nonspecific 

BLND EYE 

Blind, left eye BLND L EYE 

Blind, right eye BLND R EYE 

Brace, left and right arms BRA LR ARM 

Brace, left and right legs BRA LR LEG 

Brace, one arm, 

nonspecific 

BRAC ARM 

Brace, left arm BRAC L ARM 

Brace, left leg BRAC L LEG 

Brace, one leg, 

nonspecific 

BRAC LEG 

Brace, right arm BRAC R ARM 

Brace, right leg BRAC R LEG 

Brace, teeth BRAC TEETH 

Brace, back BRACE BACK 

Brace, neck BRACE NECK 

Cane CANE 

Cardiac pacemaker CARD PACEM 

Cataract, left eye CATA L EYE 

Cataract, right eye CATA R EYE 

Cataract, (nonspecified) CATARACT 

Cauliflower Ear CAUL EAR 

Cauliflower ear, left CAUL L EAR 

Cauliflower ear, right CAUL R EAR 

Cleft Lip CL LIP 

Cleft chin CLEFT CHIN 

Cleft palate CLEFT PAL 

Arm, nonspecific, crippled CRIP ARM 

Finger(s), nonspecific, 

crippled 

CRIP FGR 

Foot, nonspecific, crippled CRIP F00T 

Hand, nonspecific, 

crippled 

CRIP HAND 

Crippled arm, left CRIP L ARM 
Part 1 ANSI/NIST-ITL 1-2007

114

Crippled finger(s), left 

hand (includes 

webbed fingers) 

CRIP L FGR 

Crippled foot, left 

(includes clubfoot) 

CRIP L FT 

Crippled hand, left CRIP L HND 

Crippled leg, left CRIP L LEG 

Crippled toe(s), left 

(includes webbed 

toes) 

CRIP L T0E 

Leg, nonspecific, crippled CRIP LEG 

Crippled arm, right CRIP R ARM 

Crippled finger(s), right 

hand (includes 

webbed fingers) 

CRIP R FGR 

Crippled foot, right 

(includes clubfoot) 

CRIP R FT 

Crippled hand, right CRIP R HND 

Crippled leg, right CRIP R LEG 

Crippled toe(s), right 

(includes webbed 

toes) 

CRIP R T0E 

Toe(s), nonspecific, 

crippled 

CRIP T0E 

Crutches CRUTCHES 

Crosseyed CR0SSEYED 

Colostomy appliances C0L0ST APP 

Contact lenses C0N LENSES 

Alcohol DA ALC0H0L 

Amphetamines (includes 

stimulants, speed, 

etc.) 

DA AMPHETA 

Barbiturates DA BARBITU 

Cocaine (includes crack) DA C0CAINE 

Glue DA GLUE 

Hallucinogens DA HALLUCI 

Marijuana DA MARIJUA 

Narcotics (includes 

Heroin,Morphine, 

Dilaudid, Methadone, 

etc.) 

DA NARC0TI 

Paint (includes thinner) DA PAINT 

Ritalin DA RITALIN 

Rohypnol (Brand name 

for Flunitrazepam. 

Also referred to as 

"rophies", "roofies", 

"ruffies", and "roche". 

DA R0HYPNL 

Other drugs of abuse not 

listed above, identify 

in the miscellaneous 

(MIS) field 

DA 0THER 

Deaf, left and right ears DEAF 

Deaf, one ear 

(nonspecific) 

DEAF EAR 

Deaf, left ear DEAF L EAR 

Deaf-mute DEAF MUTE 

Deaf, right ear DEAF R EAR 

Denture, lower only DENT L0W 

Denture, upper only DENT UP 

Denture, upper and lower DENT UP L0 

Deviated septum DEV SEPTUM 

Cheek, nonspecific, 

dimple 

DIMP CHEEK 

Dimples, chin DIMP CHIN 

Face, dimple DIMP FACE 

Dimples, left cheek (face) DIMP L CHK 

Dimples, right cheek 

(face) 

DIMP R CHK 

Abdomen DISC ABD0M 

Ankle, nonspecific DISC ANKL 

Arm, nonspecific DISC ARM 

Back DISC BACK 

Breast, nonspecific DISC BRST 

Buttocks, nonspecific DISC BUTTK 

Calf, nonspecific, 

discolored 

DISC CALF 

Cheek (face), nonspecific DISC CHEEK 

Chest DISC CHEST 

Chin DISC CHIN 

Ear, nonspecific DISC EAR 

Elbow, nonspecific, 

discolored 

DISC ELB0W 

Eyebrow, nonspecific DISC EYE 

Forearm, nonspecific, 

discolored 

DISC F ARM 

Face, nonspecific DISC FACE 

Finger, nonspecific DISC FGR 

Forehead DISC FHD 

Foot, nonspecific DISC F00T 

Groin, nonspecific, 

discolored 

DISC GR0IN 

Hand, nonspecific, 

discolored 

DISC HAND 

Head DISC HEAD 

Hip, nonspecific DISC HIP 

Knee, nonspecific DISC KNEE 

Ankle, left DISC L ANK 

Arm, left DISC L ARM 

Breast, left DISC L BRS 

Buttock, left DISC L BUT 

Left Calf, discolored DISC L CALF 
Part 1 ANSI/NIST-ITL 1-2007

115

Cheek (face), left DISC L CHK 

Ear, left DISC L EAR 

Left Elbow, discolored DISC L ELB 

Eyebrow, left/left eye area DISC L EYE 

Finger(s), left hand DISC L FGR 

Foot, left DISC L FT 

Hip, left DISC L HIP 

Hand, left DISC L HND 

Leg, left DISC L LEG 

Lip, lower DISC L LIP 

Left Toe, discolored DISC L T0E 

Wrist, left DISC L WRS 

Leg, nonspecific DISC LEG 

Left Forearm, discolored DISC LF ARM 

Lip, nonspecific DISC LIP 

Knee, left DISC LKNEE 

Shoulder, left DISC LSHLD 

Thigh, left DISC LTHGH 

Neck DISC NECK 

Nose DISC N0SE 

Penis DISC PENIS 

Ankle, right DISC R ANK 

Arm, right DISC R ARM 

Breast, right DISC R BRS 

Buttock, right DISC R BUT 

Right Calf, discolored DISC R CALF 

Cheek (face), right DISC R CHK 

Ear, right DISC R EAR 

Right Elbow, discolored DISC R ELB 

Eyebrow, right/right eye 

area 

DISC R EYE 

Finger(s), right hand DISC R FGR 

Foot, right DISC R FT 

Hip, right DISC R HIP 

Hand, right DISC R HND 

Leg, right DISC R LEG 

Right Toe, discolored DISC R T0E 

Wrist, right DISC R WRS 

Right Forearm, discolored DISC RF ARM 

Knee, right DISC RKNEE 

Shoulder, right DISC RSHLD 

Thigh, right DISC RTHGH 

Shoulder, nonspecific DISC SHLD 

Thigh, nonspecific DISC THGH 

Toe(s), nonspecific, 

discolored 

DISC T0E 

Lip, upper DISC U LIP 

Upper Left Arm, 

discolored 

DISC UL ARM 

Upper Right Arm, 

discolored 

DISC UR ARM 

Wrist, nonspecific DISC WRIST 

Tubes in ears, left and 

right 

EAR TUBES 

Extra breast, nonspecific EXTR BRST 

Extra nipple, center EXTR C NIP 

Extra vertebrae, cervical EXTR C VRT 

Extra breast, center EXTR CBRST 

Finger(s), nonspecific, 

extra 

EXTR FGR 

Extra finger(s), left hand EXTR L FGR 

Extra nipple, left EXTR L NIP 

EXTRA TOOTH/TEETH 

(LOWER JAW) 

EXTR L TTH 

Extra toe(s), left EXTR L T0E 

Extra vertebrae, lumbar EXTR L VRT 

Extra breast, left EXTR LBRST 

Extra nipple, nonspecific EXTR NIP 

Extra finger(s), right hand EXTR R FGR 

Extra nipple, right EXTR R NIP 

Extra toe(s), right EXTR R T0E 

Extra breast, right EXTR RBRST 

Tooth/Teeth, nonspecific, 

extra 

EXTR TTH 

Toe(s), nonspecific, extra EXTR T0E 

EXTRA TOOTH/TEETH 

(UPPER JAW) 

EXTR U TTH 

Extra vertebrae, 

nonspecific 

EXTR VRT 

Ankle, nonspecific FRC ANKL 

Arm, nonspecific FRC ARM 

Back FRC BACK 

Clavicle, nonspecific FRC CLAVIC 

Elbow, nonspecific, 

fractured 

FRC ELB0W 

Finger(s), nonspecific FRC FGR 

Foot, nonspecific FRC F00T 

Hand, nonspecific FRC HAND 

Hip, nonspecific, fractured FRC HIP 

Jaw, nonspecific FRC JAW 

Knee, nonspecific FRC KNEE 

Ankle, left FRC L ANKL 

Left Arm, fractured FRC L ARM 

Left Elbow, fractured FRC L ELB 

Finger(s), left FRC L FGR 

Foot, left FRC L F00T 

Hand, left FRC L HAND 

Left Hip, fractured FRC L HIP 

Knee, left FRC L KNEE 
Part 1 ANSI/NIST-ITL 1-2007

116

Left Leg, fractured FRC L LEG 

Rib(s), left FRC L RIB 

Shoulder, left FRC L SHLD 

Toe(s), left foot FRC L T0E 

Wrist, left FRC L WRST 

Clavicle, left FRC LCLAVI 

Leg, nonspecific FRC LEG 

Arm, lower left FRC LL ARM 

Jaw, lower left FRC LL JAW 

Leg, lower left FRC LL LEG 

Pelvis bone, left FRC LPELVI 

Arm, lower right FRC LR ARM 

Jaw, lower left FRC LR JAW 

Leg, lower right FRC LR LEG 

Neck FRC NECK 

Nose FRC N0SE 

Pelvis FRC PELVIS 

Ankle, right FRC R ANKL 

Right Arm, fractured FRC R ARM 

Right Elbow, fractured FRC R ELB 

Finger(s), right FRC R FGR 

Foot, right FRC R F00T 

Hand, right FRC R HAND 

Right Hip, fractured FRC R HIP 

Knee, right FRC R KNEE 

Right Leg, fractured FRC R LEG 

Rib(s), right FRC R RIB 

Shoulder, right FRC R SHLD 

Toe(s), right foot FRC R T0E 

Wrist, right FRC R WRST 

Clavicle, right FRC RCLAVI 

Rib(s), nonspecific FRC RIBS 

Pelvis bone, right FRC RPELVI 

Shoulder, nonspecific FRC SHLD 

Skull FRC SKULL 

Spine FRC SPINE 

Sternum FRC STERN 

Toe(s), nonspecific FRC T0E 

Arm, upper left FRC UL ARM 

Jaw, upper left FRC UL JAW 

Leg, upper left FRC UL LEG 

Arm, upper right FRC UR ARM 

Jaw, upper right FRC UR JAW 

Leg, upper right FRC UR LEG 

Wrist, nonspecific FRC WRIST 

Freckles FRECKLES 

Glasses (prescription) GLASSES 

Glaucoma GLAUC0MA 

Gold tooth G0LD T00TH 

Hair implants HAIR IMPL 

Hearing Aid HEAR AID 

Ankle, nonspecific HFR ANKL 

Arm, nonspecific HFR ARM 

Back HFR BACK 

Clavicle, nonspecific HFR CLAVIC 

Elbow, nonspecific, 

healed fractured 

HFR ELB0W 

Finger(s), nonspecific HFR FGR 

Foot, nonspecific HFR F00T 

Hand, nonspecific HFR HAND 

Hip, nonspecific, healed 

fractured 

HFR HIP 

Jaw, nonspecific HFR JAW 

Knee, nonspecific HFR KNEE 

Ankle, left HFR L ANKL 

Left Arm, healed fractured HFR L ARM 

Left Elbow, healed 

fractured 

HFR L ELB 

Finger(s), left HFR L FGR 

Foot, left HFR L F00T 

Hand, left HFR L HAND 

Left Hip, healed fractured HFR L HIP 

Knee, left HFR L KNEE 

Left Leg, healed fractured HFR L LEG 

Rib(s), left HFR L RIB 

Shoulder, left HFR L SHLD 

Toe(s), left foot HFR L T0E 

Wrist, left HFR L WRST 

Clavicle, left HFR LCLAVI 

Leg, nonspecific HFR LEG 

Arm, lower left HFR LL ARM 

Jaw, lower left HFR LL JAW 

Leg, lower left HFR LL LEG 

Pelvis bone, left HFR LPELVI 

Arm, lower right HFR LR ARM 

Jaw, lower left HFR LR JAW 

Leg, lower right HFR LR LEG 

Neck HFR NECK 

Nose HFR N0SE 

Pelvis HFR PELVIS 

Ankle, right HFR R ANKL 

Right Arm, healed 

fractured 

HFR R ARM 

Right Elbow, healed 

fractured 

HFR R ELB 

Finger(s), right HFR R FGR 

Foot, right HFR R F00T 

Hand, right HFR R HAND 
Part 1 ANSI/NIST-ITL 1-2007

117

Right Hip, healed 

fractured 

HFR R HIP 

Knee, right HFR R KNEE 

Right Leg, healed 

fractured 

HFR R LEG 

Rib(s), right HFR R RIB 

Shoulder, right HFR R SHLD 

Toe(s), right foot HFR R T0E 

Wrist, right HFR R WRST 

Clavicle, right HFR RCLAVI 

Rib(s), nonspecific HFR RIBS 

Pelvis bone, right HFR RPELVI 

Shoulder, nonspecific HFR SHLD 

Skull HFR SKULL 

Spine HFR SPINE 

Sternum HFR STERN 

Toe(s), nonspecific HFR T0E 

Arm, upper left HFR UL ARM 

Jaw, upper left HFR UL JAW 

Leg, upper left HFR UL LEG 

Arm, upper right HFR UR ARM 

Jaw, upper right HFR UR JAW 

Leg, upper right HFR UR LEG 

Wrist, nonspecific HFR WRIST 

Humpbacked HUMPBACKED 

Penile implant IMPL PENIS 

Intramedullary rod INTRA R0D 

Intrauterine device IUD 

Acne MC ACNE 

Attention Deficit Disorder MC ADD 

Alcoholism MC ALC0H0L 

Allergies including asthma MC ALLERGY 

Alzheimer's Disease MC ALZHMRS 

Arthritis MC ARTHRTS 

Behavior Disorder 

(includes Autism, 

Depression, 

Schizophrenia, 

Suicidal Tendencies 

(past and present) 

MC BEHAVI0 

Hematological Diseases 

(disease of the blood 

- includes: anemia, 

hemophilia, 

leukemia, and sickle 

cell anemia 

MC BL00D 

Cancer MC CANCER 

Diabetic MC DIABTIC 

Drug Abuse MC DRUGAB 

Down's Syndrome MC D0WNSYN 

Eating Disorders 

(Includes Anorexia 

Nervosa and 

Bulimia) 

MC EATDIS 

Heart or circulatory 

diseases including: 

high blood pressure, 

heart failure, heart 

attack, hardening of 

the arteries, and 

circulation problems 

MC HEART 

Kidney Conditions or 

Diseases 

MC KIDNEY 

Liver Disease (Including 

cirrhosis and 

hepatitis) 

MC LIVER 

Nervous conditions 

including: seizures, 

stroke, senility, and 

mental retardation 

MC NERV0US 

Neurological Conditions 

or Diseases 

(includes Cerebral 

Palsy, Epilepsy, 

Multiple Sclerosis, 

Parkinson's Disease) 

MC NRLGCAL 

Paraplegic MC PARPLGC 

Pregnancy - Past MC PASTPRE 

Pulmonary (Lung) 

Diseases (includes 

Emphesyma, Cystic 

Fibrosis) 

MC PLMNARY 

Pregnancy - Present MC PREGNAN 

Quadriplegic MC QUADPLG 

Skin Disorders (includes 

psoriasis and 

eczema) 

MC SKIN 

Tuberculosis MC TB 

Thyroid Conditions or 

Diseases 

MC THYR0ID 

Tourette's Syndrome MC T0URETE 

Other medical 

disorders/conditions 

not listed above, 

identify in the 

Miscellaneous (MIS) 

Field 

MC 0THER 

Adenoids MISS ADND 

Appendix MISS APPNX 

Arm, nonspecific, missing MISS ARM 

Breast, nonspecific, 

missing 

MISS BRST 

Breasts MISS BRSTS 
Part 1 ANSI/NIST-ITL 1-2007

118

Missing Cervical 

Vertebra(e) 

MISS C VRT 

Ear, nonspecific, missing MISS EAR 

Eye, nonspecific, missing MISS EYE 

Finger(s), nonspecific, 

missing 

MISS FGR 

Finger Joint, nonspecific, 

missing 

MISS FJT 

Foot, nonspecific, missing MISS F00T 

Gallbladder MISS GALL 

Hand, nonspecific, 

missing 

MISS HAND 

Intestines MISS INTES 

Kidney, nonspecific, 

missing 

MISS KID 

Arm, left MISS L ARM 

Ear, left MISS L EAR 

Eye, left MISS L EYE 

Finger(s), left hand MISS L FGR 

Finger joint(s), left hand MISS L FJT 

Foot, left MISS L FT 

Hand, left MISS L HND 

Kidney, left MISS L KID 

Leg, left MISS L LEG 

Testis, left MISS L TES 

Toes(s), left foot MISS L T0E 

Missing Lumbar 

Vertebra(e) 

MISS L VRT 

Breast, left MISS LBRST 

Leg, nonspecific, missing MISS LEG 

Arm, lower left MISS LLARM 

Leg, lower left MISS LLLEG 

Lung, left MISS LLUNG 

Arm, lower right MISS LRARM 

Leg, lower right MISS LRLEG 

Larynx MISS LRYNX 

Lung, nonspecific, 

missing 

MISS LUNG 

Ovary, left MISS L0VAR 

Nose MISS N0SE 

Pancreas MISS PANCR 

Missing Penis MISS PENIS 

Prostate Gland MISS PR0ST 

Arm, right MISS R ARM 

Ear, right MISS R EAR 

Eye, right MISS R EYE 

Finger(s), right hand MISS R FGR 

Finger joint(s), right hand MISS R FJT 

Foot, right MISS R FT 

Hand, right MISS R HND 

Kidney, right MISS R KID 

Leg, right MISS R LEG 

Testis, right MISS R TES 

Toes(s), right foot MISS R T0E 

Breast, right MISS RBRST 

Lung, right MISS RLUNG 

Ovary, right MISS R0VAR 

Spleen MISS SPLEN 

Stomach MISS ST0MA 

Testical, nonspecific, 

missing 

MISS TES 

Thyroid MISS THYRD 

Toe(s), nonspecific, 

missing 

MISS T0E 

Tongue MISS T0NG 

Tonsils MISS T0NSL 

Uterus MISS UTRUS 

Missing 

Vertebra(e),nonspeci

fic 

MISS VRT 

Ovaries MISS 0VARS 

Ovary, nonspecific, 

missing 

MISS 0VARY 

Mute (To be used if 

person is mute but 

not deaf.) 

MUTE 

Abdomen M0LE ABD0M 

Ankle, nonspecific M0LE ANKL 

Arm, nonspecific, mole M0LE ARM 

Back M0LE BACK 

Breast, nonspecific M0LE BRST 

Buttocks, nonspecific M0LE BUTTK 

Calf, nonspecific, mole M0LE CALF 

Chest M0LE CHEST 

Chin M0LE CHIN 

Cheek (face), nonspecific M0LE CHK 

Ear, nonspecific M0LE EAR 

Elbow, nonspecific, mole M0LE ELB0W 

Eye, nonspecific, mole M0LE EYE 

Forearm, nonspecific, 

mole 

M0LE F ARM 

Face, mole M0LE FACE 

Finger, nonspecific M0LE FGR 

Forehead M0LE FHD 

Foot, nonspecific M0LE F00T 

Groin area M0LE GR0IN 

Hand M0LE HAND 

Head, nonspecific M0LE HEAD 

Hip, nonspecific M0LE HIP 

Knee, nonspecific M0LE KNEE 
Part 1 ANSI/NIST-ITL 1-2007

119

Ankle, left M0LE L ANK 

Arm, left M0LE L ARM 

Buttock, left M0LE L BUT 

Left Calf, mole M0LE L CALF 

Cheek (face), left M0LE L CHK 

Ear, left M0LE L EAR 

Left Elbow, mole M0LE L ELB 

Eyebrow, left/left eye area M0LE L EYE 

Finger(s), left hand M0LE L FGR 

Foot, left M0LE L FT 

Hip, left M0LE L HIP 

Hand, left M0LE L HND 

Knee, left M0LE L KNE 

Leg, left M0LE L LEG 

Lip, lower M0LE L LIP 

Shoulder, left M0LE L SHD 

Thigh, left M0LE L THG 

Left Toe, mole M0LE L T0E 

Wrist, left M0LE L WRS 

Breast, left M0LE LBRST 

Leg, nonspecific M0LE LEG 

Left forearm, mole M0LE LF ARM 

Lip, nonspecific M0LE LIP 

Neck M0LE NECK 

Nose M0LE N0SE 

Penis M0LE PENIS 

Ankle, right M0LE R ANK 

Arm, right M0LE R ARM 

Buttock, right M0LE R BUT 

Right Calf, mole M0LE R CALF 

Cheek (face), right M0LE R CHK 

Ear, right M0LE R EAR 

Right Elbow, mole M0LE R ELB 

Eyebrow, right/right eye 

area 

M0LE R EYE 

Finger(s), right hand M0LE R FGR 

Foot, right M0LE R FT 

Hip, right M0LE R HIP 

Hand, right M0LE R HND 

Knee, right M0LE R KNE 

Leg, right M0LE R LEG 

Shoulder, right M0LE R SHD 

Thigh, right M0LE R THG 

Right Toe, mole M0LE R T0E 

Wrist, right M0LE R WRS 

Breast, right M0LE RBRST 

Right forearm, mole M0LE RF ARM 

Shoulder, nonspecific M0LE SHLD 

Thigh, nonspecific M0LE THGH 

Toe(s), nonspecific, mole M0LE T0E 

Lip, right M0LE U LIP 

Upper Left Arm, mole M0LE UL ARM 

Upper Right Arm, mole M0LE UR ARM 

Wrist, nonspecific, mole M0LE WRS 

Ankle, nonspecific, needle 

mark 

NM ANKL 

Arm, nonspecific, needle 

mark 

NM ARM 

Buttock, nonspecific, 

needle mark 

NM BUTTK 

Calf, nonspecific, needle 

mark 

NM CALF 

Elbow, nonspecific, 

needle mark 

NM ELB0W 

Finger(s), nonspecific, 

needle mark 

NM FGR 

Foot, nonspecific, needle 

mark 

NM F00T 

Groin, nonspecific, needle 

mark 

NM GR0IN 

Hand, nonspecific, needle 

mark 

NM HAND 

Hip, nonspecific, needle 

mark 

NM HIP 

Knee, nonspecific, needle 

mark 

NM KNEE 

Left Ankle, needle mark NM L ANKL 

Arm, left NM L ARM 

Buttock, left NM L BUTTK 

Left Calf, needle mark NM L CALF 

Left Elbow, needle mark NM L ELB 

Finger(s), left hand NM L FGR 

Foot, left NM L F00T 

Left Hip, needle mark NM L HIP 

Hand, left NM L HND 

Left Knee, needle mark NM L KNE 

Leg, left NM L LEG 

Left Shoulder, needle 

mark 

NM L SHLD 

Thigh, left NM L THIGH 

Left Toe, needle mark NM L T0E 

Wrist, left NM L WRIST 

Leg, nonspecific, needle 

mark 

NM LEG 

Lower Left Arm, needle 

mark 

NM LL ARM 

Lower Right Arm, needle 

mark 

NM LR ARM 

Penis, needle mark NM PENIS 

Right Ankle, needle mark NM R ANKL 

Arm, right NM R ARM 
Part 1 ANSI/NIST-ITL 1-2007

120

Buttock, right NM R BUTTK 

Right Calf, needle mark NM R CALF 

Right Elbow, needle mark NM R ELB 

Finger(s), right hand NM R FGR 

Foot, right NM R F00T 

Right Hip, needle mark NM R HIP 

Hand, right NM R HND 

Right Knee, needle mark NM R KNE 

Leg, right NM R LEG 

Right Shoulder, needle 

mark 

NM R SHLD 

Thigh, right NM R THIGH 

Right Toe, needle mark NM R T0E 

Wrist, right NM R WRIST 

Shoulder, nonspecific, 

needle mark 

NM SHLD 

Thigh, nonspecific, needle 

mark 

NM THIGH 

Toe(s), nonspecific, 

needle mark 

NM T0E 

Upper Left Arm, needle 

mark 

NM UL ARM 

Upper Right Arm, needle 

mark 

NM UR ARM 

Wrist, nonspecific, needle 

mark 

NM WRIST 

Pierced abdomen PRCD ABDMN 

Pierced back PRCD BACK 

Pierced ear, one 

nonspecific 

PRCD EAR 

Pierced ears PRCD EARS 

Pierced eyebrow, 

nonspecific 

PRCD EYE 

Pierced genitalia PRCD GNTLS 

Pierced left ear PRCD L EAR 

Pierced left eyebrow PRCD L EYE 

Pierced nipple, left PRCD L NIP 

Pierced lip, nonspecific PRCD LIP 

Pierced lip, lower PRCD LLIP 

Pierced nipple, 

nonspecific 

PRCD NIPPL 

Pierced nose PRCD N0SE 

Pierced right ear PRCD R EAR 

Pierced right eyebrow PRCD R EYE 

Pierced nipple, right PRCD R NIP 

Pierced tongue PRCD T0NGU 

Pierced lip, upper PRCD ULIP 

Jaw, nonspecific, 

protruding 

PR0T JAW 

Protruding lower jaw PR0T L JAW 

Protruding upper jaw PR0T U JAW 

Pockmarks P0CKMARKS 

Abdomen RTAT ABDM 

Ankle, nonspecific RTAT ANKL 

Arm, nonspecific RTAT ARM 

Back RTAT BACK 

Breast, nonspecific RTAT BRST 

Buttocks, nonspecific RTAT BUTTK 

Calf, nonspecific RTAT CALF 

Cheek (face), nonspecific RTAT CHEEK 

Chest RTAT CHEST 

Chin RTAT CHIN 

Ear, nonspecific RTAT EAR 

Elbow, nonspecific RTAT ELB0W 

Eye, nonspecific, remove 

tattoo 

RTAT EYE 

Face, nonspecific (Use 

the MIS field to 

further describe 

location) 

RTAT FACE 

Forearm, nonspecific RTAT FARM 

Forehead RTAT FHD 

Full body RTAT FLB0D 

Finger, nonspecific RTAT FNGR 

Foot, nonspecific RTAT F00T 

Groin Area RTAT GR0IN 

Hand, nonspecific RTAT HAND 

Head, nonspecific (Use 

the MIS fieldo further 

describe location) 

RTAT HEAD 

Hip, nonspecific RTAT HIP 

Knee, nonspecific RTAT KNEE 

Arm, left RTAT L ARM 

Cheek (face), left RTAT L CHK 

Ear, left RTAT L EAR 

Elbow, left RTAT L ELB 

Left Eye, remove tattoo RTAT L EYE 

Finger(s), left hand RTAT L FGR 

Hip, left RTAT L HIP 

Hand, left RTAT L HND 

Leg, left RTAT L LEG 

Left Toe, remove tattoo RTAT L T0E 

Ankle, left RTAT LANKL 

Breast, left RTAT LBRST 

Buttocks, left RTAT LBUTK 

Calf, left RTAT LCALF 

Leg, nonspecific RTAT LEG 

Forearm, left RTAT LFARM 

Foot, left RTAT LF00T 

Lip, nonspecific RTAT LIP 

Knee, left RTAT LKNEE 
Part 1 ANSI/NIST-ITL 1-2007

121

Shoulder, left RTAT LSHLD 

Thigh, left RTAT LTHGH 

Lip, lower RTAT LWLIP 

Wrist, left RTAT LWRS 

Neck RTAT NECK 

Nose RTAT N0SE 

Penis RTAT PENIS 

Arm, right (Use the MIS 

field to further 

describe location) 

RTAT R ARM 

Cheek (face), right RTAT R CHK 

Ear, right RTAT R EAR 

Elbow, right RTAT R ELB 

Right Eye, remove tattoo RTAT R EYE 

Finger(s), right hand RTAT R FGR 

Hip, right RTAT R HIP 

Hand, right RTAT R HND 

Leg, right (Use the MIS 

field tourther 

describe location) 

RTAT R LEG 

Right Toe, remove tattoo RTAT R T0E 

Angle, right RTAT RANKL 

Breast, right RTAT RBRST 

Buttocks, right RTAT RBUTK 

Calf, right RTAT RCALF 

Forearm, right RTAT RFARM 

Foot, right RTAT RF00T 

Knee, right RTAT RKNEE 

Shoulder, right RTAT RSHLD 

Thigh, right RTAT RTHGH 

Wrist, right RTAT RWRS 

Shoulder, nonspecific RTAT SHLD 

Thigh, nonspecific RTAT THGH 

Toe(s), nonspecific, 

remove tattoo 

RTAT T0E 

Arm, left upper RTAT ULARM 

Lip, upper RTAT UPLIP 

Arm, right upper RTAT URARM 

Wrist, nonspecific RTAT WRS 

Abdomen SC ABD0M 

Ankle, nonspecific SC ANKL 

Arm, nonspecific SC ARM 

Back SC BACK 

Breast, nonspecific SC BREAST 

Buttocks, nonspecific SC BUTTK 

Calf, nonspecific SC CALF 

Chest SC CHEST 

Chin SC CHIN 

Cheek, nonspecific SC CHK 

Ear, nonspecific SC EAR 

Elbow, nonspecific SC ELB0W 

Eyebrow, nonspecific SC EYE 

Forearm, nonspecific SC F ARM 

Face, nonspecific (use 

MIS field to further 

describe location) 

SC FACE 

Finger, nonspecific SC FGR 

Forehead SC FHD 

Foot, nonspecific SC F00T 

Groin area SC GR0IN 

Hand, nonspecific SC HAND 

Head, nonspecific (use 

MIS field to further 

describe location) 

SC HEAD 

Hip, nonspecific SC HIP 

Knee, nonspecific SC KNEE 

Ankle, left SC L ANKL 

Arm, left, nonspecific SC L ARM 

Breast, left SC L BRST 

Buttocks, left SC L BUTTK 

Calf, left SC L CALF 

Cheek, left SC L CHK 

Ear, left SC L EAR 

Elbow, left SC L ELB 

Eyebrow, left/left eye area SC L EYE 

Finger(s), left hand SC L FGR 

Foot, left SC L FT 

Hip, left SC L HIP 

Hand, left SC L HND 

Knee, left SC L KNEE 

Leg, left SC L LEG 

Shoulder, left SC L SHLD 

Thigh, left SC L THGH 

Left Toe, scar SC L T0E 

Wrist, left SC L WRIST 

Leg, nonspecific SC LEG 

Forearm, left SC LF ARM 

Lip, nonspecific SC LIP 

Lip, lower SC L0W LIP 

Neck SC NECK 

Nose SC N0SE 

Penis SC PENIS 

Ankle, right SC R ANKL 

Arm, right, nonspecific SC R ARM 

Breast, right SC R BRST 

Buttocks, right SC R BUTTK 

Calf, right SC R CALF 

Cheek, right SC R CHK 

Ear, right SC R EAR 

Elbow, right SC R ELB 
Part 1 ANSI/NIST-ITL 1-2007

122

Eyebrow, right/right eye 

area 

SC R EYE 

Finger(s), right hand SC R FGR 

Foot, right SC R FT 

Hip, right SC R HIP 

Hand, right SC R HND 

Knee, right SC R KNEE 

Leg, right SC R LEG 

Shoulder, right SC R SHLD 

Thigh, right SC R THGH 

Right Toe, scar SC R T0E 

Wrist, right SC R WRIST 

Forearm, right SC RF ARM 

Shoulder, nonspecific SC SHLD 

Thigh, nonspecific SC THGH 

Toe(s), nonspecific, scar SC T0E 

Arm, left upper SC UL ARM 

Lip, upper SC UP LIP 

Arm, right upper SC UR ARM 

Wrist, nonspecific SC WRIST 

Shorter left leg SHRT L LEG 

Leg, nonspecific, short SHRT LEG 

Shorter right leg SHRT R LEG 

Shunt, arterial vascular SHUNT ART 

Shunt, cerebral ventricule SHUNT CERB 

Skull plate SKL PLATE 

Silver tooth SLVR T00TH 

Staples STAPLES 

Stutters STUTTERS 

Abdomen TAT ABD0M 

Ankle, nonspecific TAT ANKL 

Arm, nonspecific TAT ARM 

Back TAT BACK 

Breast TAT BREAST 

Buttocks TAT BUTTK 

Calf, nonspecific TAT CALF 

Cheek (face), nonspecific TAT CHEEK 

Chest TAT CHEST 

Chin TAT CHIN 

Ear, nonspecific TAT EAR 

Elbow, nonspecific TAT ELB0W 

Eye, nonspecific, tattoo TAT EYE 

Face, nonspecific (use 

MIS field to further 

describe location) 

TAT FACE 

Forearm, nonspecific TAT FARM 

Forehead TAT FHD 

Full Body (Use only when 

the entire body - 

arms, legs, chest, 

and back are 

covered with 

tattoos.) 

TAT FLB0DY 

Finger, nonspecific TAT FNGR 

Foot, nonspecific TAT F00T 

Groin area TAT GR0IN 

Hand, nonspecific TAT HAND 

Head, nonspecific (use 

MIS field to further 

describe location) 

TAT HEAD 

Hip, nonspecific TAT HIP 

Knee, nonspecific TAT KNEE 

Ankle, left TAT L ANKL 

Arm, left TAT L ARM 

Breast, left TAT L BRST 

Buttock, left TAT L BUTK 

Calf, left TAT L CALF 

Cheek (face), left TAT L CHK 

Ear, left TAT L EAR 

Left Eye, tattoo TAT L EYE 

Finger(s), left hand TAT L FGR 

Foot, left TAT L F00T 

Hip, left TAT L HIP 

Hand, left TAT L HND 

Knee, left TAT L KNEE 

Leg, left, nonspecific TAT L LEG 

Shoulder, left TAT L SHLD 

Thigh, left TAT L THGH 

Left Toe, tattoo TAT L T0E 

Wrist, left TAT L WRS 

Leg, nonspecific TAT LEG 

Elbow, left TAT LELB0W 

Forearm, left TAT LF ARM 

Lip, nonspecific TAT LIP 

Lip, lower TAT LW LIP 

Neck TAT NECK 

Nose TAT N0SE 

Penis TAT PENIS 

Ankle, right TAT R ANKL 

Arm, right TAT R ARM 

Breast, right TAT R BRST 

Buttock, right TAT R BUTK 

Calf, right TAT R CALF 

Cheek (face), right TAT R CHK 

Ear, right TAT R EAR 

Right Eye, tattoo TAT R EYE 

Finger(s), right hand TAT R FGR 
Part 1 ANSI/NIST-ITL 1-2007

123

Foot, right TAT R F00T 

Hip, right TAT R HIP 

Hand, right TAT R HND 

Knee, right TAT R KNEE 

Leg, right, nonspecific TAT R LEG 

Shoulder, right TAT R SHLD 

Thigh, right TAT R THGH 

Right Toe, tattoo TAT R T0E 

Wrist, right TAT R WRS 

Elbow, right TAT RELB0W 

Forearm, right TAT RF ARM 

Shoulder, nonspecific TAT SHLD 

Thigh, nonspecific TAT THGH 

Toe(s), nonspecific, tattoo TAT T0E 

Arm, left upper TAT UL ARM 

Lip, upper TAT UP LIP 

Arm, right upper TAT UR ARM 

Wrist, nonspecific TAT WRS 

Anticonvulsants (seizure 

medicines - includes: 

Dilantin Mysoline, 

Phenobarbital, etc.) 

TD AC0NVUL 

Antidepressants (moodlifters - (Mood lifters - 

includes: 

Amitriptylene, Elavil, 

Norpramine, Prozac, 

Triavil, Zoloft, etc.) 

TD ADEPRES 

Analgesics (pain relievers 

-includes: Darvon, 

Acetominophen, 

Aspirin, etc.) 

TD ANALGES 

Antibiotics TD ANTBTCS 

Anti-Inflammatory 

Medication 

TD ANTINFL 

Bronchial Dilators 

(Includes inhalers) 

TD BRNCHDL 

Cardiac (heart 

medications -

includes: Digitalis, 

Digoxin, etc.) 

TD CARDIAC 

Hypnotics (sleeping aides 

-includes: 

Barbiturates, Chloral 

Hydrate, 

Glutethemide, etc.) 

TD HYPN0TI 

Insulin TD INSULIN 

Ritalin TD RITALIN 

Tranquilizers (includes: 

Valium, Thorazine, 

Stellazine, etc.) 

TD TRANQUI 

Other therapeutic 

medications not 

listed above, identify 

in the MIS Field. 

TD 0THER 

Transsexual 

(Miscellaneous field 

should indicate what 

the individual was at 

birth and what they 

are at the time the 

record is entered into 

NCIC.) 

TRANSSXL 

Transvestite TRANSVST 

Tube in left ear TUBE L EAR 

Tube in right ear TUBE R EAR 

Vascular prosthesis VASC PR0TH 

Wheelchair WHEELCHAIR 

Wire sutures WIRE SUTUR 

Orthopedic nail or pin 0RTH NAIL 

Orthopedic plate 0RTH PLATE 

Orthopedic screw 0RTH SCREW 

 
Part 1 ANSI/NIST-ITL 1-2007

124

Annex F Example transaction 

(informative) 

This annex contains an example of the use of the standard for the interchange of specific types of 

biometric image data between different systems or organizations. The TOT code is fictional and 

used to represent a transaction for submitting fingerprint, mugshot, and palmprint image data to a 

remote system. In addition to the Type-1 record, this transaction includes eight other records. It 

contains a Type-2 user-defined descriptive text record, a Type-10 mugshot record, three Type-14 

variable resolution tenprint image records, two Type-15 variable resolution records containing a 

full and writer’s palmprint image, and a Type-99 CBEFF record. A scanning resolution of 19.69 

ppmm (500 ppi) was used for the fingerprint and palmprint images. The WSQ Version 2.0 

compression algorithm was used to compress these images to approximately 15:1. For the 

mugshot image, a JPEG Baseline algorithm was used to compress the image to approximately 

20:1. 

The example of a Type-99 CBEFF Data Record contains a Biometric Data Block (BDB) that is 

formatted in a fictional INCITS M1 body odor data interchange format. M1 is a registered BDB 

format owner and has (fictionally) assigned a BDB Format Type code of 0xABCD Hex to this data 

format. The <binary data> in the BDB field of this record is the body odor BDB which contains 

100,000 bytes. 

Type-1 Transaction Record

LENGTH (LEN) 1.001: 245 S

G

VERSION (VER) 1.002:0400 S

G

CONTENT (CNT) 1.003:1 S

U 8 SR 2 SU 00 SR 10 SU 01 SR 14 SU 02 SR 14 SU 03

S

R 14 SU 04 SR 15 SU 05 SR 15 SU 06 SR 99 SU 07 G

S

TYPE OF TRANSACTION (TOT) 1.004:XXX S

G

DATE (DAT) 1.005:20071120 S

G

PRIORITY (PRY) 1.006:1 S

G

DESTINATION AGENCY IDENTIFIER (DAI) 1.007:DCFBIWA6Z S

G

ORIGINATING AGENCY IDENTIFIER (ORI) 1.008:NY0303000SLAS01000 S

G

TRANSACTION CONTROL NUMBER (TCN) 1.009:1234567890 S

G

TRANSACTION CONTROL REFERENCE (TCR) 1.010:2345678901 S

G
Part 1 ANSI/NIST-ITL 1-2007

125

NATIVE SCANNING RESOLUTION (NSR) 1.011:19.69 S

G

TRANSMITTING RESOLUTION (NTR) 1.012:19.69 S

G

DOMAIN NAME (DOM) 1.013:NORAM S

U

S

G

GREENWICH MEAN TIME (GMT) 1.014:20071120235745Z F

S

Type-2 User-Defined Descriptive Text Record

LENGTH (LEN) 2.001:813 S

G

IMAGE DESIGNATION CHARACTER (IDC) 2.002:00 S

G

USER-DEFINED INFORMATION (793 ASCII TEXT CHARACTERS) F

S

Type-10 Facial / Mugshot Record

LENGTH (LEN) 10.001:14750 S

G

IMAGE DESIGNATION CHARACTER (IDC) 10.002:01 S

G

IMAGE TYPE (IMT) 10.003:FACE S

G

SOURCE AGENCY (SRC) 10.004:NY0303000SLAS01000 S

G

PHOTO DATE (PHD) 10.005:20071120 S

G

HORIZONTAL LINE LENGTH (HLL) 10.006:480 S

G

VERTICAL LINE LENGTH (VLL) 10.007:600 S

G

SCALE UNITS (SLC) 10.008:0 S

G

HORIZONTAL PIXEL SCALE (HPS) 10.009:1 S

G

VERTICAL PIXEL SCALE (VPS) 10.010:1 S

G

COMPRESSION ALGORITHM (CGA) 10.011:JPEGB S

G
Part 1 ANSI/NIST-ITL 1-2007

126

COLOR SPACE (CSP) 10.012:YCC S

G

SUBJECT ACQUISITION PROFILE (SAP) 10.013:30 S

G

SUBJECT POSE (POS) 10.020:D S

G

POSE OFFSET ANGLE (POA) 10.021:-45 S

G

PHOTO DESCRIPTION (PXS) 10.022:HAT S

R GLASSES SG

PHOTO ACQUISITION SOURCE (PAS) 10.023:DIGITAL CAMERA S

G

SUBJECT QUALITY SCORE (SQS) 10.024:88 S

U 000F SU 99 SG

SUBJECT POSE ANGLE (SPA) 10.025:+45 S

U 0 SU 0 SU

S

U

S

U

S

G

SUBJECT FACIAL DESCRIPTION (SXS) 10.026:OPEN MOUTH S

G

SUBJECT EYE COLOR (SEC) 10.027:BLU S

G

SUBJECT HAIR COLOR (SHC) 10.028:BAL S

R GRY SG

FACIAL FEATURE POINTS (FFP) 10.029:1 S

U 12.2 SU 120 SU 130 SR 1 SU 

 12.1 S

U 240 SU 129 SG

IMAGE DATA (DAT) 10.999: 

 SOI & APP0 Marker Segment X'FFD8', X'FFE0', X'0010', X'4A46494600', 

 X'0102', X'00', X'0001', X'0001', X'00', X'00', 

 Compressed Image Data <14382 BYTES FACIAL DATA COMPR. @ 20:1> 

 End Of Image Marker Code X'FFD9' F

S

Type-14 Variable-Resolution Fingerprint 

Image Records

 1ST TYPE-14 RECORD (PLAIN RIGHT FOUR)

LOGICAL RECORD LENGTH (LEN) 14.001:107280 S

G

IMAGE DESIGNATION CHARACTER (IDC) 14.002:02 S

G
Part 1 ANSI/NIST-ITL 1-2007

127

IMPRESSION TYPE (IMP) 14.003:20 S

G

SOURCE AGENCY (SRC) 14.004:NY0303000SLAS01000 S

G

CAPTURE DATE (FCD) 14.005:20071120 S

G

HORIZONTAL LINE LENGTH (HLL) 14.006:1600 S

G

VERTICAL LINE LENGTH (VLL) 14.007:1000 S

G

SCALE UNITS (SLC) 14.008:2 S

G

HORIZONTAL PIXEL SCALE (HPS) 14.009:197 S

G

VERTICAL PIXEL SCALE (VPS) 14.010:197 S

G

COMPRESSION ALGORITHM (CGA) 14.011:WSQ20 S

G

BITS PER PIXEL (BPX) 14.012:8 S

G

FINGER POSITION (FGP) 14.013:13 S

G

FINGERPRINT SEGMENTATION POSITION(S) (SEG) 14.021:2 S

U 125 SU 420 SU 675 SU 1045

S

R 3 SU 430 SU 740 SU 475 SU 900

S

R 4 SU 775 SU 1075 SU 665 SU 1095

S

R 5 SU 1075 SU 1325 SU 1050 SU 1400 SG

NIST QUALITY METRIC (NQM) 14.022:2 S

U 2 SR 3 SU 1 SR 4 SU 1 SR 5 SU 2 SG

IMAGE DATA (DAT) 14.999: <107KB OF DATA COMPRESSED @ 15:1> F

S

 2ND TYPE-14 RECORD (PLAIN LEFT FOUR)

LOGICAL RECORD LENGTH (LEN) 14.001:107282 S

G

IMAGE DESIGNATION CHARACTER (IDC) 14.002:03 S

G

IMPRESSION TYPE (IMP) 14.003:20 S

G

SOURCE AGENCY (SRC) 14.004:NY0303000SLAS01000 S

G
Part 1 ANSI/NIST-ITL 1-2007

128

CAPTURE DATE (FCD) 14.005:20071120 S

G

HORIZONTAL LINE LENGTH (HLL) 14.006:1600 S

G

VERTICAL LINE LENGTH (VLL) 14.007:1000 S

G

SCALE UNITS (SLC) 14.008:2 S

G

HORIZONTAL PIXEL SCALE (HPS) 14.009:197 S

G

VERTICAL PIXEL SCALE (VPS) 14.010:197 S

G

COMPRESSION ALGORITHM (CGA) 14.011:WSQ20 S

G

BITS PER PIXEL (BPX) 14.012:8 S

G

FINGER POSITION (FGP) 14.013:14 S

G

FINGERPRINT SEGMENTATION POSITION(S) (SEG) 14.021:7 S

U 1080 SU 1375 SU 675 SU 1045

S

R 8 SU 760 SU 1070 SU 475 SU 900

S

R 9 SU 425 SU 725 SU 665 SU 1095

S

R 10 SU 175 SU 425 SU 1050 SU 1400 SG

NIST QUALITY METRIC (NQM) 14.022:7 S

U 1 SR 8 SU 2 SR 9 SU 2 SR 10 SU 2 SG

IMAGE DATA (DAT) 14.999: <107KB OF DATA COMPRESSED @ 15:1> F

S

 3RD TYPE-14 RECORD (TWO THUMBS)

LOGICAL RECORD LENGTH (LEN) 14.001:70235 S

G

IMAGE DESIGNATION CHARACTER (IDC) 14.002:04 S

G

IMPRESSION TYPE (IMP) 14.003:20 S

G

SOURCE AGENCY (SRC) 14.004:NY0303000SLAS01000 S

G

CAPTURE DATE (FCD) 14.005:20071120 S

G

HORIZONTAL LINE LENGTH (HLL) 14.006:1600 S

G
Part 1 ANSI/NIST-ITL 1-2007

129

VERTICAL LINE LENGTH (VLL) 14.007:1000 S

G

SCALE UNITS (SLC) 14.008:2 S

G

HORIZONTAL PIXEL SCALE (HPS) 14.009:197 S

G

VERTICAL PIXEL SCALE (VPS) 14.010:197 S

G

COMPRESSION ALGORITHM (CGA) 14.011:WSQ20 S

G

BITS PER PIXEL (BPX) 14.012:8 S

G

FINGER POSITION (FGP) 14.013:15 S

G

FINGERPRINT SEGMENTATION POSITION(S) (SEG) 14.021:11 S

U 415 SU 745 SU 1025 SU 1450

S

R 12 SU 750 SU 1080 SU 1025 SU 1450 SG

NIST QUALITY METRIC (NQM) 14.022:11 S

U 2 SR 12 SU 1 SG

IMAGE DATA (DAT) 14.999: <70KB OF DATA COMPRESSED @ 15:1> F

S

Type-15 Variable-Resolution Palmprint 

Records

 1ST TYPE-15 RECORD (FULL RIGHT PALM)

LENGTH (LEN) 15.001:733170 S

G

IMAGE DESIGNATION CHARACTER (IDC) 15.002:05 S

G

IMPRESSION TYPE (IMP) 15.003:20 S

G

SOURCE AGENCY (SRC) 15.004:NY0303000SLAS01000 S

G

PALMPRINT CAPTURE DATE (PCD) 15.005:20071120 S

G

HORIZONTAL LINE LENGTH (HLL) 15.006:2750 S

G

VERTICAL LINE LENGTH (VLL) 15.007:4000 S

G

SCALE UNITS (SLC) 15.008:2 S

G
Part 1 ANSI/NIST-ITL 1-2007

130

HORIZONTAL PIXEL SCALE (HPS) 15.009:197 S

G

VERTICAL PIXEL SCALE (VPS) 15.010:197 S

G

COMPRESSION ALGORITHM (CGA) 15.011:WSQ20 S

G

BITS PER PIXEL (BPX) 15.012:8 S

G

PALMPRINT POSITION (PLP) 15.020:21 S

G

IMAGE DATA (DAT) 15.999: <733KB OF DATA COMPRESSED @ 15:1> F

S

2ND TYPE-15 RECORD (RIGHT WRITER’S PALM)

LENGTH (LEN) 15.001:146169 S

G

IMAGE DESIGNATION CHARACTER (IDC) 15.002:06 S

G

IMPRESSION TYPE (IMP) 15.003:20 S

G

SOURCE AGENCY (SRC) 15.004:NY0303000SLAS01000 S

G

PALMPRINT CAPTURE DATE (PCD) 15.005:20071120 S

G

HORIZONTAL LINE LENGTH (HLL) 15.006:876 S

G

VERTICAL LINE LENGTH (VLL) 15.007:2500 S

G

SCALE UNITS (SLC) 15.008:2 S

G

HORIZONTAL PIXEL SCALE (HPS) 15.009:197 S

G

VERTICAL PIXEL SCALE (VPS) 15.010:197 S

G

COMPRESSION ALGORITHM (CGA) 15.011:WSQ20 S

G

BITS PER PIXEL (BPX) 15.012:8 S

G

PALMPRINT POSITION (PLP) 15.020:22 S

G

IMAGE DATA (DAT) 15.999: <146KB OF DATA COMPRESSED @ 15:1> F

S
Part 1 ANSI/NIST-ITL 1-2007

131

Type-99 CBEFF Data Record

LENGTH (LEN) 99.001:100144 S

G

IMAGE DESIGNATION CHARACTER (IDC) 99.002:07 S

G

SOURCE AGENCY (SRC) 99.004: NY0303000SLAS01000 S

G

BIOMETRIC CAPTURE DATE (BCD) 99.005:20071120 S

G

CBEFF HEADER VERSION (HDV) 99.100:0101 S

G

BIOMETRIC TYPE (BTY) 99.101:00002000 S

G

BIOMETRIC DATA QUALITY (BDQ) 99.102:89 S

U 9999 SU 99 SG

BDB FORMAT OWNER (BFO) 99.103:001B S

G

BDB FORMAT TYPE (BFT) 99.104:ABCD S

G

BIOMETRIC DATA BLOCK (BDB) 99.999: <100KB OF DATA > F

S
Part 1 ANSI/NIST-ITL 1-2007

132

Annex G INCITS / M1 378 Minutiae Format 

(Informative) 

Minutia placement and type 

For templates to be conformant with Section 5 of the ANSI INCITS 378-2004 standard, the 

following method, which enhances the current INCITS 378-2004 standard, shall be used for 

determining placement (location and angular direction) of individual minutiae. 

The position or location of a minutia representing a ridge ending shall be the point of forking of 

the medial skeleton of the valley area immediately in front of the ridge ending. If the three legs of 

the valley area were thinned down to a single-pixel-wide skeleton, the point of the intersection is 

the location of the minutia. Similarly, the location of the minutia for a bifurcation shall be the point 

of forking of the medial skeleton of the ridge. If the three legs of the ridge were each thinned 

down to a single-pixel-wide skeleton, the point where the three legs intersect is the location of the 

minutia. 

After all ridge endings have been converted to bifurcations, all of the minutiae of the fingerprint 

image are represented as bifurcations. The X and Y pixel coordinates of the intersection of the 

three legs of each minutia can be directly formatted. Determination of the minutia direction can 

be extracted from each skeleton bifurcation. The three legs of every skeleton bifurcation must be 

examined and the endpoint of each leg determined. Figure G1 illustrates the three methods used 

for determining the end of a leg that is based on a scanning resolution of 500 ppi. The ending is 

established according to the event that occurs first. The pixel count is based on a scan resolution 

of 500 ppi. Different scan resolutions would imply different pixel counts. 

• A distance of .064” (the 32nd pixel) 

• The end of skeleton leg that occurs between a distance of .02” and .064” (the 10th through the 

32nd pixels); shorter legs are not used 

• A second bifurcation is encountered within a distance of .064” (before the 32nd pixel) 

Figure G1 Minutiae angle components 

32 pixels 

<32 pixels 32 pixels

32 pixels
Part 1 ANSI/NIST-ITL 1-2007

133

The angle of the minutiae is determined by constructing three virtual rays originating at the 

bifurcation point and extending to the end of each leg. The smallest of the three angles formed 

by the rays is bisected to indicate the minutiae direction. 

Coordinate system 

The coordinate system used to express the minutiae of a fingerprint shall be a Cartesian 

coordinate system. Minutiae locations shall be represented by their x and y coordinates. The 

origin of the coordinate system shall be the upper left corner of the original image with x

increasing to the right and y increasing downward. Both x and y coordinates of a minutiae shall 

be represented in pixel units from the origin. It should be noted that the location of the origin and 

units of measure is not in agreement with the convention used in the “standard format” definitions 

of Section14.1. 

Minutiae direction 

Angles are expressed in standard mathematical format, with zero degrees to the right and angles 

increasing in the counterclockwise direction. Recorded angles are in the direction pointing back 

along the ridge for a ridge ending and toward the center of the valley for a bifurcation. This 

convention is 180 degrees opposite of the angle convention described in the “standard format” 

definitions of Section 14.1.4. 

Fields for Type-9 logical record INCITS-378 Format 

For purposes of this standard, no proprietary information shall be contained in any of the 

information and data specified by the M1-378 block of information items. Therefore, the following 

descriptions are presented for each of the fields in this Type-9 block. All fields of the Type-9 

records shall be recorded as ASCII text. No binary fields are permissible in this tagged-field 

record. The first four fields are mandatory and retain the same meaning a described in Sections 

14.2.1 through 14.2.4. 

Field 9.001: Logical record length (LEN) 

This mandatory ASCII field shall contain the length of the logical record specifying the total 

number of bytes, including every character of every field contained in the record. 

Field 9.002: Image designation character (IDC) 

This mandatory field shall be used for the identification and location of the minutiae data. The 

IDC contained in this field shall match the IDC found in the file content (CNT) field of the Type-1 

record. 

Field 9.003: Impression type (IMP) 

This mandatory one- or two-byte ASCII field shall describe the manner by which the fingerprint or 

palmprint image information was obtained. The ASCII value of the proper code as selected from 

Table 11 shall be entered in this field to signify the impression type. 

Field 9.004: Minutiae format (FMT) 

This field shall contain a "U" to indicate that the minutiae are formatted in M1-378 terms. Even 

though information may be encoded in accordance with the M1-378 standard, all data fields of the 

Type-9 record must remain as ASCII text fields. 

Field 9.126: CBEFF information 
Part 1 ANSI/NIST-ITL 1-2007

134

This mandatory field shall contain three information items. The first information item shall contain 

the value "27". This is the identification of the CBEFF Format Owner assigned by the 

International Biometric Industry Association (IBIA) to INCITS Technical Committee M1. The “US” 

character shall delimit this item from the CBEFF Format Type that is assigned a value of "513" to 

indicate that this record contains only location and angular direction data without any Extended 

Data Block information. A value of “514” indicates the presence of extended data. The “US” 

character shall delimit this item from the CBEFF Product Identifier (PID) that identifies the "owner" 

of the encoding equipment. The vendor establishes this value. It can be obtained from the IBIA 

website (www.ibia.org) if it is posted. 

Field 9.127: Capture equipment identification 

This mandatory field shall contain two information items separated by the “US” character. The 

first shall contain "APPF" if the equipment used originally to acquire the image was certified to 

conform with Appendix F (IAFIS Image Quality Specification, January 29, 1999) of CJIS-RS0010, the Federal Bureau of Investigation's Electronic Fingerprint Transmission Specification. If 

the equipment did not conform it will contain the value of "NONE". The second information item 

shall contain the Capture Equipment ID which is a vendor-assigned product number of the 

capture equipment. A value of "0" indicates that the capture equipment ID is unreported. 

Field 9.128: Horizontal line length (HLL) 

This mandatory ASCII field shall contain the number of pixels contained on a single horizontal line 

of the transmitted image. The maximum horizontal size is limited to 65,534 pixels. 

Field 9.129: Vertical line length (VLL) 

This mandatory ASCII field shall contain the number of horizontal lines contained in the 

transmitted image. The maximum vertical size is limited to 65,534 pixels. 

Field 9.130: Scale units (SLC) 

This mandatory ASCII field shall specify the units used to describe the image sampling frequency 

(pixel density). A "1" in this field indicates pixels per inch, or a "2" indicates pixels per centimeter. 

A "0" in this field indicates no scale is given. For this case, the quotient of HPS/VPS gives the 

pixel aspect ratio. 

Field 9.131: Horizontal pixel scale (HPS) 

This mandatory ASCII field shall specify the integer pixel density used in the horizontal direction 

providing the SLC contains a "1" or a "2". Otherwise, it indicates the horizontal component of the 

pixel aspect ratio. 

Field 9.132: Vertical pixel scale (VPS) 

This mandatory ASCII field shall specify the integer pixel density used in the vertical direction 

providing the SLC contains a "1" or a "2". Otherwise, it indicates the vertical component of the 

pixel aspect ratio. 

Field 9.133: Finger view 

This mandatory field contains the view number of the finger associated with this record's data. 

The view number begins with "0" and increments by one to "15". 

Field 9.134: Finger position 
Part 1 ANSI/NIST-ITL 1-2007

135

This mandatory field shall contain the code designating the finger position that produced the 

information in this Type-9 record. A code between 1 and 10 taken from Table 12 shall be used to 

indicate the finger position. 

Field 9.135: Finger quality 

This mandatory field shall contain the quality of the overall finger minutiae data. 

Each subfield shall contain three information items separated by the "US" separator character. 

They identify a quality score and the algorithm used to create the quality score. This information 

is useful to enable the recipient of the quality score to differentiate between quality scores 

generated by different algorithms and adjust for any differences in processing or analysis as 

necessary. 

1. The first 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 

image quality score between 0 and 100 assigned to the image data by a quality algorithm. Higher 

values indicate better quality. An entry of “255” shall indicate a failed attempt to calculate a quality 

score. An entry of “254” shall indicate that no attempt to calculate a quality score was made. The 

use of additional values to convey other information should be harmonized with ISO/IEC 19794 

standards. 

2. The second information item shall specify the ID of the vendor of the quality algorithm 

used to calculate the quality score. This 4-digit hex value is assigned by IBIA and expressed as 

four ASCII characters. The IBIA shall maintain the Vendor Registry of CBEFF Biometric 

Organizations that will map the value in this field to a registered organization. 

3. The third information item shall specify a numeric product code assigned by the vendor of 

the quality algorithm, which may be registered with the IBIA, but it is not required to be registered. 

It indicates which of the vendor’s algorithms was used in the calculation of the quality score. This 

field contains the ASCII representation of the integer product code and should be within the range 

1 to 65535. 

Field 9.136: Number of minutiae 

The mandatory field shall contain a count of the number of minutiae recorded in this logical 

record. 

Field 9.137: Finger minutiae data 

This mandatory field has six information items separated by the “US” character. It consists of 

several subfields, each containing the details for a single minutiae. The total number of minutiae 

subfields must agree with the count found in field 136. The first information item is the minutiae 

index number, which shall be initialized to “1” and incremented by “1” for each additional minutia 

in the fingerprint. The second and third information items are the 'x' coordinate and 'y' 

coordinates of the minutiae in pixel units. The fourth information item is the minutiae angle 

recorded in units of two degrees. This value shall be nonnegative between 0 and 179. The fifth 

information item is the minutiae type. A value of "0" is used to represent a minutiae of type 

"OTHER", a value of "1" for a ridge ending and a value of "2" for a ridge bifurcation. The sixth 

information item represents the quality of each minutiae. This value shall range from 1 as a 

minimum to 100 as a maximum. A value of "0" indicates that no quality value is available. Each 

subfield shall be separated from the next with the use of the “RS” separator character. 

Field 9.138: Ridge count information 
Part 1 ANSI/NIST-ITL 1-2007

136

This field shall consists of a series of subfields each containing three information items. The first 

information item of the first subfield shall indicate the ridge count extraction method. A “0” 

indicates that no assumption shall be made about the method used to extract ridge counts, nor 

their order in the record. A “1” indicates that for each center minutiae, ridge count data was 

extracted to the nearest neighboring minutiae in four quadrants, and ridge counts for each center 

minutia are listed together. A “2” indicates that for each center minutiae, ridge count data was 

extracted to the nearest neighboring minutiae in eight octants, and ridge counts for each center 

minutia are listed together. The remaining two information items of this first subfield shall each 

contain “0”. Information items shall be separated by the “US” separator character. Subsequent 

subfields will contain the center minutiae index number as the first information item, the 

neighboring minutiae index number as the second information item, and the number of ridges 

crossed as the third information item. Subfields shall be separated by the “RS” separator 

character. 

Field 9.139: Core information 

This field will consist of one subfield for each core present in the original image. Each subfield 

consists of three information items. The first two items contains the ‘x’ and ‘y’ coordinate 

positions in pixel units. The third information item contains the angle of the core recorded in units 

of 2 degrees. The value shall be a nonnegative value between 0 and 179. Multiple cores will be 

separated by the “RS” separator character. 

Field 9.140: Delta information 

This field will consist of one subfield for each delta present in the original image. Each subfield 

consists of three information items. The first two items contains the ‘x’ and ‘y’ coordinate 

positions in pixel units. The third information item contains the angle of the delta recorded in units 

of 2 degrees. The value shall be a nonnegative value between 0 and 179. Multiple cores will be 

separated by the “RS” separator character. 
Part 1 ANSI/NIST-ITL 1-2007

137

Annex H Best Practice Application Level 30 

(Informative) 

BEST PRACTICE RECOMMENDATION 

FOR THE CAPTURE OF MUGSHOTS 

Version 2.0 

September 23, 1997 

The original version of the •Best Practice Recommendation• was initiated at the Mugshot and Facial 

Image Workshop which was held in Gaithersburg, MD on October 23-25, 1995. Developed as a 

recommendation, the implementation of the practices and principles described in that document makes the 

conversion of existing and ongoing photographic collections more uniform. It contains a suggested set of 

procedures and equipment specifications for organizations considering the purchase of new systems or the 

upgrade of current systems. The recommendation is not designed to render current and legacy mugshot 

collections unacceptable. Rather, it is intended as a means of establishing or improving interoperability 

between mugshot systems. 

The information contained in this updated revision of the •Best Practice Recommendation•, Version 2.0, 

does not alter any of the individual points that were consensually agreed upon and included in the original 

version of this recommendation. It does provide additional details and clarifications for many of those 

points and has been supplemented with information regarding depth-of-field and exposure considerations. 

This recommendation reflects a minimum set of common denominators. The provisions of this 

recommendation are keyed to the quality aspects associated with the unaltered captured mugshot image. 

For new mugshot images being captured, the specifications contained in this recommendation are equally 

applicable to realtime electronic capture of mugshots as well as the electronic conversion of photographic 

images. For conversion of legacy files of photographs, most of the provisions of this recommendation are 

also still applicable. In the future, it should be possible to add additional specifications without 

contradicting any of the current contents of the recommendation. 

* POSE 

The full-face or frontal pose is the most commonly used pose in photo lineups and shall always be 

captured. This pose is in addition to profiles or intermediate angled poses captured to acquire 

perspective and other information. For subjects who normally wear eyeglasses, a frontal mugshot 

image should be captured of the subject without glasses. This is required due to the glare from 

exernal illumination. An additional image can optionally be captured of the subject wearing 

eyeglasses. 
Part 1 ANSI/NIST-ITL 1-2007

138

* DEPTH OF FIELD 

The subject•s captured facial image shall always be in focus from the nose to the ears. Although 

this may result in the background behind the subject being out of focus, it is not a problem. For 

optimum quality of the captured mugshot, the f-stop of the lens should be set at two f-stops below 

the maximum aperture opening when possible. 

* CENTERING 

The facial image being captured (full-face pose) shall be positioned to satisfy all of the following 

conditions: 

- The approximate horizontal mid-points of the mouth and of the bridge of the nose shall 

lie on an imaginary vertical straight line positioned at the horizontal center of the image. 

- An imaginary horizontal line through the center of the subject's eyes shall be located at 

approximately the 55% point of the vertical distance up from the bottom edge of the 

captured image. 

- The width of the subject's head shall occupy approximately 50% of the width of the 

captured image. This width shall be the horizontal distance between the mid-points of 

two imaginary vertical lines. Each imaginary line shall be drawn between the upper and 

lower lobes of each ear and shall be positioned where the external ear connects to the 

head. 

* LIGHTING 

Subject illumination shall be accomplished using a minimum of three (3) point balanced 

illumination. Appropriate diffusion techniques shall also be employed and lights positioned to 

minimize shadows, and to eliminate hot spots on the facial image. These hot spots usually appear 

on reflective areas such as cheeks and foreheads. Proper lighting shall contribute to the uniformity 

of illumination of the background described in the exposure requirement. 

* BACKGROUND 

The subject whose image is being captured shall be positioned in front of a background which is 

18% gray with a plain smooth flat surface. A Kodak or other neutral gray card or densitometer 

shall be used to verify this 18% gray reflectance requirement. 

* EXPOSURE 

The exposure shall be keyed to the background. Several areas of the recorded 18% gray 

background shall be used to verify the proper exposure. The averages of the 8-bit Red, Green, 

and Blue (RGB) components within each area shall be calculated. Each of the RGB means shall 

fall between 105 and 125 with a standard deviation of plus or minus 10. Furthermore, for every 

area examined, the maximum difference between the means of any two of the RGB components 

shall not exceed 10. 

* ASPECT RATIO 

The Width:Height aspect ratio of the captured image shall be 1:1.25. 
Part 1 ANSI/NIST-ITL 1-2007

139

* MINIMUM NUMBER OF PIXELS 

The minimum number of pixels in an electronic digital image shall be 480 pixels in the horizontal 

direction by 600 pixels in the vertical direction. It should be noted that the image quality of the 

captured mugshots and facial images will be improved as the number of pixels in both directions 

are increased. However, as images are captured with an increased number of pixels, the 1:1.25 

(Width:Height) aspect ratio will be maintained. 

Two considerations must be noted regarding this aspect of the recommendation. First, the normal 

orientation of many available cameras is the landscape format which specifies a greater number of pixels in 

the horizontal than in the vertical direction. Unless these cameras capture at least 600 pixels in the vertical 

direction, it may be necessary to rotate the camera 90 degrees. Second, the 480x600 capture format 

exceeds the VGA display format of 640x480. Therefore, at a minimum, an SVGA specification of 

800x600 pixels will be required to display the facial image. The image will occupy less than the total 

number of available horizontal pixels. 

* COLOR SPACE 

Captured electronic color facial images are required. Digital images shall be represented as 24-bit 

RGB pixels. For every pixel, eight (8) bits will be used to represent each of the Red, Green, and 

Blue components. The RGB color space is the basis for other color spaces including the Y, Cb, Cr

and YUV. Additional color management techniques are available from the International Color 

Consortium. Information regarding these techniques can be downloaded from the following URL: 

http://www.color.org . 

* PIXEL ASPECT RATIO 

Digital cameras and scanners used to capture facial images shall use square pixels with a pixel 

aspect ratio of 1:1. 

* COMPRESSION ALGORITHM 

The algorithm used to compress mugshot and facial images shall conform to the JPEG Sequential 

Baseline mode of operation as described in the specification approved by the ANSI X3L3 

Standards committee. The target size for a JPEG compressed color mugshot image file shall be 

25,000 to 45,000 bytes. 

* FILE FORMAT 

The JPEG File Interchange Format (JFIF) shall contain the JPEG compressed image data. The 

JFIF file shall then be part of the transaction file for interchange which conforms to the 

requirements as contained in ANSI/NIST-CSL 1-1993 and ANSI/NIST-ITL 1a-1997. 
Part 1 ANSI/NIST-ITL 1-2007

140

Annex I Best Practice Image Capture Requirements for SAP Levels 40, 50, and 51 

(Informative) 

Introduction 

This set of “enhanced best practice recommendation” (EBPR) clauses is a set of constraints. 

These constraints can be categorized into four types of requirements: scene, photographic, 

digital, and format. Scene requirements refer to the content, subject and background in the 

image. Photographic requirements refer to lighting, focus and other constraints required for photo 

capture. Digital requirements refer to the conversion of the captured image into a digital record. 

Finally, format requirements refer to additional or conditional required fields and in a Type-10 

record or NIST transaction. 

Note that the set of requirements applies to all poses of a subject. 

Scene Requirements 

Number of photographs

Level 50 and 51 records shall include at least five photographs of the subject: frontal, left and 

right profile, and left and right 3⁄4 profile. 

A 3⁄4 profile view consists of a face with a Yaw pose angle of ± 67.5 degrees, and with Pitch and 

Roll angles of zero (see Section 15.1.23, “Field 10.025: Subject pose angle (SPA)”). Note that for 

3⁄4 profile, the orientation of the head is rotated to 3⁄4 profile (the rotation of the body shall not be 

required), and care should be taken to prevent the subject from keeping the head fixed while 

changing only the gaze. In addition, for 3⁄4 profile photographs, both eyes must be visible in the 

image. For full profile images, the entire body shall be rotated with the head. 

The “Head and Shoulders” photo composition

The composition consists of a subject’s head, partial shoulders, and plain background. For a 

frontal-facing pose, the width of the subject's head shall occupy approximately 50% of the width 

of the captured image. This width shall be the horizontal distance between the mid-points of two 

imaginary vertical lines. Each imaginary line shall be drawn between the upper and lower lobes of 

each ear and shall be positioned where the external ear connects to the head. A template and an 

example is shown in Figure I1. For other poses, the composition shall be rotated about an 

imaginary axis extending from the top of the head though the base of the neck. 

This composition is applied to SAP levels 30, 40, and 50. 
Part 1 ANSI/NIST-ITL 1-2007

141

a. A template of the “head and 

shoulders” photo. The width of the 

head is 1⁄2 the width of the photo. 

b. An example “head and 

shoulders” photo. 

Figure I1 – A facial image template and an example image that meets “Head and 

Shoulders” (levels 40 and 50) scene constraints. 

The “Head Only” photo composition 

The composition consists of a subject’s head, and a plain background. For a frontal-facing pose, 

the width of the subject's head shall occupy approximately 70% of the width of the captured 

image. This width shall be the horizontal distance between the mid-points of two imaginary 

vertical lines. Each imaginary line shall be drawn between the upper and lower lobes of each ear 

and shall be positioned where the external ear connects to the head. A template and an example 

are shown in Figure I2. For other poses, the composition shall be rotated about an imaginary 

axis extending from the top of the head though the base of the neck. 

This composition is applied to SAP level 51. 
Part 1 ANSI/NIST-ITL 1-2007

142

a. A template of the “head only” 

photo. The width of the head is 7/10th

the width of the photo. 

b. An example “head only” 

photo. 

Figure I2 – A facial image template and an example image that meets “Head Only” (level 

51) scene constraints. 

Head centering

For the frontal pose, the face shall be positioned to satisfy all of the following conditions: 

The approximate horizontal mid-points of the mouth and of the bridge of the nose shall lie on an 

imaginary vertical straight line positioned at the horizontal center of the image. 

An imaginary horizontal line through the center of the subject's eyes shall be located at 

approximately the 55% point of the vertical distance up from the bottom edge of the captured 

image. 

For non-frontal pose, the subject shall satisfy these conditions when the head is rotated about an 

axis though the head and torso from the current pose back to center (zero angles) pose. 

Visibility of Ears

The ear(s) shall be visible in frontal, profile and angled views for both “Head and Shoulders” and 

“Head Only” scene compositions. The hair shall be pushed back or tied behind the ears when 

appropriate. 

From the 50/51 level description:

If hair covers the ears, then when possible, two photographs should be captured – one with hair 

in its normal state, and one with hair pulled back behind the ears. 
Part 1 ANSI/NIST-ITL 1-2007

143

Facial expression

The expression should be neutral (non-smiling) with both eyes open normally (i.e. not wide-open), 

and mouth closed. Every effort should be made to have supplied images conform with this 

specification. A smile with closed jaw is not recommended. 

Eyeglasses

For subjects who normally wear eyeglasses, every effort should be made to capture the 

mugshots with the glasses on. If significant glare in the glasses is evident in the photograph, then 

a second frontal mugshot image should be captured of the subject without glasses. Specification 

of eyeglasses in the SXS field is required. 

Eye patches

The wearing of eye patches is allowed only for medical reasons. In these cases, the specification 

of the patch, in the SXS field is required. 

Background

The subject whose image is being captured shall be positioned in front of a background which is 

18% gray with a plain smooth flat surface. A Kodak or other neutral gray card or densitometer 

shall be used to verify this 18% gray reflectance requirement. 

The boundary between the head and the background should be clearly identifiable about the 

entire subject (very large volume hair excepted). There should be no shadows visible on the 

background behind the face image. 

Photographic Requirements 

Depth of field

The subject's captured facial image shall always be in focus from the nose to the ears. Although 

this may result in the background behind the subject being out of focus, this is not a problem14. It 

is recommended that auto-focus on the central part of face be used with digital camera 

photography. 

Subject lighting 

Lighting shall be equally distributed on the face. There shall be no significant direction of the light 

from the point of view of the photographer. 

The region of the face, from the crown to the base of the chin, and from ear-to-ear, shall be 

clearly visible and free of shadows. In particular, there shall be no dark shadows in the eyesockets due to the brow and the iris and pupil of the eyes shall be clearly visible. 

Subject illumination can be accomplished using three point balanced illumination sources. A 

single bare “point” light source, such as a camera flash, is not acceptable for imaging. 

 

14 For optimum quality of the captured mugshot, the f-stop of the lens should be set at two f-stops below the maximum 

aperture opening when possible. 
Part 1 ANSI/NIST-ITL 1-2007

144

Appropriate diffusion techniques shall be employed to eliminate hot spots on the facial image. 

These hot spots usually appear on reflective areas such as cheeks and foreheads. 

Background lighting 

Proper lighting shall contribute to the uniformity of illumination of the background, and the 

background shall be free of shadows. 

Exposure calibration

The exposure shall be keyed to the background. Several areas of the recorded 18% gray 

background shall be used to verify the proper exposure. The averages of the 8-bit Red, Green, 

and Blue (RGB) components within each area shall be calculated. Each of the RGB means shall 

fall between 105 and 125 with a standard deviation of plus or minus 10. Furthermore, for every 

area examined, the maximum difference between the means of any two of the RGB components 

shall not exceed 10. 

No saturation 

For each patch of skin on the person’s face, the gradations in textures shall be clearly visible. In 

this sense, there will be no saturation (over or under exposure) on the face. 

No unnatural color or “red-eye”

Unnaturally colored lighting (e.g. yellow, red) is not allowed. Care shall be taken to correct the 

"white balance" of image capture devices. The lighting shall produce a face image with natural 

looking flesh tones when viewed in typical examination environments. “Red-eye” is not 

acceptable. 

No color or grayscale enhancement

A process that overexposes or under-develops a color or grayscale image for purposes of beauty 

enhancement or artistic pleasure is not allowed. The full spectrum shall be represented on the 

face image where appropriate. Teeth and whites of eyes shall be clearly light or white (when 

appropriate) and dark hair or features (when appropriate) shall be clearly dark. 

No unnatural radial distortion of the camera lens, resulting in a diagonal angle of view of 

approximately 20 to 28 degrees 

Fish eye effect, a type of distortion where central objects of the image erroneously appear closer 

than those at the edge, typically resulting in what appear to be unusually large noses in the 

image, is not allowed. While some distortion is almost always present during portrait photography, 

that distortion should not be noticeable by human examination. 

For a typical photo capture system with a subject 1.5 to 2.5 meters from the camera, the focal 

length of the camera lens should be that of a medium telephoto lens. For 35 mm photography 

this means that the focal length should be between 90 mm and 130 mm. For other negative 

formats/sensors the recommended focal length is 2 to 3 times the diagonal of the negative/sensor 

Digital Requirements 

Pixel aspect ratio 

Digital cameras and scanners used to capture facial images shall use square pixels with a pixel 

aspect ratio of 1:1 
Part 1 ANSI/NIST-ITL 1-2007

145

Image aspect ratio 

The Width:Height (i.e., HLL:VLL) aspect ratio of the captured image shall be 3:4. This 

corresponds to commonly used format sizes such as 600 x 800, 768x1024, etc., allowing for a 

COTS digital camera to be used for capture. 

No interlacing

Interlaced video frames are not allowed and all interlacing must be absent (not simply removed, 

but absent). 

No digital zoom

The use of digital zoom (interpolation) to achieve specified resolution associated with Subject 

Application Profiles. 

Image Compression 

Non-frontal facial images shall be compressed using JPEG 2000 (JPEG is not allowed) meeting 

the maximum compression limits specified below. 

There shall be one frontal facial image compressed using lossless JPEG 2000. If multiple frontal 

images are in the transaction, then one image must be compressed via lossless compression and 

the others can be compressed either using lossless JPEG 2000 or lossy JPEG 2000 that meets 

the maximum compression limits specified below. The best practice is to apply the lossless 

compression to the frontal image meeting the “Ears Visible” constraint. 

The maximum compression ratio for both JPEG and JPEG 2000 of a rectangular region 

containing any exposed skin of the face, from crown to chin and ear to ear, shall be at most 15:1. 

This requirement is derived from studies of face algorithm matching at high and low resolutions. 

The non-facial portion of the mugshot, as well as the SMT Type-10 record, can be compressed 

up to a ratio of 120:1. 

For JPEG, reference [14] provides source code to implement compression with both ROI and 

fixed compression ratios. For JPEG 2000, these capabilities are built into the implementation. 

For both JPEG and JPEG 2000, care must be taken to account for automatic compression by 

camera hardware. Multiple compression stages can damage the quality of photographic data. 

When possible, minimum compression (highest resolutions) should be applied at the camera 

level when external software performs the final (15:1 or less) compression stage. 

The table on the following page provides the the typical size of a single facial photograph using 

the compression recommendations contained in this section for levels 30 and 40, 50, and 51. . 

We assume that the image is formated as RGB888 (8 bits per color chanel per pixel). For levels 

30 and 40, we also estimate that since the face width is 50% of the image width, then the area 

taken by the face is 25% of the total image area. SAP levels 50 and 51 include the constraint of 

lossless compression for the frontal pose facial image as discussed above. 

Allowed color space

A full color image shall be captured. To ensure that color images exchanged between differing 

systems can be correctly displayed or printed, images shall be converted to the deviceindependent color space, sRGB. 
Part 1 ANSI/NIST-ITL 1-2007

146

Example File Sizes after compression 

Level Minimum WxH Uncompressed 

Size (RGB888) 

Size @ 2:1 

Lossless 

Compression 

Size @ 15:1 

compression for 

the entire image 

Size @ 15:1 

compression for the 

face and 120:1 for 

the background 

30 480x600 844 KB 58 KB 19.34 KB 

40 768x1024 2.3 MB 156 KB 52.8 KB 

50 3300x4400 42.5MB 14.2 MB 

51 2400x3200 22.5 MB 7.5 MB 

Format Requirements 

Subject Pose (POS) and Subject pose angles (SPA) 

One of either the POS or SPA fields shall be used to denote pose angles. 

The POS field code values “F”, “R”, and “L” can be used for images in which the Pitch and Roll 

angles are 0 and the Yaw angle is 0, 90, and -90 respectively. (The sign of the Yaw angle in the 

previous sentence corresponds to the field 10.020 convention where a right profile is when the 

subject turns to the left). 

The SPA field 10.025 can be used for the above poses and shall be used for all other angled 

poses. The POS field 10.020 shall then be of type code “D”, for determined 3D pose, instructing 

the user to use 10.025 as the reference for pose angles. (For example, a 3⁄4 profile capture would 

require a POS field entry of “D” with the angle specified in the SPA field.) 

In all cases, the uncertainty in the Yaw pose angle determination shall be less than 5 degrees of 

the frontal photograph, and 10 degrees in the non-frontal photographs. The uncertainty in the 

Pitch and Roll angles shall be less than 5 degrees. 

Subject facial description (SXS)

The Subject facial description field shall be present in the transaction when one or more of the 

facial attributes given by the type codes of 10.026 is present in the image. 

Subject hair color (SHC)

The Subject hair color field shall be present in the transaction. The code “UNSPECIFIED” for this 

field is not allowed. 

Subject eye color (SEC)

The Subject eye color field shall be present in the transaction. The code “UNSPECIFIED” for this 

field is not allowed. 
Part 1 ANSI/NIST-ITL 1-2007

147

Annex J Face-Pose Values 

(Informative) 

The definition and range of pose angles 

The Yaw and Roll angles shall be measured from the full face pose position and have a range of 

values from -180 degrees to +180 degrees. The Pitch angle shall have a range of values from -90 

degrees to +90 degrees. The pose angle set is given by Tait-Bryan angles. 

Yaw angle: rotation about the vertical (y) axis. A positive Yaw angle is used to express the 

angular offset as the subject rotates from a full-face pose to their left (approaching a right profile). 

A negative Yaw angle is used to express the angular offset as the subject rotates from a full-face 

pose to their right (approaching a left profile). 

Pitch angle: rotation about the horizontal side-to-side (x) horizontal axis. 

Roll angle: rotation about the horizontal back to front (z) axis. 

The angles are defined relative to the frontal view of the subject, which has angles (0, 0, 0) as 

shown in Figure J1. Examples are shown in Figure J2. 

Figure J1 – The definition of pose angle set is with respect to the frontal view of the 

subject. 
Part 1 ANSI/NIST-ITL 1-2007

148

A B C d e f g 

Figure J2 – Examples of pose angles and their encodings. The pose angles (Y, P, R) of 

Figures (a) – (g) are given by (0, 0, 0), (+45, 0, 0), (-45, 0, 0), (0, -45, 0), (0, +45, 0), (0, 0, -45), 

and (0, 0, +45), respectively. 

The uncertainty in the pose angles is given by the range 0 to 90 inclusive. It shall denote 

approximately a maximum value of possible deviation in the measurement of the pose. This shall 

correspond to a two standard deviation confidence interval. 

The encoding of angles is in ASCII format, with the minus sign “-“ used to denote a negative 

value and the plus “+” sign optionally used to denote a positive value. Pose angle uncertainty 

angles always are positive. 

The order of rotation through pose angles 

As order of the successive rotation around the different axes does matter, the encoded rotation 

angle shall correspond to an order of execution starting from the frontal view. This order shall be 

given by Roll (about the front axis), then Pitch (about the horizontal axis) and finally Yaw (about 

the vertical axis). The (first executed) Roll transformation will therefore always be in the image (x, 

y) plane. Examples are shown in Figure J3. 

From the point of view of executing a transformation from the observed view to a frontal view, the 

transformation order will therefore be Yaw, Pitch, and then Roll. Note however that the encoded 

angle is from the frontal view to the observed view.
Part 1 ANSI/NIST-ITL 1-2007

149

 (Y, P, R)=(0, 0, +45) (Y, P, R)=(0,-30, +45) (Y, P, R)=(-45, -30, +45) 

A B c 

(Y, P, R)=(0, 0, -30) (Y, P, R)=(0, +20, -30) (Y, P, R)=(-30, +20, -30) 

D E F 

Figure J3 – Examples of the order of rotation through pose angles with an origin of 

coordinate system at the nose tip. Figures (a)-(c) show three successive rotation steps to 

achieve the pose angles (Y, P, R) of (-45, -30, +45). Figures (d)-(f) show three successive 

rotation steps to achieve the pose angles (Y, P, R) of (-30, +20, -30). 
Part 1 ANSI/NIST-ITL 1-2007

150

Annex K Bibliography 

(Informative) 

AAMVA, Personal Identification – AAMVA International Specification – DL/ID Card Design, March 

2005. 

ANSI INCITS 379-2004, Iris Image Interchange Format. 

ANSI INCITS 385-2004, Face Recognition Format for Data Interchange. 

ISO/IEC 19794-5 Information technology - Biometric data interchange formats - Part 5: Face 

image data. 

ISO/IEC 19794-6 Information technology - Biometric data interchange formats - Part 6: Iris image 

data. 

NIST SP 800-76, Biometric Data Specification for Personal Identity Verification, February 2006.