Sistema Multiprojector per a sistema CAVE de Realitat Virtual

Títol: Sistema Multiprojector per a sistema CAVE de Realitat Virtual Volum: 1/1 Alumne: Adrià Vernetta Rubio Director: Pere Brunet i Crosa Departament: LSI Data: Gener de 2011 DADES DEL PROJECTE Títol del Projecte: Sistema Multiprojector per a sistema CAVE de Realitat Virtual Nom de l'estudiant: Adrià Vernetta Rubio Titulació: Enginyeria Informàtica Crèdits: 37,5 Director/Ponent: Pere Brunet i Crosa Departament: LSI MEMBRES DEL TRIBUNAL (nom i signatura) President: Carlos Antonio Andújar Gran Vocal: Beatriz Otero Calviño Secretari:Pere Brunet i Crosa QUALIFICACIÓ Qualificació numèrica: Qualificació descriptiva: Data: Sistema multiprojector per a sistema Cave de Realitat Virtual Adrià Vernetta Rubio Facultat d'Informàtica de Barcelona ´ Index I Presentaci´o 1 1 Introducci´o 3 1.1 Els sistemes de realitat virtual . . . . . . . . . . . . . . . . . 3 1.2 Lamem`oria............................ 10 1.3 Objectius del projecte . . . . . . . . . . . . . . . . . . . . . . 10 2 Organitzaci´o 13 2.1 M`oduls del programa . . . . . . . . . . . . . . . . . . . . . . . 13 2.2 Planificaci´o ............................ 14 II Desenvolupament 17 3 Homografies 19 3.1 Qu`e s´on les homografies? . . . . . . . . . . . . . . . . . . . . 19 3.2 Com calcular una homografia . . . . . . . . . . . . . . . . . . 20 3.3 Homografies al projecte . . . . . . . . . . . . . . . . . . . . . 21 4 Calibratge 25 4.1 Calibratge geom`etric . . . . . . . . . . . . . . . . . . . . . . . 26 4.2 Calibratge crom`atic . . . . . . . . . . . . . . . . . . . . . . . 30 4.3 Calibratge crom`atic global . . . . . . . . . . . . . . . . . . . . 34 5 Captaci´o 37 5.1 Elecci´o de la c`amera . . . . . . . . . . . . . . . . . . . . . . . 37 5.2 Problemes adicionals . . . . . . . . . . . . . . . . . . . . . . . 39 5.3 C`alcul de les homografies . . . . . . . . . . . . . . . . . . . . 41 6 Arquitectura 45 6.1 Descripci´o dels equips . . . . . . . . . . . . . . . . . . . . . . 45 6.2 Descripci´o de les connexions f´ısiques . . . . . . . . . . . . . . 48 6.3 Descripci´o de la xarxa . . . . . . . . . . . . . . . . . . . . . . 49 i ii ´ INDEX 7 Llibreries 53 7.1 LibFoto .............................. 53 7.2 LibSocks.............................. 54 7.3 LibHomography.......................... 55 7.4 LibImages............................. 57 8 El Programa 61 8.1 Mapesconceptuals ........................ 61 8.2 Casosd’´us............................. 65 III Resultats 71 9 An`alisi final 73 9.1 Estrat`egies rebutjades . . . . . . . . . . . . . . . . . . . . . . 73 9.2 Resultat final i conclusions . . . . . . . . . . . . . . . . . . . . 76 9.3 An`alisi de costos . . . . . . . . . . . . . . . . . . . . . . . . . 78 9.4 Millores proposades . . . . . . . . . . . . . . . . . . . . . . . . 80 Bibliografia 82 A Manual d’instruccions 85 A.1 Instal · laci´o............................. 85 A.2 Execuci´o.............................. 85 A.3 ´ Usdel’aplicaci´o ......................... 86 B Dades 89 B.1 Homografies............................ 89 B.2 M`ascares ............................. 90 B.3 Patrons .............................. 90 C Shaders 91 C.1 Aplicar les homografies . . . . . . . . . . . . . . . . . . . . . . 91 C.2 Aplicar les m`ascares . . . . . . . . . . . . . . . . . . . . . . . 92 ´ Index de figures 1.1 Utilitzaci´o de la visi´o est`ereo via imatges anaglyph ...... 4 1.2 Ulleres amb headtracking incorporat .............. 5 1.3 Sistema de so envolupant dom`estic . . . . . . . . . . . . . . . 6 1.4 Exemple d’una CAVE . . . . . . . . . . . . . . . . . . . . . . 7 1.5 Powerwall del CRV de Barcelona . . . . . . . . . . . . . . . . 8 1.6 Ulleres de realitat virtual . . . . . . . . . . . . . . . . . . . . 9 1.7 Diferents exemples de dispositius haptics . . . . . . . . . . . . 9 1.8 Projector similar als actuals de la CAVE . . . . . . . . . . . . 11 2.1 Diagrama de Gantt inicial. . . . . . . . . . . . . . . . . . . . . 15 2.2 Diagrama de Gantt definitiu. . . . . . . . . . . . . . . . . . . 16 3.1 Correspond`encia entre punts enviats per un projector i punts capturats per una c`amera. . . . . . . . . . . . . . . . . . . . . 21 3.2 Diagrama de les transformacions que apliquem a la imatge inicial per a que al ser capturada per la c`amera es vegi correctament, sense deformacions. . . . . . . . . . . . . . . . . . 22 3.3 Correspond`encia entre punts enviats per dos projectors i punts capturats per una c`amera. . . . . . . . . . . . . . . . . . . . . 23 3.4 Imatge final situada a l’interior dels frame buffers. ...... 24 4.1 Calibratge geom`etric . . . . . . . . . . . . . . . . . . . . . . . 25 4.2 Il · lustraci´o dels sistemes de coordenades i la seva relaci´o . . . 27 4.3 Pantalla il · luminada des del centre de la CAVE . . . . . . . . 28 4.4 Il · lustraci´o de les coordenades de CAVE respecte al projector 29 4.5 Calibratge amb lluminositat no homog`enia . . . . . . . . . . . 30 4.6 Efecte obtingut aplicant diferents correccions crom`atiques. . . 31 4.7 M`ascares computades amb l’algorisme de feathering . . . . . 33 4.8 Resultat del calibratge crom`atic amb correcci´o . . . . . . . . 34 5.1 Imatges del muntatge a la CAVE . . . . . . . . . . . . . . . . 38 5.2 Distorsi´o de barril provocada per una lent corvada. . . . . . . 40 5.3 Aplicaci´o del primer filtrat a la fotografia realitzada . . . . . 42 5.4 Resultat de la resta del fons a la captura dels patrons . . . . 43 iii 6CAP´ ITOL 1. INTRODUCCI ´ O O¨ıda Una de les primeres aproximacions ´es el so est`ereo, el qual reprodueix el so amb dos canals, un per a cada orella, aconseguint diferenciar si el so ve de la dreta o de l’esquerra. Actualment hi ha molts sistemes, for¸ca m´es evolucionats que l’anterior, que estimulen convenientment aquest sentit, essent molts d’ells heretats del cinema. L’exemple m´es clar s´on els sistemes de so envolupant que, disposant diferents altaveus al voltant de l’usuari, aconsegueixen un so tridimensional. Una altra t`ecnica molt potent, per`o que no ha tingut molt ress`o, ´es l’holofonia. L’objectiu ´es aconseguir un so envolupant per`o sense tenir la necessitat de disposar de molts altaveus que voregin a l’usuari. La manera que t´e d’aconseguir-ho ´es enregistrant les fonts de so de forma independent per a cada orella, utilitzant dos micr`ofons omnidireccionals situats al cap d’un dummy, tal i com s’ubicarien realment les orelles en un cap hum`a. L’`exit d’aquesta t`ecnica est`a en que, se suposa, imita la forma en que el cervell hum`a processa el so. Figura 1.3: Sistema de so envolupant dom`estic Tacte Els dispositius que treballen amb aquest sentit s’anomenen haptics. Una de les aproximacions m´es comuns ´es un bra¸c robotitzat, un dels extrems del qual s’agafa amb la m`a. L’usuari pot agafar aquest extrem per moure el bra¸c robotitzat que, treballant de forma conjunta amb algun programa que visualitzi on es troba la m`a dins del m´on virtual, oferir`a resist`encia quan el moviment efectuat impacti contra la superf´ıcie de l’objecte, donant una sensaci´o de tacte. Aquests sistemes encara tenen bastants problemes i inconvenients:  D’una banda, aquest bra¸c ´es for¸ca car i, per tant, nom´es assequible pels centres d’investigaci´o.  D’altra banda, per a poder notar i resseguir una superf´ıcie virtual, la detecci´o de col · lisions ha de ser molt r`apida, o l’usuari notaria una 1.1. ELS SISTEMES DE REALITAT VIRTUAL 7 tremolor que faria desapar`eixer la sensaci´o d’immersi´o. Aix`o ´es degut a que el tacte ´es molt m´es sensible que la vista en el que es refereix a canvis. Tot i tenir aquests petits problemes, s´on t`ecniques amb molt potencial, sobretot en aplicacions com la medicina, el disseny de cotxes, treball a dist`ancia, etc. Olfacte Finalment, tamb´e hi ha l´ınies d’investigaci´o obertes amb el sentit de l’olfacte, per`o ´es una via molt poc explorada. S’han constru¨ıt alguns prototipus i proposat idees com integrar sensors i emissors d’olor en m`obils, dispositius connectats a l’ordinador que emeten olors, o fins i tot webs que suportin aquests dispositius i envi¨ın informaci´o per utilitzar-los. De totes maneres, les dificultats t`ecniques d’aquests aparells, i tamb´e la del programari per utilitzar-los, fan que encara sigui una idea del futur. Cal dir, per`o, que es tracta de dispositius amb un gran potencial al darrere, perqu`e aquest sentit ´es un gran estimulant del cervell, essent un dels que m´es records evoca i reaccions agradables, o no, produeix a les persones. 1.1.4 Exemples En aquest darrer apartat es mostren uns quants exemples dels sistemes de realitat virtual comentats. CAVE Una CAVE (l’acr`onim de Cave Automatic Virtual Environment o Entorn Virtual Autom`atic de Cova) consisteix en una sala de 3x3x3m on es projecten imatges a quatre cares del cub (tres parets i un terra). L’usuari se situa a l’interior d’aquest espai i s’endinsa, d’aquesta manera, al m´on virtual, tal i com es pot veure a la Figura 1.4. Figura 1.4: Exemple d’una CAVE 8CAP´ ITOL 1. INTRODUCCI ´ O L’aplicaci´o 3D que gestiona la CAVE hi projecta el m´on virtual, de tal manera que no es percebi que hi ha parets; l’usuari, envoltat d’aquestes imatges, tindr`a la sensaci´o de ser-hi dins. Per tal de millorar-ne l’experi`encia, les CAVEs han evolucionat i, actualment, incorporen la visi´o est`ereo i el seguiment de l’usuari. Powerwall La powerwall es podria descriure com l’evoluci´o d’un cinema tradicional. Es tracta d’una pantalla tan gran com es pugui, generalment amb estereovisi´o passiva i, fins i tot, so envolupant. L’aplicaci´o que la gestiona suposa que l’usuari est`a visualitzant la pantalla des del centre i, tot i que aix`o no ´es exacte, at`es que s’acostumen a asseure en cadires i, per tant, no ´es possible que totes elles estiguin, `obviament, al centre, es tracta d’una aproximaci´o v`alida (especialment perqu`e els espectadors s´on est`atics). Figura 1.5: Powerwall del CRV de Barcelona Ulleres de realitat virtual Les ulleres de realitat virtual van ser una de les primeres aproximacions que es van construir. La idea ´es tenir dues pantalles molt petites separades i que cada ull nom´es en pugui veure una, muntant-les sobre unes ulleres. Aquest tipus de dispositiu permet fer head tracking mesurant els girs del cap amb acceler`ometres, suposant que l’usuari est`a quiet a una cadira, o es pot mesurar amb un sistema com el de la CAVE, i llavors l’usuari es pot moure. Els inconvenients s´on que les pantalles muntades a les ulleres han de ser molt bones, perqu`e han de tenir una resoluci´o prou alta i ser suficientment grans com per a que l’usuari no hagi de for¸car la vista i la qualitat de la imatge sigui bona. Tamb´e hi ha altres problemes molt m´es dif´ıcils de solu- 1.1. ELS SISTEMES DE REALITAT VIRTUAL 9 cionar, com que l’aplicaci´o t´ıpicament nom´es t´e coneixement de la posici´o del cap, per`o no de la resta del cos i, per tant, no el pot ensenyar. Figura 1.6: Ulleres de realitat virtual Actualment, s’est`a investigant l’evoluci´o d’aquestes ulleres per tal d’eliminar aquests problemes. La idea ´es utilitzar unes ulleres normals, per`o incloure uns petits projectors a les patilles. D’aquesta manera, i fent el seguiment de l’usuari, podem solucionar el problema de que es maregi per no veure el seu propi cos, aprofitant que els vidres serien transparents i se’l podria veure. Tamb´e se solucionarien els problemes de que la pantalla no ´es prou gran. Dispositius haptics Aquests dispositius se centren en el sentit del tacte. A la figura 1.7 s’hi poden veure uns quants exemples. (a) Exemple de robot haptic petit (b) Exemple de bra¸c robotitzat haptic (c) Exemple de dispositiu haptic per a la m`a Figura 1.7: Diferents exemples de dispositius haptics La figura 1.7b mostra un bra¸c robotitzat. L’usuari agafa la punta m´es 10 CAP´ ITOL 1. INTRODUCCI ´ O fina amb la m`a i la va movent lliurement fins que troba un objecte virtual, de tal manera que el robot ofereix resist`encia al moviment en aquell sentit i l’usuari nota l’impacte. Es tracta d’elements for¸ca cars i, conseq¨uentment, dif´ıcilment assequibles, per`o ja s’est`a comen¸cant a fabricar-ne de m´es petits, com el de la figura 1.7a. Altres tipus de dispositius s´on les mans robotitzades, les quals estan connectades a una altra m`a que t´e l’usuari. Aquest darrer pot moure la seva pr`opia m`a lliurement; la m`a robotitzada que duu posada est`a sincronitzada amb la que est`a tocant l’objecte a dist`ancia, tal i com podem veure molt m´es clarament a la figura 1.7c. 1.2 La mem`oria Aquesta mem`oria est`a organitzada en tres parts. La primera consisteix en una introducci´o a la problem`atica que se’ns presenta amb la CAVE del CRV, i en la presentaci´o i justificaci´o dels objectius del projecte (part I). Tamb´e s’hi presenta la organitzaci´o en m`oduls que s’ha realitzat i la planificaci´o dels terminis del projecte. La segona cont´e tot el desenvolupament del projecte en si (part II). A la tercera part, presentem els resultats i les conclusions (part III). Per acabar, s’inclouen tres ap`endixos A, B i C que complementen aspectes t`ecnics del projecte. M´es detalladament, en la primera part, despr´es d’aquesta introducci´o, presentem els detalls de la problem`atica actual del sistema CAVE, la soluci´o que proposem i l’exposici´o de tots els objectius del projecte actual. A la segona part pasem a presentar l’eina matem`atica principal utilitzada al projecte: les homografies (cap´ıtol 3) i tots els detalls del proc´es de calibratge dissenyat (cap´ıtol 4). Dediquem el cap´ıtol 5 al sistema de captaci´o implementat, amb tots els seus detalls corresponents. Al cap´ıtol 6 definirem tota l’arquitectura del nostre sistema i al cap´ıtol 7 presentarem el disseny de les diferents llibreries auxiliars que hem implementat per al desenvolupament del sistema. L’´ultim cap´ıtol d’aquesta part est`a dedicat al disseny del programa principal que ens permetr`a realitzar els calibratges (8). La tercera part de la mem`oria consisteix en un an`alisi dels diferents resultats obtinguts (cap´ıtol 9). En ell hi veurem les estrat`egies rebutjades, les conclusions finals, un an`alisi dels costos del projecte i tota una s`erie de millores proposades. 1.3 Objectius del projecte 1.3.1 Problem`atica actual La CAVE del Centre de Realitat Virtual (que anomenarem CRV a partir d’ara en aquest document) de Barcelona est`a composada per una s`erie de projectors est`ereo de gran lluminositat que permeten projectar en est`ereo 1.3. OBJECTIUS DEL PROJECTE 11 actiu, sincronitzant-se amb les ulleres d’oclusi´o. Varen ser instal · lats a l’any 2001 i s’estan apropant al final de la seva vida ´util (un d’ells ja no ´es funcional, de fet). Aquest tipus de projector t´e un gran cost de reempla¸cament, al voltant d’uns 50.000 ¿ . Aix´ı doncs, l’objectiu principal ´es substituir aquest antic sistema per un de nou de molt menor cost i major qualitat. 1.3.2 Soluci´o proposada Per a assolir aquests objectius de reducci´o de cost i augment de la qualitat (que es correspondr`a amb un augment de la ressoluci´o final aconseguida a les projeccions) s’ha definit la seg¨uent arquitectura del sistema: La idea principal ´es substituir cada projector per un conjunt de projectors comercials de baix cost (al voltant de 500 ¿ cadascun), que ens proporcionaran, en global, una major ressoluci´o de la pantalla a molt menor cost. Tenint en compte que necessitem cobrir pantalles de 3x3m i que es far`a servir est`ereo passiu, necessitarem 12 projectors (6 per a cobrir tota la pantalla per a un sol ull). Aix`o comporta un cost d’uns 3.000 ¿ . Per a control · lar aquests 12 projectors, farem servir 3 pc’s dotats de 2 targetes gr`afiques duals, per tal de que cada un d’ells control · li tota una fila de projectors i ambd´os ulls. Aquestes m`aquines s’hauran de comunicar entre elles mitjan¸cant una xarxa que els permeti intercanviar informaci´o. Les m`aquines que s’han adquirit tenen un cost d’aproximadament uns 1.500 ¿ , per tant aix`o fa un total de 4.500 ¿ . Figura 1.8: Projector similar als actuals de la CAVE Si fem l’agregat de tot plegat, el cost aproximat del sistema seria d’uns 7.500 ¿ enfront els 50.000 ¿ que costaria reempla¸car els antics projectors per uns equivalents nous. Per`o amb aix`o no en tenim prou. Necessitem dissenyar un software que ens permeti realitzar el calibratge dels projectors per a que aquests 12 CAP´ ITOL 1. INTRODUCCI ´ O simulin un ´unic projector est`ereo. Aquesta ser`a la part central del projecte: dissenyar i implementar un software capa¸c de realitzar aquests ajustos de forma totalment autom`atica. A m´es, volem que el sistema es pugui calibrar sense massa restriccions en quant al muntatge dels diferents dispositius i, per tant, haurem d’implementar-lo d’acord amb aix`o realitzant el proc`es de forma que funcioni en unes condicions molt generals sense tenir en compte massa detalls dels elements externs al software. 1.3.3 Objectius espec´ıfics del projecte A continuaci´o es detalla un resum dels objectius proposats per assolir al projecte:  Definir l’arquitectura: Necessitem definir completament l’arquitectura del nostre sistema: quins projectors farem servir, quants, quin tipus de sistema de calibratge emprarem, quines caracter´ıstiques ha de tenir el software a implementar...  Correcci´o geom`etrica: Els nostres projectors estaran situats en unes torres on seran instal · lats a una certa al¸cada per tal de garantir el recobriment total de la pantalla. No obstant aix`o, no podem garantir la perfecta alineaci´o d’aquests i, per tant, caldr`a calcular les transformacions necess`aries a aplicar a les c`ameres del sistema de visualitzaci´o per a poder garantir que l’escena es veu ben alineada geom`etricament. Per a fer aix`o, calcularem una s`erie d’homografies (transformacions perspectives 2D. Veure secci´o 3 per a una descripci´o detallada) amb uns patrons de punts que anirem captant amb una c`amera de fotos i amb els que calcularem les matrius necess`aries.  Correcci´o crom`atica: Un cop aconseguit que els nostres 6 projectors projectin l’escena de forma geom`etricament correcta caldr`a realitzar una correcci´o crom`atica, ja que, per assegurar-nos que no queden forats entre els projectors el que farem ser`a sol · lapar les `arees de projecci´o a la paret. Aix`o comporta que hi haur`a zones de la pantalla que quedaran m´es iluminades que d’altres. Per a solucionar aquest problema, calcularem una m`ascara a aplicar a la lluminositat dels projectors per tal d’atenuar-los en les zones de conjunci´o. A m´es, caldr`a corregir tamb´e la lluminositat dels projectors per tal que tots ilumin amb la mateixa intensitat la paret.  Igualaci´o de la lluminositat: un cop arribats a aquest punt, faltar`a nom´es igualar la lluminositat dels dos ulls d’una mateixa paret per tal que l’escena s’aprecii de forma correcta. Adicionalment, caldr`a fer aix`o en el conjunt de tota la CAVE per a que totes les parets estiguin iluminades amb la mateixa intensitat. Cap´ıtol 2 Organitzaci´o En aquest cap´ıtol s’exposar`a l’organitzaci´o del projecte vista des de dos perspectives diferents:  Per una banda exposarem l’organitzaci´o des del punt de vista de la implementaci´o. En aquest punt descriurem els diferents m`oduls que conformen el software dissenyat.  Per un altre costat, veurem la organitzaci´o temporal del projecte. Exposarem les previsions de planificaci´o inicials i la seva variaci´o al llarg del desenvolupament del projecte. 2.1 M`oduls del programa Donada la naturalesa multidisciplinar del projecte es poden separar f`acilment les seves seccions diferents per tal d’implementar de forma modular cadascuna d’aquestes, aportant independ`encia entre elles. Aix`o ens permetr`a modificar la tecnologia emprada per a realitzar cadascuna de les diferents tasques sense que aix`o afecti a la resta. 2.1.1 Llibreria fotogr`afica Per a la implementaci´o de la llibreria que ens permet control · lar la c`amera de fotos hem emprat la llibreria Libgphoto2 [3]. Aquesta llibreria ens permet control · lar via protocol PTP (Picture Transfer Protocol) les funcions de la c`amera de fotos associada a la paret corresponent. Podrem ordenar la realitzaci´o de fotografies aix´ı com la seva desc`arrega immediata per tal de ser tractada. No tots els models de c`amera, per`o, poden ser control · lats de forma remota i aix`o ens afegeix una limitaci´o adicional a l’hora d’escollir un model de c`amera adient per al sistema. 13 14 CAP´ ITOL 2. ORGANITZACI ´ O 2.1.2 Llibreria d’an`alisi d’imatges Per a implementar el processat de les imatges preses per la c`amera hem fet servir la llibreria VXL [5] com a base per al seu tractament. Hem implementat una llibreria que la utilitza i que s’encarrega de realitzar les diferents operacions dessitjades en el proc´es d’adquisici´o i an`alisi que ens permetr`a extreure la informaci´o necessaria per als diferents processos del programa. 2.1.3 Llibreria de comunicaci´o via sockets Per a implementar la nostra llibreria de comunicaci´o via sockets hem fet servir la llibreria LibSockets d’Alhem [1]. Aquesta llibreria encapsula les funcions b`asiques de sockets en crides m´es simples i afegeix gestor d’events per als sockets per tal de facilitar la comunicaci´o. La nostra llibreria, encapsula encara m´es aquests sockets i en crea extensions per a poder ser utilitzats en diferents situacions. 2.1.4 Llibreria de c`alcul d’homografies La eina principal sobre la que es recolza el projecte ´es l’´us d’homografies per a modificar la sortida dels projectors. Per tal d’implementar el c`alcul d’aquestes hem creat una petita llibreria que realitza els diferents procesos i tractament de dades necess`aries per assolir els nostres objectius. Ja que les matrius que utilitzarem seran com a m´ınim de 9 ×8, hem utilitzat la llibreria matem`atica newmat10 [4], que est`a pensada per a realitzar c`alculs amb matrius de forma `optima per a dimensions superiors a 10 ×10. 2.2 Planificaci´o 2.2.1 Planificaci´o inicial Inicialment es va planificar el projecte per a que la seva durada fos d’aproximadament un any natural. Tal i com es pot observar a la figura 2.1, s’ha dissenyat i implementat cada m`odul del programa de forma independent. L’estructura a seguir en cada llibreria ha sigut la seg¨uent: 1. Estudi de les tecnologies necess`aries. 2. Disseny i implementaci´o de la llibreria. 3. Implementaci´o d’una aplicaci´o de prova de la llibreria. Una vegada hem anat implementant les llibreries, s’ha realitzat la implementaci´o de l’aplicaci´o de calibraci´o. Les parts m´es feixugues han sigut la implementaci´o del c`alcul amb homografies i el c`alcul de la homografia Pantalla-C`amera (marcada al diagrama com a “Homografia del Marc”). Hi 2.2. PLANIFICACI ´ O15 hem dedicat m´es temps ja que hem estat cercant i provant estrat`egies que ens donessin una molt bona precisi´o. Els ´ultims pasos han sigut implementar ´el calibratge geom`etric i el crom`atic, que es van estimar en un mes i mig cada un d’ells, i un mes i mig addicional per enllestir la mem`oria. Figura 2.1: Diagrama de Gantt inicial. 2.2.2 Planificaci´o final A la figura 2.2 s’observa la planificaci´o final. Els procesos de calibratge geom`etric i crom`atic han donat m´es problemes dels estimats i la seva implementaci´o s’ha allargat 2 mesos per a cada un d’ells. A m´es, finalment s’ha modificat el marc del projecte per a realitzar nom´es 22 CAP´ ITOL 3. HOMOGRAFIES c`amera i calcular una nova homografia Hfque converteixi les coordenades d’una imatge normalitzada ((x∈[0,1], y ∈[0,1]) cap a les coordenades (DcT L , DcT R , DcBL , DcBR ). Tal i com es pot veure a la figura 3.2, aix`o permet que quan la imatge sigui projectada pel projector i capturada per la c`amera, el que aquesta ´ultima vegi sigui la imatge inicial, sense deformacions de perspectiva1. Figura 3.2: Diagrama de les transformacions que apliquem a la imatge inicial per a que al ser capturada per la c`amera es vegi correctament, sense deformacions. Per a trobar aquestes correspond`encies entre punts del projector i la CAVE i punts a la c`amera, fem servir un senzill sistema d’identificaci´o de punts caracter´ıstics existents a les fotografies. M´es endavant, al cap´ıtol 4, es detallen les diferents t`ecniques emprades per a cada cas. 3.3.2 C`alcul amb dos projectors i una c`amera A continuaci´o, s’afegeix un nou projector al muntatge descrit anteriorment, complicant-lo lleugerament. Tal i com es pot apreciar a la figura 3.3, ara la c`amera capta els patrons de dos projectors i, per tant, es disposa de la geometria de les dues `arees projectades (en verd i blau). De manera an`aloga al cas anterior, es pot calcular una homografia HP1 que converteixi els punts del frame buffer del projector P1a coordenades de la c`amera, aix´ı com una homografia HP2que faci el mateix per al projector P2. A m´es, necessitarem con`eixer igualment l’altra homografia que transforma els punts en coordenades de la c`amera, a punts en coordenades de la pantalla de la CAVE (en aquest darrer pas, no hi ha cap canvi respecte al cas anterior). Arribats a aquest punt, podrem calcular tamb´e la homografia que transforma els punts del projector P1a punts del projector P2i viceversa, fent un simple c`alcul: H1−2=H−1 P2HP1 1Aix`o no vol dir que no hi pugui haver deformacions de relaci´o d’aspecte. 3.3. HOMOGRAFIES AL PROJECTE 23 Figura 3.3: Correspond`encia entre punts enviats per dos projectors i punts capturats per una c`amera. Aquesta ´ultima homografia H1−2ser`a necess`aria m´es endevant per als c`alculs necessaris per a la realitzaci´o de la correcci´o crom`atica dels projectors. Finalment, nom´es cal calcular les homografies finals HfP1iHfP2que, de la mateixa manera que en el cas d’un projector i una c`amera, situaran la imatge correctament dins dels frame buffers. 3.3.3 C`alcul amb Nprojectors i una c`amera Si se suposa que tenim Nprojectors enlloc de dos, el problema a resoldre ´es el mateix i no suposa cap complicaci´o addicional. En aquest cas, ´es necessari calcular les Nhomografies que ens permetran passar les coordenades de la pantalla final (calculades en el sistema de coordenades de la c`amera) a les coordenades de cadascun dels projectors i computar, aleshores, les homografies finals que situ¨ın una imatge normalitzada a cadascun dels Nframe buffers. Ara b´e, cal tenir en compte que quan el nombre de projectors va augmentant, les dimensions que podr`a assolir la pantalla final tamb´e creixen. Disposar d’una ´unica c`amera implica que arribar`a un punt en que aquesta no tindr`a un camp de visi´o prou ampli com per a veure tota l’`area projectada. Tot i que allunyant-la s’aconseguiria veure-ho tot, la resoluci´o de la c`amera no permetria fer-ho amb prou detall, o fins i tot ens podem trobar amb limitacions d’espai com ´es el nostre cas. La manera de solucionar-ho consisteix en disposar d’una c`amera m`obil o de m´es d’una c`amera, de tal manera que cadascuna d’elles visualitzi una petita porci´o del total d’`area projectada. En el nostre cas, per`o, les c`ameres 24 CAP´ ITOL 3. HOMOGRAFIES que ofereix el mercat ens permeten prendre les fotografies amb qualitat suficient com per poder captar tota la pantalla amb nom´es una i, per tant, no entrarem a discutir el m`etode a fer servir amb m´es d’una c`amera. (a) Imatge final situada a l’interior del frame buffer del projector 1. (b) Imatge final situada a l’interior del frame buffer del projector 2. Figura 3.4: Imatge final situada a l’interior dels frame buffers. Cap´ıtol 4 Calibratge Com s’ha explicat a la introducci´o, l’objectiu principal del projecte ´es aconseguir il · luminar una pantalla de forma homog`enia mitjan¸cant diversos projectors. Per a assolir aix`o, ´es necessari realitzar un calibratge d’aquests, de tal manera que cadascun d’ells il · lumini una regi´o de la pantalla aconseguint que la totalitat de la superf´ıcie il · luminada sembli procedent d’un sol projector. Aquest problema es pot separar en tres tasques diferenciades:  Calibratge geom`etric: per tal que la imatge projectada per tots els projectors sigui coherent i estigui ben alineada amb els marges de la pantalla, ´es necessari realitzar un calibratge de tipus geom`etric que deformi la part de la imatge enviada a pintar a cada projector per tal que es vegi ben orientada, tal i com es veu a la figura 4.1. (a) Projecci´o sense calibrar (b) Projecci´o calibrada Figura 4.1: Calibratge geom`etric  Calibratge crom`atic: per evitar l’aparici´o de forats a la pantalla per un mal enquadrament dels projectors, el que fem es sol · lapar les `arees projectades d’aquests per tal de no deixar cap espai entre elles. Degut a aquesta mesura, hi ha zones de la pantalla que es veuen m´es il · luminades que d’altres, i aix`o ´es un efecte no destijable. Per tant, 25 26 CAP´ ITOL 4. CALIBRATGE haurem d’afegir un tractament extra a la lluminositat dels projectors per a que s’aconsegueixi una projecci´o de lluminositat homog`enia.  Calibratge crom`atic global: un cop assolits els dos objectius anteriors per a cada paret de la CAVE cal igualar la lluminositat de totes les parets per tal de crear un entorn amb lluminositat homog`enia. A continuaci´o, es detalla el desenvolupament dels diferents pasos que intervenen en la realitzaci´o d’aquestes tasques. 4.1 Calibratge geom`etric Per a aconseguir coher`encia geom`etrica entre tots els projectors hem de resoldre dues q¨uestions.  Calibratge de la c`amera: el nostre sistema treballa sense con`eixer ni la ubicaci´o de la c`amera ni la orientaci´o i posici´o dels projectors. Per tant, primer necessitarem descobrir la posici´o i orientaci´o relatives de la c`amera respecte a la paret.  Calibratge dels projectors: cada projector haur`a de con`eixer la correcci´o a aplicar a l’escena projectada per tal que quedi ben alineada amb la paret i amb els altres projectors. Per a realitzar aquests calibratges calcularem una s`erie d’homografies que ens permetran tant analitzar les imatges com corregir les projeccions realitzades per cada projector. 4.1.1 Sistema d’homografies Tal i com hem descrit, necessitem registrar els diferents dispositius entre ells per a poder realitzar tots els c`alculs i correccions corresponents per a assolir els objectius del sistema. A la figura 4.2 es mostra un gr`afic on s’il · lustra el conjunt d’homografies que necessitarem calcular i tot seguit es presenta amb detall com s’aconsegueix cada una d’elles. Haur´ıem de destacar en aquest punt l’´us del sistema de captaci´o com a element de mesura. Podr´ıem treballa nom´es amb coordenades de projector i coordenades de CAVE si, un cop projectats els patrons, poguessim mesurar directament a la pantalla la posici´o d’aquests punts. Aix`o, per`o, ´es inviable i per aix`o s’introdueix el sistema de captaci´o i un nou sistema de coordenades intermig (veure cap´ıtol 5). 4.1.2 Homografia C`amera-Pantalla El primer problema a resoldre consisteix en trobar la correspond`encia entre la pantalla que volem il · luminar i el punt de vista des d’on seran captades 4.1. CALIBRATGE GEOM ` ETRIC 27 Figura 4.2: Il · lustraci´o dels sistemes de coordenades i la seva relaci´o les imatges. Necessitem saber exactament on es troba la pantalla vista des de la c`amera per tal d’alinear la zona de pintat dels projectors estrictament amb els marges de la pantalla. Per a fer aix`o, farem servir una homografia que relacionar`a una superf´ıcie de pintat normalitzada {S(x, y)|x∈[0,1], y ∈[0,1]} amb la zona de les fotografies on es veu la pantalla. Aix`o ens permetr`a relacionar un espai can`onic Samb les imatges capturades i aix´ı fer correspondre aquest espai amb l’espai a pintar en OpenGL. Per comoditat, tractarem les coordenades dels p´ıxels de les fotografies tamb´e en un espai homogeni (per tant, definit igual que S). Identificar el marge Per a fer aix`o necessitem, primer de tot, identificar els marges de la pantalla en la fotografia. Aix`o, per`o, no ´es una tasca trivial ja que necessitem ferho amb molta precisi´o. No podem permetre l’acumulaci´o d’errors en les diferents parts del proc´es donat que la nostra tasca ha de ser extremadament precisa. 28 CAP´ ITOL 4. CALIBRATGE Despr´es d’avaluar diferents possibilitats, la forma m´es precisa que s’ha trobat ´es la d’il · luminar la pantalla desde el centre de la CAVE per tal de veure en color nom´es la pantalla, i aix´ı poder detectar f`acilment els costats d’aquesta, tal i com es veu a la figura 4.3. Un cop idenfiticat el contorn, calcularem una homografia Hfent correspondre les cantonades de la pantalla amb les cantonades de la superf´ıcie S abans esmentada. Aquesta homografia s’aplicar`a a totes les imatges capturades per tal de transportar tots els punts captats a l’espai corresponent a la superf´ıcie S. Figura 4.3: Pantalla il · luminada des del centre de la CAVE 4.1.3 Homografies Projector-C`amera i Projector-Pantalla Un cop obtenim la homografia H, tenim una eina per relacionar les fotografies que capturem amb la pantalla de la CAVE corresponent i aix´ı procedir a l’an`alisi d’aquestes. Per a corregir geom`etricament les imatges projectades per cada projector necessitarem relacionar els projectors amb la c`amera i els projectors amb la pantalla de la CAVE. Per a fer aix`o, pintarem patrons de l´ınies, que en el nostre cas corresponen a 3 l´ınies de colors b`asics diferents (vermell, verd i blau) per tal de fer-ne m´es f`acil la identificaci´o a la imatge capturada. Extraurem els p´ıxels corresponents a cada l´ınia i en calcularem la recta de regressi´o. En el nostre cas, pintem dos patrons d’aquest tipus amb l´ınies orientades horitzontalment i dos patrons amb les l´ınies orientades verticalment. Aquestes l´ınies es pinten en uns indrets coneguts en l’espai OpenGL (en el nostre cas, les 12 l´ınies formen una quadr´ıcula de 6x6 punts centrada al projector, 4.1. CALIBRATGE GEOM ` ETRIC 29 que ocupa un 36% de la superf´ıcie total projectada). Un cop tenim les 12 l´ınies, calculem les interseccions de les l´ınies horitzontals amb cada l´ınia vertical, obtenint (si el proc´es d’identificaci´o de l´ınies les ha identificat totes) un total de 36 punts. Amb aquests 36 punts calcularem dues homografies diferents:  Per un costat, calcularem directament amb les coordenades dels punts obtinguts i les seves posicions te`oriques corresponents (conegudes, com ja hem dit anteriorment) la homografia HPi, que transformar`a els punts en coordenades normalitzades del projector en punts de la fotografia amb valors normalitzats entre 0 i 1.  Paral · lelament, multiplicarem per Hels punts obtinguts i fent servir les posicions te`oriques calcularem la homografia h. Aquesta homografia ser`a la correcci´o que el projector haur`a d’aplicar a les escenes pintades per tal que estigui correctament alineada en la seva regi´o de pintat corresponent. Aquest proc´es de calibratge ´es iteratiu, ´es a dir, podem realitzar successius calibratges per tal de refinar petits errors que s’hagin pogut produir, realitzant el proc´es cada vegada a partir de les dades modificades pel resultat del calibratge anterior. Figura 4.4: Il · lustraci´o de les coordenades de CAVE respecte al projector 30 CAP´ ITOL 4. CALIBRATGE 4.1.4 Homografia Pantalla - Projector Cal puntualitzar que el c`alcul d’hnecessita un petit refinament, ja que el que voldrem finalment ser`a que el projector corregeixi de forma local la posici´o de la geometria. Per tant, necessitarem multiplicar per una homografia adicional M, que transformar`a els punts en coordenades de la CAVE, a coordenades de CAVE respecte al projector. Per a fer aix`o no necessitem con`eixer cap tipus de dada per mitj`a d’imatges, ja que s’ha pres la convenci´o de que cada projector estar`a iluminant completament al menys un dels sextants en que es pot dividir la paret de la CAVE. Per tant, aquesta transformaci´o simplement far`a correspondre una superf´ıcie {S0(x, y)|x∈[−1,1], y ∈[−1,1]}amb el sextant de la pantalla de la que s’encarrega el projector on s’est`a realitzant el c`alcul, tal i com s’observa a la figura 4.4. 4.2 Calibratge crom`atic Una vegada realitzada el calibratge geom`etric dels projectors, la pantalla presenta zones amb una lluminositat clarament superior en les regions on es solapen dos o m´es projectors, tal i com s’observa a la imatge 4.5. Aix´ı doncs, necessitem un m`etode que ens permeti resoldre aquest problema i poder obtenir una superficie amb una lluminositat homog`enia i que, a m´es, no ens permeti distingir l’exist`encia de diferents projectors. Figura 4.5: Calibratge amb lluminositat no homog`enia 4.2. CALIBRATGE CROM ` ATIC 31 4.2.1 Feathering Cal disminuir, doncs, la contribuci´o de llum que aporten els projectors en aquestes regions de solapament. A la figura 4.6 es poden veure diferents maneres d’aplicar la correcci´o d’intensitats; la primera fila mostra el projector de l’esquerra, la segona el de la dreta i la darrera el resultat que obtenim en solapar-los. La subfigura 4.6a mostra el cas ideal: si el calibratge ´es perfecte, qualsevol de les tres aproximacions d´ona un bon resultat. La resta d’imatges (apagant completament part dels projectors, deixant que contribueixin al cinquanta per cent o utilitzant un degradat), exemplifiquen els errors que es produirien a la intensitat final de tota la pantalla si el calibratge no ha sigut prou acurat. La soluci´o de la figura 4.6d, utilitzant degradats, ´es la millor. A difer`encia de la resta, no veurem clarament una franja on la intensitat de llum sigui molt superior o molt inferior a la resta, sin´o que nom´es percebrem, a l’`area de solapament, un petit augment o una petita disminuci´o d’aquesta intensitat. (a) (b) (c) (d) Figura 4.6: Efecte obtingut aplicant diferents correccions crom`atiques. L’algorisme proposat per Baar, Raskar i Xiang[7] que s’explica a continuaci´o d´ona com a resultat unes m`ascares amb aquests degradats a l’`area de solapament. Definim una m`ascara per a cada projector, la qual assigna un pes entre [0.0, 1.0] a la intensitat de cada pixel que aquest projecta. Ja hem dit que un mateix punt pot ser il · luminat per m´es d’un projector; en qualsevol cas, donat un punt qualsevol, la intensitat total que aquest rep ha de sumar 1.0. L’estrat`egia que utilitza l’algorisme que calcula els degradats pren les seg¨uents consideracions: 38 CAP´ ITOL 5. CAPTACI ´ O tant, necessitem una c`amera de fotos amb la qual es pugui ordenar remotament la realitzaci´o de fotografies i la seva desc`arrega al PC. Per a fer aix`o, hem fet servir una llibreria de lliure distribuci´o anomenada LibGphoto2 [3]. Aquesta llibreria ens permet integrar al codi de la nostra aplicaci´o les eines necess`aries per a configurar i utilitzar una c`amera de fotos que pugui ser controlada remotament. 5.1.2 ` Optica de la c`amera A la figura 5.1 podem veure imatges del nostre muntatge de la CAVE del CRV de Barcelona. El nostre muntatge consta de 2 torres de projectors i una c`amera de fotos per a cada paret. Els projectors han d’estar situats a una dist`ancia des de la qual puguin, entre tots, il · luminar la totalitat de la paret. Aix`o no es un requeriment massa preocupant ja que els projectors d’avui dia estan dotats d’un zoom de qualitat i aix`o ens dona una certa llibertat de la dist`ancia a la qual hem de situar les torres. D’altra banda per`o, hem de situar la c`amera de fotos en una posici´o des de la qual es capti la totalitat de la pantalla. Per a assolir aix`o, necessitarem col · locar la c`amera en una posici´o o una altra depenent de la seva dist`ancia focal. Com m´es petita sigui aquesta, m´es gran ser`a l’angle d’obertura i, per tant, m´es a prop de la pantalla podrem situar la c`amera. Una vegada situada en un punt on captem tota la paret, haurem de situar les torres de tal manera que no obstrueixin el camp de visi´o de la c`amera. (a) (b) Figura 5.1: Imatges del muntatge a la CAVE No podem situar la c`amera, per`o, a la dist`ancia que volguem ja que estem limitats per les dimensions de la sala, aix´ı que, tot i que l’al¸cada `optima per a situar-la seria en un punt en la recta perpendicular al centre geom`etric de la pantalla (a uns 1.5m d’al¸cada), no totes les dist`ancies focals ens permeten capturar la totalitat de la pantalla en la dist`ancia l´ımit. Per tant, ens podem veure obligats a situar la c`amera a una al¸cada inferior o superior a la `optima (afegint perspectiva a la imatge captada i, per tant, 5.2. PROBLEMES ADICIONALS 39 una font m´es de possibles errors). Adicionalment, necessitem tenir una precisi´o molt alta pel que fa a la detecci´o de punts, per la qual cosa necessitarem que el tamany de les imatges ens permeti apreciar-los amb una precisi´o a nivell subp´ıxel. Aix`o implica que cada mil´ımetre quadrat de la pantalla hauria de pert`anyer a 1 o m´es p´ıxels de la imatge. Com la pantalla es de 3x3m i el ratio de les fotografies no ´es 1:1, necessitarem una c`amera amb 3000 o m´es p´ıxels de resoluci´o vertical (la qual cosa implica que les c`ameres `optimes seran les de m´es de 12 megap´ıxels). 5.1.3 Elecci´o final Resumint totes les condicions, necessitem una c`amera de fotos que pugui ser controlada de forma remota mitjan¸cant la llibreria LibGphoto2 i que tingui una `optica que ens permeti situar la c`amera a una dist`ancia dintre dels nostres l´ımits. Ens hem concentrat en la cerca de c`ameres compactes que acompleixin aquests requeriments per tal de tenir un sistema el m´es senzill possible i amb una `optica integrada ja en el dispositiu. Lamentablement, la majoria de les c`ameres del mercat que s´on controlables de forma remota o b´e estan descatalogades, o b´e tenen una dist`ancia focal que no ens permet situar-les de forma `optima o b´e s´on tan senzilles i poc configurables que no ens permeten obtenir les fotos amb una qualitat suficient tenint en compte les diferents condicions de llum que hi ha en cada pas del projecte. Hem estat probant una c`amera Nikon Coolpix P2, la qual hem hagut de situar arran de terra per tal de poder captar tota la pantalla, per`o que ens permetia realitzar el proc´es de forma completament autom`atica, tot i que la seva baixa resoluci´o (5 megap´ıxels) i la no configurabilitat dels par`ametres de captura afegia un error mitj`a no despreciable per`o assumible (al voltant d’un 0.7%). Tot i aix´ı, al no tenir un temps d’exposici´o configurable, la part de cal · libraci´o crom`atica ens ha resultat impossible de realitzar per culpa de la variaci´o entre les fotografies (dues fotografies del mateix escenari resultaven en dues fotografies completament diferents a nivell de lluminositat). Finalment hem adquirit una Canon EOS1000, una c`amera de tipus r`eflex que podem control · lar remotament i que ´es altament configurable (encara que m´es aparatosa i cara). ´ Es una c`amera de 10.2 megap´ıxels on trobem una reducci´o de l’error en el calibratge d’un 0.3%, la qual cosa ens permet demostrar la robustessa del sistema creat. 5.2 Problemes adicionals La `optica i la posici´o de la c`amera ens afegeix tota una s`erie d’incorreccions a les imatges que necessitem solventar per tal de poder fer l’an`alisi de forma acurada. B`asicament ens afegeix una distorsi´o radial i una altra per causa de la perspectiva. 40 CAP´ ITOL 5. CAPTACI ´ O 5.2.1 Distorsi´o radial La distorsi´o radial es deu a la geometria de la lent. Al no ser rectil´ınia, la lent no ´es capa¸c de capturar les l´ınies rectes en l´ınies rectes. Les lents s´on corvades i, per tant, els rajos de llum captats als extrems de la lent no es projecten ortogonalment al sensor, sin`o que ”s’apropen” al centre de la lent (el que es coneix com distorsi´o de barril) tal i com es pot observar en la figura 5.2. Figura 5.2: Distorsi´o de barril provocada per una lent corvada. Per tant, necessitem corregir aquesta distorsi´o per tal d’analitzar la imatge com si s’hagu´es captat sense cap distorsi´o, ja que analitzem rectes que a les nostres imatges apareixeran corvades, amb la qual cosa estarem afegint errors a les nostres mesures. Per a realitzar aquesta correcci´o, hem fet servir el m`etode proposat per Pollefeys i Koch[8]. Una c`amera perspectiva ve modelada per l’equaci´o de projecci´o m∼ =PM on ∼ =representa la igualtat obviant un valor d’escalat, M´es un vector de 4 components que representa un punt 3D del m´on en coordenades homog`enies i m, de forma similar, ´es un vector de 3 components que representa el punt 2D corresponent. P´es una matriu de projecci´o de 3×4 que pot ser factoritzada de la seg¨uent manera P=KRT[I| − t]on K =  f s u rf v 1   Kcont´e els par`ametres intr´ınsecs de la c`amera, R´es una matriu de rotaci´o que representa la orientaci´o i tun vector de 3 components que representa la posici´o de la c`amera. El par`ametre fcorrespon a la distancia focal mesurada en amplades de p´ıxel i r´es la relaci´o d’aspecte d’un p´ıxel. (u, v) 5.3. C ` ALCUL DE LES HOMOGRAFIES 41 representa les coordenades del punt principal de la imatge i s´es un terme que valora el biaix. A la pr`actica, el punt principal ´es molt proper al centre de la imatge i la relaci´o d’aspecte ´es pr`acticament l’unitat. Tal i com hem esmentat, sovint les c`amares no satisfan aquesta equaci´o projectiva degut a distorsions, la m´es important de les quals ´es la que ara ens ocupa i que es pot modelar normalment de la seg¨uent manera: m∼ =P(M) = KR0(RT[I| − t]M) on R0= (1 + K1(x2+y2)) x y 0T+0 0 1 T Aix´ı doncs, per aplicar la correcci´o d’aquesta distorsi´o, el que farem ser`a rec`orrer la imatge p´ıxel a p´ıxel des del centre i aplicarem, per a cada p´ıxel (x, y) de la imatge la seg¨uent correcci´o xc= (1 + K(x2+y2))x yc= (1 + K(x2+y2))y on (xc, yc) seran les noves coordenades del p´ıxel. El valor Kl’hem trobat mitjan¸cant la observaci´o de diferents fotografies amb diferents correccions i seleccionant el millor. 5.2.2 Distorsi´o per causa de la perspectiva Hem explicat anteriorment que l’al¸cada a la que instalem la c`amera finalment dependr`a de la dist`ancia a la paret de la CAVE a la que la poguem situar. Aix`o pot afegir una distorsi´o adicional a la fotografia degut a la inclinaci´o de la c`amera. L’error afegit en aquest cas es simplement una p`erdua de resoluci´o en les zones m´es allunyades de la c`amera (per exemple, si la situem a ran de terra, tindr`a m´es resoluci´o l’aresta inferior que l’aresta superior de la paret). Per a resoldre aix`o, hem optat per garantir una resoluci´o en les imatges que faci que la precisi´o subp´ıxel es compleixi en les zones m´es desfavorides per aquest factor, amb la qual cosa no s’afegeix cap mena d’error com a conseq¨u`encia d’aquest fenomen. 5.3 C`alcul de les homografies Com s’ha vist al cap´ıtol 3, hem realitzat tota una s`erie de procesos d’an`alisi d’imatges per a computar les diferents homografies necess`aries per a assolir els objectius del projecte. En aquesta secci´o es detallen un a un els m`etodes emprats en cada cas. Cal recordar que per a obtenir la homografia PantallaProjector no es necessita realitzar cap mena d’an`alisi en imatges i, per tant, no hi aprofundim en aquest apartat. 42 CAP´ ITOL 5. CAPTACI ´ O 5.3.1 Homografia C`amera-Pantalla Com s’ha esmentat abans, necessitem obtenir el contorn de la pantalla de la CAVE a partir d’una fotografia on es pot distingir la pantalla gr`acies a la iluminaci´o provocada per una bombeta col · locada a l’altra banda. Per a obtenir aquest contorn, primer es pasa la imatge per un proc`es de filtrat aconseguint una imatge on nom´es ´es visible la pantalla com s’observa a la figura 5.3b. (a) Pantalla il · luminada des del centre de la CAVE (b) Fotografia filtrada per a resaltar la pantalla Figura 5.3: Aplicaci´o del primer filtrat a la fotografia realitzada Aquest proc`es es divideix en els seg¨uents pasos: 1. Eliminar colors segons la intensitat: Ja que nom´es estem iluminant la zona de la pantalla, les zones exteriors a aquesta es veuran molt m´es fosques que les interiors. El que fem es substituir pel color negre el color de tots aquells p´ıxels on la seva intensitat de gris sigui menor a un llindar indicat. Aquesta intensitat de gris es calcula com el promig de la intensitat dels tres canals de color RGB. A partir de la observaci´o de les imatges preses, hem trobat un llindar d’intensitat de gris que ens permet eliminar pr`acticament tota la zona de la fotografia exterior a la pantalla. 2. Tancament: per tal d’eliminar tots aquells p´ıxels externs a la zona de la pantalla que encara romanen a la fotografia aplicarem un filtre de tancament o closing. Aquest filtre serveix per eliminar forats i osques cap a l’interior de les regions. S’aplica a una imatge binaria i pren per entrada una regi´o circular d’un cert radi. El filtre elimina tots aquells conjunts de p´ıxels que estan a¨ıllats en entorns circulars iguals o menors a la regi´o indicada a l’entrada. Amb aquesta imatge filtrada obtindrem ara un conjunt de p´ıxels corresponent a cada costat de la pantalla. Per a fer aix`o, farem servir un senzill algorisme que recorrer`a transversal i longitudinalment la imatge per tal de 5.3. C ` ALCUL DE LES HOMOGRAFIES 43 trobar, en cada direcci´o, el primer i l’´ultim p´ıxel no negre. D’aquesta manera, per`o, a les `arees properes a la intersecci´o entre dues arestes podr´ıem identificar err`oniament p´ıxels d’una aresta que no hi pertanyen realment degut a que la pantalla de la CAVE no es capta perfectament ortogonal als costats de la fotografia i a m´es el proc´es de filtrat pot afegir petits errors. Per a resoldre aix`o, limitarem l’adquisici´o de p´ıxels a una porci´o determinada de la fotografia per tal de tractar nom´es punts que siguin exactament del costat indicat. Un cop hem fet un recull i classificaci´o d’aquests p´ıxels, en calculem les rectes de regressi´o per a cada costat i mitjan¸cant les interseccions dos a dos de les rectes, trobem les quatre cantonades de la pantalla, les quals farem servir per al c`alcul de la homografia Hfent-les correspondre amb els 4 punts de refer`encia de la superf´ıcie normalitzada S(que seran els 4 v`ertexs d’aquesta). 5.3.2 Homografies Projector-C`amera i Projector-Pantalla Per tal de calcular les homografies que relacionen els projectors amb la c`amera i la pantalla, necessitarem identificar els patrons de l´ınies dels que hem parlat a l’apartat 4.1.3. Per tal de facilitar-ne la identificaci´o, en aquest cas el que fem inicialment ´es realitzar una fotografia del sistema sense que es projecti res. Aquesta imatge la restarem a totes les dem´es fotografies per tal de mantenir nom´es les parts diferents (en aquest cas, les l´ınies projectades). (a) Imatge original (b) Imatge despr´es de la resta Figura 5.4: Resultat de la resta del fons a la captura dels patrons El seg¨uent pas consisteix a anar projectant els patrons de l´ınies a cada projector i anar fent les captures. Recordem que per a cada projector es pinten 2 grups de 3 l´ınies horitzontals de colors vermell, verd i blau i 2 grups de 3 l´ınies verticals amb els mateixos colors. Un cop realitzada la fotografia, se n’ha d’extreure la informaci´o relativa a cada l´ınia. Per a fer aix`o, primer aplicarem l’estrat`egia esmentada al primer paragraf d’aquesta secci´o: restem, p´ıxel a p´ıxel, la nova imatge a la imatge del fons aconseguida pr`eviament. Amb aix`o aconseguim que, salvant 44 CAP´ ITOL 5. CAPTACI ´ O alguns petits errors en p´ıxels a¨ıllats, nom´es tinguin color no negre els p´ıxels corresponents a les 3 l´ınies fotografiades tal i com es veu a la figura 5.4. A continuaci´o hem de procedir a identificar cada l´ınia. Gr`acies a haver pintat cada l´ınia amb un dels 3 colors b`asics, podrem identificar a quina l´ınia pertany cada un dels diferents p´ıxels simplement consultant quin ´es el color predominant en cada un d’ells. A m´es, com coneixem pr`eviament l’ordre de les l´ınies i la seva orientaci´o (tot i que poden no ser perfectament ortogonals als costats de la imatge, ho s´on aproximadament) aprofitem aquestes dades per a realitzar una cerca ordenada. ´ Es a dir, per a identificar les l´ınies horitzontals, cercarem la imatge fent escombrats dels p´ıxels fila a fila des de la fila inferior i per a les l´ınies verticals ho farem columna a columna i de dreta a esquerra. Aix´ı, realitzarem primer la cerca de p´ıxels vermells, despr´es verds i despr´es blaus. Amb aquesta estrat`egia, amb un ´unic recorregut de la imatge podem classificar tots els p´ıxels evitant que per culpa de petits errors en la identificaci´o del color del p´ıxel aquests quedin barrejats. Figura 5.5: Superposici´o dels 4 patrons de l´ınies. Una vegada classificats els p´ıxels de les 3 l´ınies, nom´es queda calcularne la recta de regressi´o i fer servir aquesta informaci´o per a realitzar els c`alculs descrits en seccions anteriors per a trobar els punts d’intersecci´o. A la figura 5.5 es pot observar la superposici´o de les 4 imatges captant els 4 conjunts diferents de l´ınies per a un projector. Un cop procedim a calcular les interseccions de les l´ınies, haur´ıem de trobar els punts que conformen els v`ertexs dels quadrats que formen la graella i calcular aix´ı les homografies dessitjades. Cap´ıtol 6 Arquitectura En aquest cap´ıtol es presenta detalladament l’arquitectura del projecte. S’- explicar`a per un costat els detalls de tots els components f´ısics del sistema i per l’altre com s’interconnecten i es comuniquen entre ells. 6.1 Descripci´o dels equips Com ja hem descrit a l’apartat 1.3.2, els elements f´ısics que necessitarem s´on, per a cada paret de la CAVE:  Sis projectors.  Tres ordinadors.  Dues estructures de suport.  Una c`amera de fotografiar. Tot seguit, procedirem a descriure les caracter´ıstiques de cadascun dels models escollits per a cada tipus de component. Projectors Tal i com ja s’ha esmentat, volem reduir al m´ınim el cost del nostre sistema i, per tant, farem servir projectors comercials amb un cost inferior a 500 ¿ . Hem optat per uns projectors CASIO XJ-S32. Ens ofereixen una resoluci´o nativa de 1024×768 p´ıxels, la qual implicar`a tenir una resoluci´o m`axima de 2048 ×2304 p´ıxels per a tota l’extensi´o de la pantalla. A m´es, aquests projectors tenen un mode de configuraci´o que permet la seva encesa autom`atica en rebre corrent i que tamb´e fa que s’apaguin autom`aticament als 5 minuts de no rebre senyal d’entrada. Aix´ı doncs, podem endollar tots els projectors a una regleta de corrent amb interruptor i encendre’ls tots alhora simplement mitjan¸cant aquest, amb la qual cosa 45 46 CAP´ ITOL 6. ARQUITECTURA guanyem comoditat al no haver d’encendre els projectors un a un de forma manual o mitjan¸cant el comandament a dist`ancia. Figura 6.1: Projector CASIO XJ-S32 Ordinadors Per a realitzar tot el control i computaci´o del nostre software necessitem comptar amb tres ordinadors equipats amb targetes gr`afiques duals. La nostra aplicaci´o no necessita una gran pot`encia de c`alcul ni de renderitzat gr`afic, ja que les tasques que realitza s´on c`alculs matem`atics poc complexos i optimitzats gr`acies a les llibreries utilitzades (veure apartat 2.1). Tot i aix´ı, les aplicacions que hauran d’aprofitar la informaci´o obtinguda al proc`es de calibraci´o si que poden ser aplicacions de computaci´o complexa (com pot ser la visualitzaci´o de dades m`ediques o d’entorns d’alt realisme). Per aquest motiu, els equips que s’han adquirit compten amb les seg¨uents caracter´ıstiques:  Font d’alimentaci´o Tacens Radix Supero de 1000W.  Placa base Intel socket 1366 model DX58S0.  CPU Intel core I7 950 (HT 4 nuclis / 8 vies d’execuci´o / 3,06Ghz / 8Mb de cach´e).  8 Gb de mem`oria DDR3 1066Mhz (ampliable a 16Gb).  Unitat de disc de 320 Gb SATA-2 Seagate.  2 targetes gr`afiques nVidia GeForce GTX 285. Estructures Els projectors s’instal · len en unes torres fabricades expressament al CRV per a les necessitats del projecte. Aquestes torres tenen capacitat per a 6 projectors, agrupats de dos en dos en 3 al¸cades diferents. Aquest muntatge est`a fet pensant en el desenvolupament del sistema de visi´o est`ereo passiu, on els 6.1. DESCRIPCI ´ O DELS EQUIPS 47 dos projectors que es troben a la mateixa al¸cada (tot i que, t`ecnicament, un est`a una mica per sobre de l’altre) projecten cada un la imatge corresponent vista des d’un ull diferent. Per convenci´o, els projectors de l’ull esquerra els situarem a la safata inferior, mentres que els de l’ull dret els situarem a la safata superior. Aquesta convenci´o, per`o, la prenem senzillament per un tema d’ordre i organitzaci´o del cablejat, ja que l’´unic requeriment que tenen els nostres projectors ´es que les `arees projectades per tots els projectors d’un mateix ull cobreixin completament tota la pantalla, sense deixar cap mena de forat entre ells. (a) (b) Figura 6.2: Estructura de suport dels projectors En aquestes estructures hi ha tamb´e uns receptacles per als filtres polaritzadors, necessaris per a la realitzaci´o d’est`ereo passiu. Tamb´e hi instal · larem les regletes de corrent que hem esmentat a l’apartat dels projectors. C`amera La c`amera de fotografiar que hem comprat per a la realitzaci´o del projecte ´es una Canon EOS D1000 amb un objectiu 15-85mm. Aquesta `optica ens permet realitzar les fotografies a aproximadament 1.5m d’al¸cada i a una dist`ancia de 4m. La seva resoluci´o m`axima ´es de 10.2Mp i podem configurar, entre d’altres par`ametres, el temps d’exposici´o i la sensibilitat del sensor, la qual cosa ens permet tenir un control total sobre la llum captada per la c`amera (fet crucial en el nostre cas, sobretot en l’apartat de calibratge crom`atic). 54 CAP´ ITOL 7. LLIBRERIES Amb aquestes quatre funcionalitats en tindrem prou per a realitzar totes les operacions que necessitem amb la c`amera. 7.1.3 Implementaci´o La implementaci´o d’aquesta llibreria ´es una mica diferent a la de la resta, ja que no actua com a llibreria intermitja entre el nostre sistema i una tercera llibreria, si no que reimplementa una llibreria ja existent anomenada libgphoto2, per tal d’adaptar el codi ja existent a les nostres necessitats. Hem aprofitat que aquesta llibreria incorpora un programa que la utilitza per a realitzar totes les funcionalitats implementades (anomenat gphoto2). Expliquem ara doncs com hem implementat les funcionalitats que hem especificat en l’apartat anterior a partir d’aquestes. Carregar la c`amera Per a carregar la c`amera al sistema, hem creat la funci´o loadCamera, que implementa el codi d’inicialitzaci´o de l’aplicaci´o gphoto2. Aquest codi s’encarrega de cercar les c`ameres conectades als diferents ports del PC, identificarne el model i les caracter´ıstiques i obrir una conexi´o amb aquests ports per a comunicar-s’hi. Realitzar i descarregar fotografia La llibreria original implementa una crida anomenada capture generic, que permet realitzar fotografies amb diversos par`ametres de configuraci´o. Un d’aquests ´es la possibilitat de realitzar la fotografia, descarregar-la al PC i esborrar-la de la c`amera en un sol pas. Aix´ı doncs, la nostra funci´o captureAndDownload cridar`a a aquesta funci´o amb el par`ametre que permet fer aquestes tres operacions en una ´unica crida. Tancar la c`amera Hem implementat una funci´o anomenada closeCamera, que crida a la funci´o de la llibreria original gp params exit que ens permet tancar els ports oberts i esborrar la pres`encia de la c`amera al sistema. 7.2 LibSocks 7.2.1 Motivaci´o En el nostre sistema tenim diferents entitats independents que necessiten comunicar-se entre elles per tal de poder realitzar totes les tasques necess`aries per al correcte funcionament del proc´es. ´ Es per aix`o que necessitem un m`odul per gestionar totes les funcions de comunicaci´o. 7.3. LIBHOMOGRAPHY 55 7.2.2 Funcionalitats Com en tot sistema de missatges necessitem, b`asicament, dues funcions:  Enviar missatges: una entitat ha de poder enviar informaci´o a altres entitats.  Rebre missatges: les entitats han de rebre la informaci´o enviada pels altres. 7.2.3 Implementaci´o La llibreria LibSocks ´es una petita adaptaci´o de la llibreria LibSockets d’Alhem. En aquest cas s’ha especialitzat una classe de la llibreria original de dues maneres diferents, per tal de facilitar la gesti´o dels missatges dintre del sistema. Aquestes dues classes noves es corresponen cada una a una de les dues funcionalitats especificades a l’apartat anterior. Enviar missatges Per a l’enviament de missatges, el que hem fet ha sigut implementar la classe SendSocket, especialitzaci´o de la classe TCPSocket amb un buffer per emmagatzemar els missatges sortints i una funci´o per omplir el buffer i ordenar l’enviament del seu contigut pel socket. Amb aix`o en tenim prou, un cop configurat el socket amb el port i la direcci´o IP corresponents, per enviar informaci´o sortint a trav´es seu. Rebre missatges La recepci´o de missatges es gestiona des de la classe RecieveSocket, que ´es una altra especialitzaci´o de la classe TCPSocket. Aquesta nova classe cont´e un buffer on enmagatzemarem l’´ultim missatge llegit i una funci´o que es llen¸car`a cada cop que es demani la lectura del socket (OnRead). Aquesta funci´o llegeix la informaci´o del socket al buffer d’entrada i la copia al buffer de la classe per a que sigui accesible des del gestor de recepci´o de missatges. 7.3 LibHomography 7.3.1 Motivaci´o Una de les parts m´es importants del projecte ´es la utilitzaci´o d’homografies per a realitzar les transformacions entre imatges 2D. LibHomography s’encarrega de subministrar totes les eines necess`aries per a computar i utilitzar homografies. 56 CAP´ ITOL 7. LLIBRERIES 7.3.2 Funcionalitats Per a poder dur a terme tots els objectius, necessitem que la llibreria s’encarregui dels seg¨uents aspectes:  Tipus de dades: necessitem una forma d’emmagatzemar les homografies de forma general.  Dades d’entrada: necessitem crear un tipus de dades per a poder nodrir el sistema de c`alcul.  C`alcul: haurem d’implementar el c`alcul de les homografies amb els dos m`etodes descrits a la secci´o 3.2 (m`etode homogeni i m`etode no homogeni). 7.3.3 Implementaci´o Veiem ara com s’ha resolt la implementaci´o de les diferents funcionalitats requerides. Ens hem servit de la llibreria newmat10 per a realitzar-la de forma eficient i compacta. Tipus de dades Hem creat un tipus de dades anomenat Homography, que contindr`a totes les funcions referents a les homografies i les dades referents a les pr`opies homografies. Les homografies 2D s´on matrius de dimensi´o 3 ×3, per tant necessitarem un vector de 9 components per a representar-les (mSimpleHomography). Tanmateix, al nostre sistema les farem servir tenint en compte que el nostre ´es un espai 3D i, per tant, necessitarem homografies de dimensi´o 4 ×4. Necessitarem doncs un altre vector de 16 components per a representar aix`o (mHomography). Paral · lelament, tenint en compte el tipus de dades que necessitem per als c`alculs realitzats amb newmat10, necessitarem a m´es dues matrius m´es: una per enmagatzemar el resultat final del c`alcul abans de traspasar-lo al vector que representa la homografia (mAuxHomography) i una altra per anar enmagatzemant per al c`alcul les dades d’entrada (mDataMatrix). Dades d’entrada Per a calcular les homografies hem vist que ´es necessari aportar correspond`encies entre p´ıxels de les dues imatges sobre les quals es vol calcular l’homografia. Per a implementar aix`o, hem creat una altra classe Correspondence, que cont´e dos tipus de dades:  PPixel: representa un p´ıxel 2D en coordenades homog`enies (per tant, amb 3 components x,y i w). 7.4. LIBIMAGES 57  Correspondence: representa un parell de PPixel entre els quals hi ha correspond`encia en les imatges. C`alcul Hem separat internament el c`alcul de les homografies en 3 pasos diferents per a fer el codi m´es entendible. El punt d’entrada ´es la funci´o computeHomography que rebr`a com a par`ametres d’entrada un vector de Correspondence i el m`etode de c`alcul a utilitzar (estimaci´o homog`enia o no homog`enia). a partir d’aqu´ı, el proc`es ´es el seg¨uent: 1. Poblar la matriu de dades: a partir de les diferents parelles de p´ıxels corresponents, anirem omplint mDataMatrix de la forma descrita per a crear la matriu amb la que fer els c`alculs. 2. Computar la homografia: depenent del m`etode de c`alcul triat ´es cridar`a a homogeneousHomography o a nonHomogeneousHomography. Cada m`etode implementa una de les estrat`egies descrites a la secci´o 3.2. 3. Convertir la homografia: en l’´ultim pas, amb la homografia ja calculada, la transformarem d’una homografia de dimensi´o 3 ×3 a una de dimensi´o 4 ×4 on la component z dels p´ıxels a transformar es conservar`a (recordem que nom´es volem transformacions 2D i, per tant, de x i y). 7.4 LibImages 7.4.1 Motivaci´o Per a poder extreure informaci´o de les fotografies que prenem, necessitem tenir m`etodes que ens permetin rec`orrer i analitzar imatges. A m´es, necessitarem tenir, adicionalment, tota una s`erie d’algorismes de tractament de fotografies per a poder fer m´es precises les operacions que volguem fer sobre les fotografies. Per a aix`o hem creat LibImages que, amb l’´us de la llibreria VXL, ens permetr`a assolir tots aquests objectius. 7.4.2 Funcionalitats La llista de necessitats que ens caldr`a cobrir amb la present llibreria ´es la seg¨uent:  Tipus de dades: necessitarem crear un tipus de dades que sigui una abstracci´o de la imatge i ens permeti interactuar amb ella de forma senzilla. 58 CAP´ ITOL 7. LLIBRERIES  Entrada/Sortida: hem de ser capa¸cos de llegir i escriure imatges a disc.  Operacions bin`aries: volem tenir operacions de resta i multiplicaci´o entre dues imatges.  Operacions un`aries: necessitarem operacions com l’aplicaci´o d’un filtre de tancament o resaltat de colors.  Correcci´o de la distorsi´o de barril: corregir la distorsi´o provocada per l’`optica.  Operacions d’an`alisi: totes les operacions per classificar l´ınies, trobar els marges, etc... que hem vist al projecte.  Dades per a generalitzar els patrons: necessitem un tipus de dades per a poder generalitzar els tipus de patrons que podem fer servir al projecte. 7.4.3 Implementaci´o Procedim a explicar doncs la implementaci´o de les funcionalitats exposades. Tipus de dades Hem creat la classe SimpleImage per a que actui com a abstracci´o de les imatges. La llibreria VXL treballa amb refer`encies i vistes sobre les imatges, permetent estalviar espai en mem`oria al carregar nom´es una vegada la imatge i generant diferents vistes amb diversos tipus de dades per a la mateixa imatge. Nosaltres aprofitem aix`o per a tenir 3 vistes de la imatge carregada: una vista amb els tres canals RGB (mOriginalImage) que ser`a la vista de la imatge en disc, una com a tira de bytes sense saber la quantitat de canals (mActualImg) que ser`a sobre la que treballem normalment i una ´ultima vista bin`aria (mBinaryImg) que farem servir per a alguns filtres. Com a funcions de consulta hem implementat getWidth igetHeight per a coneixer les dimensions de la imatge i l’operador() per a consultar el color d’un p´ıxel en uns dels 3 canals de la imatge. Entrada/Sortida Per a l’apartat d’entrada i sortida, la llibreria VXL ens aporta tot una interficie per carregar vistes d’una imatge i per guardar-la f´ısicament a disc amb les funcions vil load ivil save respectivament. Adicionalment, mantindrem dues estructures de punters intel · ligents, un per a la imatge inicial i un altre per a la imatge actual per tal de facilitar les c`opies i l’entrada i sortida en els diferents formats. 7.4. LIBIMAGES 59 Operacions bin`aries Nom´es hem implementat dues operacions bin`aries: la resta i la multiplicaci´o. La resta (substractImage) pren com a entrada una imatge de tipus SimpleImage i la resta, p´ıxel a p´ıxel, de la imatge actual. La multiplicaci´o (fuseImage) treballa nom´es de forma interna en la imatge, i el que multiplica ´es la imatge bin`aria (mBinaryImage) i la imatge actual, deixant el resultat en la imatge actual. Operacions un`aries Com a operacions un`aries tenim el resaltat de p´ıxels amb un llindar d’intensitat de gris indicat com a par`ametre (applyRGBRealtorFilter), que substitueix pel color negre el color de tots els p´ıxels que no superin aquest llindar i els filtres de tancament i d’obertura (applyClosingFilter iapplyOpeningFilter respectivament), encara que el d’obertura no el fem servir en aquests moments. Correcci´o de la distorsi´o de barril La funci´o correctSphericalDistortion s’encarrega de rec`orrer tota la imatge des del centre cap als extrems aplicant la funci´o correction, que implementa l’estrat`egia de correcci´o de la distorsi´o comentada a l’apartat 5.2.1. A m´es, la funci´o permet ordenar l’emplenat dels p´ıxels que han quedat sense informaci´o degut a la deformaci´o, a partir de calcular el color promig dels p´ıxels del voltant. Operacions d’an`alisi Un cop hem implementat totes les funcions que han de corregir i refinar les dades que veurem a les imatges, podem procedir a implementar tots aquells processos que n’extreuen informaci´o. S´on els seg¨uents:  Calcular rectes de regressi´o: en diferents punts dels processos d’an`alisi haurem de calcular l´ınies de regressi´o a partir de conjunts de p´ıxels. La funci´o calculateRegression s’encarrega d’aquest c`alcul i la funci´o drawRegressionLine la dibuixar`a a la imatge si es vol tenir un refor¸c visual per a l’an`alisi dels resultats.  Trobar l´ınies de colors: la funci´o findColoredLines, cercar`a a dins de la imatge les l´ınies dels patrons i en classificar`a els p´ıxels tal i com hem explicat a la secci´o 5.3.2.  Trobar les arestes de la pantalla: la funci´o getBorders, s’encarrega de trobar els l´ımits detectats de la pantalla de la CAVE, implementant l’estrat`egia que s’explica a la secci´o 5.3.1. 60 CAP´ ITOL 7. LLIBRERIES Dades per a generalitzar els patrons Hem creat una classe anomenada LinePattern per a generalitzar un patr´o de l´ınies. La ´unica informaci´o que aporta aquest patr´o ´es el nombre de l´ınies que hi ha i els colors d’aquestes. Aquesta classe llegeix el patr´o d’un fitxer pla de text amb un format especificat (veure ap`endix B per a m´es informaci´o). La llibreria, adicionalment, consta de tota una s`erie d’operacions d’analisi i modificaci´o extres, fruit de les diverses estrat`egies diferents analitzades per a assolir els objectius del projecte, com poden ser aplicar una homografia a la imatge, trobar grups de punts a¨ıllats en la imatge, etc. Tots aquests s’han conservat al codi com a recursos ´utils per a altres situacions, per`o no tenen cap utilitat en el projecte actual. Cap´ıtol 8 El Programa Un cop presentada tota l’estructura que envoltar`a el nostre programa i les llibreries que utilitzarem per a desenvolupar-lo, procedirem a exposar el seu disseny. En aquest cap´ıtol es mostraran tant la conceptualitzaci´o de les classes que el formen com els casos d’´us dissenyats per al seu funcionament. 8.1 Mapes conceptuals Per tal de fer m´es entenedors els mapes, hem procedit a classificar-los en grups per a fer-ne un analisi m´es detallat. 8.1.1 Comunicacions En aquest apartat, analitzem totes les classes responsables de la comunicaci´o entre les diferents entitats que composen el nostre sistema. Com s’observa a la figura 8.1, tenim quatre classes que s´on una especialitzaci´o de classes de la nostra llibreria LibSocks:  ThreadRecieveSocket: ´es l’encarregada de rebre i gestionar els missatges en les entitats de tipus Esclau per a un Socket.  ThreadSocketHandler: ´es el SocketHandler de les entitats de tipus Esclau. Els SocketHandlers s´on unes classes que s’encarreguen d’agrupar tots els Sockets de recepci´o d’una mateixa entitat per tal de gestionar-ne els events que sobre ells actuen.  WindowRecieveSocket: ´es l’encarregada de rebre i gestionar els missatges en les entitats de tipus M`aster per a un Socket.  WindowSocketHandler: ´es el SocketHandler de les entitats de tipus M`aster. 61 62 CAP´ ITOL 8. EL PROGRAMA Figura 8.1: Diagrama de les classes responsables de la comunicaci´o. 8.1.2 Esclaus A la figura 8.2 es poden observar totes les classes que formen part de les entitats de tipus Esclau. Cada esclau s’encarrega de la gesti´o de dos projectors per a cada ull. La manera de que estiguin els dos controlats i sincronitzats per`o que, alhora, siguin independents l’un de l’altre ´es que cada costat sigui controlat per un fil d’execuci´o diferent. ´ Es per aix`o que les entitats Esclau seran representades per ClientThread, un fil d’execuci´o que s’encarrega de mantenir dos GLWidget, sincronitzantlos i compartint informaci´o entre ells per mitj`a de la classe Data. Per via del ThreadSocketHandler, l’Esclau es comunicar`a amb el M`aster tal i com hem explicat anteriorment. Per a que cada un dels GLWidget realitzi les seves funcions a la targeta gr`afica adient, haurem d’assignar el context gr`afic a cada una d’elles de forma expl´ıcita. Per a assolir aquest objectiu hem creat la classe MyQGLContext, que ens realitzar`a tota aquesta asssignaci´o de forma transparent a l’usuari. L’execuci´o de cada GLWidget ´es controlada per un GLThread. Aquesta ´es la classe encarregada del gruix de la feina que es realitza a cada un 8.1. MAPES CONCEPTUALS 63 Figura 8.2: Diagrama de les classes responsables dels Esclaus. dels Esclaus. ´ Es la responsable del pintat, el c`alcul de les m`ascares, les homografies i la seva aplicaci´o al proc`es. Per a realitzar totes aquestes operacions, la classe utilitza les llibreries LibImages i LibHomog que hem descrit al cap´ıtol anterior. 8.1.3 M`aster En el cas de l’entitat M`aster tenim un sistema bastant m´es senzill ja que nom´es hi interv´e una classe en la computaci´o. Com hem esmentat a l’apartat 6.3.1, dotarem el sistema d’una interf´ıcie gr`afica per a realitzar la comunicaci´o amb l’usuari. Ser`a doncs la classe ServerWindow l’encarregada de recollir la informaci´o de la interf´ıcie per a processar-la i enviar els missatges corresponents per mitj`a dels Sockets gestionats pel WindowSocketHandler corresponent. A m´es, al ser l’entitat encarregada de controlar la c`amera de fotos i realitzar el c`alcul de l’homografia C`amera-Pantalla, utilitzar`a les llibreries LibFoto, LibHomo i LibImages descrites al cap´ıtol 7. 70 CAP´ ITOL 8. EL PROGRAMA Part III Resultats 71 Cap´ıtol 9 An`alisi final Un cop finalitzada l’exposici´o de tots els components del nostre projecte, procedirem en aquest cap´ıtol a presentar-ne l’an`alisi final. En ell exposarem primer totes aquelles estrat`egies implementades que han sigut descartades durant la realitzaci´o d’aquest i la ra´o del seu rebuig. Finalment, veurem el resultat final de l’aplicaci´o i presentarem les conclusions extretes. 9.1 Estrat`egies rebutjades Hem probat diferents estrat`egies de c`alcul en els calibratges geom`etric i crom`atic, donada la import`ancia d’obtenir un calibratge d’alta precisi´o. Tamb´e hem intentat realitzar una correcci´o de la distorsi´o radial de les fotografies amb una t`ecnica diferent a la proposada en el projecte. 9.1.1 Calibratge geom`etric El primer obstacle a resoldre ha sigut la identificaci´o del marge de la pantalla. Per a fer aix`o necessit`avem marcar-lo d’alguna manera i captar aquestes marques des de la c`amera. Les opcions que ten´ıem es poden classificar en dos grups:  Marcadors passius: marcadors que responen a est´ımuls externs per a ser clarament visibles (per exemple, adhesius reflectants).  Marcadors actius: marcadors que emeten un senyal per si mateixos (per exemple, bombetes). Adhesius reflectants La primera estrat`egia que vam intentar va ser la de fer servir adhesius reflectants que responguessin al flash de la c`amera. Per a situar en una posici´o precisa els adhesius vam adquirir cinta m`etrica adhesiva. 73 74 CAP´ ITOL 9. AN ` ALISI FINAL El problema principal que se’ns va presentar va ser la manipulaci´o dels adhesius reflectants. Per a que el sistema fos prec´ıs necessit`avem tenir quadrats adhesius d’1mm de costat per a tenir precisi´o subp´ıxel a l’hora de detectar el marge de la pantalla. Colocar artesanalment i amb precisi´o aquests adhesius va resultar realment un inconvenient, i m´es tenint en compte que el per´ımetre a cobrir amb els marcadors ´es de 12m. Tot aix`o va fer que es descart´es aquesta estrat`egia. (a) (b) Figura 9.1: Cinta m`etrica adhesiva i adhesius reflectants. Tires de LEDs La seg¨uent estrat`egia plantejada va ser la d’optar per uns marcadors actius. Es va pensar en algun sistema basat en LEDs (les sigles per a Light Emitting Diode, ´es a dir, diode emissor de llum) degut al seu baix consum i alta lluminositat i a que el mercat ens presenta diverses solucions de f`abrica en forma de tires d’aquests components. Lamentablement, de totes aquestes solucions no ens ha conven¸cut cap, ja fos pel seu elevat cost o per la poca flexibilitat a l’hora de configurar-les. ´ Es per aix`o que vam intentar fer-ho artesanalment. Vam crear una s`erie de tires de LEDs soldant els diferents components necessaris a un cablejat i ho vam instal · lar dintre de canals el`ectrics foradats cada 20mm per a adherir-los al marge de la pantalla i captar aix´ı la llum que sortia per aquests forats. Aquest sistema, per`o, va tornar a mostrar-se inefica¸c donat als petits errors de precisi´o que ens aportava el sistema fet a m`a i el vam acabar descartant. 9.1.2 Calibratge crom`atic Per al c`alcul de les m`ascares de correcci´o crom`atica vam probar diferents estrat`egies abans de triar l’exposada en aquest document. A continuaci´o 9.1. ESTRAT` EGIES REBUTJADES 75 Figura 9.2: Exemple de tira de LEDs. explicarem les dues amb les que m´es temps hem estat probant i modificant. M`ascares via framebuffer Vam intentar pintar les m`ascares directament via c`opia del framebuffer dels projectors, pintant-hi una s`erie de quads en escala de grisos amb els que delimit`avem de forma manual les zones fins on vol´ıem que arrib´es el solapament entre projectors i realitzant els degradats depenent del nombre de projectors que, en teoria, s’havien de solapar en aquella zona. Aquesta t`ecnica ens oferia un control perfecte de les zones iluminades per cada projector per`o era tamb´e molt inefica¸c, sobretot en les zones de solapament entre 4 projectors ja que els petits errors de la calibraci´o geom`etrica feien que zones de la m`ascara que haurien d’estar pintades amb els degradats de les zones de 4-solapament (on n-solapament vol dir solapament de n projectors) es pintessin amb degradats de les zones de 2-solapament i viceversa. Baar, Raskar i Xiang Vam rec`orrer doncs a l’algorisme proposat per Baar, Raskar i Xiang[7], que s’havia mostrat correcte tal i com es veia en el document. Tot i aix´ı, vam trobar-nos amb el problema que es mostra a la figura 9.3. En aquesta imatge es veu clarament que les intensitats dels projectors en les zones de solapament no es sumen correctament i la lluminositat total en aquestes no ´es la unitat. La soluci´o proposada en l’apartat 4.2.3 resol aquest problema de forma bastant efica¸c i sense afegir cap iteraci´o adicional al proc´es de calibratge crom`atic. 9.1.3 Correcci´o de la distorsi´o radial El model que hem fet servir per a corregir la distorsi´o radial de les fotografies ´es un model bastant simplificat i afegeix petits errors que provoquen que el calibratge geom`etric sigui lleugerament pitjor del que dessitjar´ıem. Hi ha, 76 CAP´ ITOL 9. AN ` ALISI FINAL Figura 9.3: Resultat d’aplicar el feathering de Baar, Raskar i Xiang. per`o, un altre model molt m´es complex que hem intentat implementar per a fer-ho. Aquest model es conegut com a model de c`amera de Tsai. Per a aplicarlo, necessitarem calibrar la c`amera amb algun software que, a partir de visualitzar un model tipus tauler d’escacs, ens permeti extreure tots els par`ametres impl´ıcits de la c`amera que hem vist a l’apartat 5.2.1. Un cop realitzada la calibraci´o podrem aplicar diverses equacions per a corregir la posici´o de cada p´ıxel de la fotografia. Implementar aquest m`etode ´es molt cost´os a nivell temporal i per aix`o l’hem rebutjat, per`o ´es molt possible que millori el resultat final de la calibraci´o geom`etrica del sistema. 9.2 Resultat final i conclusions 9.2.1 Resultat En aquesta secci´o presentem el resultat final del nostre projecte. Recordem breument quin era el nostre objectiu: vol´ıem dotar el sistema CAVE d’una s`erie de projectors que havien d’actuar com si fossin un de sol. Per a fer aix`o, hem dut a terme tot un proc`es de calibratge geom`etric per a alinear els projectors entre ells i amb la pantalla de la CAVE corresponent i un proc`es de calibratge crom`atic per a igualar la lluminositat de tota l’`area de projecci´o. El resultat que obtenim de tot aix`o ´es el mostrat a la figura 9.4. Per a reutilitzar tot el proc´es, s’han anat desant a disc tant les homografies calculades com les m`ascares de correcci´o crom`atica. Aix´ı doncs, qualsevol aplicaci´o convenientment adaptada les podr`a utilitzar per a fer 9.2. RESULTAT FINAL I CONCLUSIONS 77 servir el dispositiu CAVE. Figura 9.4: Resultat final del calibratge. 9.2.2 Conclusions Vist el resultat, podem concloure que hem assolit els seg¨uents objectius que ens hav´ıem marcat:  Hem definit l’arquitectura del sistema de forma completa.  Tenim un sistema de 6 projectors calibrats geom`etricament. Aquest proc`es ´es extensible als altres 6 projectors corresponents a l’altre ull de la mateixa paret. Per tant, tenim els 12 projectors calibrats geom`etricament.  Tenim una s`erie de m`ascares per realitzar la correcci´o crom`atica dels 6 projectors. De la mateixa manera que el calibratge geom`etric, el calibratge crom`atic tamb´e ´es generalitzable als altres 6 projectors. Per tant, tenim els 12 projectors calibrats crom`aticament. No hem acomplert l’objectiu d’igualar la lluminositat de dues pantalles de la CAVE per les dificultats t`ecniques que provoca el canvi de les parets del dispositiu i que no ens permet adquirir de moment cap equip nou. Tanmateix, l’objectiu, a priori, ´es un refinament de les m`ascares computades al calibratge crom`atic i no hauria d’afegir cap tipus de dificultat t`ecnica nova. Aix´ı doncs, considerem satisfactoris els resultats obtinguts tot i que hi ha aspectes a millorar dels quals parlarem m´es endavant. 78 CAP´ ITOL 9. AN ` ALISI FINAL 9.3 An`alisi de costos En aquest cap´ıtol s’ha dut a terme un breu an`alisi de costos del projecte, on es calcula, per una banda, el cost dels treballadors que hi haurien estat implicats i, per l’altra, el del maquinari que s’ha hagut d’adquirir. ´ Es important adonar-se de la relev`ancia que t´e realitzar una bona planificaci´o per tal de calcular amb precisi´o el cost del projecte abans de comen¸car-lo. Haver fet una bona planificaci´o al principi de les tasques i les seves duracions, aix´ı com preveure qui se n’hauria d’encarregar, permet estimar molt b´e el cost que caldria assumir per a desenvolupar-lo. En aquest cas, per`o, s’ha utilitzat la seva duraci´o real, enlloc de l’estimaci´o inicial. D’aquesta manera, el que obtenim al final ´es el cost real que representa. 9.3.1 Cost salarial Primerament, cal notar que les tasques necess`aries per a dur a terme el projecte requereixen l’acci´o de treballadors amb diferents habilitats. En el nostre cas, aquestes quedaven cobertes amb dos rols: un analista i un programador. Dedicaci´o dels treballadors A cadascun dels rols se l’hi assigna les tasques que li pertoca desenvolupar i, per cadascuna, en quina mesura ho fa. Aix`o permet determinar quantes hores ha dedicat a una tasca en concret i, conseq¨uentment, quantes hores ha dedicat en total al projecte. Tota aquesta informaci´o la podeu veure recopilada a les taules 9.1 i 9.2. Aix´ı, per exemple, si alg´u ha dedicat dos dies de feina a una tasca determinada, ´es a dir, un total de setze hores, per`o nom´es amb un 50% de dedicaci´o, hi hauria dedicat un total de 16h×50% = 8h. Activitat Dies Dedicaci´o Hores Especificaci´o i disseny de les llibreries 60 100% 480 Especificaci´o del m`odul de calibratge 40 50% 160 Disseny del m`odul de calibratge 60 50% 240 Especificaci´o i disseny de l’aplicaci´o d’usuari 2 100% 16 Total d’hores 896 Taula 9.1: Hores invertides per l’analista del projecte 9.3. AN ` ALISI DE COSTOS 79 Activitat Dies Dedicaci´o Hores Implementaci´o de les llibreries 40 70% 224 Desenvolupament calibratge geom`etric 80 70% 448 Desenvolupament calibratge crom`atic 60 70% 336 Desenvolupament del m`odul de visualitzaci´o 5 100% 40 Escriptura de resultats 5 100% 40 Total d’hores 1088 Taula 9.2: Hores invertides pel programador del projecte Salaris Despr´es de con`eixer la dedicaci´o en hores al projecte de cada treballador, cal saber quina ´es la seva retribuci´o per hores per tal de poder calcular-ne el cost. Per tal de fer-nos una idea del salari mig d’un analista i d’un programador s’ha consultat la web de comparaci´o de tend`encies d’InfoJobs [2]. A la seg¨uent figura es pot veure l’evoluci´o dels salaris de cadascun d’ells: Figura 9.5: Evoluci´o mitja en els ´ultims 24 mesos dels salaris d’un analista i d’un programador (en vermell i verd, respectivament). Finalment, tal i com veiem a la figura 9.5, assumim que el sou mig d’un programador ´es de 26 000 ¿ /any i el d’un analista ´es de 29 500 ¿ /any. Si suposem que aquestes quantitats es divideixen en 14 pagues, i que cada mes consta de quatre setmanes amb cinc dies laborables cadascuna d’elles, i amb vuit hores per dia, hem de dividir aquestes quantitats per 14×4×5×8 = 2240 86 AP` ENDIX A. MANUAL D’INSTRUCCIONS A.2.1 Execuci´o en mode M`aster Per a iniciar el programa en mode M`aster farem servir la seg¨uent comanda: >./visualitzador s <n> On sindica que s’executar`a el programa en mode M`aster i n´es el nombre d’Esclaus que s’han de conectar per comen¸car l’execuci´o del programa. A.2.2 Execuci´o en mode Esclau Per als nodes de tipus Esclau, l’aplicaci´o es llen¸ca de la seg¨uent manera: >./visualitzador c <port> <IP> On cindica que s’executar`a el programa en mode Esclau, <port>indica el port que es far`a servir per a comunicar-se amb el M`aster i <IP>indica la IP de la m`aquina que executa el programa. Si s’omet el par`ametre <IP>, es considera que la m`aquina ´es la mateixa que exerceix de M`aster i si s’omet tamb´e el par`ametre <port>, es considera per defecte el port 9001 (no es pot ometre el par`ametre <port>i explicitar el par`ametre <IP>). A.3 ´ Us de l’aplicaci´o A la figura A.1 es mostra la interf´ıcie gr`afica de l’aplicaci´o de calibratge. A continuaci´o explicarem la seva organitzaci´o i les funcions que controla cada bot´o. Figura A.1: Interf´ıcie gr`afica de l’aplicaci´o. ` Area de notificaci´o A la zona inferior hi podem veure una `area de notificaci´o on el sistema ens informa de qualsevol error que pugui apar`eixer durant l’execuci´o i tamb´e ens mostra quan s’han enllestit les diferents tasques. A.3. ´ US DE L’APLICACI ´ O87 C`amera El bot´o de la zona superior dreta serveix per a realitzar una fotografia amb la c`amera i descarregar-la a l’ordinador. Canvia Fons Aquest ´es el bot´o encarregat d’ordenar el canvi del color de fons de l’aplicaci´o. Checkbox Carrega Amb aquesta checkbox marquem si volem carregar les fotografies manualment de disc o si pel contrari volem que es vagin realitzant autom`aticament amb la c`amera de fotografiar. Aquesta opci´o afecta als tres procesos de calibratge. Calibra C`amera Amb aquest bot´o ordenem a l’aplicaci´o que realitzi el calibratge de la c`amera respecte a la pantalla. Cal recordar que necessitem encendre la llum de l’interior de la CAVE abans de realitzar aquest proc´es i apagar-la tot seguit. Calibra Aquest bot´o controla la funci´o de realitzar el calibratge geom`etric dels projectors. Crom`atica Per ordenar a l’aplicaci´o que realitzi el calibratge crom`atic farem servir aquest bot´o. Pinta Aquest bot´o ens permet canviar el mode de pintat de l’aplicaci´o entre pintar la imatge carregada o no pintar res (amb el que veurem el color de fons seleccionat). 88 AP` ENDIX A. MANUAL D’INSTRUCCIONS Ap`endix B Dades L’objectiu principal del projecte ´es realitzar el calibratge per a poder tenir una s`erie de dades que permetin a altres aplicacions utilitzar els sistema CAVE. Per a fer aix`o, necessitem desar les homografies i les m`ascares de correcci´o crom`atica a disc. En aquest ap`endix mostrarem el format utilitzat per a cada tipus d’arxiu i els convenis que hem pres a l’hora de posar-los nom. B.1 Homografies El nostre projecte calcula i desa tres tipus d’homografies diferents, els arxius dels quals anomenarem de la seg¨uent manera:  Homografia C`amera-Pantalla: hi ha un per cada c`amera, per tant, nom´es hi ha un en el nostre cas. L’anomenem Homography.txt.  Homografia Projector-Pantalla: hi ha un per cada projector. Els anomenem MutualID.txt, on ID correspon a l’identificador del projector. Identificarem els projectors amb n´umeros del 0 al 5 comen¸cant, vist des de l’interior de la CAVE, amb el projector superior de la torre esquerra i avan¸cant d’esquerra a dreta i de la filera superior a la inferior).  Homografia Projector-Projector: hi ha un per projector. Els anomenem HomographyID.txt on ID est`a determinat de la mateixa forma que en el cas anterior. El format de tots els arxius que contenen homografies ´es el mateix: h0 : h1 : h2 : ... :h15 : On cada hicorrespon a l’element i-essim de la homografia (comen¸cant amb i= 0 i recordant que les homografies amb les que treballar`a el programa son de dimensi´o 4×4). Desem les homografies al directori arrel de l’aplicaci´o. 89 90 AP` ENDIX B. DADES B.2 M`ascares Les m`ascares de correcci´o crom`atica s´on imatges en escala de grisos en format .pnm. La llibreria de manipulaci´o d’imatges i OpenGL situen el punt inicial de la imatge en indrets diferents: mentres que per a OpenGL el p´ıxel (0,0) de la imatge ´es la cantonada inferior esquerra, per a la llibreria d’imatges ´es la cantonada superior esquerra. ´ Es per aix`o que totes les imatges que s’utilitzen en la nostra aplicaci´o estan reflexades verticalment. Figura B.1: Exemple de la m`ascara Mask0. Els arxius es desen a la carpeta data del directori arrel de l’aplicaci´o. La seva nomenclatura ´es MaskID, sense extensi´o i on ID es determina de la mateixa manera que en el cas de les homografies. B.3 Patrons A la nostra llibreria LibImages hem implementat una classe per a representar els patrons de l´ınies. Per a fer-la m´es flexible hi hem introduit la informaci´o del nombre de l´ınies i els colors per pintar i per a cercar a les imatges. Tota aquesta informaci´o la introdu¨ım per mitj`a d’un petit fitxer de text anomenat SimplePattern.txt que podem trobar a la carpeta patterns situada al directori arrel de la llibreria. El format de l’arxiu ´es el seg¨uent: n R1:G1:B1: ... Rn:Gn:Bn: On n´es el nombre de l´ınies i Ri:Gi:Bi´es el codi RGB del color de la l´ınia i-`essima del patr´o. Ap`endix C Shaders Un shader ´es un programa senzill capa¸c de manipular dades de coordenades en 3D i textures. Aquests programes s’executen a la GPU de la targeta gr`afica, i aix´ı, al tenir tota la informaci´o a la mem`oria pr`opia de la targeta, evitem col · lapsar el bus que ve de la mem`oria principal i, per tant, es pot manipular la sortida gr`afica d’una manera considerablement m´es r`apida que amb un programa executat al processador. Qualsevol aplicaci´o que faci un ´us intensiu en gr`afics necessita desenvolupar shaders. Els shaders que hem programat fan una feina ben senzilla: els utilitzem per corregir geom`etrica i crom`aticament la imatge resultant. Per comen¸car a dissenyar aquesta part, la primera gran decisi´o era trobar el llenguatge de shading m´es adequat. Ens vam decantar per GLSL perqu`e ´es el llenguatge de shading d’OpenGL, amb el qual hem implementat tot el projecte. A continuaci´o es mostra l’estructura dels shaders implementats. Totes les aplicacions que vulguin fer servir les dades de la calibraci´o haurien d’integrar aquests shaders d’una o altra forma. C.1 Aplicar les homografies El principal problema ´es la sintaxi, perqu`e hem de manipular dades tant en 3D com en 2D. Del resultat de multiplicar un punt per la matriu modelview projection obtenim un punt amb tres coordenades m´es l’homog`enia. Per fer la correcci´o geom`etrica volem coordenades 2D, per tant hem de crear un vector 2D homogeni per poder-lo multiplicar per la matriu 3x3 o b´e manipular la matriu per convertir-la en una 4x4 de manera que obtinguem el mateix resultat. Per raons de sintaxi en GLSL, la segona opci´o ´es molt m´es f`acil d’implementar i tamb´e m´es eficient. Tenim la multiplicaci´o en 2D homogeni de la homografia: 91 92 AP` ENDIX C. SHADERS   xp yp 1  =  h11 h12 h13 h21 h22 h23 h31 h32 h33    xq yq 1   Per tenir una equival`encia en 3D que conservi la coordenada z, podem manipular l’homografia i afegir-li una dimensi´o. El que volem ´es multiplicar nom´es x, y i 1, no volem que ens influeixi la z i volem que es conservi. Afegint una columna a 0 a la tercera posici´o aconseguim el primer objectiu, perqu`e anulem la component z. I si intercalem una fila a la tercera posici´o, amb un 1 a la tercera columna i la resta zeros, obtenim la z sense modificar.     xp yp zp 1     =     h11 h12 0h13 h21 h22 0h23 0 0 1 0 h31 h32 0h33         xq yq zp 1     Aquest resultat, per`o, no li podem passar tal qual al pixel shader, perqu`e abans d’arribar-li el pipeline agafa la component homog`enia i divideix tot el vector per ella, i nosaltres volem dividir nom´es xiyper r, ´es a dir: zp no s’ha de veure afectada per r. L’´unic que hem de fer abans d’acabar ´es dividir xiyper ri posar la component homog`enia a 1. A continuaci´o afegim el codi del vertex shader encarregat d’aquestes operacions. Hem de tenir en compte que mHomography ja est`a en forma de matriu de dimensi´o 4 ×4. gl_Position = gl_ModelViewProjectionMatrix * gl_Vertex; //Apliquem la divisio de perspectiva gl_Position = gl_Position / gl_Position.w; //Apliquem la homografia gl_Position = mHomography * gl_Position; //Dividim pel membre homogeni vec4 mVec = vec4(gl_Position.w,gl_Position.w,1.,gl_Position.w); gl_Position = gl_Position / mVec; C.2 Aplicar les m`ascares Un cop hem corregit la posici´o de la geometria, nom´es ens queda corregir el color de cada p´ıxel. L’encarregat de fer aix`o en GLSL ´es el fragment shader, que computa el color dels fragments i realitza les operacions amb textures. En el nostre cas, fem servir una estrat`egia molt senzilla per a aplicar la correcci´o crom`atica. C.2. APLICAR LES M ` ASCARES 93 Tenim una textura en escala de grisos del mateix tamany que el framebuffer del projector. El que farem ser`a multiplicar la intensitat del color del fragment pel valor indicat a la textura. Recordem que aquesta textura ´es de color negre en les zones on el projector no ha de pintar res, blanc en les zones on ´es l’´unic projector que les ilumina, i diferents intensitats de gris a la resta. El codi que utilizem ´es el seg¨uent: vec3 black = vec3(0.,0.,0.); vec3 texcolor; texcolor = texture2D(mask,gl_FragCoord.xy/vec2(width,height)).rgb; if(texcolor==black) { discard; } gl_FragColor = texture2D(textura,gl_TexCoord[0].st); float gray = texcolor.r; if(gray<1.) { gl_FragColor.rgb = gl_FragColor.rgb * gray; } Si el color de la textura ´es negre, descartem el fragment, operaci´o que provoca la interrupci´o de les operacions per a aquest fragment i passa a processar el seg¨uent.