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

E ÖTVÖS L ORÁND T UDOMÁNYEGYETEM I NFORMATIKAI K AR

Mozgó alakzatok valósideju˝ 3D-s rekonstrukciója és megjelenítése D IPLOMAMUNKA

Témavezet˝o:

Készítette:

Csetverikov Dmitrij

Hapák József

egyetemi tanár

Programtervez˝o 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 1.1. Dolgozat felépítése . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4 4

2. A feladat áttekintése 2.1. A stúdió felépítése . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2. A vezérl˝oszoftver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3. A feladat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6 6 8 8

3. Tudományos, technikai el˝ozmények 3.1. GPGPU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2. nVidia CUDA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.1. Kernelek . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.2. Szál hierarchia . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.3. Memória hierarchia . . . . . . . . . . . . . . . . . . . . . . . 3.3. További technológiák . . . . . . . . . . . . . . . . . . . . . . . . . . 3.4. Szakirodalmi el˝ozmények . . . . . . . . . . . . . . . . . . . . . . . . 3.4.1. INRIA Rhone-Alpes, Montbonnot, Franciaország . . . . . . . 3.4.2. Max Planck Institut, Saarbrücken, Németország . . . . . . . . 3.4.3. Institute of Computer Science (ICS), Heraklion, Görögország 3.4.4. University of Surrey, Guildford, Nagy-Britannia . . . . . . . 3.4.5. University of Southern California . . . . . . . . . . . . . . . 4. Megoldás áttekintése 4.1. Képek feltöltése . . . . 4.2. Szegmentálás . . . . . 4.3. Vizuális Burok . . . . 4.4. Élsimítás . . . . . . . 4.5. Marching Cubes . . . . 4.6. Textúrázás . . . . . . . 4.6.1. Árnyéktérképek

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

2

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . . . . . . .

. . . . . . .

. . . . . . . . . . . .

11 11 15 15 15 16 17 18 18 19 19 20 21

. . . . . . .

22 23 23 24 26 27 29 32

5. Megvalósítás 5.1. Fejlesztés során alkalmazott eszközök . . . . . . . . . . . . . . . . . . . 5.2. Programkönyvtár ismertetése . . . . . . . . . . . . . . . . . . . . . . . . 5.3. Gyakorlati alkalmazás . . . . . . . . . . . . . . . . . . . . . . . . . . .

36 36 36 42

6. Tesztelés, eredmények 6.1. Tesztelés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.2. Eredmények, további tervek . . . . . . . . . . . . . . . . . . . . . . . .

44 44 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˝odés hatására egyre magasabb min˝oség˝u számítógépes grafikai megoldásokat alkalmaz. Ennek a magas szintnek az eléréséhez megfelel˝o min˝oség˝u bemen˝o adatokra van szükség, amik még napjainkban is nagyrészt emberi munka által kerülnek el˝oá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˝oben változó színteret magas min˝osé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˝o 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˝oben változó színtér valósidej˝u rekonstrukciója. Illetve amennyiben ez kivitelezhet˝onek bizonyul, akkor az ezt végrehajtó szoftverkomponenst megvalósítani a stúdió meglév˝o vezérl˝oszoftveré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˝ott betekintést nyerhetünk a várható eredménybe. A felhasználási lehet˝osé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˝o átültetése.

1.1.

Dolgozat felépítése

A dolgozat els˝o 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˝oforduló 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˝o é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˝ol, é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˝oj˝u, 3 méter magas fémváz, mely zöld szín˝u 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˝ol, hat pedig lentr˝ol rögzíti a stúdió bels˝o 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˝ol A kamerák által küldött nagy mennyiség˝u adat mentéséért összesen 7 számítógép felel˝os. 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˝o merevlemezeken kerülnek tárolásra. A számítógépeken Open SUSE operációs rendszer fut. A kés˝obbi feldolgozás érdekében minden számítógép el van látva egy közepes teljesítmény˝u videokártyával. A valósidej˝u rekonst6

rukciót végz˝o PC egy nagyteljesítmény˝u 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˝odnek. Az elérhet˝o 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˝o min˝oség˝u képek el˝oá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˝ovel próbáljuk korrigálni, akkor elmosott, részletszegény képeket kaphatunk. Túl er˝os megvilágítás használata esetén pedig a fényforráshoz közel es˝o részek telít˝odhetnek, 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˝ol 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˝ol világító er˝os fény elronthatja a felvételek min˝osé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˝oegység felel˝os. Ez a vezérl˝oegység végzi a kamerák szinkronizálását, és lehet˝ové teszi az egyes fényforrások külön-külön történ˝o 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˝oeltolódást eredményez a felvételek között, de ez érdemben nem befolyásolja a rekonstrukció min˝oségét.

2.2.

A vezérl˝oszoftver

A stúdió, mint egy összetett hardverrendszer m˝uködtetése bonyolult feladat, saját szoftvert követel meg [10]. A szoftvernek lehet˝oséget kell adnia a következ˝o feladatok elvégzésére: • stúdió kameráinak kalibrálása, • a kamerák mikrokontroller segítségével való szinkron m˝ukö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˝u 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˝u kiegészíthet˝oségének a biztosítása, lehet˝oséget adva a stúdió további funkciókkal való könny˝u tovább fejlesztésére. Munkám során a stúdió már meglév˝o vezérl˝oszoftverét kellett kib˝ovíteni a valósidej˝u rekonstrukciót lehet˝ové tev˝o komponenssel.

2.3.

A feladat

A munka célja megvizsgálni, hogy megfelel˝oen 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˝u rekonstrukciója és megjelenítése. A munka kiinduló pontja a már elkészített 8

2.4. ábra. A stúdió vezérl˝oszoftvere utófeldolgozáson alapuló offline m˝uködés volt. Ennek használatával egy tíz másodperces rögzített adatfolyam feldolgozása 30 percet vesz igénybe. Az id˝onek a nagy részét a lemezm˝uveletek teszik ki. A valósidej˝u implementációban az offline m˝uködéssel ellentétben nincs szükség a felvételek rögzítésére, a rendelkezésre álló feldolgozási id˝ot a lehet˝o legjobb min˝oség elérése kell fordítani A feladat megoldása jelent˝os 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öz˝oek. 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, s˝ur˝u geometria létrehozása a cél. A m˝uvelet elvégzéséhez nincs szükség markerek elhelyezésére, így lehet˝oség nyílik állatok, vagy akár füst rekonstrukciójára is. A munka eredményét egy a stúdiót m˝uködtet˝o már elkészült vezérl˝oprogramhoz in1 http://en.wikipedia.org/wiki/Motion_capture

9

tegrálható kiegészítésként kellett megvalósítani. A vezérl˝oprogram 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˝u megjeleníthet˝osége a Visualisation Toolkit2 segítségével.

2 http://www.vtk.org/

10

3. fejezet Tudományos, technikai el˝ozmények 3.1.

GPGPU

Napjainkra a számítógépekben található grafikus processzor - f˝oleg a játékfejlesztés jóvoltából - óriási fejl˝odésen ment keresztül. Ezeknek a sokmagos architektúrával rendelkez˝o processzoroknak a teljesítménye rövid id˝on belül elérte, kés˝obb 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˝os számítási kapacitásnak az általános célra történ˝o 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˝u 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˝u feladat. Kezdetben a grafikus API-kra épül˝o, azok kényelmetlenségét elfed˝o könyvtárak próbálták segíteni a fejleszt˝ok 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˝o korlátozásokat mind technikai, mind teljesítménybeli téren. Kés˝obb az ipar igényeire válaszolva elkészült az els˝o gyártó független megoldás is - az OpenCL. Ezt a kiemelked˝o teljesítményt a grafikus processzorok a központi feldolgozó egységt˝ol jelent˝osen eltér˝o 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˝ubb feldolgozó egységgel rendelkezik. Ezen kívül az egyes részfunkciókra alkalmazott tranzisztorok száma is jelent˝os 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˝odve 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˝os 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˝u adatpárhuzamosságra alapozó egyszer˝u folyamatvezérlést tartalmazó algoritmusok esetén van lehet˝oség. A technológia legnagyobb gyengesége a GPU-val történ˝o kommunikáció. Mivel a videókártya saját nagysebesség˝u 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˝osen költséges. Napjainkban érkeztünk el a személyi számítógépek 3. érájába. Minden nagyobb ipari szerepl˝o fejlesztéseire jellemz˝o a törekvés a két különböz˝o architektúra el˝onyeinek egyesítésére. A 2011-es évben megjelen˝o APU-k (Accelarated Processing Units) vegyesen tartalmaznak a GPU, illetve a CPU-ra jellemz˝o feldolgozó egységeket. A magok egy szilicum lapkán való kialakításának az el˝onye az alacsony fogyasztás, továbbá lehet˝oség adódik különböz˝o 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˝ové. 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˝u 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˝o eszközkészletekre, paradigmákra van

12

3.2. ábra. A rekonstrúkció végrehajtására alkalmazott GF110 GPU bels˝o 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˝o CPU-n futó úgynevezett gazdaprogram, egyszer˝u, f˝oleg adatpárhuzamosságra alapozó feladatokkal bízza meg a nagy teljesítmény˝u GPU-t. A gazdaprogram szokványos programozási nyelvek segítségével készíthet˝o 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˝uveletek, vagy a párhuzamosságot támogató szinkronizációs m˝uveletek. Az általunk a valósidej˝u 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˝o technológiák, így esetünkben nem voltak alkalmazhatóak. A GLSL az OpenGL grafikus könyvtár saját C szer˝u programozási nyelve, mellyel a korszer˝u 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˝o 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˝osen feltörekv˝o nyílt technológia, mely lehet˝ové 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˝u támogatottságát a felhasználói programok írásakor kamatoztathatjuk, hiszen az otthoni multimédiás eszközök jelent˝os hányada támogatja. Jelent˝osége az utóbbi években az APU-k megjelenésével tovább n˝ot, hiszen egy egységes felületet nyújt azok teljes mérték˝u kihasználáshoz, meg˝orizve 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˝uködésre képes. A hatékony m˝uködés érdekében lehet˝oség van er˝oforrások megosztására a két technológia között. A CUDA-val ellentétben viszont - a technológia frissességéb˝ol adódóan - számottev˝oen kisebb szakirodalom bázissal, a fejlesztést megkönnyít˝o könyvtárral és eszközzel rendelkezik jelenleg. Az CUDA (Compute Unified Device Architecture) a heterogén programozást lehet˝ové tev˝o eszközkészlet az nVidia-tól. Lehet˝oséget ad a cég által gyártott grafikus processzorok teljesítményének egyszer˝u kihasználására. Els˝o 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˝osége révén nagyobb felhasználói bázissal, kiforrottabb eszközkészlettel rendelkezik. Az OpenCL-hez hasonlóan képes együttm˝uködni az OpenGL grafikus környezettel. Választásunk végül a CUDA platformra esett annak magasabb színt˝u 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˝oforrás megosztás lehet˝osé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˝o 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˝ové teszi a programozóknak úgynevezett kernelek írását. A kernelek egyszer˝u 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 _ _ v o i d VecAdd( f l o a t * A, f l o a t * B, f l o a t * C) { i n t i = t h r e a d I d x .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˝o 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˝ové. 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˝o le. A szálak csoportja úgynevezett blokkokat alkot (3.4. ábra). A blokkban résztvev˝o szálakra igaz, hogy azok végrehajtása egy processzoron belül zajlik. Így lehet˝oség nyílik a processzor bels˝o memóriája segítségével az adatmegosztásra. A blokkok hálókba szervez˝odnek. 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˝o 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˝ové 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˝o 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˝oséget biztosít különböz˝o típusú bejöv˝o adatok egyszer˝u 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˝oben rekonstruált adatok VTK-ban történ˝o 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˝ujti össze. Kialakítása során nagy figyelmet fordítottak, hogy az implementált funkciók valósidej˝u programok írása esetén is alkalmazhatóak legyenek. Az implementált algoritmusokat a fejleszt˝ok a következ˝o 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˝ozmé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˝u 3D-s modellezés • Nagy er˝oforrás igény˝u fizikai szimulációk • Nagy er˝oforrás igény˝u 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 Solution2 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˝os. 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˝u feladatok elvégzése esetén lehet˝osé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˝obb célja mozgó emberi alakzatok rekonstrukciója. Magáról a stúdió hardveres felépítésér˝ol kevés információ található. A modelleket els˝o 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˝o 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˝ol automatikus csontváz modell el˝oá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˝ové teszi az emberi kéz által végzett m˝uveletek rögzítését és feldolgozását. [2] A munka keretein belül egy valósidej˝u implementáció is elkészítésre került. A megfigyelt terület egy 2 × 1 m2 terület˝u 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˝o 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épekb˝ol térfogatmodellt építenek a Vizuális Burok algoritmus segítségével. A valósidej˝u rekonstrukció során nincs lehet˝oség az el˝oá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 vezet˝onek 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ételekb˝ol. Az el˝oállított tartalom min˝osége megfelel a

20

filmipari és játékipari felhasználás által támasztott magas követelményeknek. A fejlesztések lehet˝ové tették a felvételek újrahasznosítását, utólag más megvilágítás és néz˝opont 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övetkez˝o eredményeket sikerült elérni: • Álló és mozgó alakzatok rögzítése és 3D adatstruktúrában való eltárolása. • Magas min˝oség˝u adatok rögzítése díszletekr˝ol és színészekr˝ol, hogy lehet˝ové tegyék más jelenetekben való alkalmazásukat. • A színészek arcának és ruhájának magas min˝oségben történ˝o 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ért˝ojé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öz˝o irányú, szín˝u fényforrásokkal megvilágított alakzatok felületének normálvektorai a megvilágítás alapján becsülhet˝o. A különböz˝o fényforrások és kamerák alapján kinyert normálvektorok összeregisztrálásával felépíthet˝o 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˝u 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˝uzve kialakításra került egy végrehajtási futószalag (4.1. ábra), mely lehet˝ové teszi a valósidej˝u rekonstrukciót. Az eljárás els˝o lépése, amint a vezérl˝oszoftver 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˝ofeldolgozzák: a Bayer kódolásból [1] RGB színtérbe alakítják, és elvégzik a megfelel˝o átméretezést is. Ezután a képeket szegmentáljuk elválasztva a stúdió hátterét az el˝otért˝ol. 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˝ol a Vizuális Burok algoritmussal térfogat modellt állítunk el˝o. 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˝o renderelése. Ez a lépés felbomlik úgynevezett shadowmapok (árnyéktérképek) el˝oállítására, és magára a textúrázásra. A futószalag modulárisan került implementálásra. Annak tetsz˝oleges része külön lefuttatható, a részeredmények kinyerhet˝ok. Ezáltal lehet˝osé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˝ok, mint például a textúrázás vagy a sziluettképek simítása. Ezt az igényt szem el˝ott 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˝u 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˝uvelet, végrehajtása mégis költséges a PCI-Express busz alacsony átereszt˝o képessége miatt. A képeket a vezérl˝oprogramtól egy összefügg˝o 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˝o képek szétválasztása háttérre és el˝otérre. Az eljárás végeredménye egy az eredetivel megegyez˝o méret˝u bináris kép, melyben a fekete pixelek háttérhez, a fehér pixelek pedig az el˝otérhez tartoznak. Több különböz˝o elv˝u 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˝o 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˝otérhez tartozik, egyébként pedig a háttérhez. Jelöljük i-vel az el˝oté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˝o formula alapján hajtódik végre. d = |ir − bgr | + |ig − bgg | + |ib − bgb | ahol az r, g, b a megfelel˝o 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˝o 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˝otér színeit.

4.2. ábra. A feldolgozásra beérkez˝o 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˝osége van a grafikus processzor textúra mintavételez˝oire 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˝uveletigénye a képpontok számában lineáris.

4.3.

Vizuális Burok

A szegmentált képekb˝ol a Vizuális Burok (Visual Hull) [4, 5] nev˝u eljárással állítunk el˝o 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˝ur˝uségértékeit. Esetünkben egy valószín˝uségi érték kerül tárolásra, mely jellemzi, hogy a rekonstruálandó objektum, milyen valószín˝uséggel található az adott voxelben. Az eljárás bemen˝o 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˝ol, egy „sziluett alapú gúlát” metsz ki. Minden kamerára elvégezve a m˝uveletet, megkapjuk a rekonstruálandó tér durva modelljét. Az eljárást m˝uködési módszeréb˝ol 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˝ol. 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˝o ü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˝o modell voxeleit. A voxel térbeli pozícióijának ismeretében, lehet˝oségünk van annak helyét meghatározni az egyes kamerák terében. Jelöljük Ri -vel az i. kamera forgatási, Ki -vel a kameramátrixát, Legyen ti a kamera térbeli poziciója. T a térfogatmodell indexteréb˝ol a rekonstruálandó térbe átviv˝o transzformáció. Ekkor a képpont koordinátái a szegmentált képen ci = Ki (Ri T [x, y, z]T + ti ) 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) = min1..n (tex2D(Si , ci )), ahol n a kamerák száma, Si az aktuális kamerához tartozó sziluettkép, tex2D pedig egy textúra mintavételez˝o függvény.

4.4. ábra. A Vizuális Burok algoritmus Mivel a sziluettb˝ol 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˝ofeldolgozási lépésként a textúrából több különböz˝o méret˝u verziót, úgynevezett réteget állít el˝o. A mintavételezés során egy, vagy akár több réteget alkalmaz a lehet˝o legjobb eredmény elérése érdekében. Mivel esetünkben az alkamazott textúrák dinamikusan kerülnek el˝oállításra, és a mipmapping algoritmus alkalmazására költséges, annak el˝ofeldolgozási lépése miatt, ezért kompromisszumokat kell kötni. A szegmentált képekre a Vizuális Burok eljárás el˝ott 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˝u térfogatmodellt járja be. Minden voxelben mintavételezés történik az egyes sziluettképekb˝ol. Az m˝uveletigé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˝o 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˝u implementációban ezt egy egyszer˝u szeparábilis dobozsz˝ur˝o 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˝ur˝o mérete futásid˝oben nem módosítható, csak a teljes program újrafordításával. Ez lehet˝osé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˝osége van a textúra mintavételez˝ok alkalmazására, mely egyszerre több adatot képes elérni, mindezt gyorsítótárazva. Ez különösen el˝onyös a simítás szempontjából, hiszen a sz˝urés folyamán sokszor van szükségünk ugyanazokra az értékekre. M˝uveletigé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˝oséget, míg jobboldalt viszont igen.

4.5.

Marching Cubes

A Vizuális Burok algoritmus által el˝oállított térfogatmodell a Marching Cubes algoritmus segítségével háromszöghálót állítunk el˝o [6, 9]. Mivel az eljárás meglehet˝osen népszer˝u 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˝osen egyszer˝u, de hatékony implementáció, és könnyen testre szabható igényeinknek megfelel˝oen.

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˝o voxeleket min˝osí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˝o 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˝ol alkotja meg a poligonokat. A csúcspontok végs˝o elhelyezését a voxelek pozicióinak lineáris kombinációjával számítjuk ki a küszöbértéknek megfelel˝oen. Legyen v0 , v1 a két voxel koordinátiái, f0 , f1 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 − f0 )v1 + ( f1 − i)v0 ( f1 − f0 )

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˝uködést kihasználva egy Vertex Buffer Objectben is eltárolhatjuk a további feldolgozás céljából.

28

4.7. ábra. A Marching Cubes algoritmus különböz˝o esetei

4.6.

Textúrázás

A munka els˝o fázisa a valósidej˝u geometriai rekonstrukció volt. Mivel ezt sikerült megvalósítani, a generált geometria valósidej˝u textúrázása következett. Ezzel a problémával kapcsolatban napjainkban még meglehet˝osen kevés eredmény született. A létez˝o megoldások, is általában speciális feltételek mellett biztosítanak értékelhet˝o 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˝oállító megoldás nem alkalmazható, annak nagy er˝oforrás költsége miatt. A valósidej˝u eredmény elérése érdekében közvetlenül a bejöv˝o képekb˝ol 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˝o 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˝oállítjuk a megfelel˝o á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˝osen zajos. A másik megoldás jóval simább életszer˝ubb képmin˝oséget biztosít, de m˝ukö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˝ore. Mindkét esetben a láthatósági problémát az árnyéktérképek segítségével oldjuk meg. Az els˝o 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˝ol 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˝o képb˝ol végezzük. Az algoritmus el˝onye a robusztusság, azaz minden esetben m˝uködik, ha az adott pontot legalább egy kamera látja. Hátránya a meglehet˝osen 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˝opontunkhoz képest a lehet˝o legkisebb szöget zár be. Ezt használja ki a második módszer. Els˝o lépésként, még a renderelés megkezdése el˝ott 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˝obb a mintavételezés szempontjából. A m˝uvelet 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˝obb 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˝uvelet egy mátrix szorzással elvégezhet˝o. A kapott együtthatókat, mint súlyokat használva súlyozzuk az egyes kamerák képéb˝ol 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˝o kamerát találni, akkor visszaállunk az els˝o módszerre. Ez csak nagyon kevés kamera alkalmazása esetén fordul el˝o, 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˝o 30

Algorithm 1 Textúrázás Require: n: kamerák száma, Ii , i ∈ [1..n]: beérkez˝o képek, Pi , ci , 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: Iout : eredmény kép for all pixel u ∈ Iout do /* A kamerák, és az aktuális nézeti irányunk közötti szögek kiszámítása */ vT ci ), i ∈ [1..n] γi := cos−1 ( kvkkc ik /* A legjobb 3 kamera kiválasztása */ i1 , i2 , i3 := arg mini∈[1..n] (γi ) /* Nézeti irányokból el˝ oállítjuk a bázist */ B := [ci1 , ci2 , ci3 ] /* 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˝ o térbeli pont meghatározása */ X := backprojectP (u) ui j := Pi j X, j = 1, 2, 3 /* A pixel színének meghatározása */ Iout (u) := w[1]Ii1 (ui1 ) + w[2]Ii2 (ui2 ) + w[3]Ii3 (ui3 ) 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˝u árnyékok létrehozására. [8] Az eredeti algoritmus irányított, illetve fényszórószer˝u fényforrásokkal dolgozik, de többszöri alkalmazással pontszer˝u 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˝o részeket. Az els˝o fázisban a fényforrás szemszögéb˝ol 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˝o 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˝o textúrázási módszer eredménye meghatározásához szükséges m˝uveleteket 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˝ol 35

5. fejezet Megvalósítás 5.1.

Fejlesztés során alkalmazott eszközök

A m˝uködést vezérl˝o gazdaprogram fejlesztése C++ nyelven történt NetBeans fejleszt˝o környezet segítségével. Az alkalmazott fordítóprogram a g++ volt. A számításokat elvégz˝o algoritmusokat CUDA C-ben implementáltunk. A textúrázási fázist, annak jellegéb˝ol 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˝o legfrissebb 3.2-es változat került felhasználásra. A forrásállományok kezelését a Subversion verziókezel˝o 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˝o 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˝u 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˝u rekonstrukciót. A kódbázis jelent˝os része a valósidej˝u 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˝osé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˝ukö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˝o kernel. A m˝uvelet egy 3D-s munkatér felett kerül végrehajtásra. Az els˝o 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˝o: _ _ g l o b a l _ _ v o i d 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 = b l o c k I d x .x; i n t j = b l o c k I d x .y; i n t k = t h r e a d I d x .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
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˝o 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˝u kezeléséért a CCameraTransformGroup osztály felel˝os. A kalibrációs adatok a kamerák natív felbontása mellett kerültek meghatározásra. Mivel a valósidej˝u rekonstrukció során különböz˝o méret˝u 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˝uveletnek az elvégzését. Lekérdezhet˝o továbbá a rekonstruálandó 3Ds tér befoglaló téglatestének koordinátái is. A térfogatmodellt el˝oállító algoritmusokat a CVolumeSource absztrakt osztály fogja össze. Optimalizációs okokból megkötés, hogy az el˝oállítandó modell mérete csak kett˝o hatvány lehet. Egy Vizuális Burok algoritmus használó megvalósítás a CCudaVolumeSource osztály. Létrehozáskor meg kell adni, a használandó CSilhouetteSource és CCameraTransformGroup típusnak megfelel˝o objektumokat, illetve a el˝oá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˝uködés jellemz˝o 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˝ol gondoskodni. Az alkalmazott munkatér a térfogatmodellb˝ol 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˝ol mintavételezett értékek minimuma lesz. A m˝uveletet elvégz˝o kernel a következ˝o: 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

// A koordináták f l o a t u = P[sp + + P[sp + f l o a t v = P[sp + + P[sp + f l o a t w = P[sp + + P[sp +

transzformálása a sziluettképek terébe 0] * xf + P[sp + 1] * yf 2] * zf + P[sp + 3]; 4] * xf + P[sp + 5] * yf 6] * zf + P[sp + 7]; 8] * xf + P[sp + 9] * yf 10] * zf + P[sp + 11];

i n t ui = ( i n t ) (u / w + 0.5); i n t vi = ( i n t ) (v / w + 0.5); uchar res = 0; i f (ui >= 0 && ui < img_width && vi >= 0 && vi < img_height) { i n t idx = i * silh_wh + vi * silh_w + ui; res = tex1Dfetch(silhouetteTexture, idx); } // Ha az aktuális érték kisebb, aktualizálunk i f (volrow[x] > res) volrow[x] = res; // Ha elértük a nullát kilépünk i f (volrow[x] == 0) break ; }

A térfogatmodell generálása el˝ott a sziluettképek simítását a CCudaSilhouetteBlur osztály példányával végezhetjük. Az implementáció a CSilhouetteSource interfészt valósítja meg. Ezáltal könnyen beékelhet˝ové válik a sziluettképeket, illetve a térfogatmodellt el˝oállító lépések közé. Az alap megvalósítás egy szeparábilis doboz sz˝ur˝ot alkalmaz. Els˝o lépésként a sorok mentén végezzük el a sz˝urést az eredményeket egy átmeneti pufferbe írva. A második lépés az oszlopok mentén dolgozza fel az átmeneti puffer adatait és a végeredmény a kiindulási pufferbe kerül. A sz˝ur˝o méretét konstansként definiáljuk, csak újrafordítással módosíthatjuk meg. Ezáltal a CUDA fordítónak lehet˝osége van a ciklusok kibontása segítségével optimalizálni a kódot. Mivel a szegmentáláshoz hasonlóan itt is képek csoportjával dolgozunk, ezért szintén egy 3 dimenziós munkateret alkalmazunk. Az oszlopok mentén történ˝o sz˝urésért a következ˝o kódrészlet a felel˝os: # d e f i n e KERNEL_RADIUS 4 _ _ g l o b a l _ _ v o i d silhouetteConvolutionColumnKernel(cudaPitchedPtr sourceBuffer,

39

cudaPitchedPtr resultBuffer) { uchar* resptr = (uchar*)resultBuffer.ptr ; // A munkatér koordinátáinak lekérdezése i n t x = b l o c k I d x .x; i n t y = b l o c k I d x .y; i n t z = t h r e a d I d x .z; // Pufferben belüli pozició meghatározása s i z e _ t resPitch = resultBuffer.pitch ; s i z e _ t resSlice = resPitch * resultBuffer.ysize ; i n t resIdx = z*resSlice + y*resPitch + x ; s i z e _ t srcPitch = sourceBuffer.pitch ; s i z e _ t srcSlice = srcPitch * sourceBuffer.ysize ; uint offset = z*srcSlice ; // Értékek összegzése i n t sum = 0 ; f o r ( i n t j = -KERNEL_RADIUS; j <= KERNEL_RADIUS; ++j) { i n t i = y+j ; i f (i < 0) c o n t i n u e ; i f (i > sourceBuffer.ysize) c o n t i n u e ; i = i*srcPitch+x ; sum +=

tex1Dfetch(tempTexture,offset+i) ;

} // Eredmény visszaírása resptr[resIdx] = sum/ ( 2*KERNEL_RADIUS+1 ) ; }

Az el˝oállított térfogatmodellt egy vizualizációs eszköz segítségével akár meg is jeleníthetjük, de a CCudaMarchingCubes osztály segítségével a GPU-k által hatékonyan feldolgozható háromszöghálóvá alakíthatjuk. Mivel a Marching Cubes algoritmust széleskör˝uen alkalmazzák a számítógépes grafikai feladatok megoldása során, ezért a Cuda SDK már tartalmazott egy az architektúrára optimalizált megvalósítást. Ezt az implementációt a feladat igényeinek megfelel˝oen testre szabtuk, majd a CCudaMarchingCube osztály segítségével beillesztettük a végrehajtási futószalagba. A felület meghatározásánál alkalmazott iso érték a getIsoValue és a setIsoValue függvényekkel lekérdezhet˝o illetve módosítható. Az el˝oállított csúcspontok és normálvektorok listáját igény szerint egy tömbben, vagy egy OpenGL VBO-ban (Vertex Buffer Object) kaphatjuk meg. A VBO egyszer˝u megjelenítését teszi lehet˝ové a CBufferDrawer osztály. drawBuffer 40

metódusának meghívása esetén végrehajtja a kirajzoláshoz szükséges megfelel˝o OpenGL parancsokat. Létrehozásakor a geometriát szolgáltató CCudaMarchingCubes típusú objektumot várja paraméterként. A rendszer által megvalósított textúrázás a CTexturedBufferDrawer osztályban került implementálásra. Interfésze megegyezik a CBufferDrawer osztállyal, de m˝uködését kiegészíti a textúrázás végrehajtásához szükséges m˝uveletekkel. Ennek elvégzéséhez a CCudaMarchingCube objektumon túl szüksége van a textúrákat biztosító CSilhoutteTextureSource, és a kalibrációs adatokat tartalmazó CCameraTransformGroup példányváltozókra is. Meg kell adni még a textúrázásért és árnyékszámításért felel˝os shaderprogramokat tartalmazó könyvtár elérési útvonalát is. Az update metódusának meghívás esetén frissíti a futószalagban mögötte található elemeket, és újraszámolja a geometriához tartozó árnyéktérképeket is. A drawBuffer metódus els˝o lépésként sorbarendezi a kamerákat néz˝opontukkal bezárt szög alapján. Ez a sorrend feltöltése kerül a pixel szint˝u textúrázást végrehajtó shaderprogramba. Ennek alkalmazásával a puffer kirajzolásakor elvégezhetjük a textúrázást. A következ˝o kódrészlet a második textúrázási módszer megvalósítása: // cdirs - kamerák irányvektorai // camids - a sorbarendezett kamerák indexei // Els˝ o 3 legjobb kamera megkeresése int j = 0 ; i n t usedCams[3] ; f o r ( i n t i = 0; i < imgCount; ++i) { i f (isShadowed(camids[i])) c o n t i n u e ; usedCams[j] = i ; j++ ; i f (j == 3) break ; } // Ha találtunk 3 kamerát elvégezzük a textúrázást i f (j >= 3) { // létrehozzuk a nézeti vektorokból a bázist mat3 base = mat3( cdirs[camids[usedCams[0]]], cdirs[camids[usedCams[1]]], cdirs[camids[usedCams[2]]] ) ; base = inverse(base) ; // meghatározzuk a súly együtthatókat v e c 3 alfa = base*view_dir ; // a negatív súlyokat elhagyjuk f o r ( i n t i = 0 ; i < 3;++i) { i f (alfa[i] < 0) alfa[i] = 0 ; }

41

f l o a t s = alfa[0] + alfa[1] + alfa[2] ; v e c 3 color = v e c 3 (0.0) ; // Mintavételezünk és összegzünk a normalizált súlyokkal f o r ( i n t i = 0; i < 3; ++i) { f l o a t w = alfa[i] / s ; i n t id = camids[usedCams[i]] ; color += w*fetchTexture(id).xyz ; } } else { ... }

A CRfvrVtkMapper osztály segítségével beburkolhatjuk a CBufferDrawer típusú objektumunkat, ezáltal azt a Visualization Toolkit segítségével könnyen megjeleníthet˝ové tehetjük.

5.3.

Gyakorlati alkalmazás

Ebben a fejezetben bemutatjuk, hogy a programkönyvtár segítségével milyen egyszer˝uen építhetünk és alkalmazhatunk különböz˝o rekonstrukciós futószalagokat. A következ˝o kódrészlet egy simítással ellátott geometria rekonstrukciót és megjelenítést végrehajtó futószalagot inicializál textúrázás nélkül. // kamera kalibráció betöltése CCameraTransformGroup ctg(camTransforms,imgWidth,imgHeight,1.0f) ; CSilhouetteSource* ss = new CCudaSilhouetteSource(imgWidth,imgHeight ,imgCount) ; ss->setImagePtrs(imgptr) ; ss->setBackGrounds(bgptr) ; CSilhouetteSouce* sb = new CCudaSilhouetteBlur(ss) ; // 128x128x128-as térfogatmodell alkalmazása CVolumeSource* vs = new CCudaVolSource(sb,ctg,7,7,7) ; CCudaMarchingCube* cmc = new CCudaMarchingCube(vs) ; CBufferDrawer* bd = new CBufferDrawer(cmc) ; CRfvrVtkMapper* mapper = new CRfvrVtkMapper(bd) ;

42

vtkActok actor = vtkActor::New(); actor->SetMapper(mapper) ;

Látható, hogy ahol csak lehetett a lehet˝o legáltalánosabb interfészt használtuk a változók típusának. Ezáltal a kód sokkal karbantarhatóbbá válik, különböz˝o algoritmusok alkalmazása esetén nincs szükség a kód újraírására. A megfelel˝o metódusok hívásáról és az er˝oforrások felszabadításáról a dinamikus kötés mechanizmusa gondoskodik. A futószalag frissítését a CBufferDrawer update metódusa segítségével válthatjuk ki. Ha szükséges a végrehajtás el˝ott átállíthatjuk a bejöv˝o képekre mutató pointert a CSilhouetteSource objektumunk setImagePtrs metódusa segítségével. Abban az esetben, ha teljesítménybeli korlátok miatt nem élünk az simítás lehet˝oségével, akkor egyszer˝uen hagyjuk ki a lépések inicalizálása során. CSilhouetteSource* ss = new CCudaSilhouetteSource(imgWidth,imgHeight ,imgCount) ; ss->setImagePtrs(imgptr) ; ss->setBackGrounds(bgptr) ; // CSilhouetteSouce* sb = new CCudaSilhouetteBlur(ss) ; // 128x128x128-as térfogatmodell alkalmazása CVolumeSource* vs = new CCudaVolSource(ss,ctg,7,7,7) ;

A textúrázás alkalmazása esetén csak az érintett objektumok típusának megváltoztatása szükséges: // kamera kalibráció betöltése CCameraTransformGroup ctg(camTransforms,imgWidth,imgHeight,1.0f) ; CSilhouetteTexturesSource* sts = new CCudaSilhouetteSource(imgWidth, imgHeight,imgCount) ; sts->setImagePtrs(imgptr) ; sts->setBackGrounds(bgptr) ; CSilhouetteSouce* sb = new CCudaSilhouetteBlur(sts) ; CVolumeSource* vs = new CCudaVolSource(sb,ctg,7,7,7) ; CCudaMarchingCube* cmc = new CCudaMarchingCube(vs) ; CTexturedBufferDrawer* bd = new CBufferDrawer(cmc,sts,ctg, SHADER_DIR) ; CRfvrVtkMapper* mapper = new CRfvrVtkMapper(bd) ; vtkActok actor = vtkActor::New(); actor->SetMapper(mapper) ;

43

6. fejezet Tesztelés, eredmények 6.1.

Tesztelés

A rekonstrukciós futószalag moduláris felépítéséb˝ol köszönhet˝oen, az egyes fázisok önállóan is futtathatóak, tesztelhet˝oek. Ezt el˝osegítette az offline verzió által lementett mérési adatok, mint például kameraképek, kalibrációs adatok, sziluett képek és térfogat modellek. Az egyes fázisok teszteléséhez önálló segédprogramok készültek. Mivel a teljes futószalag futtatása jelent˝os id˝ot és teljesítményt emészt fel, ezért a hibakeresést el˝osegítend˝o az egyes fázisok feladatát szimuláló megvalósítások is készültek. Ezek az offline módszer által lementett adatokat töltötték be, és szolgáltatták eredményként. A teljes futószalag tesztelésének biztosítása érdekében egy a vezérl˝oszoftver által teremtett feltételeket szimuláló tesztprogram készült. Megadva a háttérképek, felvételképek, és kamera kalibrációs adatok elérési útját az algoritmus betölti azokat a memóriába, majd a vezérl˝oszoftverhez hasonló módon használja a valósidej˝u rekonstrukciós komponens szolgáltatásait. Indításkor lehet˝oség nyílik a használni kívánt kamerák kiválasztására, a szimuláció során pedig küszöbértékek állítására.

6.2.

Eredmények, további tervek

A munka eredményeképp sikerült egy a rekonstrukciót elvégz˝o munkafolyamatot grafikus processzoron megvalósítani, ezzel lehet˝ové téve annak valósidej˝u végrehajtását. A puszta geometriai rekonstrukción túl, opcionális lehet˝oség annak eredményének textúrákkal való ellátása. Az offline m˝uködéshez képest, a textúrázáshoz teljesen eltér˝o módszerek kerültek kidolgozásra a valósidej˝u végrehajtás által támasztott sz˝uk id˝ohatárok betartása végett. A 6.1. táblázatban néhány mérési eredmény található a rekonstrukciós eljárás sebességér˝ol (A táblázatban használ rövidítések: Seg. - szegmentálás, Blur. - simítás, VH - Vizuális Burok, MC - Marching Cubes, SM - árnyéktérképek számítása, Tex. - textúrázás). Az

44

6.1. táblázat. Futási id˝ok fázisonként ezredmásodpercben Felbontás Seg. Blur. VH MC SM Tex. Összesen 320 × 244 5.1 5.7 1.5 1.6 1.5 1.5 16.9 480 × 364 11.9 12.8 1.6 1.5 1.5 1.5 30.7 640 × 484 20.5 22.5 1.6 1.5 1.5 1.5 49.0 1624 × 1236 129.1 147.8 1.6 1.5 1.5 1.5 282.9

értékek ezredmásodpercben értend˝ok. A mérések különböz˝o felbontású bemeneti képekkel készültek, a rekonstruált térfogatmodell minden esetben 128 × 128 × 128-as volt. Jól látható, hogy a munkamenetben a legtöbb id˝ot a szegmentálás és a simítás igényli. Ezek a fázisok kevés számítási m˝uveletet végeznek, de intenzíven használják a memóriát. Megjegyezzük, hogy a szegmentálás tartalmazza a képek videokártyába való feltöltését is. A feldolgozás sz˝uk keresztmetszete tehát a nagy mennyiség˝u adat mozgatása a PCI-Express buszon keresztül, és a memóriam˝uveletek. A stúdióban alkalmazott kamerák másodpercenként 25 képkockát küldenek, tehát 40ms-enként egyet. A rekonstrukció idejét is ez alá az érték alá kellett szorítani a valósidej˝u megjelenítés érdekében. Ezt a célt a két kisebb felbontás alkalmazása esetén sikerült is elérni. Magasabb felbontású bemen˝o adatok alkalmazása esetén a min˝oség már számottev˝oen nem javul, illetve a nagy mennyiség˝u adat hálózaton való átküldése is hardveres korlátokba ütközik. Terveink szerint a közeljöv˝oben a stúdió összeköttetésre kerül a VirCA 1 rendszerrel, hogy a valósidej˝u rekonstrukció eredményét, egy bejárható 3D-s környezetben megjeleníthet˝ové tegyük. További lehet˝oségként fennáll a végrehajtási pipeline rugalmasságából adódóan az egyes feladatok más módszerekkel való megoldása a teljesítmény, vagy a min˝oség további javítása céljából. Nem került még kihasználásra a stúdió fejlett, programozható világítása sem. Megfelel˝o alkalmazásával növelhetjük a rekonstrukció min˝oségét, esetleg finomabb részletek el˝oállítása is lehetségessé válhat.

1 http://www.virca.hu/

45

7. fejezet Köszönetnyilvánítás El˝oször is szeretnék köszönetet mondani Csetverikov Dmitrij tanár úrnak, a dolgozat elkészítése során végzet témavezet˝oi munkájáért, és hogy lehet˝oséget adott a projektben való részvételre. Továbbá Jankó Zsoltnak, aki munkám során felmerül˝o problémák, kérdések megoldásában mindig azonnal segített. Továbbá köszönettel tartozom az MTA SZTAKI Geometriai Modellezés és Számítógépes Látás Kutatólabor tagjainak, akik szakmai tapasztalatukkal, tanácsaikkal hozzájárultak a dolgozat elkészültéhez.

46

Ábrák jegyzéke 1.1. A felvétel és a rekonstruált eredmény . . . . . . . . . . . . . . . . . . . .

5

2.1. 2.2. 2.3. 2.4.

6 7 7 9

A stúdió panorámaképe belülr˝ol . . . . . . . . . . . . . . . . . . A stúdió látványterve . . . . . . . . . . . . . . . . . . . . . . . . A stúdióban található egyik kamera, és a hozzá tartozó fényforrás . A stúdió vezérl˝oszoftvere . . . . . . . . . . . . . . . . . . . . . .

. . . .

. . . .

. . . .

. . . .

3.1. A GPU-k és CPU-k teljesírményének növekedése az évek során (forrás CUDA C Programming Guide) . . . . . . . . . . . . . . . . . . . . . . . 3.2. A rekonstrúkció végrehajtására alkalmazott GF110 GPU bels˝o felépítése . 3.3. A részegységekre felhasznált tranzisztorok mennyisége különböz˝o architektúrák esetén. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.4. A CUDA szálhierarchiája (forrás CUDA C Programming Guide) . . . . . 3.5. A CUDA memóriahierarchiája (forrás CUDA C Programming Guide) . . 3.6. INRIA stúdió és az alkalmazott géppark . . . . . . . . . . . . . . . . . . 3.7. Institute of Computer Science stúdiója, Görögország . . . . . . . . . . . 3.8. Dél-Kaliforniai egyetem stúdiója . . . . . . . . . . . . . . . . . . . . . .

14 16 17 19 20 21

4.1. A GPU munkamenet (a szaggatott vonallal jelölt fázisok opcionálisak) . . 4.2. A feldolgozásra beérkez˝o képek . . . . . . . . . . . . . . . . . . . . . . 4.3. A szegmentálás eredménye . . . . . . . . . . . . . . . . . . . . . . . . . 4.4. A Vizuális Burok algoritmus . . . . . . . . . . . . . . . . . . . . . . . . 4.5. Az elmosott sziluettképek . . . . . . . . . . . . . . . . . . . . . . . . . . 4.6. Simitás alkalmazásának hatása az eredményre. (bal oldalt nincs alkalmazva) 4.7. A Marching Cubes algoritmus különböz˝o esetei . . . . . . . . . . . . . . 4.8. A voxelek, és a csúcspontok indexei . . . . . . . . . . . . . . . . . . . . 4.9. A generált háromszögháló VTK-ban . . . . . . . . . . . . . . . . . . . . 4.10. Az els˝o textúrázási módszer eredménye . . . . . . . . . . . . . . . . . . 4.11. Az második textúrázási módszer eredménye . . . . . . . . . . . . . . . . 4.12. A textúrázási módszerek összevonása . . . . . . . . . . . . . . . . . . . 4.13. A textúrázott eredmény VTK-ban . . . . . . . . . . . . . . . . . . . . . 4.14. Árnyékszámítás a generált modellb˝ol . . . . . . . . . . . . . . . . . . . .

23 24 25 26 27 28 29 30 32 33 34 34 35 35

47

12 13

Dolgozat témakörében megjelent publikációk J. Hapák, Z. Jankó, D. Chetverikov: "GPU-Based Real-Time Spatio-Temporal Reconstruction Studio", Proc. 28th Spring Conference on Computer Graphics, ACM, Smolenice, Slovakia, pp. 164-169, 2012. J. Hapák, Z. Jankó, D. Chetverikov: "Real-Time 4D Reconstruction of Human Motion", Proc. 7th International Conference on Articulated Motion and Deformable Objects (AMDO 2012), Mallorca, Spain, to appear in Lecture Notes in Computer Science, Springer, 2012. Z. Jankó, D. Chetverikov, J. Hapák: "4D Reconstruction Studio: Creating dynamic 3D models of moving actors", Proc. Sixth Hungarian Conference on Computer Graphics and Geometry, Budapest, pp.1-7, 2012. ISBN 978-963-313-048-3.

48

Irodalomjegyzék [1] Bryce E. Bayer: Color imaging array, US Patent, 1976-07-20, Patent Number: US3971065. [2] K. Tzevanidis, X. Zabulis, T. Sarmis, P. Koutlemanis, N. Kyriazis, A.A. Argyros: From multiple views to textured 3D meshes: a GPU-powered approach. Computer Vision on GPUs Workshop 2010. Sep. 10., [3] JANKO, Z., AND PONS, J.-P. 2009. Spatio-temporal image-based texture atlases for dynamic 3-D models. In Proc. ICCV Workshop 3DIM’09, 1646-1653. [4] KUTULAKOS, K., AND SEITZ, S. 1999. A theory of shape by space carving. In Proc. International Conference on Computer Vision, vol. 1, 307-314. [5] LAURENTINI, A. 1994. The Visual Hull concept for silhouettebased image understanding. IEEE Trans. Pattern Analysis and Machine Intelligence 16, 150-162. [6] LORENSEN, W., AND CLINE, H. 1987. Marching Cubes: A high resolution 3D surface construction algorithm. In Proc. ACM SIGGRAPH, vol. 21, 163-169. [7] SZTAKI GMCV, 2011. The 4D Reconstruction Studio, 2012.5.12 http://vision.sztaki.hu/4Dstudio/index.php. [8] LANCE WILLIAMS: Casting curved shadows on curved surfaces Computer Graphics Lab New York Institute of Technology Old Westbury, New York 11568 [9] nVidia CUDA SDK Marching Cubes Isosurfaces, 2012.5.12 http://developer.nvidia.com/cuda-cc-sdk-code-samples\ #marchingCubes [10] Fodor Bálint: Háromdimenziós stúdió vezérl˝oszoftverének elkészítése, diplomamunka, Budapesti M˝uszaki és Gazdaságtudományi Egyetem Villamosmérnöki és Informatikai Kar 2011 [11] nVidia CUDA C Programming Guide, 2012.5.12 http://developer. download.nvidia.com/compute/DevZone/docs/html/C/doc/ CUDA_C_Programming_Guide.pdf 49