1 

2 

3 

4 

5 

6 

7 

8 

9 

10 

11 

12 

13 

14 

15 

16 

Iris Exchange (IREX) Evaluation 2008 

Concept, Evaluation Plan and API 

 

 

17 

18 

19 

20 

21 

22 

23 

24 

25 

26 

27 

28 

IREX 2008 

IREX 

An Evaluation-based Program for the Development of Compact 

Interoperable ISO/IEC 19794-6 Standardized Iris Images 

Patrick Grother 

NIST 

August 28, 2008 

NIST Concept, Evaluation Plan and API Page 1 of 33 
 

 

1 

2 

3 

4 

5 

 

 

 

 

 

 

 

 

6 

 

 

 

 

7 

IREX 2008 

Status of this Document 

August 5, 2008: Note on the semantics of 0 values passed to the unsegmented polar preparation 

routine. 

June 25, 2008: Various updates. See FAQ http://iris.nist.gov/irex/faq.pdf 

June 11, 2008: This is the final specification of the IREX concept and API. Questions should be 

addressed to irex@nist.gov and these will generally be answered in a FAQ to be posted on 

http://iris.nist.gov/irex. NIST does not intend to identify the questioner. 

NIST is eager to help participants in implementing this specification, and to encourage wide 

participation. Suggestions are welcome also, please post to irex@nist.gov. 

NIST Request for Iris Images 

NIST is renewing its call for contribution of iris imagery. 

NIST is eager to identify organizations in possession of iris images who might share them 

with NIST, and who might benefit from their use in NIST's testing effort. 

Please contact me via email patrick.grother@nist.gov or phone 301 975 4157. 

NIST Concept, Evaluation Plan and API Page 2 of 33 
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

1 

IREX 2008 

Major changes from the February to May 2008 draft 

1 The timeline has slipped. Several remarks that the schedule was too ambitious; New schedule below. 

2 The crop-only format is added so we propose to explicitly evaluate implementations of these three: 

― the crop-only part of the Cambridge proposal [CAM07,CAM08] 

― the crop-and ROI-masking part of the Cambridge proposal [CAM07,CAM08] 

― the Iritech/US unsegmented polar documented in 37N2296 [IRI07] - inner and outer circles are 

concentric; extended to allow vendor-defined segmentation information. 

See particularly 

sections 6 and 7. 

3 Important: Refined classes of participation. See Table 4 

4 The document was been greatly simplified via the proposed use of a single data structure to hold all of 

the above kinds of imagery. Plans to use the 2005 standard for rectilinear images have been dropped. 

See Table 6 

5 Added language to emphasize that the uncompressed raw rectilinear part of IREX will constitute the 

largest test of iris recognition algorithms to date. 

6 On metrics 

― We propose to also quantify accuracy available without any standard-related constraints. This 

allows a measure of sufficiency - the ISO term [PERFSTD] for expressing whether the standardized 

format is sufficient to achieve the accuracy of fully proprietary unconstrained encodings, including zero 

compression. 

― We will compute iris-specific SNR and PSNR values as a function of compression ratio. 

― We will compute variance and upper bounds for compressed record size, per hard limits 

established (for smartcards for example). 

Sec. 5.5 

7 Refined text on our intentions regarding the use of, and separation of, high and low quality images. Sec. 5.8. 

2 

3 

NIST Concept, Evaluation Plan and API Page 3 of 33 
 

 

1 

2 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

IREX 2008 

Intended Timeline 

Important Dates in Red 

Jan 18-24, 2009 SC37 meeting, United States 

Nov 30, 2008 NIST submission to M1 (US TAG to SC 37) of results 

Fall 2008 NIST Interagency Report - Primary IREX results. 

Sep 12, 2008 Window for submission of signed Annex A Participation Application and SDKs to NIST closes. Please send 

FINAL SDK. Mod Jun 20, 2008: Withdrawal from IREX after September 12 will be reported in the IREX 

report. 

Aug 18, 2008 Window for submission of signed Annex A Participation Application and SDKs to NIST opens. Please send 

draft SDKs for validation 

Jul 7-15, 2008 SC37 meeting, Korea 

Jul 2, 2008 Deadline for submission of an "Intention to Participate" email to NIST. This is required for IREX 

participation. The function of this requirement is twofold: 

― To allow US experts to inform SC 37 WG 3 of the number (not names) of IREX participants 

― Participants will be given validation data with which to check the correct function of the various 

functions of the SDK. 

Mod Jun 20, 2008 - The "intention to participate" is non-binding: Participants can withdraw after this date. 

NIST does not intend to make the names of such participants public. 

June 11, 2008 Release of this specification 

Mar 11, 2008 Comments on second draft due 

Feb 20, 2008 Release of second draft evaluation plan, for comment. 

Jan 7-12, 2008 SC 37 Working Group 3 meeting in Tel Aviv, Israel 

Dec 8, 2007 Conclusion of Initial comment period 

Nov 18, 2007 Release of initial evaluation plan for comment. 

May 2008 June 2008 July 2008 August 2008 September 2008 

Su Mo Tu We Th Fr Sa Su Mo Tu We Th Fr Sa Su Mo Tu We Th Fr Sa Su Mo Tu We Th Fr Sa Su Mo Tu We Th Fr Sa 

1 2 3 

4 5 6 7 8 9 10 

11 12 13 14 15 16 17 

1 2 3 4 5 6 7 

8 9 10 11 12 13 14 

15 16 17 18 19 20 21 

1 2 3 4 5 

6 7 8 9 10 11 12 

13 14 15 16 17 18 19 

1 2 

3 4 5 6 7 8 9 

10 11 12 13 14 15 16 

1 2 3 4 5 6 

7 8 9 10 11 12 13 

14 15 16 17 18 19 20 

18 19 20 21 22 23 24 22 23 24 25 26 27 28 20 21 22 23 24 25 26 17 18 19 20 21 22 23 21 22 23 24 25 26 27 

25 26 27 28 29 30 31 29 30 27 28 29 30 31 24 25 26 27 28 29 30 28 29 30 

31 

3 

4 

5 

6 

7 

NIST Concept, Evaluation Plan and API Page 4 of 33 
 

 

 

5

10

15

20

25

30

1 

2 

3 

4 

6 

7 

8 

9 

11 

12 

13 

14 

16 

17 

18 

19 

21 

22 

23 

24 

26 

27 

28 

29 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

35

40

45

50

31 

32 

33 

34 

36 

37 

38 

39 

41 

42 

43 

44 

46 

47 

48 

49 

51 

52 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

IREX 2008 

Table of Contents 

1. IREX................................................................................................................................................................................... 7 

1.1. Overview................................................................................................................................................................. 7 

1.2. Scope ...................................................................................................................................................................... 7 

1.3. Relation to other NIST tests.................................................................................................................................... 8 

2. Motivation and background............................................................................................................................................. 8 

2.1. Market drivers ........................................................................................................................................................ 8 

2.2. Support for the ISO standard.................................................................................................................................. 8 

3. Normative References...................................................................................................................................................... 9 

4. Abbreviations ................................................................................................................................................................... 9 

5. Aspects of the test.......................................................................................................................................................... 11 

5.1. Fundamental concept of the test ......................................................................................................................... 11 

5.2. Segmentation on uncompressed data.................................................................................................................. 11 

5.3. NIST invocation of compressors and de-compressors.......................................................................................... 11 

5.4. Feature extraction on compressed data............................................................................................................... 11 

5.5. Measure sufficiency.............................................................................................................................................. 11 

5.6. Interoperability space........................................................................................................................................... 11 

5.7. Offline evaluation using archival imagery............................................................................................................. 12 

5.8. Separation of good and bad images..................................................................................................................... 12 

5.9. Audience and options for participation................................................................................................................ 12 

5.10. Number of submissions........................................................................................................................................ 13 

5.11. Compression metrics............................................................................................................................................ 13 

5.12. Provision of sensor information to SDKs .............................................................................................................. 13 

5.13. Verification performance...................................................................................................................................... 13 

5.14. Phased testing....................................................................................................................................................... 13 

5.15. Open-source code for ISO/IEC 19794-6................................................................................................................ 13 

6. Standardized data elements........................................................................................................................................... 14 

6.1. Overview............................................................................................................................................................... 14 

6.2. Identifying the records of the standard................................................................................................................ 14 

6.3. The Cropping operation........................................................................................................................................ 14 

6.4. The ROI masking operation................................................................................................................................... 14 

6.5. Unsegmented polar records................................................................................................................................. 15 

6.6. Polar encoding ...................................................................................................................................................... 15 

6.7. Auxiliary boundary data........................................................................................................................................ 16 

6.8. Inclusion of non-standard information................................................................................................................. 17 

7. PC-based API specification ............................................................................................................................................. 21 

7.1. Overview............................................................................................................................................................... 21 

7.2. Testing interface ................................................................................................................................................... 21 

7.3. Software and Documentation............................................................................................................................... 26 

7.4. Runtime behavior ................................................................................................................................................. 27 

8. References...................................................................................................................................................................... 28 

Annex A Application to participate in IREX ............................................................................................................................ 30 

A.1 Who should participate ........................................................................................................................................ 30 

A.2 How to participate ................................................................................................................................................ 30 

A.3 NIST activity .......................................................................................................................................................... 30 

A.4 Parties................................................................................................................................................................... 31 

A.5 Access to IREX validation data .............................................................................................................................. 31 

A.6 Access to IREX test data........................................................................................................................................ 31 

A.7 Reporting of results .............................................................................................................................................. 32 

A.8 Return of the supplied materials.......................................................................................................................... 32 

A.9 Agreement to participate ..................................................................................................................................... 32 

NIST Concept, Evaluation Plan and API Page 5 of 33 
 

 

1 

2 

3 

4 

5 

6 

7 

8 

9 

10 

11 

12 

13 

14 

15 

16 

17 

18 

19 

20 

21 

22 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

23 

24 

25 

IREX 2008 

List of Figures 

Figure 1 – Example Freeman Chain Code............................................................................................................................... 16 

Figure 2 - Freeman Chain Code Directions............................................................................................................................. 16 

List of Tables 

Table 1 – NIST's iris evaluations ............................................................................................................................................... 8 

Table 2 – Abbreviations............................................................................................................................................................ 9 

Table 3 – IREX 08 image variants............................................................................................................................................ 10 

Table 4 – IREX classes of participation ................................................................................................................................... 12 

Table 5 – Format for Freeman chain code ............................................................................................................................. 16 

Table 6 – Structure for the proposed formats for ISO/IEC 19794-6....................................................................................... 18 

Table 7 – Sensor identifiers .................................................................................................................................................... 21 

Table 8 – IREX API for preparation of cropped rectilinear records ........................................................................................ 22 

Table 9 – IREX API for preparation of cropped-and-ROI-masked records.............................................................................. 23 

Table 10 – IREX API for creation of unsegmented polar records ........................................................................................... 24 

Table 11 – IREX API template creation................................................................................................................................... 25 

Table 12 – IREX API template matching ................................................................................................................................. 25 

Table 13 – IREX API get_pids function.................................................................................................................................... 26 

Acknowledgements 

The authors are grateful to the many members of the commercial, academic and end-user iris recognition communities 

for their comments on and toward this document. 

Project History 

Jun 11, 2008 

― NIST thanks the six organizations who commented on the February 2008 draft. 

― NIST also thanks the members of the SC 37 and M1 Working Groups for the time allocated to discussion. 

― Final concept , API, and participation solicitation released (i.e. this document) 

Feb 20, 2008 

― NIST thanks those organizations who commented on the November 2007 draft, and the members of the SC 37 Working 

Group 3 committee for discussion of the related standardization issues. 

― Revised draft circulated. 

Nov 18 + 19, 2007 

― Announcement: NIST indicates it will conduct the Iris Exchange evaluation, IREX 08, to test the capabilities to segment 

irides, prepare compact rectilinear and polar standard records, and accurately match compressed images in a crossvendor interoperable environment. 

― Posting of this initial evaluation plan, for public comment, to the IREX homepage: http://iris.nist.gov/irex 

NIST Concept, Evaluation Plan and API Page 6 of 33 
 

 

 

5

10

15

20

1 

2 

3 

4 

6 

7 

8 

9 

11 

12 

13 

14 

16 

17 

18 

19 

21 

22 

23 

24 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

25 

30

26 

27 

28 

29 

31 

32 

33 

34 

 

 

 

 

 

 

 

 

 

35

IREX 2008 

1. IREX 

1.1. Overview 

The NIST Interoperable Iris Program is being initiated at NIST in support of an expanded marketplace of iris-based 

applications based on standardized interoperable iris imagery. The immediate driver is to standardize formats that can 

establish iris as a second interoperable modality for identity credentials, to be used instead of, or in addition to, the 

fingerprints which exist today on (for example) US PIV cards. 

The work is conducted to: 

― test compact formats covered by, and proposed for, the ISO/IEC 19794-6 standard, now under revision, 

― quantify the relationship between error rates and compression of iris imagery, and 

― baseline these by conducting the largest public test of current iris recognition algorithms on the same images. 

1.2. Scope 

Specifically the test aims to 

― quantify the performance and interoperability of 

− rectilinear images, 

− the UK-proposed ROI masked rectilinear images [CAM07], 

− the US-proposed unsegmented polar images [IRI07]. 

― measure the effect of JPEG and JPEG 2000 compression on accuracy, 

― quantify the performance and interoperability of iris segmentation algorithms 

― formulate record structures and other content toward the revision of ISO/IEC 19794-6, and 

― check that suppliers can produce records conformant to the ISO/IEC 19794-6 standard. 

The primary outputs of the test will be statements of performance including 

― measurements of failure-to-segment rates for various compression levels 

― measurements of false non-match and false match error rates for various compression levels and operating 

thresholds, 

― time taken to prepare the various standard instances, 

― time taken to extract features from the various standard instances, and 

― time taken to match feature-based templates. 

In so doing, the IREX evaluation requires 

― conversion raw rectilinear raster images into cropped and/or ROI-masked rectilinear images, and 

― conversion of raw rectilinear raster images into unsegmented polar images. 

The following are specifically not within the current scope of this evaluation: 

― predictions of operational performance, 

― sensor usability or security evaluation (this study will be conducted with offline imagery), 

― off-angle imagery (other than that incidentally present in the test corpora), and 

― identification performance. 

NIST Concept, Evaluation Plan and API Page 7 of 33 
 

 

1 

2 

3 

4 

 

 

 

 

 

 

 

 

 

 

5 

6 

7 

8 

9 

10 

11 

12 

13 

14 

15 

16 

17 

18 

19 

20 

21 

22 

23 

24 

25 

26 

27 

28 

29 

 

IREX 2008 

1.3. Relation to other NIST tests 

The IREX is distinct from NIST's prior Iris Challenge Evaluations (ICE). Table 1 gives the context for IREX amongst the 

various iris activities at NIST. 

Table 1 – NIST's iris evaluations 

IREX 08 

IREX 08 is intended to measure interoperable performance of the two compact formats proposed for the 

revision of the ISO/IEC 19794-6 standard. As a baseline IREX will embed an evaluation of technologies 

running on raw iris imagery and as such is likely to constitute the largest public test of iris recognition 

technology yet conducted. 

MBGC Considers fusion of face and iris; looks at video sequences. http://face.nist.gov/mbgc/ 

ICE 06 Coordinated by Jonathon Phillips, the Iris Challenge Evaluation 2006 was a comparative assessment of 

commercial iris verification implementations on a common sequestered test corpus. 

ICE 05 Coordinated by Jonathon Phillips, the ICE 05 activity was a cooperative research and development effort 

centered on the ICE 05 image corpus collected by University of Notre Dame. 

2. Motivation and background 

2.1. Market drivers 

NIST's motivation in executing IREX 08 is the establishment of a standardized accurate, interoperable and compact iris 

image format suitable for large scale credentialing and identity management applications. In addition, IREX supports law 

enforcement applications via future revision of the ANSI/NIST ITL 1-2007 Type 17 standard (as derived from the ISO/IEC 

19794-6:2005 parent [STD05]). 

While IREX 08 is structured only as an application-independent assessment of the core algorithmic performance of the 

segmentation and recognition components, NIST is particularly interested in establishing a set of specifications for an iris 1 data element suitable for storage on an ISO/IEC 7816 crypto-token , and for rapid transmission across a network. 

Toward similar ends, iris compression studies have been conducted [USNA, CAM07, BATH06, BATH07]. While the studies 

report promising results, they explored only the single-vendor case in which enrolment and verification data are 

processed by a lone supplier's segmentation and matching algorithms. The exception here is [BATH07] which showed 

similar compression sensitivities for two different matching algorithms. 

The ISO/IEC 19794-6 standard was published in 2005 [STD05]. It is almost identical to its precursor, the INCITS 379:2004 

standard published in the United States [I379]. As application-independent standards, neither document establishes 

normative requirements on compression. Instead the ISO standard's clause A.1.6 gives the following informative 

guidance "... a compression factor of 6:1 or less is recommended". This is an order of magnitude smaller than 

compression ratios cited recently [CAM07, BATH06, BATH07]. 

2.2. Support for the ISO standard 

A second key motivation is to support the production of a more robust, interoperable, useful and implementable ISO/IEC 

19794-6 standard. Thus, IREX 08 should be viewed as an unofficial augmentation of the ISO development process. This 

contrasts with the default practice of the SC 37 Working Group 3 and M1.3 committees, which has not been to embed 

conformance, performance and interoperability tests into the standards' development process. For [STD05] the result of 

this structure was that the ultimate viability of the final standard rested on the considerable expertise of the editor and 

the committee, and on any (unpublished) intra-supplier tests. 

1 For example, the U. S. Government's PIV Card, which currently uses fingerprint minutia. As the de facto leading data element for 7816 

identity credentials, single-finger minutia templates, encoded as INCITS 378:2004 records, contain 38 minutiae (the MINEX 04 median 

value [MINEX]) and occupy 260 bytes including header information. ISO/IEC 19794-2:2005 compact card templates are less than half 

the size yet offer similar accuracy [MO ]. 

NIST Concept, Evaluation Plan and API Page 8 of 33 
 

 

1 

2 

3 

4 

5 

6 

7 

8 

9 

10 

11 

12 

13 

14 

15 

16 

17 

18 

19 

20 

21 

22 

23 

24 

25 

26 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

27 

28 

29 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

IREX 2008 

The ISO standard was adopted by at least the Registered Traveler (RT) program2 in the United States which provided for 

compact iris imagery on an ISO/IEC 7816 smartcard. This was achieved by specifying a no-inner-boundary polar format3 

to mitigate possible interoperability problems with the full polar format. Such problems have recently been asserted by 

noting that the interoperability of the polar format is critically sensitive to the consistency of the segmentation [N2059, 

N2124], and subject to sampling problems [PROC]. The solution advocated in the German proposal to SC 37 [N2059] is 

complete removal of the polar format, and per the Tel Aviv meeting of SC 37 WG3, the revised text of the standard 

[N2484] no longer includes polar. A UK contribution [N2124] advocated removal and suggests the polar format's size can 

be achieved via cropping and compression of the rectilinear format. The UK contribution [CAM07] indicates that 

compressed sizes of about 2KB are achievable. The proposal to remove was opposed by US [DHS, NIST, LG] with 

observations that the polar format was thought to be interoperable (viz. RT), that removal would undermine standards 

adoption, and that some testing is needed. This was defeated by 6-5 vote, and the [N2484] draft is polar-free. 

Three alternative compact forms have been advanced: A cropped rectilinear image and an ROI-masked version thereof 

[CAM07], and a new polar variant termed the unsegmented polar format [IRI07]. The IREX 08 test is therefore being 

conducted as an independent assessment of interoperability and accuracy of these proposed compact forms. This is more 

formally stated below. 

3. Normative References 

The following referenced documents are indispensable for the application of this document. For dated references, only 

the edition cited applies. For undated references, the latest edition of the referenced document (including any 

amendments) applies. 

― ISO/IEC 19794-6:2005 — Information technology — Biometric data interchange formats — Part 6: Iris image data 

― ISO/IEC FDIS 19795-4 — Biometric Performance Testing and Reporting — Part 4: Interoperability Performance 

Testing.4 

The following two documents describe compact representations: 

― [CAM07, CAM08] UK Contribution Effect of severe image compression on iris recognition performance. 

― [IRI07] US Contribution Compact Iris Format. 

See the References in section 8 for full citations and URLs. 

4. Abbreviations 

The abbreviations and acronyms of Table 2 are used in many parts of this document. 

Table 2 – Abbreviations 

DET Detection error tradeoff characteristic – a plot of FNMR vs. FMR (sometimes as normal deviates, 

sometimes on log-scales) 

FMR False match rate 

FNMR False non-match rate 

INCITS InterNational Committee on Information Technology Standards 

ISO/IEC 19794 Multipart standard of "Biometric data interchange formats" 

I379 INCITS 379:2004 

IREX Generic name for the series of NIST's Iris Interoperability Program 

2 See http://www.rtconsortium.org/_docpost/RTICTIGSpec_v1.7.pdf 3 Clause 6.3.2.3 of ISO/IEC 19794-6:2005 allows the pupil center to be used as the inner boundary, i.e. the pupil-iris boundary is not 

detected and the pupil radius is set to zero. 

4 The IREX evaluation is an interoperability test. As such, NIST intends to conduct it in conformance to the ISO/IEC FDIS 19795-4 — 

Biometric Performance Testing and Reporting — Part 4: Interoperability Performance Testing standard. This standard establishes 

requirements for the execution of multi-supplier biometric interoperability tests, primarily those evaluating standardized interchange 

formats such as ISO/IEC 19794-x. 

NIST Concept, Evaluation Plan and API Page 9 of 33 
 

 

 

 

 

 

1 

2 

Cropped Rectilinear Cropped + ROI-masked Rectilinear Unsegmented Polar 

Standards As a rectilinear instance it is As a rectilinear instance it is compliant 

compliance compliant to ISO/IEC 19794-6:2005 to ISO/IEC 19794-6:2005 but that 

but that standard gave no sizestandard gave no sizeparameter 

parameter guidance. guidance, and [CAM07] is not 

obviously covered under clause 6.3.2.4 

of the 2005 standard [STD05]. 

Proposed content for ISO/IEC Proposed content for ISO/IEC 19794- Proposed content for ISO/IEC 19794-

19794-6:200X, X > 7. 6:200X, X > 7. 6:200X, X > 7. 

See [CAM07,CAM08] [CAM07,CAM08] [IRI07] 

NIST input image The input images will be uncompressed with the intention that no processing has been done since they left the 

to SDK particular sensor. 

Required Enough to cropthe image around Cropping and masking via detection of Concentric inner and outer circles, 

Segmentation the iris center. the eyelid-iris and sclera-iris neither of which is necessarily centered 

boundaries. on pupil or iris center. 

Encoding Table 6, Kind = 3 Table 6, Kind = 7 Table 6, Kind = 16 

Stored image 

Aug 28, 08: This replaces incorrect 

version from prior versions of 

document. 

Compression NIST will apply compression to allkinds of the above images, and baseline the effect of compression by

also running participants' feature extraction and matching algorithms on theraw uncompressed images. 

Feature 

extraction from 

the stored image 

How to process the stored image is entirely at the discretion oftheprovider. In therectilinear cases 

further segmentation and feature extraction seems necessary. For the unsegmented polar, either 

feature extraction is done directly, or, as [IRI07] suggests, the reverse polar transform is applied and a 

fine grained segmentation is applied before feature extraction. 

Semantic rules Section 6.3 Section 6.4 and 6.3 Section 6.5 

API Section 7.2.4 Section 7.2.5 Section 7.2.6 

 

IREX 2008 

NIST National Institute of Standards and Technology 

PIV Personal Identity Verification 

SC 37 Subcommittee 37 of Joint Technical Committee 1 – developer of biometric standards 

SDK The term Software Development Kit refers to any library software submitted to NIST 

Table 3 – IREX 08 image variants 

NIST Concept, Evaluation Plan and API Page 10 of 33 

3 
 

 

 

5

10

15

20

25

30

1 

2 

3 

4 

6 

7 

8 

9 

11 

12 

13 

14 

16 

17 

18 

19 

21 

22 

23 

24 

26 

27 

28 

29 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

35

31 

32 

33 

34 

36 

37 

 

 

 

 

 

 

IREX 2008 

5. Aspects of the test 

5.1. Fundamental concept of the test 

The IREX 08 is an interoperability test and is structured around three core operations: 

In stage 1, functions within the supplier's SDK are called to convert archival rectilinear raster images into the compact 

forms of Table 3, specifically 

― Cropped rectilinear images conformant to the specifications herein. 

― ROI-masked rectilinear images conformant to the specifications herein. 

― Unsegmented polar images conformant to the specifications herein. 

In stage 2, functions within a supplier's SDK are called to convert these processed images into an opaque proprietary 

template. This will potentially require reconstruction, re-segmentation, and feature extraction. 

In stage 3, functions within a supplier's SDK are called to compare two proprietary templates and produce a distance 

measure. 

5.2. Segmentation on uncompressed data 

All cropped, unsegmented polar and ROI-masked images will be prepared from uncompressed input data. This mimics 

the scenario in which the image processing steps need to instantiate the standard records are conducted at time of 

enrollment either in the sensor, or on a local computer, before transmission or commitment to an identity credential. 

5.3. NIST invocation of compressors and de-compressors 

SDK functions shall not apply compression. NIST will call compression routines, and will survey over appropriate 

compression parameters, primarily the bit rate. 

NIST will not pass JPEG or JPEG 2000 encoded data to the SDK functions. Instead, any compression will be followed by 

decompression before passing the record to the SDK. This avoids the need for the SDK to call decompression routines. 

5.4. Feature extraction on compressed data 

For the cropped, ROI-masked or unsegmented polar images, the SDK template generation function will likely need to 

embed (re)segmentation and template generation operations. These will usually be performed on previously compressed 

data. 

5.5. Measure sufficiency 

NIST will compute and report performance on full-size uncompressed rectilinear images. This establishes a baseline 

against which error rates for any given compression ratio and compact format can be compared. 

5.6. Interoperability space 

There are two targeted interoperability scenarios: 

― A one-to-one verification application in which compressed enrollment imagery is retrieved for storage to be 

compared with an uncompressed and unsegmented verification sample. NIST will mimic this operation in an offline 

evaluation by comparing enrollment instances in the various compressed formats against unprocessed and 

uncompressed verification images. 

― A server-centric verification application in which a compressed image is transmitted to a server for enrollment, and 

later compared with a compressed image submitted for verification. Thus both images are compressed and it is 

assumed that the code to produce the compact form resides in or near to the sensor, and not on the server. 

NIST Concept, Evaluation Plan and API Page 11 of 33 
 

 

1 

2 

3 

4 

5 

6 

7 

8 

9 

10 

11 

12 

13 

14 

15 

16 

17 

18 

19 

20 

21 

22 

23 

24 

25 

26 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

IREX 2008 

5.7. Offline evaluation using archival imagery 

NIST intends to execute the test in an entirely offline fashion and to use images from various datasets. NIST has not 

conducted a dedicated collection or scenario test in support of IREX 08. 

5.8. Separation of good and bad images 

For a detailed study of compression and the relationship of bit rate, PSNR, and matching error rates, NIST will use images 

typical of what might be seen in an operator assisted enrolment session. Such a study will require us to ignore certain 

images in some of our databases. 

For a study of the ability to segment images and convert them into instances of the three compact forms, NIST intends to 

use more a natural mix of the images in our databases. 

NIST does not intend to include a strict repetition of the ICE 06 trial5 in IREX 08. However, IREX 08 is likely to supplement 

our larger corpora with ICE data. NIST will: 

― attempt to exclude images which would contribute to false rejection whatever compression or compact 

representation is selected (e.g. eyes closed) 

― document this practice in all reports, report the number of such exclusions, and include text on the effect of 

regarding these exclusions as FTE and FTA. 

― add caveats to published reports that the performance values are specifically not predictive of any deployment in 

which imaging is systematically dissimilar to that reflected by the databases used. 

5.9. Audience and options for participation 

Universities and commercial concerns with capabilities in following areas are invited to participate in the IREX 08 test. 

― Production of conformant ISO/IEC 19794-6 records 

― Segmentation of iris imagery, including production of polar formats 

― Verification of standardized image records. 

Prospective participants should read this document then complete the application form, Annex A. Participants must 

submit an SDK that provides all of the components identified in one of the rows of Table 4. All components in a row shall 

be supplied. 

Table 4 – IREX classes of participation 

1 2 3 4 5 6 7 8 

Class Annex A 

Participation 

agreement 

Ability to convert 

a raw rectilinear 

image into a 

cropped 

rectilinear image 

[CAM07] 

Ability to convert 

a raw rectilinear 

image into a ROImasked 

rectilinear image 

[CAM07] 

Ability to convert 

a raw rectilinear 

image into an 

unsegmented 

polar image 

[IRI07] 

Ability to extract 

features from a 

cropped [CAM07] 

image and match 

Ability to extract 

features from a 

cropped and 

masked [CAM07] 

image and match. 

Ability to extract 

features from an 

[IRI07] polar 

image and match 

X + + 

Y + + + + + + 

Z + + + + + + 

27

28

29

30

 The inclusion of these classes is motivated as follows: 

― Class X allows "enrollment-only" organizations to participate, by executing cropping only. 

― Class Y exists to allow organizations to demonstrate the capability to generate cropped and ROI-masked images, and 

 to extract features from all kinds of images. 

5 The ICE homepage is http://iris.nist.gov/ice 

NIST Concept, Evaluation Plan and API Page 12 of 33 
 

 

5

10

15

20

25

30

1 

2 

3 

4 

6 

7 

8 

9 

11 

12 

13 

14 

16 

17 

18 

19 

21 

22 

23 

24 

26 

27 

28 

29 

31 

32 

33 

34 

36 

37 

 

35

IREX 2008 

― Class Z exists to allow organizations to demonstrate the capability to generate unsegmented polar images, and to 

extract features from all kinds of images. 

A participant may enter SDKs for more than one class. A participant may merge Y and Z functionalities into one SDK. 

5.10. Number of submissions 

Organizations may enter two SDKs per class. This would allow, for example, "fast vs. slow", or "experimental vs. mature" 

implementations to be tested. 

5.11. Compression metrics 

JPEG implementations accept a quality parameter that controls the quantization of the DCT coefficients specified in 

ISO/IEC 10918. The quantitative effect of this parameter is not standardized, and may vary between implementations. 

ISO/IEC 15444 JPEG 2000 implementations are parameterized by a target value, such as the number of bits per pixel. 

NIST is likely to survey over other JPEG 2000 compression parameters, as available and appropriate. This would form the 

basis of a compression profile. 

Some input images are more compressible than others. For example, a motion-blurred image will compress well, as will 

images with large areas of smooth skin content. 

NIST intends to establish operational guidance on the application of compression. NIST intends to quantify compression 

damage in terms of, at least, PSNR as the independent variable. However, compression software does not take this an 

input parameter and thus practical implementation would require iterative schemes to achieve a desired entropy or PSNR 

value. This may be tenable if computational expense is not prohibitive. NIST intends to report compression times. 

5.12. Provision of sensor information to SDKs 

NIST will provide the manufacturer and model information to the image processing functions provided in the SDK. This 

allows the implementation to tailor its algorithms to known properties of the sensor (e.g. spectral properties of the 

illuminant). NIST is not, however, in possession of detailed sensor specifications, and it is therefore incumbent on 

participants to acquire such information and to use it as they see fit. 

5.13. Verification performance 

The test will embed pure 1:1 template comparisons. It will not formally enroll a population and thus will not support 6 verification systems that run in an identification mode, execute cohort normalization techniques . This test nevertheless 

is influential on 1:N performance because identification accuracy is closely related to the result of N 1:1 comparisons. 

5.14. Phased testing 

In an attempt to support SC37 timelines, NIST will depart from its usual practice (e.g. MINEX II, ELFT I) and conduct this 

test in just a single phase. This means the results of testing will be published sometime after the implementations are 

received, without interim disclosure of results to the supplier. However NIST's purpose to aid development of 

implementations of the proposed ISO standard and we will therefore actively assist participants. For example, we will 

communicate obviously incorrect, aberrant or poor behavior to the supplier e.g. FNMR > 0.03 at FMR = 0.001 (i.e. worse 

than the worst ICE 2006 result). 

5.15. Open-source code for ISO/IEC 19794-6 

7 As part of NIST's Biometric Data Interchange (BIOMDI) software distribution , NIST has exposed its open-source "C" code 

project for the reading, writing and validation of ISO/IEC 19794-6 records. The software is freely distributable. It is under 

 

6 Such normalization methods may still be implemented within the matcher, by, for example, storing a supplier-owned internal 

background set of templates into the SDK. 7 The BIOMDI repository currently includes code for handling standardized iris, face, finger and minutiae records. Instructions for access 

are described here: http://biometrics.nist.gov/nigos/biomdi.html 

NIST Concept, Evaluation Plan and API Page 13 of 33 
 

 

 

5

10

15

20

25

1 

2 

3 

4 

6 

7 

8 

9 

11 

12 

13 

14 

16 

17 

18 

19 

21 

22 

23 

24 

26 

27 

28 

29 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

35

31 

32 

33 

34 

36 

37 

38 

39 

 

 

 

 

 

 

 

 

 

30

IREX 2008 

formal version control and subscribers to the server are automatically informed of development activities. This code is 

now under revision. 

NIST will develop and release C/C++ code to execute forward and reverse polar transforms. That is it will execute 

coordinate transformation via interpolation. It will not implement any segmentation of feature detection function. This 

will execute both bilinear and bicubic interpolation. NIST will evaluate both variants. 

6. Standardized data elements 

6.1. Overview 

Much of IREX 08 will involve the generation or use of the data structure defined in Table 6. It is the definitive data 

structure for all IREX operations. It is derived from the original ISO/IEC 19794-6:2005 record and has been extended here 

to include support for ROI-masked images [CAM07, CAM08] and unsegmented polar images [IRI07]. If it is used 

successfully here, NIST would contribute this toward the revision of ISO/IEC 19794-6. 

6.2. Identifying the records of the standard 

The ISO/IEC 19794-6:2005 standard [STD05] required all iris biometric data blocks (BDBs) to be wrapped in CBEFF 

headers8

. For IREX 08, CBEFF headers shall be absent. In ISO/IEC 19794-6:2005, the only means of differentiating 

rectilinear records from polar records was via the CBEFF format type (Rectilinear = 0x0009; Polar = 0x000B). For IREX 08, 

in order to differentiate the various forms, NIST has added a new field to the record - see Line 3 of Table 6. 

The following subsections are a provisional attempt at encoding the [CAM07,IRI07] proposal in language suitable for the 

revision of the ISO-standard. Definitive language will be developed in SC 37 Working Group 3. 

6.3. The Cropping operation 

In keeping with ISO notation; the term "shall" connotes a requirement and the term "should" connotes recommendation. 

The [CAM08] paper notes that "the algorithms correctly localized the iris in all [ICE] images and produced from each one a 

new cropped image of 320x320 pixels with the iris centered in it. For those images in which the iris was partly outside the 

original image frame, the missing pixels were replaced with black ones." While this may be appropriate for LG 2200 

images used in the ICE collection, it is not portable to larger sizes. We therefore suggest the following rules. 

― The crop region shall be symmetric about the iris center. 

― The crop region should be sized such that at least N ≥ M pixels of the sclera are exposed on either side the iris, where 

the lower limit M = max(60, 0.4R) where R is the estimate of the iris radius. 

― Parts of the iris estimated to have been cropped during capture (i.e. absent in the input image) shall be replaced with 

pixels of value 0. 

NB: NIST will conduct a survey over the 60 and 0.4 parameters. 

6.4. The ROI masking operation 

6.4.1. Definition 

In keeping with ISO notation; the term shall connotes a requirement and the term should connotes recommendation. 

The pixels in the sclera region should be substituted with a fixed mask value. This value shall be recorded on line 32 of 

Table 6. The sclera mask shall extend to the first and last columns unless the iris itself lies on those columns, or the upper 

and lower eyelids touch there. 

The pixels in the upper eyelid region should be substituted with a fixed mask value. This value shall be recorded on line 

30 of Table 6. The upper eyelid mask shall extend to the first (top) row of the image unless the iris itself lies in this row. 

The upper eyelid mask shall extend to the leftmost and rightmost columns of the image unless the iris itself lies there. 

8 CBEFF, published as ISO/IEC 19785-1, advances abstract fields and values for encapsulating, signing and encrypting BDBs. 

NIST Concept, Evaluation Plan and API Page 14 of 33 
 

 

1 

2 

3 

4 

5 

6 

7 

8 

9 

10 

11 

12 

13 

14 

15 

16 

17 

18 

19 

20 

21 

22 

23 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

24 

25 

26 

27 

28 

29 

30 

31 

32 

33 

34 

35 

36 

 

 

 

 

 

 

 

 

 

 

 

 

IREX 2008 

The pixels in the lower eyelid region should be substituted with a fixed mask value. This value shall be recorded on line 31 

of Table 6. The lower eyelid mask shall extend to the last (bottom) row of the image unless the iris itself lies in this row. 

The lower eyelid mask shall extend to the leftmost and rightmost columns of the image unless the iris itself lies there. 

At least one region shall be masked. For regions that are not masked, the corresponding Table 6 mask value shall be 0. 

Masks shall be understood as being four-connected regions of a single pixel value. 

6.4.2. Assigned values 

When masking is used, the non-iris region shall be masked with three values according to the following rules. If the upper 

and lower eyelid mask values are respectively U and L, with S the sclera mask value, then: 

― S ≠ U 

― S ≠ L 

― L ≤ U 

― 1 ≤ U ≤ 255, but without a specific reason to do otherwise, recommended value is U = 128 

― 1 ≤ L ≤ 255, but without a specific reason to do otherwise, recommended value is L = 128 

― 1 ≤ S ≤ 255, but without a specific reason to do otherwise, recommended value is S = 200 

In each case, the special value 0 is reserved to indicate that the region has not been masked. This would support an ISO 

standard for raw images, and for images in which one or more regions might reasonably not be masked. The ongoing 

revision of ISO/IEC 19794-6 might adopt these rules and conventions. 

6.4.3. Mask-ROI transition blurring 

Regarding the pixels on the boundary between the mask and the original image, [CAM07] and [CAM08] include this 

statement: "the transition to eyelid substitution regions was locally smoothed by a [5x7] kernel to minimize the 

boundary's impact on the coding budget". 

Therefore, the value of each non-masked pixel that is eight-connected to a masked pixel should be substituted by the 

result of the kernel neighborhood summation using "an isotropicly binomial 7x7 kernel", K, as offered by L1: 

K = 1/(64*64) uu T 

where: 

u = [ 1 6 15 20 15 6 1 ]T 

6.5. Unsegmented polar records 

6.5.1. Outer circle size 

The implementation should over-segment the iris. That is, it should assign the radius of the outer circle to be about 15% 

larger than that of the iris boundary when it is best approximated by a circle. 

NB: NIST will survey over this parameter (by re-segmenting original images). The 15% value is a default. 

6.5.2. Inner circle size 

The implementation should under-segment the pupil. That is, it should assign the radius of the inner circle to be about 

20% smaller than that of the pupil boundary when it is best approximated by a circle. 

NB: NIST will survey over this parameter (by re-segmenting original images). The 20% value is a default. 

6.6. Polar encoding 

The ISO/IEC 19794-5:2005 encoding procedure (subclause 6.3.2.7 "Polar conversion") shall be followed. Note that while 

the procedure allows for different iris and pupil centers, they shall be co-located here per the concentricity requirement 

of [IRI07]. NIST will release code to effect the forward- and reverse-polar interpolations. 

NIST Concept, Evaluation Plan and API Page 15 of 33 
 

 

 

1 

2 

3 

4 

5 

6 

7 

8 

9 

10 

11 

12 

13 

14 

15 

16 

17 

18 

19 

20 

 

 

 

 

 

 

 

 

 

 

 

 

21 

22 

23 

24 

 

 

 

 

 

IREX 2008 

6.7. Auxiliary boundary data 

6.7.1. Requirement 

IREX does not make provision for purely vendor-defined data (e.g. a proprietary template) in the IREX record because it is 9 non-interoperable . However, reflecting the fact that segmentation information can be very useful (and, operationally, 

could be computed during acquisition) the IREX record allows implementers of all of the formats to supplement the 

mandatory fields with either or both of the boundary encodings listed in sections 6.7.2 and 6.7.3. 

6.7.2. Ellipse encoded boundaries 

Implementers may elect to populate the 24 byte block of best-fit ellipses of the pupil and iris, i.e. Table 6 lines 39 to 50. 

6.7.3. FCC encoded boundaries 

Implementers may elect to populate either or both of the Freeman chain code blocks on Lines 51-54 of Table 6. This shall 

be indicated by setting the respective N values to N > 0 and by including data as specified in Table 5. This first block 

applies to the inner iris-pupil boundary. The second block applies to the iris-sclera boundary. 

Each element of the FCC shall be stored immediately following its predecessor, without regard to byte boundaries. If 

necessary, the FCC shall be padded with trailing zeros to ensure that the result is an integral number of octets. 

Eight-connected Freeman chain codes shall be used. These allow encoding of an arbitrary path in 3 bits per pixel. For an 

iris of radius 100 pixels, and a pupil of radius 40 pixels, such encoding would require, with a small header, around 220 and 

90 bytes respectively. 

Table 5 – Format for Freeman chain code 

# Field Length 

1 X-coordinate of first pixel in closed path 2B 

2 Y-coordinate of first pixel in closed path 2B 

3 Number of elements in chain code, K 2B 

4 Bit-packed Freeman chain code, zero padded to nearest octet if (3N % 8 != 0) ≤ 3K/8 + 1 

Figure 1 – Example Freeman Chain Code 

If the grey region denotes the body of a pupil 

then, from the first pixel "1" to the last "8", the 

FCC result would be: 4,4,4,7,7,0,2,2 which would 

be encoded as: 

100100100111111000010010 

MOD Jun 20, 2008: Labels were in wrong order. 

4 3 2 1 

5 8 

6 7 

MOD Jun 20, 2008 added figure: The standard directions of Figure 2 shall be used. 

Figure 2 – Freeman Chain Code Directions 

3 2 1 

4 X 0 

5 6 7 

9 The issue of allowing Extended Data has been discussed with respect to other biometric standards and has been deprecated because 

it is only valuable when the producing and consuming implementations are manufactured by the same company. 

NIST Concept, Evaluation Plan and API Page 16 of 33 
 

 

1 

2 

3 

 

 

IREX 2008 

6.8. Inclusion of non-standard information 

The records shall contain only the information defined in this document. This restriction prohibits steganographic markup 

of images. Interoperability is not assisted by proprietary hidden information. 

NIST Concept, Evaluation Plan and API Page 17 of 33 
1 

Section title and/or field name L IREX actual or required values Remarks 

Iris Record Header (adapted from Table 2 of 37N2484 posted February 2008 as the latest revision text of ISO/IEC 19794-6) 

1. Format Identifier 4 B 0x49495200 i.e. ASCII "IIR\0" 

2. Version Number 4 B 0x30313500 '015\0' a non-standard interim value for IREX 08 

3. Kind of imagery in this record 8b 0000 0001b = 1 Rectilinear without ROI masking without any cropping 

0000 0011b = 3 Rectilinear without ROI masking but cropped so iris is abo

0000 0111b = 7 [CAM07, CAM08] Rectilinear with masking and cropping 

0001 0000b = 16 [IRI07] Unsegmented polar 

0011 0000b = 48 Rectilinear reconstruction of [IRI07] unsegmented polar im

4. Record Length 4 B 32 46 ≤ L ≤ 2 - 1 Total length 

5. Capture Device ID 2 B Value will be provided to SDK, which stores it here. Value 

6. Number of eyes imaged 1 B 1 In IREX this will always be 1 

7. Record header length 2 B 46 In ISO drafts this was 45, but here line 3 adds 1 to make 46 

8. Iris image properties 

(NB order) 

Horz. orientation 2 b ORIENTATION_BASE Bits 0 and 1 i.e. 2 least significant bits (per see 6.4 in N248

9. Vert. orientation 2 b ORIENTATION_BASE Bits 2 and 3 

10. Scan type 2 b SCAN_TYPE_PROGRESSIVE Bits 4 and 5. One of these two values will be supplied to t

SCAN_TYPE_INTERLACE_FRAME 

11. Occlusions 1 b Polar format only, see ISO/IEC 19794-6:2005 

12. Occlusion filling 1 b Polar format only, see ISO/IEC 19794-6:2005 

13. Reserved for future use 8b 0 Most significant bits are reserved in ISO/IEC 19794-6 

14. Iris diameter (rectilinear) 2 B Expected iris diameter in pixels. Optional: if not estimated 

15. Image format 2 B IMAGEFORMAT_MONO_RAW IREX SDKs are not permitted to compress, and not require

not be used. IMAGEFORMAT_MONO_RAW is the only allo

16. Raw image width 2 B > 0 For rectilinear, these values are the dimensions of the ima

Table. For polar images these are the dimensions of the p

representation was extracted. 

17. Raw image height 2 B > 0 

18. Intensity depth 1 B 8 bits 

19. Image transformation (polar only) 1 B 1 TRANS_STD = 1 i.e. linear radial interpolation per [STD05, 

20. Device unique identifier 16 B '0000000000000000' 16 character zeroes '0' = 0x30, not 0x00. 

Iris Biometric Subtype Header (Table 3 of 37N2484 posted February 2008 as the latest revision text of ISO/IEC 19794-6) 

21. Eye 1 B EYE_UNDEF = 0 (0x00) NIST expects L/R will be known and supplied to SDK 

EYE_RIGHT = 1 (0x01) EYE_LEFT = 2 (0x02) 

22. Number of iris images of this eye 2 B 1 NIST will not present multiple images, so this is 1 here 

Iris Image Header (Table 4 of 37N2484 posted February 2008 as the latest revision text of ISO/IEC 19794-6) 

23. Image length 4B M > 0 Length of image data. For uncompressed 8bit greyscale d

24. Image number 2 B 1 This field is an index starting at 1 

25. Quality 1 B 0 ≤ Q ≤ 100, 255 This value shall be computed and stored here by the SDK 

IREX 2008 

Table 6 – Structure for the proposed formats for ISO/IEC 19794-6 

NIST Concept, Evaluation Plan and API Page 18 of 33 
IREX 2008 

26. Quality algorithm vendor ID 2B This value is optional in IREX. IBIA code may be used - NIS

27. Quality algorithm ID 2B The value is optional in IREX 28. Rotation angle of eye 2 B 0 ... 0xFFFE 

0xFFFF =ROT_ANGLE_UNDEF 

= (unsigned short) round(65536*angle/360) modulo 6553counter-clockwise in degrees 

29. Rotation uncertainty 2 B 0 ... 0xFFFE 

0xFFFF =ROT_UNCERTAIN_UNDEF 

= (unsigned short) round(65536*uncertainty/180) where 0 degrees and is the absolute value of maximum error 

Fields supporting ROI-masked images 

30. Mask value for upper eyelid 1B These three fields are populated if Kind = 7. Otherwise all 

See definitions and rules in section 6.4. Beyond IREX 08 the depth may need to be >= 8 bits. 

31. Mask value for lower eyelid 1B 32. Mask value for sclera 1B 

Fields supporting UNSEG polar images 

33. Number of samples radially 2B 0 < NR These six fields shall be populated if Kind = 16 or Kind = 48 

NR is the number of samples along a spoke NC is the number of spokes around the iris The polar image data on the last line of this table has heigCoordinate system is zero oriented with (0,0) at the top leThe inner and outer circle centers are concentric. 

34. Number of samples circumferentially 2B 0 < NC 

35. X coordinate of inner + outer circle centers 2 B 0 ≤ x < W 36. Y coordinate of inner + outer circle centers 2 B 0 ≤ y < H 

37. Inner circle radius 2 B 0 < r 

38. Outer circle radius 2 B 0 < r 

Fields supporting all images 

39. X coord of the center of the ellipse 

approximating the pupil boundary 

2 B Population of these six fields is allowed but not required f

elects not to compute the ellipse then it shall assign X = 0xConsumers of this data shall ignore these fields if X = 0xFFbounds with respect to the width on line 16. 

40. Y coord of the center of the ellipse 

approximating the pupil boundary 

2 B 

41. X coord of the intersection pt. of the semi-major 

axis with the ellipse approximating the pupil 

2 B 

42. Y coord of the intersection pt. of the semi-major 

axis with the ellipse approximating the pupil 

2 B 

43. X coord of the intersection pt. of the semi-minor 

axis with the ellipse approximating the pupil 

2 B 

44. Y coord of the intersection pt. of the semi-minor 

axis with the ellipse approximating the pupil 

2 B 

45. X coord of the center of the ellipse 

approximating the iris boundary 

2 B Population of these six fields is allowed but not required f

elects not to compute the ellipse then it shall assign X = 0xConsumers of this data shall ignore these fields if X = 0xFFbounds with respect to the width on line 16. 

46. Y coord of the center of the ellipse 

approximating the iris boundary 

2 B 

47. X coord of the intersection pt. of the semi-major 

axis with the ellipse approximating the iris 

2 B 

48. Y coord of the intersection pt. of the semi-major 

axis with the ellipse approximating the iris 

2 B 

49. X coord of the intersection pt. of the semi-minor 

axis with the ellipse approximating the iris 

2 B 

NIST Concept, Evaluation Plan and API Page 19 of 33 
1 

IREX 2008 

50. Y coord of the intersection pt. of the semi-minor 

axis with the ellipse approximating the iris 

2 B 

Continued next page ... 

51. Freeman code length for pupil-iris boundary 2 B NP bytes See section 6.7. These two blocks are allowed but not req

sclera-iris FCC length value follows immediately. Aug28 20in Table 5 is K the length in bytes will be: N = 6 + 3

N = 6 + 3

52. Freeman code data for pupil-iris boundary NP 

53. Freeman code length for sclera-iris boundary 2 B NS bytes 54. Freeman code data for sclera-iris boundary NS 55. Image data M Length M encoded on line 23, in bytes 

NIST Concept, Evaluation Plan and API Page 20 of 33 
 

 

1 

2 

3 

4 

5 

6 

7 

8 

9 

10 

11 

12 

13 

14 

15 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

16 

17 

18 

19 

20 

21 

22 

23 

24 

25 

26 

27 

 

 

 

 

 

IREX 2008 

7. PC-based API specification 

7.1. Overview 

This section describes the IREX API. All SDK's submitted to IREX 08 shall implement the functions below here as required 

by the classes of participation listed in Table 4. 

7.2. Testing interface 

7.2.1. Requirement 

IREX participants shall submit an SDK which presents the "C" prototyped interface given in the following subsections. 

7.2.2. Sensor identifiers 

IREX will use images from: 

― a large corpus collected using the LG 3000. 

― a larger corpus collected using the Securimetrics PIER camera. 

― the smaller sequestered ICE 06 corpus of LG 2200 images 

NIST is actively seeking to extend this to include other sources - please see NIST's call for images on Page 2. To support 

interoperable i.e. cross-sensor matching, the SDK will be told the sensor the two byte unsigned integer values in Table 7. 

Table 7 – Sensor identifiers 

# Sensor Manufacturer and Model Identifier 

1 LG 2200 0x2A16 

2 LG 3000 0x2A1E 

3 LG 4000 0x2A26 

4 Securimetrics PIER 0x1A03 

5 Unknown or unspecified 0x0000 

Presence on this table indicates NIST's intention to use images captured by these devices. NIST will revise this table as 

other data becomes available. 

7.2.3. Geometric, photometric or other alterations to images 

It is at the discretion of the provider whether to alter the input images during the Table 6 record preparation. If a vendor 

believed for instance that contrast enhancement would produce a more easy-to-recognize image then the 

implementation is permitted to do this. A more important example is described in Section 2 of [CAM07,CAM08]. 

For those images in which the iris was partly outside of the original image frame, the missing 

pixels were replaced with black ones. For those in which the algorithms detected that the 

gaze was directed away from the camera, as gauged by projective deformation of the eye 

shape, a corrective affine transformation was automatically applied which effectively 

“rotated” the eye in its socket back into orthographic perspective on-axis with the camera. 

Such steps are allowed and are likely to allow downstream feature extractors and matchers to give better performance. 

NIST takes no position on whether these or other operations should be applied. NIST does however prohibit the 

application of compression and recommends against any action which would blur the image. Note that vendors might 

profitably implement local image processing steps (i.e. not requiring the entire original image) in the front-end of the 

feature extraction routines. 

NIST Concept, Evaluation Plan and API Page 21 of 32 
 

 

1 

2 

3 

4 

5 

6 

7 

8 

9 

Prototype INT32 convert_raster_to_cropped_rectilinear( 

const BYTE *uncompressed_raster_data, 

const UINT16 image_width, 

const UINT16 image_height, 

const BYTE horz_orientation, 

const BYTE vert_orientation, 

const BYTE scan_type, 

const BYTE which_eye, // August 28, 2008: New parameter 

const BYTE image_format, 

const BYTE intensity_depth, 

const UINT16 nist_encoded_device_id, 

INT16 *bbox_topleft_x, //June25, 08: These two parameters are new and are introduced toallow NIST 

INT16 *bbox_topleft_y, //to surveyover crop sizes. July 28, 2008: They're are SIGNED (x,y) so can be negative. 

const UINT32 allocated _bytes, // August 28, 2008: New parameter added for safety. 

BYTE * c_rectilinear_image); 

Description This function takes a raw inputimage and outputs a corresponding cropped image. 

The memory for the output structure is allocated before the call i.e. the implementation shall not allocate memory for 

the result. The function returns either success (0) or failure (non-zero). Failure indicates a failure to convert the image. 

The result will nevertheless be a conformant instance with zero irides and zero images. 

Input 

Parameters 

uncompressed_raster_data The uncompressed raw image used for template creation. 

image_width The number of pixels indicating the width of the image. 

image_height The number of pixels indicating the height of the image. 

horz_orientation NIST anticipates setting these values to ORIENTATION_BASE, per [STD05, 6.5.4]. 

vert_orientation 

scan_type Progressive or interlaced. Values per the standard. 

which_eye EYE_UNDEF = 0 (0x00) 

EYE_RIGHT =1 (0x01) 

EYE_LEFT =2 (0x02) Theseare the values used in ISO/IEC 19794-6:2005. 

image_format NIST anticipates using only unprocessed uncompressed 8 bit 

image format will be 0x0002, and theintensity depth will be 

grayscale data, so the

8, both per [STD05]. intensity_depth 

nist_encoded_device_id A two byte unsigned integer value from Table 7 

allocated_bytes Number of bytes NIST allocated for the output image record 

Output 

Parameters 

c_rectilinear_image The output record, per Table 6 with Kind = 3 

bbox_topleft_x X coordinate in the original image from which the crop was prepared 

bbox_topleft_y Y coordinate in the original image from which the crop was prepared 

Return 

Values 

0 Success 

2 Elective refusal to generate this Kind of output record 

4 Involuntary failure to make output record - e.g.could not find iris-sclera boundary. 

6 Elective refusal to produce an output record - e.g.on quality grounds. 

8 Cannot parse input data (i.e. assertion that input record is non-conformant) 

Other Vendor-defined 

 

IREX 2008 

7.2.4. Conversion of raw rectilinear imagery to cropped rectilinear 

To assess viability of the proposed standard crop-only format, participating submissions to IREX 08 shall convert a raw 

raster iris image into a cropped raster iris image, and write the result as a Table 6 instance of Kind = 3. To do this the 

implementation will need to find the iris center and crop symmetrically around it. The implementation shall not compress 

the image data. 

June 25, 2008. The implementation shall not rotate the iris: Instead if rotation is detected it shall be recorded in the 

appropriate fields of Table 6, i.e. lines 28-29. Template generators and/or matchers should heed such values. 

The provided SDK shall implement the API call specified in Table 8. 

Table 8 – IREX API for preparation of cropped rectilinear records 

NIST Concept, Evaluation Plan and API Page 22 of 32 

10 
 

 

1 

2 

3 

4 

5 

6 

7 

8 

9 

10 

11 

12 

13 

14 

 

IREX 2008 

The number of times a non-zero error codes is returned will be counted, reported and appropriately factored into 

analyses. 

7.2.5. Conversion of raw rectilinear imagery to cropped ROI-masked rectilinear 

To assess viability of the proposed standard's cropped-and-ROI-masked format, participating submissions to IREX 08 shall 

convert a raw raster iris image into a cropped raster iris image, replace eyelids and sclera with fixed pixel values, and write 

the result as a Table 6 instance of Kind = 7. To do this the implementation will need to find the iris center and crop 

symmetrically around it, and find the eyelids and iris-sclera boundaries. The implementation shall not compress the 

output image data. 

The function shall be implemented with the API call specified in Table 9. 

Table 9 – IREX API for preparation of cropped-and-ROI-masked records 

Prototype INT32 convert_raster_to_cropped_and_masked_rectilinear( 

const BYTE *uncompressed_raster_data, 

const UINT16 image_width, 

const UINT16 image_height, 

const BYTE horz_orientation, 

const BYTE vert_orientation, 

const BYTE scan_type, 

const BYTE which_eye, // New August 28, 2008. 

const BYTE image_format, 

const BYTE intensity_depth, 

const UINT16 nist_encoded_device_id, 

const UINT32 allocated _bytes, // August 28, 2008: New parameter added for safety. 

BYTE * cm_rectilinear_image); 

Description This function takes a raw input image and outputs the corresponding cropped and ROI-masked image. 

The memory for the output structure is allocated before the call i.e. the implementation shall not allocate memory for 

the result. The function returns either success (0) or failure (non-zero). Failure indicates a failure to convert the image. 

The result will nevertheless be a conformant instance with zero irides and zero images. 

Input 

Parameters 

uncompressed_raster_data The uncompressed raw image used for template creation. 

image_width The number of pixels indicating the width of the image. 

image_height The number of pixels indicating the height of the image. 

horz_orientation NIST anticipates setting these values to ORIENTATION_BASE, per [STD05, 6.5.4]. 

vert_orientation 

scan_type Progressive or interlaced. Values per the standard. 

which_eye EYE_UNDEF = 0 (0x00) 

EYE_RIGHT = 1 (0x01) 

EYE_LEFT = 2 (0x02) These are the values used in ISO/IEC 19794-6:2005. 

image_format NIST anticipates using only unprocessed uncompressed 8 bit 

image format will be 0x0002, and the intensity depth will be 

grayscale data, so the 

8, both per [STD05]. intensity_depth 

nist_encoded_device_id A two byte unsigned integer value from Table 7 

allocated_bytes Number of bytes NIST allocated for the output image record 

Output cm_rectilinear_image The output cropped and ROI-masked image, per Table 6 with Kind = 7 

Parameters 

Return 

Values 

0 Success 

2 Elective refusal to generate this Kind of output record 

4 Involuntary failure to make output record - e.g. could not find iris-sclera boundary. 

6 Elective refusal to produce an output record - e.g. on quality grounds. 

8 Cannot parse input data (i.e. assertion that input record is non-conformant) 

Other Vendor-defined 

The number of times a non-zero error code is returned will be counted, reported and appropriately factored into 

analyses. 

NIST Concept, Evaluation Plan and API Page 23 of 32 
 

 

1 

2 

3 

4 

5 

6 

7 

8 

Prototype INT32 convert_raster_to_unsegmented_polar( 

const BYTE *uncompressed_raster_data, 

const UINT16 image_width, 

const UINT16 image_height, 

const BYTE horz_orientation, 

const BYTE vert_orientation, 

const BYTE scan_type, 

const BYTE which_eye, //NewAugust 28, 2008. 

const BYTE image_format, 

const BYTE intensity_depth, 

const UINT16 nist_encoded_device_id, 

const UNIT16 num_samples_radially, // Aug 6 2008: If either of these input parameters are 0, the implemconst UINT16 num_samples_circumferentially, //entation should decide suitable values or use published defaults. 

const UINT32 allocated _bytes, // August 28, 2008: New parameter added for safety. 

BYTE * unseg_polar_image); 

Description This function takes raw inputimage and outputs the corresponding unsegmented polar image. The coordinates of the 

pupil and iris centers are returned also. 

The memory for the template is allocated before the call i.e. the implementation shall not allocate memory for the 

result. The function returns either success (0) or failure (non-zero). Failure indicates a failure to convert the image. The 

result will nevertheless be a conformant instance with zero irides and zero images. 

Input 

Parameters 

uncompressed_raster_data The uncompressed raw image used for template creation. 

image_width The number of pixels indicating the width of the input image. 

image_height The number of pixels indicating the height of the input image. 

horz_orientation NIST anticipates setting these values to ORIENTATION_BASE, per [STD05, 6.5.4]. 

vert_orientation 

scan_type Progressive or interlaced. Values per the standard. 

which_eye EYE_UNDEF = 0 (0x00) 

EYE_RIGHT =1 (0x01) 

EYE_LEFT =2 (0x02) Theseare the values used in ISO/IEC 19794-6:2005. 

image_format NIST anticipates using only unprocessed uncompressed 8 bit 

image format will be 0x0002, and theintensity depth will be 

grayscale data, so the

8, both per [STD05]. intensity_depth 

nist_encoded_device_id A two byte unsigned integer value from Table 7 

num_samples_radially The number of sample along a spoke. The output polar data shall have this height. 

num_samples_circumferentially The number of "spokes" around the iris. The output polar data shall have this width. 

allocated_bytes Number of bytes NIST allocated for the output image record 

Output unseg_polar_image The output record, per Table 6, with the values on lines 33 - 38 set correctly. The 

Parameters Kind on line 3 and the image data on line 55 shall be set as follows. 

― EITHER: Set Kind =16 and insert proper polar format image data. 

You can usethe NIST code available for the interpolation needed to

execute the forward polar transform. 

― OR : SetKind =1, copy theinput raster to the output record. 

Return Value 0 Success 

2 Elective refusal to generate this Kind of output record 

IREX 2008 

7.2.6. Conversion of raw rectilinear imagery to unsegmented polar 

To assess viability of the proposed standard's unsegmented polar format, participating submissions to IREX 08 shall 

convert a raw raster iris image into an unsegmented polar image and write the result as a Table 6 instance of Kind = 16. 

To do this the implementation will need to find concentric circles in the pupil and outside the iris, and to execute the 

forward polar transformation (using NIST will provide reference polar transformation code). The implementation shall 

not compress the output image data. 

The function shall be implemented with the API call specified in Table 10. 

Table 10 – IREX API for creation of unsegmented polar records 

NIST Concept, Evaluation Plan and API Page 24 of 32 
 

 

 

 

 

 

1 

2 

3 

4 

5 

6 

7 

8 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

9 

10 

11 

12 

13 

 

 

 

 

IREX 2008 

4 Involuntary failure to make output record - e.g. could not find iris-sclera boundary. 

6 Elective refusal to produce an output record - e.g. on quality grounds. 

8 Cannot parse input data (i.e. assertion that input record is non-conformant) 

Other Vendor-defined failure. 

The number of times a non-zero error code is returned will be counted, reported and appropriately factored into 

analyses. 

7.2.7. Template creation 

This function converts a Table 6 record into an opaque proprietary template. The function will need to look at the header 

of the input record to determine the content, particularly the "Kind" value on Line 3. The function should return the 

defined error code if it does not support certain Kinds. 

Table 11 – IREX API template creation 

Prototype INT32 convert_image _to_template( 

const BYTE *input_record, 

UINT16 *template_size, 

BYTE *proprietary_template); 

Description This function takes either a rectilinear image, or an ROI-masked image, or an unsegmented polar image, and outputs a 

proprietary template. The implementation should inspect the input header to determine which kind of imagery is 

being provided, per the version number values given in section 6.2. 

The memory for the output template is allocated before the call i.e. the implementation shall not allocate memory for 

the result. In all cases, even when unable to extract features, the output shall be a template record that may be 

passed to the match_templates function without error. That is this routine must internally encode "template creation 

failed" and the matcher must transparently handle this. 

Input input_record An instance of Table 6. Implementations must alter their behavior according to the Kind of 

Parameters image. The implementation shall support these values: 

Kind = 1 

Kind = 3 

Kind = 7 

Kind = 48 

The SDK does not have to support Kind = 16 because NIST will execute any needed reverse 

polar transforms using NIST code to make Kind = 48 instances. 

Output 

Parameters 

Template_size The size, in bytes, of the output template 

proprietary_template The output template. The format is entirely unregulated. June 25,2008: NIST will allocated 8KB 

before the function is called - if 8KB is not enough email us. 

Return Value 0 Success 

2 Elective refusal to process this Kind of input record 

4 Involuntary failure to extract features (e.g. could not find iris in the input-image) 

6 Elective refusal to produce a template (e.g. insufficient iris area) 

8 Cannot parse input data (i.e. assertion that input record is non-conformant) 

Other Vendor-defined failure 

The number of times a non-zero error code is returned will be counted, reported and appropriately factored into 

analyses. When the error code is "2" this will be noted in the IREX report. 

7.2.8. Template comparison 

This function compares two proprietary templates and returns a real-valued distance score. 

Table 12 – IREX API template matching 

Prototype INT32 match_templates( 

const BYTE *verification_template, 

const UINT16 verification_template_size, 

const BYTE *enrollment_template, 

NIST Concept, Evaluation Plan and API Page 25 of 32 
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

1 

2 

3 

4 

5 

6 

7 

8 

9 

10 

11 

12 

 

 

 

 

 

 

 

 

 

13 

14 

15 

16 

17 

18 

19 

20 

21 

IREX 2008 

const UINT16 enrollment_template_size, 

double *dissimilarity); 

Description This function compares two opaque proprietary templates and outputs a non-negative match score. 

The returned score is a non-negative distance measure. It need not satisfy the metric properties. NIST will allocate 

memory for this parameter before the call. When either or both of the input templates are the result of a failed 

template generation (see Table 11), the dissimilarity score shall be -1 and the function return value shall be 2. 

Input Parameters verification_template A template from create_template(). 

verification_template_size 16 The size, in bytes, of the input verification template 0 ≤ N ≤ 2 - 1 

enrollment_template A template from create_template(). 

enrollment_template_size 16 The size, in bytes, of the input enrollment template 0 ≤ N ≤ 2 - 1 

Output 

Parameters 

dissimilarity A dissimilarity score resulting from comparison of the templates, on the 

range [0,DBL_MAX]. See section 7.2.9. 

Return Value 0 Success 

2 Either or both of the input templates were result of failed feature extraction 

Other Vendor-defined failure 

7.2.9. Dissimilarity score 

The template comparison function shall return a measure of the dissimilarity between the persons whose iris data is 

contained in the two templates. So, smaller values indicate more likelihood that the two samples are from the same 

person. This deviates from many prior NIST tests which have used "larger-is-more-genuine" semantics. 

There is no requirement for the scores to be Hamming distances. 

There is no requirement for values to obey the metric property. 

7.2.10. Implementation identifiers 

The implementation shall support the self-identification function of Table 13. This function is required to support internal 

NIST book-keeping. The version numbers should be distinct between any versions which offer different algorithmic 

functionality. 

Table 13 – IREX API get_pids function 

Prototype INT32 get_pid(UINT32 *nist_assigned_identifier, char *email_address); 

Description This function retrieves an identifier that the provider must request from NIST irex@nist.gov, and hardwire into the 

source code. NIST will assign the identifier that will uniquely identify the supplier and the SDK version number. 

Output 

Parameters 

nist_assigned_identifier A PID which identifies the SDK under test. The memory for the identifier is allocated 

by NIST's calling application, and shall not be allocated by the SDK. 

email_address Point of contact email address as null terminated ASCII string. NIST will allocates at 

least 64 bytes for this. SDK shall not allocate. 

Return Value 0 Success 

Other Vendor-defined failure 

7.3. Software and Documentation 

7.3.1. SDK Library and Platform Requirements 

Participants shall provide NIST with binary code only (i.e. no source code). Header files ( “.h”) are allowed, but these shall 

not contain intellectual property of the company nor any material that is otherwise proprietary. It is preferred that the 

SDK be submitted in the form of a single static library file (ie. “.LIB” for Windows or “.a” for Linux). However, dynamic and 

shared library files are permitted. 

If dynamic or shared library files are submitted, it is preferred that the API interface specified by this document be 

implemented in a single “core” library file with the base filename ‘libIREX’ (for example, ‘libIREX.dll’ for Windows or 

NIST Concept, Evaluation Plan and API Page 26 of 32 
 

 

 

5

10

15

20

25

30

1 

2 

3 

4 

6 

7 

8 

9 

11 

12 

13 

14 

16 

17 

18 

19 

21 

22 

23 

24 

26 

27 

28 

29 

31 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

35

32 

33 

34 

36 

37 

38 

 

 

 

 

 

 

 

IREX 2008 

‘libIREX.so’ for Linux). Additional dynamic or shared library files may be submitted that support this “core” library file (i.e. 

the “core” library file may have dependencies implemented in these other libraries). 

7.3.2. Linking 

NIST will link the provided library file(s) to a C language test driver application developed by NIST. The runtime 

environment shall be either 

― RedHat Linux Enterprise 4 or 5 platforms. (PREFERRED) 

― The cygwin10 layer running on a Windows Server 2003 OS. 

Both will use GNU's gcc compiler, version 3.3.3. These use libc. The link command might be: 

― gcc –o irextest irextest.c -L. –lIREX 

Participants are required to provide their library in a format that is linkable using GCC with the NIST test driver, which is 

compiled with GCC. All compilation and testing will be performed on x86 platforms. Thus, participants are strongly 

advised to verify library-level compatibility with GCC (on an equivalent platform) prior to submitting their software to 

NIST to avoid linkage problems later on (e.g. symbol name and calling convention mismatches, incorrect binary file 

formats, etc.). 

Dependencies on external dynamic/shared libraries such as compiler-specific development environment libraries are 

discouraged. If absolutely necessary, external libraries must be provided to NIST upon prior approval by the Test Liaison. 

7.3.3. Installation and Usage 

The SDK must install easily (i.e. one installation step with no participant interaction required) to be tested, and shall be 

executable on any number of machines without requiring additional machine-specific license control procedures or 

activation. 

The SDK’s usage shall be unlimited. The SDK shall neither implement nor enforce any usage controls or limits based on 

licenses, execution date/time, number of executions, presence of temporary files, etc. 

It is recommended that the SDK be installable using simple file copy methods, and not require the use of a separate 

installation program. Contact the Test Liaison for prior approval if an installation program is absolutely necessary. 

7.3.4. Documentation 

Participants shall provide complete documentation of the SDK and detail any additional functionality or behavior beyond 

that specified here. The documentation must define all (non-zero) vendor-defined error or warning return codes. 

7.3.5. Modes of operation 

Individual SDKs provided shall not include multiple “modes” of operation, or algorithm variations. No switches or options 

will be tolerated within one library. For example, the use of two different “coders” by an iris feature extractor must be 

split across two separate SDK libraries, and two separate submissions. 

7.3.6. Watermarking of images 

The SDK functions shall not watermark or otherwise steganographically mark up the images. 

7.4. Runtime behavior 

7.4.1. Speed 

The following limits are instituted to constrain NIST's total IREX computational workload. The absolute times are probably 

less relevant than any relative trends. Deviations above these limits will be allowed but note that timing statistics will be 

reported. 

10 According to http://www.cygwin.com/ is a Linux-like environment for Windows. It consists of two parts: A DLL (cygwin1.dll) which 

acts as a Linux API emulation layer providing substantial Linux API functionality; a collection of tools which provide Linux look and feel. 

NIST Concept, Evaluation Plan and API Page 27 of 32 
 

 

1 

2 

3 

4 

5 

6 

7 

8 

9 

0 

1 

2 

3 

4 

5 

6 

7 

8 

9 

0 

1 

2 

3 

4 

5 

6 

7 

1

1

1

1

1

1

1

1

1

1

2

2

2

2

2

2

2

2

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

IREX 2008 

― The mean template match operation should not exceed 20 milliseconds. 

― The mean template creation operation should not exceed 2.5 seconds. 

― The mean iris segmentation operation (e.g. polar) should not exceed 2.5 seconds. 

The above times assume a vanilla a 2GHz Pentium IV. 

7.4.2. Interactive behavior 

The SDK will be tested in non-interactive “batch” mode (i.e. without terminal support). Thus, the submitted library shall 

not use any interactive functions such as graphical user interface (GUI) calls, or any other calls which require terminal 

interaction e.g. reads from “standard input”. 

7.4.3. Error codes and status messages 

The SDK will be tested in non-interactive “batch” mod, without terminal support. Thus, the submitted library shall run 

quietly, i.e. it should not write messages to "standard error" and shall not write to “standard output”. 

7.4.4. Exception Handling 

The application should include error/exception handling so that in the case of a fatal error, the return code is still 

provided to the calling application. 

7.4.5. External communication 

Processes running on NIST hosts shall not side-effect the runtime environment in any manner, except for memory 

allocation and release. Implementations shall not write any data to external resource (e.g. server, file, connection, or 

other process), nor read from such. If detected, NIST will take appropriate steps, including but not limited to, cessation of 

evaluation of all implementations from the supplier, notification to the provider, and documentation of the activity in 

published reports. 

7.4.6. Stateful behavior 

All components in this test shall be stateless. This applies to segmentation, feature extraction and matching. Thus, all 

functions should give identical output, for a given input, independent of the runtime history. NIST will institute 

appropriate tests to detect stateful behavior. If detected, NIST will take appropriate steps, including but not limited to, 

cessation of evaluation of all implementations from the supplier, notification to the provider, and documentation of the 

activity in published reports. 

8. References 

AN27 NIST Special Publication 500-271: American National Standard for Information Systems — Data Format for the 

Interchange of Fingerprint, Facial, & Other Biometric Information – Part 1. (ANSI/NIST ITL 1-2007). Approved April 20, 

2007. 

BATH06 S. Rakshit and D. M. Monro, Effects of Sampling and Compression on Human Iris Verification, Proc. IEEE International 

Conference on Acoustics, Speech, and Signal Processing, Vol. 2, No. II, pp. 337-340, Toulouse, May 2006 

BATH07 Soumyadip Rakshit and Donald M. Monro, An Evaluation of Image Sampling and Compression for Human Iris Recognition, 

IEEE Transactions On Information Forensics And Security, Vol. 2, No. 3, September 2007 

CAM07 JTC001-SC37-N-2125 — UK Contribution on the effect of severe image compression on iris recognition performance. May 

29, 2007. This document was submitted as a UK contribution to SC 37 Working Group 3. It is available as: John 

Daugman and Cathryn Downing, Effect of severe image compression, on iris recognition performance. Technical Report 

No. 685, University of Cambridge, Computer Laboratory, UCAM-CL-TR-685, ISSN 1476-2986, May 07. 

http://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-685.pdf 

http://isotc.iso.org/livelink/livelink/6461927/JTC001-SC37-N-2125.pdf?func=doc.Fetch&nodeid=6461927 

CAM08 Also very similar material to [CAM07] can be found in: 

John Daugman and Cathryn Downing, Effect of Severe Image Compression on Iris Recognition Performance, IEEE Trans on 

Information Forensics and Security, Vol. 3, No. 1, March 2008. 

NIST Concept, Evaluation Plan and API Page 28 of 32 
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

1 

IREX 2008 

DHS J. Mayer-Splain for DHS, DHS Technical Contribution in Support of Retaining the Iris Polar Image Format. August 31, 2007. 

This document is a password protected contribution toward the US position on the revision of 19794-6:2005. 

http://www.incits.org/tc_home/m1htm/2007xdocs/m1070456.pdf 

I379 American National Standard for Information Technology – iris Image Format for Data Interchange, ANSI/INCITS 379-2004, 

http://www.incits.org 

IRI07 JTC001-SC37-N-2296 US NB Contribution on Compact Iris Format: SC37 Link. Posted 2007-11-03. 

This document was submitted to M1 for consideration as M1/07-0490. 

Readers unable to access either link document should contact NIST. 

http://isotc.iso.org/livelink/livelink/6904418/JTC001-SC37-N-2296.pdf?func=doc.Fetch&nodeid=6904418 

http://www.incits.org/tc_home/m1htm/2007xdocs/m1070490.pdf 

LG S. Shah, Comment on Iris Boundary Determination (Polar Representation) and Polar Format, September 7, 2007. This 

document is a password protected US contribution to the January 2008, SC37/WG3 meeting in Tel Aviv. 

http://www.incits.org/tc_home/m1htm/2007xdocs/m1070486.pdf 

MINEX P. Grother et al., Performance and Interoperability of the INCITS 378 Template, NIST IR 7296 

http://fingerprint.nist.gov/minex04/minex_report.pdf 

MOC P. Grother and W. Salamon, MINEX II - An Assessment of ISO/IEC 7816 Card-Based Match-on-Card Capabilities 

http://fingerprint.nist.gov/minex/minexII/NIST_MOC_ISO_CC_interop_test_plan_1102.pdf 

N2059 JTC001-SC37-N-2059 — German National Body contribution on the revision project on Iris Image Data standard ISO/IEC 

19794-6. April 20, 2007 

N2124 JTC001-SC37-N-2124 — UK Contribution on a defect in ISO/IEC 19794-6 polar iris image format. May 29, 2007 

N2226 JTC001-SC37-N-2226 — Base document for revision of ISO/IEC 19794-6, Information technology: Biometric data 

interchange formats – Part 6: Iris image data 

NIST P. Grother, NIST comments toward US position on N2226, revision of ISO/IEC 19794-6, September 7, 2007 

http://www.incits.org/tc_home/m1htm/2007xdocs/m1070488.pdf 

PERFSTD ISO/IEC FDIS 19795-4 — Biometric Performance Testing and Reporting — Part 4: Interoperability Performance Testing. 

Posted as document 37N2370. 

PROC Hugo Proença and Luís A. Alexandre, Iris Recognition: An Analysis of the Aliasing Problem in the Iris Normalization Stage 

STD05 ISO/IEC 19794-6:2005 — Information technology — Biometric data interchange formats — Part 6: Iris image data 

The standard was published in 2005, and can be purchased from ANSI at http://webstore.ansi.org/ or ISO. 

UNSEG D. Kim, Introducing the Unsegmented Polar Format, posted as m1070606 and m1070606rev to the M1 document register: 

http://m1.incits.org/m1htm/2007docs/m1docreg_2007.htm. These documents are password protected US contributions 

to the January 2008, SC37/WG3 meeting in Tel Aviv. Substantially the same information was presented to the Second 

NIST Quality Workshop on November 8, 2007 and is linked here: 

http://www.itl.nist.gov/iad/894.03/quality/workshop07/presentations.html as 

http://www.itl.nist.gov/iad/894.03/quality/workshop07/proc/Kim_Introducing_Unsegmented_Polar_Data_Format_for_NIST_Presentation_20071106_forPrinting.pdf 

USNA Robert W. Ives, Bradford L. Bonney, and Delores M. Etter, Effect of Image Compression on Iris Recognition, IMTC 2005 – 

Instrumentation and Measurement Technology Conference, Ottawa, Canada, 17-19 May, 2005. 

NIST Concept, Evaluation Plan and API Page 29 of 32 
 

 

1 

2 

3 

4 

5 

6 

7 

8 

9 

10 

11 

12 

13 

14 

15 

16 

17 

18 

19 

20 

21 

22 

23 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

24 

25 

26 

27 

28 

29 

30 

31 

32 

IREX 2008 

Annex A 

Application to participate in IREX 

A.1 Who should participate 

Providers of iris recognition technologies are invited to participate in IREX. In addition, companies, research 

organizations, or universities that have developed mature prototypes or who research iris segmentation or matching are 

invited to participate. 

The algorithms and 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 API 

specification that NIST has specified in section 7 for this evaluation. 

Anonymous participation will not be permitted. This means that signatories to this Agreement acknowledge that they 

understand that the results (see sections 5.10 and Annex A.7) of the evaluation of the software and/or hardware will be 

published with attribution to their organization(s). 

A.2 How to participate 

Those wishing to participate in IREX testing must do all of the following, on the schedule listed on Page 4. 

― MOD Jun 20, 2008: Indicate via email a non-binding "Intention to Participate" - see the schedule on Page 4. 

― Request an SDK ID from NIST (for use per section 7.2.10). 

― Follow the instructions for cryptographic protection of your SDK here. 

http://iris.nist.gov/irex/NIST_biometrics_crypto.pdf 

― Send a signed and fully completed copy of this entire Annex A, including the IREX Application to Participate form 

below. This must identify, and include signatures from, the Responsible Parties as defined in section A.4 

― Provide an SDK (Software Development Kit) library which complies with the API (Application Programmer Interface) 

specified in this document. 

The IREX Application to Participate shall be sent to: 

IREX Test Liaison In cases where a courier needs a phone 

National Institute of Standards and Technology number please use NIST shipping and 

Information Access Division (894) handling on: 301 - - 975 -- 6296. 

100 Bureau Drive 

A203/Tech225/Stop 8940 

Gaithersburg, MD 20899-8940 

USA 

A.3 NIST activity 

A.3.1 Initiation 

Upon receipt of the signed Annex A form by NIST, the organization shall be classified as a “Participant”. NIST must receive 

the form during the submission period described in schedule on Page 2 of this document. 

A.3.2 Supplier validation 

Registered Participants will be provided with a small Validation Dataset available on the website http://iris.nist.gov/irex. 

Prior to submission of their SDK, the Participant must to verify that their software executes on the validation data, and 

produces correct similarity scores and templates. 

NIST Concept, Evaluation Plan and API Page 30 of 32 
 

 

 

5

10

15

20

25

30

1 

2 

3 

4 

6 

7 

8 

9 

11 

12 

13 

14 

16 

17 

18 

19 

21 

22 

23 

24 

26 

27 

28 

29 

31 

32 

33 

35

34 

36 

37 

38 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

IREX 2008 

A.3.3 Submission of software to NIST 

NIST requires that all software submitted by the participants be signed and encrypted. Signing is done with the 

participant's private key, and encrypting is done with the NIST public key, which is published on the IREX Web site. NIST 

will validate all submitted materials using the participant's public key, and the authenticity of that key will be verified 

using the key fingerprint. This fingerprint must be submitted to NIST by writing it on the signed participation agreement. 

By encrypting the submissions, we ensure privacy; by signing the submission, we ensure authenticity (the software 

actually belongs to the submitter). NIST will not accept into IREX any submission that is not signed and encrypted. NIST 

accepts no responsibility for anything that is transmitted to NIST that is not signed and encrypted. 

The detailed commands for signing and encrypting are given here: http://iris.nist.gov/irex/crypto_protection.pdf 

A.3.4 Acceptance testing 

Software submitted shall implement the IREX API Specification of section 7. 

Upon receipt of the SDK and validation output, NIST will attempt to reproduce the same output by executing the SDK on 

the validation imagery, using a NIST computer. In the event of disagreement in the output, or other difficulties, the 

Participant will be notified. 

A.3.5 Limits of testing 

NIST will use the Participant's SDK software only for purposes related to the testing described in this document. The 

provided software will also be used to resolve any errors identified subsequent to the test or publication of results. NIST 

agrees not to use the Participants software for purposes other than indicated herein, without express permission by the 

Participant. NIST reserves the right to conduct analyses of the output data and measurements beyond those described in 

this document. NIST reserves the right to apply the software to images from sensors not enumerated in this document. 

A.4 Parties 

A.4.1 Responsible Party 

The Responsible Party is an individual with the authority to commit the organization to the terms in this document. 

A.4.2 Point of contact 

The Point of Contact is an individual with detailed knowledge of the system applying for participation. 

The IREX Liaison is the government point of contact for IREX. All correspondence should be directed to irex@nist.gov, 

which will be received by the IREX Liaison and other IREX personnel. 

These correspondences may be posted on the FAQ (Frequently Asked Questions) area of the http://iris.nist.gov/irex at the 

discretion of the IREX Liaison. The identity of those persons or organizations whose correspondences lead to FAQ 

postings will not be made public in the FAQ. 

A.5 Access to IREX validation data 

The IREX Validation Data is supplied to Participants to assist in preparing for IREX. 

The images in the IREX Validation Data are representative of the IREX Test Data only in their format. Image quality, 

collection device and other characteristics are likely to vary between the Validation and Test Datasets. 

A.6 Access to IREX test data 

The IREX Test Datasets are in some cases protected under the Privacy Act (5 U.S.C. 552a), and will be treated as Sensitive 

but Unclassified and/or Law Enforcement Sensitive. 

IREX Participants shall have no access to IREX Test Data, either before, during or after the test. 

NIST Concept, Evaluation Plan and API Page 31 of 32 
 

 

 

5

10

15

20

25

30

1 

2 

3 

4 

6 

7 

8 

9 

11 

12 

13 

14 

16 

17 

18 

19 

21 

22 

23 

24 

26 

27 

28 

29 

31 

32 

33 

34 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

36 

37 

38 

39 

 

 

 

35

IREX 2008 

A.7 Reporting of results 

A.7.1 Reports 

The Government will combine appropriate results into one or more IREX reports. Together these will contain, at a 

minimum, descriptive information concerning IREX, descriptions of each experiment, and aggregate test results. NIST will 

include 

― DET performance metrics as the primary indicators of one-to-one verification accuracy, 

― ISO/IEC 19795-4 interoperability matrices as the primary measures of interoperability, and 

― Image generation, template generation, and matching timing statistics. 

NIST may compute and report other aggregate statistics. 

MOD Jun 20, 2008: NIST intends to publish results in one or more NIST Interagency Reports. The reports will contain 

― contain the names of participants, 

― contain the results of all participants' implementations with attribution to the participants. 

A.7.2 Pre-publication review 

Participants will have an opportunity to review and comment on the reports. Participants’ comments will be either 

incorporated into the main body of the report (if it is decided NIST reported in error) or published as an addendum. 

Comments will be attributed to the participant. 

A.7.3 Citation of the report 

Subsequent to publication of our reports Participants may decide to use the results for their own purposes. Such results 

shall be accompanied by the following phrase: “Results shown from the Iris Exchange Test (IREX) do not constitute 

endorsement of any particular system by the U. S. Government.” Such results shall also be accompanied by the URL of 

the IREX Report on the IREX website, http://iris.nist.gov/irex. 

A.7.4 Rights and ownership of the data 

Any data generated, deduced, measured or otherwise obtained during IREX (excepting the submitted SDK itself), 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. 

A.8 Return of the supplied materials 

NIST will not return any supplied software, documentation, or other material to vendors. 

A.9 Agreement to participate 

With the signing of this form, Participants attest that they will not file any IREX-related claim against IREX Sponsors, 

Supporters, staff, contractors, or agency of the U.S. Government, or otherwise seek compensation for any equipment, 

materials, supplies, information, travel, labor and/or other participant provided services. 

The Government is not bound or obligated to follow any recommendations that may be submitted by the Participant. The 

United States Government, or any individual agency, is not bound, nor is it obligated, in any way to give any special 

consideration to IREX Participants on future contracts, grants or other activities. 

With the signing of this form, Participants realize that any test details and/or modifications that are provided in the IREX 

website supersede the information on this form. 

With the signing of this form, Participants realize that they cannot withdraw from the IREX without their participation and 

withdrawal being documented in the IREX Final Report. 

NIST Concept, Evaluation Plan and API Page 32 of 32 
 

 

1 

IREX 2008 

This form shall be completed by all suppliers electing to participate in the IREX evaluation. 

NIST assigned identifier for the supplied SDK. 

Responsible Party for supplier of iris segmentation, encoding and/or matching technologies. 

Company / Organization Name 

Title First Name MI Last Name Suffix 

Street Address 

City State Zip Country 

Phone Fax Email 

Technical point of contact Phone Email 

Participant's public-key fingerprint 

(enter here) 

NIST's public-key fingerprint 846E 7008 996A E912 974C F8D7 1C7A 0F22 856B 9B28 

2 With my signature, I agree that this document is a sufficient description of the test to be conducted. 

3 With my signature, I hereby request consideration as a Participant in the Iris Interoperability Exchange Test II (IREX), and I 

4 am authorizing my company or organization to participate in IREX according to the rules and limitations listed in this 

5 document. 

6 With my signature, I also state that I have the authority to accept the terms stated in this document 

7 

8 

9 ________________________________________________________________________________ 

10 SIGNATURE OF SOFTWARE SUPPLIER RESPONSIBLE PARTY DATE 

11 

NIST Concept, Evaluation Plan and API Page 33 of 32