ANSI/NIST-ITL 1-2000 Information Systems-Data Format for the Interchange of Fingerprint, Facial, & Scar Mark & Tattoo (SMT) Information

Information Technology:
American National Standard for
Information Systems—
Data Format for the Interchange of
Fingerprint, Facial, & Scar Mark & Tattoo
(SMT) Information
NIST Special Publication 500-245 ANSI/NIST-ITL 1-2000
Revision of
ANSI/NIST-CSL 1-1993 &
ANSI/NIST-ITL 1a-1997
NIST Special Publication 500-245
Information Technology:
American National Standard for
Information Systems—
Data Format for the Interchange of
Fingerprint, Facial, & Scar Mark & Tattoo
(SMT) Information
Sponsored by
Information Technology Laboratory
National Institute of Standards and Technology
Gaithersburg, MD 20899-8940
September 2000
U.S. Department of Commerce
Norman Y. Mineta, Secretary
Technology Administration
Dr. Cheryl L. Shavers, Under Secretary of Commerce for Technology
National Institute of Standards and Technology
Raymond G. Kammer, Director
ANSI/NIST-ITL 1-2000
Revision of ANSI/NISTCSL
1-1993 & ANSI/NIST-ITL
1a-1997
Approved July 27, 2000
American National Standards Institute, Inc.
Certain commercial entities, equipment, or materials may be identified in this document in order to describe an
experimental procedure or concept adequately. Such identification is not intended to imply recommendation or
endorsement by the National Institute of Standards and Technology, nor is it intended to imply that the entities,
materials, or equipment are necessarily the best available for the purpose.
National Institute of Standards and Technology
Special Publication 500-245
Natl. Inst. Stand. Technol.
Spec. Publ. 500-245
78 pages (September 2000)
CODEN: NSPUE2
U.S. GOVERNMENT PRINTING OFFICEWASHINGTON:
2000
For sale by the Superintendent of Documents
U.S. Government Printing Office
Washington, DC 20402-9325
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-2000,
Data Format for the Interchange of Fingerprint, Facial & SMT Information, is free to do so.
However, there shall be no alteration to any of the material contained in the document.

iii
CONTENTS
Foreword......................................................................................................................... vii
0 Introduction .................................................................................................................... 1
1 Scope, purpose, and application.................................................................................. 1
1.1 Scope ........................................................................................................................ 1
1.2 Purpose ..................................................................................................................... 1
1.3 Application................................................................................................................. 2
2 Normative references .................................................................................................... 2
3 Definitions...................................................................................................................... 3
4 Transmitted data conventions...................................................................................... 3
4.1 Byte and bit ordering ................................................................................................. 3
4.2 Grayscale data .......................................................................................................... 3
4.3 Binary data ................................................................................................................4
4.4 Color data.................................................................................................................. 4
4.5 Scan sequence.......................................................................................................... 4
5 Image resolution requirements .................................................................................... 5
5.1 Scanner resolution requirement ................................................................................ 5
5.2 Transmitting resolution requirement.......................................................................... 5
6 File description .............................................................................................................. 6
6.1 File format ................................................................................................................. 7
6.2 File contents ..............................................................................................................7
6.3 Implementation domains ........................................................................................... 8
6.4 Image designation character (IDC) ........................................................................... 8
7 Record description ........................................................................................................ 9
7.1 Logical record types .................................................................................................. 9
7.2 Record format.......................................................................................................... 11
8 Type-1 transaction information record...................................................................... 14
8.1 Fields for Type-1 transaction information record..................................................... 14
8.2 End of transaction information record Type-1......................................................... 16
9 Type-2 user-defined descriptive text record............................................................. 17
9.1 Fields for Type-2 logical records ............................................................................. 17
9.2 End of Type-2 user-defined descriptive text record ................................................ 17
10 Type-3 low-resolution grayscale fingerprint image record ................................... 17
10.1 Fields for Type-3 logical record............................................................................. 17
10.2 End of Type-3 low-resolution grayscale fingerprint image record......................... 19
10.3 Additional low-resolution grayscale fingerprint image records.............................. 19
11 Type-4 high-resolution grayscale fingerprint image record.................................. 19
11.1 Fields for Type-4 logical record............................................................................. 19
11.2 End of Type-4 high-resolution grayscale fingerprint image record ....................... 20
11.3 Additional high-resolution grayscale fingerprint images........................................ 20
12 Type-5 low-resolution binary fingerprint image record ......................................... 20
iv
12.1 Fields for Type-5 logical record............................................................................. 21
12.2 End of Type-5 low-resolution binary fingerprint image record .............................. 22
12.3 Additional low-resolution binary fingerprint image records ................................... 22
13 Type-6 high-resolution binary fingerprint image record ....................................... 22
13.1 Fields for Type-6 logical record............................................................................. 22
13.2 End of Type-6 high-resolution binary fingerprint image record............................. 23
13.3 Additional high-resolution binary fingerprint image records.................................. 23
14 Type-7 user-defined image record ........................................................................... 23
14.1 Fields for Type-7 logical record............................................................................. 23
14.2 End of Type-7 user-defined image record............................................................. 24
14.3 Additional user-defined image records.................................................................. 24
15 Type-8 signature image record ................................................................................ 24
15.1 Fields for Type-8 logical record............................................................................. 24
15.2 End of Type-8 signature image record.................................................................. 25
15.3 Additional signature............................................................................................... 25
16 Type-9 minutiae data record..................................................................................... 25
16.1 Minutiae and other information descriptors ........................................................... 25
16.2 Fields for Type-9 logical record............................................................................. 27
16.3 End of Type-9 logical record ................................................................................. 30
16.4 Additional minutiae records................................................................................... 30
17 Type-10 facial & SMT image record ......................................................................... 30
17.1 Fields for Type-10 logical record........................................................................... 30
17.2 End of Type-10 logical record ............................................................................... 36
17.3 Additional facial & SMT image records ................................................................. 36
18 Type-11 record reserved for future use................................................................... 36
19 Type-12 record reserved for future use................................................................... 36
20 Type-13 variable-resolution latent image record.................................................... 36
20.1 Fields for the Type-13 logical record..................................................................... 37
20.2 End of Type-13 variable-resolution latent image record ....................................... 39
20.3 Additional variable-resolution latent image records ............................................. 39
21 Type-14 variable-resolution tenprint image record................................................ 39
21.1 Fields for the Type-14 logical record..................................................................... 39
21.2 End of Type-14 variable-resolution tenprint image record.................................... 42
21.3 Additional variable-resolution tenprint image records ........................................... 42
22 Type-15 variable-resolution palmprint image record............................................. 42
22.1 Fields for the Type-15 logical record..................................................................... 43
22.2 End of Type-15 variable-resolution palmprint image record ................................. 45
22.3 Additional Type-15 variable-resolution palmprint image records.......................... 46
23 Type-16 user-defined testing image record ............................................................ 46
23.1 Fields for the Type-16 logical record..................................................................... 46
23.2 End of Type-16 user-defined testing image record............................................... 47
23.3 Additional Type-16 user-defined testing image records........................................ 48
24 Another individual ..................................................................................................... 48
v
ANNEXES
Annex A - 7-bit ANSI code for information interchange .......................................... 49
Annex B - Use of information separator characters.................................................. 50
Annex C - Base-64 encoding scheme......................................................................... 51
Annex D - JPEG file interchange format..................................................................... 53
Annex E - Scars, marks, tattoos, and other characteristics..................................... 59
Annex F - Example transaction ................................................................................... 64
FIGURES
Figure 1 – Byte & bit ordering.......................................................................................... 4
Figure 2 - Minutiae coordinate system ......................................................................... 27
TABLES
Table 1 – Logical record types ...................................................................................... 6
Table 2 – Number of logical records per transaction.................................................. 7
Table 3 – Information separators ................................................................................ 12
Table 4 – Directory of character sets.......................................................................... 16
Table 5 – Finger impression type................................................................................ 18
Table 6 – Finger position code & maximum size....................................................... 19
Table 7 – Minutia types................................................................................................. 26
Table 8 – Pattern classification ................................................................................... 28
Table 9 – Type-10 facial and SMT record layout........................................................ 31
Table 10 – Subject pose ............................................................................................... 32
Table 11 – Photo descriptors....................................................................................... 33
Table 12 – Tattoo classes............................................................................................. 34
Table 13a – Human tattoo subclasses........................................................................ 35
Table 13b – Animal tattoo subclasses........................................................................ 35
Table 13c – Plant tattoo subclasses ........................................................................... 35
vi
Table 13d – Flags tattoo subclasses .......................................................................... 35
Table 13e – Objects tattoo subclasses....................................................................... 35
Table 13f – Abstract tattoo subclasses ...................................................................... 36
Table 13g – Symbols tattoo subclasses..................................................................... 36
Table 13h – Other tattoo subclasses .......................................................................... 36
Table 14 – Color codes................................................................................................. 36
Table 15 – Type-13 variable-resolution latent record layout.................................... 37
Table 16 – Type-14 variable-resolution tenprint record layout ................................ 40
Table 17 – Type-15 variable-resolution palmprint record layout ............................. 44
Table 18 – Palm impression type ................................................................................ 44
Table 19 – Palm codes, areas, & sizes........................................................................ 45
Table 20 – Type-16 User-defined testing record layout ............................................ 46
Table C1 – Base-64 alphabet ....................................................................................... 51
vii
Foreword (This foreword is not part of American National Standard ANSI/NIST-ITL 1-2000)
Federal, state and local law enforcement and related criminal justice agencies have procured
or are in the process of procuring equipment and systems intended to facilitate the
determination of the personal identity of a subject from fingerprint, palm, facial (mugshot),
or scar mark & tattoo (SMT) images.
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 (ISR) systems. An AFIS scans and stores the digital representations
of fingerprint and palmprint images from inked or chemical cards. Live-scan
readers scan 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 SMTs
present on the subject’s body 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 (ISR) together with textual descriptive data and other information
for each image. When required, specific images stored on a master file can be
retrieved from the ISR 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. A human witness or an examiner
using images retrieved from the system makes the confirming identification.
Features from the scanned fingerprint, palmprint, facial, or SMT 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 makes the final
identification.
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. The data may either be scanned images or the processed
minutiae extracted by the system.
The Information Technology Laboratory (ITL) of the National Institute of Standards and
Technology (NIST) sponsored the development of this American National Standards Institute
(ANSI) document using the Canvass Method to demonstrate evidence of consensus.
This updated standard replaces ANSI/NIST-CSL 1-1993 and ANSI/NIST-ITL 1a-
1997 that address the interchange of fingerprint, facial, and SMT data.
There are six annexes associated with this standard. Annex A is normative and contains
the 7-bit ANSI code for information interchange. 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 contains excerpts from the Eighth Edition (July 14, 1999) of the NCIC
Code Manual for describing Scars, Marks, and Tattoos. Annex F is a comprehensive
viii
example of a transaction file containing fingerprint, mugshot, and palmprint logical records.
The image exchange records contained in Annex F are formatted in accordance
with this standard and are informative and not considered as part of the standard.
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, and SMT 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.
AAMVANET, Inc.
AFR Consortium
AK Dept. of Public Safety
Abilene Police Dept. (TX)
Aware, Inc.
Barry Blain, Ph.D - Consultant
Biometric Identification, Inc.
Bundeskriminalamt (Germany)
Bureau ATF /Dept. of Treasury
CA Bureau of Criminal Information &
Analysis
CA Dept. Motor Vehicles
CA DOJ; Bureau of Criminal Identification &
Information
CA DOJ; Bureau Forensic Science
CT Dept. of Public Safety
CT Dept. of Social Services
Chicago Police Dept. (IL)
Cogent Systems
Comnetix Computer Systems, Inc.
Criminal Justice Coordination Council
Cross Match Technology, Inc.
Digital Biometrics, Inc.
Digital Descriptor Systems, Inc.
Drug Enforcement Administration
FBI / CJIS
FBI / LFPS
FL Dept. of Law Enforcement
Flagler County Sheriff’s Office (FL)
Forensic Identification Services
Free Radical Enterprises
G. A. Thompson Co.
GA Bureau of Investigation
HI Criminal Justice Data Center
Heimann Biometric Systems GMBH
Higgins & Associates, Inc.
IA Division Criminal Investigation
IACP
IAI Latent Print Certification Board
IBM
ID Networks, Inc.
IL State Police Information Services
Bureau
IRS Forensic Science Laboratory
I/O Software, Inc.
Identicator Corp.
Identix
Imagis Technologies, Inc.
Indianapolis Police Dept. (IN)
Infineon Tech AG
KEUPZ (Slovakia)
KS Bureau of Investigation
Kent Ridge Digital Labs.
King County Sheriffs Office (WA)
LA State Police
Lightning Powder Co., Inc.
Lockheed Martin Info. Systems
Los Angeles County Sheriffs Dept. (CA)
Los Angeles Police Dept. / Records &
Identification (CA)
MD Dept. of Public Safety & Correctional
Services
MD State Police
ME State Police
MI State Police
MN Bureau of Criminal Apprehension
MO State Highway Patrol
MTG Management Consultants
Miami-Dade Police (FL)
Miami Valley Regional Crime Lab. (OH)
Michael Fitzpatrick - Consultant
Mikos Ltd.
More Hits
NC State Bureau of Investigation
NEC Corporation
NEC Technologies, Inc.
NIST/OLES
NM Dept. Public Safety
NY State Division Of Criminal Justice
New York City Police Dept. (NY)
OK State Bureau of Investigation
Orange County Sheriffs Dept. (CA)
Orange County Sheriff’s Office (FL)
PA Chiefs of Police Assoc.
PA State Police
PITO, UK
Performance Engineering Corp.
Pittsburgh Police Dept. (PA)
ix
Portland Police Bureau (OR)
Printrak International
RCMP (Canada)
RoadRider Solutions Group, Inc.
SC Law Enforcement Division
STMicroelectronics, Inc.
Saber Imaging
Sagem Morpho, Inc.
Sagem SA
Salt Lake County Sheriff’s Dept. (UT)
San Francisco Police Dept. (CA)
San Jose State University (CA)
TX Dept. of Public Safety
The Avator Group
Thompson, CSF
Toronto Police Service - Forensic ID
(Canada)
US Dept. of Justice
US Postal Inspection Service
VA Judges’ Chambers, Alex. Circuit Court
VA State Police
VT Forensic Lab. CJIS
Visionics Corp.
WA State Patrol
WI Dept. of Justice
WIN, Inc.
x
AMERICAN NATIONAL STANDARD ANSI/NIST-ITL 1-2000
1
American National Standard
for Information Systems
Data Format for the Interchange of Fingerprint, Facial, &
Scar Mark & Tattoo (SMT) Information
0 Introduction
In 1993, ANSI approval was obtained for the
"Data Format for the Interchange of Fingerprint
Information" standard (ANSI/NIST-CSL 1-1993).
The standard specifies formats to be used for exchanging
fingerprint and other image data.
In 1997, ANSI approval was obtained for
the expansion of that standard to include
mechanisms for interchanging facial/
mugshot image data and captured image
data from scars, marks, and tattoos.
That standard is titled Data Format for the
Interchange of Fingerprint, Facial & SMT
Information and carries the ANSI designation
of ANSI/NIST-ITL 1a-1997.
During a workshop that was held in September
1998, these two standards were reviewed
and discussed. Several agreements
were reached affecting various aspects of
the standard. These included the addition
of new fields, new record structures, and
the merging of the two standards into this
single standard. This standard is the combination
of the two previous standards plus
additional record type descriptions, the incorporation
of agreements reached during
the September workshop, and subsequent
proposals offered for improving the standard.
1 Scope, purpose, and app lication
1.1 Scope
This standard defines the content, format, and
units of measurement for the exchange of fingerprint,
palmprint, facial/mugshot, and scar, mark, &
tattoo (SMT) image information that may be used
in the identification 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 uncompressed
images. This information is intended for
interchange among criminal justice administrations
or organizations that rely on automated fingerprint
and palmprint identification systems or
use facial/mugshot or SMT 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 assemble
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, or SMT
images.
1.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 in lieu of a fingerANSI/
NIST-ITL 1-2000
2
print card, a latent fingerprint, facial/mugshot, or
other types of photographs. Law enforcement
and criminal justice agencies will use the standard
to exchange fingerprint, palmprint, or other photographic
images and related identification data.
1.3 Application
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, for a
transaction to be meaningful, there must be at
least one additional type of record included. The
implementor 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.
2 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).
ANSI X3.172-1990, Information Systems --- Dictionary
for Information Systems.
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.
CJIS-RS-0010 (V7) Electronic Fingerprint Transmission
Specification1.
IAFIS-IC-0110 (V3) WSQ Gray-scale Fingerprint
Image Compression Specification2.
ISO 646-1983 7-Bit Coded Character Set for Information
Interchange.3
ISO 8601-1988, Data Elements and Interchange
Formats - Information Interchange Representation
of Dates and Times.4
ANSI/NIST-CSL 1-1993, Information systems
Data Format for the Interchange of Fingerprint
Information.
ANSI/NIST-ITL 1a-1997, Information systems
Data Format for the Interchange of Fingerprint,
Facial, and SMT Information.
ISO International Standard 10918-1, Information
Technology - Digital Compression and Coding of
Continuous-Tone Still Images Part 1: Requirements
and Guidelines5. This is commonly referred
to as the JPEG (Joint Photographic Experts
Group) algorithm.
National Crime Information Center (NCIC) Code
Manual, Eighth Edition, July 14, 19996.
1 Available from Criminal Justice Information Services Division,
Federal Bureau of Investigation 935 Pennsylvania Avenue,
NW, Washington, DC 20535.
2 Available from Criminal Justice Information Services Division,
Federal Bureau of Investigation, 935 Pennsylvania Avenue,
NW, Washington, DC 20535.
3 Available from the American National Standards Institute, 11
West 42nd Street, New York, NY 10036.
4 Available from the American National Standards Institute, 11
West 42nd Street, New York, NY 10036.
5 Available from the American National Standards Institute, 11
West 42nd Street, New York, NY 10036.
6 Available from the U.S. Department of Justice, Federal Bureau
of Investigation, 935 Pennsylvania Avenue, NW, Washington,
DC 20535.
ANSI/NIST-ITL 1-2000
3
3 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.
3.1 ANSI: Abbreviation for the American National
Standards Institute, Inc.
3.2 aspect ratio: The width-to-height ratio of the
captured image.
3.3 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.
3.4 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.
3.5 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.
3.6 mugshot: Term used interchangeably with facial
image. The term facial image usually implies a higher
quality image than a mugshot.
3.7 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.
3.8 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.
3.9 ppi: Abbreviation for pixels per inch.
3.10 ppmm: Abbreviation for pixels per millimeter.
3.11 RGB: Red, Green, Blue used to represent color
pixels comprised of a specified number of bits to represent
each of these primary color components.
3.12 SMT: Abbreviation used for scar, mark, and
tattoo information.
3.13 scanning resolution: The number of pixels per
unit distance at which an image is captured (ppmm or
ppi).
3.14 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
contents of the first two fields.
3.15 transaction: A command, message, or input
record that explicitly or implicitly calls for a processing
action. Information contained in a transaction shall be
applicable to a single subject.
4 Transmitted data conventions
4.1 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. 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.
4.2 Grayscale data
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 sixteenbit
pixels with values in the range of 0-65635. For
ANSI/NIST-ITL 1-2000
4
Figure 1 – Byte & bit ordering
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.
The transmission of compressed grayscale images
shall be the output of the appropriate grayscale
compression algorithm specified. Upon decompression
the grayscale value for each pixel
shall be represented in the same manner as pixels
in an uncompressed image.
4.3 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.
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.
4.4 Color data
For color facial, SMT, or testing images scanned,
it shall be assumed that the scanned images consist
of nominal 24-bit RGB pixels.
Color image data may be transmitted in either
compressed or uncompressed form. The transmission
of uncompressed color images shall consist
of RGB pixels, each of which shall be quantized
to 256 levels (8 bits) for each of the three
components. For each pixel, the three components
shall be sequentially formatted for transmission
on a pixel-by-pixel basis. Compressed
image data shall adhere to the requirements of
the algorithm used.
4.5 Scan sequence
For each color, grayscale, or binary image that
was captured and formatted, the transmitted scan
sequence shall be assumed to have been left to
right and top to bottom.
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 xcoordinate
(horizontal) position shall increase
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.
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
ANSI/NIST-ITL 1-2000
5
5 Image resolution requirements
Image resolution requirements are applicable to
fingerprint and palmprint images. Facial/mugshot
and SMT images rely on the total number of pixels
scanned and transmitted and are not dependent
on the specific scanning resolution used.
5.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.
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.38 ppmm (500 ppi to 1000 ppi), from 39.38
ppmm to 78.76 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.38
ppmm (1000 ppi).
5.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.38 ppmm plus or minus
1% (500 ppi to 1000 ppi), from 39.38 ppmm to
78.76 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.
ANSI/NIST-ITL 1-2000
6
Table 1 – Logical record types
Logical record
Identifier
Logical record contents Type of data
1 Transaction Information ASCII
2 Descriptive Text (User-defined) ASCII
3 Fingerprint Image Data
(Low-resolution grayscale) Binary
4 Fingerprint Image Data
(High-resolution grayscale) Binary
5 Fingerprint Image Data
(Low-resolution binary) Binary
6 Fingerprint Image Data
(High-resolution binary) Binary
7 Image Data (User-defined) Binary
8 Signature Image Data Binary
9 Minutiae Data ASCII
10 Facial & SMT Image Data ASCII/Binary
11 Reserved for Future Use -
12 Reserved for Future Use -
13 Latent Image Data
(Variable-resolution) ASCII/Binary
14 Tenprint fingerprint Impressions
(Variable-resolution) ASCII/Binary
15 Palmprint Image Data
(Variable-resolution) ASCII/Binary
16 User-defined Testing Image Data
(Variable-resolution)
ASCII/Binary
6 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 to
exchange ASCII textual information fields, six
logical records to exchange binary information,
and five tagged-field record types designed to
exchange 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.
Two additional record types are reserved
for inclusion in future revisions of this standard.
The sixteen types of logical records together
with the identifier for each type are listed in
Table 1.
ANSI/NIST-ITL 1-2000
7
Table 2 – Number of logical records per transaction
Type of
logical
record
Tenprint
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-6 0 0-6 0 0-N 0-N
16 0 0 0-N 0 0-N 0-N
6.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 Type-2, and Type-9
through Type-16 records will normally be recorded
using the 7-bit ASCII code in variablelength
fields with specified upper limits on the size
of the fields. The first two fields in all tagged-field
records must be numerically ordered. The remaining
textual fields can be in any order. For
tagged-field image records, Type-10 through
Type-16, the last and concluding field shall
have a tagged ASCII field number identifier
followed by the image data.
For data interchange between non-English
speaking agencies, character sets other than 7-bit
ASCII may be used in textual fields contained in
Type-2 and Type-9 through Type-16 records. The
mechanism to change character sets is described
in Section 7.2.3, International Character Sets.
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.
6.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, the number of fingerprint, palmprint,
facial/mugshot, or SMT images available for
processing, one or more additional records may
be present in the file.
Table 2 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. In parANSI/
NIST-ITL 1-2000
8
ticular, specific applications must dictate the
maximum number of Type-2 records that may be
present in a transaction. 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. However, any recipient
agency may impose their own specific limit for
each type of logical record.
6.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 taggedfield
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.
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.
6.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
contents field of the Type-1 record to each logical
record, and to properly identify and link together
logical records that pertain to the same subject
matter. 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. 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, six palmprint records,
and a facial/mugshot image of the subject. Additional
mugshot and SMT logical records may expand
the file even more. For this file configuration,
the IDC shall range from "0" to "23" 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 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.
ANSI/NIST-ITL 1-2000
9
The IDC shall also be used to relate information
items in the file contents field of the
Type-1 record to each facial or SMT 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 subject matter shall have a
unique IDC with an increment of one greater than
the last IDC used.
7 Record description
7.1 Logical record types
7.1.1 Type-1 transaction record
A Type-1 logical record is mandatory and shall be
contained in 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.
7.1.2 Type-2 user-defined descriptive text record
Type-2 logical records shall contain user-defined
textual fields providing identification and descriptive
information about the subject of the fingerprint
information. 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.
7.1.3 Type-3 low-resolution grayscale record
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. The resultant
transmitting resolution shall be within the bounds
of the permissible transmitting resolutions for lowresolution
fingerprint images.
The low-resolution grayscale fingerprint image
data contained in the Type-3 logical record may
be in compressed form. Typically, there may be
up to 14 of these Type-3 records 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.
7.1.4 Type-4 high-resolution grayscale record
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. 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.
The high-resolution grayscale fingerprint image
data contained in the Type-4 logical record may
be in compressed form. Typically, there may be
up to 14 of these Type-4 records 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.
7.1.5 Type-5 low-resolution binary record
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. The resultant
transmitting resolution shall be within the bounds
of the permissible transmitting resolutions for lowresolution
fingerprint images.
The low-resolution binary fingerprint image data
contained in the Type-5 logical record may be in
compressed form. Typically, there may be up to
14 of these Type-5 records 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.
7.1.6 Type-6 high-resolution binary record
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. If the scanning
resolution is greater than the upper limit of the
permissible transmitting resolution, the scanned
ANSI/NIST-ITL 1-2000
10
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.
The high-resolution binary fingerprint image data
contained in the Type-6 logical record may be in
compressed form. Typically, there may be up to
14 of these Type-6 records 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.
7.1.7 Type-7 user-defined image record
Type-7 logical records shall contain user-defined
image data. This record type is used to exchange
image data that is not elsewhere specified or described
in this standard. With the exception of the
length and IDC fields, 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. This record type
is included to handle miscellaneous images such
as those pertaining to wrists, toes, soles, etc.
7.1.8 Type-8 signature image data 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.
7.1.9 Type-9 minutiae record
Type-9 logical records shall contain, and be used
to exchange geometric and topological minutiae
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.
Each Type-9 logical record shall contain the minutiae
data read from a fingerprint, palm, or latent
image.
7.1.10 Type-10 facial & SMT image record
Type-10 tagged-field image records shall contain,
and be used to exchange facial and SMT image
data 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.
7.1.11 Type-11 record reserved for future use
7.1.12 Type-12 record reserved for future use
7.1.13 Type-13 variable-resolution latent image
record
Type-13 tagged-field image records shall contain,
and be used to exchange variable-resolution latent
fingerprint and palmprint image data together
with fixed and user-defined textual
information fields pertinent to the digitized
image. It is strongly recommended that the
minimum scanning resolution (or effective scanning
resolution) and transmission rate for latent
images be 39.38 ppmm plus or minus 0.40 ppmm
(1000 ppi plus or minus 10 ppi). However, in all
cases the scanning resolution used to capture a
latent image shall be at least as great as the
minimum scanning resolution of 19.69 ppmm (500
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 these latent records that may be present
in a transaction.
7.1.14 Type-14 variable-resolution tenprint image
record
Type-14 tagged-field image records shall contain,
and be used to exchange variable-resolution tenprint
fingerprint image data together with fixed
ANSI/NIST-ITL 1-2000
11
and user-defined textual information fields
pertinent to the digitized image. Fingerprint
images can be either rolled or plain 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 tenprint images be 39.38
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 tenprint image shall be at
least as great as the minimum scanning resolution
of 19.69 ppmm (500ppi).
The variable-resolution tenprint 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 and two plain impressions
of the four simultaneously obtained remaining
fingers of each hand.
7.1.15 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. Image data contained
in this record may be the full palm impression,
the upper half of the palm, the lower half of
the palm, or the writers palmprint impression.
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.38
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 tenprint 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. Typically, there may be up to
6 of these Type-15 records in a file; two full
palmprints or four partial palms, and two writers
palms.
7.1.16 Type-16 user-defined testing image record
The Type-16 tagged-field image record is intended
as the tagged-field version of the Type-7
user-defined 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,
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.
The scanning resolution is not specified for this
record type but 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.38 ppmm (1000
ppi), 78.76 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 first two
tagged fields 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.
7.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 singlevalued
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 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.
ANSI/NIST-ITL 1-2000
12
Table 3 – 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
7.2.1 Information separators
In the tagged-field logical records (Type-1, Type-
2, and Type-9 through Type-16), 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 3 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.
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 of 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.
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 charANSI/
NIST-ITL 1-2000
13
acters. 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.
7.2.2 Record layout
For tagged-field logical records (Type-1, Type-2,
Type-9, Type-10, and Type-13 through Type-16),
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-1) 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 oneto
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 twocharacter
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 contain 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 or 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 and Type-13 through Type-16
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.
7.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 effect data and transaction
interchanges between non-English based
agencies, a technique is available to encode information
using character sets other than 7-bit
ASCII. Fields from theType-1 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 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 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
ANSI/NIST-ITL 1-2000
14
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.
8 Type-1 transaction information record
8.1 Fields for Type-1 transaction information record
The following paragraphs describe the data contained
in fields for the Type-1 logical 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. Annex
F contains an example of the use of the standard
that illustrates the layout for a Type-1 logical record.
8.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” 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 Type-9
through Type-16 logical records shall always be
observed. The “US” separator shall separate
multiple information items within a field or subfield,
the “RS” separator shall separate multiple
subfields, and the “GS separator shall separate
information fields.
8.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 this 2000 approved standard
shall be "0300". This version number signifies
the inclusion of the tagged-field logical
Type-10 through Type-16 image records.
8.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 indicating
that this is a Type-1 record consisting of
header information (the logical record identifier
"1" selected from Table-1).
The second information item of this subfield shall
be the sum of the Type-2 through Type-16 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
ANSI/NIST-ITL 1-2000
15
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-16 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-1 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.
8.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.
8.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 CCYYMMDD.
The CCYY 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,
20000103 represents January 3, 2000.
8.1.6 Field 1.006: Priority (PRY)
When this field is used, it 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.
8.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.
8.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.
8.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.
8.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.
8.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 applications other than fingerprint where
resolution is not a factor or not applicable (such a
facial or SMT image) this field shall be set to
00.00.
ANSI/NIST-ITL 1-2000
16
Table 4 – 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-127 ------------- Reserved for ANSI/NIST future use
128-999 ------------- User-defined character sets
8.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 applications
where resolution is not a factor or not applicable
(such as a facial or SMT image) this field
shall be set to 00.00.
8.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}.
8.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 "CCYYMMDDHHMMSSZ, a
15-character string that is the concatenation of
the date with the GMT and concludes with a Z.
The CCYY 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.
8.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. Table 4 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.
8.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
ANSI/NIST-ITL 1-2000
17
logical record. This “FS” character shall replace
the “GS” character that is normally used between
information fields.
9 Type-2 user-defined des criptive 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 subjects criminal history.
Every transaction shall usually contain one or
more Type-2 records which is dependent upon
the entry in the Type-of-Transaction Field 1.004
(TOT).
9.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.
9.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.
9.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.
9.1.3 Field 2.003-999: 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 7.2.2 Record
Layout.
9.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 Type-3 low-resolution grayscale fingerprint
image record
Type-3 logical records shall contain low-resolution
grayscale fingerprint image data. The fingerprint
image data shall have been 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
such that the resulting transmitting resolution is
within the range specified by the transmitting
resolution requirement for low-resolution images.
When the image data is obtained from a live-scan
reader, it shall be the grayscale subsampled,
scaled down, or interpolated output of the livescan
fingerprint scanner and not a rescan of a
hard copy fingerprint image.
10.1 Fields for Type-3 logical record
Within a Type-3 logical record, entries shall be
provided in nine ordered and unnumbered fields.
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.
10.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 nine fields contained
in the record.
ANSI/NIST-ITL 1-2000
18
10.1.2 Image designation character (IDC)
This mandatory one-byte binary field shall occupy
the fifth byte of a Type-3 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.
10.1.3 Impression type (IMP)
This mandatory one-byte binary field shall occupy
the sixth byte of a Type-3 record. The code selected
from Table 5, describing the manner by
which the fingerprint image information was obtained,
shall be entered in this field.
10.1.4 Finger position (FGP)
This mandatory fixed-length field of six binary
bytes shall occupy the seventh through twelfth
byte positions of a Type-3 record. 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 6 and entered as a binary number
right justified and left zero filled within the eight-bit
byte. Table 6 also lists the maximum image area
and the recommended width and height dimensions
for each of the finger positions. The maximum
areas are larger than the product of the
width and height in order to accommodate images
that extend beyond the boundaries of the marked
areas on a standard fingerprint card. Up to five
additional finger positions may be referenced by
entering the alternate finger positions in the remaining
five bytes using the same format.
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.
10.1.5 Image scanning resolution (ISR)
This mandatory one-byte binary field shall occupy
the thirteenth byte of a Type-3 record. 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.
10.1.6 Horizontal line length (HLL)
This mandatory two-byte binary field shall occupy
the fourteenth and fifteenth bytes of the Type-3
record. It shall be used to specify the number of
pixels contained on a single horizontal line of the
transmitted image.
10.1.7 Vertical line length (VLL)
This mandatory two-byte binary field shall occupy
the sixteenth and seventeenth bytes of the Type-3
record. It shall be used to specify the number of
horizontal lines contained in the transmitted image.
Table 5 – Finger impression type
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
10.1.8 Grayscale compression algorithm (GCA)
This mandatory one-byte binary field shall occupy
the eighteenth byte of a Type-3 record. It shall be
used to specify the type of grayscale compression
algorithm used (if any). A binary zero denotes no
compression. Otherwise, the contents of this byte
shall be a binary representation for the number
allocated to the particular compression technique
used by the interchange parties. The domain
registrar will maintain a registry relating these
numbers to the compression algorithms.
10.1.9 Image data
This binary field shall contain all of the lowresolution
grayscale image data. Each pixel of
the uncompressed image shall be quantized to
eight bits (256 gray levels) contained in a single
byte. If compression is used, the pixel data shall
be compressed in accordance with the compression
technique specified in the GCA field. This
completes the low-resolution image description
for a single image.
ANSI/NIST-ITL 1-2000
19
Table 6 – Finger position code & maximum size
Finger position Finger
code
Max image area
(mm2)
Width
(mm) (in)
Length
(mm) (in)
Unknown 0 1745 40.6 1.6 38.1 1.5
Right thumb 1 1745 40.6 1.6 38.1 1.5
Right index finger 2 1640 40.6 1.6 38.1 1.5
Right middle finger 3 1640 40.6 1.6 38.1 1.5
Right ring finger 4 1640 40.6 1.6 38.1 1.5
Right little finger 5 1640 40.6 1.6 38.1 1.5
Left thumb 6 1745 40.6 1.6 38.1 1.5
Left index finger 7 1640 40.6 1.6 38.1 1.5
Left middle finger 8 1640 40.6 1.6 38.1 1.5
Left ring finger 9 1640 40.6 1.6 38.1 1.5
Left little finger 10 1640 40.6 1.6 38.1 1.5
Plain right thumb 11 2400 25.4 1.0 50.8 2.0
Plain left thumb 12 2400 25.4 1.0 50.8 2.0
Plain right four fingers 13 6800 81.3 3.2 50.8 2.0
Plain left four fingers 14 6800 81.3 3.2 50.8 2.0
10.2 End of Type-3 low-resolution grayscale fingerprint
image record
Since the Type-3 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.
10.3 Additional low-resolution grayscale fingerprint
image records
Typically, up to thirteen more images may be described
within the file. For each additional image,
a Type-3 logical record is required.
11 Type-4 high-resolution grayscale fingerprint
image record
Type-4 logical records shall contain highresolution
grayscale fingerprint image data that
have been scanned at the minimum scanning
resolution. Alternatively, the native scanning
resolution may be used and the image processed
such that the resulting transmitting resolution is
within the range specified by the transmitting
resolution requirement for high-resolution images.
When the image data is obtained from a live-scan
reader it shall be the grayscale output of the livescan
fingerprint scanner and not a rescan of a
hard copy fingerprint image.
11.1 Fields for Type-4 logical record
Within a Type-4 logical record, entries shall be
provided in nine ordered and unnumbered fields.
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.
11.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 nine fields contained
in the record.
11.1.2 Image designation character (IDC)
This mandatory one-byte binary field shall occupy
the fifth byte of a Type-4 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.
ANSI/NIST-ITL 1-2000
20
11.1.3 Impression type (IMP)
This mandatory one-byte binary field shall occupy
the sixth byte of a Type-4 record. The code selected
from Table 5, describing the manner by
which the fingerprint image information was obtained,
shall be entered in this field.
11.1.4 Finger position (FGP)
This mandatory fixed-length field of 6 binary bytes
shall occupy the seventh through twelfth positions
of a Type-4 record. It shall contain possible finger
positions beginning in the leftmost byte of the field
(byte seven of the record). The decimal code
number for the known or most probable finger
position shall be taken from Table 6 and entered
as a binary number right justified and left zero
filled within the eight-bit byte. Up to five additional
finger positions may be referenced by entering
the alternate finger positions in the remaining five
bytes using the same format. 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.1.5 Image scanning resolution (ISR)
This mandatory one-byte binary field shall occupy
the thirteenth byte of a Type-4 record. 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.
11.1.6 Horizontal line length (HLL)
This mandatory two-byte binary field shall occupy
the fourteenth and fifteenth bytes of the Type-4
record. It shall be used to specify the number of
pixels contained on a single horizontal line of the
transmitted image.
11.1.7 Vertical line length (VLL)
This mandatory two-byte binary field shall occupy
the sixteenth and seventeenth bytes of the Type-4
record. It shall be used to specify the number of
horizontal lines contained in the transmitted image.
11.1.8 Grayscale compression algorithm (GCA)
This mandatory one-byte binary field shall occupy
the eighteenth byte of a Type-4 record. It shall be
used to specify the type of grayscale compression
algorithm used (if any). A binary zero denotes no
compression. Otherwise, the contents of this byte
shall be a binary representation for the number
allocated to the particular compression technique
used by the interchange parties. The domain
registrar will maintain a registry relating these
numbers to the compression algorithms.
11.1.9 Image data
This binary field shall contain all of the highresolution
grayscale image data. Each pixel of
the uncompressed image shall be quantized to
eight bits (256 gray levels) contained in a single
byte. If compression is used, the pixel data shall
be compressed in accordance with the compression
technique specified in the GCA field. This
completes the high-resolution image description
for a single image.
11.2 End of Type-4 high-resolution grayscale fingerprint
image record
Since the Type-4 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.
11.3 Additional high-resolution grayscale fingerprint
images
Typically, up to thirteen more images may be described
within the file. For each additional image,
a Type-4 logical record is required.
12 Type-5 low-resolution binary fingerprint
image record
Type-5 logical records shall contain low-resolution
binary fingerprint image data. The fingerprint image
data shall have been 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 such
that the resulting transmitting resolution is within
ANSI/NIST-ITL 1-2000
21
the range specified by the transmitting resolution
requirement for low-resolution images. When the
image data are obtained from a live-scan reader,
it shall be the binarized subsampled, scaled
down, or interpolated output of the live-scan fingerprint
scanner and not a rescan of a hard copy
fingerprint image.
12.1 Fields for Type-5 logical record
Within a Type-5 logical record, entries shall be
provided in nine ordered and unnumbered fields.
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.
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 nine 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-5 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 Impression type (IMP)
This mandatory one-byte binary field shall occupy
the sixth byte of a Type-5 record. The code selected
from Table 5, describing the manner by
which the fingerprint image information was obtained,
shall be entered in this field.
12.1.4 Finger position (FGP)
This mandatory fixed-length field of six binary
bytes shall occupy the seventh through twelfth
positions of a Type-5 record. It shall contain possible
finger positions beginning in the leftmost
byte of the field (byte seven of the record). The
decimal code number for the known or most
probable finger position shall be taken from Table
6 and entered as a binary number right justified
and left zero filled within the eight-bit byte. Up to
five additional finger positions may be referenced
by entering the alternate finger positions in the
remaining five bytes using the same format. 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.
12.1.5 Image scanning resolution (ISR)
This mandatory one-byte binary field shall occupy
the thirteenth byte of a Type-5 record. 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.
12.1.6 Horizontal line length (HLL)
This mandatory two-byte binary field shall occupy
the fourteenth and fifteen bytes of the Type-5 record.
It shall be used to specify the number of pixels
contained on a single horizontal line of the
transmitted image.
12.1.7 Vertical line length (VLL)
This mandatory two-byte binary field shall occupy
the sixteenth and seventeenth bytes of the Type-5
record. It shall be used to specify the number of
horizontal lines contained in the transmitted image.
12.1.8 Binary compression algorithm (BCA)
This mandatory one-byte binary field shall occupy
the eighteenth byte of a Type-5 record. It shall be
used to specify whether or not data compression
is used. A binary zero denotes no compression.
A binary one denotes the use of the
ANSI/EIA-538-1988 facsimile compression standard
for the lossless compression and decompression
of the image data.
12.1.9 Image data
This field shall contain all of the low-resolution
binary image data. Each pixel of the uncompressed
image shall be quantized to two levels
(binary representation). For binary pixels, a value
of 0 shall represent a white pixel and a value of
1 shall represent a black pixel. Uncompressed
data shall be packed at eight pixels per byte. If
compression is used, the pixel data shall be compressed
in accordance with the technique as
specified in BCA field. This completes the lowANSI/
NIST-ITL 1-2000
22
resolution binary image description for a single
image.
12.2 End of Type-5 low-resolution binary fingerprint
image record
Since the Type-5 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 low-resolution binary fingerprint
image records
Typically, up to thirteen more images may be described
within the file. For each additional image,
a Type-5 logical record is required.
13 Type-6 high-resolution b inary fingerprint
image record
Type-6 logical records shall contain highresolution
binary fingerprint image data that has
been scanned at the minimum scanning resolution.
Alternatively, the native scanning resolution
may be used and the image processed such that
the resulting transmitting resolution is within the
range specified by the transmitting resolution requirement
for high-resolution images. When the
image data are obtained from a live-scan reader it
shall be the binarized output of the live-scan fingerprint
scanner and not a rescan of a hard copy
fingerprint image.
13.1 Fields for Type-6 logical record
Within a Type-6 logical record, entries shall be
provided in nine ordered and unnumbered fields.
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.
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 specifying the total number of
bytes, including every byte of all nine fields contained
in the record.
13.1.2 Image designation character (IDC)
This mandatory one-byte binary field shall occupy
the fifth byte of a Type-6 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.
13.1.3 Impression type (IMP)
This mandatory one-byte binary field shall occupy
the sixth byte of a Type-6 record. The code selected
from Table 5, describing the manner by
which the fingerprint image information was obtained,
shall be entered in this field.
13.1.4 Finger position (FGP)
This mandatory fixed-length field of six binary
bytes shall occupy the seventh through twelfth
positions of a Type-6 record. It shall contain possible
finger positions beginning in the leftmost
byte of the field (byte seven of the record). The
decimal code number for the known or most
probable finger position shall be taken from Table
6 and entered as a binary number right justified
and left zero filled within the eight-bit byte. Up to
five additional finger positions may be referenced
by entering the alternate finger positions in the
remaining five bytes using the same format. 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.
13.1.5 Image scanning resolution (ISR)
This mandatory one-byte binary field shall occupy
the thirteenth byte of a Type-6 record. 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.
13.1.6 Horizontal line length (HLL)
This mandatory two-byte binary field shall occupy
the fourteenth and fifteenth bytes of the Type-6
record. It shall be used to specify the number of
pixels contained on a single horizontal line of the
transmitted image.
ANSI/NIST-ITL 1-2000
23
13.1.7 Vertical line length (VLL)
This mandatory two-byte binary field shall occupy
the sixteenth and seventeenth bytes of the Type-6
record. It shall be used to specify the number of
horizontal lines contained in the transmitted image.
13.1.8 Binary compression algorithm (BCA)
This mandatory one-byte binary field shall occupy
the eighteenth byte of a Type-6 record. It shall be
used to specify whether or not data compression
is used. A binary zero denotes no compression.
A binary one denotes the use of the ANSI/EIA-
538-1988 facsimile compression standard for the
lossless compression and decompression of the
image data.
13.1.9 Image data
This field shall contain all of the high-resolution
binary image data. Each pixel of the uncompressed
image shall be quantized to two levels
(binary representation). For binary pixels, a value
of 0 shall represent a white pixel and a value of
1 shall represent a black pixel. Uncompressed
data shall be packed at eight pixels per byte. If
compression is used, pixel data shall be compressed
in accordance with the technique as
specified in BCA field. This completes the highresolution
binary image description for a single
image.
13.2 End of Type-6 high-resolution binary fingerprint
image record
Since the Type-6 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 high-resolution binary fingerprint
image records
Typically, up to thirteen more images may be described
within the file. For each additional image,
a Type-6 logical record is required.
14 Type-7 user-defined image record
Type-7 logical records shall contain user-defined
image information relating to the transaction submitted
for processing. This record type is designed
to be used to exchange image data that is
not addressed elsewhere in this standard. Examples
of usage include, but are not limited to, images
pertaining to the toes and soles of a subject
s feet. Scanned pixels 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, Type-4, Type-5, and Type-6 logical
records.
14.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.
14.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.
14.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.
ANSI/NIST-ITL 1-2000
24
14.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.
14.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.
14.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.
15 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.
15.1 Fields for Type-8 logical record
When there are one or two Type-8 logical records,
entries shall be provided in eight ordered
and unnumbered binary fields. 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.
15.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.
15.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.
15.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.
15.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.
15.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.
15.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.
ANSI/NIST-ITL 1-2000
25
15.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.
15.1.8 Signature image data
This 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.
15.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.
15.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.
15.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-to-right 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.
15.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.
15.3 Additional signature
One more signature may be described within the
file. For an additional signature, a Type-8 logical
record is required.
16 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,
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 six of these records for
palmprint searches. The Type-9 record shall also
be used to exchange the minutiae information
from latent finger or palm images between similar
or different systems.
16.1 Minutiae and other information descriptors
16.1.1 Minutia type identification
This standard defines four identifier characters
that are used to describe the minutia type. These
are listed in Table 7. 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
ANSI/NIST-ITL 1-2000
26
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 7 – Minutia types
Type Description
A Ridge ending
B Bifurcation
C Compound (trifurcation or crossover)
D Type undetermined
16.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.
16.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.
16.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.
For encoded minutiae from fingerprints, values of
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 2
illustrates the defined coordinate system for a fingerprint.
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,
a bifurcation, a compound or a minutia of undetermined
type shall be expressed as positive integers
in units of degrees from 0 to 359 degrees.
Theta shall be 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.
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.
No orientation shall be assigned to a compound
type minutiae; therefore, a value of "000" shall be
entered for Theta in the Type-9 logical record entry.
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.
ANSI/NIST-ITL 1-2000
27
Figure 2 - Minutiae coordinate system
16.2 Fields for Type-9 logical record
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.
This logical record type can also be used to accommodate
a variety of methods used by AFIS
vendors for encoding minutiae data according to
their particular requirements. The numbered
fields of the Type-9 logical record are partitioned
into registered blocks of tagged-fields starting at
Field-13. Each AFIS vendor has a block of
uniquely numbered fields reserved for the encoding
of minutiae and other characteristic data
required for their feature vector. Each specific
vendor implementation must contain the first
four fields described below. The remaining
numbered fields of the feature vector are vendor
dependent and encoded according to their own
conventions. None of the fields from Field-5
through Field-12 described below are required to
be present in specific vendor implementations.
16.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.
16.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.
16.2.3 Field 9.003: Impression type (IMP)
This mandatory one-byte field shall describe the
manner by which the fingerprint image information
was obtained. The ASCII value of the
proper code as selected from Table 5 or Table
18 shall be entered in this field to signify the impression
type.
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
ANSI/NIST-ITL 1-2000
28
16.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 terms.
This alternative allows each vendor to encode
minutiae data and any additional required characteristic
or feature data in accordance with their
own systems specific hardware and software
configuration. Reserved blocks, each consisting
of several tagged fields, are registered to and
allocated for use by specific vendors. Vendorspecific
data shall begin with Field-13. 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. Multiple blocks of vendorspecific
data, which may include Field-5 through
Field-12, may occur within a single Type-9 record
when this field contains a U.
Even though information may be encoded in
accordance with a specific vendors implementation,
all data fields of the Type-9 record must
remain as ASCII text fields.
16.2.5 Field 9.005: Originating fingerprint reading
system (OFR)
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 of this field. 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.
16.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. Entries from
Table 6 or Table 19 list the codes that shall be
used for each fingerprint or palmprint.
16.2.7 Field 9.007: Fingerprint pattern classification
(FPC)
This mandatory field shall contain the fingerprint
pattern classification code. It shall contain two
information items. The first information item shall
indicate the source of the specific pattern classification
code. It may be one chosen from Table
8 or may be a user-defined classification code.
This item shall contain a "T" to indicate that the
pattern classification code is from Table 8, 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 8 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.
Table 8 – 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
ANSI/NIST-ITL 1-2000
29
16.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
16.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.
16.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.
16.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.
16.2.12 Field 9.012: Minutiae and ridge count
data (MRC)
This variable field length shall contain all of the
individual minutiae and ridge count data associated
with the current fingerprint 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.
16.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.
16.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.
16.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.
16.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 7. 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.
ANSI/NIST-ITL 1-2000
30
16.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).
16.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.
16.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.
16.4 Additional minutiae records
Typically, up to nine more fingers may be described
within the file. For each additional finger,
a Type-9 logical record, and an “FS” separator
is required.
17 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 either in a compressed
or an uncompressed form.
17.1 Fields for 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 9 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.
17.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.
17.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.
17.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.
ANSI/NIST-ITL 1-2000
31
Table 9 – Type-10 facial and SMT record layout
Field size per
occurrence
Occur
count
Ident Cond
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 21 1 1 28
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 A 5 7 1 1 14
CSP M 10.012 COLOR SPACE A 4 5 1 1 12
RSV - 10.013
10.019
RESERVED FOR FUTURE
INCLUSION
-- -- -- -- -- --
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
RSV - 10.023
10.039
RESERVED FOR FUTURE
INCLUSION
-- -- -- -- -- ---
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
INCLUSION
-- -- -- -- -- ---
UDF O 10.200
10.998
USER-DEFINED FIELDS -- -- -- -- -- ---
DAT M 10.999 IMAGE DATA B 2 5,000,001 1 1 5,000,008
Key for character type: N = Numeric; A = Alphabetic; AN = Alphanumeric; B = Binary
17.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 facial 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 user
initiating the transaction shall define the size of
this field and its data content so that it can be
processed by the receiving agency.
17.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 CCYYMMDD. The CCYY
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, 20000229 repreANSI/
NIST-ITL 1-2000
32
sents February 29, 2000. The complete date
must be a legitimate date.
17.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.
17.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.
17.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.
17.1.9 Field 10.009: 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.
17.1.10 Field 10.010: 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.
17.1.11 Field 10.011: Compression algorithm
(CGA)
This mandatory ASCII field shall specify the algorithm
used to compress the color or grayscale
image. 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,
the preferred method for the compression
of facial and SMT images is specified by the
baseline mode of the JPEG algorithm. The data
shall be formatted in accordance with the JPEG
File Interchange Format, Version 1.02 (JFIF)7 as
found in Annex D. An entry of "JPEGB" 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 luminescence component will be compressed
and transmitted.
17.1.12 Field 10.012: Colorspace (CSP)
This mandatory ASCII field shall contain the color
space used to exchange the image. For compressed
images, the preferred colorspace using
baseline JPEG and JFIF is YCbCr8 to be coded
as "YCC". An entry of "GRAY" shall be used for
all grayscale images. This field shall contain
"RGB" for uncompressed color images containing
non-interleaved red, green, and blue pixels in that
order. All other colorspaces are undefined.
17.1.13 Field 10.013-019: 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.
17.1.14 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 10 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.
Table 10 – Subject pose
Pose description Pose code
Full Face Frontal F
Right Profile (90 degree) R
Left Profile (90 degree) L
Angled Pose A
7Developed by C-Cube Microsystems, 1778 McCarthy Blvd.,
Milpitas, CA 95035.
8Annex D contains the information necessary to perform
conversions between 24-bit RGB pixels and the YCbCr color
space.
ANSI/NIST-ITL 1-2000
33
17.1.15 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 fullface
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.
17.1.16 Field 10.022: Photo description (PXS)
This optional ASCII field shall be used for the exchange
of facial image data. When present, it
shall describe special attributes of the captured
facial image. Attributes associated with the facial
image may be selected from Table 11 and entered
in this field.
Table 11 – 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 Part 4 Section 13 of the
Eighth (or current) Edition of the NCIC Code
Manual, July 14, 1999. 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" 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.
17.1.17 Field 10.023-039: 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.
17.1.18 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, or
tattoo image. The contents of this field will be an
entry chosen from Part 4 Section 13 of the Eighth
(or current) Edition of the NCIC Code Manual,
July 14, 1999. 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
17.1.19 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.
17.1.20 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
ANSI/NIST-ITL 1-2000
34
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.
The second information item shall be the general
class code of tattoo chosen from Table 12. 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 Tables 13a - 13h which lists
the various subclasses of tattoos for each of the
general classes.
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.
17.1.21 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 14. Additional
colors for the sub-field shall be entered as information
items in the subfield separated by the US
separator character.
17.1.22 Field 10.044-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.
17.1.23 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.
17.1.24 Field 10.999: Image data (DAT)
This field shall contain all of the grayscale or color
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.
For example, 10.999: is followed by image data
in a binary representation.
Table 12 – 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
ANSI/NIST-ITL 1-2000
35
Table 13a – 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 13b – Animal tattoo subclasses
Subclass Subclass
code
Cats & Cat Heads CAT
Dogs & Dog Heads DOG
Other Domestic Animals DOMESTIC
Vicious Animals
(Lions, Tigers, 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
Table 13c – 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 13d – 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 13e – Objects tattoo subclasses
Subclass Subclass
code
Fire FIRE
Weapons
(Guns, Arrows, etc.)
WEAP
Airplanes PLANE
Boats, Ships, and 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
ANSI/NIST-ITL 1-2000
36
Table 13f – 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
Table 13g – 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 13h – Other tattoo subclasses
Subclass Subclass
code
Wording
(Mom, Dad, Mary, etc.)
WORDING
Freeform Drawings FREEFRM
Miscellaneous Images MISC
Table 14 – 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
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 bit RGB pixels.
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. If compression is used, the pixel data shall
be compressed in accordance with the compression
technique specified in the GCA field. If the
JPEG algorithm is to be used to compress the
data, this field shall be encoded using the JFIF
format specification.
17.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.
17.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.
18 Type-11 record reserved for future use
19 Type-12 record reserved for future use
20 Type-13 variable-resolution latent image
record
The Type-13 tagged-field logical record shall
contain image data acquired from latent 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, and other parameters required
to process the image, are recorded as
tagged-fields within the record.
ANSI/NIST-ITL 1-2000
37
Table 15 – 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 A 2 2 1 1 9
SRC M 13.004 SOURCE AGENCY / ORI AN 10 21 1 1 28
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 A 5 7 1 1 14
BPX M 13.012 BITS PER PIXEL N 2 3 1 1 10
FGP M 13.013 FINGER POSITION N 2 3 1 6 25
RSV 13.014
13.019
RESERVED FOR FUTURE
DEFINITION
-- -- -- -- -- --
COM O 13.020 COMMENT A 2 1 28 0 1 128
RSV 13.021
13.199
RESERVED FOR FUTURE
DEFINITION
-- -- -- -- -- --
UDF O 13.200
13.998
USER-DEFINED FIELDS -- -- -- -- -- --
DAT M 13.999 IMAGE DATA B 2 -- 1 1 --
Key for character type: N = Numeric; A = Alphabetic; AN = Alphanumeric; B = Binary
20.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 15 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 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.
20.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.
ANSI/NIST-ITL 1-2000
38
20.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 5 (finger)
or Table 18 (palm) shall be entered in this field.
20.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 20 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 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 CCYYMMDD. The CCYY 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, 20000229 represents February
29, 2000. The complete date must be a
legitimate date.
20.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.
20.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.
20.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.
20.1.9 Field 13.009: 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.
20.1.10 Field 13.010: 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.
20.1.11 Field 13.011: Compression algorithm
(CGA)
This mandatory ASCII field shall specify the algorithm
used to compress 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 preferred
method for the compression of latent fingerprint
images. For grayscale images, the domain registrar
shall maintain a registry of compression techniques
and corresponding codes that may be
used as they become available.
20.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.
20.1.13 Field 13.013: Finger / palm position (FGP)
This mandatory tagged-field shall contain one or
more the 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
6 or the most probable palm position from Table
19 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
ANSI/NIST-ITL 1-2000
39
Unknown Palm, shall be used to reference
every listed palmprint position.
20.1.14 Field 13.014-019: 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.
20.1.15 Field 13.020: Comment (COM)
This optional field may be used to insert comments
or other ASCII text information with the
latent image data.
20.1.16 Field 13.021-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.
20.1.17 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.
20.1.18 Field 13.999: Image data (DAT)
This 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. For example, 13.999: is followed by
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 or less 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 GCA field.
20.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.
20.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.
21 Type-14 variable-resolution tenprint image
record
The Type-14 tagged-field logical record shall
contain and be used to exchange tenprint fingerprint
image data. Rolled and plain fingerprint impressions
shall be acquired from a tenprint 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
used, the image size and other parameters
or comments required to process the image are
recorded as tagged-fields within the record.
21.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. 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 16 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
ANSI/NIST-ITL 1-2000
40
Table 16 – Type-14 variable-resolution tenprint 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
CHARACTER
N 2 5 1 1 12
IMP M 14.003 IMPRESSION TYPE A 2 2 1 1 9
SRC M 14.004 SOURCE AGENCY / ORI AN 10 21 1 1 28
TCD M 14.005 TENPRINT 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 A 5 7 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
RSV 14.014
14.019
RESERVED FOR FUTURE
DEFINITION
-- -- -- -- -- --
COM O 14.020 COMMENT A 2 1 28 0 1 128
RSV 14.021
14.199
RESERVED FOR FUTURE
DEFINITION
-- -- -- -- -- --
UDF O 14.200
14.998
USER-DEFINED FIELDS -- -- -- -- -- --
DAT M 14.999 IMAGE DATA B 2 -- 1 1 --
Key for character type: N = Numeric; A = Alphabetic; AN = Alphanumeric; B = Binary
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 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.
21.1.2 Field 14.002: Image designation character
(IDC)
This mandatory ASCII field shall be used to identify
the tenprint fingerprint image 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 Field 14.003: Impression type (IMP)
This mandatory one-byte ASCII field shall indicate
the manner by which the tenprint image information
was obtained. The appropriate code selected
from Table 5 shall be entered in this field.
21.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 tenprint 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 20 identifying characters
and the data content of this field shall be
defined by the user and be in accordance with the
receiving agency.
ANSI/NIST-ITL 1-2000
41
21.1.5 Field 14.005: Tenprint capture date (TCD)
This mandatory ASCII field shall contain the date
that the tenprint image was captured. The date
shall appear as eight digits in the format
CCYYMMDD. The CCYY 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, the entry 20000229 represents February
29, 2000. The complete date must be a legitimate
date.
21.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.
21.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.
21.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.
21.1.9 Field 14.009: 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.
21.1.10 Field 14.010: 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.
21.1.11 Field 14.011: Compression algorithm
(CGA)
This mandatory ASCII field shall specify the algorithm
used to compress 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 preferred method for the
compression of tenprint fingerprint images. For
grayscale images, the domain registrar maintains
a registry of acceptable compression techniques
and corresponding codes that may be used as
they become available.
21.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 or less than 8 shall represent a
grayscale pixel with increased or decreased precision
respectively.
21.1.13 Field 14.013: Finger position (FGP)
This mandatory tagged-field shall contain 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 6 and entered as a one- or twocharacter
ASCII subfield. Table 6 also lists the
maximum image area that can be transmitted for
each of the fourteen 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.
21.1.14 Field 14.014-019: 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.
21.1.15 Field 14.020: Comment (COM)
This optional field may be used to insert comments
or other ASCII text information with the
tenprint image data.
ANSI/NIST-ITL 1-2000
42
21.1.16 Field 14.021-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.
21.1.17 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.
21.1.18 Field 14.999: Image data (DAT)
This 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. For example, 14.999: is followed
by 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 or less 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.
21.2 End of Type-14 variable-resolution tenprint
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.
21.3 Additional variable-resolution tenprint image
records
Additional Type-14 records may be included in
the file. For each additional tenprint image, a
complete Type-14 logical record together with the
“FS” separator is required.
22 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, or from a
palmprint card or other media that contains the
subjects 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 writers
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 that are both located
over the interdigital area of the 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 writers palm and the full
palm image(s) from each hand. Since a taggedfield
logical image record may contain only one
binary field, a single Type-15 record will be required
for each writers palm and one or two
Type-15 records for each full palm. Therefore,
four to six Type-15 records will be required to represent
the subjects palmprints in a normal
palmprint transaction.
ANSI/NIST-ITL 1-2000
43
22.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. 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 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 including
the “GS” character.
22.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.
22.1.2 Field 15.002: Image designation character
(IDC)
This mandatory ASCII field shall be used to identify
the palmprint image contained in the record.
This IDC shall match the IDC found in the file
content (CNT) field of the Type-1 record.
22.1.3 Field 15.003: Impression type (IMP)
This mandatory one-byte ASCII field shall indicate
the manner by which the palmprint image information
was obtained. The appropriate code selected
from Table 18 shall be entered in this field.
22.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 20 identifying
characters and the data content of this field shall
be defined by the user and be in accordance with
the receiving agency.
22.1.5 Field 15.005: Palmprint capture date (PCD)
This mandatory ASCII field shall contain the date
that the palmprint image was captured. The date
shall appear as eight digits in the format
CCYYMMDD. The CCYY 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, the entry 20000229 represents February
29, 2000. The complete date must be a legitimate
date.
22.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.
22.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.
22.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.
22.1.9 Field 15.009: 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.
22.1.10 Field 15.010: 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,
ANSI/NIST-ITL 1-2000
44
Table 17 – 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 21 1 1 28
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 5 7 1 1 14
BPX M 15.012 BITS PER PIXEL N 2 3 1 1 10
PLP M 15.013 PALMPRINT POSITION N 2 3 1 1 10
RSV 15.014
15.019
RESERVED FOR FUTURE
INCLUSION
-- -- -- -- -- --
COM O 15.020 COMMENT AN 2 1 28 0 1 128
RSV 15.021
15.199
RESERVED FOR FUTURE
INCLUSION
-- -- -- -- -- --
UDF O 15.200
15.998
USER-DEFINED FIELDS -- -- -- -- -- --
DAT M 15.999 IMAGE DATA B 2 -- 1 1 --
Key for character type: N = Numeric; A = Alphabetic; AN = Alphanumeric; B = Binary
Table 18 – Palm impression type
Description Code
Live-scan palm 10
Nonlive-scan palm 11
Latent palm impression 12
Latent palm tracing 13
Latent palm photo 14
Latent palm lift 15
it indicates the vertical component of the pixel
aspect ratio.
22.1.11 Field 15.011: Compression algorithm (CGA)
This mandatory ASCII field shall specify the algorithm
used to compress 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 preferred method for the
compression of tenprint fingerprint images. For
grayscale images, the domain registrar maintains
a registry of acceptable compression techniques
and corresponding codes that may be used as
they become available.
22.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 or less than 8 shall represent a
grayscale pixel with increased or decreased precision
respectively.
ANSI/NIST-ITL 1-2000
45
Table 19 – Palm codes, areas, & sizes
Palm
Position
Palm
code
Image area
(mm2)
Width
(mm) (in)
Height
(mm) (in)
Unknown Palm 20 28387 139.7 5.5 203.2 8.0
Right Full Palm 21 28387 139.7 5.5 203.2 8.0
Right Writers Palm 22 5645 44.5 1.8 127.0 5.0
Left Full Palm 23 28387 139.7 5.5 203.2 8.0
Left Writers Palm 24 5645 44.5 1.8 127.0 5.0
Right Lower Palm 25 19516 139.7 5.5 139.7 5.5
Right Upper Palm 26 19516 139.7 5.5 139.7 5.5
Left Lower Palm 27 19516 139.7 5.5 139.7 5.5
Left Upper Palm 28 19516 139.7 5.5 139.7 5.5
Right Other 29 28387 139.7 5.5 203.2 8.0
Left Other 30 28387 139.7 5.5 203.2 8.0
22.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 19 and entered as a
two-character ASCII subfield. Table 19 also lists
the maximum image areas and dimensions for
each of the possible palmprint positions.
22.1.14 Field 15.014-019: 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.
22.1.15 Field 15.020: Comment (COM)
This optional field may be used to insert comments
or other ASCII text information with the
palmprint image data.
22.1.16 Field 15.021-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.
22.1.17 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.
22.1.18 Field 15.999: Image data (DAT)
This 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. For example,
15.999: is followed by 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 or
less 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.
22.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.
ANSI/NIST-ITL 1-2000
46
Table 20 – Type-16 User-defined testing 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
UDF O 16.003
16.005
USER-DEFINED FIELDS -- -- -- -- -- --
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 5 7 1 1 14
BPX M 16.012 BITS PER PIXEL N 2 3 1 1 10
UDF O 16.013
16.998
USER-DEFINED FIELDS -- -- -- -- -- --
DAT M 16.999 IMAGE DATA B 2 -- 1 1 --
Key for character type: N = Numeric; A = Alphabetic; AN = Alphanumeric; B = Binary
22.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.
23 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 taggedfield
user-defined logical record to be used for
developmental 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.
23.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 taggedfields
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 20 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
ANSI/NIST-ITL 1-2000
47
byte count includes the field number, the information,
and all the character separators including
the “GS” character.
23.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.
23.1.2 Field 16.002: Image designation character
(IDC)
This mandatory ASCII field shall be used to identify
the image 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 Fields 16.003-005: 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.4 Field 16.006: Horizontal line length (HLL)
This mandatory ASCII field shall contain the number
of pixels present on a single horizontal line of
the transmitted image.
23.1.5 Field 16.007: Vertical line length (VLL)
This mandatory ASCII field shall contain the number
of horizontal lines present in the transmitted
image.
23.1.6 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.
23.1.7 Field 16.009: 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.
23.1.8 Field 16.010: 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.
23.1.9 Field 16.011: Compression algorithm (CGA)
This mandatory ASCII field shall specify the algorithm
used to compress the image. An entry of
"NONE" in this field indicates that the data contained
in this record is uncompressed. The domain
registrar maintains a registry of acceptable
compression techniques and corresponding
codes that may be used as they become available.
23.1.10 Field 16.012: Bits per pixel (BPX)
This mandatory ASCII field shall contain the number
of bits used to represent a pixel.
23.1.11 Fields 16.013-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.12 Field 16.999: Image data (DAT)
This field shall contain all of the pixel data from a
captured unspecified 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.
23.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.
ANSI/NIST-ITL 1-2000
48
23.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.
24 Another individual
If fingerprint 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.
ANSI/NIST-ITL 1-2000
49
Annex A - 7-bit ANSI code for information interchange
(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