Iris Recognition Architecture Diagram: NIR Capture, Segmentation, IrisCode Match and Template Retention

An iris recognition architecture diagram has to show two different things NIST actually specifies, and they are not the same record. IREX IX Part One (NISTIR 8207) times the creation of a comparison template and then either a one-to-one compare or a one-to-many search. NIST SP 800-76-2 does not standardize an iris template at all. For Personal Identity Verification it profiles iris images: one form that can sit on the PIV card, and another form an agency may retain off the card. The drawing below is that path. Near-infrared capture, a quality check that can force a recapture, template creation for the matcher IREX measures, then a fork between a fast 1:1 compare and a 1:N gallery, with a side box for where the image is allowed to live.

What this iris recognition architecture diagram shows

The IREX IX program evaluates verification, meaning one-to-one matching, and identification, meaning one-to-many matching. It also calls out illumination from the visible through the near infrared, off-angle images, and images from cameras that were not designed for iris recognition. NIST started the Iris Exchange program in 2008 to give quantitative support to the marketplace, including the ISO/IEC 19794-6 and 29794-6 standards. Earlier parts of that program looked at compressed images, quality assessment, one-to-many algorithms, and capture guidance.

Part One of the evaluation, summarized on the NIST publication page and in NISTIR 8207, is a performance test of verification and identification algorithms on operational field images. The report separates template creation time from comparison time. For one-to-one matching it says comparison of two templates is nearly instantaneous relative to creating the template, so creation time is the speed figure that matters for most verification transactions. It does not publish a bit layout for an IrisCode, and this diagram does not draw one.

The same report says the next IREX IX report will look at recognition when the iris is illuminated at different wavelengths. ISO/IEC 19794-6, as quoted there, recommends near-infrared illumination between approximately 700 and 900 nanometres. The follow-on work is specifically about how well algorithms can segment and compare samples captured from the visible through the infrared. Segmentation is named as future measurement, not as a finished result in Part One.

The problem this architecture is solving

A matcher needs a comparable template. A credential program needs an image other vendors can still read years later. SP 800-76-2 states the difference directly: it makes no mention of an iris template, because templates are proprietary encodings of the standardized images, they are not interoperable, and an agency that keeps only templates is exposed to supplier lock-in. Interoperability in that specification is achieved with images.

PIV therefore splits storage rather than inventing a universal code. An image may be prepared for the card. Separately, the specification neither requires nor precludes an agency from retaining iris images outside the card. If images are retained, they support uses such as detecting duplicate identities, and the text notes that iris image data may be available off the card for authentication during issuance, re-issuance, and verification-data reset. The same publication warns against treating every compact iris record as gallery fuel: it would be appropriate to use the compressed iris specification defined there on a nation state's e-passport, and technically suboptimal to copy those images in as the enrollment samples of an expedited-traveler program running one-to-many with the iris as a single factor.

Main components and trust boundaries

NIR camera. SP 800-76-2 requires dedicated infrared illuminators emitting in the 700 to 900 nanometre interval. Cameras that are primarily sensitive to visible light, such as those used for face photography, are not suitable and shall not be used. The output the specification wants for later authentication is a rectilinear iris image, not a polar bit grid.

Quality control. Before an image is accepted for the card, the specification tells agencies to have the applicant remove eyeglasses, hard contact lenses, or patterned contact lenses, then run a one-to-one check of a newly captured image against the image that is, or will be, stored on the card. If that check fails, the client recaptures and repeats the match. The camera and software might collect several images and cross-match them. An operator should confirm that the eyes are open, not blurred, looking toward the camera, and that the iris is centered. NISTIR 8207 adds the operational reason this gate exists: accuracy is dominated by the small fraction of samples with serious quality problems, and it gives motion blur and eyelid occlusion as examples. IREX II, described on the program page, was the earlier evaluation of automated quality metrics.

Segmentation and the on-card image. Preparing the card record is not a trivial crop. SP 800-76-2 says production of the on-card record requires iris detection and localization. The on-card profile is a cropped, masked, and centered image: eyelids and sclera are masked, the iris is centered, and the record is compressed so it can fit the card. An earlier polar encoding was removed from the second-generation image standard because interoperability depended on finding the iris and pupil centers correctly. That is the segmentation step. It is not a published map of IrisCode bits.

Template creation and IrisCode match. IREX IX Part One defines one-to-one mode as a claimed identity tested by comparing two templates, and one-to-many mode as a search of an authentication template against enrolled templates. For John Daugman's IrisCode, the report says the dissimilarity score is also known as a Hamming distance, and an identity claim is accepted when that score is below or equal to a preset decision threshold. The report does not set that threshold for you, and it does not describe a bit grid. PIV still stores the standardized image, not this proprietary template. The matcher box in the diagram is the IREX comparison step. The card box is the image SP 800-76-2 actually puts on the credential.

Where the image lives. On the card, the profile is the cropped and masked image type, with a recommended size of about 3 kilobytes for a single iris so the record, its header, and its signature fit the card container. Off the card, if the agency elects to retain images, the profile is a 640 by 480 image, PNG or raw, again under ISO/IEC 19794-6:2011, wrapped so integrity protection is required and encryption is allowed. Those are different records. Retention is optional. Putting an image on the card does not by itself create an off-card gallery.

Request or data path, step by step

Capture. The camera illuminates the iris in the near infrared and produces a rectilinear image. If the detected iris diameter falls outside the 160 to 280 pixel range SP 800-76-2 requires for PIV images, the specification says recapture should be attempted at least twice. Interpolation to enlarge an iris is not allowed unless the physical iris is actually below 9 millimetres. That rule is a size check on the image, not a matcher threshold.

Quality gate. Remove glasses and the contact-lens cases the specification names. Inspect the frame. Run the one-to-one check against the image destined for the card. A failed check returns to capture. It does not open a gallery search.

Template creation. For the recognition algorithms IREX IX measures, a comparable template is built from the sample. Part One reports creation time and comparison time separately, on a single processing core in that test, and notes that adding compute would reduce creation time. Treat any duration in that report as a result for the submitted algorithms and that test machine, not as a latency budget for a gate or a phone.

1:1 compare. Two templates are compared to test one claimed identity. SP 800-76-2 describes PIV biometric authentication, when a card is presented, as one-to-one. The on-card image is the record a later capture is compared with when the transaction is a one-to-one check against the card.

1:N gallery. An authentication template is searched across enrolled templates. IREX IX measures that search separately from one-to-one comparison, and it says a speed-accuracy tradeoff is less obvious in the one-to-many results than in one-to-one comparison. SP 800-76-2's warning still applies: a compact image specified for a card or an e-passport is a poor substitute for enrollment samples in a one-to-many, single-factor traveler program. Gallery size and threshold choices change identification outcomes. This article does not copy false-match or false-non-match figures out of the report and treat them as a product guarantee.

Retention decision. If policy keeps an image off the card, store the off-card profile, with integrity protection. If policy does not, the specification does not demand a second copy. Either way, do not assume the proprietary template IREX times is the record on the card.

The diagram: labeled boxes and failure or isolation edges

• NIR camera to quality gate. Visible-light capture is out of scope for the PIV iris camera. A sample that fails the one-to-one check against the card image, or fails the operator's open-eye and blur check, goes back to capture.
• Quality gate to template creation. Only a sample that passes quality control is turned into the comparison template IREX measures. Part One does not define the segmentation algorithm. It schedules segmentation across wavelengths as the next report.
• Matcher, two exits. One exit is a 1:1 compare of two templates. The other is a 1:N search of an enrolled set. There is no third box for a bit layout.
• Image placement, isolated from the matcher score. On-card storage uses the cropped, masked, centered profile. Off-card retention is a separate optional profile. No arrow makes retention mandatory, and no arrow copies the card image into a one-to-many enrollment set.

What the source does not claim

NISTIR 8207 is an evaluation on sequestered operational images, not a certification of a camera fleet and not a published IrisCode bit map. It names Hamming distance as the dissimilarity score for Daugman's IrisCode and says acceptance uses a preset threshold. It does not print one threshold you can copy into a product. It reports template creation time and match time for the algorithms that were submitted. Those times are not a service-level target.

SP 800-76-2 profiles PIV images and minimum tests for record generators and matchers. It does not require every commercial system to store a raw raster, and it does not forbid retention either. The sentence about e-passports is a warning against reusing the compressed card-style image as one-to-many enrollment, not a design for a border system.

FAQ

Does SP 800-76-2 require an agency to keep an iris image off the PIV card?

No. The specification neither requires nor precludes retaining iris images. If an agency does retain them, they must use the off-card profile of ISO/IEC 19794-6:2011, with a header that requires integrity protection and allows encryption. Images placed on the card follow a separate cropped, masked, and centered profile.

What speed does IREX IX Part One measure?

It measures the time to create a template from an iris sample and the time to compare or search templates. For one-to-one matching it says comparison is nearly instantaneous relative to template creation, so creation time matters more for verification throughput. It also says the next report will investigate how well algorithms segment and compare samples captured from visible light through the infrared. It does not publish an IrisCode bit layout or a single Hamming threshold for every matcher.

How do one-to-one and one-to-many iris comparison differ?

One-to-one comparison tests a claimed identity by comparing two templates. One-to-many comparison searches an authentication template against a database of enrolled templates. SP 800-76-2 notes that iris recognition has been used for both, and that copying the compressed iris images specified for a card or an e-passport into the enrollment set of a one-to-many single-factor program would be technically suboptimal.

Conclusion

Draw the iris path as NIR capture, a quality check that can send the subject back to the camera, template creation, and then either a 1:1 compare or a 1:N search. Keep the PIV image decision in its own box: a cropped image on the card, and an optional larger image retained off the card under the retention profile. Use IREX IX when you talk about creation time versus match time, and about segmentation as the follow-on study. Use SP 800-76-2 when you talk about which image is allowed to exist. Do not draw an IrisCode, and do not treat a number from the evaluation as your operating threshold. More architecture diagrams are on the ByteDiagram blog.