1 

SLAPSEGII 

Slap Fingerprint Segmentation Evaluation II 

Draft Testing Plan 

Updated July 23, 2008 

Craig Watson 

NIST 

July 2008 
2 

Abstract 

In 2004, NIST conducted a fingerprint slap segmentation study [1] to assess the 

state-of-the-art in fingerprint segmentation technology. Given the development of 

new technology it has become necessary to reassess the current state-of-the-art 

of segmentation algorithms. SlapSegII will give providers of this technology the 

opportunity to participate multiple times as their technology improves and 

compare their results to previous results on a fixed standard database. The 

SlapSegII testing strategy, evaluation data, and measure of successful 

segmentation are discussed in detail in this testing plan. 

1. Introduction/Background 

Fingerprint data is collected and maintained in the form of Ten-print cards or 

Identification Flats (ID Flats). Traditional Ten-print cards are comprised of the 

rolled impressions of the ten fingers as well as four slap impressions: the left slap 

(four fingers of the left hand), the right slap (the four fingers of the right hand) and 

the thumb slap (the left and right thumbs). Slaps are taken by pressing the four 

fingers of one hand onto a scanner or fingerprint card simultaneously. The Tenprint card slaps whether scanned inked cards or live-scan capture are also 

referred to in this document as 2 inch data which refers to the height of the 

capture area for the fingerprint slaps. ID Flats are Ten-print fingerprint records 

which are constructed by capturing three discrete impressions: left slap, right 

slap, and both thumbs together. For this document the ID Flats are data that was 

captured on new live-scan devices that use a larger platen that is 3 inches in 

height so this data is also referred to as 3 inch data. 

Currently the Federal Bureau of Investigation (FBI) receives the majority of their 

fingerprint submissions electronically from live-scan devices, however, hundreds 

of millions of legacy fingerprint transactions are stored that were originally taken 

on paper cards and electronically converted. The Department of State (DOS) and 

Department of Homeland (DHS) US-VISIT program are migrating from 2 finger 

capture to 10 print ID Flats capture so the ability to evaluate and improve 

segmentation technology on this type of data will have a significant impact on 

those agencies. 

2. Purpose of Slap Fingerprint Segmentation (SlapSeg) 

Slap fingerprints are noted for the speed at which they can be documented and 

processed. However, a slap record is an image of multiple fingers. Fingerprint 

images must be matched against individual fingerprint images, not an image of a 

group of fingers. Thus, it is necessary to quickly and accurately separate, or 

segment, the grouped image of prints into individual fingerprint images which can 

be used for matching. 
3 

2.1. Definition 

Slap segmentation is the process by which a single image containing four 

fingerprint images is divided into four images of the individual fingers or by 

finding the fingerprint segmentation positions and using them to separate the 

image into individual images at a later date. The term fingerprint segmentation 

positions refer to the expected positions of each of the four fingers and thumb of 

each hand relative to an adjacent finger of the hand. The fingerprint 

segmentation positions are defined in the ANSI/NIST-ITL 1-2007 data 

transmission standard (type-14 record) [4] for non-rotated segmentation boxes as 

the x-coordinate of the left and right edge and the y-coordinate of the top and 

bottom edge of the segmentation box. For rotated fingerprint images, 

segmentation positions are the x,y coordinates of the four corners of the rotated 

segmentation box. For this evaluation they will be in the follow order: top-left 

corner, top-right, bottom-left, and bottom-right. Fingers are conventionally 

numbered as positions 1 and 6 (thumbs on the right and left hands, respectively), 

2 and 7 (index fingers), 3 and 8 (middle fingers), 4 and 9 (ring fingers), and 5 and 

10 (small fingers). Accurately labeling each finger is imperative for future 

matching efforts as well as the ability to correctly detect when fingers are not 

present in the image. 

2.2. Issues 

Slap segmentation can prove difficult due to a variety of scenarios. The most 

common challenge scenarios include fingerprints that are not clearly separated in 

an image, a fingerprint which appears as multiple images in a slap, background 

noise, the “halo” effect, and rotation. Many of these problems are the same as 

those that existed in the SlapSeg04 evaluation but the use of newer 3 inch platen 

capture devices can reduce problems such as finger spacing and rotation. 

Figure 1. Middle fingers touching in slap. 
4 

Slap segmentation can be adversely affected by fingers that are not clearly 

separated in an image (See Figure 1), which could be due to finger placement at 

the time of capture. It is also possible that two neighboring fingerprints may have 

been over inked or too wet/oily at the time of capture, in which case a down 

sampling or an improper threshold may result in the fingerprints being detected 

as single component. However, the single component should not be split solely 

due to the large width of the detected component. The preferred method for 

splitting the component depends on the width of the component, the number of 

components detected, and the geometric relationship of the component to the 

other components. 

At the opposite end of the spectrum, an excessively dry or under inked finger or a 

fingerprint captured using uneven pressure may be detected as several 

components due to down sampling or improper thresholding. (See Figure 2). 

Whether to merge or delete these components depends on the relationship 

between each sub component and the rest of the components. Segmentation 

algorithms often use contrast equalization to enhance ridge detail and allow for 

better segmentation. Though this process can sometimes improve the matching 

quality of the segmented fingerprint, it sometimes has the opposite effect. 

However, SlapSegII will not judge the effect these changes have to fingerprint 

image’s quality in regards to matching as SlapSegII will focus on segmentation, 

not matching. 

Figure 2. Low Contrast slap image. 
5 

Background noise such as extraneous print lines, printed letters, smudges, etc 

near the boundary of the slap print pose an additional challenge for 

segmentation. (See Figure 3.) “Noise”, which may also be caused by dirt on the 

platen surface of the scanner, is most problematic in low contrast images. 

Figure 3. “Noisy” slap image. 

The “Halo” affect can make segmentation difficult as it introduces noise to the 

image. (See Figure 4.) The “Halo” affect is a moisture build up on platen surface 

of the scanner due to temperature variations (i.e. a warm hand being placed on a 

cool scanning surface). 

 

Figure 4. Moisture/Condensation on the platen surface. 
6 

Image rotation poses an additional problem when a scanner with a two inch high 

scanning surface is used, as well as in some older paper data which has been 

scanned electronically. (See Figure 5.) 

Figure 5. Slap rotation. 

Amputated fingers could also pose a problem during the segmentation process. 

Livescan capture devices should correctly identify this problem during the 

enrollment process, however older devices may not have captured this 

information and electronically converted fingerprint cards may not have the 

proper flags for amputation. The segmentation software may incorrectly segment 

an image based on missing or amputated fingers. 

Often the right and left little finger are not captured or only partially captured 

during the slap enrollment process. Vendors may fail to find these partial little 

fingers or have trouble processing transactions without little fingers. While this is 

actually a livescan capture issue versus a segmentation issue, the resulting 

image can pose challenges to the segmentor. 

3. SlapSeg 2004 

SlapSeg04 [1] was conducted to assess the accuracy of existing slap 

segmentation algorithms in segmenting slap fingerprint images into individual 

fingerprint images, using a variety of operational-quality slap fingerprints. The 

study was conducted by the National Institute of Standards and Technology 

(NIST) on behalf of the Department of Justice (DOJ) Justice Management 

Division (JMD), IDENT/IAFIS Integration Project, with the support of the USVISIT Program Office of the Department of Homeland Security (DHS) and the 

Federal Bureau of Investigation (FBI). 

The study, which was conducted between October and December of 2004, used 

rolled images to match against the segmented slaps as the measure of 
7 

segmentation success. This required manual checking to verify the results of 

each vendor as a low quality image may have segmented correctly without 

matching to the rolled image. The study examined records from about thirty 

thousand subjects from seven different operational datasets, none of which was 

three inch platen fingerprint data. SlapSeg04 incorporated several subtly 

different objectives including measurement of the accuracy of state-of-the-art 

slap segmentation software, assessment of the practicality of segmenting 

operational quality slap fingerprints, determination of the factors that cause slap 

segmentation and matching to fail, and assessment of the ability of segmentation 

algorithms to detect when segmentation was successful. 

4. SlapSegII 

SlapSegII will be conducted by NIST in order to provide the ability to assess the 

current state-of-the-art in slap segmentation technology. SlapSegII will give 

vendors the opportunity to participate multiple times as their technology improves 

and compare their results to previous results on the same dataset. 

The study is sponsored by the FBI and DOS. The sponsors require the ability to 

test on large volumes of Sensitive But Unclassified (SBU) data. The FBI is 

accepting submissions consisting only of slap data, while DOS/DHS are currently 

migrating from 2 finger captures to ten finger captures for its US-VISIT program. 

The most efficient method for capturing ten fingers is slap images. Thus the 

sponsors will benefit from knowing what the current state of the art is in slap 

segmentation technology. Vendors will also benefit from the study as they will 

gain the knowledge of how their segmentation implementation will perform on a 

large dataset of operational quality law enforcement data. Thus, the study can 

prove extremely critical for improving segmentation technology. 

4.1. Testing Strategy 

NIST intends to use a measure of successful slap segmentation for SlapSegII 

that requires minimal manual verification of segmented slaps and does not rely 

on the ability to match segmented slap images. This success measure is based 

on comparing segmentor output with “ground truth” segmentation coordinates. In 

order to prove effective, it is imperative to have a controlled test location, 

submission process, and validation data, as well as a clear understanding of the 

input and expected output. 

4.2. Test Location 

All testing will be conducted at the NIST laboratory in Gaithersburg, MD. The lab 

responds to needs for measurement methods, tools, data, and technology. NIST 

researchers collaborate with colleagues in industry, academic institutions, and 

other government agencies. The result is research that advances the nation's 

technology infrastructure and is needed by U.S. industry to continually improve 

technology and services. 
8 

 

4.3. Who Should Participate 

Makers of commercially available slap fingerprint segmentation software are 

invited to participate in the Slap Fingerprint Segmentation Evaluation II. In 

addition, companies, research organizations, or universities that have developed 

mature prototype or research slap fingerprint segmentation software are invited 

to participate. It is important to note that the segmentation software need not be 

“operational,” nor a production system, nor commercially available. However, the 

system must, at a minimum, be a stable implementation capable of being 

“wrapped” (formatted) in the specification that National Institute of Standards and 

Technology (NIST) has published for this evaluation (Section 4 of this document). 

Additionally, anonymous participation will not be permitted. The results of the 

evaluation of the software will be published with attribution to the participating 

organizations. 

4.4. Submission Process 

In order to simplify the submission process, NIST will adhere to specific 

guidelines and processes for vendor submissions. NIST will write and maintain 

the control software. Vendors will submit compiled command line executables 

that do not use any graphical user interface (GUI) and will run on either Red Hat 

Enterprise Linux 5 or Windows Server 2003 operating systems1

. Any data 

generated or obtained during the SlapSegII evaluations, as well as any 

documentation required by the Government from the participants, becomes the 

property of the Government. Participants will not possess a proprietary interest in 

the data and/or submitted documentation. 

4.5. Application Process 

In order to request participation in SlapSegII, potential participants must 

complete and submit the Application to Participate in SlapSegII (will be made 

available on the website). Incomplete forms will not be accepted. When 

completing the application, the Responsible Party must be an individual with the 

authority to commit the organization to the terms in this document, and the Point 

of Contact must be an individual with detailed knowledge of the system to be 

considered for evaluation. 

Participants may withdraw from the SlapSegII evaluations at any time before the 

software to be evaluated is received by NIST, without their participation and 

withdrawal being documented in the SlapSegII Evaluation Report. 

1 Specific hardware and software products identified in this plan will used in order to perform the evaluations 

described in this document. In no case does identification of any commercial product, trade name, or vendor, 

imply recommendation or endorsement by the National Institute of Standards and Technology, nor does it 

imply that the products and equipment identified are necessarily the best available for the purpose. 
9 

Upon receipt of the signed form by NIST, the organization will be classified as a 

“Participant”. NIST must receive the form by the due date described in the 

SlapSegII Calendar, as posted on the SlapSegII website for inclusion in the initial 

evaluation report. Registered participants should then download the small 

Validation Dataset when it is available on the website. 

4.6. Points of Contact 

The SlapSegII Liaison is the government point of contact for SlapSegII. All 

correspondence should be directed to slapseg@nist.gov, which will be received 

by the SlapSegII Liaison and other SlapSegII personnel. Any correspondences 

may be posted on the FAQ (Frequently Asked Questions) area of the SlapSegII 

website at the discretion of the SlapSegII Liaison. The identity of those persons 

or organizations whose correspondences lead to FAQ postings will not be made 

public in the FAQ. 

4.7. Validation Data 

In order to minimize the variability introduced to testing by the physical 

differences in vendor hardware versus NIST hardware, NIST will provide 

sample/validation data to the vendors prior to testing. This validation data will be 

used to ensure that the software produces the same results on vendor computers 

and NIST computers. Thus ensuring the software being tested will produce the 

required data format during testing. 

4.7.1. Access to SlapSegII Validation Data 

The SlapSegII Validation Data will be supplied to Participants to assist in 

preparing for SlapSegII. The fingerprints in the SlapSegII Validation Data are 

representative of the SlapSegII Test Data only in format. Image quality, 

collection device, and other characteristics may vary between the Validation and 

Test Datasets. 

4.7.2. Validation and Submission Process 

Prior to submission of their SDK the participant needs to verify that their software 

executes on the validation data and produces segmentation information in the 

required format. 

After the Participant has executed his software on the Validation Data, the output 

of the validation data must be submitted to NIST along with the SDK. Software 

can be sent by email (file must be encrypted using encryption key provided 

by NIST, procedures will be posted on the SlapSegII website.) to 

slapseg@nist.gov, or on CD (recommend encrypting the files on the CD) to: 
10 

Slap Fingerprint Segmentation Evaluation II (SlapSegII) Liaison 

National Institute of Standards and Technology 

Information Access Division (894) 

100 Bureau Drive, Stop 8940 

Gaithersburg, MD 20899-8940 

Software submitted must be compliant with the section 4 of the SlapSegII 

Documentation, as posted on the SlapSegII website at 

http://fingerprint.nist.gov/SlapSegII/slapsegII.pdf

Upon receipt of the SDK and validation output, NIST will attempt to reproduce the 

output by executing the SDK on the validation data using a NIST computer. In 

the event of disagreement in the output, if the software is found to be nonfunctional or non-compliant with section 4 of this document, or the validation 

dataset results cannot be replicated by NIST, participants will be notified with a 

detailed description of the problem(s) and given a reasonable opportunity to 

resubmit (as time allows) according to the discretion of the SlapSegII Liaison. 

4.8. Application Inputs 

Slap Fingerprint Segmentation Evaluation II will investigate the accuracy of 

fingerprint image segmentation systems for use with multi-finger slap images. 

These slap images will consist of both 2 inch slap data (fingerprint are rotated) 

and 3 inch slap data (no rotation). The 2 inch data contains left and right four 

finger slap images that are live-scan and rescanned ink. The 3 inch data contains 

left and right four finger slap images as well as slap impressions containing both 

left and right thumbs. All 3 inch data is live-scan. 

The submitted segmentation application is assumed to run on Windows Server 

2003 or Red Hat Linux Enterprise 5.0, on x86 platforms2. Other options must be 

approved by the Test Liaison. The application must have a command-line 

interface as specified in this document; no other user interface is permissible. 

The segmentation application must be capable of taking as input an 

uncompressed raw slap image, and outputting the segmentation coordinates as 

specified in this document. 

 

2 Specific hardware and software products identified in this plan will used in order to perform the evaluations 

described in this document. In no case does identification of any commercial product, trade name, or vendor, 

imply recommendation or endorsement by the National Institute of Standards and Technology, nor does it 

imply that the products and equipment identified are necessarily the best available for the purpose. 
11 

4.8.1. Slap Image Files 

The segmentation application must be capable of processing multi-finger slap 

images stored raw pixel data files. 

Syntactically correct samples will be made available on the website. 

4.8.1.1. Resolution and Dimensions 

All images for this test shall be 500 PPI resolution (horizontal and vertical). The 

dimension of the 3 inch slap images are 1576 x 1572 pixels (80mm x79.9mm, 

3.15in x 3.14in). The majority of the 2 inch slap images are 1600 x 950 pixels 

(81.3mm x 48.3mm, 3.2in x 1.9in) but may be as large as 1600 x 1000 pixels. 

4.8.1.2. Slap Image Filenames 

Multi-finger slap image files shall be specified in the command line either by 

relative pathnames, or fully-qualified pathnames. Unix-style forward slashes (“/”) 

shall be used, not Windows-style backward slashes (“\”). For example, 

/3inch/data/slap001.raw 

The root filename is defined as the filename without the path or extension. For 

example, 

slap001 

Root filenames will be limited to alphanumeric characters and underscores. 

Symbolic links or Windows shortcuts will not be used. 

4.8.1.3. Raw File Format 

Raw 8-bit grayscale image files are canonically encoded with black equal to 0, 

white equal to 255, etc.; stored left to right, top to bottom, with one 8-bit byte per 

pixel. The number of bytes in a file is exactly the image width * image height, as 

measured in pixels; there is no header. 

4.8.2. Input Parameters 

The following information shall be provided as parameters to the segmentation 

application: 

Identifier [-i] 

If this input is given the segmentation algorithm will return the 

software vendor’s point of contact email address without performing 

any segmentation. This will be used to confirm that the correct 

segmentation algorithm is run for the testing vendor. Optionally, the 

vendor can provide version information after the email address. 
12 

Type [-t] 

specifies the type of the fingerprint image: 2 (2 inch), 3 (3 inch). 

Hand identifier[-h] 

specifies R (right hand ), L (left hand), or T (two thumb, 3 inch only) 

corresponding to the specified slap image. 

Source [-s] 

specifies the source of the fingerprint image: L (livescan), P

(paper), or U (unspecified; could be livescan or paper). 

The parameters (if present) will always be in the stated order. Parameters will be 

separated by spaces or tabs. 

4.8.2.1. Example Command-line Usage 

The following are examples of how the input parameters may be specified to the 

segmentation application (using “Unix-like” command-line usage syntax). In the 

following examples, items within “[ ]” are optional. The application should be 

named “ssIIseg” (Linux) or “ssIIseg.exe” (Windows). 

Usages: 

ssIIseg –i 

ssIIseg –t TYPE -h ID –s SOURCE image.raw WIDTH HEIGHT 

-i 

Segmentation algorithm only returns vendor point of contact email 

address for confirmation that testing is linked to correct vendor. 

Optionally, version information can be provided after the email 

address. 

-t TYPE 

Slap image type (2=2 inch, 3=3 inch, no other cases) 

-h ID 

Hand identifier (R=right, L=left, T=Two Thumbs) (no other cases; 

uppercase only) 

-s SOURCE 

Fingerprint image source (L=live-scan, P=paper, U=unspecified) 

(no other cases; uppercase only). 3 inch data will be all live-scan 

and 2 inch can be a mix of live-scan, paper, and unknown. 

image.raw WIDTH HEIGHT 

Raw image filename with height and width in pixels 
13 

Examples: 

ssIIseg –i 

ssIIseg –t 3 –h L –s L slap001.raw 1576 1572 

4.9. Application Outputs 

4.9.1. Segmentation Coordinates 

The segmentation output for each input image will be multiple lines of text which 

contain the segmentation box coordinates for each expected finger in the slap 

image. The output coordinate format will be based on the type-14 record from 

ANSI/NIST-ITL 1-2007 [4]. 

For 2 inch images the output will be the x,y coordinates for all four corners of the 

segmentation box and the angle of rotation (theta) for the fingerprints in the 

image. The corner x,y coordinates will be listed in the following order: top-left, 

top-right, bottom-left, and bottom-right. The rotation angle will use positive for 

clockwise rotation and negative for counter-clockwise rotation and be given in 

degrees of rotation. Zero degrees will be at vertical. It is anticipated that the 

vertices form a rectangular segmentation box but it is not required in the way 

they are reported. For this evaluation the ground truth boxes are rotated 

rectangles, it is up to the reporting segmentation algorithm whether or not to 

report rectangular segmentation boxes for 2 inch slaps. 

All 3 inch input data is assumed to be vertical/non-rotated and the segmentation 

should be the best fit vertical/non-rotated box for each finger in the slap image. 

The segmentation coordinates for the 3 inch slap will be the x-position of the left 

side, x-position of the right side, y-position of the top, and y-position of the bottom 

of the segmentation box. All x,y positions are from the top-left corner of the slap 

image. 

The finger positions are the position codes defined in Table 12 of ANSI/NIST-ITL 

1-2007 [4]: 

01 Right thumb

02 Right index 

03 Right middle

04 Right ring 

05 Right little 

06 Left thumb 

07 Left index 

08 Left middle 

09 Left ring 

10 Left little 
14 

The output should be written to a file with the same name as the input file but 

changing the extension from .raw to .sgm. For example if the input file is 

image.raw the output file should be image.sgm. The output file should be 

written in the same directory path as the input file. Examples for each image 

type are: 

2 Inch Right Hand: 

02,xtl,ytl,xtr,ytr,xbl,ybl,xbr,ybr

03,xtl,ytl,xtr,ytr,xbl,ybl,xbr,ybr

04,xtl,ytl,xtr,ytr,xbl,ybl,xbr,ybr

05,xtl,ytl,xtr,ytr,xbl,ybl,xbr,ybr 

Theta 

2 Inch Left Hand: 

07,xtl,ytl,xtr,ytr,xbl,ybl,xbr,ybr

08,xtl,ytl,xtr,ytr,xbl,ybl,xbr,ybr

09,xtl,ytl,xtr,ytr,xbl,ybl,xbr,ybr

10,xtl,ytl,xtr,ytr,xbl,ybl,xbr,ybr 

theta 

3 Inch Right Hand: 

02,xleft,xright,ytop,ybottom

03,xleft,xright,ytop,ybottom

04,xleft,xright,ytop,ybottom

05,xleft,xright,ytop,ybottom

3 Inch Left Hand: 

07,xleft,xright,ytop,ybottom

08,xleft,xright,ytop,ybottom

09,xleft,xright,ytop,ybottom

10,xleft,xright,ytop,ybottom

3 Inch Two Thumb: 

01,xleft,xright,ytop,ybottom

06,xleft,xright,ytop,ybottom 
15 

If the segmentation algorithm can’t detect/segment one or more of the fingers it 

must output a -1 after the finger number indicating it could not segment that 

finger. For example: 

02,xleft,xright,ytop,ybottom

03,-1 

04,xleft,xright,ytop,ybottom

05,xleft,xright,ytop,ybottom 

4.10. Error Codes and Handling 

The segmentation application shall exit with a return code of zero on success. 

The participant must provide documentation of all (non-zero) error or warning 

codes (see section 4.11). 

The application should include error/exception handling so that in the case of a 

crash, the return code is still provided to the calling shell. 

We request that the following return codes be used: 

Return code Explanation

0 Success 

1 Unable to read input file 

2 Unable to open input file 

10 0 fingers could be segmented 

11 Only 1 finger could be segmented 

12 Only 2 fingers could be segmented 

13 Only 3 fingers could be segmented 

20 – 63 Application-specific fatal errors (explained in documentation) 

64 – 127 Application-specific non-fatal warnings (explained in documentation)

All errors, warnings and informational messages shall be limited to output 

displayed via standard output or standard error. No GUI-type dialog windows are 

permitted. 

4.11. Software and Documentation 

4.11.1. Application type and platform 
16 

 

The application provided shall be command-line driven, and capable of being run 

in non-interactive “batch mode.” No graphical user interface (GUI) is permitted. 

Test participants shall provide NIST with binaries only (i.e. no source code) for 

their segmentation application. Testing of segmentation systems will be 

performed on commercial, off-the-shelf PCs. Applications running on Red Hat 

Enterprise Linux 5 or Microsoft Windows Server 2003 are preferred3

; other 

operating systems must be approved by the Test Liaison. 

4.11.2. Installation 

Segmentation software must install and run easily to be evaluated. The 

application shall be immediately executable without use of an installation 

program. Please contact the Test Liaison if an installation program is absolutely 

necessary. The application shall be executable on any number of machines 

without requiring additional machine-specific license control procedures or 

activation. 

It is preferred that the application be packaged as a single executable file. If 

external libraries (such as DLLs) are necessary, they must work from the 

application directory, and not require installation in another location. 

4.11.3. External Communication 

The segmentation software running on NIST hosts shall not write any data to 

external resources (e.g. server, file, network connections, or other process) other 

than those explicitly allowed in this document. 

4.11.4. Documentation 

Complete documentation of application usage shall be provided, and shall detail 

any additional functionality or behavior beyond what is specified in this 

document. The documentation must define all error and warning codes. 

4.11.5. Speed 

Software that runs excessively slow cannot be evaluated. On average, 

segmentation software should take less than five (5) seconds to segment a slap 

image (using a 2.8 GHZ Pentium Xeon processor). Due to resource limitations, 

software that takes longer than that may not be evaluated. Processing speed will 

be noted but will not be a primary evaluation criterion. 

3 Specific hardware and software products identified in this plan will used in order to perform the evaluations 

described in this document. In no case does identification of any commercial product, trade name, or vendor, 

imply recommendation or endorsement by the National Institute of Standards and Technology, nor does it 

imply that the products and equipment identified are necessarily the best available for the purpose. 
17 

4.12. Sample Data and Results 

Participants must test their software using the SlapSegII sample data, and email 

these results to the Test Liaison for validation before sending software to NIST 

for evaluation 

4.13. SlapSegII Calendar (Tentative) 

Date 

5/8/2008 Announcement/Request for Comments 

5/23/2008 End Comment Period 

6/3/2008 

Release Final Test Plan 

Start Accepting Applications 

6/12/2008 Validation Data Available 

6/27/2008 Last Day for Applications 

8/7/2008 Validation Data Results Submission 

Deadline 

8/13/2008 Software Submission Deadline 

Oct./Nov. 2008 Results Report Issued 

5. Evaluation Data 

In an operational environment, slap segmentation is required for Ten-print Cards 

and Identification Flats. Ten-print Cards are synonymous with two inch data. 

Identification Flats are synonymous with three inch data. Two inch, Ten-print 

Card, contains a right slap and left slap without thumbs. Three inch, 

Identification Flats, contains a right slap, left slap, and thumbs. 

The segmentation process varies for two inch data and three inch data, due to 

the size of the image and number of components within the image. Because of 

the differences in the segmentation process, the SlapSegII test will evaluate 

segmentation of both two inch data and three inch data as separate tests. 

Vendors will be given the option of selecting to participate in the two inch test, 

three inch test, or both. Each test will be run using data, with approximately 

20,000 to 24,000 subjects per test. The two inch test will be conducted using 
18 

data from the law enforcement quality data, while the three inch test will use 

Identification Flats from the Department of State (DOS3). 

The 2 inch dataset consists of a random selection of approximately 20,000 

subjects with right and left hand slap images. The data contains mostly of livescan images and some scanned ink images. There is rotation in the images. 

The three inch segmentation set will be conducted using the DOS3 dataset. The 

DOS3 dataset consists of a random selection of approximately 24,000 subjects 

with right hand, left hand, and thumb images. The thumb image is a single 

image that captures left and right thumb simultaneously. The data contains only 

live-scan images. The fingerprints are assumed vertical with no rotation so there 

is no rotation of the segmentation boxes. 

5.1. Dataset Ground Truth 

The ground truth data is based on the NIST fingerprint segmentation algorithm 

NFSEG. Humans examined every slap image starting with the NFSEG 

segmentation boxes and hand corrected all errors to produce the ground truth 

segmentation. The three main errors the examiners looked for were excess 

white space between a segmentation box edge and the fingerprint, a box side 

touching fingerprint ridges, and the bottom side correctly placed at the first 

crease. Figure 6 shows an example of ground truth segmentation boxes. 

The ground truth boxes were placed to capture only the part of the finger above 

the first joint (ie. the finger tip). The left, right, and top sides of the segmentation 

boxes were placed so that a small amount of white space existed between the 

segmentation box and those edges of the fingerprint. Ground truth information 

will be included with validation data allowing users to see what is considered 

“small amount of white space.” If two fingers are touching the box sides are 

placed along the point of contact. 

The bottom side of the segmentation box was placed in the middle of the first 

joint/crease of the finger. If there was not a well defined white space at the 

crease, the box was still placed in the middle of the crease cutting through any 

ridge information that existed. If there was a slight slant in the fingerprint, (see 

2nd print in Figure 6) the bottom side was placed to include the lowest part of the 

crease inside the segmentation box. Ground truth segmentation boxes do not 

extend past the edges of the slap image for 3-inch slap images but corners could 

be outside the edge of the image for 2-inch data depending on rotation angle. 

After initial testing results are computed some ground truth data will be reviewed 

as deemed necessary to detect any human errors that may exist. This will 

include cases where all vendors miss the segmentation or a certain number miss 

the segmentation box (which will depend on the number of participating vendors) 
19 

Figure 6. Sample Ground Truth Boxes. 

5.2. Access to SlapSegII Test Data 

The SlapSegII Test Datasets are protected under the Privacy Act (5 U.S.C. 

552a), and will be treated as Sensitive but Unclassified (SBU) and/or Law 

Enforcement Sensitive. SlapSegII participants will not have access to SlapSegII 

test data, before, during, or after the test. 

6. How Successful Segmentation will be Determined in 

SlapSegII 

6.1. 3 Inch Data 

The measure of a successful segmentation for the 3 inch dataset will be a 

comparison of the segmentation algorithm’s output to hand marked ground truth 

coordinates to determine if they are within an acceptable tolerance. The 

tolerances allowed are based on matching tests done with slap image data that 

has rolled mates. Tolerance values were selected so that segmentation would 

not significantly impact a matcher’s ability to match the segmented fingerprint. 

A sample of slap image data was selected from a dataset that also had rolled 

images. Testing was conducted to determine what tolerances around the hand 

marked ground truth segmentation boxes would produce a minimal effect on 

matching results using the more accurate matchers evaluated in the proprietary 

fingerprint template test (PFT)4 http://fingerprint.nist.gov/PFT/index.html. 

The initial matching results were computed by matching the hand marked ground 

truth segmented fingerprint images against the rolled fingerprint images. A 

threshold was chosen based on these initial results and was fixed throughout the 

rest of the comparisons. 

 

4 Specific hardware and software products identified in this plan will used in order to perform the evaluations 

described in this document. In no case does identification of any commercial product, trade name, or vendor, 

imply recommendation or endorsement by the National Institute of Standards and Technology, nor does it 

imply that the products and equipment identified are necessarily the best available for the purpose. 
20 

Next each ground truth segmentation box was adjusted by various amounts and 

those segmentation results were matched against the same rolled images. 

These results were then compared to the “ground truth” results to determine how 

varying the edges of the ground truth box affected the number of False Rejects 

(FR) and False Accepts (FA) during matching. 

Figure 7 shows the averages for the various matching results and different 

tolerances across all the fingers in both hands. The first row in the table 

(“Ground Truth”) shows the number of false rejects and false accepts for the 

hand marked ground truth segmentation boxes. The “change from ground truth” 

columns show the difference between the number of FR/FA for a given tolerance 

adjustment and the ground truth value from the first row. The average number of 

mates in the dataset was 9,300 and the average number of non-mates was 

36,713. The average size of the segmented images over the entire dataset was 

270 pixels x 436 pixels. 

The “All sides” rows show results for varying all four sides at the same time at the 

given tolerance. These two rows show that there is improvement in matcher 

performance when allowing the size of the segmentation boxes to increase 

beyond the size of the ground truth results. This allows the upper tolerance for 

the left, right, top and bottom to be set at +64 pixels. Since the crease is a more 

difficult area to detect and most of the better matchers crop the input image 

during enrollment, the bottom tolerance will be set to allow +128 pixels over the 

ground truth bottom edge. 

The last 8 rows of the table show the effects of varying the left, right, top and 

bottom individually by -32 and -64 pixels. These results indicate a significantly 

larger error rate for both FR and FA when allowing a -64 pixel change to the left 

or right side. The top and bottom are more tolerant to a change of -64 pixels. 

The 3 inch successful segmentation is then computed for each finger in the slap 

image as follows (gt = ground truth): 

dleft = leftgt – left 

dright = right – rightgt

dtop = topgt – top 

dbottom = bottom – bottomgt

Successful segmentation of each finger is based on the following criteria: 

-32 <= [dleft,dright] <= 64 

-64 <= dtop <= 64 

-64 <= dbottom <= 128 
21 

Variation 

Average # 

False Reject 

Change from 

Ground Truth

Average # 

False Accept 

Change from 

Ground Truth

Ground Truth 77 24 

All Sides +32 68 -9 20 -4 

All Sides +64 62 -15 18 -6 

Left -32 86 9 34 10 

Left -64 97 20 64 40 

Right -32 87 10 37 13 

Right -64 103 26 64 40 

Top -32 78 1 25 1 

Top -64 81 4 33 9 

Bottom -32 80 3 27 3 

Bottom -64 88 11 32 8 

Figure 7. Matching results (number of FRs and FAs) for different 

segmentation box tolerances. 

Based on the matching results shown in Figure 7 it is determined that the best 

tolerances for the left/right/top/bottom edges are as shown in the image and table 

in Figure 8. The solid line box is the size of the “average” image at 270 x 436 

pixels which at 500 dpi is 0.54 inches x 0.87 inches. All the boxes are adjusted 

by a factor of two for better viewing. 
22 

Lower 

Limits Upper 

Limits 

Side 

Segmentation Tolerances 

Lower Limit 

(pixels) 

Upper Limit 

(pixels) 

Left/Right -32 +64 

Top -64 +64 

Bottom -64 +128 

Figure 8. 3 inch Segmentation box tolerances. 

To further validate the choice of these segmentation box tolerances the NIST 

segmentor that was used in SlapSeg 04 was run on the data sample used to 

make Figure 7 and scored against the hand marked ground truth coordinates 

using the tolerances previously discussed and shown in Figure 8. In SlapSeg04 

the NIST segmentor was able to correctly segment 3 or more “matchable” fingers 

an average of 94.2% for slaps across the seven datasets used in that study [1]. 

Using this new metric for 3 inch data, the same segmentor can segment 3 more 

fingers 96.0% correct. 

The reported results will use the tolerance shown in Figure 8 as the desired level 

of performance. Other tolerances will be shown which can be useful for vendors 

to see where segmentation errors may be occurring. This can include (but not 

limited to) results given by individual edges, individual fingers, and left/right hand 

statistics in different finger combinations like 3 or more per hand, index/middle, 

index/thumb, and both index fingers 
23 

6.2. 2 Inch Data 

The measure of a successful segmentation for the 2 inch dataset will also be a 

comparison of the segmentation algorithm’s output to hand marked ground truth 

coordinates to determine if they are within an acceptable tolerance. The 

difference from the 3 inch slaps is the need to account for rotation in the 

segmentation boxes. The tolerances allowed are based on matching tests done 

with slap image data that has rolled mates. Tolerance values were selected so 

that segmentation would not significantly impact a matcher’s ability to match the 

segmented fingerprint. 

After trying several different methods of comparing segmentation output to 

ground truth for rotated data. An accurate and efficient method was to compare 

the four vertices (xtl,ytl,xtr,ytr,xbl,ybl,xbr,ybr) of the segmentation box to the ground 

truth vertices and determine if the segmentation vertices were within tolerances 

similar to those used with 3 inch data. The variations between the reported 

segmentation vertices and the ground truth are computed relative to the ground 

truth rotation angle as shown in Figure 9 and Figure 10 (picture on the left). The 

rotation angle reported by the segmentation algorithm is not used directly to 

determine successful segmentation but it is still being reported to assist in any 

error checking as needed. 

The acceptable distance tolerances for the vertices were set based on the 

matching done for the 3 inch slap data as described in the previous section 6.1. 

Additional matching was performed to determine what variation in rotation to 

allow. 

Figure 9 shows the averages for the various matching results and different 

rotation variations across all the fingers for both hands. The first row in the table 

(“Ground Truth”) shows the number of false rejects and false accepts for the 

hand marked ground truth segmentation boxes. The “change from ground truth” 

columns show the difference between the number of FR/FA for a given rotation 

change (+/-5o

 through +/- 20o) from the ground truth rotation value. The average 

number of mates in the dataset was 9,300 and the average number of non-mates 

was 36,713. The average size of the segmented images over the entire dataset 

was 270 pixels x 436 pixels. 

Clearly the number of false rejects increases as the rotation angle is increasingly 

varied from ground truth rotation. It is interesting that the number of false accepts 

did not increase in a similar fashion. There is no definitive increase in the number 

of false rejects that defines a clear tolerance point. The conservative point is to 

allow +/- 5o

 from the ground truth angle. This coupled with the distance 

tolerances provides significant variation from ground truth boxes while still 

minimizing impact on the matcher. 
24 

Variation 

Average # 

False Reject 

Change from 

Ground Truth

Average # 

False Accept 

Change from 

Ground Truth

Ground Truth 77 24 

Rotate 5o 80 3 31 7 

Rotate -5o 79 2 28 4 

Rotate 10o 82 5 30 6 

Rotate -10o 82 5 29 5 

Rotate 15o 84 7 30 6 

Rotate -15o 84 7 29 5 

Rotate 20o 85 8 30 6 

Rotate -20o 87 10 29 5 

Figure 9. Matching results (number of FRs and FAs) for different 

segmentation box rotation tolerances. 

The reported segmentation vertices will be compared to the ground truth vertices 

relative to the ground truth angle (varied by +/-5o). This is shown in Figure 11 in 

the image on the right. If the reported segmentation vertices are within tolerance 

at any of the three angles then it is accepted as a successful segmentation. This 

could mean that the top-left corner is within tolerance at thetagt+5 o and the 

bottom-right corner is within tolerance at thetagt-5 o and the segmentation box is 

still considered good. 

The differences between the four vertices returned by the segmentation 

algorithm (xtl,ytl,xtr,ytr,xbl,ybl,xbr,ybr) and the ground truth (gt) vertices are computed 

for each fingerprint in the slap image as follows (Figure 9 is a drawing of the 

parameter placement for the top-left corner): 

dx1tl = xtl - xtlgt

dx1tr = xtrgt - xtr

dx1bl = xbl - xblgt

dx1br = xbrgt - xbr

dy1tl = ytl - ytlgt

dy1tr = ytr - ytrgt

dy1bl = yblgt - ybl

dy1br = ybrgt - ybr 
25 

dtl = sqrt(((dx1tl)**2) + ((dy1tl)**2)) 

dtr = sqrt(((dx1tr)**2) + ((dy1tr)**2)) 

dbl = sqrt(((dx1bl)**2) + ((dy1bl)**2)) 

dbr = sqrt(((dx1br)**2) + ((dy1br)**2)) 

theta1tl = tan-1(dy1tl/dx1tl) 

theta1tr = tan-1(dy1tr/dx1tr) 

theta1bl = tan-1(dy1bl/dx1bl) 

theta1br = tan-1(dy1br/dx1br) 

thetatl = theta1tl + thetagt

thetatr = theta1tr - thetagt

thetabl = theta1bl - thetagt 

thetabr = theta1br + thetagt

dxtl = int(dtl * cos(thetatl) + 0.5) 

dytl = int(dtl * sin(thetatl) + 0.5) 

dxtr = int(dtr * cos(thetatr) + 0.5) 

dytr = int(dtr * sin(thetatr) + 0.5) 

dxbl = int(dbl * cos(thetabl) + 0.5) 

dybl = int(dbl * sin(thetabl) + 0.5) 

dxbr = int(dbr * cos(thetabr) + 0.5) 

dybr = int(dbr * sin(thetabr) + 0.5) 

These computations are repeated for thetagt-5o

 and thetagt+5o and successful 

segmentation is based on the difference values for any of the three angles 

thetagt, thetagt-5o

 or thetagt+5o meeting the following criteria: 

-32 <= [dxtl, dxtr, dxbl, dxbr] <= 64 

-64 <= [dytl, dytr] <= 64 

-64 <= [dybl, dybr] <= 128 
26 

Figure 10. Shows the parameter placement (top-left corner) when 

computing the success measure for 2 inch segmentation boxes (this 

drawing is not to scale it is just intended to assist in understanding the 

formulas in section 6.2). 

Based on the matching results shown in Figure 7 and Figure 10 it was 

determined that the best tolerances for the four vertices are as shown in the 

images and table in Figure 11. The solid line box is the size of the “average” 

image at 270 x 436 pixels which at 500 dpi is 0.54 inches x 0.87 inches and 

shown at a rotation angle of -20o (image on the left). All the boxes are adjusted 

by a factor of two for better viewing. The “acceptable tolerance” box for each 

corner point is shown by the dotted line also rotated relative to the ground truth 

angle of rotation (-20o for this example). The image on the right in Figure 10

shows the distance tolerances at +/-5o

 from the ground truth angle of -20o. Again, 

for successful segmentation all four vertices must be within tolerance at any of 

the three angular positions. 
27 

 

Side 

Segmentation Tolerances 

Lower Limit 

(pixels) 

Upper Limit (pixels) 

X-limits (dx) -32 +64 

Top Y-Limits (dy) -64 +64 

Bottom Y-Limits (dy) -64 +128 

Rotation -5 degrees +5 degrees 

Figure 11. 2 inch segmentation tolerances. 

To further validate the choice of these segmentation box tolerances the NIST 

segmentor that was used in SlapSeg 04 was run on the data sample used to 

make Figure 9 and scored against the hand marked ground truth coordinates 

using the tolerances previously discussed and shown in Figure 10. In SlapSeg04 

the NIST segmentor was able to correctly segment 3 or more “matchable” fingers 

an average of 94.2% for slaps across the seven datasets used in that study [1]. 

Using this new metric for 2 inch data, the same segmentor can segment 3 more 

fingers 93.7% correct. 

The reported results will use the tolerance shown in Figure 10 as the desired 

level of performance. Other tolerances will be shown which can be useful for 

vendors to see where segmentation errors may be occurring. This can include 

(but not limited to) results given by individual vertices, individual fingers, and 
28 

left/right hand statistics in different finger combinations like 3 or more per hand, 

index/middle, index/thumb, and both index fingers 

7. Conclusions 

Given the advances made in technology in recent years, it is necessary to 

conduct an evaluation to assess current state-of-the-art slap fingerprint 

segmentation. By following the guidelines laid out in this document, vendors can 

submit SDKs for evaluation by NIST as part of SlapSegII. 

By utilizing validation data, NIST will effectively minimize the potential for errors 

due to hardware differences prior to testing. By then conducting the evaluation 

using the ground truth dataset, NIST can better implement success measures to 

accurately determine the success of the segmentor independent of a successful 

match, thus providing a more accurate evaluation of the segmentation process 

and minimize the amount of human verification needed to check matcher errors. 

8. References 

1. Slap Fingerprint Segmentation Evaluation 2004 (SlapSeg04). NISTIR 7209. 

http://fingerprint.nist.gov/SlapSeg04

2. NIST Biometric Image Software, http://biometrics.nist.gov/nigos

3. “American National Standard for Information Systems – Data Format for the 

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

ANSI/NIST-ITL 1-2007, NIST Special Publication 500-271, May 2007. 

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