ii
České vysoké učení technické v Praze Fakulta Elektrotechnická
Diplomová práce
Otevřené virtuální TV studio Bc. Jan Charvát
vedoucí práce: Ing. Roman Berka, Ph.D.
Studijní program: Elektrotechnika a informatika, strukturovaný, Navazující magisterský
Obor: Výpočetní technika květen 2009
iv
` Poděkování: Velice rád bych poděkoval Ing. Romanu Berkovi, Ph.D., za odborné konzultace, které mi přinesly cenné rady pro vypracování této diplomové práce a také za poskytnutí vybavení a prostoru na realizaci a této práce.
vi
Prohlášení: Prohlašuji, že jsem diplomovou práci vypracoval samostatně a použil jsem pouze podklady uvedené v přiloženém seznamu. Nemám žádný důvod, proti užití tohoto díla ve smyslu §60 zákona č.121/2000 Sb., o právu autorském, o právech souvisejících s právem autorským a o změně některých zákonů (autorský zákon).
V Praze dne dne 21. 5. 2009
….........................................................................
viii
Abstract Every larger TV channel has its own studio, in which it makes own televiews. Some of them, however, have so specific artistic design, which can’t be made in real. That’s why virtual studios came up. With them you are able to bring non-realistic objects into studio. This technology works not only in virtual TV studios, but also in film or film postproduction. In this thesis, a concept and implementation are made, which could be used also practically. A big problem of virtual studios is generally their high price and accuracy. Here we’ll try to make a system that will be cheap and accurate enough. It will be an open source virtual studio, which means that it will be made of free accessible or licensed components, which allows their exploitation.
Abstrakt Každá větší televizní stanice má své studio, v němž připravuje vlastní pořady. Některé pořady však mají takové nároky na provedení, jež nelze v reálné podobě uskutečnit, a proto vznikla studia virtuální, která dokáží vnést do reálného studia nereálné, virtuální prvky. Tato technologie funguje nejenom v televizních virtuálních studiích, ale může mít své využití i ve filmu nebo filmové postprodukci. Předkládaná práce se zabývá popisem, návrhem a implementací systému, který umožňuje provozování virtuálního studia. Problémem většiny těchto studií je jejich vysoká cena a požadovaná přesnost. Zde se pokusíme sestavit systém nenáročný jak na finanční prostředky, tak i poměrně přesný. Půjde o otevřené virtuální TV studio a všechny jeho části budou volně dostupné nebo pod licencí, jež umožní volné jejich použití.
ix
x
Obsah 1 Úvod 2 Popis virtuálního studia, specifikace cíle 2.1 Popis klasického studia, virtuálního studia a jeho zázemí 2.1.1 Kamerový systém a scéna 2.1.2 Virtuální scéna 2.1.3 Klíčování 2.1.4 Systém sledování pohybu 2.2 Základní schéma virtuálního studia 2.3 Cíle
1 2 2 4 5 5 6 7 8
3 Analýza a návrh virtuálního studia 3.1 Návrh implementace 3.2 Návrh částí 3.2.1 Kamerový systém a scéna 3.2.2 Virtuální scéna 3.2.3 Klíčování 3.2.4 Systém sledování pohybu 3.3 Návrh fyzických součástí
9 11 12 12 13 16 19 20
4 Realizace 4.1 Implementace částí 4.1.1 Kamerový systém a scéna 4.1.2 Virtuální scéna 4.1.3 Klíčování 4.1.4 Systém sledování pohybu 5 Testování 5.1 Testování částí 5.2 Návrhy zlepšení 5.3 Srovnání
21 22 23 25 28 31 38 38 42 43
6 Závěr Literatura
45 46
A Instalace a spuštění Otevřeného virtuálního TV studia B Obsah přiloženého CD
47 50
xi
xii
Seznam obrázků obr. 1 klasické televizní zpravodajské studio s průhledem do newsroomu obr. 2 měkké světlo obr. 3 virtuální studio (a) – záběr z kamery (b) – výstup v televizi diváka obr. 4 virtuální studio založené na senzorech obr. 5 virtuální studio založené rozpoznávání obrazu obr. 6 návrh schématu zapojení virtuálního studia obr. 7 datové přenosy v systému obr. 8 návrh základního výstupu na obrazovku obr. 9 příklad VRML scény obr 10 schéma popelíne na grafické kartě s vyznačením vertex a fragment shaderu obr. 11 krychle obarvená pomocí fragment shaderu obr. 12 pozadí virtuálního studia pro systém rozpoznávání obrazu obr. 13 schéma zapojení IR LED diod senzoru obr. 14 GUI obr. 15 class diagram obr. 16 vývojový diagram kamerového systému obr. 17 schéma výpočtu virtuální scény obr. 18 schéma vytváření shaderu obr. 19 obr. 19 schéma spuštění shaderu obr. 20 Wii Remote obr. 21 senzor (a) – pohled shora (b) – pohled zleva (c) – perspektiva obr. 22 Wii Sensor Bar (a) – celý Sensor bar (b) – detail rozebrané části, rozložení a natočení diod Sensor baru obr. 23 bod senzoru obr. 24 schéma zapojení senzoru obr. 25 senzor obr. 26 bod senzoru obr. 27 průběh výpočtu pozice jedné kamery obr. 28 testovací scéna obr. 29 testovací virtuální scéna obr. 30 výsledný složený obraz obr. 31 testování v laboratoři IIM
2 3 4 7 7 9 10 11 16 17 18 20 20 21 22 25 27 28 31 32 33 34 34 35 35 36 37 38 39 40 41
xiii
xiv
Seznam tabulek tabulka 1. testování přesnosti sledovacího systému
42
xv
xvi
1 Úvod Digitalizace postupně prostupuje naší republikou a tím zvyšuje počet televizních stanic, jež vyplňují náš éter. Pokud chce televizní stanice produkovat vlastní a často pro diváky zajímavější pořady, musím mít své studio. Tato studia bývají velmi dobře vybavena a osvětlena. Ani nejlepší vybavení ovšem na některé návrhy nestačí a je třeba dodat nereálné objekty, které by scénu doplnily. K tomu slouží tzv. virtuální studia, tedy studia, kde se reálný obraz spojuje s nereálným. Ta jsou na první pohled zvláštní tím, že na určité ploše, někdy i na celém pozadí, se umístí jedna kontrastní barva, např. zelená nebo modrá. A tato plocha se pak nahradí virtuálním obsahem. Výhodou takových studií je, že jsou dynamická a je možné měnit pomocí počítače obsah modrých ploch, zatímco u klasických studií je dynamičnost omezena na technické vybavení studia a fyzikální zákony. Cenou za takový luxus je velká technická složitost provedení a především vysoké pořizovací náklady. Právě pro svou technickou náročnost bývají studia vyvíjena v uzavřeném režimu různými společnostmi, které se o výsledky své práce samozřejmě nechtějí dělit. Virtuální studia mají však stále velký potenciál využití a je možné je neustále vylepšovat a rozšiřovat jejich možnosti. V uzavřeném režimu ovšem záleží pouze na firmě, která studio vytváří, zda bude studio dále vyvíjet. Otevřenost kódu by mohla přinést do tohoto prostředí novou vlnu invence. Důležitá je rovněž nezávislost studia na jiných programech či komerčních společnostech. Díky tomu nebude nutné pořizovat drahý software, který by studio umožnil provozovat. Technický pokrok v oblasti počítačů by mohl umožnit přenést náročné úkoly z drahých komponent do počítače a tím zlevnit celkovou cenu studia.
1
2 Popis virtuálního studia, specifikace cíle Zde vysvětlíme, jak se liší klasické studio od studia virtuálního, dále si popíšeme rozdělení jeho částí a cílů a nakonec uvedeme diagram znázorňující propojení systému.
2.1 Popis klasického studia, virtuálního studia a jeho zázemí Klasické televizní studio je složeno z částí, které jsou v něm fyzicky přítomné. Složení objektů se liší podle účelu, k němuž je vytvořeno. Například zpravodajské studio obvykle obsahuje stůl, u nějž sedí jeden nebo více moderátorů. V zahraničí tomu tak řadu let také tak bývalo. V dnešní době se již objevují i studia bez stolu, kde je vidět moderátor od hlavy až k patě. Výhodu stolu u zpráv je mimo jiné to, že se moderátor může připravit pouze od pasu nahoru. Nikdo totiž neuvidí, jestli náhodou nesedí ve studiu v krátkých kalhotách, což se už nejednou stalo. Diskusní pořady mívají naproti tomu pohodlné sezení, soutěžní zase různé pulty nebo stolečky.
obr 1. Klasické televizní zpravodajské studio s průhledem do newsroomu
Každé studio má pak své další vybavení, jež se v záběrech většinou neobjeví. Jeho nejdůležitější součástí jsou samozřejmě kamery přenášející obraz do režie. V režii sedí několik lidí, kteří se starají o hladký průběh vysílání. Člověk sedící u režisérského pultu kromě jiného vybírá podle přání režiséra obraz, který půjde na výstup vysílání. Další pracovník se stará o titulky, jež se mohou ve vysílání vyskytnout. Při živém vysílání je to pak on, kdo mluvícím lidem dodává titulky se jmény a funkcemi. Jak se v televizním žargonu 2
říká, titulkář je skoro nepřetržitě „venku“, což znamená, že všechno, co dělá, je okamžitě při vysílání vidět a on nemá čas na opravu, pokud se zmýlí. Má-li pořad nějaké příspěvky, klipy apod., sedí v režii další člověk, který se stará o to, zda jsou příspěvky připravené a ve správném pořadí. Dříve, když se ještě vysílalo z kazet, měl tento pracovník připravené kazety a příspěvky pouštěl na přehrávacím zařízení značky Beta, jež se podobalo klasickému domácímu videu, ale používalo se jen v televizích, přestože technologicky systémy VHS předčilo. Zvukař se v režii stará o správné ozvučení celého studia. Má před sebou zvukařský pult a musí neustále dohlížet na to, aby zvukové úrovně byly správně nastavené. Dále je tam člověk, který sleduje barevné úrovně v obrazu. Má k dispozici histogram na každou základní barvu, tedy na červenou (R), zelenou (G) a modrou (B), a rovněž na úroveň jasu; histogram mu ukazuje, jak je v obrazu zastoupena každá složka. Pokud by byl obraz přeexponovaný nebo podexponovaný, může ještě omezeně zasáhnout. V neposlední řadě může být v režii pracovník, který pohybuje s tzv. čtecím zařízením. To je obvyklé u zpravodajských relací, kde jsou na kamerách umístěna speciální zařízení, umožňující číst moderátorovi text přímo z objektivu kamery, jako by četl zpaměti. V režii bývá celá jedna stěna osazena obrazovkami, kde jsou všechny obrazové vstupy režie. Jsou tam signály ze všech studiových kamer, dále z aktuálního vysílání stanice, z případného přenosu mimo budovu a také z grafiky, odkud se mohou vkládat další součásti obrazu. Celá osádka režie se schází několik desítek minut před vysíláním, aby je připravila. Další velmi důležitou součástí studia jsou světla. Správné osvětlení studia je velmi podstatné. Klasická studia mají většinou tři stěny kolem kamer plus podlahu. Strop bývá osazen světly. Důležité u těchto světel je skutečnost, že jsou ve své velké většině měkká (obr 1.), tedy rozptýlena přes určitou plochu. Předměty poté nevrhají ostré stíny, ale mají měkké okraje, jako když je venku zataženo.
obr 2. Měkké světlo
Virtuální studio se od klasického liší především tím, že umísťuje do scény nereálné – virtuální prvky. Příkladem mohou být pořady jako počasí, Toulavá kamera, Objektiv, Prizma, Svět 2009, TopStar a mnoho dalších. V různých studiích mají různá použití. Základní zásadou je odstranění určité barvy na nějaké ploše a její nahrazení virtuálním prostředím, jak ukazuje obr. 3. V některých studiích mají barevné celé pozadí, jinde je barevný pouze určitý výsek plochy, doplněný o reálné předměty.
3
(a)
(b)
obr 3. Virtuální studio (a) – záběr z kamery (b) – výstup v televizi diváka
Barevná plocha ve virtuálním studiu musí být velmi kvalitní, aby její barva byla co nejrovnoměrnější, což zásadně usnadní její odstranění. Zde je také kladen mnohem větší důraz na osvětlení scény. Studio musí být nasvětlené tak, aby moderátor nevrhal příliš mnoho stínů a plocha neměla velké rozdíly v osvětlení. Rovněž obsluha virtuálního studia je složitější. Ve studiu musí být pohyb kamer sledován speciálním zařízením. Režii přibývá jeden pracovník, který se musí o virtuální scénu starat. Před vysíláním připravuje její nastavení a během něj pracuje s případnými interaktivními prvky. Virtuální studio rovněž přináší do celého zpracování obrazu větší časové zpoždění a je tedy nutné zvuk přicházející ze studia pozastavit a synchronizovat s obrazem. Virtuální studia přinášejí oproti klasickým do televizního vysílání nové prvky, které by byly v reálném světě příliš složité, nákladné nebo dokonce nerealizovatelné. Rozšiřují pole možností, jež lze v televizním studiu využít. S technikou pokročilého virtuálního studia je možné interaktivně pracovat s prostředím. Nejnovější techniky dovolují snímat pohyb člověka-moderátora, pracovat s ním a měnit s ním virtuální scénu.
2.1.1 Kamerový systém a scéna Kamerový systém se skládá z libovolného počtu klasických kamer; jeho výstupem jsou snímky, které se následně zpracovávají v režii. Virtuální studio by nemělo omezovat jeho provozovatele při výběru kamery. Neměl by být ani problém zpracovat jak rozdílné formáty PAL nebo NTSC, tak klasické rozlišení 720 x 576 pixelů nebo 1920 x 1080 (full HD) či jiné podobné formáty. Virtuální studio by se rovněž nemělo omezovat pouze na statické kamery – mělo by umožňovat jejich pohyb po studiu, aby se ve studiu prodalo jeho virtuální prostředí. Scéna virtuálního studia má oproti klasickým studiím jen jednu zvláštnost. Tou je právě barevná neboli klíčovací plocha. Tato plocha nemusí být nutně zrealizována jako pozadí, ale často tomu tak bývá. Barva bývá volena taková, aby se u lidí nebo předmětů, jež budou ve
4
studiu, vyskytovala co nejméně – např. zelená nebo modrá. Aby bylo klíčování co nejúčinnější, je třeba vše vhodně nasvítit. Plocha nesmí být nasvícena přímo, protože by na ní snímané objekty vrhaly stíny, což by značně zkomplikovalo klíčování. Osvěcuje se tedy nepřímo, nebo přes měkká světla. Také je důležité, aby byla nasvícena všude stejnoměrně. Protože je zde víc světel než obvykle, moderátoři i účinkující vždy musí zajít do maskérny a nechat si namaskovat a zejména napudrovat obličej. Při tak silném osvětlení by se totiž jejich tváře nepříjemně leskly. Zde se nerozlišuje, jak velká bude klíčovací plocha. Může zahrnout celé studio, nebo třeba jen malý výřez.
2.1.2 Virtuální scéna Virtuální scénou je obvykle jakýsi trojrozměrný (3D) počítačový model, který se do reálné scény přidá přes zmíněnou barevnou plochu. Virtuální scéna obsahuje přinejmenším stejný počet kamer jako scéna reálná. Pomocí speciálního zařízení se sleduje pohyb reálných kamer a podle toho se řídí pohyb virtuální kamery. Vše pak vypadá přirozeně a divák ani nemusí poznat, že přidané prvky ve studiu vůbec nejsou. Scéna nemá co do velikosti žádné omezení a nemusí být ani stejně velká jako studio. Jediným omezením je snad rychlost spočítání jednoho snímku scény. Většinou se totiž virtuální studia používají živě a je tedy třeba, aby scéna byla spočítána rychleji, než kamera pošle další snímek. Nekladou se ani žádné požadavky na strukturu či formát virtuální scény. Pro oživení by virtuální scéna mohla obsahovat prvky, jež by se pohybovaly a případně reagovaly na podněty ve studiu. Není to podmínkou, ale je to možné udělat. Záleží na pojetí, jaké zvolí tvůrce studia.
2.1.3 Klíčování Klíčování označuje odstraňování bodů (pixelů) obrazu na základě nějakých podmínek. Těmi může být kromě jiného například určité barevné nebo jasové rozmezí. Klíčování je bezpochyby jednou z nejdůležitějších součástí virtuálního studia. Bez dobrého klíčování nemůže mít virtuální studio v praxi úspěch. Barevné klíčování odstraní ze snímku pořízeného reálnou kamerou barvu klíčovací plochy. Je to velmi složitý proces, jenž využívá rozvinutých matematických funkcí jako např. Fourierovy transformace, rozpoznávání hran apod. Doslova noční můrou všech výrobců klíčovacích algoritmů jsou kudrnaté vlasy, neboť odstranění klíčovací barvy z bodů u vlasů, které mohou být i velmi tenké (třeba jen pixel nebo dva), je velmi náročné. Klíčování se dnes běžně dodává do všech profesionálních režisérských pultů. Takový pult bohužel k dispozici nemáme, a proto se zde budeme klíčováním zabývat podrobněji. Samozřejmě není vhodné chodit do studia v oblečení či s věcmi, jež jsou barevně blízké barvě klíčovací plochy (pokud to není záměr). V praxi se vždy před zavedením nového studia konají zdlouhavé kostýmové zkoušky, kde se přezkouší veškeré oblečení ze šatny, aby při vysílání nedošlo náhodou k nemilému překvapení a moderátor se v obraze neobjevil průhledný.
5
2.1.4 Systém sledování pohybu Systém sledování pohybu je další nedílnou součástí virtuálního studia. Tento systém sleduje pohyb a rotaci reálných studiových kamer a převádí je na informaci, která slouží k řízení odpovídajícího pohybu a rotace virtuální kamery. Při pohybu reálné kamery se tak příslušně pohne i virtuální kamera a změní se pozadí, které je zde místo klíčovací barvy, aby vznikl dojem, že virtuální pozadí do scény patří. Přitom velmi záleží na přesnosti celého systému. Sledovat pohyb kamer lze různými způsoby. Existují dva základní druhy sledování pohybu kamer: • studio založené na senzorech • studio založené na rozpoznávání obrazu První druh je nejpoužívanější systém sledování pohybu, který se uchytil ve většině virtuálních studií. Jak ukazuje obr. 4, na kameře jsou umístěny senzory, které přesně sledují její pohyb a to na několika místech. Sleduje se jak translace kamery, tak i její rotace po obou osách, ve kterých stativ dovoluje otočení. Jako poslední se sleduje objektiv kamery pro informaci o aktuálním přiblížení (zoomu). Druhou možností na obr. 5 je rozpoznávání obrazu, u kterého není třeba senzorů, ale speciálního klíčovacího pozadí (obr. 12) Například firma Orad nabízí sledovací systém na bázi monitorování LED-diod pomocí dvou kamer umístěných na stropu studia a na tzv. gridu neboli čtvercové mřížce, instalované bezprostředně vedle modré plochy. Tak se zjistí přesná poloha kamer ve studiu a umožní se jejich volný pohyb [1]. Je to tedy kombinace obou druhů. Tuto technologii používá v praxi například česká televize Prima, která s ní donedávna vysílala Zpravodajský deník a 1. Zprávy a dnes ji využívá i pro jiné druhy pořadů.
6
2.2 Základní schéma virtuálního studia Podle použité technologie pro sledování pohybu kamery lze rozlišovat dvě základní schémata [2]: Studio založené na senzorech (sensor based system):
obr 4. virtuální studio založené na senzorech, zdroj: [2]
Studio založené na rozpoznávání obrazu (pattern-recognition system):
obr 5. virtuální studio založené rozpoznávání obrazu, zdroj: [2]
7
2.3 Cíle Cílem této práce je navrhnout otevřený systém virtuálního studia na základě dostupných informací a praktických zkušeností. Tento systém bude obsahovat všechny základní prvky virtuálního studia, jak byly popsány výše. Nebude se však snažit dosáhnout profesionální kvality ve všech ohledech. Důraz bude kladen především na funkčnost systému jako celku. Každou část bude později možné snadno vyměnit za dokonalejší či přesnější. Záměrem je jednak vytvořit část systému, která se bude starat o přijímání snímků z kamery a jejich převedení do srozumitelného formátu (dekódování). Dalším úkolem je vytvoření části systému pro načtení 3D modelu scény a její následné vykreslení. Nedílnou součástí práce bude klíčovací algoritmus, který zbaví reálný obraz jedné barvy, a posledním cílem je zkonstruovat sledovací zařízení, monitorující pohyb reálných kamer. To vše by mělo spolupracovat v jednom programu, jehož kód bude poté volně přístupný.
8
3 Analýza a návrh virtuálního studia Virtuální studio se jako systém bude skládat z výše uvedených součástí. Následující schéma na obr. 6 ukazuje propojení různých částí studia.
STUDIO
K1
…
KN
sledování pohybu kamer
…
…
výpočet pozice
klíčování a skládání obrazu
K1 - KN
K1 - KN
…
… 3D scéna
…
režie – výběr hlavního obrazu
divák
obr. 6 návrh schématu zapojení virtuálního studia
Přenos dat v systému znázorňuje obr. 7, kde je snímek kamery přenášen do klíčovací části a spojován se snímkem z virtuální scény. Ten se obdrží tak, že systém sledování pohybu
9
nejprve vyhodnotí pozici a rotaci kamery a tuto informaci přenese do virtuální scény; ta pak následně vykreslí obraz z obdržených souřadnic. Z obrazu ze scény se odstraní klíčovací barva a spojí se s obrazem z virtuální scény, tak že místo vyklíčovaného pixelu zaujme pixel z virtuálního pozadí.
systém sledování pohybu kamer kamerový systém a scéna
pozice, rotace (transformační matice) obraz (snímek) z kamery obraz z virtuální scény klíčování a skládání obrazu
virtuální scéna
složený obraz
výsledný obraz
obr 7. datové přenosy v systému
Důležitou roli zde hraje rychlost celého systému. Veškeré objekty musí pracovat co nejrychleji, aby se minimalizovalo zpoždění. To je důležité především pro klíčování, systém sledování pohybu a výpočet obrazu (render) scény, což jsou časově nejkritičtější části studia. Máme zde tedy minimální prostor pro hlídání a odchytávání různých výjimek a chyb. Dostačující bude hlášení o chybě na výstup programu (do konzole). Dále prozkoumáme možnosti výpočtu dat mimo hlavní procesor. Existují například způsoby, jak přesunout klíčování z hlavního procesoru na grafickou kartu a tak ušetřit drahocenný čas. Aplikace bude mít výstup na obrazovku monitoru, kde budou viditelné všechny její vstupy a výstupy. Obdržíme tedy obraz z kamery, obraz z virtuální scény a výsledný složený obraz jich obou jak ukazuje obr. 8.
10
výstup kamery
výstup 3D scény
výstup virtuálního studia (spojení obrazu z kamery a 3D scény)
obr. 8 návrh základního výstupu na obrazovku
3.1 Návrh implementace Dále je třeba vybrat, jakým způsobem se celý systém naimplementuje. Existuje několik možností, některé odvozené i z praxe. Např. firma Orad implementuje své virtuální studio jako zásuvný modul do 3D Studia Max. Problémem je zde především závislost na komerčním prostředí, které celý systém prodraží. Pokud bychom chtěli jít s dobou a pořizovat si nové verze 3D Studia, museli bychom si dokupovat i příslušný zásuvný modul, což je velmi nákladné. Výhodou je, že se pracuje ve 3D prostředí a je k němu přímý přístup. Nebylo by tedy potřeba implementovat načítání a práci s 3D scénou. Další výhodou je, že novější 3D Studia dovolují pracovat přímo s grafickou kartou, což urychluje výpočet. Přístup má tedy několik výhod i nevýhod, ovšem tato práce se zabývá otevřeným virtuálním studiem, kdy spojení s jakýmkoli komerčním softwarem není možné. Existuje i nekomerční 3D software (například Blender). Přesto závislost na jiném softwaru není vhodná. Bude tedy třeba zvolit vlastní implementaci. Nabízí se hned několik programovacích jazyků. Např. Java by mohla nabídnout mnoho hotových knihoven a především přenositelnost mezi operačními systémy. Proti jejímu použití ovšem mluví nedostatečná rychlost. V poslední době se situace zlepšila, přesto existuje ještě rychlejší možnost, a tou je jazyk C/C++. Dobré je, že v něm existuje také mnoho knihoven, které by bylo možné využít, některé dokonce i pro více systémů. Pokud se bude využívat programovací jazyk C/C++, je nutné vybrat API pro práci s obrazem a render. Zde se nabízejí dvě možnosti: OpenGL či DirectX. I přes podobné možnosti obou API je jasná volba OpenGL, především z důvodu přenositelnosti mezi operačními systémy a rovněž lepší dokumentace.
11
Bylo by také vhodné, aby se systém skládal z částí podporujících oba nejrozšířenější operační systémy – Linux a Windows. Vstup systému by měl být jakýmkoli způsobem nastavitelný. Především by mělo být možné nastavit následující parametry: •
počet vstupních kamer (příp. souborů), jejich kodek a přenosové médium
•
cesta ke scéně
•
rozlišení snímků v pixelech, které bude celý systém používat
•
fps – počet snímků za sekundu
•
možnosti klíčování
•
přiřazení reálných kamer ke kamerám virtuálním
3.2 Návrh částí Zde si popíšeme, jak bude každá část virtuálního studia navržena.
3.2.1 Kamerový systém a scéna Základem každého televizního studia jsou kamery a scéna. Tento systém virtuálního studia neklade žádné požadavky na kamery. Musí být pouze umožněna komunikace s počítačem a příjem snímků, což umožňuje snad každá digitální kamera. Systém bude navržen tak, aby podporoval základní formát komunikace přes firewire, což je u kamer nejrozšířenější rozhraní. Kamery dále pracují ve standardu PAL nebo NTSC. Další možnosti komunikace, např. přes USB, nebude obtížné do aplikace doprogramovat, protože bude obsahovat abstraktní třídy a bude třeba zasahovat pouze do malé části programu. Stejně tomu bude i s jinými formáty, jako např. full HD a další. Problém by mohl nastat při kombinaci těchto formátů, například PAL a NTSC nebo full HD, kde by bylo obtížné zkombinovat formáty dohromady. Při spuštění programu si tedy bude nutné vybrat, jaký formát se bude používat, případně bude nutné použít všechny kamery stejného standardu. Kamerový systém bude navržen v duchu objektového programování. V programu bude vystupovat abstraktní třída, u níž se budou volat stejné metody při jakékoli kombinaci standardu nebo typu komunikace. V pozadí této třídy již bude několik tříd, které se budou starat o přenos dat a dekódování snímků. Na scénu rovněž nejsou kladeny nijak velké požadavky. Důležité je především dobré nasvícení klíčovací plochy, jež je podmínkou dobrého klíčování.
3.2.2 Virtuální scéna Po výběru programovacího jazyka a API je nutné zvolit si způsob práce s virtuální scénou. Vzhledem k tomu, že virtuální studio se nebude používat jen jednou, se jako nejvhodnější ukazuje načtení z externího souboru, aby se při každé změně nemusel překládat 12
celý program znovu. Existuje mnoho formátů 3D scén, ne všechny jsou ovšem ideální. Takový formát by měl především pojmout geometrii scény, materiály (textury) i světla. Také by měl mít možnost obsahovat nějaké animace nebo skripty (což není podmínkou, ale v kladném případě velkou výhodou). Dále by tento formát neměl být uzavřený, aby se s ním dobře pracovalo. Rovněž by mělo být možné exportovat do tohoto formátu z různých 3D aplikací, které by umožnily rychlé a praktické sestavení scény. Pěknou možností je formát .3ds, který používal ve svých začátcích software 3D Studio. Formát obsahuje jak geometrii, tak textury a světla. Bohužel neumožňuje animaci a je binární, takže se špatně upravuje, resp. je možné ho upravit pouze v 3D softwaru. Je celkem široce podporovaný velkou řadou softwarů, jako jsou 3D Studio, Maya, Blender a jiné. Je to formát velmi starý, vznikal kolem roku 1990 a má tedy některá omezení. Každý objekt se může skládat maximálně z 65 535 vrcholů, má omezení ve jménech objektů, načítaných textur a neobsahuje směrová světla. Další možností je formát VRML (Virtual Reality Modeling Language), který se používá především na internetu. Stejně jako .3ds obsahuje také geometrii, textury i světla a umožňuje objekty animovat. Výhodou oproti .3ds je především to, že tento formát je čitelný v každém textovém editoru a je možné ho upravovat. Podpora u modelovacích softwarů je velmi podobná jako u .3ds. Formát pochází z roku 1997 a existuje i jeho novější verze X3D s dalším rozšířením. Mnoho dalších formátů, jako .obj, .max, .3dm, .c4d, .mb, .fbx aj., zde neprošly proto, že jsou buď závislé na jednom druhu softwaru, nebo nesplňují jinou podmínkou uvedenou výše. VRML je grafický formát pro popis 3D scén. Soubor je napsaný v jazyce, který je snadno čitelný a jednoduše upravitelný v jakémkoli textovém editoru. Primárně je určen pro internet a WWW, ale je možné ho použít i mimo něj. V dnešní době má svého nástupce a to X3D, které z něj vychází. Struktura VRML je založena na uzlech (nodes). Uzly se dělí na statické • • • • • •
geometrické popis geometrických parametrů – tvaru a velikosti objektů vlastností definice vlastností objektů – normály, souřadnice vzhledu popis povrchu objektů – materiály, textury světel a zvuků definice různých druhů světel a zvuků speciální popisují uzly pro zvláštní použití – odkaz, úroveň detailu atd. skupinové uzly sdružující jiné uzly do skupin a dynamické
•
interpolátory
13
převádějí vstupní hodnotu, jíž je reálné číslo, na hodnotu jiného typu, a to podle průběhu nadefinované lineární funkce •
manipulátory umožňují jednoduše převádět posuvný pohyb myši na pohyb geometrického objektu
•
senzory generují výstupní události jako reakci na specifické situace, které jsou důsledkem činnosti avatara (postava procházející scénou) [5]
Soubor VRML se skládá z výše uvedených uzlů. Jako první se vkládá do souboru komentář, v němž je definována verze VRML a kódování: #VRML V2.0 utf8 Dále je možné definovat informace o scéně v uzlu WorldInfo (název, informace) nebo o avatorovi v NavigationInfo (nastavení avatara, přední světlo): WorldInfo { title „3D scéna“ info „Autor: Jan Charvát, 2009“ } NavigationInfo { headlight FALSE } Důležitým uzlem je ViewPoint neboli kamera. Ta se definuje jménem, pozicí (x, y, z), a rotací (x, y, z, hodnota), dále je možné přidat FOV (field of view) nebo popis: DEF Cam1View Viewpoint { position 1 2 4 orientation 0 1 0 3.14 description "View: Camera 1" } Zde si uvedeme krátký přiklad scény se čtvercem i výsledným obrazem:
14
#VRML V2.0 utf8 #Box, Copyright (c) 2009 by: Jan Charvat DEF Cam1View Viewpoint { position 0 0 5 orientation 0 0 0 0 description "View: Camera1" } Group { children Shape { geometry Cylinder { radius 1 height 1 } appearance DEF A1 Appearance { texture ImageTexture { url "zluta.jpg" } material Material { diffuseColor 1 1 1 } } } }
obr. 9 příklad VRML scény
Pro virtuální studio je tedy ideální formát VRML. Výhodou také je, že existují knihovny pro načtení i render VRML scén.
15
3.2.3 Klíčování Klíčování je pro virtuální studio velmi důležitou součástí a jeho aplikace je časově velmi náročná. Lze říci, že je dnes dobře prostudovanou oblastí a existuje pro ně mnoho algoritmů. Cílem této práce není navrhnout profesionální klíčovací algoritmus, který by zvládal klíčování sebezakroucenějšího vlasu nebo vousu, nýbrž poskytnout prostor pro jeho tvorbu či případně aplikaci již známého algoritmu. Bohužel ne všechny klíčovací algoritmy jsou dostupné. Tato práce uvádí základní klíčovací algoritmus, jejž bude možné v budoucnu nahradit sofistikovanějším algoritmem bez větších změn v kódu, nebo ideálně výměnou souboru. Vzhledem k časové náročnosti je vhodné přesunout výpočet z hlavního procesoru jinam. V praxi se používá přímo speciální oddělený stroj, který vstupní obraz zpracuje a vyklíčuje. V dnešní době se nabízí podobná možnost, a sice nikoli v podobě odděleného stroje, nýbrž jiného procesoru. V současné době grafická karta dosahuje vysokých výkonů, a to především při zpracování obrazu. Je k tomu totiž speciálně vybavena několika desítkami paralelních procesorů, jež zpracovávají velký objem dat najednou. Je možné využít tzv. shaderů, což jsou programovatelné součásti grafické karty, které se starají jak o geometrii (vertex shader), tak o barvu pixelů (fragment shader). Do těchto částí je možné naprogramovat libovolný algoritmus. Vzhledem k tomu, že systém bude pracovat s OpenGL, je nejvhodnější využít jazyka GLSL (openGL Shading Language). Zde nebude nutné pracovat tolik s geometrií, ale především s pixely. Bude tudíž důležité napsat algoritmus do fragment shaderu. Protože jde o velmi specializované procesory, má i GLSL svá omezení a není možné použít jej na cokoli. Zde ovšem půjde o to zjistit, zda pixel z reálné kamery patří do klíčovací plochy, odstranit jej a nahradit pixelem z virtuální scény. Toto prostředí je vhodné pro základní klíčovací algoritmus. To jestli je možné ho použít i na pokročilejší algoritmy není možné bez jejich znalosti posoudit. Ale je to velmi rychle se rozvíjející odvětví a lze tedy očekávat, že vývoj půjde rychle dopředu a možností bude stále přibývat. GLSL je vyšší programovací jazyk, který je odvozen od jazyka C. Byl vytvořen skupinou OpenGL ARB, která sdružuje největší výrobce grafických karet s cílem umožnit výrobcům grafických aplikací větší kontrolu nad grafickou pipeline. Dovoluje převzít kontrolu na úrovni vertexů a fragmentů, což je vidět na obr. 10.
16
vertex shader
fragment shader
obr. 10 schéma popelíne na grafické kartě s vyznačením vertex a fragment shaderu
Původně se tyto programy psaly v jazyce podobném assembleru, jenž byl specifický pro každého výrobce grafické karty. OpenGL ARB proto vyvinula OpenGL Shading Language, který je stejný pro všechny výrobce. Další výhodou je, že funguje pod všemi operačními systémy (Windows, Linux, Mac OS). GLSL má mnoho operátorů stejných jako v C/C++, až na bitové operace a ukazatele. Lze také využít cyklů a větvení programu, tedy if, else, if/else, for, do-while, break, continue apod.
17
Příklad uvedený níže ukazuje jednoduché základní shadery. Zde je vidět, že tím, že se uvolní fragment a vertex shader pro vývojáře, je vždy potřeba doprogramovat alespoň jejich základní funkci. Pro vertex shader je to přenásobení vertexu ModelView a Projekční maticí a pro fragment shader je to přiřazení barvy. Vertex Shader: varying float xpos; varying float ypos; varying float zpos; void main(void) { xpos = clamp(gl_Vertex.x, 0.0, 1.0); ypos = clamp(gl_Vertex.y, 0.0, 1.0); zpos = clamp(gl_Vertex.z, 0.0, 1.0); gl_Position = gl_ModelViewProjectionMatrix * gl_Vertex; } Fragment Shader: varying float xpos; varying float ypos; varying float zpos; void main (void) { gl_FragColor = vec4 (xpos, ypos, zpos, 1.0); }
obr. 11 krychle obarvená pomocí fragment shaderu
Základní algoritmus klíčování pouze rozeznává barvu pixelů a podle celé řady nastavitelných proměnných posuzuje, zda pixel vyhovuje danému rozsahu barvy, a případně
18
ho vymění za pixely z virtuální scény. Bylo by ještě vhodné tento základní algoritmus doplnit například o rozeznávání a hran, které by napomohlo rozhodování.
3.2.4 Systém sledování pohybu Virtuální studio potřebuje především přesný systém sledování pohybu. V této práci není cílem snažit se vytvořit naprosto přesný a dokonalý sledovací systém, nicméně vytvoříme zde funkční verzi, kterou bude možné kdykoli vyměnit za profesionální systém. Například firma Vicon [3] se zabývá sledováním pohybu v prostoru (motion capture). Její produkt Vicon MX představuje systém, který je schopen sledovat pohyb objektů v prostoru pomocí kamer a speciálních bodů (markerů), jež kamery sledují. Základem produktu Vicon MX jsou kamery, které mohou snímat až několik set markerů v plné kvalitě, a to v řádech stovek snímků za sekundu. Kamery mají okolo sebe zdroj světla (viditelného, téměř infračerveného nebo infračerveného), jež se odráží na markerech zpět do snímající kamery. Markery musí velmi dobře odrážet světlo do všech směrů a mají proto podobu lesklých pingpongových míčků. Celý systém se skládá z několika kamer snímajících markery. Před každým měřením je nutné systém nakalibrovat pro aktuální rozestavení kamer. Systém je velmi výkonný, ale také velmi drahý. Jako příklad uvádí výrobce systém 8 kamer spolu s potřebným vybavením v ceně cca $200 000. Další možností by mohlo být sledování pohybu kamer přímo z obrazu, který přijímají. Znamenalo by to vytvoření takového klíčovacího pozadí, které by se nikde neopakovalo viz obr. 12 a bylo přizpůsobeno algoritmům rozpoznávajícím obraz. Scéna by pak musela být ještě lépe nasvícena, než je běžné, neboť kvalita obrazu získaného z kamery musí být co největší. Bylo by to také velmi náročné na klíčovací algoritmus, který by musel rozeznávat barvy informačního objektu od klíčovací barvy. V neposlední řadě by to velmi zaměstnalo procesor, protože ten by musel analyzovat celý obraz a vypočítat z něj pozici, což by se mohlo stát kritickým místem aplikace.
obr. 12 Pozadí virtuálního studia pro systém rozpoznávání obrazu
19
Pro tento systém se jeví jako ideální sledování pohybu bodů, které budou mechanicky spojeny s kamerou. Jak se tedy pohne kamera, tak se budou pohybovat i tyto body. Bude je sledovat kamera a zaznamená jejich pozici na svém projekčním plátně. Z této informace je následně možné dopočítat transformační matici jakéhokoli bodu od kamery [3], což je přesně to, co nás zajímá. Jedinou nevýhodou je, že takový systém nedává informaci o velikosti zoomu kamery. Body, které se budou sledovat, by měly být dobře rozpoznatelné a neměly by rušit okolí. K tomuto je možné použít malé a výkonné LED diody. Ideální je využití infračervených diod, které nijak neruší. Kamery, které budou snímat pohyb bodů, by měly mít co nejvyšší rozlišení pro rozeznávání i nepatrných pohybů. Samozřejmě platí: čím větší rozlišení, tím vyšší náklady.
3.3 Návrh fyzických součástí Návrh pole bodů, pro každou kameru Podle algoritmu, který dopočítává transformační matici tohoto pole bodů, je třeba navrhnout i strukturu senzoru. Algoritmus vyžaduje na vstupu minimálně 3 body, jejichž vektory jsou bází prostoru. Příkladem mohou být následující pozice 3 bodů (osy X, Y, Z): 1: (1, 0, 0), 2: (0, 1, 0), 3: (0, 0, 1) Pole bodů bude muset být podobné základním třem osám prostoru. Zdrojů infračerveného světla je mnoho, např. klasické žárovky, LED diody, svíčky a mnoho dalších. Pro tento systém se jeví jako ideální právě infračervené LED diody, které neruší okolí, neboť pracují jen v infračerveném spektru. Jsou většinou napájeny 1,5V napětím, což dovoluje použít k napájení například baterii AA nebo AAA. Problémem u diod může být jejich vyzařovací úhel, který by mohl být příliš malý. V tom případě je možné použít více diod. Na obr 13. je návrh zapojení senzoru.
obr. 13 schéma zapojení IR LED diod senzoru
20
4 Realizace Implementace částí probíhala postupně. Jako první vznikl vstupní kamerový systém, dále přišlo na řadu klíčování, poté virtuální scéna a nakonec sám systém sledování pohybu. Celé virtuální studio je psáno v jazyce C/C++ s důrazem na objektové programování, aby se dosáhlo co největší modularity. Celá aplikace používá více vláken a snaží se tedy co nejvíce využít procesorového času. Některé úlohy by ani bez toho nebylo možné implementovat, protože se u nich čeká na vstup. Aplikace má výstup na obrazovku monitoru. Pro každou kameru jsou zde 2 vstupy a 1 výstup (obr. 14). Při větším počtu vstupů než pojme obrazovka, se GUI adekvátně zmenší.
výstup kamery
výstup 3D scény
výstup virtuálního studia (spojení obrazu z kamery a 3D scény)
obr14. GUI
21
4.1 Implementace částí Každá část byla implementována jako soubor jednoho či více abstraktních objektů, které se starají o její funkčnost bez ohledu na to, co se pod ním skrývá. Proto je možné použít stejný kód jak pro Linux, tak pro Windows. Některé části využívají již hotové knihovny. Pro správu oken a komunikace se systémem se využívá GLUT, což je API, s nímž je možné vytvořit okno a odchytávat stisknuté klávesy nebo pohyb myší. Na obr. 15 je class diagram celého virtuálního studia (větší obrázek je přiložen na CD viz kapitola 7).
obr. 15 class diagram
22
4.1.1 Kamerový systém a scéna Zde se podstatně liší implementace pod Linuxem a Windows. Zatímco ve Windows nabízí Microsoft své API pro multimediální programy, v Linuxu zatím takové rozhraní není, ale existují knihovny, které se starají o různé části přenosu a dekódování V Linuxu je prvním krokem příjem snímku z kamery přes firewire rozhraní. To zajišťuje třída cameraio, což je pouze abstraktní třída, s jejíž pomocí se definují další již specializované třídy. Má jedinou virtuální metodu saveframe(), kterou si každá specializovaná třída nadefinuje sama a jež slouží k příjmu snímku a jeho uložení do bufferu. V této práci jsou dva tzv. potomci této třídy, jeden pro příjem přes firewire a druhý pro načítání video streamu přímo z pevného disku. Třída fileio je především pomocná pro testování v případech, kdy není k dispozici kamera. Tato třída implementuje pouze otevření souboru. Jako jediný potomek je zde implementována třída dvfileio, která se stará o načtení snímků z DV souboru na pevném disku. Kdykoli je možné přidat bez většího zásahu do programu další třídy pro příjem jiných druhů formátů. Druhá třída firewireio využívá knihovnu libiec61883 [4], což je rozhraní pro přenos, příjem a správu multimediálních streamů a zařízení jako DV, MPEG2-TS, audio a MIDI přes firewire. Podporuje i HD-DV, které by se mohlo využít s novými generacemi kamer. Příjmu snímku je věnováno jedno vlákno – přijímací, aby nedocházelo ke zbytečnému čekání, a také dva buffery o velikosti jednoho snímku, které zrychlují práci s příjmem dat. Třída naváže spojení se zařízením, a pokud je spojení v pořádku, začne přijímat snímky. Nejdříve přijme snímek, zkontroluje, zda je v pořádku, a poté ho uloží do 1. bufferu, kde na něj již čeká další dekódovací vlákno. Přijímací vlákno po zápisu do 1. bufferu přehodí ukazatel na 2. buffer a čeká na další snímek; to celé se pak zopakuje. Všechny operace se sdílenými prostředky jsou zajištěny pomocí tzv. semaforů a mutexů, jež se starají o to, aby ve sdíleném prostoru bylo pouze jedno vlákno a nedocházelo k chybám nebo dokonce pádům programu. Dalším krokem je dekódování snímku, jemuž je rovněž věnováno jedno vlákno – dekódovací. Toto vlákno nejprve čeká na příjem snímku do 1. bufferu, a když přijímací vlákno zapíše celý snímek, dekódovací vlákno jej začne dekódovat. K dekódování slouží třída framedecoder, která implementuje správu 3 bufferů (dva pro příjem snímku, jak popsáno výše, jeden pro výstup dekódovaného snímku). Kromě toho má jednu virtuální metodu decodeframe(), která dekóduje přijatý snímek. Tuto metodu opět implementují až potomci této třídy. Jedním z nich je třída dvdecoder, která v této metodě dekóduje snímek z formátu DV do posloupnosti pixelů, vyjádřených jako hodnoty RGB. K dekódování snímku využívá knihovnu libDV [5]. Po dokončení dekódování uvolní výstupní buffer a začne dekódovat snímek ve 2. bufferu. Celý systém přijmu dat z kamery ukazuje obr. 16. Dekódovaná data si přebírá třída inputcamera, která je hlavním vstupní třídou. Stará se o obě vlákna, jak přijímací, tak dekódovací, a rovněž vytváří z přijatých dat texturu, která se pak dále zpracovává v grafické kartě. V programu se vytvoří tolik instancí třídy inputcamera,
23
kolik je na vstupu dohromady kamer a souborů. Podle nastavení parametrů v konstruktoru se pak vytvoří různé typy vstupních instancí. Příkladem může být InputCamera(0, DV_DECODER, FIREWIRE_IO, 720, 576); Zde se vytváří instance, jež bude komunikovat přes rozhraní firewire a kanál 0 s tím, že jde o DV stream s rozlišením 720 x 576. Dalším příkladem může být InputCamera("data/a.dv",DV_DECODER, FILE_IO, 720, 576); Zde je volán konstruktor s parametry, jež definují to, že se bude načítat ze souboru z disku, a jméno souboru, z kterého se bude načítat. Také půjde o DV stream se stejným rozlišením 720 x 576. Celý kamerový systém končí právě třídou inputcamera, kde jsou všechna data přijata ze vstupů a převedena do formy, kterou využijí další části virtuálního studia. U Windows je naprosto jiná výchozí situace. Microsoft nabízí multimediální API DirectShow, jež dovoluje pracovat velmi podobným způsobem jak s kamerami, tak se soubory. Je založena na Microsoft Windows Component Object Model (COM). Celý systém funguje na principu filtrů neboli objektů se vstupy a výstupy, které je na sebe možné navazovat. Dovoluje pro tento systém důležité spojení s kamerou a přenos snímků a také následné dekódování. Využívá vícevláknový přístup, stejně jako vlastní implementace v Linuxu. Celé to opět zajišťuje třída inputcamera, stejně jako v Linuxu. Není proto nutné měnit kód, jenž tuto třídu využívá. Nejdříve je třeba inicializovat COM, poté podle potřeby se buď naleznou připojené kamery, nebo soubor z disku. Následně se sestaví graf podle obrázku výše a příslušné filtry se mezi sebou propojí. Při každém požadavku na snímek filtr pSampleGrabber přečte data v aktuálním bufferu, do nějž byl snímek přijat, a zkopíruje jej do bufferu třídy inputcamera.
24
Virtual:: onInit() InputCamera()
readThreadFc()
čekat na volný buffer a zabrat jeden buffer na příjem
IO->saveFrame()
decodeThreadFc()
test konce příjmu snímků
čekat na volný buffer a zabrat jeden buffer na
uvolnit jeden buffer na dekódování
decoder ->setDecodeBuffer()
test konce příjmu snímků
decoder ->decodeFrame()
decoder ->swapBuffers()
uvolnit jeden buffer na přijem dat
test konce programu
test konce programu
obr. 16 vývojový diagram kamerového systému
4.1.2 Virtuální scéna Virtuální scénu zajišťuje třída scene3d. Stará se o načítání scény ze souboru na disku a o její následné zpracování a render. Pro soubory virtuální scény se využívá formátu VRML, který má všechny potřebné vlastnosti, je navíc srozumitelný, lehce upravitelný a umožňuje rovněž skriptování. Většina 3D modelovacích programů umožňuje export do VRML, takže je možné je pro jejich sestavení použít, což ušetří čas při tvorbě. Základem práce se scénou ve VRML je knihovna OpenVRML [6], která dokáže pracovat se soubory VRML/X3D. Umí je jak načíst a zpracovat, tak i vyrenderovat. Zde se pracuje s verzí 0.17.10. Konstruktor třídy scene3d inicializuje třídy z této knihovny či odvozené z jejich tříd – OVViewer, openvrml::browser a resource_fetcher. OOViewer dědí 25
od třídy openvrml::gl::viewer a umožňuje renderování z VRML souboru. Pokud je k dispozici více kamer ve scéně (viewpointů), vybere se vždy před renderováním ta, z které se má renderovat a z ní se provede vykreslení. Resource_fetcher se stará o načítání souboru do programu. Pomocí třídy openvrml::browser je možné procházet strukturu VRML souboru a dostat se přímo na uzly. Zde se využije především přístupu ke kamerám. Browser obsahuje odkaz na fetcher a pomocí metody load_url(uri, parameter) se do něj vloží scéna VRML. Zde je důležité vědět, že OpenVRML trvá určitou dobu, než soubor načte, a dokud neskončí, není možné se scénou pracovat bez rizika pádu programu. Knihovna OpenVRML sama o sobě nemá žádnou proměnnou, která by to naznačila, proto byly do konstruktoru zařazeny dvě čekací smyčky: while (b.root_scene() == 0){} while (b.viewpoints().size() != viewpointNumber) {}
První čeká na to, až se nastaví kořen scény, což bohužel nestačí a je proto nutné počkat, než se načtou všechny kamery. Teprve pak je možné s nimi pracovat. Po vytvoření instance třídy scene3d je připravena scéna, ale implicitně neobsahuje žádné kamery. Obsahuje prázdné pole virtuálních kamer, jež zajišťuje třída camera, a do něj se instance kamer postupně přidávají pomocí příkazu: int addCamera(unsigned int id, unsigned int frameWidth, unsigned int frameHeight, int viewpointNumber)
Prvním parametrem je identifikační číslo, kterým se kamery rozpoznávají. Další dva parametry určují šířku a výšku snímku. Posledním je číslo (pořadí) kamerového uzlu v souboru VRML, k němuž se virtuální kamera přiřadí. Každá kamera ve scéně má svou instanci třídy camera. Ta zajišťuje komunikaci se sledovacím zařízením a také uchovává vyrenderovaný snímek z kamery ve virtuální scéně (data a texturu). Pomocí metody void trackCamera(unsigned int viewpointNumber) se přijme transformační matice ze systému sledování pohybu pro danou virtuální kameru a aplikuje se na ni pomocí metody void transformCamera(unsigned int viewpointNumber, const float transform [16]). Pokud je sledovací zařízení nakalibrované a přesné, pohne se virtuální kamera přesně tak jako kamera reálná a výsledný obraz bude vypadat přirozeně. Důležitou metodou je rovněž metoda void renderToFBO(int i), která slouží k renderu snímku z virtuální kamery do textury (obr. 17). Tato textura poté vstupuje do klíčovacího procesu jako textura, jíž se nahrazují vyklíčované pixely. V první části metody se na zásobník uloží aktuální stav projekční a modelovací matice, a tento stav se na závěr metody opět vrátí ze zásobníku. Zde se právě využívá poměrně nové technologie na grafických kartách, jíž je tzv. FBO (Frame Buffer Object). Dovoluje renderovat přímo do textury bez přídavných bufferů či zpomalení. Je to velmi efektivní metoda pro zpracování obrazu, který ještě nemá být vykreslen na displej. Její funkčnost zajišťuje třída jménem fbo. Před renderem do textury se inicializuje pomocí volání metody beforedraw(), a poté, co se obrázek vyrenderuje, se vše opět vrátí do původního nastavení pomocí metody afterdraw(). Snímek se vykresluje pomocí metody void render(int i), kde se
26
nejdříve nastaví aktivní virtuální kamera ve scéně, podle proměnné i, a potom, pokud je splněna podmínka existence browseru, je vydán příkaz knihovně OpenVRML, aby překreslila snímek a provedla update scény. Metoda void renderFBO(int i) pouze renderuje na aktuální viewport texturu, která je v FBO kamery s id=i. Virtual:: draw() scene ->renderToFBO(i) vložit na zásobník projection matrix vložit na zásobník modelview matrix cameras[i] ->beforeFBODraw() smazání color bufferu a depth bufferu render(i) vybrat aktivní viewpoint v OpenVRML
vykreslení scény
cameras[i] ->afterFBODraw()
vybrat ze zásobníku modelview matrix
vybrat ze zásobníku projection matrix obr. 17 schéma výpočtu virtuální scény
4.1.3 Klíčování Pro klíčování je zde třída colorkey. Třída se stará o to, aby se data z textur dostala do grafické karty, a nastavil se a spustil shader, který je napsaný v jazyce GLSL. Se shadery pracuje třída
27
shader, jejíž instanci obsahuje třída colorkey. Každý barevný klíč má tedy jeden shader, který klíčování zařídí. Existují dva druhy shaderů. Prvním je fragment shader, druhým vertex shader. Oba dva jsou umístěny v souborech na disku v normálně čitelných souborech s kódem. Následující postup přípravy shaderu (obr. 18) je v konstruktoru třídy shader a je volán při tvorbě každé její instance. Prvním krokem při práci se shadery je jejich načtení do programu. Každý shader se načte jako pole znaků. Pomocí funkce GLuint glCreateShader (GLenum shaderType) se vytvoří dva prázdné shaderové objekty, jeden s parametrem GL_VERTEX_SHADER pro vertex shader a druhý s parametrem GL_FRAGMENT_SHADER pro fragment shader. Následuje vložení načteného kódu do objektu shaderu a jeho přeložení. Po přeložení je vhodné se přesvědčit, zda překlad dopadl dobře, a zjistit případná varování nebo dokonce chyby. K tomu slouží funkce void printShaderInfoLog(GLuint obj) s parametrem v podobě shaderového objektu. Funkce vypíše všechna varování i chyby včetně čísla řádku, v němž se nacházejí. Pokud je vše v pořádku, lze vytvořit prázdný program GLuint glCreateProgram (void), k němuž se poté připojí přiložené shadery. Po přidání shaderů do programu zbývá program nalinkovat pomocí příkazu void glLinkProgram (GLuint program). Při linkování se mimo jiné kontroluje, zda lze vertex shader spojit s fragment shaderem, například zda jsou použité souřadnice ve fragment shaderu opravdu ve vertex shaderu inicializovány, apod. Posledním krokem je kontrola, zda nalinkování proběhlo správně příkazem printProgramInfoLog (GLuint program), ten vypíše všechna varování i chyby při linkování. Pokud se ani zde neukáží žádné chyby, shader je připraven na použití.
glCreateProgram
glAttachShader(VS)
glAttachShader(FS)
glLinkProgram
glUseProgram
obr. 18 schéma vytváření shaderu
Základní shader pro tento systém se nazývá chroma key a má za úkol odstranit co nejvíce klíčovací barvy. Pracuje se po pixelech. Prvním krokem je převod pixelu z reálné kamery z barevného prostoru RGB do prostoru HSV. Dále se provede lokální rozmazání obrazu (blur) z 9 bodů (1 vybraný pixel a 8 okolních), aby se odstranil šum. Následuje převod
28
pixelu z virtuální scény z barevného prostoru RGB do prostoru HSV. Poté se nastaví hranice parametrů hue a saturation, v nichž se bude vzorek nahrazovat. Nakonec se podle dalších nastavených parametrů buď pixel nahradí (je to klíčovací barva), nebo se ponechá původní (není to klíčovací barva). Barevný klíč je možné nastavit následujícími parametry: •
float hueFallofT - to je měkký přechod nad rámec hueRangeT
•
float hueFallofB - to je měkký přechod nad rámec hueRangeB
•
float hueRangeT - pravé okolí vybrané Hue
•
float hueRangeB - levé okolí vybrané Hue
•
float hueExpT - manipuluje s hue fallof
•
float hueExpB - manipuluje s hue fallof
•
float saturationRangeT - určuje jaký výsek sytosti okolo vybrané barvy bude klíčovan
•
float saturationRangeB - určuje jaký výsek sytosti okolo vybrané barvy bude klíčovan
•
float satFallof - to je měkký přechod nad rámec saturationRange
•
float satExp
•
vec4 keyColor – barva určená pro vyklíčování
•
float noiseTreshold - rozmezí pro odstraňování šumu
•
float intensityRange
Program je nahraný v grafické kartě a využívá 10 texturovacích jednotek. Je to kvůli lokálnímu rozmazání, které potřebuje celkem 9 vzorků + 1 vzorek z virtuálního snímku. Protože se však na grafické kartě pracuje paralelně, je třeba zabrat všech 10 texturovacích jednotek najednou, ne pouze jednu, ale 10x za sebou. Instance třídy colorkey se vytvoří na začátku programu, a poté se již pouze volá metoda applyColorKey(), která načte textury do grafické karty a nastaví a spustí shader. Do shaderu je možné z programu dodávat informace při jeho běhu. Zde se to využije pro nahrání textur do shaderů. Před každým zpracováním snímku je třeba sdělit shaderu, kde jsou umístěny textury. Ještě před tím je však nutné spustit shader příkazem glUseProgram(GLuint program). Jakmile se shader rozběhne, lze mu předat loc = parametry do proměnné pomocí dvou příkazů. První GLuint
29
glGetUniformLocation (program, paramName) zjistí, kde je v programu hledaná proměnná, a vrátí ji, druhý glUniform1i(loc, value) do ní přiřadí hodnotu, která se nacházi v parametru value. Takto je možné do programu vložit parametry rozličných typů jako int, float, double aj. Pomocí těchto dvou příkazů je tedy třeba pokaždé vložit do programu shaderu číslo texturovací jednotky, v které se textura nachází. Jakmile se tyto informace předají do shaderu, musí se tyto textury dostat do přiřazených texturovacích jednotek. K tomu slouží následující čtyři příkazy: glActiveTexture(GL_TEXTURE0); glClientActiveTexture(GL_TEXTURE0); glEnable(GL_TEXTURE_2D); glBindTexture(GL_TEXTURE_2D, texture[0]); První dva příkazy aktivují texturovací jednotku 0, dalším se umožní používání textur, a posledním příkazem se přiřadí textura do texturovací jednotky. Na rozdíl od klasického přiřazení jedné textury, kdy stačí pouze poslední dva příkazy, je zde ještě nutné specifikovat přesně, ke které texturovací jednotce se textura přiřadí. Druhým voláním níže uvedených příkazů se vloží druhá textura: glActiveTexture(GL_TEXTURE1); glClientActiveTexture(GL_TEXTURE1); glEnable(GL_TEXTURE_2D); glBindTexture(GL_TEXTURE_2D, texture[1]); Zde se aktivuje texturovací jednotka 1 a přiřadí se k ní patřičná textura. Následuje již vykreslení obyčejného čtverce přes celou obrazovku, na nějž se budou textury nanášet. Při ukončení práce se shaderem se deaktivují obě texturovací jednotky, vypne se na nich texturování a zastaví se shader příkazem glUseProgram(0). Celý postup je na obr. 19. Ukončení shaderu je posledním krokem v celém systému. Výstup shaderu záleží na předchozím nastavení. Je možné například opět uložit výsledek do textury nebo nějakého bufferu a znovu jej použít, což by se hodilo při přenosu dat jinam než na aktuální obrazovku. Zde nám ovšem postačí vykreslení na obrazovku. Cesty k shaderům se nastavují v souboru nastavení. Parametry se nastavují přímo v kódu shaderu na začátku fragment shaderu.
30
spuštění shaderu
vložení parametrů
aktivace texturovací jednotky 0
aktivace texturovací jednotky N
aktivace texturování na jednotce 0
aktivace texturování na jednotce N
přiřazení textury 0
přiřazení textury N
vykreslení čtverce přes celý viewport
deaktivace texturování na jednotce N
deaktivace texturování na jednotce 0 zastavení shaderu obr. 19 schéma spuštění shaderu
4.1.4 Systém sledování pohybu Realizace systému sledování pohybu se celá odvíjela od jeho dvou nejdůležitějších částí, a to herního ovladače Wii Remote a algoritmu pro výpočet transformace. Wii od společnosti Nintendo je herní konzole, jež uvedla na trh revoluční ovládání. Ovladač Wii Remote, zkráceně Wiimote, totiž používá nejenom tlačítka, ale i akcelerometr a především pro nás důležitou infračervenou (IR) kameru, jež snímá 2 IR diody umístěné nad nebo pod televizí. Komunikace s Wiimotem probíhá přes rozhraní bluetooth. Přestože Nintendo nikdy nevydalo přesnou specifikaci komunikace, fanoušci této konzole na ni přišli sami a je nyní dostupná volně. Důležité je, že ovladač dokáže sledovat až čtyři IR body najednou. Informace o ovladači [7] nejsou nijak ověřeny, můžeme se jen domnívat, že to tak je, protože Nintendo věc nikdy nepotvrdilo.
31
obr. 20 Wii Remote
Wiimote na obr. 20 má černobílou kameru 128 x 96, před níž je infračervený filtr. Do kamery projde tedy pouze infračervené světlo. Přímo na čipu ovladače je zabudováno rozeznávání obrazu. Wiimote je schopen sledovat až 4 body. Pro každý pixel je provedena osminásobná analýza, což zvýší počet pixelů na výstupu na 1024 x 768. IR kamera má horizontální zorné pole 33° a vertikální 23°. Zorné pole v programu v pixelech je 1280. Filtr nejlépe propustí světlo o vlnové délce 940 nm. U 850 nm propustí skoro dvojnásobně méně oproti stejně silnému zdroji na 940 nm. Pokud se odstraní filtr, kamera je citlivá na jakékoli světlo. Kamera má tři stavy snímání: 1) kamera zapnuta, ale nepřijímá data 2) kamera zapnuta, ale přijímá data v poloviční citlivosti 3) kamera zapnuta, ale přijímá data v plné citlivosti Ovladač je napájen dvěma AA bateriemi, které by měly vydržet podle specifikací až 25 hodin provozu při běhu IR kamery. Tento ovladač je velmi populární, proto se již od začátku pracovalo na knihovnách, jež by ho umožňovaly použít jinak než pouze k hraní na konzoli Wii. Knihoven v této době existuje opravdu mnoho. Pro Linux a Windows dohromady jich tolik už není, ale přesto nějaké existují. Pro tento systém je nejvhodnější knihovna WiiUse [8], která je napsaná v jazyce C, je jednovláknová a neblokující. Podporuje všechny ovládací prvky ovladače. Je to tedy jednoduché API pro komunikaci s Wiimotem. API je opravdu příjemné. Je velmi jednoduché se spojit s ovladačem a přečíst informaci o všech čtyřech bodech, které kamera vidí. Při známosti zorného pole v pixelech a velikosti snímaného obrazu je možné z minimálně tří nekolineárních bodů zjistit jejich transformaci. Algoritmus v jazyce C napsal Daniel DeMenthon [3], jehož inspirovala metoda popsaná v apendixu "Recognition and Tracking of 3D Objects by 1D Search", Proc. Image Understanding Workshop, Washington,
32
DC, pp. 653–659, 1993. Vstupem je posloupnost X a Y souřadnic bodů na projekčním plátně a souřadnice X, Y a Z sledovaného nekolineárního modelu. Algoritmus je iterativní s nastavitelným počtem maximálních opakování. Jeho výstupem je transformační matice 4 x 4. Když je program připraven na příjem čtyř IR bodů a je znám algoritmus, je třeba sestavit senzor. Ten se musí uzpůsobit podle potřeby algoritmu. Algoritmus má dvě podmínky: počet bodů musí být větší nebo roven třem, a tyto body nesmějí být kolineární. Senzor tedy musí být proveden ve třech rozměrech, nemůže být pouze v ploše. Ideálním řešením tohoto zadání je vytvoření dle schématu na obr. 21
(a)
(b)
3
1 4
2
obr. 21 senzor (a) – pohled shora (b) – pohled zleva (c) – perspektiva
33
Je tvořen třemi rameny a na každém z nich jsou umístěny IR diody, jež tvoří jeden bod. Podle zkušeností s několika možnostmi rozmístění IR diod tvořících jeden bod se jako nejlepší jeví stejné řešení, jako je na Sensor baru, jejž dodává Nintendo přímo ke své konzoli (obr. 22). Těchto 5 diod se z větší vzdálenosti jeví ovladači jako jeden bod.
(a)
(b) obr. 22 Wii Sensor Bar (a) – celý Sensor bar (b) – detail rozebrané části, rozložení a natočení diod Sensor baru
Senzor bar od Nintenda je uzpůsoben tak, aby byl dobře snímatelný z hrací vzdálenosti před televizí, což je tak okolo 2 – 4 metrů. Virtuální studio má ale potřebný pracovní prostor ve větší vzdálenosti. Protože měnit parametry ovladače není možné, je třeba vylepšit senzor. Místo 5 diod se použije diod 10, aby se zvýšil světelný výkon každého bodu, a to dle následujícího schématu (obr. 23):
obr. 23 bod senzoru
34
Celý senzor je pak zapojen dle následujícího schématu (obr. 24):
obr. 24 schéma zapojení senzoru
Velikost odporu R byla stanovena na max. R = 270 Ω, přičemž je možné snižovat velikost odporu na menší hodnotu, ta by totiž mohla zvýšit světelný výkon senzoru. Postupným experimentováním s velikostí odporu se hodnota ustálila na 150 Ω, což dává napětí na diodě 1,8 V. Realizace senzoru je na obr. 25 a obr. 26. Pro správnou funkčnost algoritmu je nutné zapínat diody senzoru postupně po číslech 1, 2, 3, 4 jak jsou na obr. 21, protože algoritmus očekává body vždy ve stejném pořadí, tak jak je má nadefinované v programu. Také není možné přerušit optický kontakt Wiimotu se senzorem, protože by se s největší pravděpodobností přeházely čísla bodů a diody by bylo nutné znovu pozapínat ve správném pořadí. Systém je nekalibrován na 20 cm vzdálenost mezi body senzoru a jeho tvar ve třech osách. Ve vstupu algoritmu je možné hodnoty vzdáleností nebo rozestavení bodů senzoru měnit.
35
obr. 25 senzor
obr. 26 bod senzoru
Pozice bodu senzoru snímá Wii Remote. Data z ovladače se přenášejí do počítače přes bluetooth. S pomocí knihovny WiiUse[8] je možné data z ovladače přečíst a pracovat s nimi. Jako abstraktní třida na celým systémem sledování pohybu je zde třída cameraTrack. Práci s knihovnou WiiUse zajišťuje třída WiiTrack, která dědí ze třidy cameraTrack. Pro práci s ovladačem je vytvořeno nové vlákno. Vždy při spouštění virtuálního studia se ovladače Wii Remote připojí k počítači pomocí metody connect(), kde se inicializuje knihovna pomocí příkazu wiimotes = wiiuse_init(MAX_WIIMOTES), který připraví knihovnu na MAX_WIIMOTES ovladačů. Funkce wiiuse_find(wiimotes, MAX_WIIMOTES, 5) hledá určený (MAX_WIIMOTES) počet ovladačů po dobu 5 sekund. Následně se připojí
36
k ovladačům pomocí wiiuse_connect(wiimotes, MAX_WIIMOTES). Pokud se nestane nic zvláštního, ovladače zůstanou připojeny až do konce běhu programu. Data z ovladače se přijímají v nekonečné smyčce trackingThreadFc. Vždy, když program potřebuje přečíst data ze sdílené paměti, požádá o to metodou void getCamTransformation(float camTransformation [16]). Ta jako první provede algoritmus přepočtu 4 bodů na transformační matici. Aby nedošlo ke kolizi s načítáním dat z ovladače, jsou zde data opět hlídána pomocí mutexů, které zaručí přístup pouze jednomu požadavku na čtení nebo zápis najednou. Následně přiřadí výsledek algoritmu do matice v parametru. Virtual:: draw()
scene ->trackCamera(i)
tracking ->getCamTransformation (&matrix[0])
trackingLoop() – algoritmus na výpočet transformace
přiřazení výsledků algoritmu do matrix
transformCamera (i, matrix);
výběr viewpointu OpenVRML podle i
actVpt ->user_view_transform (matrix) obr. 27 průběh výpočtu pozice jedné kamery
37
5 Testování Testování probíhalo po celou dobu vývoje v Institutu Intermedií (IIM) v Dejvicích. Důkladným testováním prošla každá část virtuálního studia. Záznam finálního testování je přiložen na CD. Vše bylo testováno na následující konfiguraci: Notebook DELL Precision M4300 procesor Intel Core 2 Duo T7500 – 2,2 Ghz paměť 2 GB grafická karta NVIDIA Quadro FX 360M – 256 MB GDDR3 pevný disk 160 GB 7200 rpm OS Mandriva Linux 2009, Windows XP SP3
5.1 Testování součástí Jako první se testoval kamerový systém. Zde šlo především o rychlost přenosu dat z kamery do počítače a jejich následné dekódování do výstupního bufferu. Použitá kamera byla typu Sony DSR – PD 170P se standardem PAL. Přenos dat funguje bez problému jak z kamery, tak z pevného disku v reálném čase. S dekódováním také nejsou žádné problémy. Pouze ve Windows při přehrávání z disku dochází k neúměrnému zrychlení videa nad 25 snímků za sekundu. Vzhledem k tomu, že čtení dat z disku a jeho dekódování je určeno pouze pro testování, není tento problém podstatný a dále se neřeší. Důležitá část, tedy přenos snímků z kamery a jejich dekódování, probíhá bez komplikací na obou systémech.
obr. 28 testovací scéna v IIM
38
O virtuální scénu se stará knihovna OpenVRML v0.17, která sice funguje, ale je zdrojem hned několika problémů. Její zvláštnost tkví především v tom, že každý soubor VRML musí mít svou geometrii v jedné skupině: Group { children [ #geometrie ] } To však není v jazyce VRML podmínkou. Například při exportu z programu 3D Studio MAX 9, scéna tuto skupinu, která je nad veškerou geometrií neobsahuje a je třeba ji tam ručně dopsat. Tuto zvláštnost obsahuje už několik verzí OpenVRML. Knihovna má rovněž problém s načítáním textur. Ne vždy se jí podaří texturu načíst celou a na ploše zůstane pak prázdný černý pruh, což je pro fungování virtuální studia velmi nepříjemný nedostatek. Ve virtuálním studiu se relativně často využívá textur, neboť nahrazují složitou geometrii, jež by jinak výpočet snímku zbytečně prodloužila. Pro virtuální studio je to velmi kritická záležitost. Další chybou v OpenVRML je celkem velký počet memory-leaků. Při testování docházelo několikrát k úplnému zahlcení paměti. Následně bylo nutné celý systém restartovat. I přes tento velký počet chyb je OpenVRML stále nejlepší knihovnou pro práci s VRML scénami.
obr. 29 testovací virtuální scéna
39
Klíčování se také testovalo už od počátečního vývoje. V první verzi se pracovalo v barevném prostoru RGB. Odstraňovala se jedna barva zadaná hodnotami červené, zelené a modré. Všechny hodnoty měly rozmezí, v němž se směl pixel pohybovat, aby mohl být odstraněn. V další verzi se přidaly další dva odstíny barvy. Klíč měl tedy větší rozmezí, které odstraňoval. Vhodné nastavení shaderu vedlo při dobrém nasvícení scény k uspokojivým výsledkům. Shader odstraňoval většinu klíčovací barvy. Bohužel na okrajích objektů docházelo stále k tzv. auře. Objekty, které byly obklopeny klíčovací barvou, měly okraje v barvě pozadí. Třetí verze dosáhla opět lepších výsledků v odstraňování klíčovací barvy. Došlo ke změně barevného prostoru z RGB na HSV, vstup však stále zůstával v RGB. Stále ovšem přetrvává problém s aurou. Lepších výsledků by se určitě dosáhlo, kdyby se užila technika rozeznávání hran.
obr. 30 výsledný složený obraz
Zkoušení systému sledování pohybu bylo nejnáročnějším testováním z celého systému. Senzor se nakonec podařilo úspěšně sestavit do funkční podoby. Nejprve se počítalo s tím, že bude napájen z 9 V baterie, poté se ovšem vzhledem k velké spotřebě energie muselo přejít k napájení ze sítě, což velmi změnilo charakter napájení. Baterie totiž sloužila v počátku své životnosti jako velmi dobrý zdroj a diody bylo možné jednoduše přebudit, aniž docházelo k jejich poškození. S takovouto konfigurací bylo dosaženo největší funkční vzdáleností mezi
40
IR kamerou a senzorem, a to kolem až kolem 6 m. Bohužel měl senzor tak velkou spotřebu, že už po několika desítkách minut se snížilo napětí natolik, že baterii nebylo možné použít. Přechod na síťový zdroj byl komplikovaný, a to vzhledem k neznalosti parametrů diod. První nestabilizovaný zdroj 9 V, 1 A na senzor nestačil. Ani stabilizovaný 9 V, 2 A nepomohl. Projevovalo se to tím, že diody blikaly a při odpojení části diod začal senzor fungovat. Protože se 9V zdroj s větším povoleným proudem neprodává, bylo nutné přistoupit na stabilizovaný zdroj 12 V, 4 A. Ten již poskytl dostatečný proud pro napájení senzoru a fungoval správně. Objevily se ovšem problémy s výkonem diod. Při spočítaném odporu bylo možné použít senzor nejdéle do tří metrů, což je nedostačující vzdálenost. Bylo nutné zmenšit velikost odporů, jež byly diodám předřazeny. Pokusy s nastavením správné velikosti odporů skončily z 270 Ω na 30 Ω, kde již jedna dioda nevydržela a přepálila se. Velikost odporů byla tedy stanovena na 150 Ω. Bohužel se ovšem nepodařilo zvětšit funkční vzdálenost senzoru. Ideální vzdáleností pro použití v praxi by bylo více jak 5 m.
klíčovací plocha kamera
senzor Wii Remote
obr. 31 testování v laboratoři IIM
Problémem se také ukazuje rozlišovací schopnost IR kamery v ovladači Wii Remote. Její fyzické rozlišení je pouze 128 x 96, což je na větší vzdálenost již nedostačující a body se začínají slévat do jednoho. Lze to vyřešit zvětšením vzdálenosti mezi body na senzoru. To je ovšem také limitováno jeho použitím. Není možné mít v praxi senzor 2 metry široký. Malé rozlišení kamery nejenže zmenšuje vzdálenost, pro niž je systém použitelný, ale způsobuje
41
rovněž lehké skoky při pohybu kamery. Ty se pak projevují tím, že celá virtuální scéna poskakuje po větších a menších krocích. Testování ukazuje, že čím je vzdálenost menší, tím se tyto chyby snižují. Při velkých vzdálenostech jsou tyto poskoky již velmi znatelné a činí systém nepoužitelným. Pro zvýšení přesnosti byly experimentálně použity dva ovladače Wii Remote a pozice z nich přepočítána průměrem ze dvou hodnot. Bohužel ani to nepřineslo podstatné zmenšení chyb, které se stále projevovaly. Součástí testování systému sledování pohybu je také jeho přesnost. Byla testována tak, že se od kamery Wii Remote natáhl metr a po 50 cm se snímala pozice. Následující tabulka ukazuje, jakých bylo dosaženo hodnot. vzdálenost
hodnota na ose Z
100 cm 150 cm 200 cm 250 cm 300 cm
10,60 14,80 19,98 24,70 -
tabulka 1. testování přesnosti sledovacího systému
Bohužel pro 300 cm a vice se již nepodařilo hodnoty naměřit, protože výkon senzoru nebyl dostatečný. Tabulka ukazuje, že hodnoty se skutečnosti velmi blíží, bohužel technické parametry použitých komponent nedovolují zvýšit přesnost a hlavně použitelnost systému na větší vzdálenost. Celý systém byl také testován na práci s pamětí s programem Valgrind. Bylo zjištěno, že vlastní kód obsahuje minimum memory-leaků, knihovny, především OpenVRML, však jich obsahují mnoho. Proto se nedoporučuje spouštět aplikaci mnohokrát po sobě, protože pak dojde volná paměť.
5.2 Návrhy zlepšení Jádro systému je navrženo tak, aby nebylo obtížné přidat nebo změnit části systému. Je proto jednoduše možné změnit systém sledování pohybu za systém přesnější, aniž by se musel měnit kód celého programu. Kamerový systém funguje bez problému jak na Linuxu, tak na Windows. Dobrým krokem, by bylo přidání informace o zoomu. To by kameramanovi dovolovalo pracovat i s nájezdem na moderátora nebo na jiné objekty ve studiu, což by ale znamenalo další senzor na objektivu kamery. Virtuální scéna funguje rovněž velmi dobře. Zde by bylo vhodné vyřešit problémy s OpenVRML, které mohou být způsobeny pouze nedostatkem informací, neboť vývojáři OpenVRML neposkytují téměř žádnou dokumentaci, natož příklady použití. Aplikace VRML jako formátu pro scénu se zdá být dobrou volbou.
42
Klíčovací algoritmus by bylo dobré doplnit o rozeznávání hran, aby se netvořila aura kolem objektů a především okolo vlasů a chlupů na těle člověka ve studiu. Dnešní grafické karty zdá se nemají problém se zpracováním takovéhoto úkolu. Dalším vhodným zdokonalením by bylo nastavení parametrů přímo v aplikaci. Shaderu je možné za běhu programu předávat data přímo z programu. Kdyby měl program vhodné GUI, mohl by předávat získané hodnoty přímo do shaderu. Nejvhodnější součástí by bylo tzv. kapátko, což by sloužilo pro výběr barvy, která slouží jako základní parametr při barevném klíčování. Dále by byla přítomna pole, do nichž by se zadávaly číselné parametry, případně jezdce pro zadávání hodnot v určitém rozsahu. Sledovací systém sice předvedl, že je schopný fungovat a sdělovat přibližnou pozici a rotaci vůči kameře, bohužel však nebyl přesný natolik, aby to dovolovalo použít systém v praxi. Bylo by především třeba mít diody s větší světelností. O infračervených diodách je při koupi opravdu málo dostupných informací. Většinou je známa vlnová délka, na níž pracují, a cena. Problémem je, že ani samotní prodejci v obchodech s elektronikou nemají o diodách dost informací a tak nejsou schopni pomoci. Diody se obvykle vyrábějí jen v malých pětimilimetrových pouzdrech. Bylo by vhodné nalézt diody výkonnější a větší (např. desetimilimetrová pouzdra). Samotný senzor, který je sestaven do tří základních os, také není ideální pro použití. Bylo by například možné použít dvě kamery na jeden senzor a mít na něm pouze dva body. Tato konfigurace rovněž dovoluje sledovat pohyb v prostoru. Velkým problémem bylo fyzické rozlišení IR kamery na ovladači Wii Remote. Při větších vzdálenostech neúměrně skákala pozice i natočení a tím i celá scéna. Dalším možností jak zlepšit tyto skoky by bylo zpožděním celého systému v řádech max. desítek snímků a vyhlazením přijatých dat pomocí derivací. Dal by se také vyvinout systém podobný Wii Remote. Klasická kamera, nejlépe černobílá, by se opatřila infračerveným filtrem, a sledovala by senzor. Měla by fyzické rozlišení 720 x 576 pixelů, což by bylo asi šestkrát víc, než má Wii Remote. Ze snímku by se pak pomocí rozeznávání obrazu identifikovaly body a údaj o jejich pozici by se předal algoritmu pro výpočet transformační matice. Druhou pravděpodobně přijatelnější možností by bylo změnit systém sledování pohybu ze senzorového na rozpoznávací. Nebylo by třeba žádného sledovacího zařízení, informace by se získávaly přímo z obrazu. Samotné aplikaci by prospělo GUI. V této chvíli je možné zadávat parametry z příkazové řádky. S přítomností GUI by bylo možné zadávat je různými výběry či přes menu. Dále by bylo vhodné přidat možnost výběru hlavního výstupu, který by viděl divák. Pro tyto účely by velmi dobře posloužila knihovna QT, jež opět dobře funguje jak pod Linuxem, tak pod Windows. Profesionální virtuální studia mají také tzv. řady, tedy vrstvy, do nichž se vkládají vstupy, a pak se podle jejich pořadí vykreslují na výstup. V tomto systému jsou přítomny pouze dvě řady – vstup z kamery a vstup z virtuální scény. Bylo by vhodné mít volitelný počet vrstev, s nimiž by studio pracovalo. Protože dvě vrstvy dovolují vkládat virtuální scénu buď před, nebo za obraz z kamery a není možné je kombinovat, přidáním třetí vrstvy by bylo možné přidávat virtuální scénu jak za obraz, tak před něj. Tímto způsobem se například
43
realizovaly volby do Sněmovny v roce 2006, kdy moderátoři seděli za stoly, za nimi bylo virtuální pozadí a před nimi sloupce s preferencemi.
5.3 Srovnání Otevřené virtuální studio se ještě stále nedá srovnávat s již existujícími funkčními systém. Jejich náskok je zatím stále velký. Avšak po vyřešení technických obtíží by bylo možné použít otevřené virtuální studio i v praxi, aniž by to pro diváka znamenalo viditelný rozdíl. Výhodou otevřeného virtuálního studia je nezávislost na komerčních programech nebo softwaru. Další velkou předností je, že na něm v budoucnu může pracovat kdokoli, kdo bude chtít a mít dobrý nápad.
44
6 Závěr Podařilo se vytvořit koncept otevřeného virtuálního studia. Technické potíže sice neumožňují jeho provoz v praxi, ale po jejich vyřešení, resp. zkvalitnění, je možné toto studio plnohodnotně využít v praxi. Systém nemá žádnou uzavřenou součást, je složen pouze z volně dostupných knihoven a vlastního kódu. Ve virtuálním studiu je plně funkční kamerový systém, který je schopen přenášet snímky z několika kamer najednou. Dále se podařilo sestavit klíčovací část, která bude po vylepšení algoritmu schopna odstranit v reálném čase klíčovací barvu a nahradit ji pozadím. Virtuální část renderuje snímky z 3D modelu, který načítá z pevného disku, a to z pozic, jež jsou jí předány ze systému sledování pohybu. Ta jako poslední a nejsložitější část ukázala, že je možné sestavit přesný systém sledování pohybu, ale je pro něj třeba kvalitních komponent, které dokáží sledovat s velkou přesností pohyb kamer. Ukázalo se tedy, že lze sestavit levné virtuální studio, ale není možné šetřit na klíčových částech studia, jako je systém sledování pohybu. Celkově principy systému fungují velmi dobře a mají naději být prakticky využívány. Je však třeba technicky vylepšit některé části tak, aby výsledný dojem byl přesvědčivý. Systém je připraven na výměnu jakékoli součásti za lepší či přesnější. Podařilo se naprogramovat funkční systém virtuálního studia na operačním systému Linux. Ve Windows se podařilo naprogramovat nejnáročnější část, a to snímaní kamery a dekódování snímku. V systému jsou použity multiplatformní knihovny, jež umožňují použití jak v Linuxu, tak ve Windows. Celý funkční systém lze převzít z Linuxu a pouze přidat podporu knihoven ve Windows; pak bude plně funkční i pod tímto systémem. Otevřené virtuální studio se bude vyvíjet dál i po dokončení této práce. Autor chystá jeho přesun na celosvětově známý portál sourceforge.net, kde se na něm dále může kdokoli podílet.
45
Literatura 1. Orad, [online], poslední revize 2008 [cit. 5. 7. 2008]
2. Virtual studio technology, Max Rotthaler, 1996, [online], poslední revize 2008 [cit. 12. 3. 2008] 3. Daniel DeMenthon, Code, [online], poslední revize 2009 [15. 4. 2009] 4. linux1394, [online], poslední revize 2008 [cit. 12. 8. 2008] 5. libDV, [online], poslední revize 2008 [cit. 24. 10. 2008] 6. OpenVRML, poslední revize 2008 [cit. 15. 11. 2008] 7. Wiimote – Wiibrew, poslední revize 2009 [cit. 23. 3. 2009] http://wiibrew.org/wiki/Wiimote#IR_Camera 8. Wiiuse, poslední revize 2009 [cit. 11. 4. 2009]
46
Dodatek A
Instalace a spuštění Otevřeného TV virtuálního studia Otevřené virtuální studio lze provozovat na jakémkoli počítači klasické architektury x86. Protože jediná kompletní verze studia je pro prostředí Linux, instalace se bude zabývat pouze touto verzí. Předpoklady pro úspěšný provoz Otevřeného virtuálního studia: •
počítač s operačním a bluetooth
•
kameru s rozhraním firewire
•
grafickou kartu podporující shadery
•
ovladač Wii Remote
•
sestavený senzor s IR diodami
systémem
typu
Linux
s
rozhraním
firewire
Prvním krokem instalace je překlad zdrojových kódů. Na to je třeba mít všechny potřebné knihovny, které studio využívá: •
pthread, OpenGL, GLU, GLUT, GLEW, libiec61883, libdv, OpenVRML, OpenVRML-gl, Wiiuse,
Po nainstalování všech těchto knihoven je již možné pomoci souboru makefile a příkazu make zkompilovat celý projekt. Soubor s nastavením má pak následující strukturu (za jmény parametrů jsou ukázkové hodnoty): Nastavení glut: #fovy 70.0 #aspectRatio 1.33 #nearPlane 0.1 #farPlane 1000.0 Velikost snímku v pixelech (kamery): #frameWidth 720 #frameHeight 576 Velikost obrazovky v pixelech – kvůli gui:
47
#screenWidth 1920 #screenHeight 1400 Počet snímků za vteřinu (kamery): #fps 25 Počet kamer: #numberOfCameras 1 Počet souborů z disku: #numberOfFiles 1 Počet viewpointů v souboru scény: #numberOfViewpoints 2 Cesty k souborům z disku: #filenames ./data/green5.dv Typy kódování zdrojů (kamer a souborů): #streamtypesEnum DV - 0 #streamtypes 0 Typy přenosových medíí kamer: #transfertypesEnum FIREWIRE - 0 #transfertypes 0 Cesta k souboru s 3D scénou: #sceneFilename ./data/studio_iim_2.wrl Cesty k souborům shaderu(fragment, vertex): #shaderFilenames
./keying/_keying.frag ./keying/_keying.vert
Přiřazení kamer k viewpointům: #camera->viewpoint
0 0 1 1
Počet kamer + počet souborů z disku by se měl rovnat počtu viewpointů.
48
Otevření virtuální TV studio se spouští příkazem: ./virtual jmeno_souboru_s_nastavenim po několika informačních hláškách vás studio vyzve k připojení ovladače Wii Remote pomocí tlačítek 1+2, které jsou na ovladači. Následně se již spustí GUI. Pro správnou funkčnost systému je nutné zapínat diody senzoru postupně po číslech 1, 2, 3, 4, jež jsou na obr. 21.
49
Dodatek B
Obsah přiloženého CD index.html
výchozí stránka projektu
readme.txt
popis, co ve kterém adresáři je a účel souborů
instal.txt
postup instalace programu
text/ DP.pdf
text DP
exe/ virtual
spustitelný soubor v Linuxu
virtual settings
nastavení virtuálního studia
data/ _keying.frag
fragment shader
_keying.vert
vertex shader
green.dv
ukázkový soubor na načtení¨
studio_iim.wrl
ukázková VRML virtuální scéna
studio_iim_2.wrl
ukázková VRML virtuální scéna
img_1005.jpg
textura do VRML scén
data/ video_ukazky.mpg
video ukázka provozu studia
images/
class diagram + screenshoty z aplikace
src/
zdrojové soubory
_vs2008
projekt pro VS2008 (Windows)
_eclipse
projekt pro Eclipse (Linux)
html/
50
doc/
dokumentace
abstract
krátký abstrakt
RabstrCZ
abstrakt v češtině
RabstrAJ
abstrakt v angličtině
