FBI Fingerprint Format

Also Known As: FBI WSQ


Type Bitmap
Colors 8-bit grayscale
Compression Wavelet Scalar Quantization
Maximum Image Size 64Kx64K
Multiple Images Per File No
Numerical Format Big-endian
Originator U.S. Federal Bureau of Investigation
Platform All
Supporting Applications Many
See Also None

Usage
The standard file format used by the FBI for storage and interchange of grayscale fingerprint images.

Comments
If you need to store compressed fingerprint or similar images then this is your format.


In the USA, fingerprints have traditionally been collected on cards, each card containing the inked impressions of all ten fingers. The U.S. Federal Bureau of Investigation's fingerprint database began in 1924 with a cataloged collection of 810,188 cards. By the start of World War II, this collection had grown to over 10 million cards, and by 1946 had reached over 100 million cards. Today this collection is contained on over 200 million cards stored in filing cabinets occupying one acre of floor space in the J. Edgar Hoover building in Washington D.C. Nearly 30 million of these are "master cards" containing the fingerprints of criminal suspects. Once a card is added to the FBI's collection it is not deaccessioned for several decades, and many duplicates do exist.

Contents:
File Organization
File Details
For Further Information

How much time it would take to visibly inspect each card for a match, even by a large army of trained researchers, is nearly unimaginable. Add the fact that this collection grows by 30,000 to 50,000 new cards per day, and you have a problem that cannot be solved without using modern computers and imaging technology.

The FBI's Integrated Automated Fingerprint Identification System (IAFIS) is part of a project to design and implement a national standard for collecting, encoding, storing, and retrieving digitized fingerprint images. Fingerprints are stored as 8-bit grayscale images. A typical fingerprint card results in about 10 megabytes of scanned bitmap data. The FBI's entire collection would therefore consume two petabytes (2,000,000,000 megabytes) of electronic storage space. At 9600bps one set of prints would require nearly three hours to transmit. You figure out how long it would take to transmit the entire database.

To compress each fingerprint bitmap, the Wavelet Scalar Quantization (WSQ) grayscale fingerprint image compression algorithm is used. WSQ is a lossy compression method that is well-suited for preserving the very high resolution details of grayscale images while maintaining high compression ratios of typically 12:1 to 15:1 on images that have not under gone "quality enhancements" (such as histogram equalization) to improve the appearance of the image.

Most lossy compression methods, such as JPEG, discard the smallest (highest frequency) details in images, and at higher compression ratios unacceptably distorts the image. Contained within fingerprints are tiny details that are considered admissible points of identification in a court of law. To JPEG, these details may be regarded as noise and removed. The JPEG quantization matrix also allows blocking artifacts to occur in the image at compression ratios above about 10:1. Shifting bits to the high frequencies to preserve small details will only make the blocking worse.

Lossless compression methods, such as LZW and JBIG, cannot achieve the high compression ratios of WSQ on fingerprint data, with 2:1 typically being the best.

Fingerprint data is scanned from a paper card as a 500 to 520 dot per inch, 8 bits per pixel, grayscale bitmap and stored using an uncompressed, headerless format[1]. These files are just a dump of the raw output from a scanner and are therefore given the extension ".raw". Scanned data requiring the storage of header information (height, width, pixel depth, etc.) may be stored using any format that supports 8bpp grayscale bitmaps, such as TIFF or Microsoft Window BMP.

[1] The ANSI standard, "Data Format for the Interchange of Fingerprint Information" (ANSI/NIST-CSL 1-1993), is also used for storing uncompressed fingerprint data. This format is basically, a "digital fingerprint card," with fields for scanning resolution, various types of records, coded fingerprint classification data, signature records, and so forth. The individual fingerprint images within such a "card" may or may not be compressed using the FBI WSQ algorithm.

When the grayscale fingerprint data is compressed using WSQ, the resulting encoded data is stored in what is referred to as a WSQ file (typically with the file extension ".wsq"). WSQ files are therefore just a dump of WSQ-encoded bitmap data.

The FBI has defined an interchange format that allows the exchange of WSQ-encoded fingerprint data between different software applications. FBI WSQ interchange files store the WSQ-compresses bitmap data and all information required to decompress the data. Human-readable text comments may also be stored in the files. Such interchange files are called FBI fingerprint files and have the file extension ".fbi".

NOTE:

The information in this section is derived from v2 of the FBI WSQ standard. The information in v2 is known to have several minor typos that will be revised in v3 of the specification. Version 3 was not yet available at the time of this writing.

File Organization

The format of FBI files strongly resembles that of JFIF. It is obvious that JPEG and JFIF served as a blueprint for the structure of WSQ data and the FBI WSQ file format. Despite the similarities of the formats, WSQ and JPEG are very different algorithms and are not compatible.

Like JFIF, the FBI WSQ interchange format is composed of data structures called marker segments and entropy-coded data segments (ECS). Marker segments contain a unique marker value followed by a set of data called marker parameters. Entropy-coded data segments contain only compressed bitmap data or fill bits.

Each marker segment begins with a 2-byte identification value, called a marker value, that identifies the types of data stored in the segment. The segment data then follows the marker value (Figure FBI-1).

Figure FBI-1: Marker segment

[Graphic: Figure FBI-1]

The first byte of a marker code is always FFh and identifies the possible start of a marker segment. The second value may be any byte value, except 00h and FFh, and identifies the type of data stored in the marker segment (Table FBI-1). The SOI, EOI, and RSTn marker codes are not followed by any marker segment data.

Table FBI-1: Marker Codes
FFA0h SOI Start Of Image
FFA1h EOI End Of Image
FFA2h SOF Start Of Frame
FFA3h SOB Start Of Block
FFA4h DTT Define Transform Table
FFA5h DQT Define Quantization Table
FFA6h DHT Define Huffman Table(s)
FFA7h DRI Define Restart Interval
FFA8h COM Comment
FFBnh RSTn Restart with modulo 8 count n (n = 0 to 7)

FFh byte values are also used as fill values that may precede any marker segment. Any FFh value that is part of actual data is always followed by a 00h byte value to indicate that the FFh byte is not the start of a marker code or being used as fill (Table FBI-2).

Table FBI-2: Examples of FFh Byte Usage
FFA1 FFh as the first byte of an EOI marker)
FFFFFFFFFFA0h Four FFh fill bytes preceding an SOI marker)
FF00FF00FF00h Three byte of data interpreted as FFFFFFh)

The marker segment data always begins with a 16-bit value indicating the number of bytes stored in the segment data. This length value does not include the two bytes used to store the marker code itself. And as this length value is part of the segment data, the length will always be at least two. If a marker segment has no associated data, then no segment length value will be present. It is therefore necessary that a file reader know which marker segments are not followed by data.

Every FBI data stream begins with a Start Of Image (SOI) marker segment, followed by a single frame of image data, and ends with an End Of Image (EOI) marker segment. Data the precedes the SOI marker, or follows the EOI marker, should be ignored (unless it is another FBI data stream). The entire data stream itself will be embedded in an ANSI/NIST CSL 1-1993 "digital fingerprint card".

SOI Marker
Frame
EOI Marker

The Frame contains a single, WSQ-encoded bitmap and all of the information necessary to interpret the bitmap data. The frame header contains all of the typical information you would expect to see in an image file header.

Following the frame header is three to eight blocks of data. Each block contains a header and one or more entropy-encoded data segments. Each of these segments contains quantized subbands that are concatenated into the block and then Huffman encoded into a single stream of data. Each subband contains different spatial frequency components of the image data. Subbands do not have separate headers, so the decoder must determine the size of each subband using the number of DWT coefficients prior to decoding, so the data can be parsed out to the correct subbands as the block is decoded.

Immediately prior to the frame header and to each block header, optional marker segments may be placed as needed. The optional marker segments include transform table specification, quantization table specification, Huffman table specification, restart interval definition specification, or comment (Figure FBI-2).

Figure FBI-2. Expanded format of an FBI data stream

[Graphic: Figure FBI-2]

Two variations of the FBI format has also been defined. The first variation is used to store only WSQ-compressed bitmap data. If an FBI file contains image data, but only some or none of the required table data, then it is the "abbreviated format for compressed image data".

The second variation only stores the table-specification data used to interpret the compressed data. If an FBI file contains some or all of the required table data (transform, quantization, and Huffman), but no compressed image data, then it is the "abbreviated format for table-specification data".

SOI
Optional Segments
EOI

The maximum size of an FBI WSQ image is 65536x65536 pixels, but the practical sizes encountered are based on the sizes of the images on the fingerprint cards that are scanned at a resolution of 520 dpi:

Card Size (in inches) Image size (in pixels)
1.500x1.500 780x780
0.875x1.875 455x975
3.125x1.875 1625x975

Header Data

The following sections describe the various headers and header markers of the format.

Start Of Image Marker

The Start Of Image (SOI) marker indicates the beginning of an FBI interchange stream. The SOI is composed of a single marker code and must appear prior to all other marker segments in an FBI interchange data stream. This marker contains no associated segment data.

typedef struct _StartOfImage
{
    WORD Marker;    /* Start Of Image Marker (FFA0h) */
} STARTOFIMAGE;

Marker is the marker code that indicates the Start Of Image marker. This value is always FFA0h.

End Of Image Marker

The End Of Image (EOI) marker indicates the end of the FBI data stream. The EOI is composed of a single marker code and always appears as the last marker in an FBI interchange data stream. This marker contains no associated segment data.

typedef struct _EndOfImage
{
    WORD Marker;    /* End Of Image Marker (FFA1h) */
} ENDOFIMAGE;

Marker is the marker code that indicates the End Of Image marker. This value is always FFA1h.

Start Of Frame Marker

The Start Of Frame (SOF) marker segment is the header for the image data and has the following format:

typedef struct _StartOfFrame
{
    WORD Marker;    /* Start of Frame Segment (FFA2h) */
    /* 
    ** Marker segment data
    */
    WORD Length;    /* Length of segment in bytes */
    BYTE Black;     /* Scanner black calibration value */
    BYTE White;     /* Scanner white calibration value */
    WORD Lines;     /* Number of lines */
    WORD Samples;   /* Number of samples per line */
    BYTE ScaleExpM; /* Scale exponent for location value */
    WORD Location;  /* Location value for image transform parameters */
    BYTE ScaleExpR; /* Scale exponent scale value/
    WORD ScaleVal;  /* Scale value for image transform parameters */
    BYTE Algorithm; /* WSQ algorithm identifier */
    WORD Software;  /* Software implementation identifier */
} STARTOFFRAME;

Marker is the marker code that indicates the start of a frame header. This value is always FFA2h.

Length is the number of bytes in the frame header data segment, including the Length field. This value is typically 17.

Black and White are the black and white scanner calibration values used to record the dynamic range of the scanner for use in display systems.

Lines is the number of lines in the source image.

Samples is the number of samples (8-bit pixel) per line in the source image.

ScaleExpM indicates the number of places the decimal point in the Location value is shifted to the left.

Location is the location value for image transform parameters.

ScaleExpR indicates the number of places the decimal point in the ScaleVal value is shifted to the left.

ScaleVal is the scale value for image transform parameters.

Algorithm identifies the WSQ encoder algorithm (parameters) used on the image data. The algorithm identifier is associated with a particular FBI-approved encoder and indicates which encoder a particular file was encoded using. This value is currently 01h. However, this value will change between revisions of the standard as new encoder algorithms are approved. So be prepared to design your WSQ decoder to "gracefully fail" if it doesn't recognise the value in this field.

Software identifies the software that encoded the image data.

Start Of Block Marker

The Start Of Block (SOB) Marker segment is a header the precedes each subband of image data. This header has the following format:

typedef struct _StartOfBlock
{
    WORD Marker;    /* Start of Block Marker (FFA3h) */
    /* 
    ** Marker segment data
    */
    WORD Length;    /* Length of segment in bytes */
    BYTE Selector;  /* Huffman coding table selector */
} STARTOFBLOCK;

Marker is the marker code that indicates the start of a Start Of Block header. This value is always FFA3h.

Length is the number of bytes in the Start Of Block data segment, including the Length field. This value is typically 3.

Selector is the Huffman coding table selector that specifies which one of eight possible entropy encoding tables needed for decoding the subband within this segment.

Define Transform Table

The Define Transform Table (DTT) contains a small header that includes the DTT marker, table length, and the length of the two arrays in the table. Each table contains one or more 6-byte elements. These elements are the filter impulse response taps (floating point values), and are coded with 6-byte precision using three separate parameters. The DTT table has the following format:

typedef struct _DefineTransformTable
{
    WORD  Marker;                /* Define Transform Table Marker (FFA4h) */
    /* 
    ** Marker segment data
    */
    WORD  Length;                /* Length of segment in bytes */
    BYTE  NumLPCoeffs;           /* Number of Low Pass Coefficients */
    BYTE  NumHPCoeffs;           /* Number of High Pass Coefficients */
    struct _LowPassCoef
    {
        BYTE  CoefSign;          /* Sign of the filter coefficient */
        BYTE  ScaleExponent;     /* Scale exponent of the filter coefficient */
        DWORD LPCoeff;           /* Low pass analysis filter element */
    } LowPassCoef[];
    struct _HighPassCoef
    {
        BYTE  CoefSign;          /* Sign of the filter coefficient */
        BYTE  ScaleExponent;     /* Scale exponent of the filter coefficient */
        DWORD HPCoeff;           /* High pass analysis filter element */
    } HighPassCoef[];
} DEFINETRANSFORMTABLE;

Marker is the marker code that indicates the start of a Define Transform Table. This value is always FFA4h.

Length is the number of bytes in the transform table data segment, including the Length field.

NumLPCoeffs is the number of analysis low pass filter coefficients (the length of the unfolded low pass filter). This value is used to determine number of elements in the LowPassCoef array using the following method: If the value of NumLPCoeffs is even, then it is divided by 2 (NumLPCoeffs / 2). If the value is odd, then it is first incremented by 1 and then divided by two ((NumLPCoeffs + 1) / 2).

NumHPCoeffs is the number of analysis high pass filter coefficients (the length of the unfolded high pass filter). This value is used to determine number of elements in the HighPassCoef array using the following method: If the value of NumHPCoeffs is even, then it is divided by 2 (NumHPCoeffs / 2). If the value is odd, then it is first incremented by 1 and then divided by two ((NumHPCoeffs + 1) / 2).

CoefSign specifies the sign extension of the filter coefficient for the current table entry. A value of 0 indicates positive and a non-zero value indicates negative.

ScaleExponent indicates the number of places the decimal point of the current filter coefficient is move to the left.

LPCoeff is the filter low pass coefficients for the DWT. For each LowPassCoef object, this is the mantissa of the floating point number represented by that object.

HPCoeff is the filter high pass coefficients for the DWT. For each HighPassCoef object, this is the mantissa of the floating point number represented by that object.

Each _LowPassCoef and _HighPassCoef object represents a single floating point number (called a "tap" in signal processing) stored as three components: a sign byte, a base-10 exponent, and an integer "mantissa". For example, the floating point value -0.089 (-89e-03) would be represented by the triple:

	CoefSign = 1       (nonzero is negative)
	ScaleExponent = 3
	LPCoef = 89

The arrays LowPassCoef[] and HighPassCoef[] of such objects contain the right half of the (symmetric or antisymmetric) filter. For example, if the length NumLPCoeffs is odd then the filter is symmetric about its midpoint, which is the first array element, LowPassCoef[0].

Define Quantization Table

The Define Quantization Table (DQT) stores data that is a set of quantization values used to quantize DWT coefficients within the subbands. The format of this table is as follows:

typedef struct _DefineQuantizationTable
{
    WORD  Marker;                /* Define Quantization Table Marker (FFA5h) */
    /* 
    ** Marker segment data
    */
    WORD  Length;                /* Length of table in bytes */
    BYTE  ScaleExpCenter;        /* Scale exponent of center */
    WORD  QuantBinCenter;        /* Quantizer Bin Center Parameter */
    struct _BinSizeTable
    {
        BYTE ScaleExpK;          /* Scale exponent of K */
        WORD QuantBinSize;       /* Quantization bin size */
        BYTE ZeroBinScaleExp;    /* Scale exponent of bin */
        WORD ZeroBinElement;     /* Zero bin quantization table element */
    } BinSizeTable[64];
} DEFINEQUANTIZATIONTABLE;

Marker is the marker code that indicates the start of a Define Quantization Table. This value is always FFA5h.

Length is the number of bytes in the quantization table data segment, including the Length field.

ScaleExpCenter is the number of places that the decimal point in the quantizer bin center parameter is moved to the left.

QuantBinCenter is the quantizer bin center parameter.

ScaleExpK is the number of places that the decimal point in the current quantization table element is moved to the left.

QuantBinSize is the quantization bin size for the current subband.

ZeroBinScaleExp is the number of places that the decimal point in the current zero bin quantization table element is moved to the left.

ZeroBinElement is the zero bin quantization table element. This element specifies the center (zero) bin size for the current subband.

Define Huffman Tables

The Define Huffman Table (DHT) specification data is a set of variable-length codes used by the Huffman encoder and decoder. The procedure for constucting these codes was taken from Annex K.2 of the ISO JPEG DIS 10918-1 JPEG specification. This table will contain three or more Define Huffman Table segements, each of which are of a different length. The format of this table is as follows:

typedef struct _DefineHuffmanTable
{
    WORD  Marker;               /* Huffman Marker (FFA6h) */
    /* 
    ** Marker segment data
    */
    WORD  Length;               /* Length of segment in bytes */
    DHTSEGMENT DHTSegements[];  /* Segements of Huffman table data */
} DEFINEHUFFMANTABLE;

Marker is the marker code that indicates the start of a Huffman Table. This value is always FFA6h.

Length is the number of bytes in the Huffman table data segment, including the Length field. The Length value will vary for different Huffman tables. The codes of each length (CodeLengths) are different depending on the Huffman coder, so the number of symbols (HuffmanCodes) for each code-length will vary as well.

HDTSegments is an array of Define Huffman Table Segements. There are typically three for more segments in a Define Huffman Table and each segement has the following format:

typedef struct _DHTSegment
{
    BYTE Identifier;        /* Huffman table identifier */
    BYTE CodeLengths[16];   /* Huffman code counts (BITS) */
    BYTE HuffmanCodes[];    /* Huffman values (HUFVAL) */
} DHTSEGMENT;

Identifier is the Huffman table identifier. This value specifies one of eight possible destinations at the decoder into which the Huffman table shall be installed.

CodeLengths stores the number of Huffman codes of a specific length of the 16 possible lengths.

HuffmanCodes are the values associated with each Huffman code. The length of this field varies and is not known prior to the actual encoding.

Define Restart Intervals

Define Restart Intervals (DRI) are used to isolate entropy-encoded data segments within each block of data. If restart is not enable, then there will be only one entropy-encoded data segment and no restart intervals. If restart is enabled, one restart marker will follow each entropy-encoded data segment except the last. The number of entropy-encoded data segments is determined by size of the image and the number of restart intervals.

Restart intervals allows features such as progressive encoding and skipping over corrupt data to exist. The format of a Restart Interval is as follows:

typedef struct _DefineRestartInterval
{
    WORD Marker;        /* Restart Interval Marker (FFA7h) */
    /* 
    ** Marker segment data
    */
    WORD Length;        /* Length of segment in bytes */
    WORD Interval;      /* Restart Interval */
} DEFINERESTARTINTERVAL;

Marker is the marker code that indicates the start of a Restart Interval. This value is always FFA7h.

Length is the number of bytes in the Restart Interval data segment, including the Length field. This value is typically 4.

Interval specifies the number of quantized DWT coefficients in all subsequent restart intervals, which are delimited by Restart (RSTn) markers. Restart intervals contain the number of DWT coefficients indicated by this field, except for the last restart interval in a block, which may contain fewer coefficients.

Comment Marker

The Comment (COM) marker stores (typically) human-readable text that may be displayed by a software application or if an FBI file is viewed as data. Comment markers may also be used to provide alignment padding, but it is more appropriate to use FFh byte values added prior to marker codes for filler, or 1-bits to fill an entropy coded segment to a byte boundary.

typedef struct _Comment
{
    WORD Marker;            /* Comment Marker (FFA8h) */
    /* 
    ** Marker segment data
    */
    WORD Length;            /* Length of segment */
    BYTE Comment[Length-2]; /* Text comment */
} COMMENT;

Marker is the marker code that indicates the start of a comment. This value is always FFA8h.

Length is the number of bytes in the comment data segment, including the Length field. This value may range from 2 to 65535.

Comment is the text data. he format for the data in this field is undefined.

Restart Markers

Restart Markers (RSTn) are optional markers that are placed between entropy-coded segments if restart is enabled. There are eight unique restart markers which repeat in sequence from 0 to 7, as indicated by the value of the marker code. The Restart marker has no associated segment data:

typedef struct _Restart
{
    WORD Marker;    /* Restart Marker (FFB0h to FFB7h) */
} RESTART;

Marker is the marker code that indicates the beginning of a specific restart interval. This value is in the range of FFB0h to FFB7h.

Image Data

As previously noted, the original fingerprint data is stored as an 8 bits per pixel, grayscale bitmap and encoded using the WSQ grayscale fingerprint image compression algorithm. WSQ uses a discrete wavelet transform (DWT) implemented by a multirate filter bank that maps a digital input signal to a collection of quantized subbands. The subbands are then concatenated into a block and Huffman-encoded into a single stream of data, interrupted only by restart markers (Figure FBI-3). The decoder is responsible for counting the number of decoded DWT coefficients and deciding when the decoded stream passes from one subband to the next.

Figure FBI-3: DWT-based encoding

[Graphic: Figure FBI-4]

WSQ is a symmetrical encoding method. That is, the complexities of encoding and decoding are very similar (Figure FBI-4). WSQ is also a lossy encoding method and the decoded data is not identical to the original data. However, because of the rate-control methods applied to control the quantization in the initial encoding, and the "encode once, decode many" philosophy used by the FBI's fingerprint archival system, in this implementation WSQ works very well.

Figure FBI-4: DWT-based decoding

[Graphic: Figure FBI-4]

Both WSQ and JPEG operate on the concept of "an acceptable level of distortion". In JPEG, the Q factor is used to control the quality of a compressed image. The greater the quality the larger the resulting data size. The user "tunes" each image by adjusting the Q factor to produce a JPEG-compressed image with a maximum acceptable level of distortion.

WSQ has a similar mechanism called the "target bit rate". Lower bit rates result in higher compression ratios, but also in more severely degraded images as the WSQ encoder throws data away. The FBI specifies a target bit rate of approximately 0.75 bits per pixel, depending upon the system, which yields typical compression ratios of 15:1. Unacceptable artifacts (blocking) occurs in JPEG-compressed fingerprint images at about 10:1 compression.

Both the WSQ target bit rate and the JPEG Q factor should be thought of as the level of acceptable distortion rather than a tool to achieve a specific file size or an exact compression ratio.

For Further Information

The FBI fingerprint file format, and the wavelet/scalar quantization compression method, are fully described in the following documents:

Data Format for the Interchange of Fingerprint Information, ANSI Standard, ANSI/NIST-CSL 1-1993.

Hopper, Tom, Johnathan N. Bradley, and Christopher M. Brislawn, "The FBI Wavelet/Scalar Quantization Fingerprint Image Compression Standard", US Federal Bureau of Investigation, February 16, 1993, IAFIS-IC-0110v2

Many WSQ resources, including the FBI WSQ FAQ, may be found at the following FTP archive:

ftp://ftp.c3.lanl.gov/pub/WSQ/

Sample WSQ images may be found at:

ftp://ftp.c3.lanl.gov/pub/WSQ/print_data
ftp://ftp.c3.lanl.gov/pub/WSQ/WWWdemo
ftp://pegasus.ncsl.nist.gov/pub/cmp_imgs/

A large collection of uncompressed fingerprint data is available on CD-ROM from:

Standard Reference Data
National Institute of Standards and Technology
221/A320
Gaithersburg, MD 20899
Voice: 301-975-2208
Fax: 301-926-0416
Email: Craig Watson <craig@magi.ncsl.nist.gov>

The ftp://ftp.c3.lanl.gov/pub/WSQ/documents directory contains the following documents in compressed (.Z) PostScript format:

"WSQ gray-scale fingerprint image compression specification", ver. 2.0, 2/16/93. Document #IAFIS-IC-0110v2, FBI.

This is the FBI WSQ compression algorithm standard.

"Classification of nonexpansive symmetric extension transforms for multirate filter banks," revised 3/5/96. Los Alamos Tech Report LA-UR-94-1747.

Includes description of WSQ wavelet transform algorithm.

"The FBI Wavelet/Scalar Quantization Standard for gray-scale fingerprint image compression." In Proc. SPIE (Orlando, 4/93), v. 1961, pp. 293-304, SPIE.

"Proposed first-generation WSQ bit allocation procedure." Proc. Symp. Criminal Justice Info. Services Tech. (Gaithersburg, MD, 9/93), pp. C11-C17, FBI.

"The wavelet/scalar quantization compression standard for digital fingerprint images." In Proc. IEEE ISCAS-94 (London, 5/94), v. 3, pp. 205-208.

"The FBI wavelet/scalar quantization fingerprint image compression standard." Proc. Conf. Solid-State Memory Tech. (Pasadena, 5/94), pp. A11-A14, National Media Lab.

Hardcopies of these documents are available from:

Christopher M. Brislawn
Los Alamos National Laboratory
Computer Research/Applications
Los Alamos, NM 87545-1663
Voice: 505-665-1165
Email: brislawn@lanl.gov

Other journal articles of interest are:

Bradley, Johnathan N. and Christopher M. Brislawn, "1992 Progress Report: Compression of Fingerprint Data Using the Wavelet Vector Quantization Image Compression Algorithms", Los Alamos National Laboratory, April 1992, Tech Report #LA-UR-92-1507.

Brislawn, Christopher M, "Classification of Symmetric Wavelet Transforms", Los Alamos National Laboratory, August 1992, Tech Report #LA-UR-92-2823.

Hopper T., F. Preston, "Compression of Gray-Scale Fingerprint Images", Proceedings Data Compression Conference, Snowbird, Utah, March 24-27, 1992, pp. 309-318.

The closest thing to an FBI/WSQ home page may be found at:

http://www.c3.lanl.gov/~brislawn/FBI/FBI.html

The FBI Fingerprint Image Compression Standard

For more information on wavelet transforms and theory, check out the following Web pages:

http://www.mathsoft.com/wavelets.html

Wavelet Resources

http://www.best.com/~agraps/current/wavelet.html

Amara's Wavelet Page

http://www.mat.sbg.ac.at/~uhl/wav.html

Andreas Uhl's Wavelet Page

It should be noted that there is a program available on the Internet from Washington University in St. Louis that creates WSQ-compressed files. This program is not close to being an accurate implementation of the FBI standard and is certainly not certified by the FBI and NIST as a compliant implementation of the FBI WSQ standard. Any files created through the use of this program (and all other uncertified programs) should not be regarded as conforming to the FBI WSQ standard.

Information on FBI-certified software that implements the FBI WSQ standard may be obtained from:

Tom Hopper
US Federal Bureau of Investigation
Voice: 202-324-3506
Email: teh@cais.cais.com



Copyright © 1996 O'Reilly & Associates, Inc. All Rights Reserved.