1 

2 

3 

4 

5 

6 

7 

8 

9 

10 

11 

12 

13 

14 

15 

16 

IREX 

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

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

17 

18 

19 

20 

21 

22 

23 

24 

25 

26 

27 

28 

 

 

IREX 2008 

Iris Exchange (IREX) Evaluation 2008 

Concept, Evaluation Plan and API 

Patrick Grother 

NIST 

February 20, 2008 

NIST Concept, Evaluation Plan and API Page 1 of 31 
 

 

 

 

 

 

 

 

 

7 

IREX 2008 

1 

2 

3 

4 

5 

6 

Commenting on this Draft 

Feb 20, 2008: NIST welcomes comments on this draft. These should be submitted to patrick.grother@nist.gov by 

Tuesday March 11, 2008. Proprietary information should not be sent to NIST, and any commentary marked with 

phrases such as "commercial in confidence" will be ignored. 

As with the 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 Request for Iris Images 

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

who might benefit from their use in NIST's testing effort. 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 Concept, Evaluation Plan and API Page 2 of 31 
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

1 

IREX 2008 

Major changes since the November 2007 draft 

2 

3 

4 

1 The timeline has slipped. Several commentators remarked that the schedule was too 

ambitious; NIST's response would be to proceed with a view to making 

― compressed and cropped rectilinear results available to SC 37 Working Group 3 in 

July 2008, 

― a final report on all aspects ahead of the U.S. meeting of SC 37 in January 2009. 

Revised timeline on page 

4. 

2 In January 2008, SC 37 Working Group 3 voted to remove all polar formats from the 

revision of ISO/IEC 19794-6. We have therefore abandoned plans to test the full-polar 

and no-inner-boundary polar formats of ISO/IEC 19794-6:2005. 

Deletions from scope in 

Sec. 3. Major changes to 

secs. 6, 7 and 8. 

3 However, WG 3 also asked for contributions "on compact formats" and on 1 "interoperability tests related to alternate compact formats" . 

We therefore propose to explicitly evaluate implementations of the following 

― the Cambridge/UK ROI-masked image documented in 37N2125 [CAM07] 

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

outer circles are concentric; extended to allow vendor-defined segmentation 

information. 

Modified scope in Sec. 3. 

Refs are elevated to 

Normative References in 

sec. 4. 

Revised data structures in 

sections 7.4 and 7.5 

3 On metrics 

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

constraints. This allows a measure of sufficiency - the ISO term [PERFSTD] for 

expressing whether the standardized format is sufficient to achieve the accuracy 

of fully proprietary unconstrained encodings, including zero compression. 

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

ratio. 

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

hard limits established for smartcards (for example). 

Sec. 6.8 

4 NIST intends to exclude or segregate unmatchable images (e.g. eyes closed, missing) 

and other images from the various databases. The ability to handle non-ideal images 

is beyond the scope of this evaluation of compression and compact forms. 

Sec. 6.7. 

5 Separate studies for these cases: 

― Only the enrollment sample is formatted and compressed, and 

― Both the enrollment and verification samples are formatted and compressed. 

Sec. 6.2 

1 Document N2426 has this: RECOMMENDATION 3.14 – Call for Contributions on 19794-6 Revision 1 SC 37 WG 3 requests its Secretariat 

to issue a call for National Body contributions on the following topics in ISO/IEC 19794-6 (Revision) Biometric data interchange format -

Part 6: Iris image data. 

a) on interoperability tests related to alternate compact formats 

b) on results of a study on iris image compression. WG3 strongly supports the proposed IREX 08 tests by NIST and would 

encourage NIST to examine both published compact formats together with proposed new formats, such as ROI compression. 

c) on allowable intra-iris Signal/Noise ratio value 

d) on effect of using available ROI implementations in COTS JPEG 2000 compressors 

e) on differences in efficiency between JPEG and JPEG 2000 at various compression ratios 

f) on a study incorporating the measurement method as described in US-12 of N2386rev 

g) on cautioning text for the use of optional parameters in the image header about pupil centre , diameter of the pupil, iris 

centre and diameter of the iris. 

h) on compact formats 

Contributions received by 22 May 2008 will be considered at the July 2008 WG 03 meeting in Korea. - Unanimous 

NIST Concept, Evaluation Plan and API Page 3 of 31 
 

 

 

2 

3 

4 

 

 

 

 

 

 

 

 

 

 

 

1 

5 

6 

IREX 2008 

Project History 

Feb 20, 2008 

― NIST thanks those organizations who commented on the November 2007 draft. 

― NIST also thanks the members of the SC 37 Working Group 3 committee for giving oxygen to the issues 

involved with developing a vendor-independent standardized iris image record. 

― Revised draft circulated. 

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 

Jan 18-24, 2009 SC37 meeting, United States 

July 7-15, 2008 SC37 meeting, Korea 

March 11, 2008 Comments on second draft due 

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

the breadth, depth, and quantity of comments received. 

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

December 8, 2007 Conclusion of Initial comment period 

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

Q2 Assuming the IREX 08 specification can be fixed in the next edition of this document, how long would it take to 

implement and send the SDK? 

NIST Concept, Evaluation Plan and API Page 4 of 31 
 

 

 

5

10

15

20

1 

2 

3 

4 

6 

7 

8 

9 

11 

12 

13 

14 

16 

17 

18 

19 

21 

22 

23 

24 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

30

35

40

45

50

26 

27 

28 

29 

31 

32 

33 

34 

36 

37 

38 

39 

41 

42 

43 

44 

46 

47 

48 

49 

51 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

25

IREX 2008 

Table of Contents 

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

2. Motivation and background............................................................................................................................................. 7 

2.1. Toward compact forms........................................................................................................................................... 7 

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

3. Scope ................................................................................................................................................................................ 8 

4. Normative References...................................................................................................................................................... 9 

5. Abbreviations ................................................................................................................................................................... 9 

6. Aspects of the test.......................................................................................................................................................... 10 

6.1. Fundamental concept of the test ......................................................................................................................... 10 

6.2. Segmentation on uncompressed data.................................................................................................................. 11 

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

6.4. Feature extraction on compressed data............................................................................................................... 11 

6.5. Interoperability space........................................................................................................................................... 11 

6.6. Offline evaluation using archival imagery............................................................................................................. 11 

6.7. Exclusion of bad images........................................................................................................................................ 11 

6.8. Measure sufficiency.............................................................................................................................................. 12 

6.9. Uniform software interface .................................................................................................................................. 12 

6.10. Audience and options for participation................................................................................................................ 12 

6.11. Number of submissions........................................................................................................................................ 12 

6.12. Compression metrics............................................................................................................................................ 13 

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

6.14. Verification performance...................................................................................................................................... 13 

6.15. Phased testing....................................................................................................................................................... 13 

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

6.17. Standards-based evaluation ................................................................................................................................. 14 

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

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

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

7.3. Rectilinear image record structure ....................................................................................................................... 14 

7.4. ROI-masked record structure ............................................................................................................................... 15 

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

7.6. Auxiliary Data........................................................................................................................................................ 18 

8. PC-based API specification ............................................................................................................................................. 19 

8.1. Overview............................................................................................................................................................... 19 

8.2. Testing interface ................................................................................................................................................... 19 

8.3. Software and Documentation............................................................................................................................... 24 

8.4. Runtime behavior ................................................................................................................................................. 25 

9. References...................................................................................................................................................................... 26 

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

A.1 Who should participate ........................................................................................................................................ 28 

A.2 How to participate ................................................................................................................................................ 28 

A.3 NIST activity .......................................................................................................................................................... 28 

A.4 Parties................................................................................................................................................................... 29 

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

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

A.7 Reporting of results .............................................................................................................................................. 30 

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

A.9 Agreement to participate ..................................................................................................................................... 31 

List of Figures 

NIST Concept, Evaluation Plan and API Page 5 of 31 
 

 

 

5

10

15

20

1 

2 

3 

4 

6 

7 

8 

9 

11 

12 

13 

14 

16 

17 

18 

19 

21 

22 

23 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

5

4 

6 

7 

8 

9 

2

2

2

2

2

2

 

 

 

IREX 2008 

No table of figures entries found. 

List of Tables 

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

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

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

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

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

Table 8 - Structure for the ROI-masked rectilinear variant of ISO/IEC 19794-6..................................................................... 15 

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

Table 10 - Format for Freeman chain code ............................................................................................................................ 18 

Table 11 – Sensor identifiers .................................................................................................................................................. 19 

Table 12 – Preparation of standard rectilinear records ......................................................................................................... 19 

Table 13 – IREX API preparation of standard rectilinear record ............................................................................................ 20 

Table 14 – Preparation of ROI-masked records ..................................................................................................................... 20 

Table 15 – IREX API for creation of ROI-masked records ....................................................................................................... 20 

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

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

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

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

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

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

 

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 particularly 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 the two compact formats proposed for the 

revision of the ISO/IEC 19794-6 standard. 

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

commercial iris verification implementations on a common sequestered test corpus. 

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

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

2. Motivation and background 

2.1. 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 2 data element suitable for storage on an ISO/IEC 7816 crypto-token , and for efficient transmission across a network. 

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

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

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

similar compression sensitivities for two different matching algorithms. 

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

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

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

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

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

2.2. Support for the ISO standard 

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

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

contrasts with the default practice of the SC 37 Working Group 3 and M1.3 committees, which 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. 

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

29 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

30 

31 

32 

33 

34 

35 

36 

37 

38 

39 

 

 

 

 

 

 

 

 

 

 

 

 

IREX 2008 

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

compact iris imagery on a ISO/IEC 7816 smartcard. This was achieved by specifying a no-inner-boundary polar format4 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 was 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. This was 

defeated by 6-5 vote, and an updated polar-free draft standard is imminent. 

Two alternative compact forms have been advanced: A ROI-masked version [CAM07] and a new polar variant termed the 

unsegmented polar version [IRI07]. The IREX 08 test is therefore being conducted as an independent assessment of 

interoperability and accuracy of these proposed compact forms. This is more formally stated below. 

3. Scope 

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

rectilinear format, and by evaluating the proposed new formats that have been contributed to the ISO/IEC 19794-6 

revision project. 

Specifically the test aims to 

― quantify the performance and interoperability of 

− rectilinear images, 

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

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

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

― quantify the performance and interoperability of iris segmentation algorithms 

― time the various operations, 

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

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

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

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

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

thresholds, 

― time taken to prepare the various standard instances, 

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

― time taken to match feature-based templates. 

In so doing, the IREX evaluation requires 

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

― conversion of ISO/IEC 19794-6 rectilinear images into ROI-masked rectilinear images, and 

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

3 See http://www.rtconsortium.org/_docpost/RTICTIGSpec_v1.2.pdf 4 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. 

NIST Concept, Evaluation Plan and API Page 8 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 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

26 

27 

28 

29 

30 

 

 

 

 

 

 

 

25 

IREX 2008 

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

― predictions of operational performance, 

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

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

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

The following two documents describe compact representations: 

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

― [IRI07] US Contribution Compact Iris Format. 

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

The syntactic representations are specified in sections 7.4 and 7.5. 

The values of the 5x7 kernel identified in the [CAM07] have not been published. NIST requests these to be contributed 

for the next IREX draft and that they become normative for all IREX participants making ROI-masked images. Further, 

NIST thinks the kernel values would be normatively written into the revised ISO/IEC 19795-6 standard, if ROI-masking is 

adopted therein. In addition, a mechanism for scaling the kernel for higher resolution images should be established. 

Q3 Is the [CAM07] document a sufficiently complete specification for implementation in IREX? Or does this IREX 

document need to refine the ROI-masking specification in any other ways? 

Q6 Is the [IRI07] document a sufficiently complete specification for implementation in IREX? Or does this IREX 

document need to refine the unsegmented polar specification in any other ways? 

If the final IREX specification is acceptable and successful, NIST would contribute definitive text and tables to the ISO/IEC 

19794-6 revision process. 

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 

NIST Concept, Evaluation Plan and API Page 9 of 31 
 

 

 

 

 

 

 

1 

2 

3 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

4 

5 

6 

7 

8 

9 

10 

11 

12 

13 

14 

15 

 

 

 

 

 

 

 

 

 

 

 

IREX 2008 

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 

Table 3 – IREX 08 image variants 

Rectilinear ROI-masked Rectilinear Unsegmented Polar 

Standards 

compliance 

ISO/IEC 19794-6 rectilinear format 

Clause 6.3.1 

Proposed content for ISO/IEC 19794-

6:200X, X > 7. 

Proposed content for ISO/IEC 19794-

6:200X, X > 7. 

See ISO/IEC 19794-6:2005 [CAM07] [IRI07] 

Required 

Segmentation 

None Eyelids, and iris sclera boundaries. 

Quoting [CAM07]: 

Concentric inner and outer circles, 

neither of which is necessarily 

centered on pupil or iris center. 

Stored image 

Use of stored 

image 

The use of the stored image is entirely at the discretion of the provider. In the rectilinear cases further segmentation 

and feature extraction seems necessary. For the unsegmented polar, either feature extraction is done directly, or, as 

[IRI07] suggests, the reverse polar transform is applied and a fine grained segmentation is applied before feature 

extraction. 

Encoding Table 7 Table 8 Table 9 

API Sections 8.2.3 and 8.2.4 Section 8.2.5 Section 8.2.6 

6. Aspects of the test 

6.1. Fundamental concept of the test 

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

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

conformant to ISO/IEC 19794-6:2005. 

In stage 2, functions within the suppliers SDK are called to convert the standard rectilinear instances into the compact 

forms of Table 3, specifically 

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

― Unsegmented polar images conformant to the specifications herein. 

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

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

NIST Concept, Evaluation Plan and API Page 10 of 31 
 

 

 

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 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

35

33 

34 

36 

37 

38 

 

 

 

 

 

 

 

IREX 2008 

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

measure. 

6.2. Segmentation on uncompressed data 

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

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

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

6.3. NIST invocation of compressors and de-compressors 

SDK functions that generate ROI-masked and unsegmented polar images shall not apply compression. NIST will call 

compression routines, and will survey over compression parameters, primarily the bit rate / compression ratio. 

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

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

6.4. Feature extraction on compressed data 

For both a ROI-masked or unsegmented polar, image the SDK template generation function will likely need to embed 

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

6.5. Interoperability space 

There are two targeted interoperability scenarios: 

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

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

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

uncompressed verification images. 

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

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

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

6.6. 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.7. Exclusion of bad images 

NIST does not intend to include a strict repetition of the ICE 06 trial5 in IREX 08. However, IREX 08 will include ICE data but 

also other datasets in addition. Given the IREX 08 goals to measure effects of compression and to evaluate compact 

formats (see scope - section 3), NIST will: 

― attempt to exclude images from the ICE and other databases which would contribute to false rejection whatever 

compression or compact representation is selected (e.g. eyes closed, or iris partially or fully absent) 

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

regarding these exclusions as FTE and FTA. 

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

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

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

NIST Concept, Evaluation Plan and API Page 11 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 

6.8. Measure sufficiency 

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

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

6.9. Uniform software interface 

We will evaluate algorithms by requiring them to be implemented behind the "C" API of section 0. 

6.10. Audience and options for participation 

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

― Production of conformant ISO/IEC 19794-6 records 

― Segmentation of iris imagery, including production of polar formats 

― Verification of standardized image records. 

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

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

be supplied. 

Table 4 – IREX classes of participation 

1 2 3 4 5 6 7 8 

Class of Annex A Ability to convert Ability to extract Ability to convert Ability to extract Ability to convert Ability to extract 

Participation Participation a raw raster into a features from a rectilinear features from a a rectilinear features from an 

agreement conformant conformant image into a ROI- [CAM07] image image into an [IRI07] polar 

instance of the instances of the masked and match. unsegmented image and match 

ISO/IEC 19794- ISO/IEC 19794-6 rectilinear image polar image 

6:2005 rectilinear 

image format 

rectilinear format 

and match 

[CAM07] [IRI07] 

Class A + + + 

Class B + + + + + 

Class C + + + 

Class D + + + + + 

The inclusion of these classes is motivated as follows: 

― Classes A+B exist to allow organizations to demonstrate the capability to generate and optionally match ROI-masked 

rectilinear images. 

― Classes C+D exist to allow organizations to demonstrate the capability to generate and optionally match 

unsegmented polar images. 

Note 

― For those providing matchers, i.e. classes B or D, then a matcher of rectilinear images also must be provided (i.e. 

column 4). 

― A participant may enter SDKs for more than one class (e.g. B and D) except 

+ Those providing B would not provide A. 

+ Those providing D would not provide C. 

6.11. Number of submissions 

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

mature" implementations to be tested. 

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 

33 

34 

 

 

 

 

 

IREX 2008 

6.12. 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.13. 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. 

6.14. 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, 

6 ― cohort normalization techniques , and 

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

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

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

As part of NIST's Biometric Data Interchange (BIOMDI) software distribution7, 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. This code will 

be changed as the record structures of Table 8 and Table 9 are solidified. 

NIST will develop code to execute forward and reverse polar transforms. This code will produce will be in C/C++ and will 

35 execute either bilinear or bicubic interpolation. NIST will evaluate both variants. 

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

background set of templates into the SDK. 

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

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

NIST Concept, Evaluation Plan and API Page 13 of 31 
 

NIST Concept, Evaluation Plan and API Page 14 of 31 

1 

2 

3 

4 

5 

6 

7 

8 

9 

10 

11 

12 

13 

14 

15 

16 

17 

18 

19 

 

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. 

20 

21 

22 

23 

 

 

 

 

 

 

 

24 

25 

26 

27 

28 

IREX 2008 

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

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 format 

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 has been handled as part of the revision process. 

Table 5 – Identifying variants via CBEFF format type 

Geometric Encoding CBEFF_BDB_format_type 

Rectilinear 0x0009 

Polar 0x000B 

Table 6 – Identifying variants using Version Number 

Geometric Encoding 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. 

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

Rectilinear 0x30313000 '010\0' 

Proposed ROI-masked rectilinear 0x30313100 '011\0' 

Proposed unsegmented Polar 0x30313200 '012\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 
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

1 

2 

3 

4 

5 

6 

 

 

 

 

 

IREX 2008 

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 See Table 6 

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

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

of those in Table 11. 

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 0 

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. 

26. Image length 4 B LEN 

27. Image data LEN 

7.4. ROI-masked record structure 

ROI-masked image generators shall produce records conformant to Table 8. The record is identical to that of the generic 

rectilinear format, but with additional fields, in yellow, for the ROI masked regions. If adopted here, and used 

successfully, the records defined herein would form the basis of NIST contributions toward revision of ISO/IEC 19794-6. 

Table 8 - Structure for the ROI-masked rectilinear variant of ISO/IEC 19794-6 

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 0x30313100 See Table 6 

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

NIST Concept, Evaluation Plan and API Page 15 of 31 
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

2 

3 

4 

5 

6 

7 

8 

 

1 

IREX 2008 

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

of those in Table 11. 

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 0 ≤ Q ≤ 100 This field to be populated with value. 

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. 

26. Mask value for upper eyelid 1B If depth was > 8 bits these should be >8 bits too. 

27. Mask value for lower eyelid 1B For IREX 08, everything is 8 bits. 

28. Mask value for sclera 1B 

29. Auxiliary information length 2 B LEN See section 7.6. 

30. Auxiliary information LEN 

31. Image length 4 B LEN 

32. Image data LEN 

Q9 Are three grey-level values needed (i.e. lines 26, 27 and 28). Or two? 

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. 

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 [IRI07]. Yellow shading indicates new fields. If adopted here, and used successfully, the records defined herein 

would form the basis of NIST contributions toward revision of ISO/IEC 19794-6. 

Table 9 – Structure for the proposed unsegmented polar format 

NIST Concept, Evaluation Plan and API Page 16 of 31 

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

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

IREX 2008 

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 0x30313200 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. 

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

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

of those in Table 11. 

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 Polar format only 

11. Occlusion filling 1 b Polar format only 

12. Boundary extraction 1 b Polar format only 

13. Iris diameter (rect) 2 B 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 0 ≤ Q ≤ 100 This field to be populated with value. 

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

25. Rotation uncertainty 2 B ROT_UNCERTAIN_UNDEF 

26. X coordinate of inner + outer circle centers 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 concentric 

27. Y coordinate of inner + outer circle centers 2 B 0 ≤ y < H 

28. Inner circle radius 2 B 0 ≤ r 

29. Outer circle radius 2 B 0 ≤ r 

30. Auxiliary information length 2 B LEN See section 7.6. 

31. Auxiliary information LEN 

32. X coordinate of the center of the ellipse 

approximating the pupil boundary 2 B 

33. Y coordinate of the center of the ellipse 

approximating the pupil boundary 2 B 

34. X coordinate of the intersection point of 

the semi-major axis with the ellipse 

approximating the pupil 

2 B 

35. Y coordinate of the intersection point of 

the semi-major axis with the ellipse 

approximating the pupil 

2 B 

36. X coordinate of the intersection point of 

the semi-minor axis with the ellipse 

approximating the pupil 

2 B 

NIST Concept, Evaluation Plan and API Page 17 of 31 
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

1 

2 

3 

4 

5 

6 

7 

8 

9 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

10 

IREX 2008 

37. Y coordinate of the intersection point of 

the semi-minor axis with the ellipse 

approximating the pupil 

2 B 

38. X coordinate of the center of the ellipse 

approximating the iris boundary 2 B 

39. Y coordinate of the center of the ellipse 

approximating the iris boundary 2 B 

40. X coordinate of the intersection point of 

the semi-major axis with the ellipse 

approximating the iris 

2 B 

41. Y coordinate of the intersection point of 

the semi-major axis with the ellipse 

approximating the iris 

2 B 

42. X coordinate of the intersection point of 

the semi-minor axis with the ellipse 

approximating the iris 

2 B 

43. Y coordinate of the intersection point of 

the semi-minor axis with the ellipse 

approximating the iris 

2 B 

44. Image length 4 B LEN 

45. Unsegmented polar-transformed image 

data 

LEN 

7.6. Auxiliary Data 

Regarding the Auxiliary Data block on Lines 30-31 of Table 9, and Lines 29-30 of Table 8, NIST does not intend to allow 

purely vendor-defined data (e.g. a proprietary template) to be placed in such a block because it is non-interoperable8

. 

NIST instead proposes to standardize the contents of this block in two parts, as follows. 

― Eight-connected Freeman chain code (FCC) of the closed-path inner boundary. 

― Eight-connected Freeman chain code (FCC) of the closed-path outer boundary. 

Eight-connected FCCs allow encoding of an arbitrary path in 3 bits per pixel. For an iris of radius 100 pixels, and a pupil of 

radius 40 pixels, such encoding would require, with a small header, around 220 and 90 bytes respectively. 

Table 10 - Format for Freeman chain code 

# Field Length 

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

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

3 Number of elements in chain code N 

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

Q12 Do you have alternatives or additions to FCC? These should be precisely documented, non-proprietary, and 

available to be specified in this document. 

Q15 Do you want Freeman chain codes? (If yes, ellipse info lines 32-43 would be deleted). If not, why not? 

Q18 Do you want a vendor-defined auxiliary data block? 

11 

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

it is only valuable when the producer and consumer of the data are manufactured by the same company. 

NIST Concept, Evaluation Plan and API Page 18 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 

 

 

 

 

 

 

IREX 2008 

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

Table 11 – 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. Geometric or other alterations to images 

In some cases poor images will need to be corrected. For example, the following action is described in Section 2 of 

[CAM07]. 

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

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

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

shape, a corrective affine transformation was automatically applied which effectively 

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

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

NIST takes no position on whether these or other operations (e.g histogram equalization) should be applied. 

Any such processing shall be conducted during the preparation of the ROI-masked rectilinear instance of section 8.2.5, or 

the unsegmented polar instance of section 8.2.6. It shall not be performed in the preparation of the rectilinear instance 

of section 8.2.4. 

8.2.4. 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 12. 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 12 – Preparation of standard rectilinear records 

Input Action Output 

Raw raster, dimensions, and 

parameters needed to instantiate 

Package the input into a 

conformant record. 

Conformant ISO/IEC 19794-6 

rectilinear record. These records 

NIST Concept, Evaluation Plan and API Page 19 of 31 
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

1 

2 

3 

4 

5 

6 

7 

8 

9 

10 

11 

12 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

IREX 2008 

the standardized record Do not alter the image data. will be checked for conformance. 

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

Table 13 – IREX API preparation of standard rectilinear record 

Prototype INT32 convert_raster_to_rectilinear( 

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 11 

Output 

Parameters 

Quality A [0,100] quality value representing 

ISO_19794_6_rectlinear_image The output rectilinear image, per Table 7 

Return Value 0 Success 

Other Vendor-defined 

8.2.5. Conversion of rectilinear to ROI-masked rectilinear 

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

operation of Table 14. In addition to the ROI-masked output image, the function shall return center coordinates. This: 

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

― allows NIST to run execute JPEG cropping as in section 2 of [CAM07] 

― allows NIST to run JPEG 2000 ROI tests (as has been considered for ISO/IEC 19794-5 Token face images) 

Table 14 – Preparation of ROI-masked records 

Input Action Output 

Conformant ISO/IEC 

19794-6 rectilinear 

record. 

Find iris-eyelid and iris-sclera boundaries and 

mask those regions with vendor fixed values. 

Perform corrective geometry actions (sec XX). 

ROI-masked record, per Table 7. 

Radius and center coordinates of 

the outer circle. 

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

Table 15 – IREX API for creation of ROI-masked records 

NIST Concept, Evaluation Plan and API Page 20 of 31 
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

1 

2 

3 

4 

5 

6 

7 

8 

9 

10 

11 

12 

13 

14 

15 

16 

17 

18 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

IREX 2008 

Prototype INT32 convert_rectilinear_to_ROI_masked_rectilinear( 

const BYTE *ISO_19794_6_rectlinear_image, 

UINT16 *x_iris_center, 

UINT16 *y_iris_center, 

UINT16 *iris_radius 

BYTE * roi_masked_rectilinear_image); 

Description This function takes a conformant ISO/IEC 19794-6 rectilinear image and outputs the corresponding ROI-masked image. 

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 

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

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

Input 

Parameters 

ISO_19794_6_rectlinear_image The uncompressed raw image used for template creation. 

Output x_iris_center Horizontal and vertical locations of the iris center. 

Parameters y_iris_center 

iris_radius Radius of a circle containing the entire iris. 

roi_masked_rectilinear_image The output polar image, per Table 8. 

Return Value 0 Success 

1 Involuntary failure to produce an output record - e.g. could not find iris-sclera 

boundary. 

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

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

Other Vendor-defined failure 

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

analyses. 

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. The function shall be implemented with the API call specified in Table 17. 

In addition to the raw input record, three additional parameters are passed in. 

― To allow surveys over the radial and circumferential sampling rates the function takes as input number-of-samples 

arguments. 

― To parameterize a loosening of the segmentation, the function takes an outer radius multiplier, specified as a 

percentage of the supplier's best computation of the circle enclosing all regions of the iris. This is introduced per 

recommendation to "over-segment the iris by 15% of the algorithm-determined iris boundary before converting it to 

Polar format" [LG]. NIST will set the default to be 115, and survey over this parameter. 

Q19 Is a NIST survey over a "radius multiplier" worth the trouble? Alternatives could be for IREX to mandatorily fix: a 

factor (e.g. 115), or a margin (e.g. 8 pixels). 

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

― allows NIST to run execute JPEG cropping as in section 2 of [CAM07] 

― allows NIST to run JPEG 2000 ROI tests (as has been considered for ISO/IEC 19794-5 Token face images) 

Table 16 – Preparation of unsegmented polar records 

Input Action Output 

NIST Concept, Evaluation Plan and API Page 21 of 31 
 

 

 

 

 

 

 

 

 

 

1 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

2 

3 

4 

5 

6 

7 

8 

9 

 

 

 

 

 

 

 

 

 

 

 

 

IREX 2008 

Conformant ISO/IEC 19794-6 rectilinear Find suitable concentric Proposed unsegmented polar 

record, desired circumferential and radial inner and outer circles. record, per Table 9. 

numbers of samples, and radius Execute forward polar 

multiplier. transform. 

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, 

const UINT16 outer_radius_multiplier, 

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

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. 

outer_radius_multiplier NIST proposes to set the default value to 115 indicating the SDK should add 15% to 

its computation of the minimal outer circle. 

Output 

Parameters 

unseg_polar_image The output template, per Table 9. 

Return Value 0 Success 

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

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

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

Other Vendor-defined failure. 

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

analyses. 

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 9 records. 

Table 18 – IREX API template creation 

Prototype INT32 convert_image _to_template( 

const BYTE *input_record, 

UINT16 *template_size, 

BYTE *proprietary_template); 

Description This function takes either 

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

― an ROI-masked image, or 

― an unsegmented polar image, 

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

imagery is being provided, per the version number values given in section 7.2. 

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

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

NIST Concept, Evaluation Plan and API Page 22 of 31 
 

 

 

 

 

 

 

 

 

 

 

 

1 

2 

3 

4 

5 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

6 

7 

8 

9 

10 

11 

12 

13 

14 

15 

16 

 

IREX 2008 

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

failed" and the matcher must transparently handle this. 

Input 

Parameters 

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

Output Template_size The size, in bytes, of the output template 

Parameters proprietary_template The output template. The format is entirely unregulated. 

Return Value 0 Success 

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

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

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

Other Vendor-defined failure 

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

analyses. 

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 *dissimilarity); 

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. the function shall assign the value -1 to the score. 

Input Parameters verification_template A template from create_template(). 

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

enrollment_template A template from create_template(). 

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

Output 

Parameters 

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

range [0,DBL_MAX]. See section 8.2.9. 

Return Value 0 Success 

Other Vendor-defined failure 

8.2.9. Dissimilarity score 

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

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

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

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

8.2.10. Implementation identifiers 

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

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

functionality. 

Table 20 – IREX API get_pids function 

Prototype INT32 get_pid(UINT32 *nist_assigned_identifier); 

NIST Concept, Evaluation Plan and API Page 23 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 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

IREX 2008 

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 

Parameters 

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

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

Return Value 0 Success 

Other Vendor-defined failure 

8.3. Software and Documentation 

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 cygwin9 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 

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. 

9 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 24 of 31 
 

 

5

10

1 

2 

3 

4 

6 

7 

8 

9 

11 

12 

13 

14 

 

 

 

 

 

 

 

 

 

 

 

15

20

25

30

35

16 

17 

18 

19 

21 

22 

23 

24 

26 

27 

28 

29 

31 

32 

33 

34 

36 

IREX 2008 

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 (non-zero) vendor-defined error or warning return codes.. 

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

Q21 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” mod, without terminal support. Thus, the submitted library shall run 

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

8.4.4. Exception Handling 

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

provided to the calling application. 

8.4.5. External communication 

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

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

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

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

published reports. 

8.4.6. Stateful behavior 

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

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

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

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

activity in published reports. 

NIST Concept, Evaluation Plan and API Page 25 of 31 
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

1 

IREX 2008 

9. References 

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

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

20, 2007. 

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

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

2006 

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

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

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

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

available as: John Daugman and Cathryn Downing, Effect of severe image compression, on iris recognition 

performance. Technical Report No. 685, University of Cambridge, Computer Laboratory, UCAM-CL-TR-685, ISSN 

1476-2986, May 07. http://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-685.pdf 

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

Also The above material is part of the following: 

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

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

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

31, 2007. This document is a password protected contribution toward the US position on the revision of 19794-

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

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

379-2004, http://www.incits.org 

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

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

Readers unable to access either link document should contact NIST. 

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

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

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

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

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

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

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

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

interchange formats – Part 6: Iris image data 

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

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

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

Testing. Posted as document 37N2370. 

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

Stage 

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

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

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

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

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

NIST Concept, Evaluation Plan and API Page 26 of 31 
 

 

 

 

 

 

1 

IREX 2008 

presented to the Second NIST Quality Workshop on November 8, 2007 and is linked here: 

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

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

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

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

NIST Concept, Evaluation Plan and API Page 27 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 

IREX 2008 

Annex A 

Application to participate in IREX 

A.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 7.6 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.11 and Annex A.7) of the evaluation of the software and/or hardware will be 

published with attribution to their organization(s). 

A.2 How to participate 

Those wishing to participate in IREX testing 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 send a signed and fully completed copy of this 

entire Annex A, including the Agreement Application to Participate in IREX, form below. This must identify, and include 

signatures from, the Responsible Parties as defined in section A.4. It shall be sent to 

IREX Test Liaison In cases where the courier needs a 

National Institute of Standards and Technology phone number please use NIST 

Information Access Division (894) shipping and handling at 301 nine 

100 Bureau Drive seven five six two nine six. 

A203/Tech225/Stop 8940 

Gaithersburg, MD 20899-8940 

USA 

A.3 NIST activity 

A.3.1 Initiation 

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

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

A.3.2 Supplier validation 

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

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

produces correct similarity scores and templates. 

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

NIST Concept, Evaluation Plan and API Page 28 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 

30

26 

27 

28 

29 

35

31 

32 

33 

34 

36 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

IREX 2008 

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

A.3.4 Acceptance testing 

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

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. 

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

A.4 Parties 

A.4.1 Responsible Party 

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

A.4.2 Point of contact 

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

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

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

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

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

postings will not be made public in the FAQ. 

A.5 Access to IREX validation data 

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

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

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

A.6 Access to IREX test data 

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

but Unclassified and/or Law Enforcement Sensitive. 

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

NIST Concept, Evaluation Plan and API Page 29 of 31 
 

 

 

5

10

15

20

25

30

1 

2 

3 

4 

6 

7 

8 

9 

11 

12 

13 

14 

16 

17 

18 

19 

21 

22 

23 

24 

26 

27 

28 

29 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

35

31 

32 

33 

34 

36 

37 

 

 

 

 

 

 

IREX 2008 

A.7 Reporting of results 

A.7.1 Reports 

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

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

include 

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

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

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

NIST may compute and report other aggregate statistics. 

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. 

A.7.2 Pre-publication review 

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

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

Comments will be attributed to the participant. 

A.7.3 Citation of the report 

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

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

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

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

A.7.4 Rights and ownership of the data 

Any data generated, deduced, measured or otherwise obtained during IREX (excepting the submitted SDK itself), as well 

as any documentation required by the Government from the participants, becomes the property of the Government. 

Participants will not possess a proprietary interest in the data and/or submitted documentation. 

A.8 Return of the supplied materials 

A.8.1 Returning software to vendors 

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

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

NIST Concept, Evaluation Plan and API Page 30 of 31 
 

 

1 

2 

3 

4 

5 

6 

7 

8 

9 

10 

11 

12 

13 

14 

15 

16 

17 

18 

19 

20 

21 

IREX 2008 

A.9 Agreement to participate 

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

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

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

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

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

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

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

website supersede the information on this form. 

With the signing of this form, Participants realize that they 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 iris segmentation, encoding and/or matching technologies. 

Company / Organization Name 

Title First Name MI Last Name Suffix 

Street Address 

City State Zip Country 

Phone Fax Email 

Technical point of contact Phone Email 

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 SOFTWARE SUPPLIER RESPONSIBLE PARTY DATE 

NIST Concept, Evaluation Plan and API Page 31 of 31