Bakalá ská práce. Michal Polic. Rekonstrukce prost edí z pohybu monokulární kamery. ƒeské VYSOKÉ UƒENÍ TECHNICKÉ V PRAZE. Fakulta elektrotechnická

ESKÉ VYSOKÉ UENÍ TECHNICKÉ V PRAZE

Fakulta elektrotechnická

Bakalá°ská práce

Michal Polic Rekonstrukce prost°edí z pohybu monokulární kamery

Katedra kybernetiky Vedoucí práce: RNDr. Petr t¥pán Ph.D.

Pod¥kování Cht¥l bych pod¥kovat vedoucímu práce RNDr. Petru t¥pánovi Ph.D. za jeho rady a pomoc p°i vývoji aplikace a psaní této práce. Dále RNDr. Danielovi Pr·²ovi Ph.D. za pomoc s denicí optimaliza£ní úlohy rekonstruující p°íznaky.

Abstrakt Tato práce se zabývá rekonstrukcí p°íznak· z pohybu monokulární kamery na opera£ním systému Android v reálném £ase. Práce seznamuje se základy tvorby aplikací na systém Android, navrºením rozhraní pro rychlé zpracování a zobrazení snímk·. Porovnává detektory p°íznak· a moºnosti asociace bod· mezi snímky. V záv¥ru implementuje algoritmus na tvorbu 3D mapy p°íznak·.

Abstrakt This work focuses on the real time features reconstruction from the move of monocular camera at the operating system Android. This work introduces the basic method of creating application at the system Android and it designs interface for fast image processing. It compares detectors of image features and the association of points between the images. At the end of the paper, there is implemented algorithm for creation 3D map of the features from images.

Rekonstrukce prost°edí z pohybu monokulární kamery

OBSAH

Obsah 1 Úvod

1

2 Vývoj aplikace na systém Android

2

2.1

Vytvo°ení projektu

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

2

2.1.1

Instalace Software . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2

2.1.2

Popis pot°ebného software . . . . . . . . . . . . . . . . . . . . . . .

2

2.1.3

Vytvo°ení nového projektu v Eclipse IDE . . . . . . . . . . . . . . .

4

2.2

Struktura soubor· projektu

2.3

Základní prvky aplikace

2.4

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

5

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

6

2.3.1

Aktivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6

2.3.2

Vykreslení graky . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7

2.3.3

Práce s kamerou

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

8

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

13

Struktura aplikace

3 Práce s knihovnou BoofCV

18

3.1

Získání funk£ní verze

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

18

3.2

Kalibrace kamery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

19

3.2.1

Projekce snímku do obecného optického modelu . . . . . . . . . . .

20

3.2.2

Aktivita zji²t¥ní vnit°ních parametr· kamery . . . . . . . . . . . . .

21

3.3

3.4

Detektory

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

24

3.3.1

Detekce hran

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

27

3.3.2

Detekce roh·

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

28

3.3.3

Detekce region· . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

33

Asociace p°íznak· . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

36

3.4.1

Pouºité deskriptory . . . . . . . . . . . . . . . . . . . . . . . . . . .

36

3.4.2

Implementace deskriptor·

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

37

3.4.3

Implementace trekr·

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

40

3.4.4

Filtování asociovaných p°íznak· . . . . . . . . . . . . . . . . . . . .

41

i


OBSAH

4 Implementace rekonstrukce p°íznak·

43

4.1

Robustní výpo£et posunu

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

43

4.2

Rekonstrukce p°íznak· . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

44

4.2.1

Rekonstrukce p°íznak· v knihovn¥ BoofCV . . . . . . . . . . . . . .

45

Rekonstrukce prost°edí . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

46

4.3

5 Experimenty 5.1

5.2

49

Porovnání rychlosti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

49

5.1.1

Detektory hran

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

49

5.1.2

Detektory p°íznak· . . . . . . . . . . . . . . . . . . . . . . . . . . .

49

5.1.3

Detektory region· . . . . . . . . . . . . . . . . . . . . . . . . . . . .

50

5.1.4

Detekce s popisem p°íznak·

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

50

5.1.5

Sledování p°íznak· pomocí KLT . . . . . . . . . . . . . . . . . . . .

50

5.1.6

Sledování p°íznak· pomocí DDA

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

51

5.1.7

asy obsluºných procedur

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

51

5.1.8

Shrnutí rychlostí vyhodnocení . . . . . . . . . . . . . . . . . . . . .

51

Robustnost p°íznak·

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

6 Záv¥r

52

53

ii


SEZNAM OBRÁZK

Seznam obrázk· 1

Struktura projektu

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

2

P°íklad - vytvá°ení projektu

3

ivotní cyklus activity uvedený na portále [1]

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

7

4

Vytvo°ení aktivity, na£tení grackého rozhraní a jeho editace . . . . . . . .

8

5

Vytvo°ení náhledu kamery CameraPreview . . . . . . . . . . . . . . . . .

8

6

Základ t°ídy CameraPreview . . . . . . . . . . . . . . . . . . . . . . . . . .

9

7

Inicializace SurfaceHolder a nastavení kamery

8

SurfaceCreated

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

5 5

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

10

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

10

9

VideoActivity schéma . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

11

10

VideoActivity onCreate() . . . . . . . . . . . . . . . . . . . . . . . . . . . .

11

11

VideoActivity onResume() . . . . . . . . . . . . . . . . . . . . . . . . . . .

12

12

VideoActivity onPause()

12

13

VideoActivity onPreviewFrame

14

Schéma t°ídy VideoActivity

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

12

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

13

15

Ukázka posunutí p°íznak· oproti reálným pozicím . . . . . . . . . . . . . .

14

16

Kód t°ídy

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

15

17

Neupravený snímek (320x240px) . . . . . . . . . . . . . . . . . . . . . . . .

15

ThreadProcess

funkce

run

20

Visualization . . . . . . Funkce onMeasure v CameraPreview Funkce onLayout v CameraPreview .

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

17

21

P°íklad transformace bod· . . . . . . . . . . . . . . . . . . . . . . . . . . .

20

22

Základ t°ídy

23

18 19

Privátní t°ída

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

16

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

17

AutomatickaKalibraceKamery

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

21

Denice prom¥nných

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

21

24

Inicializace kalibrace

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

22

25

Vyhodnocení snímku

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

23

26

Vykreslení roh· kalibra£ní m°íºky . . . . . . . . . . . . . . . . . . . . . . .

23

27

Vyhodnocení vnit°ních parametr· kamery

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

24

28

Funkce vytvá°ející objekt t°ídy DetectDescribePoint . . . . . . . . . . . . .

25

29

Parametry funkce fuseTogether

25

30

Algoritmy popisu, funkce t°ídy FactoryDescribeRegionPoint

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

iii

. . . . . . . .

25


SEZNAM OBRÁZK

31

Funkce t°ídy FactoryInterestPoint . . . . . . . . . . . . . . . . . . . . . . .

26

32

Funkce t°ídy FactoryInterestPointAlgs

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

26

33

Funkce t°ídy FactoryDetectPoint

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

26

34

Funkce t°ídy FactoryIntensityPoint

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

27

35

Funkce t°ídy FactoryIntensityPointAlg

36

Detektory hran

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

27

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

28

37

P°íklad roh· . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

28

38

P°íklad porovnávaných pixel· ze stránek [2]

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

29

39

Inicializace FAST detektoru

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

31

40

Proces a vykreslení FAST detektoru . . . . . . . . . . . . . . . . . . . . . .

31

41

Inicializace Harris detektoru . . . . . . . . . . . . . . . . . . . . . . . . . .

32

42

Inicializace Hessian detektoru

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

33

43

P°íklad výstup· detektor· . . . . . . . . . . . . . . . . . . . . . . . . . . .

34

44

Inicializace SIFT detektoru . . . . . . . . . . . . . . . . . . . . . . . . . . .

35

45

Ukázka detekovaných p°íznak· pomocí SIFT detektoru

. . . . . . . . . . .

35

46

Detekce, popis a vykreslení p°íznak·

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

39

47

Inicializace detektoru s popisem p°íznak· . . . . . . . . . . . . . . . . . . .

40

48

Inicializace vlastního trekru

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

41

49

Inicializace vlastního trekru

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

42

50

Základní schéma

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

43

51

GUI Rekonstrukce prost°edí

52

Denice prom¥nných

53

Asociované snímky

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

44

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

45

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

47

54


47

55


48

56

Porovnání doby zpracování jednotlivých £ástí FAST detektoru

52

iv

. . . . . . .

SEZNAM TABULEK


Seznam tabulek 1

as vyhodnocování vnit°ních parametr· kamery . . . . . . . . . . . . . . .

22

2

Porovnání rychlosti detektor· hran

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

49

3

Porovnání rychlosti detektor· p°íznak· . . . . . . . . . . . . . . . . . . . .

49

4

Porovnání rychlosti detektor· region· . . . . . . . . . . . . . . . . . . . . .

50

5

Porovnání rychlosti detekce s popisem p°íznak·

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

50

6

Porovnání rychlosti sledování p°íznak· pomocí KLT . . . . . . . . . . . . .

50

7

Porovnání rychlosti trekování p°íznak· pomocí DDA

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

51

8

Porovnání rychlosti obsluºných procedur FAST detektoru . . . . . . . . . .

51

9

Obsah CD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

55

v


1

Úvod Mobilní telefony jsou b¥ºnou sou£ástí na²eho ºivota. Ke konci roku 2011 bylo v R o

35,4% víc aktivních SIM karet, neº je po£et obyvatel. Zájem o mobilní telefony umoºnil jejich rychlý rozvoj. Tém¥° kaºdý telefon krom¥ základních funkcí obsahuje i kameru a senzory pohybu. Výkon mobilních telefon· se zvý²il p°ibliºn¥ o 71% (2011-2012) a o 76% (2012-2013). Zvy²ováním výkonu spolu s mobilitou za°ízení, kamerou a dal²ími senzory otevírají nové moºnosti jako je zpracování obrazu v reálném £ase. V sou£asné dob¥ se na trhu objevuje n¥kolik opera£ních systém· pro mobilní telefony. Nejvíce zastoupeným systémem je Android s 75%, dal²ím je iOS 14,9% a Blackberry 4,3%. Kaºdý den je zaregistrováno p°es 500tis nových za°ízení s Androidem. Android je opensource systém zaloºený na Linuxovém jád°e. Aplikace na Android se vyvíjí v programovacím jazyce Java. V £ase psaní této práce za£ala vznikat knihovna BoofCV. BoofCV je open-source knihovna napsaná v Jav¥ pro zpracování obrazu v reálném £ase s £áste£nou podporou p°ímo pro Android. Cílem práce je ov¥°it moºnosti rekonstrukce prost°edí pro mobilní za°ízení s opera£ním systémem Android. V první £ásti je seznámení s tvorbou aplikace na Android, vyuºití API pro ovládání kamery, základy vykreslování graky a návrh vlastní aplikace tak, aby umoº¬ovala zpracovávat obraz v n¥kolika vláknech najednou a docílili bychom co nejv¥t²í rychlosti aplikace, která je pot°eba pro zpracování obrazu v reálném £ase. Druhá £ást práce seznamuje s knihovnou BoofCV a jejím pouºitím pro detekci p°íznak· v obraze, asociaci bod· a získání pohybu kamery v prostoru. V záv¥re£né £ásti je uvedena nadstavba BoofCV pro rekonstrukci p°íznak· z obrazu do 3D.

1/55


2

Vývoj aplikace na systém Android V této £ásti je uvedeno, jak vytvo°it nový projekt. jaká je struktura projektu a jaké jsou

základní API pro práci s grakou a kamerou. Na záv¥r je ukázáno, jak navrhnou aplikaci pro zpracování obrazu v reálném £ase.

2.1


2.1.1

Instalace Software

P°ed samotným vytvo°ením projektu je t°eba nainstalovat nástroje pot°ebné pro tvorbu aplikací na Android. Nejjednodu²²ím zp·sobem je nainstalovat ADT Boundle z portálu [3]. ADT Boundle obsahuje:

•

Eclipse IDE + ADT plugin

•

Android SDK

•

Knihovny a nástroje pro poslední verzi Androidu

•

Emulátor poslední verze Androidu

Java Developement Kit (JDK) ve verzi 6, který je moºné stáhnout Apache Ant, který lze nalézt na [5].

Dále bude pot°eba z [4] a

2.1.2

Popis pot°ebného software

Eclipse IDE je open-source vývojové prost°edí. Spole£nost Google doporu£uje Eclipse pro vývoj aplikací na opera£ní systém Android. Eclipse IDE lze stáhnout z portálu [6]. Pro ná² vývoj je nejvhodn¥j²í verze classic.

Android Developer Tools plugin (ADT plugin)

je dopln¥k do Eclipse. P°idává

funkce pro tvorbu Android projekt·, gracký editor a perspektivu DDMS. ADT lze p°idat

Help > Install new software. . . > Add, dále vyName: ADT Plugin, Location: https://dl-ssl.google.com/android/eclipse/. Objeví se seznam dostupných dopl¬k· za²krtn¥te: Developer Tools a potvr¤te pomocí Finish. následovn¥. V Eclipse klikn¥te na: pl¬te:

2/55

2.1



Android Software Developement Kit (Android SDK) poskytuje nástroje na vývoj aplikací pro platformu Android. Existují t°í druhy SDK.

Základní kongurace •

SDK Tools - obsahuje nástroje pro debugging (ddms), testování aplikace, správu Android Virtual Devices (AVD), Android emulátor, analýzu grackého layoutu a dal²í pot°ebné programy

•

SDK Platform-tool - obsahuje nástroje závislé na verzi platformy

•

Android SDK platforms - obsahuje alespo¬ jednu platformu SDK skládající se z knihoven, systémového obrazu, ukázkových kód·, skin· emulátoru a dal²ích zdroj·.

Doporu£ená kongurace obsahuje navíc •

USB Driver - komponenta nutná pro lad¥ní a testování aplikace na za°ízení, pod opera£ním systémem Windows.

•

P°íklady kód·

•

Dokumentace

Plná kongurace dopl¬uje •

Google API - nap°íklad Google Maps

•

Ostatní SDK platformy

Android SDK lze stáhnout ze stejné stránky jako ADT Boundle.

Java Developement Kit (JDK) je produktem Oracle Corporation, který obsahuje soubor základních nástroj· na vývoj aplikací pro platformu Java. Jeho d·leºitou sou£ástí je mimo jiné Java Runtime Environment (JRE), který slouºí pro spou²t¥ní aplikací.

Apache Ant je nástroj pro kompilaci sloºit¥j²ích projekt·. Bude se nám hodit p°i kompilaci knihoven ze zdrojového kódu (nap°.: BoofCV). Postup instalace je uveden na stránkách [5]. V²echny vý²e uvedené softwary jsou dostupné pro Windows, Mac OS i Linux ve 32 i 64 bitové verzi.

3/55

2.1


2.1.3


Vytvo°ení nového projektu v Eclipse IDE

P°ed vytvo°ením nového projektu je pot°eba zkontrolovat aktualizace. Spustí se Android SDK Manager (ikona v Eclipse), za²krtne se Tools, Extras a API, které se budeme pouºívat. V této práci jsem pro vývoj zvolil API 16, které mám na telefonu. Dále potvrdíme instalaci. (Pozor, pro instalaci n¥kterých nástroj· musí být vypnuté prost°edí Eclipse.) Nový projekt se v Eclipse vytvo°í:

New > Android Application Project.

Zadá se

název Aplikace, na jakých verzích Androidu má aplikace b¥ºet (API 16), výchozí téma, umíst¥ní projektu na disku, ikona a schéma. Po potvrzení se vytvo°í jednoduchá aplikace, která vypí²e na displeji telefonu Hello word .

Aplikaci m·ºeme spustit dv¥ma zp·soby 1.

Pomocí emulátoru

za°ízení s OS Android se p°ipojí pomocí USB. Po spu²t¥ní

aplikace se otev°e dialogové okno Android Device Chooser, kde vybereme p°ipojené za°ízení. 2.

Pomocí simulátoru

- po spu²t¥ní aplikace se otev°e se stejné dialogové okno jako

v p°ípad¥ emulace. Ve spodní £ásti se vybere z Android Virtual Device virtuální za°ízení, na kterém se má aplikace spustit. Virtuální za°ízení se dá p°idat pomocí:

Android Virtual Device Manager > New.

Android je roz²í°en od levných za°ízení s velmi malým rozli²ením aº po za°ízení, které mají rozli²ení p°evy²ující Full HD. Simulace je velmi dobrým nástrojem pro vyzkou²ení, jak bude aplikace vypadat p°i r·zných rozli²ení obrazovky.

4/55

2.2

2.2




Vytvo°ený projekt obsahuje následující strukturu adresá°· a soubor·.

src

obsahuje

tvo°ení

nového

bor

jménem,

se

zdrojové

projektu, které

kódy

obsahuje

jsme

zadali

aplikace. pouze p°i

Po

vy-

jeden

sou-

vytvá°ení

pro-

jektu.

gen obsahuje automaticky vygenerované soubory. Pro nás nejd·leºit¥j²í je soubor s názvem R.java, který obsahuje identikátory pro p°ístup k jednotlivým soubor· a objekt·m v aplikaci. (nap°.:

R.layout.activity_main

vrací jednozna£né ID

souboru podtrºeného na obrázku 2, zelenou £arou )

libs obsahuje externí knihovny. Pozd¥ji se do tohoto adresá°e p°idají knihovny BoofCV.

Obrázek

1:

Struktura

pro-

jektu

Obrázek 2: P°íklad - vytvá°ení projektu

5/55

2.3


res


obsahuje v²echny prost°edky aplikace (obrázky, denice menu, denice layout·,

denice popisk· v závislosti na lokalit¥ a dal²ích XML soubor·). Podle typu se umisújí do podadresá°·:

• drawable

sloºka pro ikony, obrázky a vlastní graku (p°ípony

hdpi, ldpi a dal²í,

zna£í pro jaké rozli²ení jsou dané prost°edky, obecn¥ lze v²e nahrát do sloºky drawable bez p°ípon)

• layout • menu • values

sloºka s XML soubory obsahující vzhled aplikace nebo její £ásti sloºka s XML soubory obsahující menu - sloºka s XML soubory denující popisky, obecné styly a dal²í hodnoty

pouºité v aplikaci. Pomocí p°ípony lze nastavit, v jaké situaci se má daná sloºka pouºít (nap°.: values-cs/ . . . bude pouºita, pokud máme jako jazyk nastavenou £e²tinu)

• xml

- sloºka se soubory ve formátu XML. Obsahuje nap°íklad prom¥nné programu

preferences .

AndroidManifest

hlavní soubor popisující aplikaci a její komponenty. Obsahuje

seznam v²ech pouºitých obrazovek Aktivit , práva aplikace (nap°íklad právo p°ístupu ke kame°e, správu úloºi²t¥), pro jakou platformu SDK (verzi Androidu) je aplikace ur£ena a dal²í nastavení, nap°íklad jak se mají dané aktivity zobrazit (téma, orientace).

2.3


Android nabízí rozmanité mnoºství t°íd, rozhraní a API, které se dají pouºít. V následujícím shrnutí popí²u pouze ty nejd·leºit¥j²í, které jsou pot°ebné pro moji aplikaci. Ve²kerá dokumentace je dostupná na internetových stránkách [1].

2.3.1

Aktivity

Aktivita odpovídá výstupu programu na jedné obrazovce. Obsahuje gracké uºivatelské rozhraní pro interakci s uºivatelem. Aplikace obvykle obsahuje více aktivit, mezi kterými je uºivatel schopen p°epínat. Start aktivity je náro£ná záleºitost, jelikoº se spou²tí nový proces, musí alokovat pam¥´ a vyvolat zobrazení. Proto se aktivita nemaºe v okamºik, kdy se stává neaktivní, to znamená není zobrazena. Správu aktivit má na starosti Activity Manager. Aktivity se mohou nacházet v následujících stavech viz. obrázek 3.

6/55

2.3



Obrázek 3: ivotní cyklus activity uvedený na portále [1]

P°i generování nového projektu pomocí Eclipse pluginu, viz. kapitola 2.1.3, obsahuje projekt ve sloºce T°ída

src

MainActivity

t°ídu

MainActivity

4a.

obsahuje pouze funkci

onCreate().

Z ºivotního cyklu je vid¥t, ºe

je tato funkce volána p°i vytvo°ení aktivity. Ihned po vytvo°ení aktivity se uloºí stav po-

super.onCreate(savedInstanceState); a setContentView(R.layout.activity_main);.

mocí

2.3.2

denuje se gracké uºivatelské rozhraní

Vykreslení graky

Pro vykreslení údaj· na obrazovku m·ºeme pouºít dva p°ístupy. Gracké prvky m·ºeme vytvá°et p°ímo v kódu, podobn¥ jako v Jav¥, nebo pouºít XML soubory denující vzhled. Nejlep²í je kombinace t¥chto dvou p°ístup·. XML soubory jsou krat²í a p°ehledn¥j²í. Dají se vytvo°it pomocí grackého editoru. P°i

res/layout/activity_main.xml se vytvo°í objekty p°esn¥ podle toho, jak jsou activity_main.xml. Následn¥ se k nim m·ºe p°istupovat pomocí id ndViewById(R.id.nazev_id). Základní gracké rozhraní obrazovky se vytvá°í pomocí

p°ekladu

denované v souboru

editoru. To zjednodu²í a zp°ehlední samotný kód. P°i b¥hu aplikace se upravují zobrazené údaje pomocí zdrojového kód· ve t°íd¥ MainActivity, viz ukázka 4a, kde se ve ºlutém ráme£ku na£te pomocí id

TextView

a následn¥ se p°epí²e jeho obsah.

7/55

2.3



(a) MainAcivity

(b) activity_main.xml

Obrázek 4: Vytvo°ení aktivity, na£tení grackého rozhraní a jeho editace

Nastavení vzhledu je nejjednodu²²í pomocí grackého editoru. Zm¥ny jsou ihned vid¥t a poºadovaný vzhled jde intuitivn¥ nastavit. Gracké rozhraní hlavní aktivity

MainActivity

bylo vytvo°eno pomocí fragment·. Kaºdý fragment má podobné vlastnosti jako Aktivita, tedy tvo°í samostatnou stránku. Pro vytvo°ení obsahu této stránky je pot°eba získat objekty denované v xml souboru a p°edat je ve funkci

onCreateView

(povinná funkce

fragmentu). K tomu ú£elu se standardn¥ pouºívají takzvané inatery (nap°.:

ater, MenuInater ). 2.3.3

LayoutIn-

Práce s kamerou

Pro po°ízení jednoho snímku nebo videa lze pouºít existující aplikaci fotoaparátu. Tato varianta není vhodná, jelikoº je pot°eba zpracovávat obraz v reálném £ase. e²ením je vytvo°ení vlastního rozhraní pro práci s kamerou.

Obrázek 5: Vytvo°ení náhledu kamery CameraPreview

VideoActivity

bude aktivitou spravující kameru. Nejprve se vytvo°í náhled kamery

jako potomek t°ídy:

• SurfaceView

- t°ída pro vykreslení graky normáln¥ vykreslovaná p°es CPU

• TextureView

- t°ída pro vykreslení graky vykreslovaná p°es graku za°ízení

8/55

2.3



Na pouºitém za°ízení je nejrychlej²í zp·sob grackého výstupu vyuºít t°ídu

ceView

Surfa-

se zapnutou hardwarovou akcelerací. Proto je tento postup pouºit i v této práci.

SurfaceHolder.Callback, který vyºaduje funkce surfaceCreated, surfaceChanged a surfaceDestroyed. T°ída náhledu kamery musí dále implementovat interface

Postup vytvo°ení náhledu kamery je následující. V eclipse se vybere projekt, klikne se na

New > Class, zadá se Name: CameraPreview

a vybere se

Package. D¥d¥ní a imCtrl + Shift

plementace interface se doplní do podoby zobrazené na obrázku 6. Stiskem

+O

se naimportují pot°ebné a odstraní nevyuºité knihovny.

Obrázek 6: Základ t°ídy CameraPreview

Aby se zachytila událost vytvo°ení, zm¥ny a zru²ení náhledu, p°idá se do konstruktoru inicializace prom¥nné typu

SurfaceHolder a nastaví se její zp¥tné volání na this. VideoActivity. Budu tedy do konstruktoru Ca-

Aktivita zpracovávající fotky bude t°ída

meraPreview

posílat její instanci, aby se s ní mohlo dále pracovat. Také se p°idá funkce

pro nastavení kamery viz obrázek 7.

9/55

2.3



Obrázek 7: Inicializace SurfaceHolder a nastavení kamery

surfaceCreated se p°idá místo, kde má kamera zobrazovat náhled, funkce setPreviewDisplay(), nastaví se zp¥tné volání p°i vytvo°ení snímku setPreviewCallback() a spustí se náhled kamery funkcí startPreview() viz obrázek 8. Do funkce

Obrázek 8: SurfaceCreated

VideoActivity, která bude odchytávat a zpracovávat po°ízené snímky a proto implementuje rozhraní Camera. PreviewCallback. Nyní je hotový náhled kamery. Dal²ím krokem je vytvo°ení t°ídy

10/55

2.3



Obrázek 9: VideoActivity schéma

VideoActivity se vytvo°í stejným postupem jako t°ída CameraPreview. NaActivity a implementuje se interface pro odchytávání fotograí Camera.PreviewCallback. Aby byla zaji²t¥na správná funk£nost aktivity, musí se o²et°it její stavy p°idáním onCreate(), onPause() a onResume() funkcí. To lze v prost°edí Eclipse provést jednodu²e: kliknutím do kódu pravým tla£ítkem, vybráním se volby Source > Override/Implement Methods..., kde se za²krtnou poºadované funkce. T°ída

staví se d¥d¥ní t°ídy

Ve funkci

onCreate()

se denuje gracké uºivatelské rozhraní. D·leºité je vytvo°ení ná-

hledu kamery a jeho p°idání do aktuálního zobrazení (layoutu) viz obrázek 10.

Obrázek 10: VideoActivity onCreate()

Funkce

onResume()

je volána, kdyº se aktivita stane aktivní a za£ne dostávat uºiva-

telský vstup. V tento moment za£íná být aktivita viditelnou a m¥l by se za£ít zobrazovat náhled kamery (za£ít vyhodnocování snímk·). Proto se ve funkci

onResume()

nejd°íve

inicializuje kamera, nastaví její parametry a p°edá se instance kamery náhledu.

11/55

2.3



Obrázek 11: VideoActivity onResume()

Funkce

onPause()

je volána t¥sn¥ p°ed p°ekrytím grackého výstupu jinou aktivitou

a ztrátou uºivatelského vstupu. Ve funkci

onPause()

se standardn¥ uvol¬uje kamera pro

ostatní aktivity.

Obrázek 12: VideoActivity onPause()

VideoActivity implementuje Camera.PreviewCallback, který vyºaduje imonPreviewFrame(byte[] data, Camera camera) zobrazené na obrázku 13. Tato funkce je volána díky nastavení poslucha£e setPreviewCallback(VideoActivity), T°ída

plementaci funkce

ve t°íd¥

CameraPreview. Parametr data nese kopii snímku z náhledu kamery ve formátu

NV21 a parametr camera je reference na objekt kamery, ze které kopie snímku pochází. Konkrétní zpracování snímku závisí na struktu°e aplikace a je popsáno v následující kapitole.

Obrázek 13: VideoActivity onPreviewFrame

12/55

2.4

2.4


Struktura aplikace

Struktura aplikace

Struktura aplikace je navrºena pro dosaºení co nejrychlej²ího zpracování obrazu. Systém Android je postaven na n¥kolika vrstvách. ást pracující s kamerovým hardware je napsaná v jazyce C++ a odchycené snímky jsou kopírovány do £ásti psané v jazyce JAVA a tedy do Dalvik Virtual Machine. Jelikoº se pro zpracování obrazu pouºívá standardní prost°edí, napsané výhradn¥ v jazyce JAVA, tomuto zdrºení se nedá vyhnout. Prvním krokem k vytvo°ení aplikace, pro rychlé zpracování obrazu, je vyuºití hardwarové akcelerace. Díky hardwarové akceleraci nebude vyºíván pro vykreslování obrazu procesor a výpo£etní výkon je moºno pouºít na zpracování snímk·. Ve²keré úpravy obrazu budou provád¥né na grackém £ipu za°ízení pomocí OpenGL knihovny. Hardwarová akcelerace lze zapnout p°idáním v

AndroidManifest.xml.

android:hardwareAccelerated="true"

do

Dále je vhodné odd¥lit zpracování fotograí od vlákna uºivatelského rozhraní (UI), proto je pro zpracování fotograí vytvo°eno samostatné vlákno. V n¥kterých p°ípadech jde zpracování fotograí rozd¥lit do více vláken, £ehoº se vyuºívá nap°. u rekonstrukce hloubky prost°edí. Dal²í £ástí aplikace bude prostor pro vykreslení zji²t¥ných p°íznak· a pohybu kamery. Na vykreslení pouºívám op¥t SurfaceView, které bude díky hardwarové akceleraci vykreslované p°es GPU.

Obrázek 14: Schéma t°ídy VideoActivity

Pro zjednodu²ení jsou v²echny implementované £ásti (nap°.: detektory, sledování p°íznak· a mapování prost°edí) potomky abstraktní t°ídy

VideoActivity

implementující

ImageProcessing interface. Kaºdá t°ída implementující ImageProcessing se musí um¥t inicializovat (init() ), vykreslit výstup (drawResult(Canvas canvas) ) a provád¥t vlastní algoritmus (process() ).

13/55

2.4

Struktura aplikace


Základní stavební kameny aplikace jsou zobrazeny na obrázku 14. Krom¥ t°ídy

raPreview

a rozhraní

• ThreadProcess • Visualization T°ída

ImageProcessing

Came-

se jedná o:

- vlákno pro zpracování obrazových dat

- potomek SurfaceView, který zaji²úje vykreslení zji²t¥ných údaj·

ThreadProcess

je potomkem systémové t°ídy

vání obrazových dat pomocí volání funkce

process

Thread

a probíhá v ní zpraco-

viz obrázek 16. Funkci

process musí

implementovat kaºdý potomek t°ídy VideoActivity. Snímek ur£ený ke zpracování je vºdy kopií p·vodního snímku, jelikoº ukládání nového a zpracování p·vodního snímku probíhá paraleln¥. Akce kopírování snímku je synchronizovaná s akcí po°izování nového snímku. K tomuto ú£elu slouºí prázdný objekt

lockGray,

který blokuje b¥h obou £ástí sou£asn¥.

Obdobn¥ musí být synchonizovaný výstup spo£ítaných dat na displej a samotný výpo£et (objekt

lockOutput ).

Jelikoº výpo£et b¥ºí n¥jakou dobu, není vhodné zobrazovat spo£í-

tané údaje nad náhledem kamery, který se m¥ní rychleji neº probíhá výpo£et, a tak by výstupní data byly zobrazeny nad jiným snímkem neº je ten práv¥ zpracovávaný viz obrázek 15b. Proto se spolu s vypo£ítanými daty vykresluje i snímek, na kterém se data po£ítala viz obrázek 15a.

(a) P°íznaky ve vyhodnocovaném snímku

(b) P°íznaky nad náhledem kamery

Obrázek 15: Ukázka posunutí p°íznak· oproti reálným pozicím

P°evod snímku je zaji²t¥n pomocí funkcí z knihovny BoofCV, jelikoº je p°evod pomocí standardních funkcí Androidu pomalej²í. V BoofCV je p°evod zaji²t¥n pomocí tzv. skript·, které pracují paraleln¥ na v²ech nevytíºených jádrech za°ízení.

RS

rs

skripty posky-

tují mnohem v¥t²í výpo£etní výkon, jak kód napsaný v jazyce JAVA. Bohuºel v BoofCV je takto zpracován pouze p°evod snímk·, ostatní algoritmy b¥ºí v jazyce JAVA. Poslední akcí, po vyhodnocení algoritmu, je volání funkce

postInvalidate()

na objekt t°ídy

Visu-

alization, který zajistí p°ekreslení výstupních dat na displej za°ízení.

14/55

2.4

Struktura aplikace


Obrázek 16: Kód t°ídy

ThreadProcess

funkce

run

Visualization, zobrazená na obrázku 18, je sou£ástí abstraktní t°ídy VideoActivity. Obsahuje konstruktor s nastavením d·leºitého parametru setWillNotDraw(false) udávající, ºe se objekt nep°ekresluje sám, ale je p°ekreslován externím voláním postInvalidate(). Dále obsahuje funkci onDraw(Canvas canvas), která je volána p°i p°ekreslování Privátní t°ída

a provádí základní úpravy obrazu, jako je zmen²ení nebo zv¥t²ení plátna, jeho posunutí do st°edu displeje a vykreslení zpracovávaného snímku. Vykreslení spo£ítaných dat provádí potomci ve funkci

drawResult(canvas).

Rozm¥ry plátna se m¥ní tak, aby se zachoval pom¥r stran snímku a plátno bylo co nejv¥t²í.

Obrázek 17: Neupravený snímek (320x240px)

15/55

2.4

Struktura aplikace


Obrázek 18: Privátní t°ída

T°ída

CameraPreview

d¥dí t°ídu

Visualization

ViewGroup

místo t°ídy SurfaceView. Náhled sní-

mané scény je nutný pro získání dat, ale nemusí být p°ímo vid¥t. Je dobré ho zmen²it,

setMeasuredDimension(sirka,vyska), která je platná pouze ve funkci onMeasure(sirka,vyska). Rodi£ovská funkce onMeasure odchytává výjimku IllegalStateException, která vzniká aby mén¥ zat¥ºoval graku za°ízení. Zmen²ení lze provést pomocí metody

p°i zm¥n¥ rozm¥r·. Pro p°ípad vyuºití náhledu je zde i varianta zamezující roztaºení náhledu p°es celý displej.

16/55

2.4

Struktura aplikace


Obrázek 19: Funkce

onMeasure

v

CameraPreview

Funkce onLayout slouºí k nastavení pozice potomk· ViewGroup, coº je náhled SurfaceView. Ten byl p°idán do ViewGroup pomocí funkce addView(nahled_kamery).

Obrázek 20: Funkce

onLayout

v

CameraPreview

17/55


3

Práce s knihovnou BoofCV BoofCV je open-source knihovna, psaná v jazyce Java, slouºící pro zpracování obrazu

v reálném £ase. Funkce jsou optimalizované na nízké úrovni, díky tomu dosahuje stejných rychlostí jako ostatní nativní knihovny nap°. OpenCV [7]. BoofCV je organizována do n¥kolika balí£k·.

• Image processing

- obsahuje b¥ºn¥ pouºívané funkce pro zpracování fotograí,

které pracující s pixely

• Features

- obsahuje algoritmy extrahující p°íznaky z obrazu

• Calibration

- obsahuje funkce pro získání parametr· monokulární a stereo kamery

• Geometric vision

- obsahuje algoritmy extrahující p°íznaky pouºitím 2D a 3D

geometrie

• Visualize • IO ásti

- obsahuje funkce pro zobrazení spo£ítaných dat

- obsahuje funkce pro vstup a výstup

Visualize

a

IO

nelze pouºít na OS Android. Pro vstupy, výstupy a vizualizaci v

rámci systému Android slouºí knihovna BoofCVAndroid, která obsahuje p°evody snímk· do formátu, se kterým pracuje BoofCV, funkce pro uloºení a na£tení parametr· kamery a funkce pro vizualizaci snímk·, hran a hloubky snímané scény.

3.1

Získání funk£ní verze

V²echny pot°ebné zkompilované knihovny lze stáhnout z internetových stránek [8]. Bohuºel je v¥t²ina kompilována pomocí

JDK7

a Android vyºaduje knihovny kompilované

JDK6. P°i pokusu pouºít funkci z knihovny zkompilované pomocí JDK7 vznikne java.lang.NoClassDefFoundError. V²echny knihovny se proto musí zkompilovat pomocí JDK6. K tomu slouºí program Apache Ant, jehoº instalace je uve-

pomocí

chybové hlá²ení -

dena v kapitole 2.1.1.

Pot°ebné knihovny • BoofCV, BoofCVAndroid • DDogleg

- odkaz na zdrojový kód je na stránkách [8]

- knihovna pro nelineární optimalizaci, polynomiální stromové vyhledávání,

t°íd¥ní, ltrování matematických model· a dal²í uºite£né funkce. Zdrojový kód lze stáhnout ze stránek [9]. Ke své funk£nosti pot°ebuje knihovnu

EJML.

18/55

3.2


Kalibrace kamery

• EJML

- Ecient Java Matrix Library zprost°edkovává rychlé °e²ení lineárních úloh

a práci s maticemi. Je to jediná knihovna, kterou nebylo pot°eba znovu kompilovat. Zkompilovaná lze stáhnout ze stránek [10].

• GeoRegression

- Geometric Regression Library je knihovna zam¥°ující se na geo-

metrii ve 2D a 3D prostoru. Denuje datové typy jako je bod, p°ímka, vektor, jejich transformace a dal²í matematické geometrické operace. Pro kompilaci na Microsoft Windows je nutné otev°ít p°íkazový °ádek (Ctrl+win, napsat

cmd a potvrdit). Pomocí p°íkazu cd p°ejít do sloºky obsahující soubor build.xml,

p°ípadn¥ podobný

zev_souboru.xml

xml soubor denující strukturu knihovny. Voláním p°íkazu

ant na-

se spustí kompilace. Názvy sloºek se zkompilovanými knihovnami jsou

uvedeny p°i kompilaci. Zkompilované knihovny mají koncovku

.jar. Pro pouºití knihoven libs.

v aplikaci je nutné tyto knihovny zkopírovat do projektu, do sloºky

3.2

Kalibrace kamery

Fotoaparáty, které se v sou£asné dob¥ vyráb¥jí neposkytují obecný optický model. o£ky nemají dokonalý st°ed, pixely nejsou £tvercové a dochází k radiálnímu zkreslení. Zkosení fotograe se v¥t²inou, díky pravoúhlým pixel·m, p°edpokládá nulové. Nedokonalost obrazu není v¥t²inou viditelná, ale výrazn¥ ovliv¬uje strojové výpo£ty a tím i rekonstrukci obrazu. Pro rekonstrukci obrazu je pot°eba tyto nedokonalosti odstranit. Zjistit vnit°ní parametry kamery a p°epo£ítat snímky, aby platil obecný optický model.

Kalibrace kamery znamená ur£ení následujících vnit°ních parametr· kamery:

• Focal length

- ohnisková vzdálenost

• Principal point • Skew coecient • Distortions

- hlavní bod obrazu leºící na p°ímce mezi kamerou a ohniskem - koecient zkosení fotograe

- koecienty radiálního zkreslení

19/55

3.2


Kalibrace kamery

3.2.1

Projekce snímku do obecného optického modelu

Pokud známe vnit°ní parametry kamery, m·ºeme zkreslený snímek promítnout do nezkresleného následujícím postupem.

[Xc , Yc , Zc ], Xc je a Zc je ohnisková

1. P°edpokládejme bod snímku jako bod v prostoru se sou°adnicemi

x

sou°adnice

bodu v obraze,

vzdálenost. Potom

xn

Yc

je sou°adnice

y

bodu v obraze

je normalizovaná "dírková" projekce bodu (pinhole image pro-

jection).

xn = 2. Sou°adnice

xd

Xc /Zc Yc /Zc

(1)

bez radiální zkreslení denujeme následovn¥.

xd = 3. Finální sou°adnice

xp

Xd (1) Yd (2)

= 1 + kc(1)r2 + kc(2)r4 xn

se £tvercovými pixely a st°edem posunutým do

point získáme vynásobením maticí M .

(2)

principal



   xp xd (1)  yp  = M  xd (2)  1 1 Matice

M

(3)

je v následujícím tvaru.



 f c(1) skew cc(1)  0 f c(2) cc(2)  0 0 1 Ohnisková vzdálenost je

[f c(1), f c(2)],

hlavní bod obrazu je

(4)

[cc(1), cc(2)]

a

skew

je

zkosení. Po p°epo£ítání v²ech pixel· fotograe spl¬uje obecný optický model. P°epo£ítávat kaºdý snímek by bylo £asov¥ náro£né, proto se v¥t²inou p°epo£ítávají pouze pozice p°íznak·. Pro transformaci bod· existuje v BoofCV t°ída

PointTransform_F64.

Obrázek 21: P°íklad transformace bod·

20/55

3.2


Kalibrace kamery

3.2.2

Aktivita zji²t¥ní vnit°ních parametr· kamery

P°i implementaci aktivity, slouºící k zji²t¥ní vnit°ních paremetr· kamery, se nejd°ív vytvo°í t°ída, která bude potomek VideoActivity a bude implementovat ImageProcessing interface. Kalibrace pot°ebuje snímky v jiném formátu neº v¥t²ina ostatních výpo£t·, a proto byl do VideoActivity naimplementován p°evod snímku do objektu t°ídy

Obrázek 22: Základ t°ídy

ImageFloat32.

AutomatickaKalibraceKamery

Pro kalibraci je nutné denovat parametry kalibra£ní m°íºky, prom¥nné algoritmu a místo pro uloºení nam¥°ených hodnot.

Obrázek 23: Denice prom¥nných

Parametry kalibrace jsou statické prom¥nné, coº umoº¬uje nastavit vlastnosti m°íºky p°ed samotnou kalibrací (p°ed vytvo°ením objektu). Ve funkci

init

se inicializují objekty

edit ), detekci roh· m°íºky (prom¥nná detector ), rozmíst¥ní bod· ve m°íºce (prom¥nná target ) a samotný algoritmus výpo£tu vnit°ních parametr· kamery (prom¥nná calibrationAlg ).

pro ukládání hodnot (prom¥nná

21/55

3.2


Kalibrace kamery

Obrázek 24: Inicializace kalibrace

Funkce

process

z obrázku 25 hledá v kaºdém snímku rohy kalibra£ní m°íºky, coº je

pom¥rn¥ rychlé a Samgung Galaxy S2 zpracuje p°ibliºn¥ 13 snímk· za vte°inu. Pomalé je následné vyhodnocení vnit°ních parametr· kamery. V tabulce 1 je vid¥t, jak dlouho probíhal výpo£et p°i r·zných po£tech zpracovávaných snímk·. Po£et snímk·

Doba výpo£tu [s]

6

1,568

10

5,770

15

8,627

20

25,198

25

41,526

Tabulka 1: as vyhodnocování vnit°ních parametr· kamery

P°i 13fps získáme za 2s p°es 25 snímk·. Jelikoº byli snímky po°ízeny v tak krátkém £asovém intervalu, budou pravd¥podobn¥ hodn¥ podobné, z £ehoº vyplývá, ºe vnit°ní parametry kamery budou nep°esné. Je rozumné p°idávat do vyhodnocení pouze rozdílné snímky. Snímky jsou denovány pozicí roh· kalibra£ní m°íºky, sta£í tedy vyhodnotit rozdílnost pozic t¥chto roh·. Nejjednodu²²í je spo£ítat vzdálenost pozic roh· v jiº po°ízených snímcích oproti pozicím roh· sou£asného snímku a tuto vzdálenost porovnat s danou hodnotou, závisející na rozli²ení. Na základ¥ porovnání bu¤ detekované rohy p°idat do

calibratibody slouºí k drawResult(Canvas

vyhodnocení, nebo je vykreslit na displeji. Do seznamu snímk· pro výpo£et

onAlg.addImage(snímek)

se p°idávají pouze rozdílné snímky. Prom¥nná

uloºení roh· kalibra£ní m°íºky vykreslovaných na displeji (funkce

canvas))

a v prom¥nná

výpo£tu. Funkce

kalibracni_body

je seznam s jiº p°idanými pozicemi roh· do

textbfdostatecnaZmena vrací

false, pokud jsou snímky podobné, a true,

pokud jsou rozdílné. Míra podobnosti snímk· je nastavena tak, aby byl maximální po£et snímk· p°ibliºn¥ 25.

22/55

3.2


Kalibrace kamery

Obrázek 25: Vyhodnocení snímku

Funkce

drawResult

vykreslí body uloºené v prom¥nné

body

a zobrazí po£et snímk·.

Obrázek 26: Vykreslení roh· kalibra£ní m°íºky

Výpo£et vnit°ních parametr· kamery je v samostatném vlákn¥, aby neblokoval vlákno UI. Pro zjednodu²ení není pouºito klasické vlákno Thread, ale t°ída T°ída

AsyncTask.

AsyncTask zprost°edkovává funkce:

• doInBackground metr· kamery

- b¥ºí v samostatném vlákn¥, obsahuje výpo£et vnit°ních para-

calibrationAlg.process()

• onPostExecute

- funkce volaná po dokon£ení

doInBackground

obsahuje uloºení

hodnot

• onProgressUpdate

- nevyuºito ale umoº¬uje aktualizovat hodnoty za b¥hu vlákna

(nap°íklad: kolik procent dat je jiº zpracováno) 23/55

3.3


Detektory

calibrationAlg.process() vrací vnit°ní parametry kamery IntrinsicParameters. Pro uloºení hodnot do SharedPreferences musíme nejd°ív hodnotu nastavit edit.putString( klí£, hodnota) a poté ji odeslat edit.commit(). K tomu slouºí funkce setPrefer. Funkce

Obrázek 27: Vyhodnocení vnit°ních parametr· kamery

3.3

Detektory

Detektory slouºí k nalezení zajímavých bod· - p°íznak·. P°íznaky jsou místa v obraze, která lze popsat matematicky a uchovávají významnou informaci oproti okolí. Optimální p°íznak by m¥l být invariantní v·£i nato£ení a m¥°ítku, dávat r·zné hodnoty pro r·zné objekty a být po£itatelný v reálném £ase. P°íznaky se vyuºívají nap°íklad p°i spojování fotograí, rozpoznávání objekt·, zji²óvání rychlosti a pohybu t¥les. V záv¥ru práce je ukázáno, jak je pouºít k lokalizaci v 3D prostoru. P°íznaky lze d¥lit podle popisované domény na:

• Fotometrické

- p°íznaky popisující optické vlastnosti (nap°.: maximální a minimální

úrove¬ jasu, kontrast, histogram p°íznaku)

• Radiometrické

- p°íznaky popisující geometrické vlastnosti (nap°.: velikost, obvod,

orientace, konvexnost) Podle oblasti popisu na:

• Regiony

- p°íznaky popisující regiony pomocí jasových hodnot

• Hranice

- p°íznaky popisující oblast tvarem

24/55

3.3


Detektory

BoofCV implementuje n¥kolik úrovní pro vytvo°ení detektor· p°íznak·. V nejvy²²í úrovni se vytvá°í t°ída

DetectDescribePoint, která detekuje a zárove¬ popisuje regiony

v obraze.

Obrázek 28: Funkce vytvá°ející objekt t°ídy DetectDescribePoint

SIFT a SURF, sloºit vlastní detektor, s popisem p°íznak·, pomocí funkce fuseTogether. Na této úrovni lze vytvo°it detektory s popisem bod· pomocí

nebo

Obrázek 29: Parametry funkce fuseTogether

OrientationImage vytvá°í t°ída FactoryOrientation, funkce convertImage. Funkce convertImage má dva parametry, prvním je algoritmus orientace (vytvá°í t°ída FactoryOrientationAlgs ) a druhým t°ída zpracovávané fotograe. OrienObjekt implementující

tationImage je interface t°íd, které slouºí pro ur£ení orientace v popisovaném regionu. Objekt implementující

Point

DescribeRegionPoint

vytvá°í t°ída

FactoryDescribeRegion-

a slouºí k popisu detekovaného regionu.

Obrázek 30: Algoritmy popisu, funkce t°ídy FactoryDescribeRegionPoint

25/55

3.3


Detektory

Objekt implementující interface

InterestPointDetector

vytvá°í t°ída

FactoryInte-

restPoint a je to detektor, detekující p°íznaky v obraze. V²echny pot°ebné operace pro výpo£et jsou implementované uvnit° a vyhodnocení se provádí voláním funkce detect(snímek). Na této úrovni lze vytvo°it Hessian detektor, SIFT detektor a p°ípadn¥ sloºit vlastní detektor pomocí ºlut¥ ozna£ených funkcí na obrázku 31.

Obrázek 31: Funkce t°ídy FactoryInterestPoint

V knihovn¥ BoofCV existují t°i r·zné druhy detektor·, které lze obalit do objektu imple-

InterestPointDetector a to FeatureLaplacePyramid, FeaturePyramid GeneralFeatureDetector. FeatureLaplacePyramid a FeaturePyramid se vytvá°í pomocí t°ídy FactoryInterestPointAlgs a jedná se o algoritmy detekující regiony. lut¥

mentujícího a

ozna£ené algoritmy na obrázku 32 vyuºívají jako základ detekci roh·, ostatní jsou zaloºené na hledání extrém· v obraze.

Obrázek 32: Funkce t°ídy FactoryInterestPointAlgs

Detektory detekující pozici zajímavých bod· v obraze jsou objekty t°ídy

GeneralFea-

tureDetector. Vytvo°it je lze pomocí t°ídy FactoryDetectPoint. lut¥ ozna£ené funkce z obrázku 33 dovolují sloºit vlastní detektor zaloºený na intenzit¥ p°íznak· (GeneralFeatureIntensity ) nebo intenzit¥ roh· (GradientCornerIntensity ).

Obrázek 33: Funkce t°ídy FactoryDetectPoint

26/55

3.3


Detektory

FactoryIntensityPoint. FactoryIntensityPoint vytvá°í objekt t°ídy GeneralFeatureIntensity viz obráT°ída slouºící k vytvo°ení algoritmu po£ítajícího intenzitu p°íznak· je

zek 34.

Obrázek 34: Funkce t°ídy FactoryIntensityPoint

FactoryIntensityGradientCornerIntensity interface

B¥ºn¥ puºívané algoritmy pro výpo£et intenzity roh· vytvá°í t°ída

PointAlg.

Algoritmy jsou objekty implementující

viz obrázek 35.

Obrázek 35: Funkce t°ídy FactoryIntensityPointAlg

3.3.1

Detekce hran

Detekce hran slouºí k rozpoznávání hranice objekt·. BoofCV umoº¬uje vytvo°it bu¤ de-

CannyEdge (pomocí t°ídy FactoryEdgeDetectors ), a nebo jeden ze základních ImageGradient (pomocí t°ídy FactoryDerivative ). Výstup ImageGradient je obrázek s hranami. CannyEdge umí navíc ud¥lat jako výstup seznam obrys·

tektor

detektor· t°ídy

objekt· obsaºených v obrázku. Obrysy se dají dále vyuºít k u£ení vzor· a rozpoznávání p°edm¥t·. V knihovn¥ BoofCV jsou implementovány t°i základní detektory hran, a to a

three.

Vytvo°ení a pouºití t¥chto detektor· je zobrazeno na obrázku 36.

prewitt,sobel Ve funkci init

se inicializuje jeden ze t°í vý²e uvedených detektor· a snímky pro uloºení detekovaných hran. Funkce

process

zpracuje snímek a vytvo°í výstup na displej. Funkce

drawResult

není vyuºita.

27/55

3.3


Detektory

Obrázek 36: Detektory hran

3.3.2

Detekce roh·

Jedním z nejjednodu²²ích p°íznak· v obraze jsou rohy. Roh m·ºe být denovaný jako pr·se£ík dvou hran 37a, nebo také jako bod sousedící s dv¥ma hranami v rozdílných sm¥rech 37b. V¥t²ina detektor· detekuje zajímavé body, které nemusí být pouze rohy. Zajímavý bod je bod, který je dob°e matematicky denovaný. M·ºe to být roh, ale i konec £áry, maximum nebo minimum na k°ivce, nebo izolovaný bod s rozdílnou intenzitou jasu.

(a) Pr·se£ík dvou hran

(b) Bod sousedící se dv¥mi hranami

Obrázek 37: P°íklad roh·

28/55

3.3


Detektory

Kvalita detektor· je obecn¥ posuzována podle schopnosti detekovat stejné p°íznaky na více podobných fotkách s r·zným osv¥tlením, p°iblíºením a oddálením, pod r·zným úhlem a dal²ích základních transformacích.

FAST detektor Detektor "Features from Accelerated Segment Test"(FAST) zkoumá jas pixel· leºících na kruºnici o daném polom¥ru. Roh je detekován pokud na této kruºnici existuje souvislá £ást pixel· s v¥t²ím resp. men²ím jasem neº je ve st°edu kruºnice. Tato souvislá £ást kruºnice musí být del²í neº polovina kruhu. Algoritmus vºdy zkoumává pixel s nejv¥t²ím informa£ním ziskem (nejmen²í entropií). Hledání rohu je tedy procházení stromu pixel· leºících na kruºnici. Algoritmus pouºitý na prozkoumávání pixel· se jmenuje ID3 a není optimální, negarantuje nejlep²í °e²ení.

Obrázek 38: P°íklad porovnávaných pixel· ze stránek [2]

CongGeneralDetecpomocí t°ídy FactoryDetect-

K nastavení obecných parametr· detektoru slouºí objekt t°ídy

tor. Vyºadují ho v²echny detektory roh·, které se vytvá°í Point. CongGeneralDetector má sedm prom¥nných, které

denují vlastnosti detek-

toru, ale pro ú£ely rekonstrukce p°íznak· dosta£uje nastavit t°i základní :

• maxFeatures • radius

- horní hranice po£tu hledaných p°íznak· (cca. 80-150)

- nastavení, v jakém polom¥ru je roh vyhodnocován (cca. 2-3)

• threshold

- minimální rozdíl intenzit detekovaného p°íznaku (cca. 10-35)

29/55

3.3


Detektory

GeneralFeatureDetector se vytvá°í voláním funkce createFast s CongFast, CongGeneralDetector a ImageBase. Detektor t°ídy GeneralFeatureDetector je vhodné obalit do t°ídy InterestPointDetector, která automaticky generuje derivace pot°ebné pro detektor a vrací seznam nalezených p°íznak· (v p°ípad¥ detektoru FAST seznam roh·). Pro obalení slouºí t°ída FactoryInterestPoint a pro rohy konkrétn¥ funkce wrapPoint. FAST detektor t°ídy

parametry v podob¥ objektu t°ídy

• CongFast

- nastavení pro algoritmus FAST, vytvo°íme pomocí konstruktoru

gFast(int pixelTol, int minContinuous)

Con-

pixelTol - nastavení jak velký rozdíl intenzit je povaºován za okraj rohu. Parametr je závislý na fotograi. (cca. 20)

minContinuous - nutný minimální po£et pixel· na kruºnici, aby byl detekován roh (cca. 9-12)

• CongGeneralDetector • imageType

- hlavní nastavení detektoru viz. 3.3.2

- je potomek ImageSingleBand, který denuje t°ídu vstupních snímk·

do algoritmu (ImageUInt8.class)

FactoryInterestPoint

funkce

wrapPoint

• GeneralFeatureDetector • double scale • imageType • derivType

vyºaduje parametry:

- hlavní nastavení detektoru

- nastavení rozsahu detekovaných p°íznak·

- t°ída vstupní fotograe

- t°ída derivace vstupní fotograe (hrany vstupní fotograe)

30/55

3.3


Detektory

Výsledný kód pro inicializaci FAST detektoru je uveden na obrázku 39.

Obrázek 39: Inicializace FAST detektoru

detect(snimek). Pozice detekovaných p°íznak· getLocation(poradi_priznaku) a jejich celkový po£et pomocí funkce getNumberOfFeatures(). Vykreslení se pak provádí obdobn¥ jako p°i automatické Vlastní proces algoritmu se volá funkcí

lze získat voláním funce

kalibraci viz obrázek 26.

Obrázek 40: Proces a vykreslení FAST detektoru

31/55

3.3


Detektory

Harris·v detektor Harris·v detektor je invariantní v·£i anním transformacím (nap°.: zv¥t²ování a rotaci). Detekované p°íznaky jsou stejné na fotkách z r·zných pohled·. V·£i p°ibliºování a oddalování obrazu je detektor invariantní také díky Gaussov¥ reprezentaci p°ibliºování a oddalování. Algoritmus je zaloºený na tom, ºe se v rohu st°etávají hrany ve více sm¥rech. Harris·v detektor je vylep²ení Moravcova detektoru roh·, který hledá minima sum £tverc· mezi hranami. Inicializace Harris detektoru se doplní do funkce se vytvo°í voláním funkce Parametry funkce

createHarris.

createHarris

• GeneralFeatureDetector • boolean weighted

init

uvedené na obrázku 39. Detektor

jsou: - hlavní nastavení detektoru

- nastavení, jestli se má pouºít Gaussova reprezentace p°ibliºování

a oddalování (bez ní je detektor výrazn¥ rychlej²í)

• derivType

- t°ída derivace vstupní fotograe (hrany vstupní fotograe)

InterestPointDetector obdobn¥ jako u FAST detektoru. P°íklad kódu dopln¥ného do funkce init je uvedený na obrázku 41. Funkce process a drawResult z·stávají stejné jako u FAST detektoru viz obrázek 40.

Detektor je nutné obalit do t°ídy

Obrázek 41: Inicializace Harris detektoru

Shi-Tomasi detektor Shi-Tomasi detektor pouºívá jádro Harrisova detektoru. Spo£ítá vlastní £ísla matice Harrisova detektoru a vybere to men²í z nich. Toto £íslo pak reprezentuje daný zajímavý bod. Shi-Tomasi detektor se ob£as nazývá Kanade-Tomasi detektor a detekuje body vhodné pro sledování pohybu p°íznak· v sekvenci snímk·. Detektor se inicializuje voláním funkce Harris·v detektor. Funkce

createShiTomasi

se stejnými parametry jako

process a drawResult z·stávají stejné jako u FAST detektoru

viz obrázek 40. 32/55

3.3


Detektory

3.3.3

Detekce region·

Detektory zaloºené na detekci region· v digitální fotograi zkoumají p°eváºn¥ histogram jasu, geometrické tvary, lokální extrémy, p°ípadn¥ regiony v okolí zajímavých bod·. Výhodou t¥chto detektor· je, ºe nepopisují pouze daný roh nebo hranu, ale dávají informaci o celé oblasti.

Hessian detektor Hessian detektor je tém¥° identický jako Harris·v detektor. Pr·b¥h detekce je stejný, pouze

FactoryInterestPoint, voláním funkce fastHessian s parametrem, který je objekt t°ídy CongFastHessian. vyuºívá Hessovu matici. Inicializace se provádí pomocí t°ídy

Parametry konstruktoru

CongFastHessian :

• oat detectThreshold

- minimální intenzita p°íznaku. Parametr závislý na fotogra-

i. (cca. 10-35)

• int extractRadius

- velikost p°íznak· pouºitá pro detekci roh· (cca. 1-2)

• int maxFeaturesPerScale

- maximální po£et hledaných region·. Pokud nastavíme

<= 0 detektor vrací v²echy nalezené regiony. (cca. 80-150)

• int initialSampleSize • int initialSize

- hodnota jak £asto jsou pixely vzorkovány (cca. 1-2)

- výchozí velikost vyhodnocované oblasti (cca. 9)

• int numberScalesPerOctave • int numberOfOctaves

Funkce

- po£et p°iblíºení v oktáv¥ (cca. 3-4)

- po£et oktáv (cca. 3-4)

fastHessian vytvo°í Hessian detektor t°ídy FastHessianFeatureDetector, obaInterestPointDetector.

lený do t°ídy

Obrázek 42: Inicializace Hessian detektoru

Snímek se vyhodnocuje ve funkci

process

voláním

detect(snimek).

Po vyhodnocení

lze p°istupovat k jednotlivým p°íznak·m stejn¥ jako u FAST detektoru, p°i£emº polom¥r popsané oblasti lze získat funkcí

getScale(poradi_priznaku).

33/55

3.3


Detektory

(a) Výstup Shi-Tomasi detektoru

(b) Výstup Hessian detektoru

Obrázek 43: P°íklad výstup· detektor·

Ve funkci

drawResult

se vykreslí místo bod· kruºnice, které znázor¬ují jakou oblast

p°íznak popisuje viz. obrázek 43b.

SIFT detektor SIFT detektor je detektor extrahující z obrázku regiony, které jsou následn¥ popsány. Scale-invariant feature transform (SIFT) je algoritmus popisující lokální p°íznaky. Tento algoritmus je pouºíván ve strojovém rozpoznávání. Popisuje danou oblast více hodnotami neº detektory roh· a díky tomu ji lépe specikuje. Následné porovnávání region· probíhá porovnáním vektoru dané oblasti. SIFT je invariantní v·£i p°ibliºování, oddalování, zm¥n¥ orientace a £áste£n¥ v·£i zm¥n¥ osv¥tlení. Následující postup ukazuje pouºití SIFT detektoru knihovny BoofCV. Implementace je obdobná jako u p°edchozích detektor·. SIFT detektor obalený do t°ídy

InterestPointDetector se vytvo°í voláním funkce siftDetector t°ídy FactoryInterestPoint se dv¥ma parametry, které denují detektor. Prvním parametrem je objekt t°ídy CongSiftScaleSpace a druhým, objekt t°ídy CongSiftDetector.


• oat blurSigma • int numScales

CongSiftScaleSpace :

- aplikovaná velikost rozost°ení v oktáv¥ (cca. 1.6)

- po£et zv¥t²ení na oktávu (cca. 5)

• int numOctaves

- po£et detekovaných oktáv (cca. 3-4)

• boolean doubleInputImage

- nastavení, jestli budou fotograe p°edávané v páru

(false) 34/55

3.3


Detektory


• int extractRadius

CongSiftDetector :

- velikost p°íznak· vyuºitá pro detekci roh· (cca. 2)

• oat detectThreshold

- minimální intenzita rohu (cca. 10-35)

• int maxFeaturesPerScale • double edgeThreshold

- maximální po£et detekovaných p°íznak· (cca. 80-150)

- nastavení ltrování roh· (cca. 5)

Detektor vyºaduje fotograe ve formátu

ImageFloat32. Je pot°eba nastavit v konstruk-

toru hodnotu denující formát fotograe obdobn¥ jako u automatické kalibrace. Detekce probíhá pomocí volání

detect(ImageFloat32 snímek). Kód pro vykreslení popisovaného

okolí m·ºe z·stat stejný. Inicializace je zobrazena na následujícím obrázku £íslo 44.

Obrázek 44: Inicializace SIFT detektoru

Obrázek 45: Ukázka detekovaných p°íznak· pomocí SIFT detektoru

35/55

3.4

Asociace p°íznak·

3.4



Dal²ím krokem k ur£ení polohy za°ízení v prostoru je asociace p°íznak· mezi snímky. Jelikoº je pot°eba asociovat p°íznaky mezi v²emi po°izovanými snímky, jsou v práci vyuºívány algoritmy sledování, které knihovna BooFCV poskytuje.

Typy algoritm· sledování v knihovn¥ BoofCV:

• KanadeLucasTomasi (KLT) - jedná se o hybridní algoritmy sledování. Algoritmus detekuje regiony, vypo£te jejich popis a následn¥ hledá pozice region· v nových snímcích pomocí gradientní metody.

• Detekce deskripce asociace (DDA)

- detekuje p°íznaky, popí²e je a podle popisu

asociuje Algoritmus

KLT

postupuje od p·vodního umíst¥ní p°íznaku, ve sm¥ru, kde se nejvíce

p°ibliºuje popis dané oblasti popisu p·vodního p°íznaku. Metoda

DDA

je zaloºena na

porovnání popisu nalezených p°íznak· mezi snímky. Detektory jsou popsané v kapitole 3.3. P°íznaky, které se budou asociovat, popí²í pomocí deskriptor·. V následující £ásti krátce popí²i základní deskriptory, které jsou v aplikaci pouºity.

3.4.1

Pouºité deskriptory

SURF Speeded Up Robust Features (SURF) je robustní detektor p°íznak·. Slouºí k úlohám jako je nap°íklad rozpoznávání objekt· nebo rekonstrukce 3D. SURF £áste£n¥ vychází ze SIFT deskriptoru, ale jeho výpo£et je n¥kolikanásobn¥ rychlej²í a p°itom robustn¥j²í v·£i transformacím. Pro detekci pouºívá Hessian detektor, který lze spo£ítat extrémn¥ rychle z integrální fotograe. Integrální fotograe má na pozici pixelu uloºen sou£et v²ech p°edcházejících pixel· od po£átku fotograe. Okolí p°íznaku je následn¥ popsáno pomocí

wavelet

Haar

sum, které jsou op¥t po£ítané z integrální fotograe.

BRIEF Binary Robust Independent Elementary Features (BRIEF) je deskriptor p°íznak· kombinovatelný s libovolným detektorem, je robustní v·£i typickým obrazovým transformacím. Oblast je popsána pomocí binárního kódu. P°íznaky jsou následn¥ asociovány pomocí Hammingovi vzdálenosti, jejíº výpo£et je velmi rychlý. Jednotlivé bity jsou získány porovnáním intenzit pár· pixel· na daném rádku. 36/55

3.4



NNC Normalized Cross-Correlation (NCC) je algoritmus po£ítající normalizované k°íºové korelace obrázku, pomocí kterých lze popsat p°íznak k následné asociaci. Jedná se o vylep²ený algoritmus rychlé Fourier transformace, po£ítaný pomocí integrální fotograe. Normalizace jasu slouºí k zv¥t²ení robustnosti, p°i zm¥n¥ sv¥telných podmínek. NNC deskriptor má hor²í výsledky asociace, jak

3.4.2

SURF a BRIEF.

Implementace deskriptor·

DeskriptorRegionu. FactoryDetectDescribe. Na této úrovni jsou funkce pro vytvo°ení detektoru SURF Fast, SURF Stable, SIFT a funkce pro sloºení libovolného detektoru s libovolným popisem p°íznak·. T°ída DeskriptorRegionu implementuje rozhraní ImageProcessing a d¥dí VideoActivity. Ve funkci init se inicializuje objekt t°ídy DetectDescribePoint pomocí funkcí uvedených na obrázku 28. Celá struktura pro vytvo°ení t°ídy DetectDescribePoint je uvedená na za£átku kaPro ukázku rychlosti detekce a popisu region· je vytvo°ena t°ída

K vytvo°ení detektoru spojeného s deskriptorem slouºí t°ída

pitoly 3.3.

Parametry pro vytvo°ení SURF Fast detektoru: • CongFastHessian

- nastavení Hessian detektoru, uvedeno v kapitole 3.3.3

• CongSurfDescribe.Speed

- vnit°ní nastavení parametr·, detektor vyºaduje ob-

jekt této t°ídy

• CongAverageIntegral

- kongura£ní t°ída pro ur£ení orientace p°íznak·

radius - polom¥r popisovaného regionu (cca. 6) samplePeriod - perioda vzorkování (cca. 1) sampleWidth - ²í°ka jádra tvo°ící vzorek (cca. 6) weightSigma - váºení sigmy, automatické p°i hodnot¥ men²í jak nula (-1)

• imageType

- t°ída denující zpracovávané snímky

SURF Stable se od parametr· pro SURF Fast li²í v p°edání vnit°ního nastavení objektem t°ídy CongSurfDescribe.Stablility a kongura£ním objektem pro ur£ení orientace, který je sou£ástí t°ídy CongSlidingIntegral. Parametry pro vytvo°ení

37/55

3.4



Parametry

CongSlidingIntegral:

• samplePeriod • windowSize • radius

- perioda vzorkování (cca. 0.65)

- rozm¥r vzorkovacího okna (cca. 1)

- polom¥r popisovaného regionu (cca. 8)

• weightSigma

- váºení sigmy, automatické p°i hodnot¥ <0, a p°i hodnot¥ =0 není

sigma váºená (-1)

• sampleWidth

- ²í°ka jádra tvo°ící vzorek (cca. 6)

SIFT detektoru s popisem p°íznak· vyºaduje parametry CongSiftScaleSpace a CongSiftDetector, které jsou popsané v p°edchozí kapitole 3.3.3 a denují detektor. Dále parametry CongSiftOrientation a CongSiftDescribe, které popisují Vytvo°ení

deskriptor.

Parametry CongSiftOrientation: • histogramSize

- po£et vzork· v histogramu (cca. 36)

• sigmaToRadius • sigmaEnlarge

- p°evod sigmy na region pixel· o polm¥ru (cca. 2.5)

- uvaºovaná zm¥na rozm¥r· (cca. 1.5)

Parametry CongSiftDescribe: • gridWidth

- po£et element· uloºených podel m°íºky (cca. 4)

• numSamples • numHistBins • weightSigma

- po£et zkoumaných vzork· podel m°íºky (cca. 8) - po£et zásobník· histogramu (cca. 8) - váºení element· v·£i st°edu vzorku (cca. 0.5)

• sigmaToRadius

- p°evod sigmy na region pixel· o polm¥ru (cca. 3)

Pro vytvo°ení libovolného detektoru s libovolným popisem p°íznak· slouºí funkce t°ídy

FactoryDetectDescibe se jménem fuseTogether, která je uvedená na obrázku 30. Na Shi-Tomasi detektor s p°íznaky popsanými pomocí BRIEF deskrip-

ukázku jsem vytvo°il toru. Vytvo°ení

Shi-Tomasi detektoru je uvedeno v kapitole 3.3.2. Deskriptor BRIEF se

vytvá°í ve t°íd¥

s parametry: ob-

jektem t°ídy

FactoryDescribeRegionPoint voláním funkce brief CongBrief a t°ídou reprezentující fotograi.

38/55

3.4



CongBrief :

Parametry t°ídy

• radius

- polom¥r popisované oblasti (cca. 16)

• numPoints • blurSigma • blurRadius • xed

- po£et vzorkovaných pixel· (256 nebo 512)

- rozost°ení aplikované p°ed vzorkováním (cca. -1) - polom¥r rozost°ení (cca. 4)

- napevno nastavený polom¥r popisované oblasti (true)

fuseTogether je objekt t°ídy OrientationImage. Vytvá°í ho t°ída FactoryOrientation a slouºí k ur£ení orientace popisované oblasti viz schéma t°íd v kapitole 3.3. Jako algoritmus denující orientaci p°íznak· je vybrán sliding_ii, který zkou²í orientaci pod r·znými pravd¥podobnými úhly. Poslední neuvedený parametr funkce

Prametry

sliding_ii:

• CongSlidingIntegral

- popsáno u SURF Stable, p°i zadání null bude pouºito

základní nastavení

• integralType

- t°ída denující typ pouºité integrální fotograe

Výsledný kód inicializující uvedené detektory s popisem p°íznak· je uveden na obrázku 47. Vyhodnocení probíhá ve funkci

bePoint.

process

voláním

detect

na objetu t°ídy

DetectDescri-

Zobrazení detekovaných p°íznak· b¥ºí v jiném vlákn¥, proto je pot°eba uloºit

nalezené údaje, které se následn¥ ve funkci

drawResult

vykreslí.

Obrázek 46: Detekce, popis a vykreslení p°íznak·

39/55

3.4



Obrázek 47: Inicializace detektoru s popisem p°íznak·

3.4.3

Implementace trekr·

Implementace je uvedena ve t°íd¥ t°ídou

FactoryPointTracker.

Trekovani

a vyuºívá algoritmy sledování vytvo°ené

Algoritmy sledování slouºí pro porovnání vlastností, jako

je p°esnost a rychlost asociace. Inicializace vyuºívá parametry, které jsou popsané v d°ív¥j²ích kapitolách.

Seznam implementovaných algoritm·, zaloºených na gradientní metod¥

• klt

- vlastní

KLT algoritmus vyuºívající Shi-Tomasi detektor

• combined_FH_SURF_KLT mocí

KLT:

- rychlý

Hessian detektor s popisem p°íznak· po-

SURF deskriptoru

• combined_ST_SURF_KLT

-

Shi-Tomasi detektor s popisem p°íznak· pomocí

SURF deskriptoru 40/55

3.4



Seznam implementovaných algoritm·, zaloºených principu

• dda_FH_SURF_Fast lého

- rychlý

DDA:

Hessian detektor s popisem p°íznak· pomocí rych-

SURF deskriptoru

• dda_FH_SURF_Stable robustního

- rychlý

Hessian detektor s popisem p°íznak· pomocí

SURF deskriptoru

• dda_FAST_BRIEF • dda_ST_BRIEF • dda_ST_NCC

-

-

-

FAST detektor s popisem p°íznak· pomocí BRIEF

Shi-Tomasi detektor s popisem p°íznak· pomocí BRIEF

Shi-Tomasi detektor s popisem p°íznak· pomocí NCC

FactoryPointTracker umoº¬uje sloºit vlastní algoritmus sledování typu KLT combined ) i DDA (funkce dda ), coº znázor¬uje následující obrázek 48. Tmav¥

T°ída (funkce

ºluté ráme£ky jsou funkce

FactoryPointTracker a sv¥tle ºluté ráme£ky jsou jejich parame-

try.

Obrázek 48: Inicializace vlastního trekru

ást umíst¥ná ve funkci

process

zaji²úje vyhodnocení nového snímku, zkopírování

údaj· pro vykreslení, smazání neaktivních p°íznak· a p°idání nových p°íznak· v p°ípad¥, ºe jejich po£et klesne pod danou úrove¬.

3.4.4

Filtování asociovaných p°íznak·

Asociace p°íznak· vrací relativn¥ velký po£et pár· a £ást z nich je s velkou pravd¥podobností asociovaná ²patn¥. K výpo£tu pohybu kamery sta£í 7 pár·. Pro zji²t¥ní pohybu kamery a ov¥°ení, které páry jsou ²patn¥ asociované, je pouºit RANSAC (RANdom SAmple Consensus). RANSAC je pravd¥podobnostní metoda pro odhad matematického modelu z mnoºiny pozorování. Matematický model je v tomto p°ípad¥ pohyb kamery v·£i p°íznak·m a pozorování jsou asociované páry. Výstupem je odhadnutý posun, rotace kamery a pouºité asociované páry, nazývané

inliers.

41/55

3.4



Nejd°íve se inicializuje algoritmus denující model pohybu kamery. K tomuto ú£elu

FactoryMultiView, funkce computeFundamental_1, která vytvo°í objekt Estimate1ofEpipolar. Objekt Estimate1ofEpipolar se pro pouºití v RANSAC z knihovny DDogleg musí obalit do t°ídy GenerateEpipolarMatrix. Dal²í parametr pro vytvo°ení RANSAC, je objekt t°ídy DistanceFromModelResidual m¥°ící vzdálenost od odhadnutého modelu. Ten lze vytvo°it pomocí konstruktoru DistanceFromModelResidual s parametrem udávající algoritmus po£ítající tuto vzdálenost, nap°íklad FundamentalResidualSampson. Vlastní inicializace RANSAC spo£ívá ve vytvo°ení objektu t°ídy ModelMatcher. slouºí t°ída t°ídy

Parametry konstruktoru Ransac: • long randSeed

- libovolné £íslo, slouºí pro generátor náhodných £ísel

• ModelGenerator

- t°ída vytvá°ející náhodný model

• DistanceFromModel • int maxIterations

- po£ítá rozdíl mezi modelem a asociovanými páry

- maximální po£et iterací (cca. 200)

• double thresholdFit

- tolerance vzdálenosti od modelu v pixelech (cca. 0.5)

P°íklad inicializace výpo£tu Fundamentální matice:

Obrázek 49: Inicializace vlastního trekru

Inicializace na obrázku 49 neuvaºuje odstran¥ní distorze, proto nebudou hodnoty posunu p°esné. V této £ásti vytvá°í výpo£et fundamentální matice spí²e ltr pro zobrazení správn¥ asociovaných pár· (inliers ). Díky tomu je d·raz kladen na rychlost a výpo£et je zkrácen o dobu transformace snímk·, p°ípadn¥ p°íznak·. Výpo£et se spou²tí funkcí

pro-

cess s parametrem v podob¥ seznamu v²ech aktuáln¥ asociovaných pár·, na objektu t°ídy ModelMatcher. Po dokon£ení výpo£tu, jsou správn¥ asociované páry dostupné, voláním funkce getMatchSet.

42/55


4

Implementace rekonstrukce p°íznak· Rekonstrukce probíhá na základ¥ pohybu monokulární kamery. V p°ípad¥, ºe dojede

pouze k nato£ení, nelze vypo£ítat hloubka obrazu.

Obrázek 50: Základní schéma

Výpo£et posunu kamery je £asov¥ náro£ný a se vzr·stajícím posunem mezi správn¥ asociovanými snímky dostáváme lep²í informaci o hloubce obrazu. Proto se p°i volb¥ rekonstrukce (Zobrazit->Rekonstruované

prost°edí 1 ) provádí výpo£et posunu t¥sn¥ p°ed

p°idáním nových p°íznak· do t°ídy PointTracker viz kapitola 3.4.3. Je pravd¥podobné, ºe se nové p°íznaky do algoritmu sledování p°idávají práv¥ z d·vodu, ºe se v¥t²ina starých p°íznak· ztratila díky posunu kamery. Výpo£et posunu je umíst¥n ve vlastním vlákn¥. Vlastní vlákno zrychlí chod aplikace a del²í posun zp°esní údaj o pozici kamery. Z analýzy chování aplikace vyplývá, ºe se výpo£et posunu stihne dokon£it do dal²ího p°idávání bod·, tedy do za£átku dal²ího výpo£tu. Pro asociaci p°íznak· mezi snímky je pouºitý vybraný algoritmus z kapitoly 3.4.3.

4.1

Robustní výpo£et posunu

Pro p°esn¥j²í výpo£et posunu se z asociovaných pár· nejd°íve odstraní distorze a nor-

transformNormToRadial_F64 t°ídy LensDistorpomocí algoritmu Ransac pohyb kamery. Generátor model· vytvá°í konstruktorem t°ídy Se3FromEssentialGenerator,

mují se sou°adnice pomocí funkce

tionOps .

Následn¥ se ur£í

posunu se v tomto p°ípad¥

která má parametry: objekt s rychlým algoritmem odhadu pohybu kamery pomocí korespondence p¥ti bod·

EnumEpipolar.ESSENTIAL_5

a objekt

TriangulateTwo-

43/55

4.2


Rekonstrukce p°íznak·

Obrázek 51: GUI Rekonstrukce prost°edí

ViewsCalibrated triangulující z pohybu kamery pozici asociovaných bod· do 3D. Se3FromEssentialGenerator vrací nejlep²í odhadnutý posun a p°iblíºení z prvního do druhého snímku pomocí dekompozice fundamentální matice a omezení, ºe vzdálenost pixel· ve 3D musí být kladná. Vzdálenost od navrºeného modelu je denována objektem vytvo°eným pomocí konstruktoru jekt

triangulace, roztaºení a zkosení obou snímk· známých z vnit°ních parametr· kamery

(parametry:

4.2

DistanceSe3SymmetricSq, který má jako parametry p°edchozí ob-

fx,fy,skew ).


Rekonstrukce p°íznak· je ur£ení 3D polohy p°íznak· ze snímk· kamery z r·zných poloh. Rekonstruovaný bod leºící v prostoru je denován jako bod s minimální vzdáleností od p°ímek, které prochází asociovanými body a odpovídajícími pozicemi kamer. Bod v snímku zna£ím písmenem

bod¥ kamery

Ai

a je denovaný na obrázku 52a. St°ed snímku je v

Principal point

i-tém

hlavním

a kaºdý bod má sou°adnice [x,y] denované jako vzdálenost

od tohoto bodu.

i je ozna£ena písmenem

K1 = [k1x , k1y , k1z ] = [0, 0, 0]. Bod leºící na p°ímce procházející body Ai a Ki zna£ím Xi a je denován Xi = Ki + α ∗ ui = Ki + αi ∗ (Ai − Ki ). Optimaliza£ní úloha hledá bod Y = [yx , yy , yz ] s nejmen²í vzdáleností k bod·m X1,2,3..n danými parametry α1,2,3...n . Optimaliza£ní úloha je denována pro nalezení bodu Y z n snímk· následovn¥: Pozice kamery

Ki .

Pozice první kamery

Mt = b

(5)

44/55

4.2



(a) Denice sou°adnic A1

(b) Denice kamery K1 a bodu X1

Obrázek 52: Denice prom¥nných

P°íklad matice

M a vektoru t pro 3 kamery a jeden bod v prostoru (n

             

4.2.1

  u11 0 0 −1 0 0    u12 0 0 0 −1 0    α 1  u13 0 0 0 0 −1     α2      0 u21 0 −1 0 0     α 3   = − 0 u22 0 0 −1 0  ∗    yx     0 u23 0 0 0 −1     yy    0 0 u31 −1 0 0   y z  0 0 u32 0 −1 0  0 0 u33 0 0 −1

k1x k1y k1z k2x k2y k2z k3x k3y k3z

= 3, i = 1):              

(6)

Rekonstrukce p°íznak· v knihovn¥ BoofCV

Rekonstrukce p°íznak· z obrazu dvou kamer je provád¥na pomocí objektu t°ídy

gulateTwoViewsCalibrated, pouºitém i p°i odhadu posunu. gulate objektu t°ídy TriangulateTwoViewsCalibrated :

Parametry funkce

• Point2D_F64 obsA

- pozice asociovaného p°íznaku v prvním snímku

• Point2D_F64 obsB

- pozice asociovaného p°íznaku v druhém snímku

• Se3_F64 fromAtoB

- odhadnutý pohyb kamery

• Point3D_F64 foundInA

Triantrian-

- triangulovaný bod s hloubkou ur£enou v·£i prvnímu

snímku

Tento výpo£et je provád¥n zárove¬ s posunem kamery a to ve v²ech volbách zobrazení.

45/55

4.3


Rekonstrukce prost°edí

4.3


Rekonstrukce prost°edí probíhá následujícím postupem: 1. 2.

Výpo£et pohybu kamery

- podle postupu uvedeného v sekci 4.1

P°epo£tení snímk· - odstran¥ní zkreslení zp·sobené kamerou a transformace, aby si odpovídali °ádky obou snímk·

3.

Výpo£et hloubky snímku - výpo£et po£ítá hloubku podle vzorce xright = xlef t + disparity , p°i£emº yright = ylef t , s podmínkou minDisparity < disparity < maxDisparity

RectifyImageOps. createCalibrated(). T°ída

P°epo£et snímk· je realizován pomocí objekt· vytvo°ených t°ídou Nejd°íve se vytvo°í objekt t°ídy

RectifyCalibrated

RectifyCalibrated

funkcí

vypo£te opravné transformace pro oba snímky a jednu optimální ka-

libra£ní matici. Vstupy do funkce

• DenseMatrix64F

process, po£ítající tyto údaje, jsou:

- kalibra£ní matice první kamery, vytvo°ená t°ídou

Perspective-

Ops funkcí calibrationMatrix s parametrem: objektem vnit°ních paramer· kamery

• Se3_F64

- pozice první kamery ve sv¥t¥ (new

• DenseMatrix64F • Se3_F64

- kalibra£ní matice druhé kamery, stejné jako první parametr

- pozice druhé kamery ve sv¥t¥ (pohyb kamery, získaný z první £ásti)

Spo£ítané transformace p°edává funkce dává funkce

Se3_F64() )

getRect1

a

getRect2.

Kalibra£ní matici p°e-

getCalibrationMatrix. Transformace snímk· se upraví, aby byly vid¥t pouze allInsideLeft t°ídy RectifyI-

pixely, které si odpovídají stejnými °ádky, pomocí funkce

mageOps, která má parametry: • IntrinsicParameters • DenseMatrix64F

- vnit°ní parametry kamery

- opravná transformace pro první snímek, výstup je uloºen do

stejné matice

• DenseMatrix64F

- opravná transformace pro druhý snímek, výstup je uloºen do

stejné matice

• DenseMatrix64F

- opravná kalibra£ní matice, výstup je uloºen do stejné matice

ImageImageDistort vy-

Upravené transformace se aplikují pro kaºdý snímek zvlá²´, pomocí objektu t°ídy

Distort

apply(p·vodní_snímek,upravený_snímek). Objekt ImageDistort t°ídy RectifyImageOps s parametry:

funkce

tvá°í funkce

46/55

4.3



• IntrinsicParameters • DenseMatrix64F • imageType

- vnit°ní parametry kamery

- opravná transformace pro první snímek

- t°ída p°epo£ítávaného snímku

Po p°epo£ítání by´ jen minimáln¥ rotovaných snímk· pomocí BoofCV, nastává problém, jelikoº je oblast s odpovídajícími °ádky velmi malá nebo ºádná a hloubka je po£ítána jen na této oblasti. Problém také vzniká p°i del²ím posunu, jelikoº jsou pak výsledky rekonstrukce ²patné (porovnávané regiony ve snímcích nejsou dostate£n¥ podobné a vypo£tený pohyb neodpovídá reálnému pohybu za°ízení). Nejlep²í výsledky jsou p°i pohybu po horizontáln¥ leºící kruºnici se st°edem v rekonstruované scén¥. Pro zlep²ení rekonstrukce p°i zm¥n¥ sv¥telných podmínek se ve snímcích zvýrazní hrany p°edm¥t· pomocí t°ídy funkce

process(p·vodní_snímek,upravený_snímek).

(a) Levý asociovaný snímek

LaplacianEdge

(b) Pravý asociovaný snímek

Obrázek 53: Asociované snímky

(a) Upravený snímek

(b) Hloubka rekonstruovaného prost°edí

Obrázek 54: Rekonstrukce prost°edí

47/55

4.3



process(upravený_první_snímek, upravený_druhý_snímek) na objektu StereoDisparity, který vytvá°í t°ída FactoryStereoDisparity funkce regionSubpixelWta s parametry: Vlastní hloubka v·£i prvnímu snímku se vypo£te voláním

• DisparityAlgorithms

- vybírá algoritmus z vý£tu algoritm· DisparityAlgorithms

RECT - oblast rekonstrukce je obdélníkový region RECT_FIVE - dynamicky vybírá nejvhodn¥j²í region z p¥ti lokálních podregion·

• int minDisparity

- omezení minimální hloubky pro zrychlení výpo£tu (cca. 5)

• int maxDisparity

- omezení maximální hloubky pro zrychlení výpo£tu (cca. 40)

• int regionRadiusX

- velikost porovnávaného regionu na ose x (cca. 5-20)

• int regionRadiusY

- velikost porovnávaného regionu na ose y (cca. 5-20)

• double maxPerPixelError

- maximální dovolený error regionu na pixel, vypnuto

v p°ípad¥, ºe je hodnota men²í jak nula (cca. 10-100)

• int validateRtoL • double texture

- tolerance asociovaných hodnot (cca. 1-10)

- tolerance podobnosti regionu vzhledem k ostatním region·m, vy-

pnuto v p°ípad¥, ºe je hodnota men²í jak nula (cca. 0.1)

• imageType

- t°ída snímku

P°i krat²ím posunu a men²í rotaci jsou výsledky rekonstrukce znateln¥ lep²í viz obrázek 55b. Pro rekonstrukci snímk· blízko u sebe vznikla t°ída potomkem t°ídy

DisparityMap

Rekonstrukce3D

se spustí volbou

(a) Upravený snímek

DisparityMap,

která je

a vyhodnocuje snímky pouze v jednom vlákn¥. T°ída

Zobrazit->Rekonstruované prost°edí 2.

(b) Hloubka rekonstruovaného prost°edí

Obrázek 55: Rekonstrukce prost°edí

48/55


5

Experimenty Hlavním cílem experiment· bylo zji²t¥ní rychlosti uvedených algoritm· pod OS Android.

Dal²ím cílem bylo zji²t¥ní výpo£etní náro£nosti vlastních algoritm· a odd¥lení t¥chto výpo£t· od reºie OS, hlavn¥ od p°evodu a zobrazování snímk·. V²echny vý²e uvedené algoritmy byly otestovány na dvou telefonech s r·znými parametry, aby byl test více nezávislý na konkrétním za°ízení.

5.1

Porovnání rychlosti

Testováno bylo na dostupných za°ízeních Samsung Galaxy S2 a Samsung Note2. Pr·m¥rný po£et fps detektor·, pokud není uvedeno jinak, je po£ítán z 1000 snímk·, p°i rozli²ení 320*240px.

5.1.1

Detektory hran

Tabulka 2 shrnuje výsledky algoritm· detekce hran z kapitoly 3.3.1. Detektor

Pr·m¥rné fps S2

Pr·m¥rné fps Note2

Three

21.2784

28.4811

Prewitt

22.7842

28.6172

Sobel

22.9615

26.284

Tabulka 2: Porovnání rychlosti detektor· hran

5.1.2

Detektory p°íznak·

Tabulka 3 zobrazuje £asovou náro£nost detekce p°íznak· popsaných v kapitole 3.3.2. Detektor

Pr·m¥rné fps S2


FAST

12.3359

19.6885

Harris

14.0904

20.1381

Shi-Tomasi

11.8539

19.5171

Tabulka 3: Porovnání rychlosti detektor· p°íznak·

49/55

5.1



5.1.3

Detektory region·

Tabulka 4 shrnuje výsledky detekce region· uvedených v kapitole 3.3.3. Detektor

Pr·m¥rné fps S2


Hessian

10.8219

16.1836

SIFT

1.4648

1.5298

Tabulka 4: Porovnání rychlosti detektor· region·

5.1.4

Detekce s popisem p°íznak·

Detekce spole£n¥ s popisem p°íznak· je pr·m¥rována z 500 snímk·, p°i rozli²ení 320*240px. Tabulka 5 shrnuje výsledky detektor· p°íznak· s popisem pomocí SIFT, SURF a BRIEF algoritm· uvedených v kapitole 3.4.1. Detektor + deskriptor

Pr·m¥rné fps S2


SIFT

0.9772

1.4952

Hessian + SURF Fast

7.9276

12.1595

Hessian + SURF Stable

6.1922

10.0323

Shi-Tomasi + BRIEF

5.5085

8.0556

Tabulka 5: Porovnání rychlosti detekce s popisem p°íznak·

Pro porovnání byla pouºita verze BoofCV 0.13. Verze 0.14 by m¥la být o 30% rychlej²í p°i výpo£tu BRIEF popisu.

5.1.5

Sledování p°íznak· pomocí KLT

Sledování p°íznak· je pr·m¥rováno z 500 snímk· p°i mírném pohybu. Sloupec "+

in-

leiers " tabulky 6 znázor¬uje rychlost algoritmu p°i výpo£tu fundamentální matice a tím i správn¥ asociovaných pár·. Detektor + deskriptor

Pr·m¥rné fps S2

+ inleiers


+ inleiers

KLT

6.8984

2.0748

10.4234

3.9142


8.1745

2.8965

11.9106

4.0249

Shi-Tomasi + SURF Stable

6.6103

2.3279

11.4257

3.6007

Tabulka 6: Porovnání rychlosti sledování p°íznak· pomocí KLT

50/55

5.1


5.1.6


Sledování p°íznak· pomocí DDA

Tabulka 7 obsahuje porovnání £asové náro£nosti sledování p°íznak· zaloºené na principu DDA, který je popsaný v kapitole 3.4. Detektor + deskriptor

Pr·m¥rné fps S2

+ inleiers


+ inleiers

Hessian + SURF Fast

6.7730

3.0197

10.2141

4.4067


2.7122

2.2332

7.3111

4.3289

FAST + BRIEF

6.3023

2.2692

10.1709

6.3853

Shi-Tomasi + BRIEF

6.0982

2.3115

8.1682

3.8595

Shi-Tomasi + NCC

9.4846

2.7523

12.7350

4.6371

Tabulka 7: Porovnání rychlosti trekování p°íznak· pomocí DDA

5.1.7

asy obsluºných procedur

Detektory hran jsou výrazn¥ rychlej²í neº detektory p°íznak·, ale p°i porovnání fps detektoru hran

Sobel s detektorem p°íznak· Harris na za°ízení Samsung Note2 se zmen²il

po£et fps pouze o 23%. Následující tabulka znázor¬uje pr·m¥rnou rychlost p°evodu snímku do BoofCV formátu, p°evod do Bitmapy a £as pot°ebný pro vykreslení na displej. Hodnoty uvedené v tabulce 8 jsou pr·m¥rem tisíce m¥°ení p°i rozli²ení 320*240px. Za°ízení

P°evod do ImageUInt8

P°evod do bitmapy

Vykreslení na displej

Samsung Galaxy S2

0.2478 ms

4.7781 ms

0.2760 ms

Samsung Note2

0.0867 ms

3.137 ms

0.175 ms

Tabulka 8: Porovnání rychlosti obsluºných procedur FAST detektoru

Gracké porovnání £ástí výpo£tu FAST detektoru je uvedené na obrázku 56 a vyplývá z n¥j, ºe se obsluºné procedury vykonávají ve zlomkovém £asu vlastního výpo£tu.

5.1.8

Shrnutí rychlostí vyhodnocení

Porovnávané detektory p°íznak· mají podobné rychlosti a p°i rozli²ení 320x240px jsou na za°ízení Samsung Note2 plynulé. Velký rozdíl rychlostí je vid¥t p°i detekci region·. SIFT detektor stihne detekovat cca. 1.5 snímku/s a pro zpracování obrazu v reálném £ase se nehodí. Rychlosti sledování p°íznak· jsou závislé na provád¥ném pohybu. Sledování je rychlej²í v dob¥, kdyº se do algoritmu nep°idávají nové body. V p°ípad¥, ºe se po£ítají správn¥ asociované páry p°íznak· - inliery, tak je nejrychlej²í výpo£et práv¥ p°i p°idání nových bod·, protoºe v tuto chvíli nejsou asociované ºádné páry a výpo£et inlier· se p°esko£í. 51/55

5.2



Obrázek 56: Porovnání doby zpracování jednotlivých £ástí FAST detektoru

5.2


D·leºitou vlastností p°i sledování pohybu p°íznak· je jejich robustnost. Nap°íklad u FAST detektoru se nem¥ní pozice p°íznak· p°i rotaci a malé zm¥n¥ pozice kamery. ShiTomasi detektor byl v porovnání s FAST detektorem mén¥ robustní p°i rotacích kamery a robustn¥j²í p°i pohybu kamery. Harris·v detektor je sice nejrychlej²í, ale v¥t²ina p°íznak· m¥ní svoji pozici i p°i nepatrné zm¥n¥ pozice kamery. Popis p°íznak· a následná asociace pomocí SURF a BRIEF byla p°ibliºn¥ stejn¥ robustní a stejn¥ rychlá, zato popis p°íznak· pomocí NCC byl rychlej²í, ale vykazoval mnohem hor²í výsledky p°i asociaci. Opticky nejlep²í výsledky p°i sledování bod· vykazovala gradientní metoda KLT. Její rychlost vyhodnocení byla nejvy²²í a p°itom asociovala nejmén¥ ²patných pár·. Z porovnání rychlostí vyplývá, ºe se u KLT po£ítá dlouhou dobu pohyb kamery. Pro výpo£et pohybu je lep²í asociovat p°íznaky popsané pomocí SURF nebo BRIEF algoritmu a detekované pomocí Shi-Tomasi nebo FAST detektoru.

52/55


6

Záv¥r Cílem této práce bylo seznámit se s metodami rekonstrukce prost°edí z pohybu mono-

kulární kamery na opera£ním systému Android. Pro tento ú£el jsem v první £ásti popsal poºadavky pro tvorbu aplikací na opera£ní systém Android, základní komponenty aplikací, jakým zp·sobem vytvo°it náhled snímané scény, nastavit parametry kamery a navrhnout strukturu aplikace pro zpracování obrazu v reálném £ase. Dále seznamuji se základními API pro ovládání kamery a vykreslování graky. Je uveden optimální zp·sob vykreslování, který minimalizuje zát¥º procesoru a je nutný pro zpracování snímk· v reálném £ase. V druhé £ásti se v¥nuji knihovn¥ BoofCV. Popisuji °e²ení, jak získat funk£ní verzi pro systém Android. Uvádím, jak odstranit nedokonalosti snímk· pomocí vnit°ních parametr· kamery a seznamuji se základními detektory a jejich vlastnostmi. Popisuji strukturu knihovny BoofCV, jak vytvo°it popis p°íznak· a jeho vlastnosti. V záv¥ru této £ásti je uveden zp·sob jak sledovat p°íznaky mezi více snímky a následn¥ po£ítat pohyb kamery. T°etí £ást se v¥nuje samotné implementaci rekonstrukce 3D modelu p°íznak·. V úvodu t°etí £ásti je popis, jak pomocí p°edchozích údaj· vytvo°it robustní odhad pohybu kamery. Poukazuji na úskalí, které p°i odhadu pohybu vznikají a °e²ím je. Navrhuji postup rekonstrukce p°íznak· pomocí triangulace a vlastní implementaci pomocí knihovny BoofCV. V záv¥ru této £ásti popisuji jak z n¥kolika snímk· vypo£ítat hloubku obrazu. V experimentální £ásti porovnám rychlost, výpo£etní náro£nost a robustnost jednotlivých algoritm·. Hlavním p°ínosem této práce je popsání a vy°e²ení úskalí spojených s rekonstrukcí p°íznak· v prostoru. Práce slouºí jako úvod do této problematiky a dává podrobný návod, jak se dopracovat k funk£ní aplikaci rekonstruující p°íznaky pomocí monokulární kamery na opera£ním systému Android. Práce by m¥la slouºit jako základ pro navigaci, která se bude orientovat pomocí kamery.

53/55


REFERENCE

Reference http://developer.android.com.

[1] Google. Android.

[2] Edward Rosten, Reid Porter, and Tom Drummond. learning approach to corner detection.

P°ístup 2013.05.21. Faster and better: A machine

IEEE Trans. Pattern Analysis and Machine

Intelligence, 32:105119, 2010.

http://developer.android.com/sdk/index.html.

[3] Google. Adt boundle.

P°ístup

2013.05.21. [4] Oracle.

Jdk 6.

index.html.

http://www.oracle.com/technetwork/java/javase/downloads/

P°ístup 2013.05.21.

[5] The Apache Software Foundation. Apache ant.

http://ant.apache.org/.

P°ístup

2013.05.21. [6] The Eclipse Foundation. Eclipse. [7] Peter Abeles.

www.eclipse.org.

P°ístup 2013.05.21.

Resolving implementation ambiguity and improving surf.

CoRR,

abs/1202.0492, 2012. [8] Peter Abeles. Boofcv.

http://boofcv.org.

[9] Peter Abeles. Ddogleg. [10] Peter

Abeles.

P°ístup 2013.05.21.

http://ddogleg.org. Ejml.

efficient-java-matrix-library.

P°ístup 2013.05.21.

http://code.google.com/p/

P°ístup 2013.05.21.

54/55

P°íloha Obsah p°iloºeného CD V tabulce 9 jsou uvedena jména v²ech ko°enových adresá°· p°iloºeného CD s popisem obsahu.

Jméno adresá°e Popis obsahu bp

bakalá°ská práce ve formátu pdf

sources

zdrojové kódy vytvo°ené aplikace Tabulka 9: Obsah CD

Bakalá ská práce. Michal Polic. Rekonstrukce prost edí z pohybu monokulární kamery. ƒeské VYSOKÉ UƒENÍ TECHNICKÉ V PRAZE. Fakulta elektrotechnická

Recommend Documents