Diplomaterv MPEG-4 paraméterekkel vezérelhető fejanimációs rendszer továbbfejlesztése Oroszi Balázs Témavezető: Takács György Pázmány Péter Katolikus Egyetem Információs Technológiai Kar 2008.
2
3 Nyilatkozat Alulírott Oroszi Balázs, a Pázmány Péter Katolikus Egyetem Információs Technológiai Karának hallgatója kijelentem, hogy ezt a diplomatervet meg nem engedett segítség nélkül, saját magam készítettem, és a diplomamunkában csak a megadott forrásokat használtam fel. Minden olyan részt, melyet szó szerint, vagy azonos értelemben, de átfogalmazva más forrásból átvettem, egyértelműen a forrás megadásával megjelöltem. Ezt a Diplomamunkát más szakon még nem nyújtottam be................ Oroszi Balázs
4 Tartalomjegyzék Összefoglaló...6 Summary...7 1. Bevezetés...8 2. A korábbi rendszer...8 3. Röviden a fej-animációs megoldásokról...9 3.1. Arcmozgás követés...9 3.2. Virtuális beszélő fej megjelenítés...10 4. Röviden az MPEG-4 pontokról...11 4.1. Pár gondolat a fogakról...13 5. Videó folyamból MPEG-4 paraméterek származtatása...13 5.1. A régi módszer problémái...13 5.2. Új felvételek készítése...15 5.3. Az Avisynth videófeldolgozási rendszer...16 5.4. Az ajakkövetéses származtatás lépései...17 5.4.1. Színkiemelés...18 5.4.2. Az ajkak pozíciójának behatárolása...20 5.4.3. Illesztés...21 5.4.4. A detektált pontok korrekciója...23 5.5. Hagyományos pontkövetés...23 5.6. A detekció eredményének megjelenítése...24 5.7. Képkockasebesség...25 5.8. Nagy teljesítményű kamera...25 5.8.1. Debayer...26 5.9. Implementáció...28 6. A detektált pontsorozat általánosítása MPEG-4 szerint...29 6.1. FAP sorozat előállítása (kódolás)...32 6.2. FAP sorozat alkalmazása (dekódolás)...33 6.3. FAPU alapú FDP sorozat...33 6.4. Implementáció...34 7. Három dimenziós megjelenítés...35 7.1. Létező megoldások...35 7.2. Saját megvalósítás egyedi 3D motor...36 7.2.1. A motor tulajdonságai, képességei...37
5 7.2.2. Szoftveres rajzoló alrendszer (SoftwareRenderDevice)...38 7.2.3. OpenGL rajzoló alrendszer (OpenGLRenderDevice)...39 7.2.4. Hierarchikus modell-struktúra (Scene Graph)...40 7.2.5. Általános 3D animáció...41 8. Három dimenziós fejanimáció...41 8.1. A fejanimáció lépései...42 8.2. 3D modell animálása FAP-okkal...44 8.3. Az elkészült fej-animációs rendszer...45 9. Kapcsolat az IPTV siketek számára projekttel...45 9.1. A DirectShow keretrendszer...46 9.2. Szűrő-gráfok készítése ill. tesztelése...48 9.3. A projekt megvalósítása...48 10. Összefoglalás, következtetés, végső gondolatok...50 11. Köszönetnyilvánítás...50 Irodalom...51 Függelék...52
6 Összefoglaló A diplomaterv virtuális, három dimenziós beszélő fejek létrehozásával és animációjával kapcsolatos munkámat foglalja össze. A feladat az egyetemen már folyamatban lévő Siketek beszédkommunikációját mobiltelefonnal segítő eszközök fejlesztése projekt keretében indult, a fejlesztés során azonban hamar a PC-s környezetben történő fej-animációra helyeződött a hangsúly, így az általam fejlesztett rendszer is ennek fényében valósult meg. Ismertetem az egyetemen korábban szintén fej-animációval foglalkozó hallgatók, korábbi projektek eredményeit, megfigyeléseit, jellegzetességeit. Röviden ismertetem az MPEG-4 szabványt, melynek alapján ezek a rendszerek készültek. A létező rendszerek kiértékelése után ismertetem az okokat, melyek az új rendszerben történt tervezési és fejlesztési döntéseimet befolyásolták. Az általam megvalósított rendszer és a kapcsolódó programok egy komplett eszközkészletet nyújtanak virtuális beszélő fejek létrehozására, a kamerával felvett beszélő személy arcának követésétől a virtuális három dimenziós fejek animációjáig, valamint speciális környezetekben történő megjelenítésükig, gondolok itt animált virtuális fejek élő televíziós adás képére való beültetésére. Ismertetem a megvalósított rendszer ill. eszközkészlet működését, használatát, fázisokra bontva. Az első fázis videófelvételek feldolgozása, nevezetesen beszélő személyek arcmozgásainak követése. A második fázis a kinyert adatok általánosítása az MPEG-4 szabványnak megfelelően. A harmadik fázis az általánosított paraméterek által egy három dimenziós fej animációja, valamint megjelenítése. A megjelenítésre egy speciális 3D motort fejlesztettem, mely képes 3D hardveres gyorsítás nélkül is működni, pusztán szoftveres módban, de támogatja az OpenGL alapú rajzolást is. Ennek a megjelenítőnek nagy hasznát vettük több kapcsolódó projektben is. Ismertetem a videófeldolgozás során alkalmazott módszereket, valamint a megjelenítéshez készített 3D motor jellegzetességeit. Végül kitérek az IPTV siketek számára projektben végzett munkámra, melyben látható, hogy a korai tervezési meggondolásoknak köszönhetően, az elkészült fej-animációs rendszert egy az egyben sikerült felhasználni ebben a projektben, valamint megmutatom, hogyan lehetséges egy három dimenziós virtuális beszélő fejet élő televíziós adás képére ültetni.
7 Summary This paper summarizes my work regarding the creation and animation of three dimensional virtual talking heads and facial animation. The assignment started under the ongoing Developing mobile phone equipments as a communication aid for deaf persons project, but during the development, emphasis quickly shifted to the animation of talking heads in a PC environment, so the system I developed came to realization in this regard. I am going to review the results of our university's students who were also working on facial animation systems, as well as the results of earlier projects. At the same time I'm going to introduce the MPEG-4 facial animation standard, whereby these systems were developed. After evaluating these systems, I'll show the reasons that directed my design and development decisions of the new system. The system I developed and the accompanying programs offer a complete toolchain for creating virtual talking heads, from the processing of video camera footage of speaking persons to the animation of virtual three dimensional talking heads, as well as displaying them in special environments, namely displaying a talking head on top of live television broadcast. I will describe the workings and usage of the finalized system and toolchain, broken down to phases. At first I'll focus on the processing of video camera footage, namely the tracking of visual features on a speaking person's face. Second, I'll describe the generalization of the acquired parameters according to the MPEG-4 standard. And third, I'll show the process of facial animation using these generalized parameters, along with the actual display of the animated three dimensional talking head. I developed a special 3D engine for this purpose, that is capable of working without hardware 3D acceleration using pure software rendering but can also use OpenGL if available. This engine was put to great use in many related projects at my university. I'll show the methods I used for processing the video recordings, as well as the features of the 3D engine used for the talking head display Finally, I'll touch on my involvement in the IPVT for deaf persons project, which shows the benefits of the early design choices I made for the new facial animation system, as we could use the system in one piece without any modification in that project. I'll also show how was it possible to integrate an animated talking head into live television broadcast.
1. 8 Bevezetés A virtuális fej- és testanimáció az utóbbi évtizedekben folyamatos fejlődésen ment keresztül. A mai számítógépes játékok, virtuális személyek ma már elképzelhetetlenek valósághű fej- és arcanimáció nélkül. Ezek a megvalósítások elsősorban szórakoztatás céljából jöttek létre. Az egyetem korábbi célkitűzése, a szórakoztatást háttérbe szorítva, egy olyan szabványos rendszer kidolgozása volt, mely alkalmas a hallássérültek beszédkommunikációjának fejlesztésére. Ezt egy olyan beszélőfej működtetésével kívánták megoldani, mely képes a beszéd-animáció konverzióra, vagyis közvetlenül a beszédjelből szájállások előállítására úgy, hogy arról a siket illetve nagyothalló emberek a szájmozgást le tudják olvasni. Ennek megvalósítása már elkezdődött, a korábbi években készült fej-animációs rendszer keretében. Az elmúlt időszakban az én feladatom elsősorban a következő volt: a korábbi egyetemi fejanimációs rendszer tanulmányozása, javaslattétel a továbbfejlesztésére, új tulajdonságok és képességek implementációja valamint integrációja a meglévő rendszerbe. Amennyiben ez nem lehetséges, úgy új rendszer kidolgozása. A továbbfejlesztés egy videófeldolgozási módszer, egy háromdimenziós megjelenítő valamint egy animációs modul kidolgozását jelenti. Ez magában foglalja az esetleges olyan más utakon való elindulást is, melyeket a korábbi rendszer fejlesztése során még nem vizsgáltak. Az általam elkészített rendszer sok-sok kisebb-nagyobb programból, könyvtárból, modulból áll. Ezek összessége alkotja az eszközkészletet, melynek segítségével lehetséges egy virtuális beszélő fej létrehozásához szükséges lépések elvégzése. Mivel az egyetemen elindult korábbi projektek ill. születendő cikkek számára volt szükség elsősorban erre az új rendszerre, így természetes módon kapcsolódik más egyetemi fejlesztésekhez. Ezeket ebben a dokumentumban nem részletezem, csupán megemlítem őket, ily módon részletes leírásokat kizárólag az általam fejlesztett és implementált funkcionalitáshoz írok. 2. A korábbi rendszer A korábbi fej-animációs rendszert az egyetemen Srancsik Bálint dolgozta ki [1]. Egészen pontosan egy komplett, MPEG-4 paraméterekkel vezérelhető fej-animációs rendszer előállítását tűzte ki célul, melynek elsődleges célja egy korábbi beszámoló [2] alapján röviden: konkrét célkitűzésünk, hogy a mobiltelefon által vett hangot a hallássérültek
9 számára is érthetővé tegyük. A beszámoló szerint végzett felmérés alapján erre lenne igény. Ezt a feladatot a hang megjelenítésével lehet elérni oly módon, hogy egy kirajzolt fej segítségével visszaadjuk a beszélő szájmozgását, melyről a siket egyén képes leolvasni és megérteni a mondott szöveget. Az emberi beszédjel önmagában hordoz olyan információkat, melyek kinyerésével lehetséges egy háromdimenziós fejmodell olyan szintű animálása, hogy arról egy siket leolvashassa a mondott szöveget. Ennek megvalósítása többlépcsős, több szakterületen átívelő folyamat, a hangfeldolgozástól kezdve a videó felvételen és feldolgozáson át a háromdimenziós grafikai programozásig és modellezésig. Az én feladatom szempontjából a rendszer alapvetően két nagy részre bontható: videófeldolgozás és 3D fejmodell animáció. A korábbi munka mindkét részre kínál megoldást. Ezen komponensek tüzetes átvizsgálása és megértése után arra a következtetésre jutottam, hogy közvetlen továbbfejlesztés nem lehetséges. Ezt úgy értem, hogy az implementált rendszer kódja nem újrafelhasználható, bármilyen nemű kiegészítés sokkal több időt és átalakítást igényelne, mint a tapasztalatokat felhasználva egy teljesen új rendszer írása alapról. Ezen okból kifolyólag a régi rendszer forráskódját nem használtam fel, az új rendszer teljesen újratervezett, alapról írt forráskódból áll. A későbbiekben a megfelelő fejezetekben konkrétan megjelölöm a korábbi rendszernél alkalmazott módszerek problémáit, és az ezekre alkalmazott megoldásaimat. 3. Röviden a fej-animációs megoldásokról Két nagy területet érint a fej-animációval kapcsolatos fejlesztés: az arcmozgás követését valamint a virtuális beszélő fej megjelenítését 3.1. Arcmozgás követés Realisztikus virtuális fej-animáció létrehozásához elengedhetetlen az ún. facial motion capture/tracking, magyarul az arcmozgás-követés. Ez az a folyamat, amikor egy beszélő személy arcának mozgásait digitális adatbázisba gyűjtjük, hogy a felépített adatbázis segítségével három dimenziós virtuális fejeket animáljunk. Alapvetően kétféle módszer létezik: Marker alapú (Kép 1) Marker nélküli
10 A marker alapú technológiák közös tulajdonsága, hogy mind nagyszámú (10-100) markert helyeznek a beszélő személy arcára, majd ezek mozgását követik nagy felbontású kamerákkal. Attól függően, hogy egy vagy több kamerát használnak beszélünk kettő ill. három dimenziós arcmozgás-követésről. Kép 1: Marker alapú arcmozgás követés A marker nélküli technológiák az arc meglévő tulajdonságait használják, mint pl. a szemek, száj sarkai, orrlyukak, stb., majd ezeket követik. Irodalma és metódusai szerteágazóak [3] [4]. Egy érdekes megközelítés az ajkak marker nélküli közvetlen követése és modellezése görbék által, melyet több más projekt is használ [5] [6]. 3.2. Virtuális beszélő fej megjelenítés Egy korábbi beszámoló [1] röviden összefoglalja a virtuális beszélő fejek fajtáit megjelenítés szempontjából: Előre tárolt arckép részek (szemek, száj, szemöldök, stb.) alapján működő. Fényképek morpholásán alapú. 3D geometriai arcmodellezésen alapuló. A mi megoldásunk alapvetően marker alapú és közvetlen ajak-követést valamint geometriai arcmodellezésen alapuló megjelenítést használó rendszer. Az arcon definiált jellemző pontok segítségével pontosan modellezni lehet az arc finom mozgásait. A pontok elhelyezése az MPEG-4 szabvány alapján történik, melyet röviden alább foglalok össze.
4. 11 Röviden az MPEG-4 pontokról Az MPEG (Moving Picture Experts Group) szabványok fő célja a hang és videó jelek tömörítése. A tömörítés alapvető követelményei a hatékonyság és élethűség. Az MPEG-4 szabványt nem csak nagy videófolyamok tömörítésére alakították ki, hanem figyelembe vettek olyan multimédiás alkalmazásokat is, mint 3D-s jelenetek, animációk, szintetizált hangok, képek, szövegek, grafikák külön vagy akár együttes kezelése és élethű megjelenítése. Az MPEG-4 szabvány [7] egyik legösszetettebb része a fej és az emberi test megjelenítése és mozgatása (FBA - Face and Body Animation). Az FBA-ra vonatkozó szabványrész leírja az arc és a test alakjának és mozgásának kódolási alapelveit. Az FBA egyik legfontosabb tulajdonsága tehát, hogy nem adja meg pontosan a kódolási és a dekódolási eljárást, csak a küldött adat formáját és értelmezését. Az MPEG-4 szabvány az arc modelljét az arc normál állapotával írja le, megad több tartópontot (Feature Point - FP) és az arc mozgását leíró paramétereket (Facial Animation Parameter - FAP), mely lényegében a normál archoz képesti elmozdulást jellemzi. Az elmozdulások méretét és arányát a szabvány szerint mindig az emberi arcra jellemző alapvető méretek alapján fejezi ki. A szakirodalomban ennek elterjedt rövidítése FAPU (Face Animation Parameter Unit). A FAPU-kat az arc olyan jellegzetes távolságaiból kell számolni, mint például a szemgolyók távolsága vagy a száj szélessége. A szabványban 84 tartóponttal írják le az arcot. Kép 2: MPEG-4 pontok (1)
12 Kép 3: MPEG-4 pontok (2) A tartópontok fő feladata, hogy referenciaként szolgáljanak a FAP-ok számára. A FAP-ok által leírt összetett mozgások mindig a normál tartópontok által leírt fejre vonatkoznak. A normál fej csukott szájat és semleges arckifejezést jelent. Vannak olyan FP-k is, melyekre egy FAP sincs közvetlen hatással (pl.: az orr szélei). Ezeket mindössze az arc alakjának meghatározására használják. A detekciós és animációs feladat szempontjából számunkra a teljes MPEG-4 pontkészlet csupán egy része szükséges. Az elkészített rendszer által detektált és az általunk felhasznált pontok az alábbi ábrán láthatók: Kép 4 Kép 4: Általunk használt MPEG-4 pontok
13 A feladat szempontjából legfontosabb területet elemezzük, az ajkak mozgását. Az elemzési feladat sok részből és több lépésből áll. Rendszerünkben a fejmodell a fenti MPEG-4 szabványban leírt paraméterekkel van vezérelve. 4.1. Pár gondolat a fogakról A korábbi rendszer tanulmányában [1] felmerült, hogy a fogak detektálása hozzájárulhat a tanulmányban ismertetett felismerési folyamat pontosságához. A fogak detekciójára azonban nincs szükség, mivel ezek pozícióját két másik MPEG-4 pont impliciten tartalmazza. Ez a két pont az orr ill. az állcsúcs pontjai. Az implicit tartalmazás pontosan azért áll fenn, mivel a felső fogsor és az orr képtelen külön mozogni, hiszen mindkettő ugyanahhoz a csonthoz, nevezetesen a koponyához van rögzítve. Ugyanez a helyzet az alsó fogsorral és az állcsúccsal is, mindkettő az alsó állkapocshoz tartozik. Az egyik mozgása magában hordozza a másik mozgását is. Tehát ha az állcsúcs lefelé mozdul, tudjuk, hogy az alsó fogsor is pontosan ugyanannyival fog lefelé mozdulni. Ez a felismerés a végleges 3D megjelenítő elkészülte után jött, akkor vettem észre ugyanis, hogy az alsó fogsorra kapcsolva az állcsúcs pontjának mozgását, tökéletes és élethű szájmozgás alakult ki. 5. Videó folyamból MPEG-4 paraméterek származtatása A feladat: egy videokamerával felvett beszélő személy arcáról a fejmodell animálásához szükséges jellemző paraméterek detektálása további feldolgozás számára. 5.1. A régi módszer problémái A régi felvételek feldolgozása a korábbi rendszerben a MatLab 7 környezet segítségével történt, az Image Processing Toolbox felhasználásával. A feldolgozó program fejlesztőjével (Srancsik Bálinttal) folytatott beszélgetések során, valamint a MatLab kép- és videókezelési eljárásainak kiértékelése után arra a következtetésre jutottam, hogy videófájlok és videófolyamok kezelése MatLab környezetben nem teljesen kiforrott, és meglehetősen nehézkes. Ezen felül túlságosan lassú is, ami megnehezíti új ötletek, képfeldolgozási algoritmusok gyors kipróbálását. Ezen túlmenően a módszerrel is adódtak problémák. A korábbi módszer az MPEG-4 pontok arcra történő felfestésével történt. A felvétel során
14 az MPEG-4 pontok az arcbőrtől elütő sárgás festékkel lettek elhelyezve [8] (Kép 5). A pontokat közvetlenül az RGB színkomponensekre adott határfeltétel alapján nyerték ki. Kép 5: Felfestett MPEG-4 pontok Az MPEG-4 pontok egy részének ilyen módszerrel történő kinyerésével nincs probléma, nevezetesen azokkal, melyek nem végeznek gyors mozgást. A problémák a száj körüli pontoknál jelentkeznek. A 8-as csoportba tartozó MPEG-4 pontok (az ajkak külső kontúrvonalán elhelyezkedő pontok) gyorsan mozognak, hiszen a beszéd miatt ezek a leginkább érintettek. A gyors mozgás és a felvétel korlátai miatt a videofelvételen elmosódhatnak a pontok. Ebben az esetben nehéz követni az adott pontot, és keveredhet a sorrend is (Kép 6). További probléma, hogy csücsörítés közben bizonyos pontok ki is takaródhatnak (Kép 7).
Kép 6: Probléma: elmosódott pontok 15 Kép 7: Probléma: kitakaródott pontok Jelentős hátrány továbbá, hogy a felfestéses módszerrel a 2-es csoportba tartozó MPEG-4 pontok egyáltalán nem követhetőek, hiszen ezeket az ajkak belső kontúrvonalára kellene felfesteni. Kiderült ugyanis, hogy pl. az ó és ú (valamint egyéb, csücsörítést igénylő) beszédhangok esetében nem elég a 8-as csoportba tartozó (az ajkak külső vonalán lévő) MPEG-4 pontokat követni, hiszen ezek nem tartalmazzák azt az információt, ami a csücsörítéshez kell. Ez a jelenlegi fejmodell animálásánál jól látható. Feltétlenül szükséges a 2-es csoportba tartozó (az ajkak belső vonalán lévő) MPEG-4 pontokat is követni. Ezen problémák miatt döntöttem egy teljesen új keretrendszer valamint teljesen új módszerek kipróbálása mellett. 5.2. Új felvételek készítése A korábbi években készült egy audiovizuális adatbázis, melyben jeltolmácsok olvastak fel előre elkészített mondatokból álló szöveget, kamera előtt. Ezek a felvételek a korábbi elemzési módszer működésének megfelelően készültek. A legelső félévben egy olyan módszert dolgoztam ki, mely (a hagyományos sárga festékes pontkövetés mellett) az ajkak kontúrvonalának követésén alapszik. Így nem szükséges az ajkakon pontokat felfesteni, ellenben a szükséges az ajkak kifestése. Az MPEG-4 pontokat a kiemelt kontúrvonal alapján állítom elő. A tesztelések alapján arra a következtetésre jutottam, hogy ez a módszer valóban működhet. Az eljárás részletes működését a későbbiekben ismertetem. Mivel a régi felvételek csak pontokat alkalmaztak, így új felvételek készítésére volt szükség. A következő félévben összesen 7 új felvétel készült, ebből 5 jeltolmácsokkal.
16 Mindegyik felvételen egy beszélő látható. A felvétel digitális kamerával készült, állított helyzetben 576 * 720-as felbontásban, 25 fps (képkocka/másodperc) képkockasebességgel. A kép a beszélő arcára van közelítve (Kép 8). A felvétel elkészítése előtt az ajkakat kipirosítottuk, valamint sárga festékkel 2 MPEG-4 pontot is felfestettünk (9.3, 2.1). Kép 8: Az új felvétel Mindegyik beszélő ugyanazt a szöveget olvasta fel egy, a kamera mögött elhelyezett képernyőről. A szöveg eleje számokat, valamint nap- és hónapneveket tartalmazott. Ez után következtek az Egri csillagok c. műből, meghatározott kritériumok alapján kiválasztott mondatok. A szöveg összeállítását Feldhoffer Gergely végezte. Egy felvétel hossza 20-30 perc között van. 5.3. Az Avisynth videófeldolgozási rendszer Korábbi tapasztalataim alapján javasoltam az Avisynth (http://www.avisynth.org) videófeldolgozási keretrendszer kipróbálását. Ez egy speciálisan videófeldolgozásra kifejlesztett programozási nyelv, beépített és bővíthető szűrőkkel, valamint a hozzá tartozó szűrő alkalmazás programozói felülettel (API). Az Avisynth rendszer lényege, hogy a saját szkriptnyelvén írt fájlban határozzuk meg a teljes videófeldolgozási folyamatot. Lehetőségünk van egyszerre több videófájl betöltésére is, melyeket klipeknek hívunk, és meghatározhatjuk, hogy mely klipeken mely szűrőket kívánjuk futtatni. Ez a fajta rugalmasság lehetővé teszi, hogy elválasszuk az alacsony (pixel)
17 szintű feldolgozást a magas (szűrő) szintű feldolgozástól. A szkriptfájl elkészülte, és természetesen az Avisynth telepítése után egyszerűen megnyitjuk a szkriptet bármely VFW (Video for Windows) alapú médialejátszóval, és ott a szűrőkön átfolyó videófolyamot fogjuk látni. Íme egy példa szkript, mely megnyit egy videófájlt (video.avi), majd átméretezi azt: c = AviSource( C:\video.avi ) c = c.pointresize(640, 480) return c A szűrő alkalmazásfejlesztési felület (API) segítségével lehetőségünk nyílik kiegészítő modulokat, DLL-eket készíteni, melyekben saját szűrőket definiálhatunk. Miután az elkészült DLL-t bemásoltuk az Avisynth megfelelő könyvtárába (plugins) a fent használt függvényekhez hasonlóan a saját szűrőinket is használhatjuk. A rendszer kifejezetten a gyors képfeldolgozási feladatok elvégzésére van optimalizálva, a videó-adatfolyamon közvetlenül dolgoznak a szűrők, nincs külön konverzió (mint a MatLab esetében). Az MPEG-4 paramétereket kinyerő eljárások is szűrőkként lettek megvalósítva. Mivel az Avisynth jelenleg kizárólag a Microsoft C++ fordítóját támogatja, valamint a szűrő fejlesztési interfész is C++ alapú, így más C++ fordítóprogrammal nem lehetséges szűrő készítése úgy, hogy az alapértelmezett Avisynth C++ szűrő fejlesztési interfészt használjuk. Ennek oka a különböző fordítóprogramok által használt eltérő C++ névferdítési eljárás (name mangling). Szerencsére készült egy C nyelvű interfész is, ami az eredeti C++ interfészt csomagolja be. Ezen keresztül lehetőség nyílik bármely C/C++ fordítóprogram segítségével szűrőt készíteni, amennyiben ezt az interfészt használjuk. Mivel a C nyelv nem alkalmaz névferdítést, így a különböző fordítóprogramokkal készített C nyelvű modulok probléma nélkül vegyíthetők. Én az ingyenes GNU Compiler Collection (GCC) C/C++ fordítóprogramjának felhasználásával készítettem a szűrőket. 5.4. Az ajakkövetéses származtatás lépései Az új módszer az ajkak kontúrvonalának követésén alapszik. Alapvető fontosságúnak tartottam, hogy az elkészült rendszer minél modulárisabb legyen. Ez alatt azt értem, hogy egyetlen monolitikus program helyett, mely a beadott videófelvételből rögtön kidobja az MPEG-4 pontokat, több kisebb, szabadon variálható és legfőképpen cserélhető modult készítettem.
18 A detekció lépései: Színkiemelés Színkiemelt képen az ajkak pozíciójának behatárolása Az ajkak vonalára MPEG-4 pontok illesztése A detektált pontok korrekciója 5.4.1. Színkiemelés Az ajkak kiemelése szín alapján történik. A színdetekció folyamata: definiálunk az adott színtérben egy színt és egy metrikát, majd a felvétel minden képpontjára kiszámoljuk a távolságot a definiált színtől, és ez alapján előállítunk egy szürkeskálás képet, mely a távolságinformációt tartalmazza pixelenként. Ennek segítségével behatárolható az ajkak pozíciója a képen. A színkiemelést 3 színtérben is kipróbáltam, melyek az RGB, Y'CbCr (más néven YUV) és HSL színterek. A következőkben összefoglalom ezek jellemzőit, valamint jelentőségüket a detekciós eljárás szempontjából. Az RGB színtér Az RGB egy additív színkeverési mód, melyben a piros, zöld és kék színek összeadásával állítjuk elő a színeket. Tökéletesen alkalmas a videó-elektronikában jelátvitelre, monitoroknál megjelenítésre, azonban nem jellemzi, hogy valójában mi az a szín, amit ez a 3 szám leír. Ennek következtében nehézkes ebben a színtérben megmondani, hogy mi két szín távolsága egymástól. A detekció szempontjából nem túl előnyös, mivel a digitális videó nem ebben a színtérben kódolt, így konverzió szükséges. Az Y'CbCr színtér Az Y'CbCr színtér (melyet egyesek által hibásan YUV színtérnek is hívnak) a digitális videó natív színtere. Ez azt jelenti, hogy a digitális kamera által tömörített videó (DV) ebben a színtérben van. A színt egy luma (fényerősség) komponens (Y) és két chroma (szín) komponens (U,V) írja le. Valamivel pontosabban határozza meg, hogy mi egy adott szín. A detekció szempontjából előnyös, mivel nem szükséges konvertálni, és a tapasztalataim alapján kellőképpen elfogadható eredményt ad.
19 A HSL színtér Ez a színtér definiálja legpontosabban a szín fogalmát, az emberi színérzékelés szempontjából. A Hue (H) komponens határozza meg a szín típusát (Kép 9), vagyis a köznapi életben is használt megnevezést, pl. piros, lila, zöld, stb., melyet egy 360 fokos színkörön helyez el. A Saturation (S) komponens mondja meg a szín telítettségét, tehát, hogy mennyire élénk a szín. A Lightness (L) komponens pedig a fényerősséget jellemzi. Kép 9: HSL színtér - Hue skála A metrikát mindhárom színtérben egyszerűen a komponensenkénti távolság összeadásával definiáltam, azzal a kiegészítéssel, hogy a komponensenkénti különbség súlyozható. Tehát ha két szín 3 komponense (c1, c2, c3) ill. (k1, k2, k3) és a három súly w1, w2, w3, akkor a két szín közötti távolság: d = w1* abs(c1 - k1) + w2 * abs(c2 - k2) + w3 * abs(c3 k3) HSL színtérben a Hue különbséget speciálisan számoljuk, mivel körbeérő színkörről van szó, így a távolság mindig 0-180 között van. A tesztelések után az YUV színtér bizonyult a legjobbnak, mivel konverzió hiányában ez a leggyorsabb, és kellően jó eredményt ad. A alábbi képek mutatják a színkiemelés eredményét az ajkak színére beállítva (Kép 10, Kép 11). Minél fehérebb egy pixel, annál közelebb van a képpont eredeti színe a beállított színhez. Hogy miért szükséges egy durva ill. egy finom beállítás, arról a későbbiekben szó lesz.
Kép 10: Színkiemelés (durva) 20 Kép 11: Színkiemelés (finom) Az orron ill. az állcsúcson elhelyezett, sárga festékkel felfestett pontok kiemelésére is ugyanezt a módszert alkalmazom, csak sárga színre beállítva. 5.4.2. Az ajkak pozíciójának behatárolása Az következő lépés a színkiemeléses képeken az ajkak pozíciójának meghatározása. A folyamat lépései (a lépések eredményét a finom színkiemeléses képre rajzoltattam fel): 1. Legelőször a száj középpontját kell meghatározni a képen. Erre szolgál a durva színkiemelés (Kép 10). Négyzetes súlyozással kiszámoljuk az átlag x,y koordinátát, ahol a súly a pixel fehérsége (0-255). Ezt úgy érjük el, hogy a színkiemelt képen pixelenként a pixel értékét négyzetre emeljük, ezzel beszorozzuk az x ill. y koordinátáját, koordinátánként ezt minden pixelen végrehajtva összeadjuk, majd átlagoljuk az össz. pixel értékkel. Ezt jelzi a piros vonal a képeken (Kép 12, Kép 13, Kép 14). 2. A középpont meghatározása után egy adott szélességű sávban felfelé ill. lefelé megkeressük a ajkak belső ill. külső szélét úgy, hogy a sáv minden sorában összeszámoljuk a sávon belül a fehér képpontok számát, és ha ez egy adott határ felett van, akkor azt ajaknak tekintjük. A keresési sávot sárga vonal jelzi. A detektált belső szélt kék, a külsőt zöld vonal jelzi (Kép 13).
21 3. Az ajkak függőleges széleinek meghatározása után jobbra ill. balra is megkeressük az ajkak széleit. Ez a fenti ill. lenti külső határok által meghatározott sávban történik a függőleges detekciónál leírtakhoz hasonlóan (csak vízszintesen). A széleket zöld vonal jelzi (Kép 14). Kép 12: Középpont meghatározása 5.4.3. Kép 13: Felső ill. alsó szélek meghatározása Kép 14: Jobb ill. bal szélek meghatározása Illesztés A száj körüli MPEG-4 pontok előállítása az ajkak színkiemeléses detektálásának eredményén dolgozva történik. A módszer lényege, hogy a kinyert száj képére illesszük a pontokat a szabványnak megfelelő módon. A továbbiakban csak az előző részben leírt módon behatárolt ajak-képen végzünk számításokat. Az illesztés lépései: 1. A 8-as csoport (továbbiakban: külső pontok) 3-as és 4-es (két szélső) pontjának detektálása. Ezt úgy végezzük, hogy balról ill. jobbról az oszlopokon fentről lefelé végigmenve a legelső fehér pixel koordinátája lesz a két szélső MPEG-4 pont koordinátája. 2. A két szélső MPEG-4 pont közötti vízszintes távolságot felosztjuk 4 egyenlő részre, és a 3 osztópontban függőleges vonalak mentén fentről lefelé ill. lentről felfelé haladva a legelső fehér pixel koordinátái lesznek a 3 felső külső (8.6, 8.1, 8.5) ill. 3 alsó külső (8.8, 8.2, 8.7) MPEG-4 pont koordinátái. A fenti módszerrel megtaláltuk a 8-as csoport pontjait, nevezetesen azon pontokat, melyek a száj külső kontúrvonalán helyezkednek el.
22 A belső pontok detektálása bonyolultabb feladat. A módszer a következő: 1. A külső pontok közül a jobb ill. bal szélső pontból kiindulva keresünk lyukat a szájkontúrban. Ezt úgy végezzük, hogy minden oszlopban először megkeressük az ajak felső ill. alsó határát. Ezután összeszámoljuk a fekete képpontok számát a két határ között, és ha ez egy adott szám felett van, akkor úgy vesszük, hogy ott lyuk van (potenciális nyitott száj). Ezt minden oszlopra elvégezzük, majd kiválasztjuk a leghosszabb lyuk szakaszt, és ezt tekintjük a nyitott száj belsejének. Abban az oszlopban, ahol a lyuk-szakasz két széle van, kiátlagoljuk függőlegesen a belső fekete pontok y koordinátáit, így megkapjuk a 2-es csoport (továbbiakban: belső pontok) két legszélső pontját (2.5, 2.4). 2. Miután a belső pontok két szélső pontja megvan, hasonlóan a külső pontoknál leírt módszerhez, itt is 4 egyenlő részre osztjuk a belső pontok két szélső pontja közötti vízszintes szakaszt. A 3 osztópontban függőleges vonalak mentén, a belső pontok két szélső pontja (2.5, 2.4) közti vízszintes középvonaltól kiindulva, felfelé ill. lefelé haladva a legelső adott mélységű fehér pixel-szakasz koordinátái lesznek a 3 felső belső (2.7, 2.2, 2.6) ill. 3 alsó belső (2.9, 2.3, 2.8) MPEG-4 pont koordinátái. Ezzel a módszerrel megtaláltuk a belső pontokat. Kép 15 demonstrálja az eredményt. Kép 15: Az illesztés eredménye
5.4.4. 23 A detektált pontok korrekciója A detektált ajak körüli pontok a felvétel hibái miatt nem tökéletesek. Bizonyos feltételezéseket azonban tehetünk a pontok egymáshoz való elhelyezkedését illetően. A hibák kijavítására modul készült, mely az alábbi korrekciókat képes elvégezni (belső pontok: 8-as csoport, külső pontok: 2-es csoport pontjai): 1. Szimmetria: Egy adott oldalon elhelyezkedő pont és túloldali párjáról feltételezhető, hogy függőlegesen ugyanabban a pozícióban vannak (y koordinátájuk megegyezik), hiszen beszéd folyamán a száj elméletben szimmetrikusan mozog. Sajnos a detektált pontoknál ez a felvétel hibái miatt nem mindig teljesül. A hiba kijavítására a pontot és párját behúzzuk a két pont által meghatározott vízszintes középvonalba. Ezt a következő pontokra végezzük el: 8.4, 8.6, 8.8 valamint 2.5, 2.7, 2.9 és túloldali párjaik. 2. Belső pontok középre húzása: A száj detektált belső pontjai nem feltétlenül helyezkednek el középen. Ennek oka a beszélő egyéni szájmozgása valamint a felvétel korlátai. Kijavítása úgy történik, hogy a belső pontokat középre húzzuk úgy, hogy a belső pontok középső 2 pontja a külső pontok középső 2 pontjával függőlegesen egy vonalban helyezkedjenek el. A javítás a 2-es csoport pontjait érinti. 3. Belső pontok alaphelyzetbe állítása: Csukott száj esetén a belső pontok rosszul detektálódhatnak. Ezt úgy vehetjük észre, hogy a belső pontok vízszintes középvonala abnormális mértékben eltér a száj közepétől. A hiba kijavítása úgy történik, hogy a pontokat a száj (külső pontok által meghatározott) vízszintes középvonalára helyezzük, egymástól egyenlő távolságra elosztva. 5.5. Hagyományos pontkövetés Az orron, ill. az állcsúcson a hagyományos sárga festékes módszerrel helyeztünk el pontokat. Ezek követése a korábbi rendszerben dilatációs ill. eróziós képfeldolgozási eljárásokkal történt. Ezen pontok követésére egy új módszert dolgoztam ki, mely mindig figyelembe veszi a pontok előző képkockán lévő helyzetét. Ez a módszer szintén az előzőekben ismertetett színkiemeléses képen dolgozik, tehát az első lépés, a pontok szín alapján történő kiemelése már megtörtént. Az alábbi képeken egy csak pontokat használó felfestés követési eredménye látható (Kép 16, Kép 17).
Kép 16: Felfestett pontok 24 Kép 17: Pontkövetés Az eljárás úgy működik, hogy a legelső képkockán megadjuk a pontok kezdeti elhelyezkedését, valamint minden ponthoz rendelünk egy követési téglalapot. Minden egyes képkockán a követési négyzetekben kiátlagoljuk a bennük lévő fehér pixelek koordinátáit a már említett négyzetes súlyozással, és ezzel megkapjuk a pont középpontját. Az előző középpont és az újonnan kiszámolt középpont különbségével eltoljuk a követési téglalapot, és a következő képkocán már ezt használjuk. Az eljárás hátránya, hogy amennyiben egy pont pár képkockára eltűnik, úgy ott eltévedhet a követés, így újra be kell állítani a követési téglalapot. Szerencsére a felvételeken a lassan mozgó pontok nem tűnnek el, és a hagyományos követőt csak ezekre alkalmaztam. 5.6. A detekció eredményének megjelenítése A detekció eredményességének tesztelésére megjelenítő modul készült. Ezen kívül az egyetemen zajló egyéb kutatásokhoz is szükséges volt a megjelenítés, személyek által végzett különböző szubjektív tesztekhez, melyet Feldhoffer Gergely végzett. A megjelenítőben külön lehet ki/be kapcsolni az egyes pont csoportokat, ezen belül pedig a pontokat is egyenként. Továbbá a megjelenítő az ajak körüli pontokat összeköti és a közrezárt területet kitölti (Kép 18). A kapott képet visszavetíthetjük az eredeti videóra, így láthatóvá válik a detekció pontossága (Kép 19).
Kép 18: Megjelenítés 5.7. 25 Kép 19: Megjelenítés az eredeti képen Képkockasebesség A detekció szempontjából a képkockasebesség mindegy mennyi. Az elkészült felvételek 25 fps sebességű videók voltak. Felmerült viszont a kérdés, hogy nagyobb (50 fps) képkockasebességű pontsorozat a megjelenítésnél vajon jobban leolvasható lesz-e. Természetesen az időtartam nem változik, így a lejátszás ugyanannyi ideig tart, csak 1 másodperc alatt több képkockát jelenítünk meg úgy, hogy a meglévőkből új képkockákat hozunk létre. Ennek kipróbálására egy egyszerű interpolációs módszerrel működő képkockasebesség-változtatót készítettem. Jelen állapotában duplázni ill. felezni tudja a képkockasebességet. A duplázás úgy történik, hogy minden képkocka után beszúrunk egy újat, melynek MPEG-4 pontjai az aktuális ill. a következő képkocka pontjainak átlaga. Vagyis kiinterpoláljuk a két képkocka közötti időtartamot. Ezáltal sokkal finomabb, kevésbé darabosan mozgó pontokat kaptam a megjelenítés folyamán. 5.8. Nagy teljesítményű kamera Az utolsó félévben az egyetem beszerzett egy 200 képkocka/mp felvételi sebességgel működő nagy teljesítményű kamerát. A félév vége felé alkalmam nyílt kipróbálni az új eszközt, és kezdeti méréseket is sikerült végeznem. A kamera ún. Bayer-mintás módban vesz fel, és feldolgozás nélkül továbbítja a képet a PC-
26 re, gigabites ethernet kapcsolaton keresztül. A Bayer-szűrő egy színszűrő tömb (CFA color filter array), mely RGB színszűrők elhelyezését határozza meg egy négyzet alapú fényérzékelő rácson (Kép 21, Kép 20). A szűrő 50% zöld, 25% piros ill. 25% kék szűrőt tartalmaz. E szűrőelrendezés által készített szürkeárnyalatosnak tűnő nyers képet hívjuk Bayer-mintás képnek. Ahhoz, hogy színes képet kapjunk, az egyes színértékek interpolációjára van szükség, melyet debayer-nek hívunk. Kép 21: Bayer elrendezés Kép 20: Bayer színszűrés Hogy a kamerából érkező nagy mennyiségű adatot el tudjuk menteni, 4 darab 250 GB tárkapacitású merevlemezt kötöttünk RAID 0-ba. 5.8.1. Debayer A kamerához ugyan mellékeltek egy debayer szűrő algoritmust, ezt azonban sajnos csak a kamera integrált szoftveréből lehetett használni, melyből a felvételt nem lehetett elmenteni. A nyers, bayer-mintás felvételt tudtuk csupán menteni, azonban általános debayer szűrőt nem találtam, így implementáltam egy saját változatot. Ahhoz, hogy egy bayer-mintás képet RGB színes formátumra konvertáljunk, ki kell interpolálni a két hiányzó színkomponenst minden pixelre. Erre több megoldás is létezik [9]. Én a legközelebbi szomszéd valamint a lineáris interpolációt implementáltam. A komponensek interpolációjának lehetséges esetei az alábbi képen láthatók (Kép 22):
27 Kép 22: A hiányzó színkomponensek interpolációjának lehetséges esetei A piros és kék értékek a legközelebbi szomszédok azonos színeinek lineáris interpolációjából kaphatóak. Ha egy zöld pixelen keressük a kék ill. piros értékeket, akkor az (a) ill. (b) esetben a 2 legközelebbi azonos színt átlagoljuk. Például az (a) esetében a zöld pixel feletti ill. alatti kék értékeket valamint a jobb ill. bal oldalon levő piros értékeket. Ha egy piros vagy egy kék pixelen keressük a hiányzó másik színeket, szintén a környező pixeleket átlagoljuk az azonos színből, ebben az esetben azonban 4 értéket átlagolunk. Például (c) esetében a sarkokban lévő négy kék ill. a szomszédos négy zöld értéket. Az interpoláció elvégzése azonban nem elég, szükséges fehéregyensúlyt is állítani. A használt kameránál ez egyszerűen megoldható volt, hiszen látszott, hogy a kék színből van jelentősen kevés valamint a zöldből minimálisan. Ez egy egyszerű RGB állítással korrigálható. Az elkészült debayer szűrő (demosaic.dll) eredménye az alábbi képen látható: Kép 23
28 Kép 23: Debayer szűrés Az eredményt az alábbi egyszerű avisynth script segítségével állítottam elő, melyben a Demosaic() szűrőt implementáltam. Az RGBAdjust() szűrő, mely az utólagos RGB állítást végzi, az avisynth rendszerben már implementálva volt. LoadCPlugin("demosaic.dll") AviSource("test.avi") ConvertToYV12() Demosaic(xoffset = 1, yoffset = 0, method = "bilinear") RGBAdjust(r=1.0, g=1.1, b=1.8, a=1.0, rb=0.0, gb=0.0, bb=0.0, ab=0.0, rg=1.00, gg=1.00, bg=1.00, ag=1.00, analyze=false) Az új kamerával beszélő személyről felvételt készíteni idő hiányában sajnos nem nyílt alkalmam. 5.9. Implementáció A kép- és videófeldolgozási valamint követési eljárások C++ Avisynth szűrőkként lettek megvalósítva, melyek a következők: Colordiff színkiemelés FP_Adjust detektált pontok korrekciója FP_ChangeFPS képkockasebesség-változtatás FP_Contour ajakkövetés FP_Display detektált pontok megjelenítése FP_Point hagyományos pontkövetés FP_Read detektált pontsorozat beolvasása fájlból
FP_Write detektált pontsorozat fájlba írása Demosaic Debayer szűrés 29 A szűrők közötti kommunikáció speciális figyelmet igényel, mivel az Avisynth szkript nyelvének működése bizonyos megkötéseket tartalmaz: Egy meghívott szűrő nem módosíthatja a kapott paramétereket (legyen az videoklip vagy más típusú paraméter) Minden szűrő kimenete (visszatérési értéke) videoklip (képkocka) Ennek következménye, hogy egy szűrő az eredményét kizárólag videoklip (képkocka) formájában tudja visszaadni. Emiatt volt szükség arra, hogy egy speciális képkockába kódoljuk az MPEG-4 pontok koordinátáit. A kódolás a következőképpen zajlik: A speciális kép formátuma BGR32, vagyis pixelenként 32 bites, RGBA komponensekből álló (komponensenként 1 byte-os) képkocka. Minden MPEG4 pont 4 byte-ot foglal (2 byte koordinátánként). Tehát 1 pixelben elfér 1 MPEG4 pont. A képbe írás úgy történik, hogy egyszerűen short int típusúvá konvertáljuk a kép adatmutatóját, és beleírjuk a pontok koordinátáit egymás után. A szükséges adatszerkezetek, valamint alapvető funkcionalitás (pontok betöltése, mentése, stb.) és egyéb speciális módosító függvények (FPS duplázó, pontok korrekciója, stb.) egy általános könyvtárként vannak implementálva. Ezt a könyvtárat használják a szűrők, valamint egyéb más parancssoros programok, melyeket a munkám során készítettem. A detektált pontsorozatot egyszerű szöveges fájlban tárolom. A formátumot író-olvasó rutinok szintén a közös általános könyvtárban vannak implementálva, így bármely később fejlesztendő modul szabadon használhatja, jelentősen megkönnyítve ezzel a jövőbeni fejlesztést. 6. A detektált pontsorozat általánosítása MPEG-4 szerint Az előző fejezetben leírt módszerrel megkaptuk a számunkra lényeges Feature Point-ok (FP-k) abszolút, pixel alapú mozgását. Ezek szigorúan függenek az adott beszélő személytől, hiszen minden ember arcberendezése valamint arcmérete más és más. Ezen kívül függ a kamera beállításaitól is, hogy milyen távol van az illető a kamerától, valamint a felvétel felbontásától is, hiszen a pontok koordinátáinak értékei nulla és a felbontás között vehetnek fel értéket. Nyilvánvaló, hogy ezeket a sok-sok paramétertől (személy-, kamera-, felbontás-) függő
30 értékeket valamilyen módon általánosítani kell, különben használhatatlanok lennének bármilyen virtuális fejmodell meghajtására. Az MPEG-4 szabvány pontosan erre kínál megoldást. Egy MPEG-4 szabványos fejmodell alkalmas vizémák és érzelmi állapotok FAP paraméter alapú közvetlen megjelenítésére. Az MPEG-4 modell kitömörítési (decompress) része egy grafikus modell mozgatási feladat. A szabványosított eljárás elején az alaphelyzetű fej teljes képének meghatározása és vevő oldalra történő átvitele valósul meg, és a továbbiakban csak az alaphelyzettől történő eltérések átvitelére van szükség a tömörített adatközlés során. Az MPEG-4 tömörítési folyamat (Kép 24) azon az elven működik, hogy a tömörítendő mosolygós fej lényeges paramétereinek valamint az alaphelyzetű fej paramétereinek különbségéből meghatározza a tömörített jellemzőket. Az MPEG-4 koncepció szerint ez a jellemzősor már a fej alakjától és környezetétől független adatokat tartalmaz. Kép 24: Az MPEG-4 rendszerű tömörítés koncepciója A visszaállítási folyamat (Kép 25) során a tömörített jellemzőkhöz, amely jelenleg a mosolygás adatait tartalmazza, hozzáadva egy tetszőleges alaphelyzetű fej paramétereit egy mosolygós fej képét kapjuk. Az alaphelyzetű fej meghatározó adatai között kell elhelyezni a felületi jellemzőket valamint esetleges további adatokat, mint például a haj, szem stb. A visszaállítás során kell létrehozni a felületeket azok megvilágítástól függő színezésével együtt. Kép 25: Az MPEG-4 rendszerű visszaállítás koncepciója
31 Ahhoz, hogy az egyik fej szerinti paraméterekkel egy másik fejet animálni lehessen, egy olyan mértékegységre van szükség, melynek segítségével lehetséges a paraméterek konverziója az egyik fej szerint adott értékekből a másik fej szerintibe. Pontosan erre szolgál a FAPU vagyis a Facial Animation Parameter Unit, mely meghatározza a különböző paraméterek mértékegységeit. Az emberi arcra jellemző méretek: ES0 A szemgolyók távolsága IRISD0 Az írisz átmérője ENS0 Az orr hossza MNS0 Az orr és a száj távolsága MW0 A száj szélessége Kép 26: Az emberi arcra jellemző méretek (FAPU) Az MPEG-4-ben a tömörítés során meghatározott és felhasznált távolság mértékrendszer (Kép 26) lehetőséget biztosít arra, hogy a tömörített információ felhasználásával tetszőleges más alaphelyzetű fejre lehessen alkalmazni a visszaállítást, és így lehessen változtatni a visszaállítás folyamatát. Az ES0; IRISD0; ENS0; MNS0; MW0; távolságok határozzák meg az adott arcberendezésen alkalmazandó távolságegységek halmazát. A távolságmérésnek ez a módszere biztosítja azt a lehetőséget, hogy a visszaállítás során az eredetitől jelentősen eltérő felépítésű alaphelyzetben álló fejre is visszaállíthatók legyenek a tömörített információk. Az MPEG-4 szabványnak köszönhetően az arc mozgásához nem kell képkockáról képkockára megadni a videó minden egyes pixelét, mindössze a mozgatott FP-khez tartozó FAP-okat kell továbbítani. Ennek köszönhetően igen alacsony sávszélességen keresztül is elérhető a real-time arcanimáció. Az MPEG-4 szabvány szerint a mozgatás tehát nem közvetlenül átadott FDP koordináták alapján történik, hanem relatív módon, a FAP-ok segítségével. A feladat tehát az, hogy az
32 erősen modell- és felvételfüggő FDP-k helyett a belőlük származtatott FAP-okkal dolgozzunk. Ez alapvetően két dolgot jelent: FDP sorozatból adott FAPU-k segítségével FAP sorozat előállítását (FAP kódolás) FAP sorozatból adott FAPU-k segítségével FDP elmozdulásvektorok előállítását (FAP dekódolás) Az alacsony szintű FAP-ok lényegében egy adott FDP adott irányú elmozdulását kódolják. Például a 3-as FAP a 2.1-es FDP y irányú elmozdulását tartalmazza. Mivel a FAP mértékegysége a FAPU, így ez modellfüggetlen. Hogy mely FAP mely FDP milyen irányú elmozdulását kódolja, azt a szabvány határozza meg, mely az idevonatkozó könyvben megtalálható [7]. Fontos megjegyezni, hogy minden FAP-ot a megfelelő FAPU-val kell számolni. A szabvány szintén leírja, hogy mely FAP-hoz mely FAPU tartozik. 6.1. FAP sorozat előállítása (kódolás) Adott FDP sorozatból modellfüggetlen FAP-okat szeretnénk előállítani. FAP sorozatot a videofelvételből kinyert FDP-adatbázis alapján készítettem, a következő módon. Először is megmérjük a FAPU-kat a felvételen szereplő beszélő arcán, pixelben. Fontos, hogy a felvétel teljes ideje alatt a beszélő végig azonos távolságra legyen a kamerától, hogy a FAPU-k végig ugyanazok maradjanak. A FAPU-k lemérése után kiveszünk egy olyan képkockát, melyen az arc nyugalmi állapotban van. A FAP-okat majd ehhez képest relatív módon fogjuk számolni. Ezután minden képkocka FDP pontjainak koordinátáiból kivonjuk az előzőleg kivett, nyugalmi állapotban lévő képkocka FDP pontjainak koordinátáit. Ezzel kapunk egy delta képkockát, mely az FDP elmozdulásvektorokat tartalmazza, még pixelben, a nyugalmi állapothoz képest. Ezután a szükséges FAP-okhoz, melyeket elő akarunk állítani, kiválasztjuk a hozzá tartozó FDP megfelelő koordinátáját, melyet ez a FAP kódol, és a pixelben lévő értéket a FAP-hoz tartozó FAPU segítségével normalizáljuk (leosztjuk), majd az értéket eltároljuk. Ez lesz a kívánt FAP. Az így elkészült FAP sorozat szabványos, tehát bármely MPEG-4 szabványos FAP lejátszóval lejátszható. Ezt az XFace ill. Lucia FAP lejátszókkal teszteltem, és az animáció az elvárásoknak megfelelően működött.
6.2. 33 FAP sorozat alkalmazása (dekódolás) Bejövő FAP sorozatból FDP koordinátákat szeretnénk előállítani. A bejövő FAP sorozat modellfüggetlen, tehát csak a célpont (az animálandó 3D fej) FAPU értékeire van szükség. Továbbá szintén szükség van a célpont animálandó fej nyugalmi állapotának FDP értékeire. A bejövő FAP sorozat értékeit először átkonvertáljuk az animálandó célpont mértékegységére. Ezt a FAPU-kal végezzük el, úgy, hogy az adott FAP-ot beszorozzuk a hozzá tartozó FAPU-val. Az így kapott értékkel beszorozzuk a FAP-hoz tartozó elmozdulás-irányvektort (mely egységvektor), majd a kapott vektort hozzáadjuk a nyugalomban levő FDP halmaz megfelelő FDP pontjához. Ezt végrehajtva az összes FAP-ra, kapunk egy új FDP halmazt, mely az animált FDP-ket tartalmazza. A dekódolás fázisában szükség van tehát egy táblázatra, mely megmondja, hogy a célpont fejen lévő FDP-ket a hozzájuk tartozó FAP-ok milyen irányban fogják mozgatni. Ez egy FAPirányvektor táblázat. Ez a fajta dekódolás viszonylag egyszerű, mivel feltételezi, hogy a célpont modellen az FDP-k csak egyenes vonalban mozoghatnak. 6.3. FAPU alapú FDP sorozat Az előzőekben ismertetett eljárás szabványhű, és első ránézésre kielégítő lehet. A konzultációk során azonban (és ez korábban is felvetődött), a szabvány által biztosított FAP lista túlságosan szűkös. Található sok olyan FDP, melyet csak egy irányba lehet mozgatni FAP-pal, a másik irány vagy kötött, vagy a környező FDP-kből számolandó. Erre nagyon jó példa a 2.6, 2.7, 2.8, 2.9 ill. a 8.5, 8.6, 8.7, 8.8 FP-k listája, vagyis a száj sarka és a száj függőleges középvonala között elhelyezkedő pontok. Ezeket FAP-pal csak függőleges (y) irányban lehetséges elmozdítani, ellenben definiálva van rajtuk egy megszorítás, miszerint a vízszintes (x). koordinátáikat a száj sarkában lévő FDP x koordinátájának valamint a száj függőleges középvonalán elhelyezkedő FDP x koordinátájának átlaga adja. A fenti hiányosságot kétféle módon lehet orvosolni. Az egyik, hogy kiegészítjük a meglévő FAP-ok listáját olyan FAP-okkal, melyek ezeket az FDP-ket a kívánt irányba mozgatják. Ezáltal több FAP-unk lesz, és felvéve további FAP-okat bármely FDP-t bármilyen irányba mozgathatunk, de eltérünk a szabványtól.
34 A másik lehetőség, hogy a FAP-os animációt megtartjuk, és készítünk egy teljesen új megoldást, melyből a FAP-okat teljes egészében kihagyjuk. Én ezt a megoldást választottam, mivel az egyetemen a korábban ezzel foglalkozó diákok konzulensei, segítői is ezt javasolták. Az új módszer lényege, hogy az FDP-ket modellfüggetlenítjük, méghozzá úgy, hogy közvetlenül az FDP koordinátákat tároljuk FAPU egységekben. A kódolás teljesen hasonlóan működik a FAP kódoláshoz, először kiszámítjuk a delta képkockát, kivonva az adott képkocka FDP értékeiből a nyugalmi állapot FDP értékeit, majd ezután elvégezzük a FAPU-val történő leosztást. Szükség lesz tehát egy új táblázatra, mely a FAP-FAPU táblázathoz hasonlóan azt mondja meg, hogy az FDP-k különböző koordinátáit mely FAPU-kkal kódoljuk. Ez egy FDP koordináta-fapu táblázat, melyet a szabványból kiindulva készítettem el. Az így kapott FDP értékek modellfüggetlenek, FAPU alapúak, és segítségükkel bármely FDP bármilyen irányba elmozdítható. A dekódolás egyszerűbb, mint a FAP-ok esetében, ugyanis nincs szükség irányvektorokra. A bejövő FAPU alapú FDP értékeket egyszerűen felszorozzuk a célpont fej megfelelő FAPU értékeivel, majd egy az egyben hozzáadjuk a nyugalmi állapot azonos FDP-jéhez. A módszer hátránya, hogy mindkét fejnek (a forrásnak és a célpontnak) azonos állásban kell lennie, tehát pl. mindkét fejnél a mínusz y irány az lefelé legyen, az állcsúcs irányába. A FAP-os animációnál ez nem szükséges, hiszen ott a célpontnál a FAP-hoz tartozó irányvektorok adják meg, hogy merre mozdít az adott FAP, ellenben itt az irány rögzítve van. 6.4. Implementáció A fent részletezett FAP kódoló ill. FAP dekódoló valamint az FAPU alapú FDP kódolást végző rutinokat egy közös könyvtárként valósítottam meg, C++ nyelven. Praktikus használatra egy parancssoros programot készítettem (faptool), melynek segítségével mindenféle FAP-FDP manipuláció elvégezhető. Az FDP-k fájlba írása a szöveges mód mellett binárisan is lehetséges, mely nagyságrendekkel felgyorsítja a betöltést ill.a mentést. A FAP fájl formátuma egy elterjedt szöveges formátum, melyet sok más FAP alapú lejátszó is támogat. Ennek következtében könnyen meg tudtam nézni, hogyan mutat az általam előállított FAP sorozat más MPEG-4-es fej-animációs programokban.
7. 35 Három dimenziós megjelenítés A modellfüggetlen FAP-ok ill. FAPU alapú FDP-k birtokában elkezdhetünk foglalkozni a virtuális három dimenziós beszélő fejekkel. Ennek legelső lépése, mielőtt bármiféle animációs megoldáson gondolkodnánk, az általános 3D rajzolás. 7.1. Létező megoldások Ahhoz, hogy beszélő fejeket rajzoljunk, szükségünk van valamilyen megjelenítő modulra, mely képes általános 3D modelleket rajzolni. Egy fejanimációs program ill. háromdimenziós megjelenítő elkészítése elengedhetetlen korábbi, mások által készített, lehetőleg MPEG-4 szabványos megvalósítások megtekintése és tanulmányozása nélkül. Három programot és forráskódjukat vizsgáltam meg tüzetesebben: A Lucia, olasz fejlesztésű MPEG-4 szabványos fejanimációs programot Az Xface nyílt forrású MPEG-4 szabványos fejanimációs ill. FDP szerkesztő programot A Johnnie Talker, Srancsik Bálint PPKE hallgató által, az önálló laboratórium keretében készített fejanimációs programot Az vizsgálat eredményét (programonként) alább ismertetem. Lucia A Lucia [10] egy kizárólag OpenGL megjelenítéssel rendelkező általános MPEG-4 FAP lejátszó. Fejlesztése sokrétű, a hangfeldolgozástól az animációig minden területet lefed. Mivel azonban a modell túl szorosan kapcsolódik a megjelenítőhöz (a modell szó szerint a forráskódba van integrálva, mint header fájl), így szétválasztani nem lehetséges. Csak OpenGL megjelenítésre képes, a fejmodell nehezen cserélhető, valamint forráskódja következetlenül van megírva, így nem használhattam fel a projektben. XFace Az XFace [11] egy nyílt forrású, OpenGL megjelenítésű, MPEG-4 szabványos FAP lejátszó ill. FP szerkesztő. Alkalmas különféle modellek betöltésére, valamint a modellen levő FP-k szerkesztésére, az FP-k arcmozgatáshoz szükséges hatóköreinek meghatározására. A forráskód jól strukturált, az OpenGL megjelenítőt viszonylag egyszerű lecserélni saját megjelenítőre. Sajnos azonban még így sem lehetséges különválasztani a megjelenítő ill. animációs részt a grafikus kezelőfelülettől, ugyanis ezek nem külön könyvtárként, hanem
36 szorosan a program részeként lettek megvalósítva. Johnnie Talker Srancsik Bálint, a PPKE hallgatójának az önálló laboratórium tárgy keretében készített MPEG-4 FAP lejátszója. A program a céljának kiválóan megfelel, de nem általános jellegű. Szorosan integrált, mind a megjelenítő, a modell és a grafikus felület együttesen (minden kódba égetett ). Részekre választani nem lehetséges. Felmerült a program továbbfejlesztése, de a kód elemzése után úgy láttam, hogy több időt venne igénybe a kód átstrukturálása, mint egy teljesen új megjelenítő készítése. 7.2. Saját megvalósítás egyedi 3D motor A létező megoldásokat látva döntöttem úgy, hogy saját megjelenítőt írok alapról. Döntésemet az is erősen befolyásolta, hogy az egyetemen a fejlesztés közben, együttműködve a hangfeldolgozást végző kollégákkal, igény jelentkezett egy olyan megjelenítő elkészítésére, mely képes beszélő fejet valós időben kirajzolni egy PC-n futó élő televíziós adásra. Emiatt, és előreláthatóan a későbbi projektek miatt is előfordulhat, hogy nem vehetünk igénybe hardveres gyorsítást. Rövidebb megfontolás után arra a következtetésre jutottam, hogy nem támaszkodhatunk kizárólag a hardveres gyorsítás (OpenGL) nyújtotta kényelemre, szoftveres megjelenítés lesz szükséges. Természetesen fontosnak tartottam, hogy amennyiben mégis rendelkezésre áll 3D gyorsító hardver, úgy ott az OpenGL gyorsítást vegyük igénybe. Ennek következményeként született meg egy hibrid, mind OpenGL mind pedig szoftveres megjelenítésre is képes 3D motor. A fejlesztésben nagy segítségemre voltak a flipcode cikkei (http://www.flipcode.com/archives/articles.shtml) valamint Charles Bloom írása a szoftveres 3D futószalagokról [12]. Alapvető fontosságúnak tartottam, hogy a megjelenítés módja teljesen független legyen attól, hogy éppen mit akarunk megjeleníteni. Természetesen bizonyos megkötéseket tennünk kell, de alapvetően ne legyen integrálva a fejanimációs kód a megjelenítő kóddal. Ily módon lehetőség van a megjelenítő folyamatos fejlesztésére, anélkül, hogy a fej-animációs kódot bárhol módosítani kellene. A motor C++ nyelven készült, erősen objektum-orientált programozási stílusban. Szoftveres ill. OpenGL rajzoló alrendszerrel rendelkezik, melyek az absztrakt RenderDevice osztályból származnak le. Ennek előnye, hogy a rajzoló alrendszer futásidőben választható, továbbá lehetséges egyéb rajzoló alrendszerek későbbi implementálása. A motor háromszög-listából álló modelleket, úgynevezett geometriai primitíveket képes
37 rajzolni, pont (Kép 27), vonalháló (Kép 28) ill. kitöltött (Kép 29) módban egyszerű textúrázással és Gouraud-árnyalással. Kép 27: Pont rajzolás Kép 28: Vonalháló rajzolás Kép 29: Kitöltött rajzolás, textúrázással és Gouraudárnyalással Ezen rajzolási módokat mindkét rajzolási alrendszer támogatja. 7.2.1. A motor tulajdonságai, képességei A motor a primitíveket az elterjedt vertex buffer - index buffer koncepcióval reprezentálja. A vertex buffer tárolja a modell csúcsait mint xyz koordinátákat, valamint egyéb információkat, mint pl. textúra koordinátákat és színinformációt. Ezek az ún. per-vertex információk. Az index buffer számhármasokat tartalmaz, melyek a vertex buffer-ba indexelnek, és ezen számhármasok határozzák meg a modell háromszögeit, vagyis a modell felületét. Az általam készített általános mátrix osztály segítségével mindenféle transzformáció elvégezhető a modelleken, mint pl. forgatás, eltolás, nyújtás. A mátrix osztályban van implementálva a perspektíva transzformációhoz szükséges speciális mátrix előállítása is. A motor jellemzőbb általános tulajdonságai, képességei: platformfüggetlen alap kód eszköz-független rajzolás (jelenleg: OpenGL, software) kamerakezelés (pozíció, irány, látószög) hierarchikus modell-struktúra (scene-graph)
7.2.2. pont, vonal, kitöltött (textúrázott, Gouraud-árnyalt) rajzolási mód automatikus polygon háromszögelés flexibilis vertex deklaráció burkoló térfogatok (bounding volumes) nézetcsonk ritkítás, vágás (view frustum culling, clipping) 38 Szoftveres rajzoló alrendszer (SoftwareRenderDevice) Mivel nem találtam használható valamint könnyen integrálható szoftveres 3D megjelenítő komponenst, így a háromszögkitöltő rutinokat magam írtam meg. A szoftveres rajzoló saját rajzfelületet foglal a memóriában, erre végzi a háromszögek rajzolását, majd az SDL könyvtár segítségével jeleníti meg az eredményt a képernyőn. A végső megjelenítés teljesen független a rajzolástól, tehát az SDL helyett bármilyen más API használható. A kellő sebesség elérése érdekében a háromszögek kitöltése integer, a textúrázás pedig lebegőpontos (float) aritmetikával történik. Ennek előnye, hogy teljes mértékben kihasználja a processzor integer valamint floating point egységeit, egyiket sem túlterhelve a másik kihasználása nélkül. A kitöltéshez a vonalrajzolásból már jól ismert Bresenham-féle vonalrajzolási algoritmus [13] egyfajta módosított változatát használom. Az algoritmus erőssége, hogy kizárólag integer aritmetikával dolgozik, ezáltal nagyságrendekkel gyorsabb, mint a hagyományos, lebegőpontos vonalrajzolási algoritmus. A Bresenham-féle algoritmus alapján végzem a háromszögek körvonalainak lekövetését (triangle egde tracing). A textúrázás nem perspektíva-korrekt. Hardveres gyorsítók automatikusan végeznek perspektíva-korrekciót a textúrázási fázisban, sajnos azonban ez a szoftveres alrendszerben nincs implementálva. Szerencsére az ennek hiányában jelentkező rajzolási hiba (az ún. textúra-úszás ) csak nagyobb háromszögek rajzolásánál jelentkezik. Mi a megjelenítőt elsősorban fejmodellek rajzolására használjuk, ahol kellően kicsik a háromszögek ahhoz, hogy ez a probléma ne jelentkezzen. Továbbá a textúra szűrés és a textúra interpoláció sem támogatott, mivel ezek igen számításigényes feladatok, viszont a képminőséget nagyban nem befolyásolják. Ellenben a szoftveres rajzoló egyik kiemelendő képessége a Gouraud árnyalás, mely nagymértékben növeli a kirajzolt modell élethűségét (Kép 31).
Kép 30: Árnyalás nélküli rajzolás 7.2.3. 39 Kép 31: Árnyalt rajzolás OpenGL rajzoló alrendszer (OpenGLRenderDevice) OpenGL használatával a rajzolandó háromszögeket egyszerűen az operációs rendszer OpenGL rendszerének továbbítjuk, és ez elvégzi a szükséges textúrázást, szűréssel és árnyalással együtt. Pontok rajzolásának módja: glbegin(gl_points);... glvertex3f(v->x, v->y, v->z);... glend(); Vonalháló rajzolásának módja: glbegin(gl_lines);... glvertex3f(v1->x, v1->y, v1->z); glvertex3f(v2->x, v2->y, v2->z);... glend(); Egy kitöltött, textúrázott háromszög kirajzolásának módja:
40 glbegin(gl_triangles);... gltexcoord2f(uv1[0], uv1[1]); glvertex3f(v1->x, v1->y, v1->z); gltexcoord2f(uv2[0], uv2[1]); glvertex3f(v2->x, v2->y, v2->z); gltexcoord2f(uv3[0], uv3[1]); glvertex3f(v3->x, v3->y, v3->z);... glend(); 7.2.4. Hierarchikus modell-struktúra (Scene Graph) Ezt a jellemzőt azért tartottam lényegesnek megemlíteni, mivel ezáltal nyílik lehetőség egy modell részeinek egyszerű összekapcsolására, együttes mozgatására. A mi esetünkben különösen hasznos lesz, hiszen egy fej általában több részből áll össze (arc, szemek, fogak, nyelv, garat, haj, stb.). A struktúra lényege, hogy a modellrészeket fa-szerkezetbe rendezi. Minden csomóponthoz (SceneNode) tartozik transzformációs adat. Ezek: egy vektor az eltoláshoz (translate), egy mátrix a forgatáshoz (rotate) valamint szintén egy vektor a nyújtáshoz (scale). A csomópontok valójában al-modellek. A mi esetünkben ez lehet a szemek, fogak, nyelv, garat, arc, haj, stb. Kinevezünk egyet gyökérelemnek, és a többi modellrészt alárendeljük. Az alárendelt modellrészek öröklik a szülő transzformációját. Tehát pl. ha a fej a gyökérelem, és minden más az alárendeltje, akkor a fej forgatásával együtt forogni fog az összes többi modellrész anélkül, hogy azokat külön forgatnunk kellene. Ezen felül az alárendelt elemek önmaguk is foroghatnak/mozoghatnak a saját koordinátarendszerükben. Pl. ha a szemet külön akarjuk forgatni (pl. jobbra nézzen), akkor a szem modellrésznek beállítunk egy elfordulást, és az a saját tengelye körül fog elfordulni. Emellett ha mondjuk a fejet is elfordítjuk, akkor a szem a fejhez képest a helyén marad (a szemüregben), de saját elfordulását megtartja (tehát pl. továbbra is jobbra néz). Ennek óriási előnye, hogy természetes működést produkál, vagyis azt amit várunk. Tehát ha azt mondjuk, hogy a fej forduljon balra, akkor a fej az összes tartozékával együtt (szem, fogak, nyelv, haj, stb.) balra fog fordulni, anélkül, hogy szétesne. Természetesen az itt leírt példa a fejjel csupán egy speciális eset, a rendszer, vagyis a
41 hierarchikus modell-struktúra teljesen általános. 7.2.5. Általános 3D animáció Háromdimenziós animációknál általában kétféle animációról beszélünk: magas szintű ill. alacsony szintű animációról. A magas szintű animáció általában egy teljes modellre vagy a modell egy nagyobb részére vonatkozik. Ez lehet pl. egy ember-modell törzsének elfordítása, a fej elfordítása, a kar mozgatása, stb. Tehát mindig a modellrész egészén, vagy a modell csúcsainak (vertex-einek) nagyobb összefüggő halmazán értelmezett egységes művelet. Mátrixokkal vagy előre definiált csúcs pozíciókkal (kulcs-képkockákkal: key-frame-ekkel) könnyen leírható. Az alacsony szintű animáció a csúcsok szintjén működik. Ez általában azt jelenti, hogy a modell meghatározott csúcsait elmozdítjuk, új pozíciót adunk meg nekik. Ez lehet pl. az arc finom mozgásainak animációja, a bőr egy adott ponton való nyújtása, stb. A motor lehetőséget ad mind magas, mind pedig alacsony szintű animáció végrehajtására, egyrészt a hierarchikus modell-struktúra segítségével, másrészt azáltal, hogy hozzáférést biztosít a modellek csúcsaihoz, valamint teljes hálószerkezetéhez. 8. Három dimenziós fejanimáció A legtöbb modell, legyen az két- vagy háromdimenziós, hálókból áll. A háló (mesh) több egymáshoz illeszkedő nem feltétlenül egy síkban levő sokszöget tartalmazó felület. A hálóban a csúcspontok koordinátáin kívül a lapok, az élek és a csúcsok illeszkedési viszonyait is nyilván kell tartani. A modell felületi jellemzői, textúrája erre a rácsra van ráhúzva. Ahogy mozgatjuk a háló csúcspontjait, úgy mozog vele a textúra is. Ám az MPEG-4 szabványban csak az FP-k mozgatására van mód, az egyes hálókéra közvetlenül nincs. Egy modell tetszőleges számú és finomságú hálóból állhat, a szabvány erre nem terjed ki. Minden MPEG-4 kompatibilis fejmodell azonban azonos tartópont rendszerre épül. A hálók mozgatása a tartópontok mozgatásával történik. A szintetikusan létrehozott szájmozgás megjelenítésére felhasznált fejmodell egy szokásos 3D grafikus modell, amely animálható és így a céljaink megvalósítására alkalmas (Kép 32). Ezt a modellt az XFace programból exportáltam ki, majd Perl szkriptekkel automatizáltam a folyamatot, hogy más, jövőbeli modellek exportálása is gyors és egyszerű legyen.
42 Kép 32: Az általam használt fejmodell a tartópontokkal 8.1. A fejanimáció lépései A fej, elsősorban pedig az arc finom mozgásainak animációját részben az XFace, valamint az egyéb más programoknál is alkalmazott módszer ihlette. A módszer az MPEG-4 szabványon nyugszik. Durva közelítéssel mondhatjuk, hogy egy tartópont (FP) egy bizonyos nagyságú környezetére van hatással az arcon, vagyis a környező csontokra ill. bőrfelületre. Tehát ha a bőr megnyúlik vagy a csontok elmozdulnak, az ott lévő FP-k is elmozdulnak, másik oldalról nézve, ha egy adott FP-t elmozdítunk, akkor a környező bőrfelület a ponttal együtt mozdul el. Ebből kiindulva az alapötlet az, hogy minden FP-hez hozzárendelünk egy listát, mely megmondja, hogy az adott FP mely hálópontokra van hatással. Ez lesz az adott FP hatóköre (Kép 33).
43 Kép 33: Példa egy FP hatókörére A hatókör megadása többféle módon történhet. Az XFace lehetőséget ad a kézi szerkesztésre. Ez meglehetősen nehézkes, mivel kézzel (egérrel) kell minden egyes FP-hez kiválogatni a kívánt hálópontokat. Kétség kívül a legpontosabb megadás ezzel volna lehetséges, azonban az ehhez szükséges idő aránytalanul sok. Egyszerűbb módszer a távolsággal meghatározott hatókör lista. Ez úgy történik, hogy megadunk egy távolságot, és ha az adott FP-hez egy hálópont ezen a távolságon belül van, akkor bekerül az FP hatókörébe. Nagyon fontos azonban ez esetben, hogy ne légvonalbeli távolsággal számoljunk, hiszen akkor pl. az alsó ajak FP-i a felső ajak hálópontjait is bevennék a hatókörbe. Emiatt kizárólag a hálószerkezet összeköttetése alapján vehetünk egy adott pontot szomszédosnak. Ezáltal pl. az átnyúlás az alsó ajakról a felsőbe kiküszöbölődik. Tehát egy FP elmozdulása valamilyen hatással lesz a hatókörének pontjaira. Ez a hatás a hálópont FP-től való távolságától, az FP elmozdulásának mértékétől és irányától, az FP típusától valamint egyéb paraméterektől (választott súlyozás) függ. A fejmodellben a hatókör egy hálópontjának az FP-től való távolsága arányában egy bizonyos súlytényezőt számolunk. E nélkül a hatókör szélén elhelyezkedő pontok a szomszédoktól igen eltérő mozgást produkálnának, ami a modell szakadozott mozgásához vezethet. Továbbá a súlytényező nem lehet a távolság arányában egy lineáris függvény szerint számolt érték, hiszen az hasonló szakadozott animációhoz vezetne. Éppen ezért az FP-k súlytényezői a következő képlet szerint alakulnak:
1 cos 1 w ij = sij rj 2 i=1...n, 44 j=1...86 Ahol wij a j-edik FP által mozgatott, a hatókörben az i-edik vertex súlytényezője, sij a j-edik FP és annak hatókörében az i-edik vertex távolsága, rj pedig a j-edik FP hatókörének sugara. A sugár az FP középpontjától legtávolabb levő, az FP hatókörébe tartozó pont távolsága. Az sij, vagyis a j-edik FP-től vett távolság háromdimenziós esetben a következőképpen alakul: s ij = x FPj xi 2 y FPj y i 2 z FPj z i 2 Ez a megoldás nagyon egyszerű, de messze nem a legjobb. Az általunk használt FP-k modellezésére ellenben tökéletesen alkalmas. Ha a súlytényezőket eszerint állítjuk be, az azt eredményezi, hogy az FP mozgatásakor, a hatókörön belül elhelyezkedő pontokra egyre kevésbé hat az FP, a távolság arányában. Így a hatókör széle felé kis elmozdulást kapunk, míg az FP tőszomszédságában az elmozdulás közel azonos az FP elmozdulásával (Kép 34). Kép 34: Egy FP hatása a hatókörére 8.2. Kép 35: FP-k elmozdulásának hatásai a hatókörükre 3D modell animálása FAP-okkal A bejövő FAP sorozat alapján, az előző fejezetekben ismertetett FAP dekódolással, meghatározzuk az új FDP pozíciókat. A új FDP pozíciók ismeretében meghatározzuk az elmozdulás irányát és nagyságát. Ennek ismeretében, a fenti súlytényezőt felhasználva, az előre megadott hatókörben szereplő hálópontokat elmozdítjuk.
8.3. 45 Az elkészült fej-animációs rendszer A 3D modell hálójának tényleges animálására C++ modult készítettem. Óriási előnye, hogy bármilyen 3D reprezentációval rendelkező modellt tud mozgatni, ami fontos, hogy vertex- és háromszöglistán alapuló modell legyen. A fej-animációs modul teljesen független a már korábban ismertetett 3D megjelenítőtől, így bármilyen más megjelenítőbe könnyedén beépíthető, anélkül, hogy azon bármiféle módosítást végre kelljen hajtani. Ezt úgy sikerült elérni, hogy az animációs modulnak mindössze egy vertex buffer-re és benne a vertexek adatainak elrendezésére van szüksége, tehát, hogy hol találja meg a vertexek 3D koordinátáit. A modul tehát könnyen beilleszthető bármilyen környezetbe. Ennek bemutatására készítettem egy Avisynth plugin-t, melynek segítségével lehetséges a beszélő személyről készített felvétel lejátszásával szinkronban a 3D fej animálása (Kép 36). Kép 36: Avisynth megjelenítő modul 9. Kapcsolat az IPTV siketek számára projekttel Mint említettem, időközben lehetőség adódott együtt dolgozni az egyetemen hangfeldolgozást végző kollégákkal. A projekt célkitűzése egy olyan speech-to-animation
46 rendszer kidolgozása, mely közvetlenül a hangból származtatja a fejmodell animálásához szükséges paramétereket. A projekt különlegessége, hogy ezt egy élő TV adásba való integrációval, picture-in-picture formájában kívánja megvalósítani. Az én feladatom volt a projektben egy alkalmas keretrendszer felkutatása, kiértékelése, a hanghoz való hozzáférés biztosítása, valamint a megjelenítés elvégzése oly módon, hogy az élő TV adásból származó hang feldolgozása után az abból nyert paraméterekkel animált fejet az eredeti képre kellett visszahelyeznem. A rendszer demó jellegű, tehát PC-s környezetben kellett megvalósítani. Rövidebb kutatás után a DirectShow keretrendszert találtam alkalmasnak arra, hogy bármilyen módon a PC-be érkező TV adást a fent leírt módon feldolgozni tudjuk. A prototípus elkészítése Microsoft Windows platformon történt. Fontos hangsúlyozni, hogy a rendszer belső működése valamint a megjelenítés egymástól függetlenül van megvalósítva, így bármely más platformra átültethető, amennyiben megfelelő megjelenítő modul készül az adott platformhoz. A megjelenítés alapvetően két részre bontható: a 3 dimenziós fejmodell kirajzolása a kiszámított paraméterek alapján a kirajzolt modell mozgóképbe ültetése (PIP: picture-in-picture) A megjelenítés első fázisa (a 3D modell rajzolása) a szoftveres 3D rajzolóval történik, memóriába, mely így alapvetően platformfüggetlen. A kirajzolt modell mozgóképbe ültetése függ csupán az adott platformtól. A megjelenítés végső fázisa (a mozgóképbe ültetés) a Windows által támogatott DirectShow környezetben készült. 9.1. A DirectShow keretrendszer A DirectShow egy média feldolgozó architektúra a Windows platformhoz. Lehetővé teszi magas minőségű multimédiás tartalom felvételét ill. lejátszását. Formátumok széles skáláját támogatja, mint például az ASF, MPEG, AVI, MP3, WAV, stb. Támogat digitális ill. analóg felvevőeszközöket. Multimédiás tartalom feldolgozása sok kihívást jelent: Multimédiás folyamok nagy mennyiségű adatot tartalmazhatnak, melyet nagyon gyorsan kell feldolgozni
47 A hangot és képet szinkronizálni kell, hogy egy időben induljanak és álljanak meg, valamint egyforma sebességgel történjen a lejátszásuk Az adat sok különböző forrásból származhat, mint például helyi fájlokból, hálózatról, televíziós sugárzásból, vagy videokameráról. Az adat sok különböző formátumban érkezhet, mint pl. AVI, ASF, MPEG, DV, stb. Egy multimédiás alkalmazás fejlesztője nem tudhatja előre, hogy milyen hardver áll rendelkezésre a célszámítógépen. A DirectShow a fenti kihívásokra kínál megoldást. Hogy a sok különböző forrás, formátum ill. hardver különbözőségeket kezelni lehessen, a DirectShow egy moduláris architektúrát használ, melynek alapeleme a szűrő. Egy szűrő bemenetekkel és/vagy kimenetekkel rendelkező komponens, mely egy adott részfeladatot lát el. Alapvetően 3 típusú szűrő van: Forrás szűrő (Source filter) Transzformáló szűrő (Transform filter) Megjelenítő szűrő (Rendering filter) Kép 37: A DirectShow keretrendszer felépítése Az architektúra alapkoncepciója a gráf-modell, melynek csomópontjai a szűrők. A DirectShow biztosít egy alap szűrőkészletet, de a rendszer igazi erőssége abban rejlik, hogy tetszőleges szűrőkkel bővíthető. Szemléltetésképpen itt van egy AVI fájl lejátszásának
48 folyamata a Windows médialejátszójában: Nyers adat olvasása a fájlból bájt-sorozatként (Fájl forrás szűrő) Az AVI formátum feldolgozása, szétválasztás képkockákra ill. hangmintákra (AVI Splitter) A képkockák dekódolása (különböző dekódoló szűrők lehetségesek, a képkocka tömörítésétől függően) A képkockák megjelenítése (Megjelenítő szűrő) A hangminták lejátszása a hangkártyán keresztül (Hanglejátszó szűrő) Kép 38: AVI fájl lejátszásának folyamata a DirectShow keretrendszerben 9.2. Szűrő-gráfok készítése ill. tesztelése Szűrő-gráf automatikusan épül, ha a szűrő-gráf kezelőnek egy médiaforrás URL-t adunk, mint pl. egy fájlnevet a helyi meghajtón vagy egy hálózati címet. Ellenben lehetőség van szűrő-gráf manuális összeállítására is. Erre a GraphEdit program szolgál, mely a DirectShow SDK része, és amely szűrő gráfok összeállítását valamint tesztelését teszi lehetővé. 9.3. A projekt megvalósítása Az animált fejmodell megjelenítése valamint mozgóképbe helyezése DirectShow transzformáló szűrőként lett megvalósítva, egy audio bemenettel és egy video kimenettel, mely a speech-to-animation konverziót valósítja meg (a szűrő neve Talking Head). Egy összeállított gráf, mely az elkészült szűrő kimenetét ráhelyezi egy élő adás képére, így néz ki (Kép 39):
49 Kép 39: Összeállított szűrő gráf Az eredmény az alábbi képen látható (Kép 40) Kép 40: IPTV siketek számára Fontos megjegyeznem, hogy DirectShow szűrők készítése különösen nehéz feladat. Nem csupán a keretrendszerrel és annak működési elveivel kell tisztában lenni, hanem a Windows Component Object Model programozási módját is ismerni kell. A szűrő elkészítése ily módon a vártnál nagyságrendekkel nehezebbnek bizonyult.