ANSI/NIST-ITL Update:2015
 Barbara Guttman

 Director, Information Access Division
 Fingerprint  Compression studies  Guidance on converting 1000 

ppi to 500 ppi

 Use of WSQ for 500 ppi and 

JPEG 2000 for 1000 ppi

 MINEX  ONGOING FPVTE  NFIQ2  3D fingerprint calibration 

targets

 Iris  IREX studies  Compact formats  Face  Face quality metrics

 Voice  Algorithm challenges  Handwriting  Algorithm challenges  DNA  RapidDNA equipment 

analysis

 electropherogram ladders, 

etc.

 Security  Hashing algorithms  Usability  Pictograms  Communication Protocols  WS-BD

SHAHRAMORANDI
BRADWING
 Revise ANSI/NIST-ITL 1-2011 starting with the 

2013 Update

 Correct errors and add explanatory material 

where needed (particularly for lists)

 Update references to other standards and to the 

Mobile ID Device BPR

 Reflect changes to NIEM

 Consider additional changes

 Brief Overviews to be presented today 

 Smaller changes without separate overviews

B

R

A

D

W

I

N

G
B 

R 

A 

D 

W 

I 

N 

G 
Pro Con

 May be irrelevant 

with codes for grasp 

and carpal delta now 

included

 Unknown if codes 

have been actually 

used

J 

O 

H 

N 

M 

A 

Y 

E 

R 

- 

S 

P 

L 

A 

I 

N 
Pro Con

 Field 9.314 (EFS Tonal 

Reversal) has only two 

options -- Add ‘U’ for 

Unknown for when 

analyst is unsure and 

both options should be 

considered

 None

J 

O 

H 

N 

M 

A 

Y 

E 

R 

- 

S 

P 

L 

A 

I 

N 
 Reasons for the change

 Incorporation of Biometric Domain

 Timetable for Finalization of V 3.0

 Plans for V 3.1

J 

U 

S 

T 

I 

N 

S 

T 

E 

K 

E 

R 

V 

I 

T 

Z 

NIEM 2.1 Element Name NIEM 3.0 Element Name

BinaryBase64Object Base64BinaryObject

LocationGeographicElevation LocationElevation

LocationTwoDemensionalGeograp

hicCoordinate

Location2DGeospatialCoordinate

TwoDimensionalGeographicCoordi

nateType 

Location2DGeospatialCoordinateType

Year YearDate

YearMonth YearMonthDate 

UTMGridZoneID MGRSGridZoneID

MeasurePointValue MeasureDecimalValue
Pro Con

 Update Standard to 

remove any element 

names in NIEM core

 Remove references to a 

NIEM version in the 

standard

 Maintain separate 

schemas and Annex G 

for each NIEM version 

for each A/N-ITL version

 Develop a conversion 

routine for all 

combination of NIEM 

and A/N versions

 Is in spirit of the A/NITL 2011 update to 

make the standard 

encoding version 

independent

 May cause confusion 

among users

 Requires funding and 

commitment to develop 

and maintain programs

 Public Outreach will be 

needed

K 

A 

M 

R 

A 

N 

A 

T 

R 

I 
RACHELWALLNER
R 

A 

C 

H 

E 

L 

W 

A 

L 

L 

N 

E 

R 
R 

A 

C 

H 

E 

L 

W 

A 

L 

L 

N 

E 

R 
RACHELWALLNER

RACHELWALLNER
RACHELWALLNER
RACHELWALLNER
Step 1 • Agency 

determines 

format to 

implement 

standards and 

specifications

Step 2 • Agency 

obtains and 

records info 

from standard 

document 

(e.g., 

ANSI/NIST-ITL)

Step 3 • Agency 

obtains and 

records info 

from 

specification 

document

(e.g., FBI 

EBTS)

Step 4 • Agency 

records info 

specific to the 

Tool 

(e.g., 

Transaction 

Tool)

R 

A 

C 

H 

E 

L 

W 

A 

L 

L 

N 

E 

R 
Step 1

• Agency 

determines 

format to 

implement 

standards and 

specifications

Step 2

• Agency 

obtains and 

records info 

from 

standard 

document

(e.g., 

ANSI/NISTITL)

Step 3

• Agencies can 

create their 

own 

specification 

MRT

Step 4

• Agency 

records info 

specific to 

the Tool 

Standard MRT 

available online 

for agencies & 

developers to use

Specification MRT 

available online 

for developers to 

use

R 

A 

C 

H 

E 

L 

W 

A 

L 

L 

N 

E 

R 
 Easier to Validate 

Information

 Increased Interoperability

 Same format

 Quicker Implementations 

of Standards and 

Specifications

 Easier to View Standards 

and Specifications

 Version Comparison

R 

A 

C 

H 

E 

L 

W 

A 

L 

L 

N 

E 

R 
 Created MRT for:  A/N 2011  A/N 2013  EBTS v9.3  EBTS v10.0.2 

(including Iris Pilot)

 MRT Verifier

 Developing MRT 

application programming 

interface 

(API)

 Host A/N MRT on NIST 

website

 Host EBTS MRT on CJIS 

website

 Develop MRT for AN 

2015 and future 

specifications/standar

ds

Completed To Date Future

R 

A 

C 

H 

E 

L 

W 

A 

L 

L 

N 

E 

R 
Want to know more?

Have any suggestions?

Want to keep up to date 

with the MRT development?

Rachel Wallner, Noblis Rachel.Wallner@noblis.org

Brian Finegold, Noblis Brian.Finegold@noblis.org

Brad Wing, NIST Bradford.Wing@nist.gov

Jennifer Stathakis, FBI Jennifer.Stathakis@ic.fbi.gov

R

A

C

H

E

L

W

A

L

L

N

E

R
RACHELWALLNER
RACHELWALLNER
RACHELWALLNER
 Discrepancies between XML schemas and Annex G R 

A 

C 

H 

E 

L 

W 

A 

L 

L 

N 

E 

R 
R 

A 

C 

H 

E 

L 

W 

A 

L 

L 

N 

E 

R 
 Testing

 Entire Annex G and XML schemas need to be 

examined closely

 Need several eyes on Annex G and XML schemas

 Determine if...

 XML elements and cardinality match in Annex G and 

schemas

 All XML child elements are included within a parent

 Consistency across XML elements for same field type

 Indentation in Annex G is clear

 Automatically update Annex G (remove 

manual updates)

R 

A 

C 

H 

E 

L 

W 

A 

L 

L 

N 

E 

R 
RACHELWALLNER
MANOJBISHT
MANOJBISHT
MANOJBISHT
 Annex G difficult to keep in sync with the 

schema and the layout is subject to 

misinterpretation

 Laying out the strict conformance testing 

logic highlights some possible different 

interpretations of the standard’s text

 Range value restrictions found to be 

different for similar elements – points out 

the need to treat them as separate concepts 

and and elements rather than keeping them 

the same elements with different ranges 

allowed.

D

Y

L

A

N

Y

A

G

A
 Dylan Yaga

 Fernando Podio

 Computer Security Division

 Information Technology Laboratory

 National Institute of Standards and Technology

D

Y

L

A

N

Y

A

G

A
 NIST/ITL CSD supports the development of 

biometric conformance testing methodology 

standards and other conformity assessment 

efforts through active technical participation 

in the development of these standards and 

the development of associated conformance 

test architectures and test suites.

 These test tools are developed to promote 

adoption of these standards and to support 

users that require conformance to selected 

biometric standards, product developers and 

testing labs.

D

Y

L

A

N

Y

A

G

A
 NIST/ITL CSD’s BioCTS team developed and provided the 

initial set of requirements, test assertions, and supporting 

test assertion syntax for ANSI/NIST-ITL 1-2011 to the NIST/ITL 

Conformance Testing Methodology Working Group, chaired by Elham Tabassi from NIST/ITL Information Access Division (IAD)

 NIST/ITL CSD’s BioCTS team acted as the editors for the 

resulting document, NIST Special Publication 500-295, 

Conformance Testing Methodology for ANSI/NIST-ITL 1-2011, 

Data Format for the Interchange of Fingerprint, Facial & 

Other Biometric Information (NIST SP 500-295)

 The test assertions that became a part of NIST SP 500-295 

were the documentation of tests that had been developed by 

the BioCTS team and implemented within the software titled: BioCTS for ANSI/NIST-ITL 1-2011

 Over 100 pages, and 1,200+ test assertions were developed
 Documented and organized Requirements, extracted 

from all around the standard

 Development of Test Assertions that can serve as a 

basis for software development

 NIST/ITL CSD’s BioCTS for ANSI/NIST Software

 Provides an additional critical evaluation of the base 

standard

 Must consider the entire range of values allowed by 

the standard

 Implementing the assertions often leads to asking 

questions, and intensive research to answer them

 May uncover multiple interpretations of requirements 

– and as part of feedback, can help to clarify them

 Helps to provide technical contributions back to the 

standard

D

Y

L

A

N

Y

A

G

A
Standard (or 

revision) 

Released

Analysis of 

Standard

Identification 

& Extraction 

of 

Requirements

Development & 

Documentation 

of Test 

Assertions

Discovery of 

Problem/ 

Potential 

alternative 

interpretation

Develop & 

Submit 

Contribution 

back to 

Standard

Standard 

incorporates 

Contribution

D 

Y 

L 

A 

N 

Y 

A 

G 

A 
 Initial version (Beta 1.0) was released in August 

2012

 Several iterations have been released over the 

years, adding additional features, and 

modifications to the Conformance Test 

Architecture (CTA), as well as additional tests 

implemented within the Conformance Test Suite 

(CTS)

 BioCTS for ANSI/NIST-ITL 1-2011 supports CTSs 

for both Traditional Encoding, as well as NIEM- XML Encoding

 Tests multiple files in a Batch Test mode, as well 

as provides an editor for Traditionally Encoded 

Transactions

D

Y

L

A

N

Y

A

G

A
 The CTSs for ANSI/NIST-ITL 1-2011 provides 

conformance testing support* for several Record 

Types and tests:

 Transaction-wide Tests

 Type 1, Transaction Information Record

 Type 4, High-resolution grayscale fingerprint image

 Type 10, Facial and SMT image

 Type 13, Variable-resolution latent image

 Type 14, Variable-resolution fingerprint image

 Type 15, Palm print image

 Type 17, Iris image

 *BioCTS accepts Transactions containing any 

Record Type, however, only basic conformance 

tests are performed on Records not listed above

D

Y

L

A

N

Y

A

G

A
 Beta version 1.2.5353.15785 Released September 10, 2014 is the 

latest version of BioCTS that supports the ANSI/NIST line of 

standards

 Includes updated versions of the ANSI/NIST-ITL 1-2011 CTSs

 Includes new CTSs for ANSI/NIST-ITL 1-2011 Update: 2013, which 

is still under development. The initial release provides 

conformance testing support* for several Record Types and tests 

(both Traditional and NIEM-XML Encodings):

 Transaction-wide Tests

 Record Type 1, Transaction Information Record

 Record Type 4, High-resolution grayscale fingerprint image

 Record Type 10, Photographic body part imagery (including face and 

SMT)

 Support for additional Record Types is under development

 *BioCTS accepts Transactions containing any Record Type, 

however, only basic conformance tests are performed on Records 

not listed above

D

Y

L

A

N

Y

A

G

A
 NIST/ITL CSD’s BioCTS team has documented the set of 

requirements, test assertions and supporting test 

assertion syntax for ANSI/NIST-ITL 1-2011 Update: 

2013, and is awaiting publication as NIST SP 500-304. 

This document contains all the tests that have been 

implemented within the BioCTS for ANSI/NIST-ITL 1- 2011 Update: 2013 CTSs.

 NIST SP 500-304 covers:

 Transaction Wide Test Assertions

 Record Type 1 Test Assertions

 Additional Documents are under development and 

cover additional Record Type test assertions, each 

Record Type assertions will be an individual NIST IRs
DYLANYAGA
 The CTSs for Traditional Encoding have several 

phases of operation:

 Parse – The first phase is to attempt to parse the 

Transaction. If the Transaction fails to parse, an error 

will be reported and testing does not proceed to the 

next phase.

 Level 1 – The second phase is to perform Level 1 

testing, which includes Value constraints, length 

constraints, character constraints and correct field 

contents (Fields, subfields and information items).

 Level 2 – The third phase is to perform Level 2 

testing, first within each Record Type individually, 

then at a cross Record Type level. Finally, Transaction 

wide tests are performed.

 Test Log Generation – The last phase is to generate 

Test Logs. Both Text based, and XML based Test Log 

Output can be generated.

D

Y

L

A

N

Y

A

G

A
DYLANYAGA
DYLANYAGA
DYLANYAGA
 Verify 

local 

BioCTS 

installs 

against 

posted 

Hash 

Summary 

values on 

the 

BioCTS 

Website

DYLANYAGA
 Easily extract 

any data 

from an 

ANSI/NIST-ITL 

1-2011 

Formatted 

File

 E.g.,  All Fields 

xx.999 – Biometric 

Sample data 

such as 

Fingerprint, 

face, iris 

images

 All Record 

Types 04, 

and 14

DYLANYAGA
 NIST/ITL CSD expects to...

 Continue its efforts to develop test assertions 

for an updated ANSI/NIST-ITL standard

 Continue to submit technical comments on the 

ANSI/NIST-ITL standard

 Continue to develop BioCTS Conformance Test 

Suites to support the additions and changes 

made to the ANSI/NIST-ITL standard

D

Y

L

A

N

Y

A

G

A
DYLANYAGA
DYLANYAGA
DYLANYAGA
DYLANYAGA
DYLANYAGA
 BioCTS Software

 All Available BioCTS Software Downloads are available 

from:

 http://www.nist.gov/itl/csd/biometrics/biocta_down

load.cfm

 BioCTS Team Email – Send feedback, comments 

and questions to:

 biocts@nist.gov

 Dylan Yaga

 dylan.yaga@nist.gov

 Fernando Podio

 fernando.podio@nist.gov

D

Y

L

A

N

Y

A

G

A
Pro Con

 Improve automated 

eye-localization & 

recognition accuracy

 Decrease photo 

rejections due to 

occlusions  Glare  Tint  Rims

 Revise standards  Public outreach  Educate  Photographers  Acceptance agents  Customers

JOHNMAYER-SPLAIN
TOMBUSS
Current situation Reasons for adding FAP55

 FAP45 (two finger) 

sensors OK for ABIS

field enrollment

 FAP45 not accepted 

by FBI/CJIS/Police for 

field booking.

 Need for mobile field 

enrollment is growing 

in US and international

 LES (film/TFT based) 

FAP55 sensor can take 

shape compatible 

with cell phone size 

and thickness goals.

 FAP55 (3.2” x 2”) size 

meets “type 4” 

enrollment standard 

suitable for field 

booking (10print rolls)

T

O

M

B

U

S

S
M

I

K

E

G

A

R

R

I

S

CONTACT CONTACTLESS

OPTICAL NON-OPTICAL OPTICAL NON-OPTICAL

PLAIN (20) PLAIN (22) PLAIN (24) PLAIN (26)

ROLLED (21) ROLLED (23) ROLLED (25) ROLLED (27)

NOW

LIVESCAN OTHER (28)

 Impression Types are “flat” coded [0..39]

 Table 7 hierarchy can be revised w/o changes to existing codes
M

I

K

E

G

A

R

R

I

S

 Multispectral

 International Users – requested by Swedish Police

 Where does it fit?

 Contact/Optical but different from FTIR (legacy)

 “OTHER(28)” – not useful

NOW

CONTACT CONTACTLESS

OPTICAL NON-OPTICAL OPTICAL NON-OPTICAL

PLAIN (20) PLAIN (22) PLAIN (24) PLAIN (26)

ROLLED (21) ROLLED (23) ROLLED (25) ROLLED (27)

LIVESCAN OTHER (28)
M

I

K

E

G

A

R

R

I

S

1. Break down Optical into FTIR (legacy) and Multispectral

 Existing codes 20 and 21 are unchanged

2. Should Non-Optical also be broken down?

 Existing codes 22 and 23 deprecated/made legacy?

3. Need to draft guidance on use between Non-Optical and OTHER(28)

PROPOSED

FTIR

CONTACT

MULTISPECTRAL

PLAIN (20)

ROLLED (21)

PLAIN (40)

CAPACITIVE

OPTICAL NON-OPTICAL

ULTRASOUND

PLAIN (41)

ROLLED (42)

PLAIN (43)

ROLLED (44)
M

I

K

E

G

A

R

R

I

S

 Contactless

 Optical vs. Non-Optical does not apply

 Plain & Rolled are Contact-based terms – do not apply

NOW

CONTACT CONTACTLESS

OPTICAL NON-OPTICAL OPTICAL NON-OPTICAL

PLAIN (20) PLAIN (22) PLAIN (24) PLAIN (26)

ROLLED (21) ROLLED (23) ROLLED (25) ROLLED (27)

LIVESCAN OTHER (28)
M

I

K

E

G

A

R

R

I

S

1. Break down Contactless into 2D and 3D

 2D has arrived, no 3D (yet!)

2. Is 3D ready to be addressed in this update?

 Type 14,15,19 – exclude 3D, include 3D-to-2D under OTHER(28)

 Type 22 for images “not standard 2D photography”

 Depth = Sensors producing point cloud

 Surface = Sensors producing triangular mesh

PROPOSED

PHOTO .... ?? DEPTH

2D 3D

SURFACE

CONTACTLESS
M

I

K

E

G

A

R

R

I

S

1. Break down Contactless into 2D and 3D

 2D has arrived, no 3D (yet!)

2. Is 3D ready to be addressed in this update?

 Type 14,15,19 – now exclude 3D, 

 now include 3D-to-2D under OTHER(28)

 Type 22 for images “not standard 2D photography”

 Depth = Sensors producing point cloud

 Surface = Sensors producing triangular mesh

PROPOSED

PHOTO

CONTACTLESS

.... ?? DEPTH

2D 3D

SURFACE
M

I

K

E

G

A

R

R

I

S

 Break down 2D/PHOTO into Wrapped and Unwrapped

 Native = image data as sensed

 TTC = Transformed To Contact (made to look like FTIR/legacy)

 PL-EQ = Plain Equivalent; RO-EQ = Rolled Equivalent

 These are coded OTHER(28) right now

PROPOSED

2D

NATIVE (45) TTC

PL-EQ (46)

RO-EQ (47)

WRAPPED UNWRAPPED

PHOTO

NATIVE (48) TTC

PL-EQ (49)

RO-EQ (50)
M

I

K

E

G

A

R

R

I

S

 PL-EQ & RO-EQ now coded OTHER(28)

 Update should at least address these codes

 Full 3D in this update will require:

 New Section: Terminology, Concepts, Formats, Compression

 New 3D Image Record Type?

PROPOSED

3D

NATIVE (51) TTC

PL-EQ (52)

RO-EQ (53)

DEPTH SURFACE

NATIVE (54) TTC

PL-EQ (55)

RO-EQ (56)
PROPOSED

LIVESCAN OTHER (28)

I 

E 

G 

A 

R 

R 

I 

S 

3D

NATIVE (51) TTC

PL-EQ (52)

RO-EQ (53)

DEPTH SURFACE

NATIVE (54) TTC

PL-EQ (55)

RO-EQ (56)

2D

NATIVE (45) TTC

PL-EQ (46)

RO-EQ (47)

WRAPPED UNWRAPPED

PHOTO

NATIVE (48) TTC

PL-EQ (49)

RO-EQ (50)

CONTACTLESS

FTIR

CONTACT

MULTISPECTRAL

PLAIN (20)

ROLLED (21)

PLAIN (40)

CAPACITIVE

OPTICAL NON-OPTICAL

ULTRASOUND

PLAIN (41)

ROLLED (42)

PLAIN (43)

ROLLED (44)

M 

K 
elham.tabassi@nist.gov

http://www.nist.gov/itl/iad/ig/development_nfiq_2.cfm

October 31, 2014

ANSI/NIST Workshop
Quality problem: “The Last 1%”

Or maybe “The Last 0.1% or 10%”

» Fraction of samples that should not be sent to the matcher

- Core algorithmic capability of current matchers are reaching their 

asymptote. Performance improvements should be and could be

 achieved by improving data quality and integrity.

- Quality assessment should be done based on only one instance most of 

the times (representation).

- Providing constructive feedback only possible if cause of poor quality is 

known

character behavior environment Imaging/system

E 

L 

H 

A 

M 

T 

A 

B 

A 

S 

S 

I 
E 

L 

H 

A 

M 

T 

A 

B 

A 

S 

S 

I 
quality 

number NFIQ1.0 =5

NFIQ’s 5 levels of quality are intended to be predictive of the relative 

performance of a minutia based fingerprint matching system. 

NFIQ=1 indicates high quality samples, so lower FRR and/or FAR is 

expected.

NFIQ=5 indicates poor quality samples, so higher FRR and/or FAR is 

expected.

E 

L 

H 

A 

M 

T 

A 

B 

A 

S 

S 

I 
NFIQ=3

NFIQ=1

NFIQ=2

NFIQ=4

NFIQ=5

ALL

74

ELHAMTABASSI
Technical

 Agnostic to comparison algorithm

 Capability to predict performance of 

different comparison algorithms

 Sufficient resolution

 How many levels are too many?

 Pairwise quality

 Q1 = F(image1) ; Q2 = F(image2);

 Q12 = G(F(image1), F(image2)) 

 Calibration

 What FNMR is expected for each quality

level/score?

 Quality of quality

 Performance measures

Way forward

 Get a good representation of the 

current (state-of-the-art) 

comparison algorithm for training

 Include as many as possible

 Requires building community 

 We really don’t know.

 Robust method for labeling 

training data + ultimately visual 

inspection

 Devise + revise metrics and 

visualization techniques

E

L

H

A

M

T

A

B

A

S

S

I
Technical, etc. Way forward

 Data + Data sharing issues

 training (particularly low 

quality)

 testing (Images with specific 

defects)

 Agnostic to application scenario 

 `sufficient quality’ is different 

for enrolment vs. verification

 Ditto 1:1 and 1:N.

 Meet unknown System 

requirements

 Timing, hardware, etc.

 Robust

 Zero failure to compute rate

 Data cannot leave a site, but 

an open source algorithm can 

be ran on the data and Results 

can then be shared

 Go for the best recommended 

by the community

 Develop technical guidance 

and best practice

 In collaboration with end users of the 

particular application 

 Good coding practice

E

L

H

A

M

T

A

B

A

S

S

I
Fingerprint

 Empty / Uniform /

no minutiae

 Wet / dry

 High/low pressure 

 Centeredness

 Singularity detection

 Incompleteness

 Entropy of orientation 

flow

 Ghost images

Iris

 occlusion

 non-frontal gaze

 Low contrast

 Non-centered 
ISO/IEC 29794 

ANSI/NIST-ITL

ELHAMTABASSI
ISO/IEC IS 29794-1:2009

 Information technology - Biometrics sample quality 

Part 1: Framework

 Definitions

 quality: "the degree to which 

a biometric sample fulfils

specified requirements for a 

targeted application"

 quality score: "a quantitative 

expression of quality"

 utility: "the observed 

performance of a 

biometric sample or set of 

samples in one or more 

biometric systems"

 Quality score from 0 to 100

5-byte Quality Block
≫ Defines and quantifies iris 

image quality components.

≫ for a single image

≫ for two images being compared

≫ for acquisition device.

≫ Considers subject, 

environment and device 

covariates.

≫ For each quality 

component, it specifies

≫ description, computation method, 

units, and valid values/threshold.

≫ FDIS Ballot

1. Usable iris area [70,100]

2. Iris-sclera contrast [5,100]

3. Iris pupil contrast [30,100]

4. Pupil boundary circularity

5. Grey scale utilisation [6,20]

6. Iris radius [80,253]

7. Pupil dilation [20,70]

8. Iris pupil concentricity 

[90,100]

9. Margin adequacy [80,100]

10. Sharpness

» Required

» Recommended

11. Frontal gaze-elevation

12. Frontal gaze-azimuth

13. Motion blur

E

L

H

A

M

T

A

B

A

S

S

I
ELHAMTABASSI
Promises, promises

 Improved feature

 More level (0-100)

 Faster, lighter

 Actionable feedback

 NFIQ 2.0 mobile

 Slap

 Better performance

 Modular design

 Calibration

 Conformance testing

So far, we have achieved

 Many features, somehow 

improved

 More level (0-100)

 Faster, lighter

 Actionable feedback

 Towards NFIQ Mobile

 In progress – need FpVTE

 Better performance 

 Plug and play

 Mapping to FNMR 

 Underway

 Standard features

E

L

H

A

M

T

A

B

A

S

S

I
NFIQ 1.0

 5 levels.  1(highest) to 5(lowest)  11 features  Comparison scores of 

3 algorithms used for 

training

 3400 training images  ~300 msec per image

NFIQ 2.0

 100 levels  0(lowest) to 100(highest)  15 features  Comparison scores of 7 

algorithms used for 

training

 ~5000 training images  ~ 100 msec per image  Actionable quality  Flags for blank image, 

low contrast

 Design for NFIQ Mobile

ELHAMTABASSI
 Elham Tabassi  301 975 5292  tabassi@nist.gov

ELHAMTABASSI
Pro Con

 NFIQ (version 1) has 

its own field (14.022) 

Users may want a 

separate field to 

clearly indicate and 

distinguish NFIQ2 

from any other 

metric. 

 Field 14.024 already 

exists (Fingerprint 

quality metric) for 

metrics that use a 

scale of 1 to 100. It 

could be confusing to 

have a separate field 

for just NIFQ2. All 

that is needed is to 

specify that the 

algorithm is NFIQ2.

BRADWING
BRUCEBANDINI
 Additional topics to be considered  Develop working groups  Select chairs  Solicit volunteers  Develop a Timetable

BRADWING