Rozpoznávání markerů v obraze

Mendelova univerzita v Brně Provozně ekonomická fakulta

Rozpoznávání markerů v obraze Diplomová práce

Vedoucí práce: Ing. David Procházka, Ph.D.

Bc. Martin Palík

Brno 2011

Na tomto místě bych chtěl poděkovat vedoucímu mé diplomvé práce, panu Ing. Davidu Procházkovi, Ph.D., za ochotu a cenné rady při přípravě a zpracování této práce.

Prohlašuji, že jsem tuto práci napsal samostatně s použitím zdrojů uvedených v seznamu literatury.

V brně dne 20. 5. 2011

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

4

Abstract Palík, M. Marker detection in picture. Diploma thesis. Brno, 2011. This diploma thesis deals with the ways of detection of general but clearly defined markers in picture. The theoretical part describes ways of detection, which are used nowadays. It also focuses on some of available libraries for working with 3D models. The practial part describes how such application, which looks for markers in picture and reacts on positive match, can be made. The practical part also describes the way of creating Graphical User Interface, which serves for parameter definition by easy way.

Abstrakt Palík, M. Rozpoznávání markerů v obraze. Diplomová práce. Brno, 2011. Tato diplomová práce se zabývá způsoby rozpoznávání obecných, předem jasně definovaných markerů v obraze a možnostmi zobrazování 3D modelů na místě nalezných markerů. Teoretická část popisuje přístupy pro detekci objektů v obraze, které jsou používány v současnosti. Také přibližuje některé z dostupných knihoven pro práci s 3D modely. Praktická část poté popisuje způsob tvorby aplikace, která objekty v obraze hledá, a v případě, že je najde, zobrazí na jejich místo předem určený 3D model. V praktické části je také popsán způsob tvorby grafického uživatelského rozhraní, které slouží pro snadné zadávání parametrů pro aplikaci.

5

OBSAH

Obsah 1 Úvod a cíl práce 1.1 Úvod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 Cíl práce . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7 7 7

2 Historie doplněné reality

9

3 Zařízení využívaná v doplněné realitě 3.1 Zobrazovací zařízení . . . . . . . . . 3.1.1 HMD . . . . . . . . . . . . . . 3.1.2 Kapesní displaye . . . . . . . 3.1.3 Prostorové displaye . . . . . . 3.2 Trackovací zařízení . . . . . . . . . . 4 Knihovny používané 4.1 ARToolKit . . . . 4.2 OpenCV . . . . . 4.3 ARTag . . . . . .

. . . . .

10 10 10 11 12 12

při vývovoji aplikací AR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

15 15 15 16

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

5 Výběr knihovny pro tvorbu AR aplikace

17

6 Postup tvorby aplikace doplněné reality

19

7 Srovnání metod používaných pro detekci 7.1 Metoda MatchTemplate . . . . . . . . . 7.2 Binární kódy . . . . . . . . . . . . . . . 7.3 Detektor SURF . . . . . . . . . . . . . .

objektů v obraze 21 . . . . . . . . . . . . . . . . 21 . . . . . . . . . . . . . . . . 21 . . . . . . . . . . . . . . . . 22

8 Knihovny pro práci s 3D 8.1 Irrlicht . . . . . . . . . 8.2 Assimp . . . . . . . . . 8.3 Ogre . . . . . . . . . . 8.4 Agar . . . . . . . . . . 8.5 Unreal Engine . . . . . 8.6 Delta3D . . . . . . . . 8.7 OpenSceneGraph . . .

. . . . . . .

modely . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

25 25 27 28 30 31 32 33

9 Výběr knihovny pro práci s 3D modely

35

10 Návrh vlastního řešení 10.1 Detekce markerů v obraze . . . . . . . . . . . . 10.1.1 Preprocessing – příprava obrazu . . . . . 10.1.2 Detekce vrcholů potenciálních markerů . 10.1.3 Matice homografie a narovnávání obrazu

37 37 37 40 43

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

6

OBSAH

10.1.4 Srovnání šablony a nalezeného markeru 10.2 Načítání a zobrazování 3D modelů . . . . . . 10.3 GUI pro zadávání vstupních parametrů . . . . 10.3.1 Rozmísťování prvků v okně . . . . . . 10.3.2 Napojení reakcí na uživatelské akce . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

44 45 46 47 50

11 Diskuze

52

12 Závěr

53

13 Literatura

54

Přílohy

57

A Ukázky výstupů práce

58

B Postup připojení knihovny Irrlicht pomocí Visual Studia 2008

62

1

ÚVOD A CíL PRÁCE

1 1.1

7

Úvod a cíl práce Úvod

Aplikace rozpoznávající objekty v obrazech se v dnešní době čím dál více dostávají do povědomí lidí i mimo vědeckou sféru a možnosti pro jejich využití se značně rozšiřují. Aplikace tohoto typu se řadí do oblasti nazývané doplněná realita (Augmented Reality – AR). AR bývá podobně, jako virtuální realita (VR), definována pomocí několika různých definic. Některé označují AR jako specialní případ virtuální reality, jiné tvrdí, že AR je mnohem obecnější pojem, a vidí VR jako speciální případ AR. Faktem však je, že na rozdíl od tradiční VR, není v AR reálné prostředí úplně potlačeno. Spíše naopak - hraje dominantní roli. Spíše než o ponoření osoby do uměle vytvořeného světa se AR pokouší vkládat uměle vytvořené doplňky do reálného prostředí (např. do live videa, se scénou z reálného prostředí). (Bimber a Raskar, 2005) Jako příklad funkčních AR aplikací, které se dnes používají, může být uvedena například aplikace Wikitude pro mobilní telefony nebo software VeriFace. Wikitude byl čtenáři Augmented Planet zvolen nejlepším prohlížečem doplněné reality roku 2010. Tato aplikace pro mobilní telefony s vestavěným kompasem a gps umí zjistit, jaký obraz snímá kamera těchto zařízení a doplnit do obrazu informace o rozpoznaném objektu. (CNN GO, 2011) Druhý zmiňovaný příklad pochází od společnosti Lenovo, která jej nabízí pro své notebooky jako lepší možnost zabezpečení. VeriFace je software na rozpoznávání tváře, který může být použit místo klasického přihlašovaní pomocí hesla do systémů Microsoft Windows, umožňuje zobrazit video zprávu pro neautorizované uživatele, uchovává historii přihlášení a nabízí šifrování souborů pomocí hesla do systému Microsoft Windows nebo pomocí snímku s obličejem. (Lenovo, 2010) Samozřejmě existuje spousta dalších aplikací doplněné reality, které nacházejí uplatnění např. v oblastech vojenství, medicíny, různých průmyslových odvětvích, spotřební elektroniky atd. Možnosti využití jsou opravdu široké. Stejně tak existuje mnoho přístupů a postupů, které vedou k vytvoření AR aplikací, a pomůcek a knihoven, které jejich vývoj značně usnadňují.

1.2

Cíl práce

Cílem práce je sestavit takový pracovní postup, který povede k vytvoření funkční aplikace rozpoznávající předem definovaný objekt v obraze. Před samotným sestavováním tohoto postupu bude nutné zjistit a analyzovat, jaké přístupy jsou v současnosti používány pro vyhledávání obecných makrerů v obraze, odhalit jejich výhody a nevýhody v souvislosti s kompatibilitou vývojových prostředí i prostředí, na kterých mohou být provozovány.

1.2

Cíl práce

8

Aby bylo možné ověřit, že tento pracovní postup funguje a že poskytuje výsledky, které jsou očekávány, bude nutné do experimentální aplikace, která bude vytvořena na základě sestaveného postupu, zaintegrovat podporu pro načítání a zobrazování 3D modelů. V případě, že bude marker úspěšně nalazen, bude na jeho místo zobrzen definovaný 3D model v odpovídající perspektivní deformaci. Proto také bude nutné zanalyzovat a porovnat některé z dosupných knihoven pro práci s 3D modely, které toto umožňují. Celá praktická část této diplomové práce bude zaintegrována do aplikace AuRel, která je vyvíjena na Ústavu informatiky Mendelovy univerzity v Brně pod vedením pana Ing. Davida Procházky, Ph.D., jenž je vedoucím tohoto projektu. Aplikace AuRel je jedním z modulů pro software VRUT vyvíjený společností Škoda Auto, a. s. ve spolupráci s ČVUT.

2

2

HISTORIE DOPLNĚNÉ REALITY

9

Historie doplněné reality

Termín „doplněná realitaÿ (Augmented Reality – AR) se poprvé objevil v padesátých letech minulého století, když kameraman Morton Heilig přemýšlel o filmu jako o aktivitě, která bude schopna vtáhnout diváka do činností na obrazovce tím, že efektivním způsobem zaměstná všechny jeho smysly. V roce 1962 Heilig představil prototyp jeho vize, kterou popsal ve „Filmu budoucnostiÿ nazvaném Sensorama. Ten předcházel digitální výpočetní technice. Dalším milníkem byl rok 1966, kdy Ivan Sutherland vynalezl Head Mounted Display (HMD – display nošený na hlavě). V roce 1958 byl Sutherland první, který vytvořil systém doplněné reality pomocí optického průhledného HMD (see-through HMD). Roku 1975 vytvořil Myron Krueger Videoprostor – první místnost, která umožňovala uživatelům interakci s virtuálními objekty. Později, během jejich pomoci zaměstnancům při shromažďování drátů a kabelů pro letadla, vytvořili Tom Caudell a David Mizell z firmy Boeing frázi „Doplněná ralitaÿ. Také začali diskutovat o výhodách doplněné reality oproti virtuální realitě, mezi které mimo jiné patřily i nižší požadavky na spotřebu energie, protože je zapotřebí menší počet pixelů. Ve stejném roce vyvinul L. B. Rosenberg jeden z prvních funkčních systémů AR nazvaný Virtual Fixtures a prokázal jeho přínos pro výkony lidí. Mimo to představili Steven Feiner, Blair MacIntyre a Doree Seligmann první myšlenku prototypu AR systému s názvem KARMA. V roce 1997 provedl Ronald Azuma první průzkum o AR, který poskytl široce uznávanou definici AR označující ji jako kombinaci reálného a virtuálního prostředí, přičemž oba jsou použitelné ve 3D prostoru a poskytují interaktivitu v reálném čase. První mobilní AR hru nazvanou ARQuake vyvinul Bruce Thomas v roce 2000 a představena byla na mezinárodním sympoziu o přenosných počítačích. Roku 2005 Horizon Report predpověděl, že technologie AR se v následujících čtyřech až pěti letech bude oběvovat čím dál častěji. Že tato předpověď byla správná dokazuje fakt, že ve stejném roce byl vyvinut kamerový systém, který dokázal v reálném čase analyzovat fyzické prostředí a zjišťovat pozici objetků v prostředí. Tento kamerový systém se stal základem pro integraci virtuálních objektů s realitou v systémech AR. V následjících letech byly aplikace AR vyvíjeny ve větší míře. Především se jednalo o aplikace používané v lékařství nebo o mobilní aplikace, jako například Wikitude AR Travel Guide, jehož vývoj byl zahájen v roce 2008. (Carmigniani a kol., 2011) V dnešní době se díky technologickému pokroku stále zvyšuje počet vyvíjených a vyvinutých aplikací AR.

3

ZAŘíZENí VYUŽíVANÁ V DOPLNĚNÉ REALITĚ

3

10

Zařízení využívaná v doplněné realitě

Zařízení, která jsou potřebná pro alikace doplněné reality lze rozdělit na: • zobrazovací, • vstupní, • trackovací, • počítače. Pro účely této práce bude naprosto dostačující, když budou přiblížena pouze některá zobrazovací a trackovací zařízení.

3.1

Zobrazovací zařízení

Jako každá počítačem vytvářená realita, i doplněná realita potřebuje prostředky, které ji umí zobrazit. Jak uvádí Koubek (Koubek, 2010) tato zobrazovací zařízení mohou být rozdělována do 3 kategorií: • HMD, • kapesní displaye, • prostorové displaye. Mimo tyto samozřejmě existují i jiné, které jsou však používanány méně. Jako zařízení nespadjící ani do jedné této kategorie, ale které lze také použít jako zobrazovací médium aplikací AR, lze uvést monitor počítače, nebo notebooku. Každé zobrazovací zařízení je vhodné pro jiný typ aplikace doplněné reality. 3.1.1

HMD

Písmena HMD zkacují anglická slova Head-Mounted Display, respektive Helmet Mounted Display. Označjí zobrazovací zařízení, které je připevněno k hlavě, nebo je součástí helmy a má malý display před jedním (monoculární HMD) nebo oběma (binoculární HMD) očima (Head-mounted display, 2011). Podle toho, zda je či není přes display vidět, lze HMD rozlišovat na optical see-through (na obr. č. 1 vlevo) nebo video see-through HMD (obr. č. 1 vpravo). Typickým příkladem HMD může být například přilba armádního pilota, jemuž jsou na průzor přilby promítány další doplňující informace (obr. č. 2). Jako vždy, existuje-li pro jednu věc více variant, má každá z těchto variant své výhody i nevýhody. Výhody Optical see-through (optické kompozice) uvádí Procházka (Procházka, 2010) následujícícm způsobem: • jsou jednodušší a tedy levnější,

3.1

Zobrazovací zařízení

11

Obr. 1: Head Mouted Display (Procházka, 2010)

Obr. 2: Přilba armádního pilota (Procházka, 2010)

• umožňují přímý kontakt s realitou i vpřípadě poruchy – display je průhledný, • nedochází k porušení vnímání prostoru. Důvody pro Video see-through (video kompozice): • teoreticky perfektní překrytí realných a umělých objektů, • lepší synchronizace obrazů, • více metod pro vkládání objektů.

3.1.2

Kapesní displaye

Kapesní displaye, jinak řečeno také ruční displaye, jsou používány v malých výpočetních zařízení, která uživatel může držet v rukách. Pro vkládání dodatečných údajů a infromací do reálného prostředí používají technologii video see-through. Dále využívají různé senzory, jako například digitální compasy nebo GPS jednotky, které jim umožňují sledovat jejich šest stupňů volnosti (obr. č. 3). Některé z nich také používají metody počítačového vidění. V současnosti existují tři různé skupiny komerčně dostupných ručních displayů, které mohou být použity pro systémy doplněné reality: mobilní telefony, PDA,

3.2

Trackovací zařízení

12

Obr. 3: Příklad Kapesního displaye – aplikace Wikitude (Wikitude, 2011)

Tablety. Mobilní telefony jsou snadno přenosné a opravdu velice rozšířená zařízení, která v kombinaci s nějakým dalším vylepšením v podobě výkoného CPU, kamery, akcelerometru, GPS modulu, případně kompasu, představují velice slibnou platformu pro aplakace AR. Velikou nevýhou je však jejich malý display. PDA mají většinu výhod i nevýhod mobilních telefonů, ale jsou mnohem méně rošířeny. Naproti tomu tablety jsou mnohem výkonější než mobilní telerfony nebo PDA, ale jsou také znatelně dražší a také mnohem těžší. (Carmigniani a kol., 2011) 3.1.3

Prostorové displaye

Prostorové displaye většinou využívají videoprojektory, optické elementy, hologramy, rádiovou frekvenci a další technologie, které umožňují zobrazovat grafické informace přímo na fyzické objekty, aniž by uživatel musel nosit nějaký display na hlavě nebo v ruce. Prostorové displaye umožňují umístit většinu potřebné technologie mimo dosah uživatele a integrovat ji přímo do prostředí.(Carmigniani a kol., 2011) Tato zobrazovací technologie je dnes čím dál častěji využívána v automobilovém průmyslu. Řidiči jsou na čelní sklo promítány údaje o aktuální rychlosti, rozpoznané dopravní značky o omezení rychlosti a další údaje. Ukázky možností, jak lze zobrazovat do prostoru jsou na obrázcích č. 4 a 5.

3.2

Trackovací zařízení

Trackovací zařízení (dále trackery) slouží ke zjišťování pozice, případně polohy sledovaného objektu v prostoru. Bez těchto zařízení by prakticky nebylo možné vytrořit žádnou aplikaci doplněné reality. Podle způsobu, jakým dochází k vlastímu snímání pozice či polohy, lze trackery dělit na: • akustické (ultrazvukové), • optické (infračervené paprsky, triangulace),

3.2

Trackovací zařízení

13

Obr. 4: Zobrazování do suché mlhy (Procházka, 2010)

Obr. 5: HeadUp display v BMW (Procházka, 2010)

• elektromagnetické (použito na půdě univerzity – v laboratoři virtuální reality), • elektromechanické (exoskelety), • neurální, aj. Toto členění je převzato z doplňkového materiálu k přednáškám předmětu Pokročilá uživatelská rozhraní (Procházka, 2010). Bimber (Bimber a Raskar, 2005) dále člení trackery na základě toho, jak jsou umístěny v prostoru, následujícím způsobem: • outside-in – stacionární senzory jsou umístěny v prostředí na stálém místě a snímají body na pohybujícím se cíli.

3.2

Trackovací zařízení

14

• inside-out – senzory jsou umístěny na pohybujícím se cíli. Tyto senzory jsou schopny určit jejich pozici v závislosti na fixních bodech umístěných v prostředí. Tyto dva způsoby trackování jsou obvykle používány pouze při klasifikaci způsobů optického trackování, nicméně jsou stejně tak vhodné k popisu ostatních způsobu trackování.

4

KNIHOVNY POUŽíVANÉ PŘI VÝVOVOJI APLIKACí AR

4

15

Knihovny používané při vývovoji aplikací AR

Pro snažší, jednodušší a samozřejmě také rychlejší práci vývojařů aplikací AR existuje několik projektů, které se soustřeďují na vývoj knihoven obsahujících sadu nástrojů, které toto umožňují. V této práci budou trochu přiblíženy knihovny OpenCV, ARTag, ARToolkit. Mimo tyto tři však existuje ještě celá řada dalších knihoven, které mohou být k tomuto účelu využity.

4.1

ARToolKit

ARToolKit (Augmented Reality Tool Kit) je softwarová knihovna pro vývoj AR aplikací. Mezi její základní vlastnosti patří multiplatformnost. Může být použita na systémech Windows, Linux i MacOS X, podporuje různé zdroje vstupu (USB, Firewire, capture card), rozumí několika formátům obrazu (RGB/YUV420P, YUV), má grafické rozhraní. Dalšími vlastnostmi pak jsou: • rychlé sledování objektů v šesti stupních volnosti, • jednoduchá grafická knihovna (založená na knihovně GLUT), • rychlé renderování pomocí OpenGL, • podpora VRML (Virtual Reality Modeling Language), • jednoduché API vytvořené v jazyce C, • podpora jiných jazyků (Java, matlab), aj. (ARToolKit – Features, 2007) Historie této knihovny sahá do roku 1999, kdy Hirokazo Kato přišel na Washingtonskou univerzitu do HITLabu (Human Interface Technology Laboratory). První představení bylo na konferenci SIGGRAPH v roce 1999 pro projekt sdíleného prostoru. Podpora Windows DirectShow videa pomohla rozšířit možnosti použití na mnoho výstav. Během posledních let jejího vývoje byly provedeny velké změny (multiplatformnost, lepší trackovací algoritmy) (ARToolKit – History, 2007). Původně byla vyvíjena jako open-source s GPL licencí pro nekomerční použití, ale jak uvádí Koubek (Koubek, 2010), vývoj této knihovy se přesunul k placené verzi ARToolkit Professional a později byl úplně zastaven. Poslední verze této knihovny nese číslo 2.72.1 a byla vydána 8. 2. 2007. Od té doby žádná nová verze nevyšla (ARToolKit – News, 2007).

4.2

OpenCV

OpenCV (Open Source Computer Vision) je open-source knihovna počítačového vidění dostupná na http://SourceForge.net/projects/opencvlibrary. Je napsaná v jazyce C a C++ a může být použita pod operčními systémy Linux, Windows i MacOS X. V současnosti se aktivně pracuje na vývoji rozhraní pro jazyky

4.3

ARTag

16

Python, Ruby, Matlab a další. OpenCV bylo navhrnuto pro výpočetní výkony s výrazným zaměřením na real-time aplikace. Je napsáno tak, že může využívat výhod vícejádrových procesorů. Jednou z hlavních výhod této konihovny je, že poskytuje jednoduše použitelnou infrastrukturu počítačového vidění, která napomáhá lidem rychle vyvíjet docela sofistikované aplikace. Obsahuje přes 500 funkcí, které postihují mnoho oblastí počítačového vidění, včetně medicínského snímání, bezpečnosti, uživatelského rozhraní, stereovize i robotiky. Protože počítačové vidění a strojové učení jdou ruku v ruce, OpenCV také obsahuje všestranně použitelnou knihovnu strojového učení. Od prvního vydání alfa verze v lednu 1999 bylo OpenCV použito v mnoha aplikacích, produktech i výzkumných projektech. Tyto aplikace zahrnují spojování obrázků dohromady do satelitních a webových map, redukci šumu v medicínských obrazech, analýzy objektů, bezpečnostní systémy a systémy detekce rušení, systémy automatického dohledu a monitoringu a mnoho dalších (Bradski a Kaehler, 2008)

4.3

ARTag

ARTag je systém vzorů rovinných značek pro systémy doplněné reality a systémy interakce počítače s člověkem. Používá značky s bílým nebo černým čtvercovým rámečkem. Celkem je jich v ARTagu definováno 2002. Každý z těchto čtvercových markerů je dále vyplněn mřížkou z černých a bílých buněk o velikosti 6 x 6. Narozdíl od ARToolKitu využívá ARTag pro hledání markerů hranově založený přístup. To znamená, že není nutné se zabývat thresholdováním při různých světelných podmínkách. Také to znamená, že pro správnou funkčnost není potřeba hledat žádné vzory. Pixel hrany, který je nalazen hranovým detektorem, slouží jako základ pro proces detekce markeru. (Ilirzer, 2008)

5

5

VÝBĚR KNIHOVNY PRO TVORBU AR APLIKACE

17

Výběr knihovny pro tvorbu AR aplikace

Jak zmiňují Procházka a Koubek (Procházka a Koubek, 2010), před samotným výběrem knihovny, která bude použita při realizaci vyvíjené aplikace, je důležité uvědomit si a ujasnit si především tyto taktory: • Podporovnané programovací jazyky: Toto kritérium může být velice omezující, protože až na výjimky (např. OpenCV ) podporují knihovny pouze jazyk C, případně C++. • Podporované platformy a architektury: Podpora platforem do jisté míry souvisí s podpooru jazyků. V současnosti může být většina knihoven použita na všech hlavních operačních systém. Horší je to však s podporou operčních systémů mobilních telefonů. • Vývoj knihovny: Další kritérium, které může ovlivnit úspěšný vývoj aplikace. Není-li projekt neustále vyvíjen, udržován a aktualizován, je více než pravěpodobné, že nebude podporovat novější zařízení využívání aplikací. • Dokumentace: Řádné dokumentování projektů bývá obecně často opomíjeno a podceňováno. Avšak mají-li být efektivně vužity všechny prostředky, které knihovna nabízí, je přesná dokumentace více než nutná. • Robustnost knihovny: Spektrum funkcí, které jsou v dané knihovně implementovány, ovlivňuje možnosti jejího využití, resp. nevyužití pro aplikaci. Procházka a Koubek (Procházka a Koubek, 2010) zde také zdůrazňují, že je nezbytné brát v úvahu, zda je projekt neustále rozvíjen, nebo se jedná o „mrtvýÿ projekt. Všechny zmiňované faktory řeší každý vývojář, který hodlá pracovat na aplikaci AR a chce využívat některou z dostupných knihoven. Nejsou to však všechny faktory. Další záleží na účelu, ke kterému má výsledná aplikace sloužit. Jedná-li se o aplikaci, která nějakým způsobem zpracovává obraz (např. v nich hledá nějaké objekty, jako v tomto případě), může být dalším kritériem, které ovlivní výsledné rozhudnutí, způsob, kterým je tato činnosti prováděna, nebo množství implementovaných metod pro registraci objektů. Jak je uvedeno v kapitole věnující se popisu knihoven (kapitola č. 4), přístupů k registraci exituje několik. ARTag nepotřebuje thresholodovat obraz, protože vše srovnává oproti 2002 vnitřně definovaným značkám v podobě černobílého čtverce. ARToolKit má implementovány všechny metody pro registraci značek. Jejich použití je ve výsledku jednodušší než v OpenCV, kde tyto metody přímo implementovány nejsou a uživatel si je musí dopsat sám pomocí metod, které tam obsaženy jsou. OpenCV však zase disponuje metodami, které umožňují pracovat s kamerou mnohem jednodušším způsobem, než jak je tomu v ARToolKitu. V dalších částech této práce bude popisována problematika vývoje aplikace doplněné reality, která umí rozpoznat hledaný marker v obraze. Pro její vývoj byla

5

VÝBĚR KNIHOVNY PRO TVORBU AR APLIKACE

18

vužita knihovna OpenCV, která byla také využita v projektu AuRel, do kterého byla praktická část této práce zaintegrována jako jedna ze součástí.

6

6

POSTUP TVORBY APLIKACE DOPLNĚNÉ REALITY

19

Postup tvorby aplikace doplněné reality

Postup při tvorbě aplikace doplněné reality je možné rozdělit do několika základních bodů, mezi které patří např.: • příprava obrazu – nutné úpravy vstupních údajů (preprocessing), • hledání výrazných oblastí – detekce linií, hran, osamocených bodů, atd., • narovnávní do roviny kamery – upravení prostorově deformovaného markeru do roviny kamery či pozorovatele (v některých případech je tento krok vynecháván), • porovnání markerů se šablonou nebo desriptorem – zjištění míry shody nalezeného markeru a uložené šablony, • akce při pozitivní shodě – v mém případě zobrazení 3D modelu na místě nalezeného markeru. Postup tvorby aplikace doplněné reality je znázorněn na obr. č. 6. Výběr metody, která bude použita při detekci markerů, do jisté míry souvisí s výběrem metody pro jejich srovnávání s uloženou šablonou. Existují totiž přístupy, které tyto dva kroky spojují a zároveň vynechvájí krok narovnávání nalezeného potenciálního markeru do roviny kamery (například metody SURF nebo SIFT ). Pro postupy, které ale tyto kroky oddělují (např. postup popisovaný a použitý v praktické části této práce), existuje několik možností, jak detekovat marker. Většina metod pro detekci markerů však umí pracovat pouze s černobílými obrazy či obrazy v odstínech šedé. Samotnému hledání markerů tak předchází příprava obrazu, neboli preprocessing. Prvním krokem preprocessingu se pak většinou stává převod barevného obrazu na obraz šedý. Takto modifikovaný obraz se dále může různě vyhlazovat či jinak upravovat, aby hledání markerů bylo přesnější. Při těchto operacích se využívá morfologie obrazu a morfologických operací. Teprve s vhodně upraveným obrazem mohou být prváděny pokusy o nalezení markerů. Jak již bylo řečeno, při příravě obrazů se využívá morfologických algoritmů. Jedním z nich je již výše zmiňovné vyhlazení. Řadí se mezi tzv. morfologické filtry a využívá se zejména proto, aby byl z obrazu odstraněn nadbytečný šum. Ten sice z obrazu není nikdy odstraněn úplně, avšak i nepatrná limitace šumu může v kombinaci s dalšími úpravami a kroky značně přispět k lepším výsledkům. Dalším krokem bývá převod šedého, přípaně dále upraveného obrazu na obraz binární, tedy černobílý. Zpracovávání binárních obrazů je ve srovnání s šedými či barevnými obrazy nepopiratlně snazší a jednodušší. Narozdíl od šedých či barevných obrazů jsou totiž v binárních obrazech všechny přechody velmi výrazné. To je důležité zejména pro další krok, kterým může být detekce hran, linií či izolovaných bodů. Konkrétní varianta se může lišit v závislosti na účelu, pro který je aplikace vyvíjena nebo na způsobu, kterým jsou pak nalezené markery

6

POSTUP TVORBY APLIKACE DOPLNĚNÉ REALITY

20

Obr. 6: Znázornění postupu tvorby aplikace doplněné reality

srovnávány s předlohou. Podaří-li se v obraze nalézet takové hrany, které dohromady tvoří uzavřený objekt (propojenou komponentu), předpokládá se, že tyto hrany patří k hledanému markeru a následuje zjišťování souřadnic těchto hran. Jelikož se většinou hledají markery v 3D prostoru, počítá se i s variantou, že tento nalezený marker bude prostorově zdeformovaný. Deformovaný marker je však nutné narovant do roviny kamery. K tomu je využito získaných souřadnic hran a tzv. matice homografie, která popisuje prostorovou deformaci objektu. Často také bývá z obrazu extrahována pouze tato nalezená propojená komponenta, aby se tak usnadnilo srovnávání s šablonou.

7

SROVNÁNí METOD POUŽíVANÝCH PRO DETEKCI OBJEKTŮ V OBRAZE

7

21

Srovnání metod používaných pro detekci objektů v obraze

I přístupů a způsobů, jak nalézt v obraze hledaný objekt, existuje celá řada. Liší se především v tom, jak jsou objekty hledány, a jak jsou nalezené objekty porovnávány. V této práci budou přiblíženy některé metody, které používají detekci hran a detekci bodů.

7.1

Metoda MatchTemplate

Metoda MatchTemplate, potažmo cvMatchTemplate, je jedna z několika možných variant, která může být použita pro registraci markerů v obraze. Je součástí knihovny OpenCV a řadí se mezi metody založené na detekci hran. To znamená, že před samotným použitím této metody je nutné v obraze, mimo jiné, identifikovat hrany, případně provést nějaké další operace. Ale její použití je poměrně snadné. Je to také metoda, která byla pro identifikaci markerků použita při tvorbě praktické části této diplomové práce. Z definice této metody (cvMatchTemplate(const CvArr* image, const CvArr* templ, CvArr* result, int method)) je patrné, že očekává 4 parametry. První parametr, který potřebuje, je obraz, ve kterém se vyskytuje potenciální nalazený marker. Jak bude rozebráno později v kapitole věnující se popisu praktické části, v mém případě se bude jednat o upravaný obraz načtený z kamery. Druhým parametrem, který je nutno funkci předat, je šablona hledaného markeru, vůči které bude obraz z prvního parametru porovnáván. Je nutné, aby obraz v prvním parametru (image) byl širší i vyšší než šablona z druhého parametru (templ). Tato nutnost vyplývá ze způsobu, jakým cvMatchTemplate pracuje. Zjednodušeně řečeno, metoda postupuje tak, že šablonu položí do levého horního rohu obrazu a postupně ji posouvá směrem doprava a dolů. Pro každou pozici pak spočítá míru shody šablony se stejně velkou oblastí v obraze a tuto výslednou hodnotu uloží v podobě pixelu, jehož barva leží někde na stupnici šedé, do obrazu ve třetím paramteru. Ten tedy představuje výstupní hodnotu funkce a reprezentuje mapu pravděpodobnosti výskytu markeru. Rozměry této mapy ve tvaru ka × vka lze vyjádřit vztahem (sirka obrazu − sirka sablony + 1) × (vyska obrazu − vyska sablony + 1). Poslední parametr představuje způsob, kterým je šablona porovnávána s oblastí v obraze. OpenCV nabízí 6 různých způsobů (OpenCV, 2010) . Rozdíl mezi jednotlivými výslekdy poskytovanými různými způsoby výpočtů je znázorněn na obr. č. 7.

7.2

Binární kódy

Další možností, jak porovnávat nelezený marker získaný z obrazu s jeho uloženou předlohou, je využití binárních kódů. Tento způsob porovnávání je v aplikaci Au-

7.3

Detektor SURF

22

Obr. 7: Výsledky jednotlivých variant výpočtů (Procházka, 2010)

Rel označován jako „metoda Golayÿ, neboť je při ní využito Golayova binárního kódu. Proto tento termín bude použit i v této práci. Podobně jako předchozí varianta i tento způsob využívá pro identifikaci markerů v obraze některý z hranových deketorů a řadí se tak mezi metody založené na detekci hran. Golayův kód je využit v mnoha různých aplikacích reálného světa. Binární kód byl použit v různých komunikačních systémech a jeho rozšířená forma byla použita v programu vesmírné logi Voyager během raných 80. let minulého století. Binární forma Golayova kódu je jedním z nějdůležitější typů lineárních binárních blokových kódů. Má zvláštní význam, protože je jedním z několika netriviálních perfektních kódů (Kanemasu). V odkazovaném článku je podrobněji rozepsána problematika proudových a blokových šifer a podrobněji je zde popsán princip Golayova kódu. Jelikož to není předmětem této práce, nebude zde tato problematika rozebírána více do hloubky. „Golayova metodaÿ tedy pracuje na principu binárních kódů. Takže narozdíl od předchozí varianty, která porovnává přímo dva obrazy, tato metoda nejdříve převede podle jasně stanovených pravidel uloženou šablonu i nalezený marker do binární podoby a srovnává až tyto binární tvary. Obrazy jsou pak vyhodnoceny jako shodné, jsou-li tyto binární tvary totožné, nebo je-li míra jejich rozdílnosti v rámci stanoveného limitu.

7.3

Detektor SURF

Další možností, jak zjistit, zda jsou dva obrazy stejné, nebo obsahují stejné části, je využití detektorů bodů. Jedním z nich je detektor SURF – Speeded Up Robust

7.3

Detektor SURF

23

Features, který byl představn v roce 2006 na konferenci ECCV v rakouském Gratzu. SURF je detektor bodů zájmu nezávislý na měřítku a rotaci. Postup hledání shodných částí ve dvou obrazech stejné scény pomocí deketroru SURF může být rozdělen do tří kroků: 1. V první řadě jsou v obrazu vybrány body na významných lokacích (např. rohy, smyčky, atd.). Nejcennější vlastností detektoru těchto bodů našeho zájmu je schopnost opakování, tedy že spolehlivě najde stejné body i v různých světelných podmínkách. 2. Okolí každého bodu je reprezentováno vektorem funkcí. Tento deskriptor musí být výrazný a zárověn robustní vzhledem k šumu, detekci chyb a geometrickým a fotometrickým deformacím. 3. Nakonec jsou vektory deskriptorů srovnávány mezi různými obrazy. Srovnávání je často založeno vzdálenosti mezi vektory (např. Mahalnobisova nebo Euklidova vzdálenost). Rozměr deskriptoru má přímý dopad na čas, který je pro srovnávání zapotřebí. Menší vzdálenost tak představuje menší časovou náročnost. Při realizaci je pro reprezentaci okolí kažédho bodu zájmu použit vektor 64 bodů (Vantacci a Martini, 2009). Cílem vývoje SURFu bylo vytvořit jak detektor, tak deskriptor, který bude v porovnání s nejmodernějšími (v roce 2006, kdy byl představen) detektory a deskriptory rychlejší při výpočtech a přitom nebude ztrácet na výkonu. Aby toto bylo možné zajistit, bylo nutné najít rovnováhu mezi poněkud protichůdnými požadavky. Na jedné straně mělo dojít k omezení velikosti a komplexnosti descriptoru a na straně druhé měla být zachována dostatečná míra specifičnosti. Detektor je založen na Hessově matici (Hessian matrix ), ale používá základní aproximaci. Tato matice je použita proto, že poskytuje dobré výsledky co do výpočetního času i přesnosti. SURF pracuje na podobném principu jako deskriptor SIFT 1 . Dobrý výkon deskriptoru SIFT v porovnání s ostatními deskriptory je pozoruhodný. Zdá se, že jeho kombinování hrubě lokalizovaných informací a rozdělování vlastností vzathujících se ke gradientu poskytuje dobré rozpoznávací možnosti, přičemž potlačuje efekty lokalizačních chyb z hlediska rozměru nebo prostoru. Pomocí relativních sil a orientací gradientů snižuje efekt fotometrikcých změn. Jak již bylo řečeno, na podobných vlastnostech je založen také SURF, ale jeho složitost je daleko nižší. Aby byl deskriptor neměnný v závislosti na rotaci, jsou pro body zájmu identifikovány opakovatelné rotace. Z tohoto důvodu je počítána Haarwaveletová transformace ve směru x a y v kruhovém okolí bodu zájmu o poloměru 6s, kde s je měřítko, ve kterém byl bod detekován. Také krok vzorkování musí být 1

SIFT (Scale-invariant feature transform) je algoritmus počítačového vidění pro detekci a popis lokláních vlastností v obrazu, který byl představen v roce 1999 (http://en.wikipedia.org/wiki/ Scale-invariant_feature_transform)

7.3

Detektor SURF

24

nezávislý na měřítku a proto je prováděn v tomtéž měřítku. Aby bylo vše jednotné, je i waveletová reakce počítána ve stejném měřítku s. Při použití většího měřítka je tak i velikost waveletové transformace větší. Proto jsou využívány integrální obrazy, které umožňují rychlé filtrování. Jakmile jsou waveletové transformace vypočteny a vycentrovány na bod zájmu, jsou výsledky převedeny na prostorové vertikální a horizontální vektory.Dominantní orientace je odhadnuta z vypočetné sumy všech výsledků uvnitř klouzavého okna orientace pokrývající úhel pi/3. Horizontální a vertikální výsledky uvnitř tohoto okna jsou sečteny, čímž je získán nový vektor. Nejdelší takový vektor představje orientaci bodu zájmu. Velikost klouzavého okna je parametr, který je vybrán experimentálně. Malá velikost klouzavého okna vede k zaměření se na jednu dominantní waveletovou reakci, velká velikost zase poskyuje maxima ve vektorech, které jsou mimo rozsah. Obě varianty vedou k nestabilní orientaci oblasti zájmu (Bay, Tuytelaars a Gool, 2006). Kompletní popis způsobu fungování deskriptoru SURF včetně matematických vzorců a dalších podrobností je popsán ve výše odkazovaném článku.

8

KNIHOVNY PRO PRÁCI S 3D MODELY

8

25

Knihovny pro práci s 3D modely

Knihoven, které umí importovat a pracovat s 3D modely v různých formátech, existije celá řada. Jejich výhoda, a zároveň i nevýhoda, spočívá v tom, že vše je již nějakým způsobem připraveno a naprogramováno. Jen nemusí být vždy úplně jasné jak. Integrace podpory pro zobrazovanání a práci s 3D modely do experimentální aplikace v praktické části je důžitá zejména proto, aby bylo možné ověřit, že postup popisované v této práci funkguje tak, jak se očekává. Bude-li tento předpoklad správný, bude se po implementaci na místě nalezeného markeru zobrazovat správně perspektivně deformovaný předem definovaný 3D model.

8.1

Irrlicht

Obr. 8: logo knihovny irrlicht (Irrlicht, 2009)

Irrlicht je platformě nezávislý vysoce výkonný realtime 3D engine napsaný v jazyce C++. Jeho součástí je vysoce výkonné API pro vytváření kompletních 3D a 2D aplikací, jako jsou např. hry nebo vědecké vizualizace. Je poskytován s vynikající dokumentací a integruje všechny nejmodernější vlastnosti pro vizuální reprezentace, mezi které patří například dynamické stíny, částicové systémy, animace osob, vnitřní a venkovní technolgie nebo detekce kolizí. Toto všechno je dostupné pomocí velice dobře navrhnutého C++ rozhranní, které umožňuje snadné použití (Irrlicht, 2009). Mezi jeho hlavní vlastnosti patří: • vysoce výkonnné realtime 3D renderovaní pomocí Direct3D a OpenGL, • nezávislost na plattormě. Tato knihovna je použitelná na systémech Microsoft Windows, Linux, MacOS X, Solaris a dalších, • velká vestavěná a rozšiřitelná knihovna materiálů s podporou vertexů, pixelů, a shaderů, • systém animací postav pomocí animace koster, • částicové efekty, billboardy, mapy světel, mapování prostředí a mnoho dalších efektů, • vazby na několik jazyků, které umožňují engine použít i s jinými jazyky, jako např. C#, Visual Basic, Delphi, Java a další,

8.1

Irrlicht

26

• zahrnuje dva rychlé softwarové rendery nezávislé na platformě a ovladačích. Mají různé vlastnosti (rychlost vs. kvalita) a jsou vybaveny vším potřebným: perspektivně správné mapování textur, bilineární filtrování, Z-buffer, průhlednost, rychlé vykreslování 2D grafiky a další, • výkonný, upravitelný a snadno použitelný 2D GUI systém s tlačítky, seznamy a mnoha dalšími prvky, • čisté, snadno pochopitelné a velmi dobře dokumentované API s mnoha příklady a tutoriály. • je napsán v progarmovacím jazyce C++ a je kompletně objektově orientován, • umožňuje přímý import mnoha formátů » mesh souborů «: Maya (.obj), 3DStudio (.3ds), COLLADA (.dae), Blitz3D (.b3d), Milkshape (.ms3d), Quake 3 levels (.bsp), Quake2 models (.md2), Microsoft DirectX (.x), atd, • pímý import textur: Windows Bitmap (.bmp), Portable Network Graphics (.png), Adobe Photoshop (.psd), JPEG File Interchange Format (.jpg), Truevision Targa (.tga), ZSoft Painbrush (.pcx) a další, • umí rychle a snadno detekovat kolize, • umožňuje přímé čtení z komprimovaných archivů, • má Integrován vlastní rychlý XML parser, • podpora kódování Unicode pro snadné lokalizování, • spolupracuje s nástroji Microsoft Visual Studio, Metroworks Codewarrior, Bloodshed Dev-C++, Code::Blocks, XCode a gcc 3.x-4.x, • engine patří mezi open source sofware a je zdarma. Je možné jej ladit, opravovat chyby a měnit věci, které uživatelům nevyhovují. Je uvolňován pod licencí zlib, nikoliv pod GPL ani LGPL (Irrlicht, 2009). Irrlicht podporuje 6 renderovacích API, což je daleko více, než umí většina ostatních 3D enginů: • Direct3D 8.1, • Direct3D 9.0, • OpenGL 1.2-3.x, • renderovací software enginu Irrlicht, • renderovací software Burningsvideo (Irrlicht, 2009).

8.2

Assimp

27

Aby mohl programátor Irrlicht používat, nemusí vůbec vědět, které API engin používá. Pouze musí enginu sdělit, které API se má snažit preferovat. Existují tři důvody, proč není engin zaměřen pouze na jedno API: • Výkon. Některé grafické adaptéry jsou optimalozovány pro OpenGL, některé jednoduše běží rychleji s Direct3d. • Nezávislost na platformě. Direct3D nebude použielný na stanicích se systémy Mac nebo Linux, zatímco OpenGL možná bude. A když náhodou nebude možné použín ani OpenGL, stále je ještě k dispozici renderovací software enginu Irrlicht, který bude pracovat na kterékoliv z podporovaných platforem. V tomto případě se uživali projistotu zobrazí nějaké upozornění. • Problémy s ovladači, které jsou celkem běžné a uživatel se s nimi potkává při používání 3D software. Existují tisíce hardwarových konfigurací a hry a 3D aplikace často kvůli starým ovladačům padají. Možnost přepínat ovladače by mohla problém vyřešit (Irrlicht, 2009). Poslední verze tohoto enginu s číslem verze 1.7.2 byla zvěřejněna dne 24. 10. 2010.

8.2

Assimp

Obr. 9: logo knihovny assimp (Assimp, 2009)

Open Asset Import Library (zkráceně Assimp) je přenosná open-sourcová knihovna, která umožňuje jednotným způsobem importovat známé formáty 3D souborů. Většina současných verzí umí 3D soubory znovu exportovat a proto je vhodný jako univerzální převodník 3D modelů. K dispozici je také prohlížeč modelů pro systémy Microsoft Windows s názvem AssimpView. Ten umí načíst všechny formáty souborů, které Assimp podporuje, a výborně se hodí pro rychlé prohlížení 3D modelů. Assimp si klade za cíl poskytovat kompletní konverze pro použití v herních enginech nebo realtime renderovacích systémech všeho druhu. V minulosti byl používán v širokém a různorodém spektru aplikací. Je napsaný v jazyce C++ a je poskytován pod licencí BSD. Obsahuje API v jazyce C a umožňuje použití i s jinými jazyky včetně jazyka Python. D. Assimp načítá modely do jednoduchých datových struktur pro další zpracování. Tuto sadu funkcí rozšiřují i různé kroky postprocessingu - od obecných optimalizacních nastrojů

8.3

Ogre

28

přes vypočítávání normál nebo tečných vektorů, až k přizpůsobování importovaných dat podle potřeby uživatele. Mezi jeho hlavní vlastnosti patří: • je napsaný v jazyce C++, • je snadno konfigurovatelný a upravitelný, • rozhraní jádra / API je poskytováno jak pro C++ tak pro C, • obsahuje Command-line rozhraní pro vykonávání běžných operací, jako např. konvertování modelů nebo extrahování textur, • umožňuje importovat kostry, vertexy a animace, • dobře umí pracovat i se vstupními soubory v kódování UNICODE. Mezi podporované formáty 3D modelů a herních souborů patří např.: Collada (.dae), Blender 3D (.blend), 3D Studio Max 3DS (.3ds), 3D Studio Max ASE (.ase), Wavefront Object (.obj), Stanford Polygon Library (.ply), AutoCAD DXF (.dxf), LightWave (.lwo), Modo (.lxo), Stereolithography (.stl), AC3D (.ac), Milkshape 3D (.ms3d). Quake I Mesh (.mdl), Quake II Mesh (.md2), Quake III Mesh (.md3), Quake III BSP (.pk3), Doom 3 (.md5*), Biovision BVH (.bvh), CharacterStudio Motion (.csm). Ostatní podporované formáty souborů: DirectX X (.x), BlitzBasic 3D (.b3d), Quick3D (.q3d,.q3s), Ogre XML (.mesh.xml), Irrlicht Mesh (.irrmesh), Irrlicht Scene (.irr), Neutral File Format (.nff), Sense8 WorldToolKit (.nff), Object File Format (.off), PovRAY Raw (.raw), Terragen Terrain (.ter), 3D GameStudio (.mdl), 3D GameStudio Terrain (.hmp), Izware Nendo (.ndo). Poslední verze enginu Assimp, Assimp 2.0, byla uvolněna dne 21. 10. 2010 (Assimp, 2009).

8.3

Ogre

Obr. 10: logo knihovny ogre (Ogre, 2009)

Ogre (Object-Oriented Graphics Rendering Engine) se stal jedním z nejpopulárnějších open-source grafických renderovacích enginů a je použit ve velkém množštví produkčních projektů v tak odlišných oblastech, jako jsou hry, simulátory, vzdělávací software, interaktivní umění, vědecké vizualizace a další (Ogre, 2009).

8.3

Ogre

29

Disponuje jednoduchým a snadno použitelným objektově orientovaným rozhraním, které bylo navrhnuto pro minimalizaci úsilí potřebného k renderování 3D scén. Je použitelný jak s Direct3D tak s OpenGL a dalšími. Jednou z jeho dobrých vlastností je čistý a přehledný design s úplnou dokumentací všech tříd, které engin obsahuje. Běžné požadavky, jako správa stavu renderování nebo řešení průhledností, jsou prováděny zcela automaticky a šetří tak čas. Plně objektově orientovaný návrh umožňuje s velmi malým úsilím rožšírit funkcionalitu enginu pomocí pluginů a podtříd (Ogre Wiki, 2011). Ogre může být použito na systémech Microsoft Windows (podporovány jsou všechny hlavní verze), Linux a MacOS X. Je přeložitelné pomocí Visual C++ 2003, 2005, 2008 and 2010, ale také pomocí gcc 4+ na Linuxu a MacOS X. Může být použit také pro iPhone (Ogre Wiki, 2011). Výkoný jazyk pro deklarace materiálů umožňuje získat materiál ze zdrojového kódu. Podporuje vertex shadery, a to jak v nízkoúrovňových programech napsaných v assembleru, tak programy napsané v Cg, Direct X 9 HLSL, nebo OpenGL GLSL. Poskytuje automatickou podporu pro mnoho běžných konstatních parametrů, jako např. worldview matice, informace o stavu světel, pozici pozorovatele v prostoru atd. Podporuje techniky pro vícenásobné materiály, což znamená, že je možné navrhovat alternativní efekty pro široký rozsah karet a Ogre automaticky použije nejlepší vhodnou variantu. Načítá textury ze souborů PNG, JPEG, TGA, BMP, PVRTC nebo DDS, včetně neobvyklých formátů jako 1D textury, volumetrické textury, HDR (high dynamic range) a komprimované textury (DXT/S3TC). Akceptuje různé formáty dat a dodržuje koncepci separace vertex bufferů, index bufferů, deklarací vertexů a mapování bufferů. Pracuje se soubory exportovanými z mnoha modelovacích nástrojů včetně Milkshape3D, 3D Studio Max, Maya, Blender a Wings3D. Umožňuje skeletální animace včetně kombinování vícenásobných animací. Hodně přizpůsobitelné a flexibilní řízení scény není vázáno na žádný jeden konkrétní typ scény. Pokud to pragramátorovi vyhovuje, je možné použít předdefinované třídy pro organizaci scény. Jinak je možné připojit vlastní podtřídu a získat tak plnou kontrolu nad organizací scény. Zatímco jiné enginy jsou omezeny tím, že jsou zaměřeny na jeden konkrétní typ, Ogre umožňuje efektivně renderovat jakýkoliv typ, který je možné si představit (Ogre Wiki, 2011). Součástí je také plugin pro podporu práce s terény, který umožňuje vykreslit geo-mipmapové terény. Nastavení cest spline pro objekty scény, včetně subjektů a kamer, které pak mohou být snadno animovány. Další z vlastností je Hierarchický graf scény; uzly umožňují objektům být spolu navzájem propojeny a sledovat všechny ostatní pohyby, kloubové struktury atd. Mezi podporované speciální efekty patří například: • částicové systémy(upravitelné pomocí pluginů, pro snadné nastavování mohou být systémy definovány v texových skriptech),

8.4

Agar

30

• automatická správa průhledných objektů (pořadí renderování a nastavení depth bufferu je nastaveno automaticky), • překryvný systém – umožňuje vytvořit HUD a menu pomocí 2D a 3D objekty, • post-processingové efekty (Ogre Wiki, 2011). Poslední verze číslo 1.7.3 vyšla 8. května 2011.

8.4

Agar

Obr. 11: logo knihovny agar (Agar, 2001)

Agar je moderní open-sourcová multiplatformní sada nástrojů pro tvorbu grafických aplikací implementovaná v jazycích C, C++, Perl a Ada (s možností využití i při vývoji v jiných jazycích). Svým návrhem pro snadnou integraci sleduje filozofi tvorby GUI přímo v aplikaci, namísto jiných způsobů. Grafická knihovna Agar je navrhnuta tak, aby pracovala pod většinou platforem, se kterými je možné používat nějaký grafický display a vstupní zařízení. Počínaje verzí 1.4 je knihovna Agar sestavována bez veškerých závislotí a je dokonce použitelná na zařízeních bez operačního systému. Řadič rozhraní představený ve verzi 1.4 umožňuje snadnější portování na nové platformy a grafické systémy. Stejně jako tradiční sady nástrojů pro tvorbu GUI, může i Agar používat základní rozhranní systémů na bázi oken (napr. Xlib, Windows API). Pokud ale není nic takového k dispozici, může použít svého vlastního správce oken (použito například s SDL ovladači direct-video, s ovladači nízkoúrovňových LCD, framebuffery). Narozdíl od většiny ostatních GUI toolkitů Agar maximálně vužívá hardwarovou grafickou akceleraci všude, kde může. Je-li kompilováno s volitelnou podporou vláken, dodržuje API knihovny Agar bezpečnost vláken. Základ knihovny Agar se snaží být co možná nejkompaktnější. Jednotlivé knihovny rozšiřující Agar v mnoha specializovaných aplikacích zahrnují Agar-MATH (matematické rozšíření), Agar-VG (vektorová grafika), Agar-RG (grafika založená na bodech), Agar-DEV (vývojářské nástroje) nebo FreeSG (graf scény a výpočetní geometrie). Agar je freeware software. Jeho zdrojové kódy jsou volně šiřitelné pod licencí BSD, což umožňuje jeho použití i v komerčních aplikacích bez poplatků. Jedná se o stabilní, pravidelně udržovaný a rostoucí projekt už od roku 2002. Jeho sponzoring a hosting zajišťuje Csoft.net. Aktuální verze nese číslo 1.4.1 a datum jejího zveřejnění je 20. 3. 2011. (Agar, 2001)

8.5

8.5

Unreal Engine

31

Unreal Engine

Obr. 12: logo knihovny Unreal Engine 3 (UnrealTechnology, 2011)

Každý aspekt Unreal Enginu verze 3 byl navrhnut se zřetelem na snadné vytváření obsahu a programování, s cílem vložit co možná nejvíce moci do rukou umělců a návrhářů při vývoji modelů ve vizuálním prostředí a s cílem dát programátorům vysoce modulární, škálovatelný a rozšiřitelný framework pro tvorbu, testování a sestavování her v široké škále žánrů. Unreal Engine 3 je integrován s řadou předních middleware technologií prostřednictvím integrovaného partnerského programu Epic Games. Byly provedeny kontinuální optimalizace, aby se z Unreal Enginu stal vysoce vyspělý nástroj, který je masivně celosvětově podporován. Jeho pokročilý toolset je specificky navrhnut tak, aby se zvýšila produktivita vývojářů při vývoji ultra-komplexních obsahů nové generace (UnrealTechnology, 2011). Unreal animační systém je systém skeletální animace, který poskytuje plnou kontrolu nad každým detailem, každým svalem a každou kostí. Pomocí něj lze vytvořit dynamičtější vlastní svět a přidat do něj více osobitosti pomocí detailních animací. Tento engine podporuje ovlivňování až 4 kostí v jednom vertexu a tím umožňuje vytvářet jemné rozdíly ve všech scénách. Také je zde přímo zaintegrována plná podpora úrovní detailů kostí. Prohlížecí nástroj AnimSet umoňuje upravovat animace a prohlížet 3D soubory. Tím nabízí možnost přidat upozornění ke konkrétnímu bodu animace pro každou hru zvlášť a umožňuje umístit spoj na kosti tak, aby mohly být použity pro připojení objektů ke kostře během hraní (UnrealTechnology, 2011). Systém umělé inteligence této knihovny poskytuje robustní systémy pro AI a navigaci. Unreal Engine 3 podporuje automatické vytváření a použití navigačních buňek, což poskytuje postavám ovládaným AI zvýšené povědomí o jejich prostředí a dává jim schopnost dělat lepší rozhodnutí týkající se pohybů. Implementace navigační buňky Unreal enginu 3 optimalizuje výkon a vyžívaní paměti umělé inteligence v mnoha scénářích ve srovnání s tradičními node-based systémy. Systém navigačních buňek poskytuje přesnou reprezentaci průchozího prostoru AI přes připojený graf konvexních polygonů (UnrealTechnology, 2011).

8.6

Delta3D

32

Vývojáři této knihovny poskytují licenci zkušeným profesionálním programátorům her. Uživatelé s licencí získají kompletní zdrojové kódy, nástroje a nejnovější hry. Podpora je poskytována přímo od vývojářského týmu Unreal Enginu (UnrealTechnology, 2011). Mimo této placené licence existuje i bezplatná. Ta se však nevztahuje ne komleptní knihovnu, ale pouze na verzi Unreal Developers Kit (UDK). UDK je zdarma pro vzdělávací a nekomerční účely, což znamená, že ji bezplatně mohou používat studenti, školy, vědecké instituce a další. Ostatní způsoby použití jsou zpoplatněny (UnrealDevelopmentKit, 2010).

Obr. 13: logo knihovny Unreal Development Kit (UnrealDevelopmentKit, 2010)

8.6

Delta3D

Obr. 14: logo knihovny Delta3D (Delta3D, 2011)

Delta3D je open-source engine, který může být použit pro hry, simulace a ostatní grafické aplikace. Jeho modulární návrh integruje dobře známé opensourcové projekty jako například OpenSceneGraph (OSG), Open Dynamics Engine (ODE), Character Animation Library (CAL3D) a OpenAL, nebo třeba projekty jako Qt od Trolltechu, Crazy Eddie’s GUI (CEGUI), Xerces-C, Producer, InterSense Tracker Drivers, HawkNL a Game Networking Engine (GNE). Delta3D integruje základní moduly do snadno použitelného API, které umožňuje přímý přístup k důležitému základnímu chování kdykoliv je to potřeba. Delta3D renderuje pomocí knihoven OpenSceneGraph a OpenGL. Primárním cílem Delta3D je poskytnout jednoduché a flexibilní API se základními prvky potřebnými pro všechny vizualizační aplikace. Kromě základních složek nabízí Delta3D řadu nástrojů, jako je simulace, výcvik a editor her (STAGE), kompilátor BSP, editor částic, samostatný prohlížeč modelů. Dále má Delta3D rozsáh-

8.7

OpenSceneGraph

33

lou architektonickou sadu, která je integrována v celém enginu. Tato sada obsahuje frameworky, jako je Application Base Classes (ABC) pro zahájení práce, Dynamic Action Layer (DAL) pro vlastnosti a parametry aktorů a podporu signálů a slotů pro přímé propojování metod,Game Manager (GM) pro spávu aktorů, zásuvné moduly pro čtení, renderování a upravování terénu, nebo modul pro vysoko úrovňové zasílání zpráv pro komunikaci aktorů. Jádro tohoto enginu obsahuje veškerou základní funkcionalitu: • mapování vstupních zařízení (klávesnice, myš, joystick, trakery), • pohybové modely (Fly, UFO, Walk, Orbit, First Person), • renderování prostředí (mraky, mlha, obloha, denní doba), • efekty částicových systémů (kouř, exploze, uživatelské), • načítání souborů – .3dc, .3ds, .ac, .dw, .flt, .geo, .ive, .logo, .lwo, .lws, .md2, .obj, .osg, .tgz, .x, .zip – .bmp, .dds, .gif, .jpg, .pic, .png, .pnm, .rgb, .tga, .tiff, .txp – .wav • ovladače kamery (úhel pohledu, stativ), • podpora více kamer, • podpora více oken, • osvětlování OpenGL, • uzly bezierovy cesty, • plná podpora OpenGL 2.0, • GLSL vertex a fragment shaders. Poslední verze s číslem 2.5.0 vyšla 9. listopadu 2010 (Delta3D, 2011).

8.7

OpenSceneGraph

OpenSceneGraph je open-sourcový multiplatformní grafický toolkit pro vývoj vysoce výkonných grafických aplikací jako jsou letecké simulátory, hry, aplikace virtuální reality a vědecké vizualizace. Je založen na konceptu SceneGraph a poskytuje objektově orientovaný framework postavený nad OpenGL. To umožňuje vývojářům vynechat implementaci a optimalizace nízkoúrovňových grafických volání a poskytuje mnoho dalších nástrojů pro rychlý vývoj grafických aplikací.

8.7

OpenSceneGraph

34

Obr. 15: logo knihovny OpenSceneGraph (OpenSceneGraph, 2007)

Cílem OpenSceneGraph je, aby výhody technologie byly dostupné pro všechny komerční i nekomerční uživatele. Celý je napsaný ve standardním C++ a OpenGL a využívá open-source vývojový model, aby poskytl vývojářskou knihovnu, která je volně použitelná a která je zaměřená na potřeby koncových uživatelů. Klíčové silné stránky OpenSceneGraph jsou její výkon, škálovatelnost, přenosnost a produktivita spojená s plně funkční knihovnou. Knihovna podporuje vertex arrays, vertex buffer objects, OpenGL Shader Language, Level Of Detail (LOD), a další. Toto vše dohromady dělá z OpenSceneGraph jeden z nejvýkonějších dostupných grafických toolkitů. Jádro knihovny shrnuje většinu funkcí OpenGL, včetně nejnovějších rozšíření, nabízí renderovací optimalizace, a celou řadu knihoven a doplňků, které umožňují velice rychle vytvořit vysoce výkonné grafické aplikace. Vývojář aplikace je tak osvobozen od nutnosti soustředit se na obsah a způsob, jakým je obsah kontrolován. Kombinace zkušeností z navazujících knihoven, například Performer nebo Open Inventor, a moderních metoda softwarového inženýrství jako Design Patterns, spolu s velkým množstvím zpětné vazby z počátku vývojového cyklu, umožnila navrhnout čistou a rozšiřitelnou knihovnu. Toto vše dělá z OpenSceneGraph knihovnu, na kterou mohou uživatelé snadno přejít a integrovat ji do vlastních aplikací. Pro čtení a zápis z a do databází přidává databázová knihovna osgDB podporu pro různorodé databázové formáty pomocí mechanizmu rozšiřitelného dynamického pluginu. Distribuce nyní zahrnuje 55 samostatných modulů pro načítání různých 3D databází a obrázkových souborů. Mezi podporované 3D databáze patří COLLADA, LightWave (.lwo), Alias Wavefront (.obj), OpenFlight (.flt), TerraPage (.txp), Carbon Graphics GEO (.geo), 3D Studio MAX (.3ds), Peformer (.pfb), AutoCAD? (.dxf), modely postav Quake (.md2). Direct X (.x) a Inventor Ascii 2.0 (.iv) / VRML 1.0 (.wrl), Designer Workshop (.dw) a AC3D (.ac) a nativní .osg ASCII formát. Podporované obrázkové soubory zahrnují např. .rgb, .gif, .jpg, .png, .tiff, .pic, .bmp, .dds (včetně komprimovaných MIP mapových snímků), .tga a QuickTime (pod OSX). Jádro této knihovny bylo navrhnuto tak, aby bylo minimálně závislé na konkrétní platformě. To umožnilo, aby se OpenSceneGraph rychle přenesl na celou řadu platforem. Původně byl vyvinut pro IRIX, pak byl portován na Linux a později Microsoft Windows, FreeBSD, MacOS X, Solaris, HP-ux, AIX a dokonce i PlayStation 2 (OpenSceneGraph, 2007). Aktuální verze nese číslo 3.0.1 a byla zveřejněna 31. července 2011.

9

9

VÝBĚR KNIHOVNY PRO PRÁCI S 3D MODELY

35

Výběr knihovny pro práci s 3D modely

Podobně, jako při výběru knihovny pro tvorbu AR aplikací (viz kapitola č. 5), je i při výběru knihovny pro práci s 3D modely zvážit stejné aspekty: • podporovnané programovací jazyky, • podporované platformy a architektury, • vývoj knihovny, • dokumentace, • robustnost knihovny. Mimo tyto je však v tomto případě vhodné do úvah zahrnout i několik dalších aspektů. Jelikož se totiž jedná o knihovny, které nějakým způsobem pracují s grafickými objekty a využívají k tomu více či méně grafické možnosti počítače, na kterém pracují, měly by být při výběru zohledněny například ještě tyto aspekty: • Podporované 3D modely: Podpora různých formátů 3D modelů, které mohou být použity, je podle mého názoru jeden z prvních aspektů, který by měl být zkoumán a hodnocen. Čím více možností spolupráce knihovna nabízí, tím může být její použití univerzálnější a jednodušší. • Podporované 2D textury: Aby výsledná scéna vypada co možná nejreastičtěji, je nutné, aby použitá knihovna umožňovala na použitý 3D model namapovat také nějakou texturu. Opět zde platí, že čím více formátů knihovna podporuje, tím jednodušší bude její použití. • Použitý renderovací software: V případech, kdy je reálná možnost, nebo je to dokonce požadavek, že aplikace bude spouštěna na více než jedné platformě, by bylo asi vhodné, kdyby knihovna nedisponovala pouze jednou možností renderovaní. Nekompatibilní render a platforma by pak způsobovaly problémy. Všechny knihovny představené v předchozí kapitole mají kompletní online dokumentaci a jsou nadále vyvíjeny. Nejedná se tedy o „mrtvé projektyÿ. Co se týče robustnosti, tak například knihovna Unreal Engine je sice velmi robustní projekt, nicméně její použití je vhodnější spíše pro hry než aplikace doplněné reality. Navíc její použití je zpoplatněno. Podrobnější shrnutí zde uváděných grafických knihoven poskytuje tabulka č. 1.

OpenSceneGraph

Delta3D

Unreal Engine

Agar

Ogre

Assimp

Irrlicht

knihovna

C++

C, C++

IRIX, Linux, Windows, FreeBSD, Mac OS X, PlayStation, . . .

nezjištěno

C, C++, Perl, Ada, dots

C++,Python, Java, C#, .NET

.gif, .png, .jpg, .bmp, .tga, .dds, . . .

.bmp, gif, .jpg, .png, .tga, .txp, . . .

.3ds, .ac, .geo, .md2, .obj, .zip, . . . .dae, .iv, .wrl, .3ds, .geo, .md2, . . .

nezjištěno

nezjištěno

.png, .jpg, .tga, .bmp, . . .

nezjisteno

nezjištěno

nezjištěno

.dae, .3ds, .blend, .md3, .irr, .ms3d, . . . Blender, Milksahpe, 3D Studio

.jpg, .bmp, .png, .psd, . . .

.obj, .dae, .ms3d, md2, .x, .3ds, . . .

C#, VisualBasic, Delphi, Java,. . . C, C++, Python, . . .

2D textury

3D modely

jazyky

Windows, Linux

Windows, Linux, Mac OS X, FreeBSD, OpenBSD a další Windows, iOS, Adobe Flash, Google Adnroid,. . .

Windows, Linux, Mac OS X

platformy Windows, Linux, OSX, Sun, platformy používající SDL

Tab. 1: Shrnutí aspektů popisovaných knihoven

9 VÝBĚR KNIHOVNY PRO PRÁCI S 3D MODELY

36

10

NÁVRH VLASTNíHO ŘEŠENí

10

37

Návrh vlastního řešení

Tato kapitola popisuje jedno z možných řešení, kterým lze pomocí prostředků knihovny OpenCV v obraze nalézt hledaný marker a následně na jeho místo zobrazit odpovídajícím způsobem perspektivně deformovaný 3D model. Jelikož se v mém případě jedná o analýzu videa načítaného z kamery, je vše prováděno uvnitř cyklu, který vypadá takto: while(key!=27){ frame = cvQueryFrame( capture ); ... key = cvWaitKey(35); } Proměnná key je datového typu char a slouží pro ukládání znaků načtených z klávesnice. Metoda cvWaitKey(int miliseconds), která na konci každého cyklu mění její hodnotu, pozdrží další provádění na tak dlouho, kolik je uvedeno v jejím parametru a vrací znak, který uživatel stiskl. První řádek tohoto cyklu zajišťuje postupné pravidelné načítání obrazů z kamery. Metoda cvQueryFrame(CvCapture *capture) čeká jako parametr zdroj videa, ze kterého postupně vrací jednotlivé framy. Ty jsou v mém případě ukládány do proměnné IplImage *frame. Zdrojem videa může být jednak nějaký video soubor, např. avi, jednak přímo kamera. Úplný popis metod a jejich parametrů je dostupný v online dokumentaci2 .

10.1

Detekce markerů v obraze

Před tím, než může započít jakákoliv analýza, která by mohla poskytnout kýžený výsledek, je nutné udělat ještě několik přípravných kroků. 10.1.1

Preprocessing – příprava obrazu

Většina metod knihovny OpenCV zpracovávajících nějakým způsobem obraz umí pracovat pouze ve stupních šedi. Takže první věc, kterou je potřeba s načteným framem provést, je převést jej na šedý obraz. K tomu lze použít metodu cvCvtColor(const CvArr* src, CvArr* dst, int code). První dva parametry představují vstupní a cílový obraz. Posledním je definováno, z jakého barevného modelu na jaký se má obraz převádět. cvCvtColor(frame, gray, CV BGR2GRAY); V mém případě dostavá metoda jako vstupní data, která se budou konvertovat na jiný barevný model, obraz v proměnné frame. Výsledek této konverze bude uložen 2

http://opencv.willowgarage.com/documentation/c/index.html

10.1

Detekce markerů v obraze

38

do proměnné gray, která je stejně jako frame ukazatel datový typ IplImage. Z posledního parametru CV BGR2GRAY je patrné, že převádět se bude z barevného prostru BGR na stupeně šedi. Dalším krokem, který ale není nezbytně nutný, je vyhlazení. Může se tak předejít některým chybným pozitivním identifikacím. Rozdíl mezi vyhlazeným a nevyhlazeným obrazem je ukázán na obrázku č. 16. I k tomuto kroku je OpenCV

Obr. 16: Rozdíl mezi nevyhlazeným (vlevo) a vyhlazeným (vpravo) obarazem

vybaveno – obsahuje metodu cvSmooth(). Použití v této práci je následující: cvSmooth(gray, smooth, CV GAUSSIAN); První parametr opět představuje obraz, se kterým se bude pracovat, druhý proměnou, kam se uloží výsledek operace. Poslední představuje způsob vyhlazení. V online dokumentaci knihovny OpenCV je uvedeno 5 možných způsobů, kterými může být obraz vyhlazen. Poslední dostačující úpravou je prahování obrazu.To spočívá ve stanovení vhodné prahové hodnoty. Za normálních okolností je vše, co je větší než prahová hodnota, nastaveno na hodnotu 255 nebo na uživatelem definovanou maximální hodnotu, vše co je menší nebo rovno, je nastaveno na hodnotu 0. Pomocí různých trhesholdovacích typů lze ale výsledné chování mírně upravit. Viz obr. č. 17. Výsledkem thresholdování je tedy buď pouze dvoubarevný obraz, nebo obraz bez špicek nad nebo pod prahovou hodnotou. Takto upravený obraz už může být lépe a jednodušeji analyzován. Během tvorby praktické části práce, jsem zkoušel několik různých prahových hodnot. Problém však byl, že výsledek byl různý za různých světelných podmínek a ne vždy byl výsledek dostačující. OpenCV nabízí několik variant thresholdovacích funkcí. Při prvních pokusech byla použita funkce cvThreshold(const CvArr* src, CvArr* dst, double threshold, double maxValue, int thresholdType). V průběhu prací a po konzultacích však

10.1

Detekce markerů v obraze

39

Obr. 17: Možné varianty výsledku prahování (OpenCV documentations, 2011)

byla jakožto vhodnější varianta použita metoda adaptiveThreshold, která hodnotu prahu nastavuje automaticky: cvAdaptiveThreshold(smooth, threshAdapt, 255, CV ADAPTIVE THRESH GAUSSIAN C, CV THRESH BINARY INV, 101, 5); Navíc, jak lze z ukázky kódu vidět, bylo také využito možnosti ovlivnit způsob prahování. Pro thresholdování byla vybrána inverzní binární metoda. Tedy vše, co bylo větší než práh, bylo nastaveno na hodnotu 0, vše ostatní bylo nastaveno na hodnotu 255. Jak to vypadá v praxi je znázorněno na obr. č. 18. V některých případech může být také výhodné analyzovaný obaz před všemi těmito úpravami zmenšit. Zpracovávání a analýzy na menších obrazech jsou rychlejší, ale také mohou být více či méně nepřesné. Takže tento krok je nutné zvážit podle konkrétní situace a požadavků na výsledek. V každém případě je k tomuto kroku možno použít metodu cvResize(const CvArr* src, CvArr* dst, int interpolation = CV INTER LINEAR). Také tato metoda byla použita v prak-

10.1

Detekce markerů v obraze

40

Obr. 18: Výsledek thresholdování obrazu

tické části mé práce, neboť tímto krokem došlo k mírnému zrychlení celého procesu a poskytovaný výsledek byl dostačující. 10.1.2

Detekce vrcholů potenciálních markerů

Po předchozích krocích je v proměnné threshAdapt uložen obraz, který už může být použit pro další analýzy a samotné hledání požadovaných markerů. Dalším krokem tak bude v připraveném dvoubarevném obraze nalézt hrany a kontury a následně jejich body a průsečíky. OpenCV opět nabízí několik variant, kterými lze hrany a kontury hledat. V této práci budou přiblíženy pouze 3. 1. Metoda cvCanny – první z metod, které byly v průběhu praktických prací použity a vyzkoušeny, a které zde budou trochu přiblíženy. Tato metoda hledá hrany v obraze pomocí algoritmu Canny86, jinak také známého jako Cannyho hranový detektor. Celá definice metody vypadá následovně: cvCanny(const CvArr* image, CvArr* edges, double threshold1, double threshold2, int apertureSize = 3). Obrázek č. 19 ukazuje výsledek jejího použití. Jak je vidět v definici samotné metody, očekává na vstupu mimo jiné obraz, který bude zpracovávat a výsledek vrací opět v podobě obrazu. Hrany jsou sice nalezeny, viz obr. č. 19, ale výsledek v podobě dalšího obrazu není úplně ideální. Pro další zpracovávání by bylo opět nutné analyzovat obraz. Lepší variantou by bylo, kdyby nalezené kontury byly rovnou uloženy do nějaké datové struktury, která by se dala zpracovávat jednodušeji. 2. Metoda cvHoughLines – další ze zkoušených metod. Tato hledá hrany v binárním obraze pomocí standardní Houghovy transformace. Stejně jako Cannyho hranový detektor umí i tato metoda zpracovávat pouze binární ob-

10.1

Detekce markerů v obraze

41

Obr. 19: Výsledek metody cvCanny

razy, avšak jistý rozdíl mezi nimi je. ZatímcocvCanny vrací výsledek v podobě obrazu, cvHoughLines ukládá nalezené hrany do zvláštní datové struktury, takže jejich další zpracování je jednoodušší. Na stejném principu funguje také cvHoughCircles. Liší se pouze v tom, že cvHoughLines hledá linie a cvHoughCircles hledá kruhy. Důvod pro použití varianty hledající linie byl ten, že hledané markery jsou čtvercové. 3. Metoda cvFindContours – poslední z vyzkoušených možností pro hledání hran a kontur. Podobně jako předchozí varianta ukládá nalezené kontury do datové struktury pro snazší další zpracování, avšak poskytované výsledky byly lepší. Proto byla nakonec využita metoda cvFindContours()Její použití v praktické části je následující: cvFindContours(threshAdaptCopy, storage, &firstContour, sizeof(CvContour), CV RETR CCOMP, CV CHAIN APPROX SIMPLE, cvPoint(0,0) ); Výsledné nalezené kontury jsou zobrazny na obrázku č. 20. Pro lepší znázornění vnitřních a vnějších kontur jsou vykresleny do původního barevného obrazu. Jak již bylo řečeno, nalezené kontrury jsou v tomto případě ukládány do zvláštní datové sruktrury. Tou je struktura cvSeq. Díky způsobu, jakým je tato struktura definována, je další zpracovávání (analýza, vykreslení, . . . ) poměrně snadné. V okamžiku, kdy je tedy obraz zpracován a nějaké kontury jsou v něm nalezeny, přichází řada na jejich analýzu. Nejdříve je nutné vyfiltrovat pouze relevantní kontury a ostatní rovnou vyřadit a vůbec se jimi nazabývat. Relevantní kontury jsou takové, které mají právě 4 strany, mají nějaké potomky a tito potomci mají alespoň 4

10.1

Detekce markerů v obraze

42

Obr. 20: Výsledek metody cvFindContours

strany. Důvod, proč musí být splněny zrovna tyto podmínky, vychází z používaných makerů. Každý použitý a hledaný marker musí mít tlustý bílý kraj, a silný černý rámeček, uvnitř kterého je pak samotný marker (možno si všimnout na předchozích ukázkách z praktické části). Pokud jsou makrery vyrobeny tímto způsobem, značně to zvyšuje šanci jejich správně detekce. Pokud tedy existuje nějaká kontura, která splňuje všechny dříve zmiňované podmínky, lze předpokládat, že patří k hledanému markeru. Následujícím krokem je nalezení zjištění čtyř rohových bodů – průsečíky stran a jejich namapování na šablonu, která bude sloužit k porovnání. K tomuto účelu byla vyrobena vlastní metoda calculateQuadrupes(CvSeq * copyCountour, CvMat * markerCornersMat, CvMat* foundCornersMat, CvPoint2D32f* markerCorners, CvPoint2D32f * foundCorners). Prvním paramatertem je ona kontura vztahující se k potenciálnímu markeru. Ostatní čtyři parametry slouží pro uložení vypočetných hodnot, se kterými se bude pracovat později. Jsou to tedy výstupní paramtery. Samotné zjišťování rohových bodů je zajištěno tímto cyklem: const int points = copyCountour->total; for (int point = 0; point < points; point++){ CvPoint p; CV READ SEQ ELEM(p, reader); foundCorners[point].x=(float)p.x; foundCorners[point].y=(float)p.y; } Tento cyklus neudělá nic jiného, než že postupně projde celou konturu a hraniční body uloží do výstupní proměnné předané v parametru funkce.

10.1

Detekce markerů v obraze

10.1.3

43

Matice homografie a narovnávání obrazu

Poté, co jsou vypočteny i všechny ostatní hodnoty pro výstupní parametry, dochází, podle mého názoru, na jednu z nejzajímavějších částí práce – výpočet matice homografie a narovnávání obrazu do roviny kamery. Matice homografie je čtvercová matice o velikosti 3 × 3. Její výpočet je důležitý zejména pro přesné zjištění polohy a natočení markeru v prostoru. Následně je také využita pro natáčení a pozicování vkládaných doplněných informací. V mém případě se jednalo o 3D modely. OpenCV pro tuto operaci nabízí metodu cvFindHomography(const CvMat* srcPoints, const CvMat* dstPoints, CvMat* H, int method=0, double ransacReprojThreshold=0, CvMat* status = NULL). Ta za pomocí rohových bodů získané kontury a bodů šablony markerů dopočte tuto tak důležitou transformační matici: cvFindHomography(foundCornersMat, markerCornersMat, homography); Na zkáladě matice homografie může dojít k narovnávání obrazu do roviny kamery. Výsledkem této operace bude obraz, v jehož levém horním rohu nalezený potenciální marker, postaven kolmo k pozorovateli potažmo kamereř a ostatní data v obrazu budou ohnuta v příslušném úhlu (obr. č. 21). Funkce, která se o tuto transformaci postará, je cvWarpPerspective(const CvArr* src, CvArr* dst, const CvMat* mapMatrix, int flags = CV INTER LINEAR+CV WARP FILL OUTLIERS, CvScalar fillval=cvScalarAll(0)). Za pozornost stojí první tři parametry. První představuje originální obraz načtený z kamery, třetí vypočtenou matici homografie. Druhý parametr představuje proměnnou, do které je uložen narovnaný obraz: cvWarpPerspective(m frame, birdsEye, homography); Aby se zrychlil proces porovnávání nalezeného potenciálního markeru s jeho uloženou šablonou, je vhodné z narovnaného obrazu vyříznout pouze tu část, která nás zajímá. Pro tento účel byla vatvořena vlastní funkce cropImage(IplImage* image, int rightBottom). Ta v parametrech očekává obraz, ze kterého se bude vyřezávat a určení velikosti oblasti. Protože hledané markery mají čtvercový tvar, stačí pouze jedno hodnota, která zároveň určuje šířku i výšku výlsedného oříznutého obrazu. Ten je návratovou hodnotou této funkce. Princip ořezávání spočívá v nastavení hodnoty ROI (Region Of Interest) a následném vykopírování této „oblasti zájmuÿ. Nejdůležitější část této funkce vypadá tedy takto: CvRect rect = cvRect(0, 0, rightBottom, rightBottom); cvSetImageROI(imgCopy, rect); cvCopy(imgCopy, subimg); cvResetImageROI(imgCopy); Prvním příkazem se vytvroří čtverec, který představuje zmiňovanou oblast našeho zájmu. Je umístěn do levého horního rohu, protože právě tam se nachází narovnaný

10.1

Detekce markerů v obraze

44

Obr. 21: Obraz narovavný metodou cvWarpPerspective

potenciální marker. Následuje vytvoření ROI. Pro případ nežádoucí modifikace obrazu se pracuje s jeho kopií. V okamžiku, kdy je definováná oblast zájmu, může být tato zkopírována a vložena do připraveného nového obrazu, který je předán jako návratová hodnota funkce. Před tím je však vhodné ještě odstranit nadefinovanou oblast ROI, aby nedocházelo k nějakým obtížím při dalších možných operacích. 10.1.4

Srovnání šablony a nalezeného markeru

Po všech předchozích krocích, které zde byly popsány, je z původního obrazu získaná menší část, která je uložená v separátní proměnné. Rozměry této malé části jsou naprosto stejné, jako velikost uložené šablony, se kterou se bude tato část získaná z videa porovnávat. Mým úkolem v praktické části bylo k tomuto úkonu použít funkci cvMatchTemplate(const CvArr* image, const CvArr* templ, CvArr* result, int method). Jak již bylo popsáno dříve, tato metoda přebírá 4 parametry: nalezený marker, uloženou šablonu, obraz pro uložení výsledků a specifikaci metody. Podrobnější princip jejího fungování je rozebrán v kapitole č. 7.1. Výsledkem této metody je „mapa pravděpodonosti shodyÿ šablony s nalezeným markerm. Velikost této mapy je (sirka obrazu − sirka sablony + 1) × (vyska obrazu − vyska sablony + 1). V mém případě je to tedy 1 × 1, neboť rozměry šablony a nalezeného markeru jsou totožné. Dalším krokem po získání mapy pravděpodobnosti je zjistění extrémů – minima a maxima. K tomu lze využít metodu cvMinMaxLoc(const CvArr* arr, double* minVal, double* maxVal, CvPoint* minLoc=NULL, CvPoint* maxLoc = NULL, const CvArr* mask=NULL). Prvním parametrem je obraz, který se bude zkouat. V mém případe je to získaná mapa pravděpodobnosti. Další čtyři parametry představují výstupní hodnoty v podobě vypočtených výsledků. Těmi jsou: hodnota minima,

10.2

Načítání a zobrazování 3D modelů

45

hodnota maxima, souřadnice bodu s minimální hodnotou a souřadnice bodu s maximální hodnotou. Vzhledem k tomu, že v mé praktické části je velikost mapy 1 × 1, hodnoty minima a maxima budou totožné. Stejně tak budou totožné souřadnice obou extrémů – budou v jediném bodě výsledku, na souřadnici (1, 1). Avšak v případech, kdy je nalezený marker větší než šablona a velikost mapy není pouze jeden jedniný bod, jsou hodnoty i souřadnice různé. To, jaký extrém je v obraze nutné nalézt, zavisí na hodnotě čtvrtého, tedy posledního, parametru hodnoty cvMatchTemplate. V závislosti na použitém způsobu porovnávání nalezeného markeru a šablony, je pak pro další práce použita hodnota a souřadnice minima nebo maxima. Pro určení míry shody šablony a markeru opět slouží prahová hodnota. V takto nalezeném a vyhovujícím bodě extrému pak leží levý horní markeru.

10.2

Načítání a zobrazování 3D modelů

Aby se dalo ověřit, že výše popsaný postup je správný a vede k požadovanému výsledku, bylo nutné také v rámci praktické části této práce zaintegrovat podporu pro práci s 3D modely. Pro tuto práci byl z počátku vyvtořen vlastní způsob načítání, avšak ten se ukázal jako nevhodný. Pokud by tímto způsobem měla být přídávána podpora pro nějaká další 3D modely, znamenalo by to, že by opět muselo být vše vytvořeno ručně na míru. Proto byla pro tuto část nakonec vybrána knihovna třetí strany, která byla pouze do stávajícího řešení vhodně zaintegrována. Z několik možných variant byla vybrána knihovna Irrlicht. Pro vytvoření okna, načtení modelu a jeho zobrazení by za normálních okolností stačilo všehovšudy asi 10 příkazů. Jelikož ale bylo nutné vužít prostředků již existujícího stavajícího řešení a podporu do něj zaintegrovat, bylo řešení o něco málo složitější. Vše v knihovně Irrlicht je rozděleno do jmenných prostorů. Základním z nich je jmenný prostor irr. Ten mimo tříd, funkcí, konstat a definovaných datových typů obsahuje ještě šest dalších jmenných subprostrů: core, gui, lo, scene, scene::quake3 a video. Tím je vše v této knihovně rozdělené do logických celků, čímž je dosaženo rozumné přehlednosti. Engin se aktivuje následjícím příkazem: irr::IrrlichtDevice *device = irr::createDevice(). Teto funkce může v parametrech přejímat velikost okna, které bude pro účely Irrlichtu vytvořeno, určení vykreslovacícho enginu a další. Bohužel však nelze předat žádný identifikátor již existujícího okna. Proto musela být vužita funkce, které lze tento identifikátor předat: irr::createDeviceEx(*irr Params). Té narozdíl od předchozí varianty může být předáno mnohem více parametrů. Když je Irrlicht aktivován, je zněj extrahován grafický ovladač a manažer scény. Oba údaje jsou loženy do proměných, neboť jsou dalé využívány: video::IVideoDriver* driver = device->getVideoDriver(); scene::ISceneManager* scenemgr = device->getSceneManager();

10.3

GUI pro zadávání vstupních parametrů

46

Po získání manažera scény do ní může být přidán jeden i více 3D modelů. K tomu slouží v irrlichtu hned několik funkcí, které se liší tím, s kterými modely umí spolupracovat. V mém případě je prozatím počítáno s modely .3ds a .md3, které jsou oba načítání stejnou funkcí. Také je zapotřebí definovat pozici pozorovatele: scene::ISceneNode* node = scenemgr->addAnimatedMeshSceneNode( scenemgr->getMesh("path to 3d model")) scenemgr->addCameraSceneNodeFPS(); Samotné vykreslení scény je pak zajištěno třemi prikazy, které jsou za normálních okolností volány v nekonečném cyklu. V mém případě však nekonečná smyčka žádoucí není: driver->beginScene() scenemgr->drawAll() driver->endScene()

10.3

GUI pro zadávání vstupních parametrů

Poslední částí praktické práce bylo vytvoření grafického uživatelského rozhraní, které by sloužilo pro snadné zadávání parametrů, se kterými se pak bude celá aplikce spouštět. Těmito paramatery jsou: • detekční metoda – představuje specifikaci metody, která bude použita pro detekci markerů, • počet markerů – udává počet markerů, které mají být v obraze hledány, • název a cesta hledaných markerů a 3D objektů – každému hledanému markeru, který je tímto způsobem definován, je přiřazen jeden konkrétní 3D model, který se bude zobrazovat na jeho pozici. Grafické rozhraní bylo vytvořeno jako samostatný projekt. Hlavním důvodem pro toto rozhodnutí byl fakt, že k jeho vývoji bylo použito prostředků knihovny Qt a projekt byl vytvořen jako „Program s uživatelským rozhraním Qtÿ. Pokud by tato poslední část měla být zaintegrována stejným způsobem, jako dvě dříve popisované, znamenalo by to, že by se vše muselo modifikovat. Projekt ArHell, do ktérého bylo vše postupně zakomponováno, je totiž vytvořen jako „konzolová aplikaceÿ. Varianta samostatného projektu se tak zdála daleko schůdnější a rozumnější. Hlavní okno tohoto grafického rozhraní je vytvořeno a spuštěno pomocí těchto 4 příkazů:

10.3

GUI pro zadávání vstupních parametrů

47

QApplication a(argc, argv); GUI ARhellParamSettings w; w.show(); return a.exec(); Prvním příkazem je vytvořeno obecné okno palikace Qt, které může přejímat paramety z příkazové řádky. Druhým příkazem je v tomto případě, jednoduše řečeno, vytvořen samotný obsah okna, tzn. všechny elementy a prvky. Třetí příkaz (w.show()) zaručí, že se zobrazí všechny definované prvky okna, a posledním příkazem se spustí nekonečná smyčka. Ta zajistí, že vytvořené okno bude zobrazeno tak dlouho, dokud uživatel nevykoná nějakou akci, která způsobí jeho zavření. V začátcích práce na tvorbě GUI bylo využito aplikace QtDesigner, která je součástí instalace prostředků knihovny Qt. Tato aplikace umožňuje jednoduchým způsobem vytvářet grafická rozhraní aplikací. Umísťování ovládacích prvků je opravdu snadné, neboť lze prvky v okně rozmisťovat způsobem drag-and-drop. Podobně snadné je také pojmenovávání a přejmenovávání vložených a umístěných objektů nebo modifikace jejich atributů. Avšak na složitější rozhraní se QtDesigner moc nehodí, protože obsahuje pouze některé – nejpoužívanější ovládací prvky. V tu chvíli se musí vše programovat ručně. Při vytvoření „Qt projektuÿ je mimo zdrojových a hlavičkových souborů vytvořen také formulářový soubor s příponou .ui. Tento soubor je vniřně strukturován jako klasické XML se všemi náležitostmi. K tomuto „.uiÿ souboru je také vytvořen hlavičkový soubor, který je pak přilinkován k projektu. V těchto dvou souborech je uložena definice objektů a prvků vytvořených pomocí QtDesigneru 10.3.1

Rozmísťování prvků v okně

Samotné okno uživatelského rozhraní je opticky rozděleno do tří samostatných logických celků, které odpovídají parametrům zmiňovaným výše. První celek tedy představuje výběr metody, která bude použita pro detekci markeru (viz obr. č. 22). Protože k tomuto úkonu může být použita právě jedna detekční metoda, bylo na

Obr. 22: Výřez gui – detekční metody

tuto část s výhodou použito ovládacího prvku radioButton. Každý radioButton je tvořen pomocí dvou příkazů: golayMethod radioButton = new QRadioButton(verticalLayoutWidget); golayMethod radioButton -> setObjectName(QString::fromUtf8(

10.3

GUI pro zadávání vstupních parametrů

48

"golayMethod radioButton")); golayMethod radioButton -> setChecked(true); V této ukázce jsou použity příkazy 3, protože se jedná o první ze skupiny přepínačů a je žádoucí, aby alespoň jeden z nich byl vybrán a (zaškrknut). To je právě účel třetího příkazu. Ke každémuradioButtonu je vytvořen textový popisek, aby uživatel věděl, co vlastně vybírá. Toho se dosáhne editací jedné z jeho vlastností: golayMethod radioButton -> setText(QApplication::translate( "GUI ARhellParamSettings", "Golay", 0, QApplication::UnicodeUTF8)); Všechny takto vytvořené přepínače jsou do okna umístěny pomocí widgetů a layoutů. To umožňuje jejich snadné rozmísťování a pozicování a usnadňuje to hierarchické členění. Druhý celek je tvořen spinBoxem, kterým uživatel nastavuje počet markerů, které se budou v obraze hledat (obr. č. 23). Podobně jako přepínače popsané výše,

Obr. 23: Výřez gui – spinBox pro zadávání počtu markerů

jsou pro vytvoření spinBoxu pouze dva příkazy. markersCount spinBox = new QSpinBox(markersCount scrollAreaWidgetContents); markersCount spinBox -> setObjectName(QString::fromUtf8("markersCount spinBox")); V mém připadě bylo ale nutné použít ještě jeden navíc: markersCount spinBox -> setGeometry(QRect(260, 0, 69, 18)). Pomocí něj je totiž nastavena velikost a pozice tohoto spinBoxu. Jelikož objety spinBox nemají definovanou žádnou vlastnot label nebo něco podobného, aby jej šlo snadno popsat, muselo být toto návěstí vytvořeno pomocí dalšího objektu. markersCount label = new QLabel(markersCount scrollAreaWidgetContents); markersCount label -> setObjectName(QString::fromUtf8("markersCount label")); markersCount label -> setGeometry(QRect(10, 0, 241, 18)); markersCount label -> setText(QApplication::translate("GUI ARhellParamSettings", "Count of markers which will be looked for (1 - 10): ", 0, QApplication::UnicodeUTF8));

10.3

GUI pro zadávání vstupních parametrů

49

Podobně jako objekty radionButton jsou i tyto dva objekty umístěny ve widgetu, aby mohly být jednoduššeji pozicovány. Třetím a posledním celkem je tabulka pro zadávání cest k markerům jejich ID a 3D objektům (obr č. 24. Tato tabulka je nejsložitější částí celého GUI a je důvodm,

Obr. 24: spinBox pro zadávání počtu markerů

proč nestačil nástroj QtDesigner. Jedná se totiž o složitější objekt i manipulaci a práce přímo ve zdrojovém kódu tak byla snazší a výhodnější zároveň. V první fázi byla vytvořena tabulka jako taková, bez jakéhokoliv obsahu, pouze s nadepsanými sloupci a definovanými šířkami sloupců. Ve druhé fázi pak došlo na vyváření implicitního obsahu, který by uživateli usnadňovali orientaci pomohlo pochopit účel jednotlivých buňek tabulky. Vytvoření tabulky spočívá ve vytvoření modelu a následně pohledu. Jako model byl vybrán QStandardItemModel, neboť nejlépe vyhovoval požadavkům. Vrámci definice modelu byly také pojmenovány sloupce: standardModel = new QStandardItemModel; standardModel ->setHorizontalHeaderLabels( QStringList() << tr("Path to marker") << tr("marker ID") << tr("Path to 3D model")); Pohled je opět vytvořen pomocí dvou příkazů. Za zmínku stojí druhý z nich. Funkcí setModel() se pohled přiřazuje jednomu konkrétnímu modelu. V mém případě ani jiná možnost není. tableView = new QTableView(this); tableView->setModel(standardModel); Při přidávání řádků musí být nejdříve tyto nadefinovány a jsou přídávány již hotové. V rámci této operace je nejdříve vytvořen samotný nový řádek a později jsou vytvořeny interně unikátní nazvy slupců. To je důležité nejen kvůli pojmenovávání, ale také kvůli dalším případným akcím. Unikátní název zajistí jednoznačnou identiikace buňky tabulky.

10.3

GUI pro zadávání vstupních parametrů

50

QList rowItems; rowItems << newQStandardItem( QString::fromStdString("markerPath ").append(strID)); rowItems << new QStandardItem(strID); rowItems << new QStandardItem( QString::fromStdString("modelPath ").append(strID)); tableRoot->appendRow(rowItems); Posledním prvkem okna je tlačítko Save and Run. To má přesně takovou funci, jakou naznačuje jeho název. Tedy při jeho stisku se uloží aktuální konfigurace, GUI okno se zavře a dojde ke spuštění aplikace ArHell. 10.3.2

Napojení reakcí na uživatelské akce

Tvorba grafických rozhraní však nespočívá pouze v rozmísťování grafických a ovládacích prvků v okně či oknech. Nedílnou součástí je také napojení příslušných reakcí na uživatelské akce (například stisknutí tlačítka myši, stisknutí talčítka v aplikaci, přejetí myší přes nějaký prvek atd.). V knihovně Qt jsou vyvolané akce označovány jako SIGNALS a reakce na ně jako SLOTS. V okamžiku, kdy tedy bylo dokončeno umísťování a pozicování prvků, přišla řada na toto navázování. Uživatel může v okně vyvolat 4 akce, na které aplikace reaguje: 1. výběr detekční metody, 2. změna počtu hledaných marekrů, 3. stisk tlačítka Save and Run, 4. dvojklik v tabulce markerů a modelů. Všechna napojení těchto akcí a reakcí jsou provedena ve funkci createConnections(), která je volána v konstruktoru třídy, jejíž instance představuje okno. Kdykoliv uživatel klikne na kterýkoliv radioButton, aby tak změnil metodu, která bude použita při detekci, je v aplikaci vyvolán signál clicked(). Tento signál je pak napojen na příslušnou metodu, která je odpovědí na vzniklou událost. Tato odpověď je však pro uživatele nepostřehnutelná, neboť reakcí je v tomto případě přiřazení hodnoty do proměné. Přiřazovaná hodnota se liší právě podle toho, na který radioButton uživatel klikl. Tato hodnota není definována nahodně, ale vychozí ze způsobu označování detekčních metoch v aplikaci ArHell. Je-li tedy kliknuto na první radioButton, je přiřazovaná hodnota rovna 0, je-li kliknuto na druhý, hodnota je rovna 1 a při kliknutí na třetí radioButton se přiřazuje hodnota 2. Napojení vyvolaných signálů se provádí pomoci metody connect() následujícím způsobem: QObject::connect(ui->golayMethod radioButton, SIGNAL(clicked()), this, SLOT(slot golayRadioButtonClicked()));

10.3

GUI pro zadávání vstupních parametrů

51

QObject::connect(ui->matchTemplMethod radioButton, SIGNAL(clicked()), this, SLOT(slot matchTemplRadioButtonClicked())); QObject::connect(ui->sufrMethod radioButton, SIGNAL(clicked()), this, SLOT(slot surfRadioButtonClicked())); Další událost v aplikaci vznikne, když uzivatel změní počet markerů, které se budou hledat. Reakci na tyto změny už uživatel vidí, neboť v závislosti na tom, zda počet markerů zvyšuje či snižuje, jsou přidávány nebo odebírány řádky v tabulce pro specifikace cest k markerům a modelům. Toto umožňuje napojení QObject::connect(ui->markersCount spinBox, SIGNAL(valueChanged(int)), this, SLOT(slot markerksCountSpinBoxModified(int))). Jak je možno vidět, narozdíl od předhozích napojení se zde předavá hodnota. Ta je celočíslená a představuje aktuální hodnotu spinBoxu. Třetí signál je vyvolán stiskem tlačítka Save and Run. Když uživatel toto tlačítko stiskne, dojde k uložení všech zadaných parametrů do souboru, zavření okna a spuštění aplikace ArHell. Navázání reakce na stisk tlačítka je provedeno přikazem QObject::connect(ui->saveAndRunARhell pushButton, SIGNAL(clicked()), this, SLOT(slot saveAndRun())). Ukládání parametrů do souboru je důležité ze dvou důvodů. Prvním z nich je, že uživatel nemusí při každém spuštění aplikace zadávat vše znova (bude podrobněji popsáno později). Druhý důvod souvisí se skutečností, že grafické rozraní není přímo součástí aplikace ArHell, ale je vytvořeno jako separátní projekt. Takže parametry, které jsou nutné pro spuštění ArHellu, jsou načteny z takto vytvořeného souboru. Poslední, čtvrtá, událost nastane v okamžiku, kdy uživatel „dvojklikneÿ v tabulce do pole pro zadávání cest k markerům a 3D modelům. Když se tak stane, dojde k zobrazení druhého okna, ve kterém může uživatel jednoduchým způsobem definovat, které markery se budou hledat (které budou sloužit jako šablony při srovnávání) a které 3D modely budou v případě nalezení na jejich místo vykresleny. Toto okno je zorazováno pomocí příkazu QString path = QFileDialog::getOpenFileName(this,tr(caption),"",tr(allowedFiles)). Metoda getOpenFielName může přebírat několik nebo žádné parametry. Zde stojí za zmínku především druhý a čtvrtý parametr. Těmi se totiž dá upravovat text, který se zobrazí v titulkovém pruhu okna, a filtrovat typy souborů, které se v tomto okně budou uživateli zobrazovat. To se hodí v okamžicích, kdy je uživatele vhodné navést k tomu, co vlastně má v zobrazeném okně vybrat, a může mu to napovědět co se bude s vybranými položkami dále provádět. S výše popsaným třetím signálem týkajícícm se stisku tlačítka Save and Run souvisí jetě jedna věc. Data uložená v souboru jsou využita i při samotném spuštění okna GUI. Při každém spuštění je totiž nejprve zkontrolováno, jestli náhodou neexistuje soubor s uloženým nastavením. Jesliže existuje, je jeho obsah načten a uživatel tak může použít konfiguraci, která byla použita při posledním spuštění. Jestliže však uložené nastavení nebylo nalezeno, což může prakticky nastat pouze při prvním spuštění na na každém počítači, je GUI okno zobrazeno ve výchozímm stavu.

11

11

DISKUZE

52

Diskuze

V průběhu prací bylo nutné řešit několik problémů, které se při implementaci vyskytly. Jedním z nich byly rozměry obrazu, který představuje vstupní data pro analýzu. Větší obraz sice poskytoval lepší a přesnější výsledky, ale jeho zpracování bylo časově naročnější. Bylo tedy nutné nalézt vhodný kompromis. Dalším obtížnějším bodem bylo stanovení vhodné hodnoty prahu při prahovaní obrazů. Při prvních pokusech byla jeho hodnota stanovována experimentálně na konstatní hodnotu, ale tento způsob se ukázal jako ne příliš vhodný. Konstantní hodnota prahu je totiž problém při nestálých světelných podmínkách. Proto bylo nakonec od tohoto způsobu stanovování prahu upuštěno a byla využita možnost automatickéo dynamického stanovování prahu, kterou nabízí knihovna OpenCV prostřednictvím metody cvAdaptiveThreshold(). Jelikož byla praktická část této práce zaintegrována do projektu AuRel, který je na Ústavu Informatiky vyvíjen, bylo také možné sledovat, jak fungují jednotlivé metody pro detekci markerů a jejich srovnávání a jak se liší. Bylo tak možné pozorovat, že například při rozpoznávání markerů pomocí deskriptoru SURF nedochází k narovnávání obrazu do roviny kamery, jako v případě metody matchTemplate, ale oproti té je zase SURF časově náročnější. A podobných rozdílů by se dalo najít více. V rámci této diplomové práce se podařilo nalézt postup, který lze použít při hledání markerů a který poskytuje celkem obstojné výsledky. Ale určitě se nejedená o naprosto dokonalý postup a dalo by se najít spousta způsobů a možností, jak by se dal tento postup vylepšit. Možné vylepšení související s hledáním objektů v obraze by mohlo spočívat např. v rozšíření množství detekčních metod, což by mohlo umožnit použití v rozmanitějším spektru AR aplikací. Dalším vylepšením by mohlo být například rozšíření podpory pro 3D modely vytvořené v jiných aplikacích, aby bylo možné zobrazovat více různých 3D modelů.

12

12

ZÁVĚR

53

Závěr

Aplikace doplněné reality přestávají patřit pouze do oblasti vědy, medicíny nebo vojenství, ale čím dál častěji pronikají do života běžných lidí. Cílem práce stanoveným v počátku práce bylo nalezení pracovního postupu, který by vedl k vytvoření aplikace AR rozpoznávající definovaný objekt v obraze. Z tohoto důvodu byla provedena analýza přístupů, které jsou k řešení této problematiky používány v současnosti. Byly srovnávány jejich výhody i nevýhody především z hlediska kompatibility s vývojovými prostředími a platformní závislosti. Také byly porovnávány některé z dostupných metod pro detekci objektů v obrazech. Bylo zjištěno, že některé z těchto metod jsou vhodnější pro detekci a srovnávání umělých objektů (markerů) a jiné pro detekci a srovnávání stejných reálných objektů nebo jejich částí v různých obrazech. V teoretické části této práce byly dále představeny a porovnány některé z knihoven, které usnadňují vývoj aplikací doplněné reality a které se v současnosti pro tyto účely používají. Také byly srovnány některé z dostupných knihoven pro práci a manipulaci s 3D objetky. V praktické části této práce, která se zaměřovala na identifikaci objektů v obraze, byl podrobně popsán způsob a možnosti takové detekce pomocí hranového detektoru. V části zaměřující se na srovnávání nalezeného markeru získaného z obrazu s jeho uloženou šablonou bylo využito metody cvMatchTemplate, která je součástí knihovny OpenCV. Aby bylo možné ověřit, že navrhovaný postup funguje a poskytuje požadované výsledky, bulo nutné do experimentální aplikace, který byla za tímto účelem vytvořena, zaimplementovat podporu pro načítání a zobrazovaní 3D modelů. V případě, že navrhovaný postup vyhodnotí nalezený marker a šablonu jako shodné, je do obrazu na místo markeru vykreslen konkrétní 3D model, který navíc bude zobrazen ve správném perspektivním zkreslení. Kvůli tomu bylo provedeno srovnání některých z dospuných knihoven, které umožňují načítat a zobrazovat 3D modely vytvořené v jiných aplikacích. Tato volba se v průběhu prací na praktické části ukázala jako rozumější, než varianta tvorby vlastní knihovny, která by toto zajišťovala. V poslední části této práce je popisován postup tvorby grafického uživatelského rozhraní. To je využito při zadávání vstupních parametrů do aplikace AuRel, do které byla zaintergrována celá praktická část této diplomové práce. AuRel vzniká na Ústavu informatiky Mendelovy univerzity v Brně pod vedením pana Ing. Davida Procházky, Ph.D. jako jeden z modulů pro software VRUT, jenž je vyvíjen ve spolupráci společnosti Škoda Auto, a. s. a ČVUT.

13

13

LITERATURA

54

Literatura

Bradski, G., Kaehler, A. Learning OpenCV: Computer Vision with the OpenCV Library. USA: O’Reilly Media, 2008. 555 s. ISBN 0-596-51613-4. Gonzales, Rafael C., Woods, Richard E. Digital Image Processing. Third Edition. New Jersey : Pearson Prentice Hall, 2008. 976 s. ISBN 978-0-13-1687288. Bimber, O., Raskar, Ramesh. Spatial Augmented Reality: Merging Real and Virtual Worlds. Wellesley, MA : A K Peters, Ltd., 2005. 392 s. ISBN 1-56881230-2. Lenovo Support [online]. 2010 [cit. 2011-03-28]. Lenovo VeriFace for Microsoft Windows XP Home Edition, Professional - IdeaPad S9e, S10e and Lenovo G530. Dostupné z WWW: . CNN GO [online]. 2011 [cit. 2011-03-29]. Top 10 augmented reality travel apps. Dostupné z WWW: . Carmigniani, J. a kol. Augmented reality technologies, systems and applications Multimedia Tools and Applications [online]. January 2011, 51, [cit. 2011-04-04]. Dostupný z WWW: . Fiala, M.ARTag, a Fiducial Marker System Using Digital Techniques ProceedingCVPR ’05 Proceedings of the 2005 IEEE Computer Society Conference on Computer Vision and Pattern Recognition (CVPR’05) [online]. 2005, 2, [cit. 201104-05]. Dostupný z WWW: . Kato, H. a kol. A registration method based on texture tracking using ARToolKitAugmented Reality Toolkit Workshop, 2003. IEEE International [online]. 7 Oct. 2003 , [cit. 2011-04-05]. Dostupný z WWW: . Procházka, D. Virtuální realita 1: zobrazování. Mendelova univerzita v Brně, 2010. Doplňkový materiál k přednáškám předmětu Pokročilá uživatelská rozhraní. Koubek, T. Aplikace umožňující realizaci rozšířené reality Brno, 2011. 54 s. Diplomová práce. Mendlova univerzita v Brně. Wikipedia : the free encyclopedia [online]. St. Petersburg (Florida) : Wikipedia Foundation, last modified on 29. 3. 2011 [cit. 2011-04-04]. Dostupné z WWW: .

13

LITERATURA

55

Wikitude – Statue of Liberty [online]. 2001 [cit. 2001-12-26]. Statue of Liberty. Dostupné z WWW: . Lamb P. ARToolKit – Features [online]. 2007 [cit. 2011-10-05]. Feature List. Dostupné z WWW: . Lamb P. ARToolKit – History [online]. 2007 [cit. 2011-10-05]. History. Dostupné z WWW: . Lamb P. ARToolKit – News [online]. 2007 [cit. 2011-10-05]. News from SourceForge.net. Dostupné z WWW: . Procházka, D., Koubek, T. Metody implementace doplněné reality v běžných aplikacích Mendelova univerzita v Brně, 2010. Ilirzer, M. Marker detection for augmented reality applications [online]. 2008 [cit. 2011-04-20]. Dostupné z WWW: . OpenCV v2.1 documentation – cvMatchTemplate [online]. 2010 [cit. 2011-05-12]. Dostupné z WWW: . Procházka, D. OpenCV: vyhledání objektů Mendelova univerzitra v Brně, 2010. Doplňkový materiál k přednáškám předmětu Počítačová grafika 2. Kanemasu, M. Golay Codes [online]. Cambridge:Massachusetts Institute of Technology [online]. [cit. 2011-11-05]. Dostupé z WWW: . Nikolaus, G. Irrlicht Engine – A free open source 3d engine [online]. 2003-2009 [cit. 2011-11-22]. Irrlicht – features. Dostupné z WWW: . Fantacci, C., Martini, A. SURF: A Surf library for processing [online]. 2001 [cit. 2011-11-15]. Dostupné z WWW: . Bay, H., Tuytelaars, T., Gool, L. V. SURF: Speeded Up Robust Features [online]. 2006 [cit. 2011-11-15]. Dostupné z WWW:. Open Asset Import Library [online]. 2007–2009 [cit. 2011-11-22]. Assimp. Dostupné z WWW: .

13

LITERATURA

56

Ogre [online]. 2000–2009 [cit. 2011-11-24]. Dostupné z WWW: . Ogre Wiki : Support and community documentation for Ogre3D[online]. 2011 [cit. 2011-11-23]. Dostupné z WWW: . Agar [online]. 2011 [cit. 2011-11-24]. Dostupné z WWW: . UnrealTechnology – features [online]. 2008–2011 [cit. 2011-10-30]. z WWW: .

Dostupné

UnrealTechnology – animation [online]. 2008–2011 [cit. 2011-10-30]. Dostupné z WWW: . UnrealTechnology – arficial intelligence [online]. 2008–2011 [cit. 2011-10-30]. Dostupné z WWW: . UnrealTechnology – licencing [online]. 2008–2011 [cit. 2011-10-30]. Dostupné z WWW: . UnrealDevelopmentKit – licencing [online]. 2009–2010 [cit. 2011-10-30]. Dostupné z WWW: . Delta3D – about [online]. 2011 [cit. 2011-11-02]. Dostupné z WWW: . OpenSceneGraph – Introduction [online]. 2007 [cit. 2011-11-05]. Dostupné z WWW: . OpenCV v2.3 documentation – Miscellaneous Image Transformations [online]. 2011 [cit. 2011-12-01]. Dostupné z WWW: .

Přílohy

A

A

UKÁZKY VÝSTUPŮ PRÁCE

Ukázky výstupů práce

Obr. 25: Původní obraz načtený z kamery

58

A

UKÁZKY VÝSTUPŮ PRÁCE

Obr. 26: Obraz převedený do stupnice šedé

Obr. 27: Vyhlazený šedý obraz

59

A

UKÁZKY VÝSTUPŮ PRÁCE

Obr. 28: Thresholdovaný obraz

Obr. 29: Nalezené a zobrazené kontury

60

A

UKÁZKY VÝSTUPŮ PRÁCE

Obr. 30: Obraz narovnaný do roviny kamery

Obr. 31: Zobrazený 3D model na pozici markeru

61

B

POSTUP PŘIPOJENí KNIHOVNY IRRLICHT POMOCí VISUAL STUDIA 2008

B

62

Postup připojení knihovny Irrlicht pomocí Visual Studia 2008

1. Stáhněte aktuální verzi knihovny Irrlicht (http://irrlicht.sourceforge. net/downloads.html). 2. Rozbalte archiv a jeho obsah umístěte na požadovanou lokaci. 3. Spustě Visual Studio a otevřte okno nastavení (Tools – Options). 4. Přejděte do sekce Projects and Solutions – VC++ Directories a nastavte cesty k potřebným souborům: a) v sekci Executable files cestu ke složce bin, např. C:\irrlicht_1.7.2\bin\ Win32-VisualStudio b) v sekci Include files cestu ke složce include, např. C:\irrlicht_1.7.2\ include c) v sekci Library files cestu ke složkám lib a bin, např. C:\irrlicht_1.7.2\ lib\Win32-visualstudio a C:\irrlicht_1.7.2\bin\Win32-visualstudio 5. Posledním krokem je přidání knihoven irrKlang.dll a Irrlicht.dll mezi soubory projektu.