ARLib: A C++ Augmented Reality Software Development Kit. Masters Thesis

Transcription

1 ARLib: A C++ Agmented Reality Software Deelopment Kit Masters Thesis Daniel Diggins MSc Compter Animation N.C.C.A Bornemoth Uniersity 5 September 5

2 Contents Introdction... 3 Preios and Crrent Work Image Segmentation Static Thresholding Dynamic Thresholding Featre Extraction Detecting the Corners Detecting the Marker Edges Cstom Corner Detector... 5 Marker Detection Detecting Markers D-to-D Projection Mappings Detection Problem Camera Orientation OpenGL Matrices Agmentation Using ARLib Installation The Hello World ARLib Application Rnning an ARLib Application Adjsting for Varying Lighting Conditions A Cstom ARLib Application Conclsion Recommendations...43 Appendices Appendix A Sample Ots Thresholding C++ code...45 Appendix B ARLib Application Command-Line Switches...46 Appendix C ARLib Application User-Interface Keys...47 Appendix D ARLib Configration File...48 Bibliography... 5

3 Introdction Compter Graphics is now a hge indstry. Compter Graphics (CG) applications are now sed across a wide range of indstries, inclding the more obios, sch as film and TV, manfactring and the defence sector, throgh to the less well known sch as specialist medical nits. CG has dominated the film indstry in recent years, with a greater proportion of moies being made that se compter generated special effects compared with those that contain none at all. Een moies that look as if they hae no special effects are likely to hae been digitally maniplated or enhanced in postprodction. From a director s point of iew, the se of compter graphics gies an endless creatie power, in what wold normally be an impossible shot to make. The downside is that the cg elements hae to be added after the scenes hae been shot, a process that can take many months to complete. It is not ntil the cg and lie action footage are merged together that the final reslt can be iewed and is hopeflly how the director enisaged it. The ability of compters to handle complex tasks has grown in parallel with their processing power and, in particlar, their ability to perform graphically intensie operations in real-time has improed so mch that preiosly impossible cg scenarios are now both feasible and commonplace. An exciting deelopment within the compter graphics arena is the field of Compter Vision. This is the ability of a compter to be able to recognise key points or extract specific featres from both still images and ideo footage. The se of Compter Vision for reading still images is sed in optical character recognition (ocr), where a compter is able to translate handwritten characters into compter text. Facial recognition is another commonly sed area of compter ision with still images. Howeer, recognition of moing images is a mch less deeloped field. One sch example is a police pedestrian monitor, sed to identify potential criminals by their nlawfl actiities [DAVIES 5]. Agmented Reality is a fast growing field within Compter Vision, where the se of compter graphics and lie footage has taken adantage of the adances in processing power. Agmented Reality is a process in which compter graphics are placed oer lie footage so that the cg elements look as if they are integral to the scene. The se of Agmented Reality cold, in the not too distant ftre, help directors to isalise how the compter graphic elements will interact in the scene dring the actally shooting. 3

4 This Masters Thesis describes the process of deeloping an Agmented Reality C++ deelopment kit called ARLib. The ARLib toolkit enables deelopers to create Agmented Applications qickly and easily. The applications work by looking for predefined black and white markers in the ideo footage and then placing compter graphics oer the top of them. The entire process has been broken down into separate modles, each one handling a specific task. As a means of placing this AR toolkit into context within the AR marketplace, Chapter details how AR applications are being sed today, and by whom. Chapters 3-6 coer how the ARLib was deeloped, and what models and methods were sed in its implementation. Chapter 3 describes the first stage of performing Agmented Reality by taking a color image and conerting it to black and white so that featres within it can be detected. Chapter 4 details the process of extracting sefl featres, ie; black and white markers, from the black and white image. Potential markers in an image are then frther analysed to determine whether it is a alid marker. This process is described in Chapter 5. The final stage of the Agmented Reality process inoles determining where the marker is in relation to the camera and is detailed in Chapter 6. Chapter 7 describes how to create applications sing ARLib. The C++ code for two working examples is detailed, which are inclded as part of ARLib. Finally, the conclsion and recommendations for frther deelopments are discssed in Chapter 8. 4

5 Preios and Crrent Work The Compter Vision Homepage [HUBER 5] proides a list of known compter ision research instittes from arond the world. At oer 3 in September 5, the nmber of entries in this list reeals jst how mch crrent interest and actiity there is in the sbject. A key aspect of Compter Vision is the ability of the application to identify known entities within an image. Some techniqes for performing compter ision se markers to aid in the recognition process whereas more recently markerless detection systems hae been deeloped [VACCHETTI et al 3], [ALLEZARD et al ] and [LEPETIT 4]. These markerless systems still reqire some knowledge abot the enironment. Some techniqes se a compter model of an object to se as a template, where lines and featres detected in the scene are matched against the model s shape. Other techniqes search for textres on objects. The application of Agmented Reality within the realms of Compter Vision is becoming more common and is now sed in many different fields, inclding medical, manfactring, military and isalisation. In particlar, fighter pilots hae been sing the application of agmented reality for many years to highlight the otside world in the form of head p displays. The Uniersity of North Carolina has researched into sing agmented reality in medicine [LIVINGSTON 998] as an aid for performing srgery, see figre.. Figre. Agmenting the internal organs dring srgery [LIVINGSTON 998]. 5

6 Another interesting example of Agmented Reality is an application that was deeloped to aid maintenance engineers who hae to repair a ariety of different eqipment [FEINER 993]. The system works by incorporating a camera into the engineer s goggles, which is linked to the AR software. The AR application is able to annotate what the engineer is seeing with sefl text and markers, to aid the engineer in his job, see figre.. Figre. Using Agmented Reality to Assist Maintenance Engineers A mndane bt essential task of qality control has been made easier by AR. Cstard creams are scanned for excess cream by an AR application and rejected if they fall otside of a predefined limit [DAVIS 5]. L'Ecole Polytechniqe Fédérale de Lasanne (EPFL) is a Swiss Uniersity that has a dedicated compter ision lab. Within this lab they hae deeloped many techniqes and applications in the realms of agmented reality, inclding realtime face tracking and 3D object tracking. Figre.3 Examples of EPFL s AR Work It is EPFL s 3D object tracking work that inspired the deelopment of the ARLib, and is described in detail in the following chapters. 6

7 3 Image Segmentation With most applications of compter ision, one of the primary and most important tasks is to isolate the foregrond from the backgrond objects. This task is often referred to as segmentation or thresholding and its performance in isolating elements will determine how sccessfl featres can be extracted from the image. 3. Static Thresholding This is the simplest and most basic form of segmentation that takes the grey ale of each pixel and conerts it to black or white, depending on a static threshold ale. Figre 3. shows the flow of the basic segmentation techniqe. Static Threshold Vale Figre 3. The basic segmentation techniqe Under ideal circmstances, where the lighting and camera parameters are constant, the basic segmentation techniqe will perform adeqately for most tasks. Howeer, most captred ideo images are ssceptible to noise and flctations in brightness and will therefore prodce arying leels of segmentation. To demonstrate this, figre 3. shows three images taken from a static ideo camera. Althogh the backgrond elements appear to be the same, by comparing the differences it can be seen in figre 3.3 that there were arying leels of brightness een in static regions. 7

8 Figre 3. Captred Video Images Figre 3.3 Varying brightness leels for static objects. When dealing with a single image, a static threshold ale will sffice, as the ale can be adjsted manally to get the desired segmented image. For ideo seqences, manal adjstment of the threshold ale is an impractical soltion as the images are being processed at a rate of 5 frames per second and therefore a techniqe was reqired that will atomatically adjst the threshold from frame to frame. 3. Dynamic Thresholding Also known as optimal thresholding, dynamic thresholding attempts to calclate the optimal threshold ale based on the grey leel ales of the image. Each frame of an image seqence is analysed and a threshold ale is calclated. This has the adantage that, if the lminance of the seqence is inconsistent between frames, then the dynamic threshold ale shold stabilise the problem. One of the more poplar approaches of dynamic thresholding is the Ots Method [NIXON and AGUADO ]. The Ots method works on the theory that there are two peaks in the grey ales of an image s histogram, one representing the 8

9 backgrond and the other representing either the foregrond or an object. Ots makes the assmption that the lowest mid-point between these two peaks is the optimal threshold ale, see figre 3.4. No. of points Backgrond Object Optimal threshold ale Brightness Figre 3.4 Ots optimal threshold position Color Image Grey leel histogram Dynamic threshold Figre 3.5 The Ots Thresholding techniqe The optimal threshold ale is calclated from the Ots method sing the following eqations: ω ( k) = k l= p( l) Eqation 3. 9

10 μ ( k) = k l= l p( l) Eqation 3. μ T N = max l= l p( l) Eqation 3.3 Using the preios eqations, the final calclation can be expressed as: σ ( k) = B ( μt ω( k) μ( k)) ω( k)( ω( k)) Eqation 3.4 Where: k = The histogram index position in the range to 55. p = The normalised histogram ale for the crrent index position. ω and μ = The first and second order cmlatie ales of the normalised histogram. μt = The total mean leel of the image. See Appendix A for example C++ implementation code for the Ots thresholding method. A final comparison of how Ots s algorithm performed against a static threshold is shown in figre 3.6. The first colmn shows the same scene with different lighting. The middle colmn shows the reslt after sing a static threshold ale and the third colmn shows the reslt with the Ots dynamic thresholding method. It can clearly be seen that the Ots method ot-performed the static method, as the markers were more prononced and also the noise cased from the shadows was greatly redced.

11 Same Scene / Different Lighting Static Thresholding Ots Thresholding Figre 3.6 Ots and static thresholding comparison.

12 4 Featre Extraction Featre extraction is a term sed for finding known elements within an image. These elements consist mainly of corners, lines, shapes and cres. The ARLib ses two dimensional sqare markers for its detection system, therefore the featres reqired were corners and edges. 4. Detecting the Corners There is a ariety of corner detection algorithms docmented in many textbooks and research papers. A commonly sed method is the Harris Corner Detector [HARRIS and STEPHENS 988]. The basic mechanism behind the Harris detector is that a small sqare template window is centred on a point in the image. The template window is then slightly shifted in arios directions and the aerage change in intensity is recorded. It is these changes in intensity that can indicate whether the template window is on a corner, see figre 4.. Figre 4. The Harris Corner Detector Althogh deemed to be the preferred method for detecting corners, it was estimated that the algorithm wold take too mch comptation time and wold hinder the real-time target of ARLib. Another common techniqe for detecting corners is known as the SUSAN Corner Detector [SMITH and BRADY 997]. This techniqe ses a circlar template mask which is placed oer eery pixel in the image. All pixels of a similar intensity to the central pixel are conted, and if the cont is less than half of the nmber of pixels in the template, then it is assmed a corner exists within the

13 circle. The actal location of the corner is indicated by performing a local minimm search within the template area, see figre 4.. Figre 4. The Ssan Corner Detector Initial prototyping and testing showed that the SUSAN algorithm was too slow at processing to be sed in a real-time application. Another corner detection algorithm that ses a circlar template is detailed in [EPFL 4] and is referred to as the Keypoint Detector. This techniqe differs from the SUSAN method in that only the pixels on the circmference of the template are analysed. The idea behind this techniqe is that if two diametrically opposed pixels hae a similar intensity to the central pixel, then the point is not a corner or featre point, see figre 4.3. Figre 4.3 The Keypoint Detector Becase of the way ideo images get digitised, some straight edges can be falsely recognised as corners. To oercome this problem, the neighboring cells on the circmference are also tested, see figre

14 Figre 4.4 Testing Neighboring Pixels in Keypoint Detector This algorithm was initially implemented in ARLib as it performs well and has no real noticeable affect on performance. Figre 4.5 shows some sample ideo images with highlighted corners. It can be seen that there appeared to be more corners indicated than were actally isible. This was de to noise cased by the segmentation process. Figre 4.5 Sample Images showing Keypoint Detector reslts. 4

15 4. Detecting the Marker Edges When a two dimensional sqare is iewed from any angle, its edges always remain straight, therefore if the for edges of the sqare can be detected, then its corners can also be calclated sing simple line intersection rotines. Since its inention in 96 by Pal Hogh, the Hogh transform method [DUDA and HART 97] has been the main techniqe sed for detecting lines within an image. The techniqe has been frther adanced to detect arbitrary shapes and is called the Generalised Hogh transform. The principle behind the Hogh transform is that there are an infinite nmber of lines that can pass throgh a single point. Howeer, if many collinear points are examined, then there is only one line that is common to all of them, see figre 4.6. It is this simple concept that is sed by the Hogh transform. Figre 4.6 The Hogh transform principle The original method for calclating the lines in the Hogh transform sed the slope-intercept eqation of: y = mx + c Eqation 4. Here a range of ales are sed for m and c to determine the lines for a particlar point (x,y). A major problem with sing the slope-intercept techniqe is that there is no way of knowing the range of ales to se for m and c. 5

16 Another techniqe was tried [DAVIS 5] that replaced the slope-intercept formla with one called the normal(θ,p) form: p = x cos( θ ) + y sin( θ ) Eqation 4. Using this formla, the lines were represented sing a sinsoidal wae. Points were plotted and mltiple hits in (θ, p) space indicated the presence of a line. Mltiple hits are highlighted in figre 4.7. Figre 4.7 Hogh Transform Sinsoidal Wae. The Hogh transform is a ery accrate techniqe for detecting lines within an image and fnctions well in noisy images too. It is, howeer, ery comptationally expensie and it is this reason that the Hogh transform was not sed in ARLib, as it cannot perform satisfactorily in a real-time scenario. With the combination of these two problems, ie; the Hogh transform not performing well and the corner detection not picking p all corners, another more efficient and reliable techniqe was needed. In [MALIK ], a completely different approach is sed to detect the corners and edges of the markers. The techniqe takes adantage of the fact that a marker comprises of a thick black border that is srronded by a white edge, see figre

17 Figre 4.8 Marker border It can be seen that a potential marker s bondary consists of a large connected region of black. To identify these regions, bonding boxes were created arond the black border. Looking for the black regions was a fairly simple process and the well known flood-fill techniqe [FOLEY et al 99] was sed. Dring the flood-fill process, the crrent bonding box was adjsted accordingly, see figre 4.9. Figre 4.9 Marker Bonding Box 7

18 The process is described in the following steps:. Starting at the bottom-left pixel of the image, each row is scanned ntil a black pixel is fond.. When a black pixel is fond, it is flagged as being processed and a bonding box is created arond it. 3. The for nprocessed neighboring pixels (aboe, below, left and right) are recrsiely scanned and processed and the extents of the bonding box are adjsted accordingly. 4. When no more black pixels can be fond dring the recrsie process, the crrent bonding box is added to the list of regions that may potentially contain a marker. 5. The scanning of rows contines ntil another nprocessed black pixel if fond, then steps to 4 are repeated. Figre 4. Example bonding boxes Becase there is noise in an image, the nmber of bonding boxes cold potentially be large, which wold hinder the performance of the detection process. The problem was easily oercome by applying some simple checks prior to each bonding box being added to the crrent list:. If the bonding boxes area is smaller than a predefined ale then it is deemed too small for processing and is exclded, see figre 4.a.. If the aspect ratio of the box is below a defined threshold, then the assmption is made that either the region does not contain a sqare or, if it did contain a sqare, then it is being iewed from too sharp an angle for a satisfactory detection, see figre 4.b. 8

19 (a) (b) Figre 4. Bonding Box Exclsions. (a) Area and (b) Aspect Ratio too small. Within each bonding box, a conex hll exists defined by the maximm extents of the black pixels. Becase the markers were sqare, then the conex hll shold contain for corners, see figre 4.. Figre 4. Bonding Box and Conex Hll can help identify corners. In [MALIK ], the assmption is made that a straight edge consists of approximately 5% black and 5% white pixels, while the corner has more than 5% white. To determine if an edge is a corner, a sqare template is placed centrally oer the edge pixel. A cont is then made of the black and white pixels and the for highest scoring conts are recorded. This entire corner detection process is inclded in the recrsie flood fill rotines. 9

20 The reslts from the corner detection process proed sccessfl for most cases in ARLib bt, like many corner detection rotines, they performed best when the image being processed contained a marker that was relatiely flat within the scene. Testing of this techniqe reealed that the corners were not detected when the marker was at an angle to the camera. This is becase, in some instances, a corner can look almost like a straight edge, see figre 4.3. Figre 4.3 Corners appearing as a straight edge. Frther research failed to reeal an alternatie corner techniqe that was capable of oercoming this problem therefore a cstom corner detection method was deised and implemented. 4.3 Cstom Corner Detector A techniqe was needed for ARLib that wold redce or een take away the assmptions of other corner detection rotines, in which a corner was determined by the ratio of black to white pixels. Becase the bonding box and oter edges of the black region within the box are known, a geometric soltion was possible. If a bonding box was scaled so that it forms a sqare, then this simplified the problem een frther, see figre 4.4.

21 Figre 4.4 Scaling bonding boxes to form a sqare. Once the bonding box was a sqare, the region corners cold be identified by working ot the frthest edge pixel from each of the bonding box corners, see figre 4.5. Figre 4.5 Detecting region corners from bonding boxes. Althogh this techniqe scceeded where preios detectors had failed i.e. it detected almost straight corners, this techniqe also had a problem with one particlar scenario. The corners were not detected correctly when the region within the bonding box formed a diamond shape. The problem was cased becase two of the corners in a diamond shape were the same distance from two of the bonding box corners, therefore only two corners were detected, see figre 4.6.

22 Figre 4.6 Two corners detected when diamond shape. A simple soltion to the problem was that, if for niqe corners were not detected sing the for corners of the bonding box, then for alternate points on the bonding box were sed. In this case, the mid-point of each of the corners were sed, see figre 4.7. By sing both sets of bonding box reference points, it garanteed that fors corners were always fond. Figre 4.7 Alternate bonding box points.

23 5 Marker Detection A D marker or fidcial, as it often called, mst be designed in sch a way that can be easily detected and be niqe enogh to be easily identified from other markers. Each marker mst also proide some kind of niqe binary code so that its ID can determined. Most markers se black and white designs, howeer in [EPFL 4] a techniqe is described that can be sed on detailed colored markers by sing classification trees for identification. In ARLib, black and white markers were sed and were based initially on the design in [LIU et al ], howeer as will be shown, this design did not perform well at acte angles. The marker design ses a 5x5 matrix where each cell represents a single bit in the marker s identification code, see figre 5.. P P P Orientation bit (4 bits) P Marker code bit ( bits) P P Parity code for rows (4 bits) P P P P Parity code for colmns (4 bits) Figre 5. 5x5 Matrix Design This marker represents a 5 bit binary code. of the bits are sed for the actal marker ID. The for corners are sed to determine the orientation and the remaining bits are sed for error detection. The error detection bits enable falsely detected markers to be rejected. 5. Detecting Markers Detecting a potential marker in ARLib inoled finding the location and color of each cell within the image. Becase the corners of the marker were aailable, the problem was simplified to mapping a sqare to a qadrilateral, see figre 5.. 3

24 Figre 5. Mapping a sqare to a qadrilateral. A soltion is described in [HECKBERT 995] and is commonly called projectie mapping. The techniqe is often sed in compter graphics when performing textre mapping. Projectie mappings can be performed in 3D, bt for the prposes of ARLib, D projections were sed. 5. D-to-D Projection Mappings The main principle behind projectie mapping is to take points from one plane and project them onto another. The general form for a projectie mapping is: x = a + b + c g + h + i Eqation 5. y = d + e + f g + h + i Eqation 5. 4

25 These preios two eqations can be represented in homogeneos form as: x y w = a d q g b e h c f i Eqation 5.3 By soling the aboe nknowns a-i, then by specifying and coordinates in the reference sqare, the x and y coordinates in the qadrilateral can be calclated, see figre y x Figre 5.3 / to x/y coordinates. In the homogeneos matrix of the problem, assming i=, then there are eight nknowns. By sing the for corners of the reference sqare and the for corners of the qadrilateral, then eight eqations can be defined. Each corner mapping prodces the following eqations: a + b + c a b k k x k = k + k + k k k k = k gk + hk Eqation 5.4 c x g x h x 5

26 6 k k k k k k k k k k k k y h y g y f e d h g f e d y = = Eqation 5.5 The eight eqations can be written sing an 8x8 system for k= to 3: = y y y y x x x x h g f e d c b a y y y y y y y y x x x x x x x x Eqation 5.6 The linear soltion can be soled sing Gassian elimination or by calclating the inerse of the 8x8 matrix. The downside of soling the aboe soltion is that it it comptationally expensie, howeer this soltion handles the mapping of a general qadrilateral to another qadrilateral. For ARLib, all that was reqired was to map a sqare to a qadrilateral therefore the soltion cold be simplified. Assming the sqare to qadrilateral ertex correspondences were as follows: x y x y x y x y x 3 y 3

27 Then the eight eqations cold be redced to: g = x y Δx Δy / Δx Δy Δx Δy h = Δx Δy x y Δx / Δy Δx Δy a + d = y y + gy = x x gx b + e = y3 y + hy = x3 x hx3 3 f = c = x y Where: Δ x = x x Δ y = y y Δ x = x3 x Δ y = y3 y x = x x + x x3 y y y + y = y3 Using the soled projection mapping eqation, it was now a straight forward task to determine the colors of the cells within the potential marker. The and coordinates were diided p into the nmber of colmns and rows and then the central position of each colmn and row was sed to locate the point in the image, see figre 5.4. Figre 5.4 Using central coordinates to locate xy coordinates. 7

28 5.3 Detection Problem The marker design described aboe had some problems in that detection performed poorly as the marker was moed away from the camera, which was amplified when the marker was also at an angle. After a ariety of experiments, the markers were redesigned to se large circles instead of sqare cells. The bits sed for error detection were remoed to allow more space for the larger circles, see figre 5.5. Using a circle improed marker detection, een at acte angles. Figre 5.5 New marker design sing circles. In the original marker design, all cells were scanned dring the detection process, whereas in the new design only cells that shold be definitely black or white were tested, for example figre 5.6 shows how the marker shown in figre 5.5 was defined. 8

29 Black Cells (, 3) (3, 3) (, 6) (7, 5) White Cells (5, ) (5, 3) (4, 6) Position (, ) is resered for orientation and is always black. Figre 5.6 New Marker definition Using this new approach, in the example aboe a maximm of 7 checks were needed. 9

30 6 Camera Orientation Once a marker had been sccessflly identified, the final step in the process was to determine the location of the marker in world space. This step was needed so that, when agmented graphics were rendered on top of the image, their scale and orientation wold match the detected marker. Determining the location of the marker in world space raised some interesting problems. The main one was that the only information aailable was the D coordinates of the reference sqare and the marker corners. There was also the added complexity in that the marker corners were sbjected to perspectie. In compter ision, this problem is referred to in many different ways, inclding Pose Estimation [ABIDI and CHANDRA 989], Camera Calibration [EASON et al 984] and Object Pose [LEPETIT 4]. Althogh referred to by different names, they each attempt to calclate the camera s internal and external parameters. The internal parameters, referred to as intrinsic parameters, are the focal lengths in the and direction. These two ales control the perspectie scaling of the agmented graphical objects. The external parameters, called extrinsic parameters, define the camera s location and orientation with respect to the marker. Many soltions assme that the focal length is already known and can be sbstitted into the releant eqations. ARToolkit [KATO 5] ses this approach and spplies the reqired tools for calibrating new cameras. For ARLib, a soltion was needed that wold be able to calclate the focal length atomatically. Sch a soltion is described in [MALIK ] in which the mapping of a planar marker in world space is mapped to the image plane, see figre 6.. It is this techniqe that was implemented in ARLib. 3

31 Image coordinates Camera coordinates Z Image plane Marker plane X Y Marker coordinates Figre 6. Planar Mapping from world to image space The D to D projection matrix calclated in section 4 were sed as the starting point. The techniqe, sed in ARLib, calls on the projection matrix ales to enable the focal lengths and orientation to be calclated atomatically. The general perspectie matrix is show in eqation 6.. This matrix was simplified and shown in eqation 6.. M = M int M ext = f r f r r3 f f r r r 3 f f r r r f f t t 3 t Eqation 6. H = f r f r r3 f f r r r 3 f f t t 3 t Eqation 6. 3

32 The following rles exist with the H matrix: r + r + r3 = r + r + r3 = r r + rr + r3r3 = Eqation 6.3 Eqation 6.4 Eqation 6.5 Using the rles in eqations 6.3 to 6.5, matrix H cold then be arranged into two eqations for soling f and f : f = h h h 3 h ( h 3 ( h h h ) h ) + h h h ( h 3 ( h h ) h3 ) Eqation 6.6 f = h h h 3 h ( h 3 ( h h h ) h ) + h h h ( h 3 ( h h ) h3 ) Eqation 6.7 Once the intrinsic ales hae been calclated from the aboe eqations, the remaining matrix ales cold be calclated sing the following eqations: r / = λh f r = λh / f r3 = rr3 r3r t = λh3 / f = λh f r = λh / f r3 = r3r rr3 t = λh3 / f 3 = λh 3 r3 = λh3 r33 = rr rr t3 = λh33 r / r Eqations 6.8 to 6.9 3

33 Where λ is a scaling factor and was calclated sing the following eqation: λ = h / f + h / f + h 3 Eqation OpenGL Matrices Once the ales had been calclated for f, f, r -r 33 and t -t 3, they cold then be sed to constrct the projection and model iew matrices. To create the projection matrix, the f and f ale were sed in the glfrstm fnction call. oid glfrstm(gldoble left, GLdoble right, GLdoble bottom, GLdoble top, GLdoble znear, GLdoble zfar) Typical ales sed in the glfrstm call were: right = imagewidth / f left = -right top = imageheight / f bottom = -top 33

34 The model iew matrix cold be constrcted from the remaining ales r -r 33 and t -t 3. The OpenGL fnction glloadmatrix ses matrices in colmn-major order, therefore the ales in ARLib were needed to be transposed from the matrix in eqations 6.8 to 6.9. The sixteen elements of the glloadmatrix parameter were set as follows: M[] = r M[4] = r M[8] = r3 M[] = M[] = r M[5] = r M[9] = r3 M[3] = M[] = r3 M[6] = r3 M[] = r33 M[4] = M[3] = t M[7] = t M[] = t3 M[5] = 6.3 Agmentation Once the OpenGL projection and model iew matrices had been initialised, then standard calls to Glt and OpenGL cold be made to render 3D objects. Any rendered objects wold be positioned and scaled on the marker with the scene. Becase there cold be mltiple markers within a particlar image, the whole process of calclating the camera intrinsic and extrinsic parameters needed to be calclated for each marker. The call to glfrstm and the loading of the model iew matrix also needed to be carried ot for each marker. Figre 6. Examples of agmented graphics. 34

35 7 Using ARLib The ARLib toolkit was written for both Windows and Linx. It consists of a single static library that is linked into the final Agmented Reality application. 7. Installation Before applications can be deeloped sing ARLib, the library needs to be bilt. Linx ARLib has the following external dependencies and they mst be installed prior to bilding the library: Libtiff Glt OpenGL Once these dependencies hae been installed, the ARLib static library can be bilt by typing Make. This process creates a file called libar.so in the lib folder. The file shold be moed either to another location, where it can be located by the linker, or alternatiely, the LD_LIBRARY_PATH can be pdated to inclde the lib folder path. Windows The Windows ersion of ARLib has the following dependencies: Libtiff Glt OpenGL DirectX 9 A Visal Stdio.NET C++ soltion file exists within the cc folder. This shold be loaded into Visal Stdio and bilt sing the Bild option. The file AR.lib will be created in the lib folder. 7. The Hello World ARLib Application To demonstrate the ease of se of ARLib, a basic application is described below. The basic application ses no cstom fnctionality, bt has instead all the 35

36 featres of all AR applications deeloped sing ARLib. Note that the sorce files for this application can be fond in the examples\basicapp folder. The first reqirement of the application is to inclde the releant header files: #inclde <arlib.h> #inclde <arapplication.h> #inclde <arappbase.h> These are the main header files. As more fnctionality of ARLib is sed, then additional files will need to be inclded. ARLib ses namespaces to grop fnctional areas. The top leel namespace is ARLib and within this namespace, there are the fnctional namespaces. sing namespace ARLib::Application; The final piece of code reqired is the main fnction. int main(int argc, char *arg[]) { ARApplication<ARAppBase> app(&argc, arg); app.rn(); } retrn ; The first line of code constrcts an ARApplication ariable called app. The ARApplication is a template class and therefore reqires a template argment. The argment in this case is the ARAppBase class name. This class proides all the base fnctionality for ARLib applications, inclding display and ser interface operations. This fnctionality can be changed by specifying a cstom class name as the template argment for ARApplication. Howeer, the cstom class mst be deried from ARAppBase. The next line of code calls the Rn method of the ARApplication. This method pts the application into Agmented Reality mode and will display the specified images or ideo with compter graphics oerlaid. Once the aboe code has been written, it can be bilt, bt before it can be exected, there are some additional reqirements. All ARLib applications are configred throgh external configration files, so some additional files will need to be created for the basic application. 36

37 Fortnately, template ersions of these files with defalt settings are spplied with the ARLib application. The folder config shold be copied to the location of the final application exectable. For details on how to modify the configration files, see Appendix D. 7.3 Rnning an ARLib Application Rnning the exectable withot any command-line argments will attempt to connect to a ideo sorce if one is aailable. In Linx this can be a webcam and in Windows this can either be a webcam or an IEEE394/firewire deice. If no ideo sorce is aailable, a pre-recorded seqence of.tif files can be iewed. To specify a seqence, the following command-line argment shold be sed: AppName -seqence <filename> The filename parameter shold be the first image to be sed in a nmbered seqence of files ie. footage..tif. As well as displaying seqences of files, a single image can also be iewed: AppName - image <filename> For a complete list of aailable command-line argments, see Appendix B. Once the application is rnning, there are nmeros keys that can be sed to control the fnctionality, see Appendix C for a complete list. Some of the more sefl keys are: Tab F Toggles between the display of messages and debg information. Toggles between fll screen and windowed mode. +/- Zoom in and ot. Space Pases the seqence. 7.4 Adjsting for Varying Lighting Conditions Althogh the rotines sed in ARLib attempt to minimise the amont of adjstments reqired, in arying lighting conditions, they will generally need to be tweaked to get the best reslts when detecting markers. The main adjstments that will need to be made are in the segmentation process, when the color image is conerted to black and white. The Ots thresholding techniqe described in Chapter 3 atomatically calclates the releant ales, bt does not 37

38 cater for the fact that the scene may either be brightly lit or is in low light. Therefore, the Ots ales need to be offset to cater for the crrent lighting. The following steps describe the process for adjsting the Ots thresholding ale:. Press the A key to display the alpha channel of the image. This makes the adjstment easier to see.. Press the U key to enter pdate mode. This will display each option that can be pdated at the top of the screen. Use the left and right arrow keys to naigate backwards and forwards throgh the aailable options. 3. Naigate to the option called Ots Threshold Offset and se the p and down arrow keys to adjst the ale ntil the markers are more prononced. The ideal setting is to hae more white than black, whilst ensring that the definition of the markers is as clear as possible. 4. Once the Ots ale has been adjsted press the escape key to exit pdate mode. 5. To switch back into color mode, press C. 7.5 A Cstom ARLib Application The basic fnctionality of ARLib spports the agmentation of static images or models. To add animated effects, a cstom implementation needs to be made. To demonstrate how to implement cstom code, the Clock example (fond in examples\clock folder) is described below. The Clock example comprises of three sorce files, one header file and two implementation files. clock.h The clock header file details the cstom fnctionality that will be proided by the Clock class. The first reqirement is to inclde the ARLib headers that will be sed: #inclde <arappbase.h> #inclde <arbondingbox.h> #inclde <arstring.h> 38

39 The next step is to define the class: class Clock : pblic ARLib::Application::ARAppBase All cstom implementations mst be deried from the ARAppBase class. The final stage of the class definition is to list the methods that are to be oerridden from the ARAppBase class: pblic: irtal oid OnGetApplicationTitle( ARLib::Utility::ARString &title ); irtal oid OnGetDetailHelp( ARLib::Utility::ARString &help ); irtal oid OnInit( int *argc, char *arg[] ); irtal oid OnInitDisplayAR(); irtal oid OnDisplayAR( ARLib::Detection::ARBondingBox *marker ); The details behind these methods will be described in the next section. clock.cpp First define the header files and namespaces that are to be sed: #inclde <clock.h> #inclde <armodels.h> #inclde <time.h> #inclde <sys/timeb.h> // specify the ARLib namespaces that are to be sed sing namespace ARLib::Application; sing namespace ARLib::Graphics; sing namespace ARLib::Utility; Next define the constant ariables that are to be sed by the cstom implementation: // define OpenGL color parameters const GLfloat ambientlight[] = {.3f,.3f,.3f,.f }; const GLfloat diffselight[] = {.7f,.7f,.7f,.f }; const GLfloat lightpos[] = {.f,.f, -.f,.f }; // Constants for loaded obj files #define OBJ_MINUTE_HAND #define OBJ_HOUR_HAND #define OBJ_SECOND_HAND 3 39

40 Now the cstom implementation code is created: oid Clock::OnGetApplicationTitle( ARString &title ) { // Set the title for the AR Application title = "Agmented Ticking Clock"; } This OnGetApplicationTitle method tells ARLib the name of the application. The title is sed in the application s main window title bar. oid Clock::OnGetDetailHelp( ARString &help ) { // Set the detail help for the application help = "An agmented reality application that displays a ticking clock."; } The OnGetDetailHelp method defines additional help text that will be displayed when the application is exected with the help switch ( -? or -help), oid Clock::OnInit( int *argc, char *arg[] ) { // Call base implementation ARAppBase::OnInit( argc, arg ); } // Load cstom models that will be sed ARModels::Add( "models/bighand.obj", OBJ_MINUTE_HAND ); ARModels::Add( "models/smallhand.obj", OBJ_HOUR_HAND ); ARModels::Add( "models/secondhand.obj", OBJ_SECOND_HAND ); The OnInit method is where all cstom initialisation is performed. The first command in the OnInit shold be to call the ARAppBase::OnInt method to allow defalt initialisation to be done. In this example, three additional models are to be loaded. 4

41 oid Clock::OnInitDisplayAR() { // Call base implementation ARAppBase::OnInitDisplayAR(); // Setp OpenGL lights gllightf( GL_LIGHT, GL_AMBIENT, ambientlight ); gllightf( GL_LIGHT, GL_DIFFUSE, diffselight ); gllightf( GL_LIGHT, GL_POSITION, lightpos ); glcolormaterial( GL_FRONT, GL_AMBIENT_AND_DIFFUSE ); } glenable( GL_LIGHTING ); glenable( GL_LIGHT ); glenable( GL_COLOR_MATERIAL ); The OnInitDisplayAR is called prior to displaying all the agmented graphics. Again as with the OnInit method, the ARAppBase implementation is called first, followed by the cstom code. In this example, the OpenGL lighting is being setp for the scene. oid Clock::OnDisplayAR( ARLib::Detection::ARBondingBox *marker ) { ARAppBase::OnDisplayAR( marker ); } // get the time time_t thetime; time( &thetime ); // break p the time sefl elements e.g. hors, mintes and seconds tm *flltime = localtime( &thetime ); // Draw the Second hand glpshmatrix(); glrotatef(-(6 * flltime->tm_sec),,,); ARModels::glDrawList( OBJ_SECOND_HAND ); glpopmatrix(); // Draw the Hor hand glpshmatrix(); glrotatef(-((3*flltime->tm_hor)+((flltime->tm_min/6.)*5)*6),,,); ARModels::glDrawList( OBJ_HOUR_HAND ); glpopmatrix(); // Draw the Minte hand glpshmatrix(); glrotatef(-(6*flltime->tm_min),,,); ARModels::glDrawList( OBJ_MINUTE_HAND ); glpopmatrix(); The final cstom method is OnDisplayAR. This method is called for each marker that is detected and reqires agmented graphics to be displayed. Here, the 4

42 ARAppBase code is exected, althogh this is optional. In the case of the Clock, a static clock model is associated with the markers, therefore the defalt implementation can handle the drawing of the static models. The rest of the code deals with drawing the clock s hor, minte and second hands. main.cpp The final sorce file in the clock application is the main fnction. The code in this file is the same as for the basic application except the ARApplication template argment is the Clock class: #inclde <arlib.h> #inclde <arapplication.h> #inclde <clock.h> sing namespace ARLib::Application; int main(int argc, char *arg[]) { ARApplication<Clock> app(&argc, arg); app.rn(); } retrn ; 4

43 8 Conclsion The aim of project was to deelop a comprehensie, yet easy to implement deeloper s toolkit for prodcing agmented reality applications. The ease of se has certainly been achieed, as an AR application can be created with jst two lines of code. For the majority of scenarios, the basic ARLib application will sffice, as mch of the fnctionality is controlled throgh external configration files. For more adanced applications, the bilt-in fnctionality can be extended or completely replaced, depending on reqirements. From a deeloper s point of iew, the toolkit offers all the extensible featres that wold normally be expected of a software library sch as ARLib. Another area with the ARLib that fnctions particlarly well is the corner detection rotines. The final soltion was deised and deeloped by the athor and ot performed other well establish techniqes in both the detection and performance. Where the toolkit performs less well is in the actal agmentation implementation, particlarly the camera calibration calclations. The techniqe sed from [MALIK ] is a fairly simple implementation for what is well known in the compter ision world as a fairly complex problem. The simplicity of the algorithms sed was also reflected in the qality of the agmented graphics; een the smallest of 3D objects can sffer from jittering. This is becase the algorithms can prodce qite different focal length ales een when a corner of a detected marker moes by a single pixel. To oercome this problem, ARLib can be switched from atomatically calclating the focal lengths to sing fixed ales. The fixed ales can be adjsted while the AR application is rnning. Eery step of this project was complex and had its difficlties. A main reqirement of ARLib was that it mst be able to rn in real-time of at least 5 frames per second. These reqirements proed too mch for some of the chosen algorithms, bt cold only be rejected once the code had been implemented and tested. In the early stages of the project, two week s work had to be abandoned, as the marker detection rotines did not fnction in a real-time enironment becase they were too comptationally expensie. 8. Recommendations ARLib is a complete application and can be sed to create AR applications qickly and easily. Howeer, like most first ersions of software there are improements to featres and fnctionality that can be added to later releases. These inclde: 43

44 Improe the camera pose calclation so that it is less jittering. This cold be improed by adding a history to the detected markers so that if a corner has only moed by a pixel or two, then the focal lengths do not need to be recalclated. Proide fll spport for IEEE394/Firewire deices in Linx. Add bilt-in spport for OpenGL lighting so that lights can be configred while an AR application is rnning. This wold allow the lit agmented objects to match the real world enironment. Crrently, a single snapshot of the agmented scene can be saed to a.tif file. This fnctionality cold be extended so that an entire seqence can be saed. 44

45 Appendices Appendix A Sample Ots Thresholding C++ code // NOTE: Creation of histogram[56] not shown float w = ; // first order cmlatie float = ; // second order cmlatie float T = ; // total mean leel int k = 55; // maximm histogram index int threshold = ; // optimal threshold ale float histnormalized[56];// normalized histogram ales float work, work; // working ariables doble work3 =.; // Create normalised histogram ales (size=image width * image height) for (int I=; I<=k; I++) histnormalized[i-] = histogram[i-]/(float)size; // Calclate total mean leel for (int I=; I<=k; I++) T+=(I*histNormalized[I-]); // Find optimal threshold ale for (int I=; I<k; I++) {Ha w+=histnormalized[i-]; +=(I*histNormalized[I-]); work = (T * w - ); work = (work * work) / ( w * (.f-w) ); if (work>work3) work3=work; } // Conert the final ale to an integer threshold = (int)sqrt(work3); 45

46 Appendix B ARLib Application Command-Line Switches The defalt implementation of ARLib spports the following command-line switches: Switch Details -? or -help Displays help for the application, inclding command-line switches and ser interface keys. -configfile <filename> Specifies an alternatie configration file to se for the application. -markerfile <filename> Specifies an alternatie marker definition file to se for the application. -modelfile <filename> Specifies an alternatie model file to se for the application. -image <filename> Loads the image specified by <filename>. -seqence <filename> Loads a seqence of tiff files starting with the specified <filename>. 46

47 Appendix C ARLib Application User-Interface Keys Key Details Left Arrow Plays the seqence backwards. If the seqence is pased, then this keys will step backward one frame at a time. Right Arrow Plays the seqence forwards. If the seqence is pased, then this key will step forward one frame at a time. Spacebar Stops the crrent seqence or ideo sorce. Press spacebar to contine. R Toggles playback of seqence between real-time and normal speed. F Toggles display between fll screen and windowed mode. D Switch into display element mode. Use left and right arrows to naigate the aailable ser interface elements. Use the p and down arrows to change to associated ale. Press Escape to exit this mode. U Switch into pdate mode. Use the left and right arrows to naigate throgh the aailable options. Use the p and down keys to change the associated ale (hold shift to pdate in increments of ). Press Escape to exit. Tab Toggles the display of all ser interface elements. M Reloads any models (obj files) that are being sed. +/- Zooms in and ot of the crrently display image. A Displays the Alpha channel. C Displays the color channel. S Saes a snapshot of the crrently display image. Esc Exits the application. 47

48 Appendix D ARLib Configration File The following configration file is spplied as defalt with ARLib: defalt.conf ######################################################### # Defalt configration settings for ARLib applications # ######################################################### # The common section defines configration options applicable # to all ARLib applications. ############################################################################### [Common] ############################################################################### # Image is for specifying an image to be atomatically loaded. Image = # Seqence is for specifying the first image of a seqence of image to load. Seqence = # MarkerFile is for specifying an alternate marker configration file. # The defalt is "config/markers.conf". If no ale then defalt will be sed. MarkerFile = # ModelFile is for specifying an alternate model configration file. # The defalt is "config/models.conf". If no ale then defalt will be sed. ModelFile = # ShowUI is an oeride for the displaying of all ser interface elements # (e.g. showfps). If this ale is not set then no UI elements will display. # The defalt is (off). Acceptable ales are or. showui = # Realtime denotes whether image seqences shold rn at realtime (as denoted # by the fps setting). If realtime is off then frames will be displayed as # they are processed. The defalt is (on). Acceptable ales are or. realtime = # denotes the reqired frames per second to display. # The defalt is 5. Acceptible ales are to. fps = 5 # Zoom denotes how mch the image shold be zoomed or scaled # The defalt is. Acceptible ales are in the range of to. Zoom = 48

49 # Fllscreen denotes whether the application shold start in fll screen mode. # The defalt is (off). Acceptable ales are or. FllScreen = # WindowWidth defines the defalt startp width of the main window. # The defalt is 8. Acceptable ales are a position integer. WindowWidth = 8 # WindowHeight defines the defalt startp height of the main window. # The defalt is 6. Acceptable ales are a position integer. WindowHeight = 6 # ShowAR denotes whether the agmented elements shold be display. # The defalt is (on). Acceptable ales are or. ShowAR = # ShowFPS denotes whether frames per second shold be displayed or not. # The defalt is (off). Acceptable ales are or. ShowFPS = # ShowFrameNo denotes whether the crrent frame nmber shold be displayed. # The defalt is (off). Acceptable ales are or. ShowFrameNo = # ShowFocalLength denotes whether to display the crrent focal length. # The defalt is (off). Acceptable ales are or. ShowFocalLength = # (LINUX) Denotes whether the image show be flipped pside down. Some (if not # all webcam driers appear to read the image pside down). # The defalt is (on). Acceptable ales are or. FlipHorizontal = # (LINUX) Specifies the defalt deice to open for streaming webcam spport. # The defalt is /de/ideo. DefaltDeice = # Specifies the location to store snapshots. # The defalt is "". SnapshotLocation = snapshots # Specifies the prefix of the snapshot file name. The format of the final image # will be SnapshotPrefix.n.tif. # The defalt is "snapshot". SnapshotPrefix = snapshot 49

50 ############################################################################### [Segmentation] ############################################################################### # The segmentation section defines options for prodcing a black and white # image from the pixel color ales. # The OtsOffset defines how mch the dynamically calclated threshold ale # shold be adjsted. The Defalt is. Acceptable ales are -55 to 55. OtsOffset = 55 # UseLminance denotes how the black and white ales shold be calclated from # the color ales. If set then a lmnance formla is sed otherwise an # aerage of the red, green and ble ale is sed. The defalt is (On). # Acceptable ales are or. UseLminance = ############################################################################### [Detection] ############################################################################### # ShowBondingBoxes denotes whether boxes shold be draw arond potential # markers. The defalt is (off). Acceptable ales are or. ShowBondingBoxes = # ShowCorners denotes whether potential marker corners shold be display. # The defalt is (off). Acceptable ales are or. ShowCorners = # ShowMarkerEdge denotes whether the markers oter edge shold be highlighted. # The defalt is (off). Acceptable ales are or. ShowMarkerEdge = # ShowMarkerID denotes whether to display the detected marker id. # The defalt is (off). Acceptable ales are or. ShowMarkerID = # The MinArea defines the minimm size in pixels that a bonding box is deemed # alid. The Defalt = 65. Acceptable ales are a positie integer. MinArea = 4 ############################################################################### [Pose] ############################################################################### # UseFixedFocal denotes whether the fixed Focal Length ales shold be sed or # whether the focal length shold be dynamic calclated based on detected marker # position. The Defalt =. Acceptable ales are or. UseFixedFocal = 5

51 # The FocalLength parameters defines the fixed focal length in the U and V # directions. FocalLength = 8,4 # The Rotation parameter defines a defalt rotation for each model prior to # being diplayed. The three ales represent rotation degrees in the x, y and z # axis. The defalt is,,. Rotation = 9,, 5

52 Bibliography ABIDI, M. A. AND CHANDRA, T., 989. Accrate Pose Estimation From A Single Perspectie View. Uniersity of Tennessee, Knoxille. ALLEZARD, N., DHOME, M., AND JURIE, F.,. Recognition of 3D Textred Objects by Mixing View-Based and Model-Based Representations. In: 5 th International Conference on Pattern Recognition. p.96. DAVIS, E. R., 5. Machine Vision - Theory, Algorithms, Practicalities, 3 rd ed. USA: Morgan Kafmann. DUDA, R.O. AND HART, P.E., 97. Use of the Hogh transformation to detect lines and cres in pictres. In: Commnications of the ACM Vol 5 Nmber, 97 New York. ACM Press. pp. -5. EASON, R. O., ABIDI, M. A., AND GONZALEZ, R. C., 984. A Method For Camera Calibration Using Three World Points. In: Proc. Int l Conf.Systems,man and Cyber., October 984 Halifax Canada. pp EPFL, 4. Towards Recognizing Featre Points Using Classification Trees. Lasanne, Switzerland, IC/4/74. FEINER, S., MACINTYRE, B., AND SELIGMANN, D., 993. KARMA: Knowledge-based Agmented Reality for Maintenance Assitance [online]. Colmbia Uniersity. Aailable from [Accessed Sept 5]. FOLEY, J. D., DAM, A. V., FEINER, S. K., AND HUGHES, J. F., 99. Compter Graphics - Principles and Practice. nd ed. USA: Addison-Wesley. HARRIS, C. AND STEPHENS, M., 988. A Combined Corner and Edge Detector. In: M. M. MATTHEWS, ed. Proceedings of the 4 th ALVEY ision conference, September 988 Uniersity of Manchester. pp HECKBERT, P., 995. Projectie Mappings for Image Warping (Masters). Uniersity of Berkeley. HUBER, D., 5. Compter Vision Homepage [online]. Carnegie Mellon Uniersity. Aailable from [Accessed 3 Sept 5]. 5

53 KATO, H., 5. ARToolkit Home Page [online]. Uniersity of Washington. Aailable from [Accessed 3 Sept 5]. LEPETIT, V., PILET, J., AND FUA, P., 4. Point Matching as a Classification Problem for Fast and Robst Object Pose Estimation. In: CVPR, Jne 4 Washington DC. LIU, P., GEORGANAS, N. D., AND BOULANGER, P.,. Designing Real- Time Vision Based Agmented Reality Enironments for 3D Collaboratie Applications. In: Proceedings of the IEEE Canadian Conference on Electrical & Compter Engineering, May -5 Hotel Fort Garry. LIVINGSTON, M. A., 998. UNC Laparoscopic Visalization Research [online]. Uniersity of North Carolina. Aailable from [Accessed 3 Sept 5] MALIK, S.,. Robst Registration of Virtal Objects for Real-Time Agmented Reality (MSc). Carleton Uniersity, Canada. NIXON, M. AND AGUADO, A.,. Featre Extraction & Image Processing. Cornwall, England: Newnes. SMITH, S.M. AND BRADY, J.M., 997. SUSAN - a new approach to low leel image processing. Int. Jornal of Compter Vision. May 997. pp VACCHETTI, L., LEPETIT, V., AND FUA, P., 3. Fsing Online and Offline Information for Stable 3D Tracking in Real-Time. In: Conference on Compter Vision and Pattern Recognition, Jne 3 Madison. Frther Reading BOYLE, R. D., AND THOMAS, R. C., 988. Compter Vision - A First Corse. Great Britain: Blackwell Scientific Pblications. GONZALEZ, R. C., WOODS, R. E., AND EDDINS, S. L., 4. Digital Image Processing Using MATLAB. New Jersey: Pearson Prentice Hall. HARTLEY, R., AND ZISSERMAN, A.,. Mltiple View Geometry in Compter Vision. nd ed. Cambridge: Cambridge Uniersity Press JAIN, R., KASTURI, R., AND SCHUNCK, B. G., 995. Machine Vision. Singapore: McGraw-Hill. STOLFI, J., 99. Oriented Projectie Geometry: A Framework for Geometric Comptations. USA: Academic Press, Inc. 53