Imperial College London

MSc Computing Science Group Project

Iris Recognition
Authors: Michael Boyd Dragos Carmaciu Francis Giannaros Thomas Payne William Snell

Supervisor: Professor Duncan Gillies

March 19, 2010

Abstract Iris Recognition is a rapidly expanding method of biometric authentication that uses pattern-recognition techniques on images of irides to uniquely identify an individual. Algorithms produced by Professor John Daugman [1] have proven to be increasingly accurate and reliable after over 200 billion comparisons [2]. The aim of this group project is to implement a working prototype of the techniques and methods used for iris recognition, and to test these methods on a database of irides provided by the Chinese Academy of Sciences Institute of Automation (CASIA) [3], which consists of 756 images of irides from 108 individuals.

Acknowledgements The authors would like to take this opportunity to thank their supervisor, Professor Duncan Gillies, for his constant encouragement and regular feedback on a project that was enjoyable, challenging and intriguing from start to nish. A This report was typeset using L TEX.

Contents
1 Introduction 2 Specication 2.1 Minimum Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2 Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 Methodology 3.1 Iris Location . . . . . . . 3.2 Encoding the Iris . . . . 3.3 Comparisons . . . . . . . 3.4 Graphical User Interface 4 Final Results 5 Conclusions 5.1 Final Product . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.2 Auto Detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.3 Source Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 Future Work 6.1 Otsu Thresholding for Iris/Sclera Separation 6.2 Eyelashes . . . . . . . . . . . . . . . . . . . 6.3 Eyelids . . . . . . . . . . . . . . . . . . . . . 6.4 Application Format . . . . . . . . . . . . . . A Division of Work B Logbook 1 2 2 2 3 3 9 11 12 15 17 17 17 18 19 19 20 20 20 22 25

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

Chapter 1 Introduction
Security and the authentication of individuals is necessary for many dierent areas of our lives, with most people having to authenticate their identity on a daily basis; examples include ATMs, secure access to buildings, and international travel. Biometric identication provides a valid alternative to traditional authentication mechanisms such as ID cards and passwords, whilst overcoming many of the shortfalls of these methods; it is possible to identify an individual based on who they are rather than what they possess or what they remember [4]. Iris recognition is a particular type of biometric system that can be used to reliably indentify a person by analysing the patterns found in the iris. The iris is so reliable as a form of identication because of the uniqueness of its pattern. Although there is a genetic inuence, particularly on the iris colour, the iris develops through folding of the tissue membrane and then degeneration (to create the pupil opening) which results in a random and unique iris [5]. In comparison to other visual recognition techniques, the iris has a great advantage in that there is huge variability of the pattern between individuals, meaning that large databases can be searched without nding any false matches [1]. This means that irides can be used to identify individuals rather than just conrm their given identity; a property that would be useful in a situation such as border control, where it might be important to not just show that an individual is not who they say they are but also to show exactly who they are. The objective of this project was to produce a working prototype program that functions as an iris recognition tool using the algorithms described by Professor John Daugman [1] and other techniques in order to implement this in an accurate and useful way that is also user-friendly. Commercial iris recognition systems are available that implement similar algorithms to these; however, there does seem to be an absence of open source implementations. This is the hole that this project sets out to ll: providing a fast, usable program that can easily be extended.

Chapter 2 Specication
2.1 Minimum Requirements

At the outset of this project, some key tasks were identied that needed to be carried out to full the aim of creating a working prototype of an iris recognition system. The rst task was to read in an image of an eye and display this on screen. From this stage the iris then needs to be isolated from the rest of the image; to do this accurately the pupil, iris, and eyelids all need to be identied. This isolation was originally specied to be carried out manually by the user by clicking points on the image. The next task for the program was to calculate features of the iris pattern using the algorithms described by Professor John Daugman[1]. The iris bitcodes that are obtained from this can then be used to compare against a database of other such bitcodes to nd the identity of the individual.

2.2

Extensions

A number of extensions to these requirements were also proposed in order to increase the eectiveness of the application if time permitted. The most desirable of these was the implementation of a robust method for the automatic detection and isolation of the iris; this would have the eect of reducing the need for user input and hence reduce the margin for error resulting from this to potentially improve the applications ability to successfully identify an individual. Other features that would also potentially improve the match rate include locating and appropriately dealing with specular highlights in the image that can obviously alter the iris pattern that is visible in the image. This would allow the application to mask these areas of the image and so produce a more accurate encoding pattern. Along the lines of increased eciency in the application, it was noted that methods would need to be investigated to ensure that nding a bitcode match in increasingly large databases remains fast and does not become a bottleneck for the application. Other potential extensions include an investigation into other possible methods for iris recognition. In particular, analysing whether the Gaussian wave and its dierential are sucient for encoding a unique bitcode, so that the sinusoidal waves are no longer required.

Chapter 3 Methodology
To achieve automated iris recognition, there are three main tasks: rst we must locate the iris in a given image. Secondly, it is necessary to encode the iris information into a format which is amenable to calculation and computation, for example a binary string. Finally, the data must be storable, to load and compare these encodings. The decision was made to use C++ with the Qt framework for this project. C++ is extremely fast and exible for the large amount of calculations that need to be performed for each iris. In the same vein, Qt is a comprehensive and well-established C++ toolkit which provides a large amount of classes for producing elegant user interfaces. In addition to this, it has several classes such as QPixmap and QImage for manipulating and loading images easily. Qt is also a cross-platform toolkit, so the application will run on Linux, Windows, and Mac desktops, adopting the operating systems native toolkit and giving it an integrated feel on all platforms.

3.1

Iris Location

When locating the iris there are two potential options. The software could require the user to select points on the image, which is both reliable and fairly accurate, however it is also time consuming and implausible for any real-world application. The other option is for the software to auto-detect the iris within the image. This process is computationally complex and introduces a source of error due to the inherent complexities of computer vision. However, as the software will then require less user interaction it is a major step towards producing a system which is suitable for real-world deployment, and thus became a priority for extending the program specication. Locating the iris is not a trivial task since its intensity is close to that of the sclera1 and is often obscured by eyelashes and eyelids. However the pupil, due to its regular size and uniform dark shade, is relatively easy to locate. The pupil and iris can be approximated as concentric and this provides a reliable entry point for autodetection.
1

The white part of the eye.

3.1.1

Pupil

The pupils intensity and location are fairly consistent in most images and so it lends itself well to auto-detection. Detection of the pupil can be carried out by: removing noise by applying a median blur, thresholding the image to obtain the pupil, performing edge detection to obtain the pupil boundary and then identifying circles. A median lter is a kernel based, convolution lter which blurs an image by setting a pixel value to the median of itself with its neighbours. A na ve approach to applying a median lter would be to simply nd the median for a given area around each pixel by sorting an array and nding the median to replace the current pixel with. This could be implemented with a sorting algorithm which would have runtime O(n log n) on average. However, since the software requires several median blurs on dierent images a more ecient solution is required. For an improved algorithm we consult Perreaults paper [6], which describes an algorithm to create a median lter in linear time. The process (see algorithm 1) involves constructing individual column histograms and combining them to form histograms centred around a pixel, known as a kernel histogram. The signicant speed increase comes from the way in which the column histograms are updated and combined. For each pixel we remove an old column histogram from the kernel, shift a new column histogram down one pixel so it is centred on the required row and then add this new histogram to the kernel histogram. While this radically reduces the number of operations which need to be performed for each pixel, there is an initialisation step for each row which has runtime linear in the size of the kernel histogram O(r). This enabled the entire median lter to be applied in a matter of milliseconds. Algorithm 1 Median ltering algorithm as proposed in [6] Input: Image X of size m n, kernel radius r. Output: Image Y of size m n. Initialise each column histogram h0 , . . . , hn1 as if centred on row 1. for i = 1 to m do Shift the rst r column histograms h0 , . . . , hr1 down 1 pixel. Combine these r column histograms to form the kernel histogram H . for j = 1 to n do Set pixel Yi,j equal to the median of H . Shift column histogram hj +r down 1 pixel. Remove column histogram hj r1 . Add column histogram hj +r . end for end for The overall eect of the median blur is to reduce the noise and pixel intensity complexity of the iris image without perturbing the edge delity of the original image. This results in a stronger clustering of pixel values in the resultant pixel data histogram; this permits a largely noise-free, dynamic analysis of features which occupy discrete pixel ranges, such as the pupil (see gure 3.2). Upon application of a dynamic threshold to our median blurred image the leftmost image in gure 3.1.1 is obtained. The location of the pupil is well dened, and edge 4

Figure 3.1: Image before and after a median lter.

Figure 3.2: Histogram generated in the application following a median blur of a database image. Note the distinct, left-most (darkest pixel values) peak as a typical pupils pixel signature on the image. detection can extract this information to form a single bit depth image which can be searched for circles. The Sobel lter is an edge detection technique which calculates the gradients (in both the x and y direction) of the image intensity for each pixel and then combines them to give a gradient magnitude. This indicates how sharp the boundary is, which is itself an indication of whether an edge is present. As can be seen in 3.3 the result of this process of ltering is a circular artifact denoting the extremeties of the pupil in the image. This data requires further analysis for the presence of circular artifacts to acquire a best-t representation of the potentially elliptical pupil. The Hough Transform is implemented to locate the pupil (and subsequently the iris). Given a regular curve in this case a circle and a suitable range of parameters x

Figure 3.3: Thresholded image before and after edge detection with a 2D Sobel convolution lter. 5

Figure 3.4: Hough transform solution for a circle (red), given edge detected pupil image. centre, y centre and radius the generalised Hough transform can query individual pixels in an image for their contribution to a globally consistent solution for any parameters within the valid range. Due to the high computational complexity of the Hough transform technique (the parameter space for a simple circle is in three dimensions and depending on valid ranges this can quickly grow to millions of computations) and previous considerations for application performance, a number of elements were streamlined to accelerate the computation. Thresholding the input image has the inherent benet of changing the virtual bitdepth of the image to 1 (black or white). Furthermore, the implemented algorithm saves time by only operating on black pixels a greyscale implementation would signicantly add to the processing time. Additionally a search on the threshold result (gure 3.1.1) gives condent parameter estimations for centre and radius which can be used to constrain and guide the Hough algorithm. As can be seen in gure 3.4, this process gives fast, accurate and reliable solutions for circular artefacts in the thresholded and edge detected pupil image. The basis of iris auto-detection relies on this process.

3.1.2

Iris

Once we have the location of the pupil clearly dened, the complexity of locating the iris is somewhat reduced due to the relative concentricity of the pupil and iris. In contrast to pupil detection, eciently locating the iris is somewhat more complicated due to (i) the obstruction of the iris by the eyelids for most eyes, (ii) its irregular pattern and (iii) because of the relative similarity with the iris boundary and the sclera. Nevertheless, following a similar method to that of locating the pupil generally provides good results. Again, a median lter is applied to the original image in order to remove noise from the image and to strengthen the clustering in the pixel histogram. The resultant histogram is used to identify a point that can be used to threshold the image to produce an image similar to gure 3.5. The method involves nding the peaks of the histogram (excluding the left-most peak that represents the pupil) and choosing a treshold value between these points. Although not always optimum, this method generally creates an image that the Hough Transform can use to nd an approximate match for the iris; other, potentially better, methods for 6

Figure 3.5: An example of an image that is obtained by intelligently thresholding the original input image and then using Sobel to edge detect. This image represents the data that is used to locate the iris; the data is used by the Hough Transform to decide on a best-t circle to represent the location of the iris. A rough semi-circle can be made out by the human eye; this is what allows the Hough Transform to accurately locate the iris. achieving this threshold are discussed in the future work section (6). The Hough transform is very ecient for the task of nding the iris from an image such as this because it is resilient to noise and performs well even when a large amount of the circle is hidden. For example, when two eyelids are covering a large portion of the iris, such as in gure 3.6. This provides us with a circle that denes the iris, although portions of this are still obscured by the eyelids, meaning that these also need to be dened.

3.1.3

Eyelids

We note that an image of an eye roughly has three intensities, from darkest to lightest: pupil, iris and sclera, and eyelids. Hence a suitable thresholding method should be able to separate the eyelids from the rest of the image. Otsu gives a method in [7] for appropriately thresholding grey level images; the algorithm works as follows. Assume we have an image with L possible intensities for each pixel and ni is the number of pixels of intensity i. We rst normalize the histogram into a probability distribution, that is pi = ni / L i=1 ni . We assume that we threshold the image at level k into two classes, C0 containing levels less than or equal to k and C1 containing the rest. We then dene
k k

(k ) :=
i=1

pi and (k ) :=
i=1

ipi ,

which are the probability of a pixel picked at random being in C0 and the expected (mean) intensity for C0 respectively. It is clear to see that that 1 (k ) is the probability of a pixel being in C1 and (L) is the mean intensity of the entire image. We then calculate [(L) (k ) (k )]2 , = (k )[1 (k )
2

Figure 3.6: A demonstration of the results obtained by applying the Hough Transform to an image such as that in gure 3.5. The chosen circle is shown in red, which is an average of all of the circles with the maximum number of votes (in green). The blue circles represent those with the second most votes.

Figure 3.7: Image before and after a median blur and Otsu threshold. which is shown to be measure of the variance between the two classes C0 and C1 by Otsu in [7]. We calculate this between-class variance for each k and nally threshold on the k where 2 maximized. To get any useful information from Otsu thresholding we must rst ignore the pupil to ensure that the result does not only consist of two classes (the pupil and then everything else). Once we have ignored the pupil in class calculations we nd that Otsu thresholding gives us two classes: one containing the iris, sclera and the pupil (since it has lowest intensity), and the other class containing the eyelids, see gure 3.7. With the iris located within the image we must now begin the task of extracting information from it.

Figure 3.8: The four phase quadrants and the corresponding bit sequences they represent

3.2

Encoding the Iris

The iris is encoded to a unique set of 2048 bits which serve as the fundamental identication of that persons particular iris. These iris bit codes can be stored in a database and then compared to uniquely identify a person. The size of 2048 is suciently large to store the data of several particular lters on most angles of the iris, while also being suciently small to be easily stored in a database and manipulated quickly. We wish to extract phase information from the iris as opposed to amplitude information since phase information is not skewed by pupil deformation. We use Gabor lters to extract this phase information as suggested by Daugman [1]. The Gabor lter is an application of the Gabor wavelet (see equation 3.1) [1]. This will return two bits depending on which quadrant (see gure 3.8) the normalised resulting imaginary number from this lies in. This equation can be simplied for computation by considering it as a combination of two lters: one lter representing the real part of the integral and the other representing the imaginary part. Each of these lters consist of a combination of a Gaussian and a sinusoidal lter (see gure 3.9). The parameters , and are then tuned by constraining the Gaussian lter to range over one standard deviation and the sinusoidal lter to range from to .
2 /2 2 / 2

h{Re,Im} = sgn{Re,Im}

I (, )ei(0 ) e(r0 )

e(0 )

dd

(3.1)

3.2.1

Filter Placement and Size

The Gabor lters need to be placed so that they take account for a large enough range of data without missing out the ne detail within the iris. As we require 2 bits to uniquely identify each quadrature, we have the additional constraint that 1024 lters must be used, allowing a manageable bit code length of 256B for each iris which can be split into sections of 4B. To simplify the calculations involved in applying the lters to the unwrapped iris they can also be considered to all be placed at a uniform rotation of 0. Since it can be observed that there is consistent amounts of information at points varying 9

Figure 3.9: The real (left) and imaginary (right) parts of the Gabor wavelets in the angular direction in the iris, it is also a good idea to place the lters uniformly in this direction. In this implementation 256 angular directions were considered because it divides our required number of lters evenly and includes a large spread of data across the iris. However, in many cases, in the radial direction there is more distinct information observed closer to the pupil. To include the more important data close to the pupil the lters can be positioned so that a larger proportion of them have their centres in this range. With the 256 angular directions there are 4 radial lter locations left to position. These can be placed uniformly between the bottom of the iris and half-way across the iris to allow the data around the pupil to be explored. Finally, to make sure that lters are always large enough to represent enough data, the constraint that a lter centre cannot be placed on the 3 pixels nearest the top and bottom of the image is added. This means that useless lters of sizes 1 and 3 will never be included when encoding the iris, and we avoid including additional pupil debris that may have been incorporated into the iris section. The nal set of lter locations across an unwrapped iris is represented in gure 3.10.

Figure 3.10: Filter positions for an iris of radius 40 between =0 and =45

10

Figure 3.11: Two schemes for lter sizes and placements at a xed point in the angular direction in an iris of radius 40. Left: maximum size lter placed. Right: lter sizes capped at 25 The nal consideration with the lters is their size. Two schemes for doing this are demonstrated in gure 3.11. The rst (left) aims to position the largest possible lter at every lter location. This means that the lters full one of the original requirements; that the lters should capture as much information as they can. The issue which this scheme suers from is that the lters with their centres in the middle of the iris can be so large that they arent really able to represent some of the ner detail in the image. The second scheme (right) tackles this problem by capping all lters in the image at a maximum size. This maximum size can be tuned in the implementation to get more distinct bitcodes, which is why it is favourable and consequently the one we use.

3.3

Comparisons

Iris encodings can be compared by computing a Hamming distance between them. The Hamming distance between two iris codes is calculated as given in [1]. Assume we have two iris codes, codeA and codeB , with corresponding bit masks, maskA and maskB (where a 0 in the bit mask corresponds to a bad bit in that position in the iris code). Then we calculate the hamming distance H as: H= (codeA codeB ) maskA maskB . maskA maskB

Where is the bitwise XOR operator and is the bitwise AND operator. We can see that the numerator will be the number of dierences between the mutually non-bad bits of codeA and codeB and that the denominator will be the number of mutually non-bad bits. However an astute reader may observe that this measure can fail if there is an exceedingly low number of mutually non-bad bits causing the numerator to be zero even though there may actually be large dierences between codeA and codeB . However, this is a simple case to handle and will rarely occur when comparing iris images. This comparison is performed for various shifts in the codes to check for rotation of the image, as it is very possible that a subjects eye in the image is rotated if the camera or their head is tilted slightly.

11

Figure 3.12: The application in Linux with the Open File view. This statistical independence test is the key to iris recognition. It provides suciently many degrees-of-freedom to fail in every case where the iris bitcodes of two dierent eyes are compared, but uniquely passed when the same iris is compared with itself.

3.3.1

Iris Database

Since we are able to generate the code and the iris mask directly, these are the only two items that are required to be stored in a database, the image bitmaps themselves are no longer required. We are currently using a basic text le as our database as this was simple to implement and for the small number of eyes we have as test subjects this is perfectly adequate and proves to be able to compare iris bitcodes extremely fast.

3.4

Graphical User Interface

Since the software was built in Qt, a cross-platform toolkit, the nal product runs on Linux, Windows, and Mac desktops, adopting the operating systems native toolkit and giving it an integrated feel on all platforms. Usability is an important consideration when creating an application, and throughout development the aim was to provide a clean and intuitive interface whilst still providing full usability and advanced features. The key intellectual challenges for the user interface have been primarily to provide a straight-forward and informative access point for the user, but also to provide relevant extra data when required with a fall-back mechanism for diculties in auto-detection.

12

Figure 3.13: Windows and Mac OS X.

Figure 3.14: Application with heatmap tab.

13

The nal product includes relevant data and feedback behaviour such as histogram information from the image to allow the advanced user to track-down and diagnose autodetection failures. This information is placed into a tabbed interface below the primary image so that it is easily accessible without encroaching on our clean interface which allows the average user point-and-click renement (if necessary) of the iris parameters with realtime visual feedback without overloading them with this more advanced information.

14

Chapter 4 Final Results

With the batch command line option of the application, it is possible to process a large amount of images of eyes. Using this option, 108 images of eyes from the CASIA database were loaded into the application; the pupil, iris and eyelids were auto-detected to generate a bitcode and store it in the database. These were then compared to an alternative image of each eye to check for matches. To further test primarily for false matches, the rst three images of each eye were loaded into the database, and then compared to a fourth image for each eye. As there were originally three images for each eye, and then a comparison was performed on all of the extra 108 images, roughly 35,000 iris comparisons took place ((108 3) 108). Our results of these tests are as follows: 0 false matches in 35,000 comparisons 70% (75 out of 108) match rate with Professor Daugmans suggested 0.32 Hamming distance. The complete lack of any false matches and the incredibly high match rate are a testament to the robustness and feasibility of an iris recognition system. The tests have suggested that in virtually any case where the iris boundary is correctly located, the iris should be correctly identied. As a roughly 70% match rate was achieved for the iris location, this percentage has, as predicted, been reected in the overall match rate in the database of images. Similarly to Daugman, we can also observe that the Hamming distances produced by comparing dierent irides tends to follow a binomial distribution, with a mean around 0.45; see gure 4.1. If time had permitted, it would have been benecial to decrease the reliance on the batch mode for the testing phase and process the images manually, in order to ensure that each iris was located correctly in the image. This would enable a separation in our results of the success of the auto-detection and of the matching process. Another appealing extension to the testing phase would have involved setting up a high resolution (and preferably infra-red) camera to appropriately test the applications ability to identify an individual outside of the CASIA database. This would also have had the benet of being able to emulate a real-world use of the application far more accurately. 15

Figure 4.1: The distribution of Hamming distances for non-matching irides with one run of all the irides in the database. The results resemble a binomial distribution with = 0.45 and = 0.024.

16

Chapter 5 Conclusions
5.1 Final Product

The nal prototype is a functional iris detection application, which provides the user with visual prompts and feedback and also some supplementary information about the loaded image for debugging purposes. The nal product can read in an 8-bit indexed, greyscale image and will attempt to automatically best-t parameters for the location of the pupil, iris and eyelids with consideration for specular highlights and padding for eyelash interference. The entire auto-detection process takes a matter of milliseconds. The user may choose to manually enter points to specify all of these locations; if the user does, he or she will receive appropriate visual feedback cues for repositioning elements in a manner intuitive to any casual computer user. From this point, the user input is complete and the application will process the image data, unwrap the iris using polar co-ordinates and mask appropriate regions of the unwrapped iris based on the auto-detection sequence or user input. This information is then extracted using Gabor wavelet convolution lters and the nal output is a 2048-bit iris code containing phase information of the valid iris pixel data. The iris code is stored in a local, new line delimited text database if unique or the prototype reports that the code has already been located in the database and a successful match dialog is given.

5.2

Auto Detection

Pupil detection in the application works to a very high degree of accuracy in every seen case. The pupil has a fairly unique shade in comparison to the rest of the eye and its surrounding area; this enables an intelligent threshold to be carried out with information from the image histogram to isolate the pupil. This, unfortunately, is not a property shared by the iris, making it signicantly more dicult to isolate than the pupil. Currently the prototype makes an estimation of the location of the iris based on concentricity (a potential source of error) with the pupil, and assumes a detectable gradient ramp between the iris and the sclera. These complications hamper the accuracy of our current estimates and produce a successful detection rate on the CASIA database of

17

around 70%, though potential improvements to this method are suggested in future work (6). The prototype manages to detect the top edge of the eyelids in the vast majority of cases. With the small amount of padding added to accommodate the thickness of the top eyelid, it can be seen that, although not perfect, a very reasonable estimate of the eyelid boundary is found automatically.

5.3

Source Code

The source code is freely available under the GNU General Public Licence (GPL) from http://projectiris.co.uk.

18

Chapter 6 Future Work

Throughout development the focus was on producing a functioning piece of software capable of fast, consistent and reliable iris recognition. There are other possible routes for extension and exploration within this project. There are alternative ideas for the format of the application and unexplored avenues within auto-detection techniques.

6.1

Otsu Thresholding for Iris/Sclera Separation

As we have seen before, on average the iris has a lower intensity than the sclera. Hence it could potentially be benecial to explore the use of Otsu thresholding for separation of the iris and sclera. Similar to the methods implemented for eyelid detection, if we remove eyelids and pupil intensities from the Otsu thresholding process then we obtain the image shown in the right-hand image of gure 6.1. Although to the human eye this image looks to hold more information than the implemented technique (see gure 3.5) the image contains a large amount of noise and would require further ltering and renement to be useful. This would be the rst recommended route for extension since, during the testing phase, the software tended to fail recognition on images where it could not adequately locate the iris.

Figure 6.1: Image before and after an Otsu threshold.

19

Figure 6.2: The eyelashes have a relatively low intensity and the eyelash region has high variation in intensity.

6.2

Eyelashes

In some images eyelashes can obscure parts of the iris. Detection and removal (marking as bad bits) of eyelashes could potentially improve the detection rate. A method is given in [8] for eyelash detection. The method relies on two characteristics of eyelashes: rstly, that they have a relatively low intensity compared to surrounding features, and secondly that the eyelash regions have a large variation in intensity due to the thin shape of the eyelashes (see gure 6.2). The method uses these characteristics by combining a standard-deviation lter and a thresholding technique.

6.3

Eyelids

The implementation of eyelid detection is based on the region obtained from the thresholding technique, as we saw in gure 3.7. The system currently constructs a parabola from three points on the boundary of this region. Accuracy in eyelid detection could potentially be improved by using the Hough technique for parabolas. This again would allow more accurate marking of non-iris regions and hence improve overall recognition rate.

6.4

Application Format

Currently the system has a text le for storing iris encodings. This could be improved to mirror a real-world application deployment by interfacing with a database. Although due to the one-to-many searches involved with iris recognition database querying could potentially become a bottle neck. Another area worth exploring is implementing the software with a client/server architecture whereby the iris is encoded client side, and compared server side. Again, this more accurately mirrors real-world deployment of an iris recognition software. This would then require further investigation into security and encryption methods for the system.

20

Bibliography
[1] J. Daugman. How iris recognition works. IEEE Transactions on circuits and systems for video technology, 14(1):2130, 2004. [2] J. Daugman. New methods in iris recognition. IEEE Trans. Systems, Man, Cybernetics B, 37(1):11671175, 2007. [3] Center for biometrics and security research. IrisDatabase.htm. http://www.cbsr.ia.ac.cn/

[4] A.K. Jain, A. Ross, and S. Prabhakar. An Introduction to Biometric Recognition. Biometrics, 14(1), 2004. [5] NSTC Subcommittee on Biometrics. Iris recognition. http://biometrics.gov/ documents/irisrec.pdf/, 2006. [6] S. Perreault and P. Hebert. Median Filtering in Constant Time. IEEE Transactions on Image Processing, 16(9):23892394, 2007. [7] N. Otsu. A threshold selection method from gray-level histograms. Automatica, 11:285296, 1975. [8] T. Min and R. Park. Eyelid and eyelash detection method in the normalized iris image using the parabolic hough model and otsus thresholding method. Pattern Recognition Letters, 30(12):1138 1143, 2009. [9] J. Blanchette and M. Summereld. C++ GUI Programming with Qt 4. Prentice Hall PTR, Upper Saddle River, NJ, USA, second edition, 2008. [10] Bryan Lipinski. Iris recognition: Detecting the pupil. http://cnx.org/content/ m12487/1.4/, 2004. [11] Bryan Lipinski. Iris recognition: Detecting the iris. http://cnx.org/content/ m12489/1.3/, 2004. [12] Bryan Lipinski. Iris recognition: Unwrapping the iris. http://cnx.org/content/ m12492/1.3/, 2004. [13] M. Sonka, V. Hlavac, and R. Boyle. Image Processing, Analysis and Machine Vision. Thomson-Engineering, second edition, 1998. [14] R. Fisher, S. Perkins, A. Walker, and E. Wolfart. //homepages.inf.ed.ac.uk/rbf/HIPR2/hough.htm. 21 Hough transform. http:

Appendix A Division of Work

The group was initially divided into two parts: Dragos Carmaciu and Thomas Payne working on HCI and application-level decisions, and William Snell and Michael Boyd working on the technical implementation of the wavelets and associated processes. Francis Giannaros aided in delegation between the groups and worked specically on each side of the divide as required. To improve design quality and have a more resilient programming ow dynamic, we have frequently exercised paired programming throughout the project. As a consequence, a couple of people are frequently responsible for one feature. Further details are highlighted below.

Michael Boyd
Theoretical work on lters Implementing the Gaussian lters Producing the bitcode and mask Producing the heat mask Creating the parabolas for the eyelids Wrote report 2

Dragos Carmaciu
General user interface handling Threshold, median and Sobel lters Assigning points and generating circles Implementing the Hough transformation Pupil and iris edge detection Website development 22

 Created tabbed interface Wrote report 2

Francis Giannaros
General user interface Creating/implementing the parabolas for the eyelids Unwrapping the iris and generating the mask Assisting with the Hough transformation Text database adding/searching Making point locations adjustable Infrastructure (mercurial/website) creation/maintenance Removal of specular highlights / pupil bad-bits Eyelid detection implementation Wrote report 1, 2, 3

Thomas Payne
General user interface Unwrapping the iris Text database adding/searching User instruction/feedback system Pupil auto-detection Implemented threshold improvements Histogram smoothing Removal of specular highlights / pupil bad-bits Wrote report 2, 3

23

William Snell
Implementation of lter classes Implementation of Gabor wavelets Iris code comparison and rotation functions Linear time median lter Otsu thresholding Autodetection of eyelids via Otsu thresholding Wrote report 2, 3

24

Appendix B Logbook
Date 11/01/10 Length < 1 hour Summary Supervisor Meeting. Outlined requirements of the implementation. Discussed technical implementation of lters. 13/01/10 4 hours Group Meeting: Full attendance. Split into two teams: User Interface and Qt logistics team (Francis, Dragos and Thomas) and Technical Methods and Implementation Team (Michael and William). Test code for Hamming distances written. 18/01/10 < 1 hour Supervisor Meeting. First working prototype of the user interface displaying the loading and I/O funcionality of the basic system, including successful unwrapping of the iris to polar coordinates. Rened requirements. More technical details eshed out. Such as how to interpret Daugmans equations. Discussed the possibilites of generating lters with the dierentials of the Gaussian.

25

24/01/10

6 Hours

Group Meeting: Dragos, Thomas(partial - via webcam).

William,

Francis

and

Discussion regarding overall design. UML diagram rened, clear targets and deadlines set. Extensions such as auto-detection and full database integration considered. Re-factored the code, moving to the main source directory. Version control repository overhauled. Started using doxygen as a code commenting system. 25/01/10 < 1 hour Supervisor Meeting. Discussion of bit masks for eyelids and minimum requirements Prof. Gillies suggested researching the Hough transform for pupil detection. 28/01/10 4 Hours Group Meeting: Dragos, William, Francis and Michael (partial). Bit code generated for full size of the unwrapped iris. New UI integrated though incomplete. Considered retrieval and comparison operations for stored bitcodes. Micheal implemented code to produce heatmaps for the Gabor lters. 01/02/10 < 1 hour Supervisor Meeting. Demonstrated current revision, with latest UI. Discussed rst report and usefulness of current techniques in autodetection. Proposed new extension to implement a client/server mechanism to more accurately parallel a real-world application. Suggest improvements to UI (draggable points) and comparing shifted codes to compensate for rotation of the iris image.

26

08/02/10

< 1 hour

Supervisor Meeting. Demonstrated suggested improvements from previous weeks meeting (draggable points and code shifting).

15/02/10 21/02/10

< 1 hour 4 hours

Supervisor Meeting. Group Meeting: Dragos, William and Thomas. Work on report 2.

01/03/10

< 1 hour

Supervisor Meeting. Submitted report 2. Discussed nalisation of implementation of project. Discussed report 3.

08/03/10

< 1 hour

Supervisor Meeting. Received feedback on report 2; discussion on the style of the report. Suggestions for structural improvement made. Presented Hamming distance results; discussion on the similarity to Daugmans results, as a binomial distribution and a similar mean.

12/03/10

2 Hours

Group Meeting: William, Thomas. Structure of report 3 nalised.

15/03/10

< 1 hour

Supervisor Meeting. Discussed presentation: formulated outline, slide designs, demo methodology. Submitted draft of report 3.

18/03/10

3 hours

Group Meeting: Dragos, Francis and Thomas. Layout nalised for presentation.

27