Mozgó alakzatok valósidejű 3D-s rekonstrukciója és megjelenítése

EÖTVÖS LORÁND TUDOMÁNYEGYETEM INFORMATIKAI KAR Mozgó alakzatok valósidejű 3D-s rekonstrukciója és megjelenítése DIPLOMAMUNKA Témavezető: Csetverikov Dmitrij egyetemi tanár Készítette: Hapák József Programtervező informatikus MSc nappali tagozat Szoftvertechnológia szakirány Budapest, 2012

A projekt az Európai Unió támogatásával, az Európai Szociális Alap társfinanszírozásával valósul meg (a támogatás száma TÁMOP 4.2.1./B-09/1/KMR-2010-0003). 1

Tartalomjegyzék 1. Bevezetés 4 1.1. Dolgozat felépítése............................. 4 2. A feladat áttekintése 6 2.1. A stúdió felépítése............................. 6 2.2. A vezérlőszoftver.............................. 8 2.3. A feladat................................... 8 3. Tudományos, technikai előzmények 11 3.1. GPGPU................................... 11 3.2. nvidia CUDA................................ 15 3.2.1. Kernelek.............................. 15 3.2.2. Szál hierarchia........................... 15 3.2.3. Memória hierarchia......................... 16 3.3. További technológiák............................ 17 3.4. Szakirodalmi előzmények.......................... 18 3.4.1. INRIA Rhone-Alpes, Montbonnot, Franciaország......... 18 3.4.2. Max Planck Institut, Saarbrücken, Németország.......... 19 3.4.3. Institute of Computer Science (ICS), Heraklion, Görögország.. 19 3.4.4. University of Surrey, Guildford, Nagy-Britannia......... 20 3.4.5. University of Southern California................. 21 4. Megoldás áttekintése 22 4.1. Képek feltöltése............................... 23 4.2. Szegmentálás................................ 23 4.3. Vizuális Burok............................... 24 4.4. Élsimítás.................................. 26 4.5. Marching Cubes............................... 27 4.6. Textúrázás.................................. 29 4.6.1. Árnyéktérképek........................... 32 2

5. Megvalósítás 36 5.1. Fejlesztés során alkalmazott eszközök................... 36 5.2. Programkönyvtár ismertetése........................ 36 5.3. Gyakorlati alkalmazás........................... 42 6. Tesztelés, eredmények 44 6.1. Tesztelés................................... 44 6.2. Eredmények, további tervek........................ 44 7. Köszönetnyilvánítás 46 8. Dolgozat témakörében megjelent publikációk 48 3

1. fejezet Bevezetés Napjaink film és játékipara a technológiai fejlődés hatására egyre magasabb minőségű számítógépes grafikai megoldásokat alkalmaz. Ennek a magas szintnek az eléréséhez megfelelő minőségű bemenő adatokra van szükség, amik még napjainkban is nagyrészt emberi munka által kerülnek előállításra. Ennek a módszernek természetesen több szempont szerint is korlátai vannak. Nagy szükség lenne egy teljesen automatikus rekonstrukciós eljárásra, mely a rekonstruálandó időben változó színteret magas minőségben tudja digitalizálni. A feladat bonyolultsága miatt speciális stúdiót igényel. Még napjainkban is kevés ilyen stúdió került felépítésre. Még kevesebb készült kifejezetten tudományos kísérletek és különböző kutatások elvégzése céljából. Hazánkban a Magyar Tudományos Akadémia Számítástechnikai és Automatizálási Kutatóintézetének Geometriai Modellezés és Számítógépes Látás Kutatólaborjában található egy ilyen stúdió. Dolgozatom témája megvizsgálni, hogy lehetséges-e a rögzített, időben változó színtér valósidejű rekonstrukciója. Illetve amennyiben ez kivitelezhetőnek bizonyul, akkor az ezt végrehajtó szoftverkomponenst megvalósítani a stúdió meglévő vezérlőszoftveréhez. Az elért eredmények megkönnyítik a stúdió keretein belül végzett munkát, hiszen már a felvétel készítése és utófeldolgozása előtt betekintést nyerhetünk a várható eredménybe. A felhasználási lehetőségek jelenleg még nem teljesen tisztázottak a film és játékipar, vagy a telekommunikáció is kamatoztathatja a fejlesztés során kidolgozott módszereket. További célunk a felvett a rekonstruált alakzat virtuális világban való elhelyezése, illetve a felvett mozgás más modellre történő átültetése. 1.1. Dolgozat felépítése A dolgozat első felében bemutatjuk a labor által felépített stúdiót, az alkalmazott hardvereket, és a szoftverkörnyezetet. Ezek ismeretében pontosítjuk a megoldandó probléma 4

1.1. ábra. A felvétel és a rekonstruált eredmény definicióját. A második részben ismertetjük a dolgozat megértéséhez szükséges alapismereteket. Tisztázzuk a grafikus processzorok programozásakor előforduló fogalmakat. Továbbá áttekintjük a feladat szakterületén már elért eredményeket. Ezután részletezzük magát a megoldás módszerét. Bemutatjuk a megoldás során alkalmazott már meglévő és általunk kidolgozott módszereket. Az ötödik fejezetben összefoglaljuk a konkrét megvalósítás során alkalmazott eszközöket, és bemutatjuk a rendszer használatát. Végezetül néhány szót ejtünk a rendszer teszteléséről, és összefoglaljuk a dolgozat elkészítése során elért eredményeket. 5

2. fejezet A feladat áttekintése Ebben a fejezetben részletesen bemutatjuk a studióban alkalmazott hardver eszközöket, és pontosítjuk a megoldandó feladatot 2.1. A stúdió felépítése A Stúdió egy 5 méter átmérőjű, 3 méter magas fémváz, mely zöld színű vászonnal van takarva. [7] A rekonstruálandó tér rögzítését 13 darab a JAI cég által fejlesztett CB-200GE típusú ipari kamera végzi. Ezek közül 12 egyenletesen elosztva helyezkedik el a terem oldalfalán váltakozó magasságban hat kamera fentről, hat pedig lentről rögzíti a stúdió belső terét. Az utolsó kamera középen fent került felfogatásra. A kamerák 1624x1236 felbontású képeket küldenek Bayer kódolásban. 2.1. ábra. A stúdió panorámaképe belülről A kamerák által küldött nagy mennyiségű adat mentéséért összesen 7 számítógép felelős. Egy számítógépet kivéve mindegyikre két kamera csatlakozik. A nagy sávszélesség biztosítása érdekében az adatok különböző merevlemezeken kerülnek tárolásra. A számítógépeken Open SUSE operációs rendszer fut. A későbbi feldolgozás érdekében minden számítógép el van látva egy közepes teljesítményű videokártyával. A valósidejű rekonst- 6

rukciót végző PC egy nagyteljesítményű Fermi architektúrás GF110 típusú grafikus processzorral szerelt GeForce 580 GTX videokártyával rendelkezik. Az alkalmazott GPU 512 darab feldolgozó processzort tartalmaz, amelyek 32-esével 16 csoportokba szerveződnek. Az elérhető maximális számítási kapacitás 1500 Gflops. A kamerák és a számítógépek Gigabit Ethernet segítségével kerültek összekötésre. Erre a sávszélességre mind a rögzítés, mind a rekonstrukció folyamán szükség van. 2.2. ábra. A stúdió látványterve A megfelelő minőségű képek előállítása érdekében a stúdió fontos részét képezi a megvilágítás. Túl kevés fény esetén a képek sötétek lesznek. Ha ezt hosszú expozíciós idővel próbáljuk korrigálni, akkor elmosott, részletszegény képeket kaphatunk. Túl erős megvilágítás használata esetén pedig a fényforráshoz közel eső részek telítődhetnek, a távolabbiak pedig sötétek maradnak a fényintenzitás négyzetes csökkenése miatt. 2.3. ábra. A stúdióban található egyik kamera, és a hozzá tartozó fényforrás A stúdió felülről néhány szórt fényforrással van megvilágítva. Ezen kívül minden kamera mellé fel van szerelve egy-egy LED-eket tartalmazó panel, a kamera által rögzített 7

tér bevilágítása céljából. Mivel a kamerák körben egyenletesen kerültek elosztásra, ezért adódik, hogy egymás fényforrásait is látják. A szemből világító erős fény elronthatja a felvételek minőségét. A probléma kiküszöbölése érdekében a kamerák két csoportra vannak osztva. Míg az egyik csoport felvételt készít, addig a másik csoport fényforrásai sötétek maradnak. Ennek a váltakozásnak az irányításáért, egy speciális mikrokontrollert tartalmazó vezérlőegység felelős. Ez a vezérlőegység végzi a kamerák szinkronizálását, és lehetővé teszi az egyes fényforrások külön-külön történő vezérlését. Programja számítógép segítségével könnyen módosítható. A kamerák két csoportra bontása minimális időeltolódást eredményez a felvételek között, de ez érdemben nem befolyásolja a rekonstrukció minőségét. 2.2. A vezérlőszoftver A stúdió, mint egy összetett hardverrendszer működtetése bonyolult feladat, saját szoftvert követel meg [10]. A szoftvernek lehetőséget kell adnia a következő feladatok elvégzésére: stúdió kameráinak kalibrálása, a kamerák mikrokontroller segítségével való szinkron működtetése, a hálózatba kapcsolt számítógépek vezérlése, mérési adatok rögzítése, háttérkép készítése, a stúdió fényeinek szabályozása Ezen feladatok elvégzésére egy kényelmes korszerű grafikus felületet biztosít a program (2.4. ábra). Fejlesztése C++ nyelven történt, a grafikus felület pedig a Qt keretrendszer segítségével lett megvalósítva. A szoftver tervezése során igény volt annak egyszerű kiegészíthetőségének a biztosítása, lehetőséget adva a stúdió további funkciókkal való könnyű tovább fejlesztésére. Munkám során a stúdió már meglévő vezérlőszoftverét kellett kibővíteni a valósidejű rekonstrukciót lehetővé tevő komponenssel. 2.3. A feladat A munka célja megvizsgálni, hogy megfelelően megválasztott hardver és szoftver technológiák alkalmazásával lehetséges-e a stúdióban rögzített mozgó 3D-s alakzatok valósidejű rekonstrukciója és megjelenítése. A munka kiinduló pontja a már elkészített 8

2.4. ábra. A stúdió vezérlo szoftvere utófeldolgozáson alapuló offline mu ködés volt. Ennek használatával egy tíz másodperces rögzített adatfolyam feldolgozása 30 percet vesz igénybe. Az ido nek a nagy részét a lemezmu veletek teszik ki. A valósideju implementációban az offline mu ködéssel ellentétben nincs szükség a felvételek rögzítésére, a rendelkezésre álló feldolgozási ido t a leheto legjobb mino ség elérése kell fordítani A feladat megoldása jelento s számítási kapacitást igényel, az ezt biztosító grafikus processzorok napjainkra érték el a szükséges teljesítményt. Ezen oknál fogva a problémakör kis irodalommal rendelkezik, és az alkalmazott hardver és szoftvermegoldások is különbözo ek. Az alkalmazott stúdióban szokványos kamerák állnak rendelkezésre, más hardverkörnyezet, például mélységkamerák esetén más szoftveres megoldások is számításba kerülhetnek. A megoldandó feladat lényegesen különbözik a film és játékiparban már rég alkalmazott Motion Capture1 technológiáktól. Hiszen míg ez utóbbiak az alakzatokon elhelyezett markerek segítségével csak a mozgás követésére, úgynevezett ritka rekonstrukcióra alkalmasak, addig esetünkben komplett, su ru geometria létrehozása a cél. A mu velet elvégzéséhez nincs szükség markerek elhelyezésére, így leheto ség nyílik állatok, vagy akár füst rekonstrukciójára is. A munka eredményét egy a stúdiót mu ködteto már elkészült vezérlo programhoz in1 http://en.wikipedia.org/wiki/motion_capture 9

tegrálható kiegészítésként kellett megvalósítani. A vezérlőprogram már biztosította számunkra a képek rögzítését, és a kamerák kalibrációs adatait, ezekkel a fejlesztés során már nem kellett foglalkozni. További igény volt az eredmények egyszerű megjeleníthetősége a Visualisation Toolkit 2 segítségével. 2 http://www.vtk.org/ 10

3. fejezet Tudományos, technikai előzmények 3.1. GPGPU Napjainkra a számítógépekben található grafikus processzor - főleg a játékfejlesztés jóvoltából - óriási fejlődésen ment keresztül. Ezeknek a sokmagos architektúrával rendelkező processzoroknak a teljesítménye rövid időn belül elérte, később többszörösen meghaladta a központi feldolgozó egységek teljesítményét (3.1. ábra). Igény merült fel, ennek a jelentős számítási kapacitásnak az általános célra történő felhasználására. Ezt a törekvést nevezzük GPGPU-nak (General-Purpose computing on Graphics Processing Units). Kezdetben a problémát hekkeléssel a grafikus futószalag segítségével valósították meg. Ez a megközelítés azonban több nehézséggel is jár. Egyrészt magas szintű ismereteket feltételez a grafikus környezetekkel kapcsolatban, másrészt az egyes problémák grafikus futószalagba való átültetése sem könnyű feladat. Kezdetben a grafikus API-kra épülő, azok kényelmetlenségét elfedő könyvtárak próbálták segíteni a fejlesztők munkáját, mint például a BrookGPU. Ezek elterjedését azonban hamar megakadályozta az egyes gyártó specifikus megoldások megjelenése, mint például az nvidia CUDA és az Ati Stream. Segítségükkel már közvetlenül a videokártya hardverét programozhattuk megkerülve a grafikus API-k miatt fellépő korlátozásokat mind technikai, mind teljesítménybeli téren. Később az ipar igényeire válaszolva elkészült az első gyártó független megoldás is - az OpenCL. Ezt a kiemelkedő teljesítményt a grafikus processzorok a központi feldolgozó egységtől jelentősen eltérő architektúrával valósítják meg. Míg utóbbiak néhány, fejlett önálló munkavégzésre alkalmas feldolgozó magot alkalmaznak, addig a GPU több száz jóval egyszerűbb feldolgozó egységgel rendelkezik. Ezen kívül az egyes részfunkciókra alkalmazott tranzisztorok száma is jelentős különbséget mutat (??. ábra). Míg a CPU-k kialakítása során nagy mennyiséget fordítanak vezérlésre és gyorsítótár kialakítására, addig a grafikus processzorok esetében a feldolgozó magok élveznek prioritást. A feldolgozó egységek nem rendelkeznek önállóan folyamat vezérléssel, csoportokba szerveződve közös 11

3.1. ábra. A GPU-k és CPU-k teljesírményének növekedése az évek során (forrás CUDA C Programming Guide) egység felelős az irányításukért. Az architektúra kialakításából adódik, hogy a számítási kapacitás kihasználása csak magas szintű adatpárhuzamosságra alapozó egyszerű folyamatvezérlést tartalmazó algoritmusok esetén van lehetőség. A technológia legnagyobb gyengesége a GPU-val történő kommunikáció. Mivel a videókártya saját nagysebességű fedélzeti memóriával rendelkezik, ezért szükséges feldolgozandó és már feldolgozott adatok mozgatása. Sajnos, ez a folyamat a PCI-Express busz lassúsága miatt meglehetősen költséges. Napjainkban érkeztünk el a személyi számítógépek 3. érájába. Minden nagyobb ipari szereplő fejlesztéseire jellemző a törekvés a két különböző architektúra előnyeinek egyesítésére. A 2011-es évben megjelenő APU-k (Accelarated Processing Units) vegyesen tartalmaznak a GPU, illetve a CPU-ra jellemző feldolgozó egységeket. A magok egy szilicum lapkán való kialakításának az előnye az alacsony fogyasztás, továbbá lehetőség adódik különböző típusú végrehajtó egységek közös gyorsítótárral való összekapcsolására, mely rendkívül hatékony kommunikációt tesz lehetővé. A kezdetben speciális feladatkör elvégzésére kialakított processzorok (esetünkben GPU) központi egységbe (CPU) való visszakerülésének folyamatát wheel of reincarnation nevezzük. A grafikus processzorok által biztosított teljesítmény kihasználása nem egyszerű feladat. Nem lehetséges az ipar által már kidolgozott, bevált módszerek segítségével. Új programozási nyelvekre, a fejlesztést megkönnyítő eszközkészletekre, paradigmákra van 12

3.2. ábra. A rekonstrúkció végrehajtására alkalmazott GF110 GPU belső felépítése szükség. Ezen új elvek mentén végzett szoftverfejlesztési munkát nevezzük heterogén programozásnak. Mind grafikus, mind általános számítások futása során a központi egység (CPU) és a grafikus processzor (GPU) egyfajta szerver kliens szerepkörben állnak egymással. A jóval alacsonyabb számítási kapacitással rendelkező CPU-n futó úgynevezett gazdaprogram, egyszerű, főleg adatpárhuzamosságra alapozó feladatokkal bízza meg a nagy teljesítményű GPU-t. A gazdaprogram szokványos programozási nyelvek segítségével készíthető el. Esetünkben ez C++ volt mivel a komponenst beágyazó keretprogram is ezen a nyelven készült. A videokártyák programozása azonban speciális nyelvek, technológiák segítségével valósítható meg, melyek új nyelvi elemeket vezetnek be a hardver hatékony kihasználása érdekében. Ilyen nyelvi elem például a grafikában használatos mátrix, és vektorműveletek, vagy a párhuzamosságot támogató szinkronizációs műveletek. Az általunk a valósidejű rekonstrukcióra használt videokártya programozása a Cuda, DirectCompute, GLSL, HLSL, és az OpenCL technológiák segítségével lehetséges. A DirectCompute és a HLSL csak Windows operációs rendszeren elérhető technológiák, így esetünkben nem voltak alkalmazhatóak. A GLSL az OpenGL grafikus könyvtár saját C szerű programozási nyelve, mellyel a korszerű renderelési futószalagok egyes fázisait programozhatjuk. Ezt a technológiát a ma kapható hardverek széles köre magas szinten támogatja. Általános számítási feladatok 13

3.3. ábra. A részegységekre felhasznált tranzisztorok mennyisége különböző architektúrák esetén. elvégzésére az OpenGL-lel való szoros kapcsolata miatt csak nehézkesen alkalmazható. Az OpenCL az utóbbi években jelentősen feltörekvő nyílt technológia, mely lehetővé teszi a sok és többmagos processzorok - legyen az központi feldolgozó egység (CPU), vagy grafikus processzor (GPU) - egy egységes felületen való hatékony kihasználását. Széleskörű támogatottságát a felhasználói programok írásakor kamatoztathatjuk, hiszen az otthoni multimédiás eszközök jelentős hányada támogatja. Jelentősége az utóbbi években az APU-k megjelenésével tovább nőt, hiszen egy egységes felületet nyújt azok teljes mértékű kihasználáshoz, megőrizve a régebbi hardverekkel való kompatibilitást. Felépítése hasonlít az OpenGL grafikus könyvtáréra, amivel magas fokú együttműködésre képes. A hatékony működés érdekében lehetőség van erőforrások megosztására a két technológia között. A CUDA-val ellentétben viszont - a technológia frissességéből adódóan - számottevően kisebb szakirodalom bázissal, a fejlesztést megkönnyítő könyvtárral és eszközzel rendelkezik jelenleg. Az CUDA (Compute Unified Device Architecture) a heterogén programozást lehetővé tevő eszközkészlet az nvidia-tól. Lehetőséget ad a cég által gyártott grafikus processzorok teljesítményének egyszerű kihasználására. Első verziója 2007-ben jelent meg, jelenleg a 4.2-es verziónál tart. A cég a tudományos, és ipari felhasználáshoz külön termékvonalat tart fenn Tesla néven, melyek kifejezetten általános számítások elvégzésére készültek. A piacon való elsősége révén nagyobb felhasználói bázissal, kiforrottabb eszközkészlettel rendelkezik. Az OpenCL-hez hasonlóan képes együttműködni az OpenGL grafikus környezettel. Választásunk végül a CUDA platformra esett annak magasabb színtű támogatottsága miatt, A futószalag minden fázisa, a textúrázás kivételével ezen a nyelven került implementálásra. A megvalósításban kihasználjuk a OpenGL-lel való erőforrás megosztás lehetőségét, és igény esetén a rekonstrukció eredményét, egy már az OpenGL segítségével hatékonyan megjeleníthető Vertex Buffer Objectben adjuk át. A textúrázást a többi fázissal ellentétben GLSL-ben valósítottuk meg. 14

3.2. nvidia CUDA Ebben az alfejezetben bemutatjuk a CUDA programozási modelljét, és a hozzá kapcsolódó fogalmakat. 3.2.1. Kernelek A fejlesztés során a videokártya programozása CUDA C nyelven történik. Ez a C nyelv kiterjesztése, mely lehetővé teszi a programozóknak úgynevezett kernelek írását. A kernelek egyszerű C metódusok, melyek nagy számban futtathatók párhuzamosan a grafikus processzoron. A kerneleket a global kulcsszó segítségével definiálhatjuk. A kernelek végrehajtása szálakban történik. Végrehajtás során minden szál, egy egyedi threadidx értékkel rendelkezik. // Kernel definició g l o b a l void VecAdd( f l o a t * A, f l o a t * B, f l o a t * C) { i n t i = threadidx.x; C[i] = A[i] + B[i]; } i n t main() {... // Kernel hívás N példányban VecAdd<<<1, N>>>(A, B, C); }... Illusztrációként a következő példakód összead két N hosszú vektort A-t és B-t, majd az eredményt eltárolja a C vektorban. 3.2.2. Szál hierarchia A szálak végrehajtása munkatereken történik. A munkatér minden pontjában végrehajtódik egy kernel példány. Jelenleg a szabvány egy-, két-, illetve háromdimenziós munkaterek használatát teszi lehetővé. Ez egy természetes módot ad vektor, mátrix, és térfogat adatszerkezetek feldolgozására. A végrehajtás során a szál indexe a munkatérben a threadidx környezeti változóból kérdezhető le. A szálak csoportja úgynevezett blokkokat alkot (3.4. ábra). A blokkban résztvevő szálakra igaz, hogy azok végrehajtása egy processzoron belül zajlik. Így lehetőség nyílik a processzor belső memóriája segítségével az adatmegosztásra. A blokkok hálókba szerveződnek. 15

3.4. ábra. A CUDA szálhierarchiája (forrás CUDA C Programming Guide) 3.2.3. Memória hierarchia A CUDA szálak több különböző memória területet érhetnek el futtatásuk során (3.5. ábra). Mindegyik szál rendelkezik egy privát memória területtel. Itt tárolódnak a futás során használt lokális változók. A szálak által alkotott blokk is rendelkezik egy megosztott memória területtel. Ez a memória terület lehetővé teszi a blokkban található szálak közötti hatékony kommunikációt. Ezen kívül minden szál eléri ugyanazt a globális, konstans, és textúra memóriát. A globális memória egy írható olvasható tár az adatok tárolásra. A konstans memória csak olvasható memória, a gazdaprogram által átadott konstans adatok tárolására használható. Alkalmazása hatékonyabb a globális memóriánál hiszen a benne lévő változatlansága biztosított, így hatékonyabban gyorsítótárazható. 16

3.5. ábra. A CUDA memóriahierarchiája (forrás CUDA C Programming Guide) 3.3. További technológiák A Visualization Toolkit (VTK) egy ingyenes, nyílt forráskódú keretrendszer mely számos 3D-s számítógépes grafikai, képfeldolgozó és vizualizációs algoritmust foglal magába. Lehetőséget biztosít különböző típusú bejövő adatok egyszerű módon való vizualizációjára. Könyvtára számos eszközt kínál a vizualizáció interaktívvá tételére. Fejlesztése C++ nyelven történik, de rendelkezik Tcl/TK, Java és Python interfészekkel is. Feladataim közé tartozott a valósidőben rekonstruált adatok VTK-ban történő hatékony megjelenítésének a biztosítása. Gazdaprogram oldalán a matematikai számításokat az OpenCV 1 könyvtár segítségé- 1 http://opencv.willowgarage.com/wiki/ 17

vel végeztük el. Az OpenCV egy nyílt forráskódú függvénykönyvtár, amely a számítógépes látással kapcsolatos algoritmusokat gyűjti össze. Kialakítása során nagy figyelmet fordítottak, hogy az implementált funkciók valósidejű programok írása esetén is alkalmazhatóak legyenek. Az implementált algoritmusokat a fejlesztők a következő területeken alkalmazhatják: Általános képfeldolgozással kapcsolatos feladatok Kamera kalibráció, 3D sztereo Szegmentálás és felismerés Arcfelismerés Ember-gép interakciók Mozgás követés Robotika 3.4. Szakirodalmi előzmények A 4D rekonstrukciós stúdiók magas kivitelezési költsége, és speciális felhasználási módja miatt viszonylag kevés kifejezetten kutatási célra létrehozott rendszert lehet találni, Magyarországon legjobb tudomásunk szerint a labor által létrehozott az egyetlen. A továbbiakban bemutatunk néhány hasonló Európában és a tengerentúlon található stúdiót. 3.4.1. INRIA Rhone-Alpes, Montbonnot, Franciaország A GrImage három kutatási terület együttes kezdeményeként jött létre. Célja kiszolgálni a számítógépes grafikával, mesterséges látással és párhuzamos számításokkal kapcsolatos kutatási projekteket, mint például: Marker nélküli valósidejű 3D-s modellezés Nagy erőforrás igényű fizikai szimulációk Nagy erőforrás igényű képszintézis és tudományos vizualizáció Kiterjesztett és virtuális valóság Bemeneti (kamerák) és kimeneti (projektorok) eszközök kalibrációja és szinkronizációja. 18

A stúdió kivitelezésének egy részét a 4D View Solution 2 vállalat végezte (3.6. ábra). A 12 színes és 8 fekete-fehér kamera adatainak feldolgozásért 27 számítógép felelős. A számítógépek dual Gigabites hálózat segítségével kerültek összekötésre. Nagyobb számítás igényű feladatok elvégzése esetén lehetőség van további számítógép klaszterek átmeneti csatlakoztatására is. 3.6. ábra. INRIA stúdió és az alkalmazott géppark 3.4.2. Max Planck Institut, Saarbrücken, Németország A labor legfőbb célja mozgó emberi alakzatok rekonstrukciója. Magáról a stúdió hardveres felépítéséről kevés információ található. A modelleket első lépésben lézerszkennerek segítségével rekonstruálják. Az így kinyert háromszöghálókat deformálják különböző algoritmusok segítségével videofelvételek alapján. A felvételek rögzítése során nem alkalmaznak markereket. További kutatási területük a rekonstruált animált modellből automatikus csontváz modell előállítása. 3.4.3. Institute of Computer Science (ICS), Heraklion, Görögország A munkacsoport célja egy olyan többkamerás rendszer kiépítése volt, mely lehetővé teszi az emberi kéz által végzett műveletek rögzítését és feldolgozását. [2] A munka keretein belül egy valósidejű implementáció is elkészítésre került. A megfigyelt terület egy 2 1 m 2 területű asztallap. Az általuk épített hardveres körülmények nagy mértékben hasonlítanak a laborunk stúdiójához. 8 darab Flea2 típusú kamerát alkalmaznak. Az elérhető maximális felbontás 1280 960 másodpercenként 30 képkocka sebesség mellett. A 8 kamera által felvett képet 4 személyi számítógép dolgozza fel. A teljes rekonstrukciós folyamatot a központi gép végzi, egy nvidia Geforce GTX 295 típusú videokártya segítségével a CUDA platformot alkalmazva. Az eljárás során a videókártyán található két grafikus processzorból csak egy kerül alkalmazásra. A 2 http://www.4dviews.com/ 19

3.7. ábra. Institute of Computer Science stúdiója, Görögország rögzített képeket szegmentálják, majd a sziluett képekbo l térfogatmodellt építenek a Vizuális Burok algoritmus segítségével. A valósideju rekonstrukció során nincs leheto ség az elo állított modell simítására. 3.4.4. University of Surrey, Guildford, Nagy-Britannia A stúdió egy fontos EU-s projekt keretében jött létre. A projekt három évig zajlott. A Surrey Egyetemen kivül további 5 tagja a szakterületben vezeto nek számító egyetemek és vállalatok közül kerültek ki: The Foundry Visionmongers Ltd London, Egyesült Királyság Trinity College Dublin, Írország University of Surrey, Egyesül Királyság Centre of Research and Technology Hellas Informatics and Telematics Institute (CERTH-ITI) Thessaloniki, Görögország Quantic Dream S.A. Párizs, Franciaország BUF Compagnie Párizs, Franciaország A munka eredményeképp új eljárások és intelligens technológiák készültek strukturált 3D-s adatok felépítésére videofelvételekbo l. Az elo állított tartalom mino sége megfelel a 20

filmipari és játékipari felhasználás által támasztott magas követelményeknek. A fejlesztések leheto vé tették a felvételek újrahasznosítását, utólag más megvilágítás és nézo pont alkalmazását. A rögzített tartalmat több grafikai és média platformon is feldolgozható tették. A projekt során a következo eredményeket sikerült elérni: Álló és mozgó alakzatok rögzítése és 3D adatstruktúrában való eltárolása. Magas mino ségu adatok rögzítése díszletekro l és színészekro l, hogy leheto vé tegyék más jelenetekben való alkalmazásukat. A színészek arcának és ruhájának magas mino ségben történo rögzítése. Szoftvereszközök fejlesztése az adatok utólagos feldolgozására. Az elért eredmények demonstrálása egy kísérleti produkcióval. Nyílt szabványok létrehozása a 3D-s tartalmak módosításához. 3.4.5. University of Southern California A tengerentúlon található a Insititute for Creative Technologies Graphics Lab stúdiója, Paul Debevec, a számítógépes grafika elismert szakérto jének vezetésével. Számos kamera és fényforrás alkalmazásával a fotometrikus sztereó segítségével hajtanak végre részlet gazdag rekonstrukciót. Az eljárás alapötlete hogy a különbözo irányú, színu fényforrásokkal megvilágított alakzatok felületének normálvektorai a megvilágítás alapján becsülheto. A különbözo fényforrások és kamerák alapján kinyert normálvektorok összeregisztrálásával felépítheto a keresett 3D-s modell. Mivel a stúdió dinamikus színterek rekonstrukciója végett készült, ezért az alkalmazott fényforrások nagysebességgel ki-be kapcsolhatóak. A stúdió a 3.8 ábrán látható. 3.8. ábra. Dél-Kaliforniai egyetem stúdiója 21

4. fejezet Megoldás áttekintése Mivel napjainkban a probléma megoldása által igényelt számítási teljesítményt csak a korszerű grafikus processzorok képesek biztosítani, ezért a megvalósítás során olyan algoritmusokat kellett választanunk, amelyek hatékonyan implementálhatóak sok magos környezetben. Ezeket az algoritmusokat egymás után fűzve kialakításra került egy végrehajtási futószalag (4.1. ábra), mely lehetővé teszi a valósidejű rekonstrukciót. Az eljárás első lépése, amint a vezérlőszoftver megkapja minden kamerától az aktuális képkockát, a képek feltöltése a videokártya memóriájába a további feldolgozás végett. Ezeket a képeket már a kamerák felvételeit fogadó gépek előfeldolgozzák: a Bayer kódolásból [1] RGB színtérbe alakítják, és elvégzik a megfelelő átméretezést is. Ezután a képeket szegmentáljuk elválasztva a stúdió hátterét az előtértől. A szebb eredmény elérése érdekében igény esetén egy simítást is elvégezhetünk. Az eredményül kapott sziluett képekből a Vizuális Burok algoritmussal térfogat modellt állítunk elő. Ezután a Marching Cubes algoritmus alkalmazásával háromszöghálót generálunk, amelyet már a videókártya hatékonyan meg tud megjeleníteni. A pipeline utolsó opcionális lépése a kapott háromszögháló textúrával történő renderelése. Ez a lépés felbomlik úgynevezett shadowmapok (árnyéktérképek) előállítására, és magára a textúrázásra. A futószalag modulárisan került implementálásra. Annak tetszőleges része külön lefuttatható, a részeredmények kinyerhetők. Ezáltal lehetőség nyílik az egyes fázisok más módszerrel való megoldására, a megoldások teljesítményének, hatékonyságának összevetésére. Egyes fázisok opcionálissá tehetők, mint például a textúrázás vagy a sziluettképek simítása. Ezt az igényt szem előtt tartva az egyes fázisokat osztályokba szerveztük. Az egyes implementációknak meg kell valósítani az adott fázis interfészét. Mivel az egyes fázisok nagy mennyiségű adatot dolgoznak fel, ezért a fölösleges adatmozgatásokat minimalizálni kell. Ezért az egyes fázisok közvetlen használják egymás memóriaterületeit a végrehajtás során. 22

4.1. ábra. A GPU munkamenet (a szaggatott vonallal jelölt fázisok opcionálisak) 4.1. Képek feltöltése Bár a képek feltöltése során nem történik semmilyen számítási művelet, végrehajtása mégis költséges a PCI-Express busz alacsony áteresztő képessége miatt. A képeket a vezérlőprogramtól egy összefüggő memóriatömbként várjuk. A videokártyában a tárolás egy 3 dimenziós tömbben történik, az egyes kameraképeket egymás mögött eltárolva. Az implementációban a lépés összevonásra került a szegmentálás fázissal. 4.2. Szegmentálás A szegmentálás feladata a beérkező képek szétválasztása háttérre és előtérre. Az eljárás végeredménye egy az eredetivel megegyező méretű bináris kép, melyben a fekete pixelek háttérhez, a fehér pixelek pedig az előtérhez tartoznak. Több különböző elvű algoritmus létezik a probléma megoldására, ezek közül az egyik leghatékonyabb, legjobban párhuzamosítható a háttér alapú szegmentálás. Első lépésként a kalibrált kamerák segítségével rögzítjük az üres stúdiót ezek az úgynevezett háttérképek. A feldolgozás során meghatározzuk az aktuális képkocka pixelei, és a háttérképek közötti abszolút különbséget az RGB szintérben. Ha a különbség átlépi a paraméterként megadott küszöbértéket, akkor a pixel az előtérhez tartozik, egyébként pedig a háttérhez. Jelöljük i-vel az előtér, bg-vel a háttér, s-sel pedig a sziluett kép aktuálisan feldolgozás alatt álló pixelét. Ekkor a szegmentálás a következő formula alapján hajtódik végre. d = i r bg r + i g bg g + i b bg b ahol az r, g, b a megfelelő színcsatornákat jelölik. 23

s = { 255 ha d > threshold 0 egyébként Látható, hogy az algoritmus nagyon jól párhuzamosítható sok feldolgozó egységgel rendelkező architektúrákon, mint például a grafikus processzorok, hiszen az egyes pixelek feldolgozása egymástól függetlenül zajlik. Az implementációban a bináris képeket bájtok segítségével ábrázoljuk, 0 értékkel jelöljük a háttér 255-tel az előtér színeit. 4.2. ábra. A feldolgozásra beérkező képek Egy-egy pixel szegmentálását a grafikus processzor egy-egy feldolgozó processzora végzi el. A feldolgozás gyorsítása érdekében az adatokat textúraként, csak olvasható módon érjük el. Ebben az esetben a futtató környezetnek lehetősége van a grafikus processzor textúra mintavételezőire támaszkodni, melyek nagy sebességgel képesek egyszerre több adatot beolvasni és gyorsítótárazni. Mivel az algoritmus magja minden pixelre lefut, ezért műveletigénye a képpontok számában lineáris. 4.3. Vizuális Burok A szegmentált képekből a Vizuális Burok (Visual Hull) [4, 5] nevű eljárással állítunk elő térfogat modellt. A térfogat modell egy 3 dimenziós adatstruktúra, lényegében a 2 dimenziós képek kiterjesztése. Pixelek (picture elements) helyett úgynevezett voxeleket (volumetric pixel) tartalmaznak, amely a reprezentált térfogat egy-egy pontjáról tárolnak 24

4.3. ábra. A szegmentálás eredménye információkat. Például orvosi felhasználás terén az emberi szövetek sűrűségértékeit. Esetünkben egy valószínűségi érték kerül tárolásra, mely jellemzi, hogy a rekonstruálandó objektum, milyen valószínűséggel található az adott voxelben. Az eljárás bemenő adatként kalibrált kamerákból származó sziluett képeket vár, tehát ismernünk kell az egyes kamerák egymáshoz képesti orientációját és pozícióját. Az ismert transzformációk alapján az egyes sziluettképeket visszavetíthetjük a rekonstruálandó térbe. A visszavetítés a térből, egy sziluett alapú gúlát metsz ki. Minden kamerára elvégezve a műveletet, megkapjuk a rekonstruálandó tér durva modelljét. Az eljárást működési módszeréből adódóan térfaragásnak (space carving) is nevezik, hiszen iteratívan a sziluettképek mentén kifaragja a rekonstruálandó alakzatot a térből. Az eljárás korlátai közé tartoznak a színtér azon konkáv mélyedései, amelyek nem jelennek meg egyetlen kamera felvételén sem. Például egy bögre belső üreges terét az algoritmus nem képes helyesen rekonstruálni. A gyakorlatban az eljárás végrehajtása során bejárjuk a készítendő modell voxeleit. A voxel térbeli pozícióijának ismeretében, lehetőségünk van annak helyét meghatározni az egyes kamerák terében. Jelöljük R i -vel az i. kamera forgatási, K i -vel a kameramátrixát, Legyen t i a kamera térbeli poziciója. T a térfogatmodell indexteréből a rekonstruálandó térbe átvivő transzformáció. Ekkor a képpont koordinátái a szegmentált képen c i = K i (R i T [x,y,z] T +t i ) ahol x, y, z az aktuálisan feldolgozás alatt álló voxel koordinátái. 25

A kapott eredmény segítségével mintavételezzük a sziluettképet. A voxel végeredményben, a mintavételezett értékek minimumát kapja eredményül. v(x,y,z) = min 1..n (tex2d(s i,c i )), ahol n a kamerák száma, S i az aktuális kamerához tartozó sziluettkép, tex2d pedig egy textúra mintavételező függvény. 4.4. ábra. A Vizuális Burok algoritmus Mivel a sziluettből kapott gúla a kamerától való távolság alapján szélesedik, ezért mintavételezési hibák jelentkezhetnek a szegmentált képek mintavételezése során. Ezeknek a hibáknak az elkerülésére a mipmapping algoritmus szolgál. Előfeldolgozási lépésként a textúrából több különböző méretű verziót, úgynevezett réteget állít elő. A mintavételezés során egy, vagy akár több réteget alkalmaz a lehető legjobb eredmény elérése érdekében. Mivel esetünkben az alkamazott textúrák dinamikusan kerülnek előállításra, és a mipmapping algoritmus alkalmazására költséges, annak előfeldolgozási lépése miatt, ezért kompromisszumokat kell kötni. A szegmentált képekre a Vizuális Burok eljárás előtt opcionálisan alkalmazhatunk egy élsimítási fázist. Ezzel valamilyen szinten kiküszöbölhetjük a mintavételezési hibákat, a teljesítmény drasztikus csökkenése nélkül. Az algoritmus futás során a paraméterként megadott méretű térfogatmodellt járja be. Minden voxelben mintavételezés történik az egyes sziluettképekből. Az műveletigény tehát a képek számában, és a térfogatmodell méretében lineáris. 4.4. Élsimítás A Vizuális Burok algoritmusban felmerülő mintavételezési problémák részleges kiküszöbölése végett a szegmentált képeken egy élsimítást hajtunk végre. A valósidejű implementációban ezt egy egyszerű szeparábilis dobozszűrő segítségével valósítjuk meg. Az 26

egyes pixelek feldolgozását ebben az esetben is a grafikus processzor egy-egy végrehajtó processzora végzi. A szűrő mérete futásidőben nem módosítható, csak a teljes program újrafordításával. Ez lehetőséget ad a fordítónak, hogy optimalizációkat hajtson végre a generált kódon (ciklusok kibontása). 4.5. ábra. Az elmosott sziluettképek A szegmentált képeket csak olvasható módon textúraként érjük el. Ez esetben a grafikus processzornak lehetősége van a textúra mintavételezők alkalmazására, mely egyszerre több adatot képes elérni, mindezt gyorsítótárazva. Ez különösen előnyös a simítás szempontjából, hiszen a szűrés folyamán sokszor van szükségünk ugyanazokra az értékekre. Műveletigény szempontjából az algoritmus a képpontok számában lineáris. Az elmosott sziluett képek a 4.5 ábrán látható. A 4.6. ábrán láthatjuk a simítás hatását az eredményre. Bal oldalt nem alkalmaztuk a lehetőséget, míg jobboldalt viszont igen. 4.5. Marching Cubes A Vizuális Burok algoritmus által előállított térfogatmodell a Marching Cubes algoritmus segítségével háromszöghálót állítunk elő [6, 9]. Mivel az eljárás meglehetősen népszerű a térfogatmodellek vizualizációja terén, ezért már több hatékony implementációval rendelkezik. Mi az nvidia SDK-ban található megoldást választottuk. Ennek oka, hogy meglehetősen egyszerű, de hatékony implementáció, és könnyen testre szabható igényeinknek megfelelően. 27

4.6. ábra. Simitás alkalmazásának hatása az eredményre. (bal oldalt nincs alkalmazva) A végrehajtás során az algoritmus bejárja a térfogatmodellt. A voxeleket nyolcasával veti össze a megadott küszöbértékkel. Az összehasonlítás eredménye 8 logikai érték, mely a megfelelő voxeleket minősíti aszerint, hogy az objektumban van-e vagy sem. A 8 logikai érték, mint egy bájt segítségével két úgynevezett lookup táblát címzünk. Az első tábla segítségével döntjük el, hogy a 8 voxel által alkotott egységkocka élei közül melyik metszi el az alakzat határvonalát, azaz melyiken helyezkednek el az végeredményt alkotó háromszögháló csúcspontjai. (Lásd 4.7. ábra). A második tábla pedig egy index lista, mely a kapott vertexekből alkotja meg a poligonokat. A csúcspontok végső elhelyezését a voxelek pozicióinak lineáris kombinációjával számítjuk ki a küszöbértéknek megfelelően. Legyen v 0, v 1 a két voxel koordinátiái, f 0, f 1 a voxelekben mért érték, i pedig az aktuális küszöbérték. Ekkor a csúcspont koordinátái: e = (i f 0)v 1 + ( f 1 i)v 0 ( f 1 f 0 ) Az algoritmus végeredményképp vertexek listáját generálja, melyek hármasával egyegy poligont alkotnak. A végeredményt visszaolvashatjuk a videokártya memóriájából egy tömbbe, vagy az OpenGL közreműködést kihasználva egy Vertex Buffer Objectben is eltárolhatjuk a további feldolgozás céljából. 28

4.6. Textúrázás 4.7. ábra. A Marching Cubes algoritmus különböző esetei A munka első fázisa a valósidejű geometriai rekonstrukció volt. Mivel ezt sikerült megvalósítani, a generált geometria valósidejű textúrázása következett. Ezzel a problémával kapcsolatban napjainkban még meglehetősen kevés eredmény született. A létező megoldások, is általában speciális feltételek mellett biztosítanak értékelhető eredményt. Ezért a stúdióban tapasztalható körülményekhez saját módszereket dolgoztunk ki. Az offline verzióban alkalmazott textúra atlaszt előállító megoldás nem alkalmazható, annak nagy erőforrás költsége miatt. A valósidejű eredmény elérése érdekében közvetlenül a bejövő képekből kellett megoldanunk a feladatot. A textúrázást a renderelés alatt fragment shaderek segítségével oldottuk meg GLSL nyelv használatával. Egy pixel színének kiszámítása során első lépésben el kell döntenünk, hogy egy adott kamera egyáltalán látja az általa reprezentált térbeli pontot. Ezt a problémát az árnyéktérképek (shadow maps) segítségével oldja meg a program. A kamerákra, jelen esetben mint fényforrásokra tekintve, előállítjuk a megfelelő árnyéktérképeket minden geometriai rekonstrukciós fázis végén. Ez esetben a takarási probléma az árnyékolási problémával analóg módon megoldható. Amely pixel árnyékban van azt a kamera nem látja. A pixel színének meghatározására két módszer került kidolgozásra. Az egyik módszer robusztusabb, minden kamerák által látható pixelhez képes színinformációt rendelni, de az eredménye meglehetősen zajos. A másik megoldás jóval simább életszerűbb képminőséget biztosít, de működéséhez több kamera alkalmazása szükséges. Alapértelmezésben ez utóbbi módszert alkalmazzuk, de ha a textúrázás nem sikerülne visszaváltunk az elsőre. Mindkét esetben a láthatósági problémát az árnyéktérképek segítségével oldjuk meg. Az első módszer kiszámítja a textúrázandó felület normálvektora, és a kamera irányvektora által bezárt szöget. Egy maximumkereséssel eldöntjük, melyik kamera látja legnagyobb szögből az adott pontot, majd a pixel színének mintavételezését az ehhez tartozó 29

4.8. ábra. A voxelek, és a csúcspontok indexei bejövő képből végezzük. Az algoritmus előnye a robusztusság, azaz minden esetben működik, ha az adott pontot legalább egy kamera látja. Hátránya a meglehetősen zajos kép. Ezt a kamerák közötti éles váltások okozzák (4.10. ábra). Sokkal egyenletesebb eredményt kapunk, ha a textúrázást annak a kamerának a képe alapján végezzük, amelynek irányvektora aktuális nézőpontunkhoz képest a lehető legkisebb szöget zár be. Ezt használja ki a második módszer. Első lépésként, még a renderelés megkezdése előtt CPU oldalon kiszámoljuk a saját és a kamerák nézeti irányvektora által bezárt szöget. A takarási probléma miatt sajnos csak pixel szinten tudjuk meghatározni, hogy mely három kamera a legmegfelelőbb a mintavételezés szempontjából. A művelet gyorsítása érdekében sorba rendezzük a kamerákat a bezárt szög alapján. Ezt a sorrendet küldjük el a fragment shadernek. A shader a takarási információkat is figyelembe véve megpróbálja kiválasztani a három legmegfelelőbb kamerát. Ha sikerül, akkor a kamerák nézeti irányvektorában, mint bázisban felírjuk a mi nézeti irányvektorunkat. Ez a művelet egy mátrix szorzással elvégezhető. A kapott együtthatókat, mint súlyokat használva súlyozzuk az egyes kamerák képéből mintavételezett színinformációkat. Az eredmény lesz a pixel végleges színe (4.11. ábra. A piros színnel jelöltük az eljárás alkalmazásával nem feltextúrázható pixeleket) Ha nem sikerülne három megfelelő kamerát találni, akkor visszaállunk az első módszerre. Ez csak nagyon kevés kamera alkalmazása esetén fordul elő, illetve ha a felület eleve nem látható (4.12. ábra). A textúrázás a többi lépéshez képest aszinkron dolgozik. Végrehajtása a megjelenítő 30

Algorithm 1 Textúrázás Require: n: kamerák száma, I i, i [1..n]: beérkező képek, P i,c i, i [1..n]: a kamerák projekciós mátrixai, és nézeti irányuk, P,v: projekciós mátrix, aktuális nézeti irányunk Ensure: I out : eredmény kép for all pixel u I out do /* A kamerák, és az aktuális nézeti irányunk közötti szögek kiszámítása */ γ i := cos 1 ( vt c i v c i ), i [1..n] /* A legjobb 3 kamera kiválasztása */ i 1,i 2,i 3 := argmin i [1..n] (γ i ) /* Nézeti irányokból előállítjuk a bázist */ B := [c i1,c i2,c i3 ] /* Súlyok kiszámítása */ w := B 1 v /* Súlyok normalizálása */ w := w w[1]+w[2]+w[3] /* A képpontnak megfelelő térbeli pont meghatározása */ X := backproject P (u) u i j := P i j X, j = 1,2,3 /* A pixel színének meghatározása */ I out (u) := w[1]i i1 (u i1 ) + w[2]i i2 (u i2 ) + w[3]i i3 (u i3 ) end for 31

4.9. ábra. A generált háromszögháló VTK-ban ablak minden újrarajzolásakor megtörténik. A többi fázis az árnyéktérképek generálásig bezárólag viszont csak új képek érkezésekor, azaz új geometriai modell létrehozásakor hajtódik végre. 4.6.1. Árnyéktérképek A shadowmapping (árnyéktérképek) algoritmus, egy gyakran használt gyors eljárás valósidejű árnyékok létrehozására. [8] Az eredeti algoritmus irányított, illetve fényszórószerű fényforrásokkal dolgozik, de többszöri alkalmazással pontszerű fényforrások esetén is alkalmazható. Az eljárás a mélységbuffer (z-buffer) segítségével határozza meg az árnyékban lévő részeket. Az első fázisban a fényforrás szemszögéből lerendereli a jelenetet. Közben a mélységbuffert egy speciális textúrába, úgynevezett árnyéktérképbe (shadowmap) mentve. A textúra texelei a fényforrás és a tér egyes pontjai közötti távolságot tartalmazzák. A második fázisban ezt a textúrát a fényforrásnak megfelelő vetítéssel alkalmazzuk a jelenetre. Minden fragmentre összevetjük a textúrából mintavételezett távolság értéket a vetítés által megadott távolság értékkel. Ha utóbbi érték nagyobb akkor az adott fragment árnyékban van, egyébként pedig nem. Az implementáció során a teljesítmény növelése érdekében speciális shader programokat alkalmaztunk, amelyek az árnyéktérképek számítása során csak a mélységértékek 32

4.10. ábra. Az első textúrázási módszer eredménye meghatározásához szükséges műveleteket végzik el. 33

4.11. ábra. Az második textúrázási módszer eredménye 4.12. ábra. A textúrázási módszerek összevonása 34

4.13. ábra. A textúrázott eredmény VTK-ban 4.14. ábra. Árnyékszámítás a generált modellből 35

5. fejezet Megvalósítás 5.1. Fejlesztés során alkalmazott eszközök A működést vezérlő gazdaprogram fejlesztése C++ nyelven történt NetBeans fejlesztő környezet segítségével. Az alkalmazott fordítóprogram a g++ volt. A számításokat elvégző algoritmusokat CUDA C-ben implementáltunk. A textúrázási fázist, annak jellegéből adódóan az OpenGL grafikus környezet, és annak GSLS shadernyelve segítségével valósítottuk meg. A CUDA SDK-ból az akkor elérhető legfrissebb 3.2-es változat került felhasználásra. A forrásállományok kezelését a Subversion verziókezelő rendszer könnyítette meg. Az elkészült eredményeket VTK segítségével jelenítettük meg. A gazdaprogramon belül felmerülő matematikai számításokat az OpenCV könyvtárral végeztük el. A CUDA SDK képességeit a Thrust könyvtárral egészítettük ki. A Thrust, egy ingyenes nyílt forráskódú template könyvtár CUDA alapú alkalmazásokhoz. Magas szintű interfésze a C++ Standart Template Library (STL) számos szolgáltatását valósítja meg. Kezdetben külön kellett telepíteni a CUDA könyvtártól függetlenül, azonban annak 4.0-s verziójától kezdve hivatalosan is a része lett. 5.2. Programkönyvtár ismertetése A fejlesztés során a rekonstrukciós algoritmusok egy programkönyvtárként kerültek implementálásra. Felhasználásával bármilyen programban könnyen elvégezhetjük a valósidejű rekonstrukciót. A kódbázis jelentős része a valósidejű implementáció megvalósítása során készült, csupán néhány metódus került felhasználásra az offline verzióból. A futószalag egyes elemei végrehajtó programrészletek egy-egy osztályban kerültek megvalósításra. Az egyes fázisok egymás interfészein kerülnek összekapcsolásra. A kód jobb áttekinthetősége érdekében az adott lépést megvalósító osztály, és a CUDA nyelven írt algoritmus külön fordítási egységbe került. A továbbiakban ismertetjük az egyes fázisok megvalósításának részleteit. 36

A szegmentálási algoritmusok interfészét a CSilhoutteSource absztrakt osztály biztosítja. Metódusai segítségével beállíthatjuk a működéshez szükséges paramétereket. Az aktuális küszöbérték módosítására és lekérdezésére a setthreshold és getthreshold függvényeket alkalmazhatjuk. Az alkalmazandó háttérképek beállítására a setbackgrounds metódus szolgál. Paraméterként egy bájttömböt vár, melyben a képek RGB kódolásban folytonosan egymás mögött helyezkednek el. Az aktuálisan szegmentálandó képek tömbjére mutató pointert a setimageptrs metódus segítségével állíthatjuk be. A szegmentálás végrehajtását az update metódus váltja ki. Az eredmény egy 3D-s CUDA bufferbe kerül. A szegmentálás egy háttéralapú változatát a CCudaSilhouetteSource osztály valósítja meg. Létrehozáskor meg kell adnunk a feldolgozandó képek méreteit és számát. Az update metódus lefuttatásának hatására a képek feltöltésre kerülnek, majd meghívásra kerül a szegmentálást végző kernel. A művelet egy 3D-s munkatér felett kerül végrehajtásra. Az első két koordináta a feldolgozandó kép pixelét, míg a harmadik koordináta magát a képet választja ki. A munkatér pontjaiban lefutó kernel kódja a következő: g l o b a l void segmentationkernel(cudapitchedptr silhouettebuffer, cudapitchedptr imagebuffer, cudapitchedptr backgroundbuffer, i n t threshold) { uchar* silptr = (uchar*)silhouettebuffer.ptr ; // A munkatéren belüli koordináták lekérdezése i n t i = blockidx.x; i n t j = blockidx.y; i n t k = threadidx.z; // A CUDA buffereken belüli indexek meghatározása s i z e _ t silpitch = silhouettebuffer.pitch ; s i z e _ t silslice = silpitch * silhouettebuffer.ysize ; i n t silidx = k*silslice + j*silpitch + i ; s i z e _ t imgpitch = imagebuffer.pitch ; s i z e _ t imgslice = imgpitch * imagebuffer.ysize ; i n t imgidx = k*imgslice + j*imgpitch + 3*i ; s i z e _ t bgpitch = backgroundbuffer.pitch ; s i z e _ t bgslice = bgpitch * backgroundbuffer.ysize ; i n t bgidx = k*bgslice + j*bgpitch + 3*i ; // A szegmentálás i n t diff = abs(fetchimg(imgidx + 0) - fetchbg(bgidx + 0)) + abs(fetchimg(imgidx + 1) - fetchbg(bgidx + 1)) + abs(fetchimg(imgidx + 2) - fetchbg(bgidx + 2)); 37

uchar res = (diff<threshold)?0:255 ; } silptr[silidx] = res ; Textúrázás alkalmazása esetén a CCudaSilhouetteTextureSource osztályt kell használunk, mely a szegmentálás elvégzése mellett biztosítja az textúrázási fázis számára a megfelelő adatokat. A futószalag további algoritmusainak a rekonstrukció elvégzéséhez szüksége van a kamerák pontos kalibrációs adataira. Ezen adatok egyszerű kezeléséért a CCameraTransformGroup osztály felelős. A kalibrációs adatok a kamerák natív felbontása mellett kerültek meghatározásra. Mivel a valósidejű rekonstrukció során különböző méretű feldolgozandó képeket használhatunk, ezért szükség van az adatok korrekciójára. A megvalósítás biztosítja ennek a műveletnek az elvégzését. Lekérdezhető továbbá a rekonstruálandó 3Ds tér befoglaló téglatestének koordinátái is. A térfogatmodellt előállító algoritmusokat a CVolumeSource absztrakt osztály fogja össze. Optimalizációs okokból megkötés, hogy az előállítandó modell mérete csak kettő hatvány lehet. Egy Vizuális Burok algoritmus használó megvalósítás a CCudaVolume- Source osztály. Létrehozáskor meg kell adni, a használandó CSilhouetteSource és CCameraTransformGroup típusnak megfelelő objektumokat, illetve a előállítandó térfogatmodell méretét. Az update metódus hívása során automatikusan frissíti a hozzá kapcsolódó CSillhouetteSource objektum állapotát is. Ez a működés jellemző a végrehajtási futószalag összes fázisára is, így a rekonstrukció során elég csak az utolsó lépés frissítéséről gondoskodni. Az alkalmazott munkatér a térfogatmodellből adódóan természetes 3 dimenziós. Az aktuális szál indexei megfelelnek a térfogatmodell koordinátáinak. A kamera transzformációs mátrixainak segítségével a koordinátákat a sziluettképek terébe vetítjük. A voxel értéke a sziluettképekből mintavételezett értékek minimuma lesz. A műveletet elvégző kernel a következő: f l o a t xf, yf, zf // A voxel koordinátáinak meghatározása xf, yf, zf változókba //... volrow[x] = 0xFF; // vetítés minden sziluett képre f o r ( i n t i = 0; i < img_depth; ++i) { uint sp = 3 * 4 * i; 38