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 

Patrick Grother 

NIST 

November 19, 2007 

IREX 2008 

IREX 

An Evaluation-based Program for the Development of Exchangeable Iris Imagery 

and Support for Compact Interoperable ISO/IEC 19794-6 Records 

Iris Exchange (IREX) Evaluation 2008 

Concept, Evaluation Plan and API 

NIST Concept, Evaluation Plan and API Page 1 of 31 
1 

2 

 

 

 

 

 

 

 

 

 

 

 

5 

6 

7 

8 

 

 

9 

10 

 

 

 

 

 

 

IREX 2008 

Commenting on this Draft 

Nov 17, 2007: NIST welcomes comments on this draft. These should be submitted to patrick.grother@nist.gov by 

December 8, 2007. Proprietary information should not be sent to NIST, and any commentary marked with phrases 

such as "commercial in confidence" will be ignored. 

As a first draft, the entire content of this document is open. Interested parties should feel free to address everything 

from motivation and scope, through the test structure, the data structures and the API, to typographical errors. 

NIST directs readers attention to the questions formatted in red in the body of the text. 

We anticipate producing at least one more draft before a definitive evaluation plan can be finalized. Given sufficient 

demand NIST would hold a workshop to discuss this project. 

3 

4 NIST Request I 

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 this effort. A number of issues would need to be addressed before 

such collaboration could proceed: We'd be happy to discuss these as soon as practicable. 

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

NIST Request II 

To help NIST plan, we would be very grateful if likely participants could send us an informal nonbinding indication of such. 

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

Project History 

Nov 19, 2007 (18:10 EST) 

― Fixed erroneous byte lengths of ISO records, Table 7+8. 

Nov 19, 2007 (14:00 EST). 

― Typos and cut-and-paste errors fixed. 

Nov 18, 2007 

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

of industry and academia to segment irides, prepare compact rectilinear and polar standard records, and 

accurately match compressed images in a cross-vendor interoperable environment. 

― Posting of this initial evaluation plan, for public comment. 

― Establishment of IREX homepage: http://iris.nist.gov/irex 

Provisional Timeline 

March 17, 2008 Completion of final validated operable SDKs to NIST 

March 1, 2008 Delivery of beta SDKs to NIST, commencement of validation process 

January 23, 2008 Conclusion of second comment period 

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

January 15, 2008 Release of second draft evaluation plan, for comment. This date is contingent on 

the breadth, depth, and quantity of comments received. 

NIST Concept, Evaluation Plan and API Page 2 of 31 
 

 

 

 

1 

IREX 2008 

December 8, 2007 Conclusion of Initial comment period 

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

NIST Concept, Evaluation Plan and API Page 3 of 31 
 

 

 

5

10

15

20

25

30

35

40

45

1 

2 1

3 2

4 

6 3

7 4

8 5

9 6

11 

12 

13 

14 

16 

17 

18 

19 

21 

22 

23 

24 

7

26 

27 

28 

29 

31 8

32 

33 

34 

36 9

37 1

38 

39 

41 

42 

43 

44 

46 

47 

50

48 

49 

51 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

IREX 2008 

Table of Contents 

. IREX Overview .................................................................................................................................................................. 6 

. Motivation and background............................................................................................................................................. 6 

2.1. Toward compact forms........................................................................................................................................... 6 

2.2. Support for the ISO standard.................................................................................................................................. 7 

. Scope ................................................................................................................................................................................ 7 

. Normative References...................................................................................................................................................... 8 

. Abbreviations ................................................................................................................................................................... 8 

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

6.1. Fundamental concept of the test ......................................................................................................................... 11 

6.2. Interoperability space........................................................................................................................................... 11 

6.3. Offline evaluation using archival imagery............................................................................................................. 11 

6.4. Uniform software interface .................................................................................................................................. 11 

6.5. Audience and options for participation................................................................................................................ 11 

6.6. Segmentation on uncompressed data.................................................................................................................. 12 

6.7. Compression ......................................................................................................................................................... 12 

6.8. Feature extraction on compressed data............................................................................................................... 12 

6.9. Compression metrics ............................................................................................................................................ 13 

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

6.11. Repetition of the ICE 06 evaluation ...................................................................................................................... 13 

6.12. Verification performance...................................................................................................................................... 13 

6.13. Phased testing....................................................................................................................................................... 13 

6.14. Open-source code for ISO/IEC 19794-6................................................................................................................ 14 

6.15. Standards-based evaluation ................................................................................................................................. 14 

. Data structures............................................................................................................................................................... 14 

7.1. Overview............................................................................................................................................................... 14 

7.2. Identifying the records of the standard................................................................................................................ 14 

7.3. Rectilinear image record structure ....................................................................................................................... 15 

7.4. Standard polar image record structure ................................................................................................................ 16 

7.5. Unsegmented Polar image record structure ........................................................................................................ 16 

. PC-based API specification ............................................................................................................................................. 17 

8.1. Overview............................................................................................................................................................... 17 

8.2. Testing interface ................................................................................................................................................... 17 

8.3. Software and Documentation............................................................................................................................... 22 

8.4. Runtime behavior ................................................................................................................................................. 23 

. NIST conversion of Rectilinear to Polar Coordinates...................................................................................................... 24 

0. References................................................................................................................................................................. 24 

Annex A Error Codes and Handling ........................................................................................................................................ 26 

Annex B Application to participate in IREX............................................................................................................................. 27 

B.1 Who should participate ........................................................................................................................................ 27 

B.2 How to participate ................................................................................................................................................ 27 

10.1. Submission............................................................................................................................................................ 27 

B.3 NIST activity .......................................................................................................................................................... 27 

B.4 Parties................................................................................................................................................................... 28 

B.5 Access to IREX validation data .............................................................................................................................. 28 

B.6 Access to IREX test data........................................................................................................................................ 29 

B.7 Reporting of results .............................................................................................................................................. 29 

B.8 Return of the supplied materials .......................................................................................................................... 29 

B.9 Agreement to participate ..................................................................................................................................... 30 

Annex C NIST mailing address ................................................................................................................................................ 31 

NIST Concept, Evaluation Plan and API Page 4 of 31 
 

 

 

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 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

30

29 

31 

32 

33 

34 

 

 

 

IREX 2008 

List of Figures 

Figure 1 - Steps for verification of rectilinear images ............................................................................................................ 10 

Figure 2 - Steps for verification of standard polar images ..................................................................................................... 10 

Figure 3 - Steps for verification of unsegmented polar images ............................................................................................. 10 

List of Tables 

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

Table 2 – Abbreviations............................................................................................................................................................ 8 

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

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

Table 5 – Identifying variants via CBEFF format type............................................................................................................. 14 

Table 6 – Identifying variants using Version Number ............................................................................................................ 14 

Table 7 – Structure of the ISO/IEC 19794-6:2005 standard ................................................................................................... 15 

Table 8 – Structure for the proposed unsegmented polar format......................................................................................... 16 

Table 9 – Sensor identifiers .................................................................................................................................................... 17 

Table 10 – Preparation of standard rectilinear records ......................................................................................................... 17 

Table 11 – IREX API preparation of standard rectilinear record ............................................................................................ 17 

Table 12 – Preparation of standard polar records ................................................................................................................. 18 

Table 13 – IREX API for creation of polar records .................................................................................................................. 18 

Table 14 – Preparation of standard no-inner-boundary polar records.................................................................................. 19 

Table 15 – IREX API for creation of no-inner-boundary polar records................................................................................... 19 

Table 16 – Preparation of unsegmented polar records ......................................................................................................... 20 

Table 17 – IREX API for creation of unsegmented polar records ........................................................................................... 20 

Table 18 – IREX API template creation................................................................................................................................... 21 

Table 19 – IREX API template matching ................................................................................................................................. 21 

Table 20 – IREX API get_pids function.................................................................................................................................... 22 

Table 21 – IREX API return codes ........................................................................................................................................... 26 

Acknowledgements 

The authors are grateful to the following contributors, and other anonymous individuals, without whose input this 

document would not have been concluded. 

A 

B ... 

NIST Concept, Evaluation Plan and API Page 5 of 31 
 

 

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 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

IREX 2008 

1. IREX 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 work is primarily conducted in support of the ISO/IEC 

19794-6 standard, now under revision. It secondarily supports the recently completed ANSI/NIST ITL 1-2007 Type 17 

standard, as derived from the ISO/IEC 19794-6:2005 parent [STD05], and future revision thereof. 

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 compressed ISO/IEC 19794-6:2005 

rectilinear and polar formatted records, and of a variant proposed for the forthcoming revision of ISO/IEC 

19794-6. 

ICE 06 Coordinated by Jonathon Phillips at NIST, 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 at NIST, 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. Toward compact forms 

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

image format suitable for large scale identity management applications. 

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 

data element suitable for storage on an ISO/IEC 7816 crypto-token1

, and for efficient transmission across a network. Such 

specifications are 

― segmentation parameters (e.g. inner and outer radii multipliers, see section X), 

― compression settings (e.g. bits per pixel, see section Y), and 

― geometric representation (e.g. polar or rectilinear, see section Z). 

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 rather conservative compared to the order of 

magnitude larger compression ratios cited in recent studies. 

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 [MOC]. 

NIST Concept, Evaluation Plan and API Page 6 of 31 
 

 

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 

37 

38 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

IREX 2008 

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 unofficial augmentation of the ISO development process. This 

contrasts with the default practice of the responsible standards bodies, SC 37 Working Group 3 and M1.3, which is to not 

embed conformance, performance and interoperability tests as part of 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. 

The ISO standard was adopted by at least the Registered Traveler (RT) program in the United States which sought to use 

compact iris imagery on an identity credential. This was achieved by specifying a no-inner-boundary polar format2 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 the revised text of the standard [N2226] identifies which text is to be removed. 

A UK contribution [N2124] also advocates 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 has been opposed by US [DHS,NIST,LG] with observations that the polar format can 

be interoperable (viz. RT), that removal would undermine standards adoption, and that some testing is needed. 

While NIST understands the assertions that the interoperability of the polar format is innately fragile, we note 

― the polar format was developed and approved by SC 37 and M1, and, 

― neither cross-vendor interoperability, nor segmentation consistency, have ever been reported3

. 

This test is therefore intended to assess the interoperability of the various polar formats, and independently measure the 

dependence of verification error rates on compression. 

NIST supports the current U.S. position to not remove the polar formats from the standard. NIST will support removal of 

one or more of those formats if 

― quantitative interoperability targets are met with compressed rectilinear formats, and 

― quantitative interoperability targets are not met when data formatted according to the polar formats in ISO/IEC 

19794-6 are matched. 

3. Scope 

IREX 08 is intended to support ISO/IEC 19794-6 by requiring participants to produce conformant instances of the 

standard, and by contributing quantitative experimental measurements to SC 37 Working Group 3 for the development 

of the ISO/IEC 19794-6 revision project. 

Specifically the test aims to 

― quantify the performance and interoperability of 

− rectilinear images, 

− no-inner boundary polar images, 

− fully segmented polar images, and 

− unsegmented polar images 

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

2 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. 

3 The International Biometric Group's ITIRT study [ITIRT] evaluated sensor interoperability with a common matching subsystem. The 

three sensors yielded either uncompressed or compressed JPEG rectilinear images. 

NIST Concept, Evaluation Plan and API Page 7 of 31 
 

 

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 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

IREX 2008 

― quantify the performance and interoperability of iris segmentation algorithms 

― time the various operations, 

― formulate content and comments toward possible revision of the relevant standards, 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 false non-match and false match error rates for various compression levels and operating 

thresholds, 

― rectilinear to polar conversion times, 

― feature extraction times, and 

― matching times. 

In so doing, the IREX evaluation requires 

― conversion of raw raster images into ISO/IEC 19794-6 rectilinear images, and 

― conversion of ISO/IEC 19794-6 rectilinear images into ISO/IEC 19794-6 polar images. 

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

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

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

― conformance to INCITS 379:2004, and 

― identification performance. 

4. 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. 

5. 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 

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 

NIST Concept, Evaluation Plan and API Page 8 of 31 
1 

2 3 

IREX 2008 

Table 3 – IREX 08 image variants 

Rectilinear Polar No-inner-boundary Polar Unsegm

Standards compliance 

ISO/IEC 19794-6 rectilinear format Clause 6.3.1 

ISO/IEC 19794-6:2005 polar format, clause 6.3.2 

ISO/IEC 19794-6 polar format, clause 6.3.2.3 

Propose6:200X, 

Notes Essentially unprocessed. Standard does not require circular 

boundaries, but if they are circular there 

are tight constraints on placement. 

Outer boundary must be circular. Detection thereof is about as complex as a rectangular bounding box. 

Inclusion reconstrplaced a

Region of Interest 

Remarks about the example image 

An image from the ICE 05 corpus. Both circles closely approximate the 

boundaries, in this case not very well because the iris is oblate. Iris and pupil centres are clearly distinct. 

Yellow circle is larger than the standard prescribes. i.e. "over-segmentation". 

The innenot centthat this 

Encoding Raster, left top origin and row major. As in ISO/IEC 19794-6:2005 6.3.2.7 and 

figure 1 therein 

As in 6.3.2.7 and figure 1. This is clarified in Figure 1b of the draft of the revised standard [N2226]. 

As in ISOfigure 1 

Pros Simplicity, interoperability Compact No requirement to find inner boundary. Rectiline

because 

Cons Size, the largest of the formats here. Questionable interoperability due to 

segmentation in consistencies [N2124]. 

Elevated size due to inclusion of pupil Requires 

Table 8. 

API See section 8.2.3 See section 8.2.4 See section 8.2.5 See sect

Q Can the use of three polar formats be avoided, e.g. by consolidation? 

4 5 

NIST Concept, Evaluation Plan and API Page 9 of 31 
IREX 2008 

Raw input image 

Current 19794-6 rectilinear image record 

SDK rectilinear formatting function 

SDK feature extractor 

SDK 

feature 

extractor 

Current19794-6 

rectilinear image 

record 

SDK r

fo

Proprietary Template 

Proprietary 

Template 

Distance (smaller is 

more genuine) 

Matcher 

Enrollment phase 

Verification phase 

Compressor DeCompressor 

1 2 3 4 

Figure 1 - Steps for verification of rectilinear images 

SDK feature extractor 

Raw input image 

Proposed 19794-6 segmented polar image record 

SDK stdandard segmented polar formatting function 

SDK 

feature 

extractor 

Current 19794-6 

rectilinear image 

record 

SDK 

f

Proprietary Template 

Proprietary 

Template 

Distance (smaller is 

more genuine) 

Matcher 

Enrollment phase Verification phase 

Compressor DeCompressor 

Figure 2 - Steps for verification of standard polar images 

SDK feature extractor 

Raw input image 

Proposed 19794-6 unsegmented polar image record 

SDK unsegmented formatting function 

SDK 

feature 

extractor 

Current 19794-6 

rectilinear image 

record 

SDK 

f

Proprietary Template 

Proprietary 

Template 

Distance (smaller is 

more genuine) 

Matcher 

Enrollment phase Verification phase 

SDK internal inverse polar transform 

Compressor DeCompressor 

Figure 3 - Steps for verification of unsegmented polar images 

NIST Concept, Evaluation Plan and API Page 10 of 31 

5 
 

 

 

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 

35

36 

37 

38 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

IREX 2008 

6. Aspects of the test 

6.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 prepare the four encodings of Table 3, specifically to convert 

― In stage 1, archival rectilinear raster images to 

− Rectilinear images conformant to ISO/IEC 19794-6:2005, 

− Two polar instances conformant to ISO/IEC 19794-6:2005, and 

− Unsegmented polar images conformant to the specifications herein. 

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

template. 

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

measure. 

This procedural decomposition is depicted in Figure 1, Figure 2 and Figure 3. The left side of those diagrams shows the 

enrollment process, and the right side shows the verification phase. 

6.2. Interoperability space 

The targeted interoperability scenario is 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. This is reflected in 

Figure 1, Figure 2 and Figure 3 which show the verification sample as always being a rectilinear image. 

NIST will mimic this operation in an offline evaluation by comparing enrollment instances in the various compressed 

formats against unprocessed and uncompressed verification images. This differs, for example, with [CAM07] in which 

both images were compressed before any segmentation and feature extraction. 

6.3. Offline evaluation using archival imagery 

NIST intends to execute the test in an entirely offline fashion and to use images from the sequestered ICE 06 corpus of LG 

2200 images, and a larger corpus collected using the LG 3000. NIST is likely to extend this data arbitrarily to include other 

sources. IREX 2008 is unlikely to embed a dedicated scenario test or data collection. 

NIST will identify the specific cameras in all published reports. 

6.4. Uniform software interface 

As in many prior NIST tests, we intend to evaluate algorithms by requiring them to be implemented behind a simple "C" 

API. Note that this is a departure from the ICE protocol. 

6.5. 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 B. 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 

NIST Concept, Evaluation Plan and API Page 11 of 31 
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

10 

1 

2 

3 

4 

5 

6 

7 

8 

9 

 

 

 

 

 

 

 

11 

12 

13 

14 

15 

16 

17 

18 

19 

20 

21 

22 

23 

IREX 2008 

Class of 

Participation 

Annex B 

Participation 

agreement 

Ability to 

convert a raw 

raster into a 

conformant 

instance of the 

ISO/IEC 19794-

6:2005 

rectilinear 

image format 

Ability to 

convert a 

ISO/IEC 19794-

6:2005 

rectilinear 

image into a 

outerboundary-only 

ISO/IEC 19794-

6:2005 polar 

image 

Ability to 

convert a 

ISO/IEC 19794-

6:2005 

rectilinear 

image into a full 

ISO/IEC 19794-

6:2005 polar 

image 

Ability to 

convert a 

rectilinear 

image into an 

unsegmented 

polar image 

[UNSEG] 

Ability to 

extract features 

from and match 

conformant 

instances of the 

ISO/IEC 19794-

6 rectilinear 

format. 

Ability to 

extract features 

from and match 

conformance 

instances of all 

rectilinear and 

polar formats. 

Class A + + 

Class B + + + 

Class C + + + + + 

Class D + + + 

Class E + + + + + + + 

The inclusion of these classes is motivated as follows: 

― Class A exists to allow organizations to demonstrate the capability to produce conformant records (e.g. for a card 

issuance system) 

― Class B exists to allow organizations to demonstrate the capability to find the bounding circle / bounding box in an 

image, i.e. to do primary segmentation. 

― Class C exists to allow organizations to demonstrate the capability to generate all variants of the ISO/IEC 19794-6 

standard. 

― Class D exists to allow organizations to demonstrate capability to match only rectilinear images. 

― Class E exists to allow organizations to demonstrate segmentation and matching capability on all images. 

Q These classes of participation are likely to be revised in subsequent drafts. How? 

Q Should NIST allow a supplier to submit entirely separate SDK's, one for class X and one for class Y? 

6.6. Segmentation on uncompressed data 

All polar segmentation steps will be performed on uncompressed 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. 

6.7. Decompressed data passed to the SDK 

NIST will not pass JPEG or JPEG 2000 encoded data to the SDK functions. Instead, we will apply compression and then 

decompress the data before passing the record to the function. This avoids the need for the SDK to call decompression 

routines. 

Q Does the SDK need any information about the compressed imagery? Would, for example, a 

segmentation algorithm vary its function on, say, the basis of input file size? 

6.8. Feature extraction on compressed data 

Template generation will usually be performed on previously compressed data. This mimics the operational scenario in 

which compressed imagery is exchanged (on a smartcard, or over a network) and features are extracted by the recipient. 

Compression ratios from 1:1 (uncompressed) to perhaps 1:200 will be applied. 

NIST Concept, Evaluation Plan and API Page 12 of 31 
 

 

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 

6.9. 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. 

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 measure and report compression 

times. 

6.10. 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 currently 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. 

Q Does this provision favor some (e.g. experienced) vendors, and should therefore all sensors be 

identified simply as "unknown"? 

6.11. Repetition of the ICE 06 evaluation 

4 IREX 2008 may include, as one slice of its scope, a repetition of the ICE 06 trial . This arises because matching of 

rectilinear ICE 06 images, compressed at an initial ratio of 1:1, is logically an approximate repetition of the ICE 06 trial. 

This is approximate because the SDK protocol here differs from that used in ICE. 

6.12. Verification performance 

The test will embed pure 1:1 template comparisons. It will not enroll a population and thus will not support 

― verification systems that run in an identification mode, 

― 5 cohort normalization techniques , and 

― 1:N testing, which is not needed to study the format and compression effects targeted by this study. 

6.13. 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 any interim disclosure of results to the supplier, and without any resubmission of SDKs to NIST. We will 

nevertheless communicate aberrant behavior to suppliers - for example, if generated records are non-conformant to the 

ISO standard, or if the SDK is not conformant to our API. 

Q Should NIST adopt a two-phase approach? This would support an improvement loop: interim 

feedback from NIST – supplier development – SDK resubmission. 

33 

4 The ICE homepage is http://iris.nist.gov/ice 5 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. 

NIST Concept, Evaluation Plan and API Page 13 of 31 
 

 

1 

2 

3 

4 

5 

6 

7 

8 

9 

10 

11 

12 

13 

14 

15 

16 

17 

18 

19 

20 

21 

22 

23 

 

Table 6 – Identifying variants using Version Number 

 

All encodings in ISO/IEC 19794-6:2005 'nnn' The 2005 standard was published with the undefined 

entry 'nnn'. This differs from all other parts 19794-x 

which stated definitive hex values. 

For IREX 08, in order to differentiate the various forms, NIST will deviate from the standard and require the Version 

Number field to be populated and respected as per Table 6. 

24 

25 

26 

27 

 

 

 

IREX 2008 

Q Should interim results be provided to the supplier? Or, instead, should an report be written with 

results that does not identify vendors? 

6.14. Open-source code for ISO/IEC 19794-6 6 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 

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

6.15. Standards-based evaluation 

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. 

Q Should NIST release a reference rectilinear to polar interpolation routine? 

7. Data structures 

7.1. Overview

Much of IREX 08 will involve the generation or use of the data structures defined in the following two subsections. The 

first is the ISO/IEC 19794-6:2005 record. The second is the proposed unsegmented polar augmentation of that record. In 

both cases, the values in certain fields have been constrained to specific values. For example, the number of images is 

always 1, and all image data is in uncompressed form. 

7.2. Identifying the records of the standard 

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

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

For IREX 08, CBEFF headers shall be absent. 

In ISO/IEC 19794-6:2005, the only means of differentiating rectilinear records from polar records is via the CBEFF fromat 

type, as shown in Table 5. However, CBEFF encapsulation is now optional in the draft revision [N2226] and there is no 

normative mechanism for determining the encoding. This presents a bug worthy of WG3 attention. 

Table 5 – Identifying variants via CBEFF format type 

Geometric Encoding CBEFF_BDB_format_type 

Rectilinear 0x0009 

Polar 0x000B 

6 The BIOMDI repository currently includes code for handling standardized iris, face, finger and minutiae records. Instructions for access 

are described here: http://www.itl.nist.gov/iad/894.03/nigos/biomdi.html 

NIST Concept, Evaluation Plan and API Page 14 of 31 

Geometric Encoding Version Number 
 

 

 

 

 

 

 

 

P

1 

2 

3 

4 

5 

6 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

IREX 2008 

All encodings in ISO/IEC 19794-6:200X, X > 7 0x30333000 '030\0' - the draft revision [N2226] value. 

Rectilinear 0x30313000 '010\0' 

No-inner-boundary Polar 0x30313100 '011\0' 

Full Polar 0x30313200 '012\0' 

roposed unsegmented Polar 0x30313300 '013\0' 

7.3. Rectilinear image record structure 

Rectilinear image generators shall produce records conformant to Table 7. This is identically the structure of the ISO/IEC 

19794-6:2005 standard. 

Table 7 – Structure of the ISO/IEC 19794-6:2005 standard 

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

Iris Record Header (Table 2 of ISO/IEC 19794-6:2005) 

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

2. Version Number 4 B 0x30313000 

0x30313100 

0x30313200 

See Table 6 

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

4. Capture Device ID 2 B 0 Value will be provided to SDK 

5. Number of eyes imaged 1 B 1 

6. Record header length 2 B 45 

7. Iris image 

properties 

Horz. orientation 2 b ORIENTATION_BASE 

8. Vert. orientation 2 b ORIENTATION_BASE 

9. Scan type 2 b SCAN_TYPE_PROGRESSIVE, 

SCAN_TYPE_INTERLACE_FRAME 

Rectilinear format only 

10. Occlusions 1 b 0 Polar format only 

11. Occlusion filling 1 b 0 Polar format only 

12. Boundary extraction 1 b 0 Polar format only 

13. Iris diameter (rect) 2 B > 0 Rectilinear format only 

14. Image format 2 B IMAGEFORMAT_MONO_RAW IREX SDKs are neither permitted nor required to 

compress or decompress image data. Thus this 

field shall not be IMAGEFORMAT_MONO_JPEG, 

or IMAGEFORMAT_MONO_JPEG2000. 

15. Raw image width 2 B > 0 

16. Raw image height 2 B > 0 

17. Intensity depth 1 B 8 

18. Image transformation (polar only) 1 B 1 TRANS_STD = 1 i.e. linear radial interpolation per 

[STD05, 6.5.4]. 

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

Iris Biometric Subtype Header (Table 3 of ISO/IEC 19794-6:2005) 

20. Eye 1 B EYE_RIGHT, EYE_LEFT 

21. Number of iris images of this eye 2 B 1 

Iris Image Header (Table 4 of ISO/IEC 19794-6:2005) 

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

23. Quality 1 B 

24. Rotation angle of eye 2 B ROT_ANGLE_UNDEF 

> 0 

For rectilinear 

For polar unless next line is set non-zero 

25. Rotation uncertainty 2 B ROT_UNCERTAIN_UNDEF 

> 0 

For rectilinear and polar when rotation is not 

estimated. 

For polar when rotation is estimated. 

NIST Concept, Evaluation Plan and API Page 15 of 31 
 

 

 

 

1 

2 

3 

4 

5 

6 

7 

8 

9 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

IREX 2008 

26. Image length 4 B LEN 

27. Image data LEN 

7.4. Standard polar image record structure 

Polar image generators shall produce records conformant to Table 7. This is identically the structure of the ISO/IEC 

19794-6:2005 standard. Note that the standard treats rotation estimates and uncertainties differently for rectilinear and 

polar instances, and thus appropriate values shall be assigned. This specification does not limit implementations to 

circular models. 

7.5. Unsegmented Polar image record structure 

The following structure is advanced as an implementation of the proposed unsegmented polar addition to the ISO 

standard [UNSEG]. The fields in yellow do not appear in the existing 2005 standard. 

Q The [UNSEG] proposal suggests that non-circular boundary information should also be encoded in 

the revised standard. Should NIST include fields for the storage of such? If so, how? 

10 Table 8 – Structure for the proposed unsegmented polar format 

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

Iris Record Header (Table 2 of ISO/IEC 19794-6:2005) 

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

29. Version Number 4 B 0x30313300 i.e. ASCII "013\0". This value is non-standard, and 

instituted by NIST to differentiate it from the 

properly standardized record in Table 7. 

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

31. Capture Device ID 2 B 0 Value will be provided to SDK 

32. Number of eyes imaged 1 B 1 

33. Record header length 2 B 45 

34. Iris image 

properties 

Horz. Orientation 2 b ORIENTATION_BASE 

35. Vert. orientation 2 b ORIENTATION_BASE 

36. Scan type 2 b SCAN_TYPE_PROGRESSIVE, 

SCAN_TYPE_INTERLACE_FRAME 

Rectilinear format only 

37. Occlusions 1 b Polar format only 

38. Occlusion filling 1 b Polar format only 

39. Boundary extraction 1 b Polar format only 

40. Iris diameter (rect) 2 B Rectilinear format only 

41. Image format 2 B IMAGEFORMAT_MONO_RAW IREX SDKs are neither permitted nor required to 

compress or decompress image data. Thus this 

field shall not be IMAGEFORMAT_MONO_JPEG, 

or IMAGEFORMAT_MONO_JPEG2000. 

42. Raw image width 2 B > 0 

43. Raw image height 2 B > 0 

44. Intensity depth 1 B 8 

45. Image transformation (polar only) 1 B 1 TRANS_STD = 1 i.e. linear radial interpolation per 

[STD05, 6.5.4]. 

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

Iris Biometric Subtype Header (Table 3 of ISO/IEC 19794-6:2005) 

47. Eye 1 B EYE_RIGHT, EYE_LEFT 

48. Number of iris images of this eye 2 B 1 

Iris Image Header (Table 4 of ISO/IEC 19794-6:2005) 

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

50. Quality 1 B 

51. Rotation angle of eye 2 B ROT_ANGLE_UNDEF Values will not be provided to SDK 

NIST Concept, Evaluation Plan and API Page 16 of 31 
 

 

 

 

 

 

 

 

 

 

 

 

 

 

1 

2 

3 

4 

5 

6 

7 

8 

9 

10 

 

 

 

11 

12 

13 

14 

15 

16 

17 

18 

19 

 

 

 

 

 

 

 

 

 

 

IREX 2008 

52. Rotation uncertainty 2 B ROT_UNCERTAIN_UNDEF 

53. Inner circle X coordinate 2 B 0 ≤ x < W Coordinate system is zero oriented with (0,0) at 

the top left corner. 

The inner and outer circle centers are not 

necessarily the same. 

54. Inner circle Y coordinate 2 B 0 ≤ y < H 

55. Inner circle radius 2 B 0 ≤ r 

56. Outer circle X coordinate 2 B 0 ≤ x < W 

57. Outer circle Y coordinate 2 B 0 ≤ y < H 

58. Outer circle radius 2 B 0 ≤ r 

59. Image length 4 B LEN See Line 60 

60. Unsegmented polar-transformed image 

data 

LEN 

8. PC-based API specification 

8.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. 

8.2. Testing interface 

8.2.1. Requirement 

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

8.2.2. Sensor identifiers 

The following sensors will be identified to the SDK using the two byte unsigned integer values in Table 9. 

Table 9 – Sensor identifiers 

# Sensor Manufacturer and Model Identifier 

1 LG 2200 0x2A16 

2 LG 3000 0x2A1E 

3 Unknown 0x0000 

Presence on this table indicates NIST's intention to use images captured by these devices. NIST may add to this table in 

due course. Also, please see NIST's call for images on Page 2. 

8.2.3. Conversion of raw imagery to standard rectilinear image 

To support the standard all submissions to IREX 08 shall implement a function to execute the packaging operation of 

Table 10. While this action is merely syntactic, prior interoperability tests conducted by NIST have revealed a not 

uncommon inability to reliably instantiate conformant records. 

The output instances are used as inputs to subsequent functions (polar processing, or feature extraction). NIST will apply 

compression-decompression to the image data contained in these records. 

Table 10 – Preparation of standard rectilinear records 

Input Action Output 

Raw raster, dimensions, and 

parameters needed to instantiate the 

standardized record 

Package the input 

into a conformant 

record. 

Conformant ISO/IEC 19794-6 

rectilinear record. These records will 

be checked for conformance by NIST. 

20 

21 

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

Table 11 – IREX API preparation of standard rectilinear record 

Prototype INT32 convert_raster_to_rectilinear( 

NIST Concept, Evaluation Plan and API Page 17 of 31 
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

1 

2 

3 

4 

5 

 

 

 

 

 

 

 

 

 

 

6 

7 

 

 

 

 

 

 

IREX 2008 

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 image_format, 

const BYTE intensity_depth, 

const UINT16 nist_encoded_device_id, 

BYTE *quality 

BYTE * ISO_19794_6_rectlinear_image); 

Description This function takes a raw input image and outputs the corresponding ISO/IEC 19794-6 rectilinear record. This function 

executes only a syntactic repackaging of the input data. It shall not alter the image data. 

Input uncompressed_raster_data The uncompressed raw image used for template creation. 

Parameters 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. 

image_format NIST anticipates using only unprocessed uncompressed 8 bit grayscale data, so the 

image format will be 0x0002, and the intensity depth will be 8, both per [STD05]. intensity_depth 

nist_encoded_device_id A two byte unsigned integer value from Table 9 

Output 

Parameters 

Quality A [0,100] quality value representing 

ISO_19794_6_rectlinear_image The output rectilinear image, per Table 7 

Return Value This function returns zero on success or a documented non-zero error code otherwise. 

8.2.4. Conversion of rectilinear to standard polar 

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

operation of Table 12. In addition to the required polar instance output, the function shall return center coordinates. 

This supports measurements of the pixel-level displacement between segmentation algorithms. 

Table 12 – Preparation of standard polar records 

Input Action Output 

Conformant ISO/IEC 19794-6 

rectilinear record, and desired 

circumferential and radial numbers 

of samples. 

Find suitable inner and 

outer circles. Execute 

forward polar 

transform. 

Segmented polar record, per Table 7. 

Coordinates of the centers of the inner and 

outer regions. 

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

Table 13 – IREX API for creation of polar records 

Prototype INT32 convert_rectilinear_to_segmented_polar( 

const BYTE *ISO_19794_6_rectlinear_image, 

const UNIT16 num_samples_radially, 

const UINT16 num_samples_circumferentially, 

UINT16 *x_iris_center, 

UINT16 *y_iris_center, 

UINT16 *x_pupil_center, 

UINT16 *y_pupil_center, 

BYTE *ISO_19794_6_seg_polar_image); 

Description This function takes a conformant ISO/IEC 19794-6 rectilinear image and outputs the corresponding segmented polar 

image as a conformant ISO/IEC 19794-6 instance. The coordinates of the pupil and iris centers are returned also. 

NIST Concept, Evaluation Plan and API Page 18 of 31 
 

 

 

 

 

 

 

 

 

 

 

 

 

 

4 

5 

6 

7 

8 

9 

10 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

11 

12 

 

 

 

 

 

 

 

 

3 

IREX 2008 

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 ISO_19794_6_rectlinear_image The uncompressed raw image used for template creation. 

Parameters num_samples_radially The requested number from inner to outer boundary 

num_samples_circumferentially The requested number of samples around the limbus 

Output x_iris_center Horizontal and vertical locations of the iris center. 

Parameters y_iris_center 

x_pupil_center Horizontal and vertical locations of the pupil center. 

y_pupil_center 

ISO_19794_6_seg_polar_image The output polar image, per Table 7. 

Return Value This function returns zero on success or a documented non-zero error code otherwise. 

1 An implementation may elect not to process the input image, or it may fail involuntarily. If this occurs, a documented 

2 non-zero error code will be returned and NIST will record this as a failure to segment. 

Q Should NIST recommend or require that the grey level data is not processed? For example, eyelids are not 

removed, frequency domain filtering is not performed, or histogram equalization is not applied? 

Q Should this function include an input over-segmentation parameter? The values for such a parameter would take 

on a limited number of values, say 100 for exact detection of the limbus, and 115 for a larger region [LG]. 

8.2.5. Conversion of rectilinear to no-inner-boundary standard polar 

To assess viability of the standard's no-inner-boundary polar format, participating submissions to IREX 08 shall execute 

the conversion operation of Table 14. In addition to the required polar instance output, the function shall return center 

coordinates. This supports 

― measurement of the pixel-level displacement between segmentation algorithms, and 

― generation of a square bounding boxes to be used for generation and testing of cropped rectilinear iris records. 

Table 14 – Preparation of standard no-inner-boundary polar records 

Input Action Output 

Conformant ISO/IEC 19794-6 

rectilinear record, and desired 

circumferential and radial numbers 

of samples. 

Find suitable inner and 

outer circles. Execute 

forward polar 

transform. 

Standard no-inner-boundary polar record, 

per Table 7. 

Coordinates of the centers of the inner and 

outer regions. 

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

Table 15 – IREX API for creation of no-inner-boundary polar records 

Prototype INT32 convert_rectilinear_to_no_inner_boundary_polar( 

const BYTE *ISO_19794_6_rectlinear_image, 

const UNIT16 num_samples_radially, 

const UINT16 num_samples_circumferentially, 

UINT16 *x_iris_center, 

UINT16 *y_iris_center, 

UINT16 *x_pupil_center, 

UINT16 *y_pupil_center, 

BYTE *ISO_19794_6_seg_polar_image); 

Description This function takes a conformant ISO/IEC 19794-6 rectilinear image and outputs the corresponding no-inner-boundary 

segmented polar image as a conformant ISO/IEC 19794-6 instance. The coordinates of the pupil and iris centers are 

returned also. 

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

NIST Concept, Evaluation Plan and API Page 19 of 31 
 

 

 

 

 

 

 

 

 

 

 

 

 

1 

2 

4 

5 

6 

7 

8 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

3 

IREX 2008 

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 ISO_19794_6_rectlinear_image The uncompressed raw image used for template creation. 

Parameters num_samples_radially The requested number from inner to outer boundary 

num_samples_circumferentially The requested number of samples around the limbus 

Output x_iris_center Horizontal and vertical locations of the iris center. 

Parameters y_iris_center 

x_pupil_center Horizontal and vertical locations of the pupil center. 

y_pupil_center 

ISO_19794_6_seg_polar_image The output no-inner-boundary polar image, per Table 7. 

Return Value This function returns zero on success or a documented non-zero error code otherwise. 

An implementation may elect not to process the input image, or it may fail involuntarily. If this occurs, a documented 

non-zero error code will be returned and NIST will record this as a failure to segment. 

Q Should NIST recommend or require that the grey level data is not processed? For example, eyelids are not 

removed, frequency domain filtering is not performed, or histogram equalization is not applied? 

Q Should this function include an input over-segmentation parameter? The values for such a parameter would take 

on a limited number of values, say 100 for exact detection of the limbus, and 115 for a larger region [LG]. 

8.2.6. Conversion of rectilinear to unsegmented polar 

To examine the viability of the proposed unsegmented polar format, participating submissions to IREX 08 shall execute 

the conversion of operation of Table 16. To allow surveys over the radial and circumferential sampling rates the function 

takes as input number-of-samples arguments. 

Table 16 – Preparation of unsegmented polar records 

Input Action Output 

Conformant ISO/IEC 19794-6 rectilinear 

record, and desired circumferential and 

radial numbers of samples. 

Find suitable inner and 

outer circles. Execute 

forward polar transform. 

Proposed unsegmented polar 

record, per Table 8. 

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

10 Table 17 – IREX API for creation of unsegmented polar records 

Prototype INT32 convert_rectilinear_to_unsegmented_polar( 

const BYTE *ISO_19794_6_rectlinear_image, 

const UNIT16 num_samples_radially, 

const UINT16 num_samples_circumferentially, 

BYTE *unseg_polar_image); 

Description This function takes a conformant ISO/IEC 19794-6 rectilinear image and outputs the corresponding unsegmented polar 

image. 

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 ISO_19794_6_rectlinear_image The uncompressed raw image as prepared by the function in Table 11. 

Parameters 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. 

Output 

Parameters 

ISO_19794_6_unseg_polar_image The output template, per Table 8. 

Return Value This function returns zero on success or a documented non-zero error code otherwise. 

NIST Concept, Evaluation Plan and API Page 20 of 31 

11 
 

 

 

 

 

2 

3 

4 

5 

6 

7 

8 

9 

10 

11 

12 

13 

 

 

 

 

 

 

 

 

 

 

 

1 

IREX 2008 

Q Should NIST recommend or require that the grey level data is not processed? For example, eyelids are not masked, 

frequency domain filtering is not performed, or histogram equalization is not applied? 

Q Should this function include an input over-segmentation parameter? The values for such a parameter would take 

on a limited number of values, say 100 for exact detection of the limbus, and 115 for a larger region [LG]. 

An implementation may elect not to process the input image, or it may fail involuntarily. If this occurs, a documented 

non-zero error code will be returned and NIST will record this as a failure to segment. 

8.2.7. Template creation 

This function converts any of the input data structures to an opaque proprietary template. The function will need to look 

at the header of the input record to determine the content. This routine will need to heed the hexadecimal "Version 

Number" values in the Table 7 and Table 8 records. 

Table 18 – IREX API template creation 

Prototype INT32 convert_image _to_template( 

const BYTE *input_record, 

 BYTE *proprietary_template); 

Description This function takes either 

― a conformant ISO/IEC 19794-6 rectilinear image, or 

― a conformant ISO/IEC 19794-6 polar image, or 

― a proposed standard unsegmented polar image, 

and outputs a proprietary template. The implementation should inspect the input header to determine which kind of 

imagery is being provided. 

The memory for the output 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 template record that may be passed to the match_templates function without error. 

Input input_record An input image presented either as instance of Table 7 or Table 8.. 

Parameters 

Output proprietary_template The output template. The format is entirely unregulated, but it shall include its own length as 

Parameters this will not be provided to the subsequent matcher function. 

Return Value This function returns zero on success or a documented non-zero error code otherwise. 

An implementation may elect not to make a template, or it may fail involuntarily. If this occurs, a documented non-zero 

error code will be returned, size then NIST will record this as a failure to acquire. 

8.2.8. Template comparison 

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

Table 19 – IREX API template matching 

Prototype INT32 match_templates( 

const BYTE *verification_template, 

const UINT16 verification_template_size, 

const BYTE *enrollment_template, 

const UINT16 enrollment_template_size, 

double *score); 

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

The returned score is a distance measure. It need not satisfy the metric properties. NIST will allocate memory for 

this parameter before the call. When the function is called with either or both templates containing zero data (see 

Error! Reference source not found.) the function shall assign the value -1 to the score. 

Input Parameters verification_template A template from create_template(). 

NIST Concept, Evaluation Plan and API Page 21 of 31 
 

 

 

 

 

 

 

Q Will templates be larger than 65535 bytes in size? 

8.2.9. Implementation identifiers 

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

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

functionality. 

Table 20 – IREX API get_pids function 

Prototype INT32 get_pid(UINT32 *nist_assigned_identifier); 

Description This function retrieves an identifier that the provider must request from NIST, and compile into the source code. 

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

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

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

Return Value This function returns zero on success or a documented non-zero error code on failure. 

8.3. Software and Documentation 

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 

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 

score A similarity score resulting from comparison of the templates, on the range 

[0,DBL_MAX]. 

Return Value This function returns zero on success (i.e. a valid score is produced) or a documented non-zero error code on 

failure. 

Q Should NIST add a polarity flag to indicate smaller-is-more-genuine vs. larger-is-more-genuine, or are all suppliers 

content with smaller-is-more-genuine distance scores? 

l 

8.3.1. SDK Library and Platform Requirements 

Participants shall provide NIST with binary code only (i.e. no source code) − supporting files such as header (“.h”) files 

notwithstanding. Such files 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/shared library files are permitted. 

If dynamic/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 

‘libIREX.so’ for Linux). Additional dynamic/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). 

8.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 

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

― RedHat Linux Enterprise 4 or 5 platforms. 

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 

7 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 22 of 31 
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

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 

30

35

31 

32 

33 

34 

36 

37 

IREX 2008 

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. 

8.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. 

8.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 error and warning codes (see 8.4.3). 

8.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. 

8.4. Runtime behavior 

8.4.1. Speed 

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

― The mean template match operation shall not exceed 10 milliseconds. 

― The mean template creation operation shall not exceed 1.2 seconds (using a 2GHz Pentium IV). 

― The mean iris segmentation operation (e.g. polar) shall not exceed 1.2 seconds (using a 2GHz Pentium IV). 

d Should these times be lowered (for operational relevance) or raised (for improved algorithmic function)? 

8.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”. 

8.4.3. Error codes and status messages 

The SDK will be tested in non-interactive “batch” mode (i.e. 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”. Instead, the 

SDK shall conform to the error notification procedures of Annex A. 

NIST Concept, Evaluation Plan and API Page 23 of 31 
 

 

 

 

 

 

 

 

 

 

 

 

 

 

1 

2 

3 

4 

5 

6 

7 

8 

9 

10 

11 

12 

13 

14 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

IREX 2008 

8.4.4. 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 cease evaluation, inform the provider and document evidence of 

such in published reports. 

8.4.5. Stateful behavior 

All components in this test shall be stateless. This applies to segmentation, feature extraction and matching. Thus the 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 

― cease evaluation of all implementations from the supplier, 

― inform the supplier, and 

― publicly report the behavior, with attribution and documentary evidence. 

9. NIST conversion of Rectilinear to Polar Coordinates 

Q Rather than have suppliers execute the conversion of rectilinear to polar format, should NIST instead require the 

supplier to return the parameters of the transform with which NIST would then execute it.? 

NIST's transformation code would include neither boundary detection nor segmentation code. 

10. 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. 

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 

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

http://fingerprint.nist.gov/IREX04/IREX_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 

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. 

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 

NIST Concept, Evaluation Plan and API Page 24 of 31 
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

1 

IREX 2008 

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 

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 

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. 

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

Stage 

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 

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 25 of 31 
 

 

1 

2 

3 

4 

5 

6 

7 

8 

 

 

 

 

 

 

 

 

9 

IREX 2008 

Annex A 

Error Codes and Handling 

Each participant shall provide their SDK with text documentation of all (non-zero) error or warning return codes (see 

section 8.3.4, Documentation). 

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. 

At minimum the bit masked return codes of Table 21 shall be set and returned. 

Table 21 – IREX API return codes 

Return code Explanation 

0 Success 

1 Image size not supported 

2 Failed to find iris 

4 Failed to find pupil center 

8 Failed to find iris center 

16 Failed to match templates 

32 Failed to match templates – unable to parse probe template 

64 Failed to match templates – unable to parse gallery template 

> 128 Supplier defined error codes in here. 

All messages which convey errors, warnings or other information shall be suppressed. 

NIST Concept, Evaluation Plan and API Page 26 of 31 
 

 

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 B 

Application to participate in IREX 

This participation agreement is an incomplete adaptation of the one used in MINEX II, a recent fingerprint 

interoperability test. It is very much a draft, and will be revised in subsequent drafts. It is included only to 

indicate the kind of content. 

B.1 Who should participate 

Providers of implementations using ISO/IEC 19794-6:2005 iris images 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 8 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 6.6 and Annex B.7) of the evaluation of the software and/or hardware will be 

published with attribution to their organization(s). 

B.2 How to participate 

B.2.1 Application package 

10.1. Submission 

Those wishing to participate in IREX testing shall provide NIST with those components identified in the Participation 

Classes given in section 6.1. Software shall be submitted as an SDK (Software Development Kit) library which complies 

with the API (Application Programmer Interface) specified in this document. 

In order to request participation in IREX, prospective participants must assemble ALL of the following items and send the 

entire package to NIST at the address given in Annex C. 

― A signed and fully completed copy of this entire Annex B, including the Agreement Application to Participate in IREX, 

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

The package may also include: 

― Software for each submission (see section 6.1 and B.3.3). 

B.3 NIST activity 

B.3.1 Initiation 

Upon receipt of the signed Annex B 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. 

B.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 27 of 31 
 

 

 

5

10

1 

2 

3 

4 

6 

7 

8 

9 

11 

 

 

 

15

20

25

30

35

12 

13 

14 

16 

17 

18 

19 

21 

22 

23 

24 

26 

27 

28 

29 

31 

32 

33 

34 

36 

37 

38 

IREX 2008 

B.3.3 Submission of software to NIST 

After the Participant has executed his software on the validation imagery, the participants shall send the software and its 

validation output to NIST. All submitted material shall be encrypted using GnuPG (gpg) by downloading the IREX Test 

Liaison's public key: http://fingerprint.nist.gov/minex/minex_pk.asc whose fingerprint is 448F 3828 719D B6B0 FDC5 

3DE6 715B 6C72 062A 520A. 

― Importing it into your keyring using: gpg --import minex_pk.asc 

― Using it to encrypt your SDK (with ASCII armor if submitting via email): gpg -r minex -ae mysdk.zip 

The result shall be emailed to irex@nist.gov . 

NIST accepts no responsibility for unencrypted materials sent to NIST. 

B.3.4 Acceptance testing 

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

Upon receipt of the SDK and validation output, NIST will attempt to reproduce the 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. 

In the event cards or software is found to be non-functional or non-compliant with this document's specifications, or 

where the validation dataset results cannot be replicated by NIST, Participants will be notified with a detailed description 

of the problem(s) and given a reasonable opportunity to resubmit (as time allows) according to the discretion of the IREX 

Liaison. 

B.3.5 Limits of testing 

NIST will use the Participant's cards and SDK software only for the testing described in this document. The provided 

hardware and 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. 

B.4 Parties 

B.4.1 Responsible Party 

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

B.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. 

B.5 Access to IREX validation data 

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

The fingerprints 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. 

NIST Concept, Evaluation Plan and API Page 28 of 31 
 

 

 

 

 

 

 

 

 

 

 

 

 

 

5

10

1 

2 

3 

4 

6 

7 

8 

9 

11 

12 

15

20

25

30

35

13 

14 

16 

17 

18 

19 

21 

22 

23 

24 

26 

27 

28 

29 

31 

32 

33 

34 

36 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

IREX 2008 

B.6 Access to IREX test data 

The IREX Test Datasets are 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. 

B.7 Reporting of results 

B.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 

― enrollment and verification timing statistics. 

NIST may compute and report other aggregate statistics. 

NIST intends to release Phase 1 results to the participant only. 

NIST intends to publish Phase 2 results in one or more NIST Interagency Reports. 

The Phase 2 reports will: 

― contain the names of Phase 1 participants, 

― not contain the results from Phase 1 participants' implementations, 

― contain the names of Phase 2 participants, and 

― contain the results of all Phase 2 participants' implementations which will associated with the participants names. 

B.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. 

B.7.3 Citation of the report 

After the release of the Phase II Final Report, 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. 

B.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. 

B.8 Return of the supplied materials 

B.8.1 Returning software to vendors 

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

NIST Concept, Evaluation Plan and API Page 29 of 31 
 

1 

2 

3 

4 

5 

6 

7 

8 

9 

10 

11 

12 

13 

14 

15 

16 

IREX 2008 

B.8.2 Returning cards to vendors 

NIST will not return cards to the provider. NIST will destroy the cards within ninety days of publication of the results for 

that card or notification to the vendor that the card is inoperable. This requirement is needed because template data on 

the card is protected and because NIST has no mechanism to assure deletion of templates from the card. However, NIST 

to support debugging NIST may, at its sole discretion, return cards during the initial acceptance testing phase. 

B.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 can withdraw from the IREX at any time prior to the end of the 

Phase 1 submission window, without their participation and withdrawal being documented in the IREX Final Report. 

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 fingerprint matcher technology (i.e. any algorithms present on the card or in the SDK library). 

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 

17 

18 

19 

20 

21 

22 

23 

24 

25 

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

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

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

document. 

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

________________________________________________________________________________ 

SIGNATURE OF FIRST FINGERPRINT SOFTWARE SUPPLIER RESPONSIBLE PARTY DATE 

NIST Concept, Evaluation Plan and API Page 30 of 31 
 

 

1 

2 

3 

4 

5 

6 

 

 

 

 

 

 

 

 

 

 

 

IREX 2008 

Annex C 

NIST mailing address 

The address given below shall be used for all mail or courier delivery to NIST. This includes delivery of IREX participation 

agreements and all IREX cards and software. 

IREX Test Liaison 

National Institute of Standards and Technology 

Information Access Division (894) 

100 Bureau Drive 

A203/Tech225/Stop 8940 

Gaithersburg, MD 20899-8940 

USA 

In cases where the courier needs a phone number please use NIST shipping and handling at 301 nine seven five six two 

nine six. 

NIST Concept, Evaluation Plan and API Page 31 of 31