Modulární SW systém pro sledování objekt ve videu v reálném ase. Ond ej Semmler

eské vysoké u£ení technické v Praze Fakulta elektrotechnická Katedra po£íta£·

Bakalá°ská práce

Modulární SW systém pro sledování objekt· ve videu v reálném £ase

Ond°ej Semmler

Vedoucí práce:

Svoboda Tomá² Ing., Ph.D.

Studijní program: Elektrotechnika a informatika, dobíhající, Bakalá°ský

Obor: Výpo£etní technika

27. kv¥tna 2010

iv

v

Pod¥kování Tímto bych rád pod¥koval v²em, kte°í mi pomáhali p°i vzniku této bakalá°ské práce. P°edev²ím chci pod¥kovat vedoucímu mé práce Ing. Tomá²i Svobodovi, Ph.D., za cenné rady a £as strávený p°i konzultacích. Dále d¥kuji za kvalitní spolupráci kolegovi Ji°ímu Va¬kovi, který je autorem £ásti vyvíjeného systému. Zvlá²tní pod¥kování pat°í árce Maixnerové a Ing. Milanu Semmlerovi, kte°í mi byli nápomocní p°i tvorb¥ textu této práce. Nakonec chci pod¥kovat mé matce a bratrovi za jejich trp¥livost a vst°ícnost v pr·b¥hu mé práce.

vi

vii

Prohlá²ení Prohla²uji, ºe jsem práci vypracoval samostatn¥ a pouºil jsem pouze podklady uvedené v p°iloºeném seznamu. Nemám závaºný d·vod proti uºití tohoto ²kolního díla ve smyslu 60 Zákona £. 121/2000 Sb., o právu autorském, o právech souvisejících s právem autorským a o zm¥n¥ n¥kterých zákon· (autorský zákon).

V Praze dne 27. 5. 2010

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

viii

Abstract The goal of my bachelor work is analysis, development and implementation of the system for testing the quality and properties of algorithms used for tracking objects in real time. The project consists of the analysis and implementation of a modular software system for tracking objects in real time. Objects are selected by the GUI tools or are loaded from a le. Monitoring is carried out from the input video or online image via a connected camera. Applications output is then a text le with results of monitoring or real time visualization. The whole system is divided into several modules mutually communicating via a standard protocol. This divide allows for easy replacement of modules and for distribution between more computers. The entire system is checked by the control module, which is viable in GUI mode and from the command line.

Abstrakt Cílem mé bakalá°ské práce je analýza, vývoj a implementace systému pro následné testování kvality a vlastností algoritm· pouºívaných pro sledování objekt· v reálném £ase. Práce se skládá z návrhu a implementace modulárního softwarového systému pro sledování objekt· v reálném £ase. Objekty jsou vybírány pomocí GUI nástroj· nebo jsou na£ítány ze souboru. Sledování probíhá ze vstupní videosekvence nebo v on-line obraze p°ipojené kamery. Výstupem aplikace je textový soubor s výsledky sledování nebo vizualizace v reálném £ase. Celý systém je rozd¥len do n¥kolika modul· vzájemn¥ komunikujících pomocí standardního protokolu TCP/IP. Rozd¥lení umoº¬uje snadnou vým¥nu modul· a moºnost distribuce jednotlivých £ástí aplikace mezi n¥kolik po£íta£·. Celý systém je kontrolovaný pomocí °ídicího modulu, který je spustitelný v reºimu GUI i z p°íkazové °ádky.

ix

x

Obsah 1 Úvod

1

2 Popis problému, specikace cíle

3

2.1

Popis problému . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3

2.2

Vymezení cíl· . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3

2.3

Existující systémy pro sledování objekt· . . . . . . . . . . . . . . . . . . . . .

4

3 Analýza a návrh °e²ení 3.1

3.2

5

Návrh modul· . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5

3.1.1

Datový modul . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6

3.1.2

Jádro

6

3.1.3

Výstupní modul

3.1.4

ídicí modul

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

6

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

6

Pouºité technologie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7

4 Realizace 4.1

4.2

9

Standardy psaní kódu

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

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

9

4.1.1

T°ída

4.1.2

Metoda a funkce

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

10

4.1.3

Prom¥nná . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

10

4.1.4

Zachování Demeterova zákona . . . . . . . . . . . . . . . . . . . . . . .

Komunika£ní protokol

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

9

10 10

4.2.1

Identikace modulu - INIT

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

11

4.2.2

Poºadavek - REQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

11

4.2.3

Odpov¥¤ - RES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

13

4.3

Statické knihovny . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

15

4.4

Implementace modul·

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

15

4.4.1

Datový modul - datamodule . . . . . . . . . . . . . . . . . . . . . . . .

16

4.4.2

ídicí modul - tracker

18

4.4.3

Výstupní modul - outputmodule

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

5 Testování

21

23

5.1

Synchronizace modul·

5.2

Výkon aplikace

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

23

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

23

5.2.1

Avi soubory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

24

5.2.2

USB kamera . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

29

xi

xii

OBSAH

5.3

Výsledky testování výkonu . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6 Záv¥r

31

33

6.1

Zhodnocení spln¥ní cíl·

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

33

6.2

Pokra£ování práce

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

34

Literatura

35

A Seznam pouºitých zkratek

37

B Instala£ní a uºivatelská p°íru£ka B.1

39

Systémové nároky a vyºadované knihovny B.1.1

Systémové nároky

B.1.2

Knihovny

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

39

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

39

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

40

B.2

Instalace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

40

B.3

Práce s programem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

41

B.3.1

P°íkazová °ádka . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

41

B.3.2

Gracké uºivatelské rozhraní

41

B.3.3

Distribuce mezi n¥kolik po£íta£·

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

43

B.3.4

Spu²t¥ní video souboru - krok za krokem . . . . . . . . . . . . . . . . .

43

B.3.5

Spu²t¥ní kamery - krok za krokem

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

45

B.3.6

Demonstra£ní video práce s kamerou . . . . . . . . . . . . . . . . . . .

45

C Obsah p°iloºeného CD

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

49

Seznam obrázk· 3.1

P°ehled modul· a datových cest . . . . . . . . . . . . . . . . . . . . . . . . . .

5

3.2

Okno GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7

4.1

Základní typy zpráv v protokolu. Zkratky: [ts] - timestamp, [name] - jméno

4.2

Formát YUV 4:2:2

5.1

Graf závislosti datového toku na FPS vykreslování p°i testu soubor·

. . . . .

28

5.2

Graf závislosti datového toku na CPU modul· p°i testu soubor· . . . . . . . .

29

5.3

Graf závislosti datového toku na CPU datového modulu p°i testu USB kamery

31

B.1

Okno GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

42

B.2

Postup p°i spou²t¥ní videa pomocí GUI

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

44

B.3

Dialog výb¥ru sledovaného objektu . . . . . . . . . . . . . . . . . . . . . . . .

45

B.4

Okno výstupní modulu v pr·b¥hu sledování

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

46

B.5

Postup p°i spou²t¥ní kamery pomocí GUI

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

47

C.1

Seznam p°iloºeného CD, 1. £ást . . . . . . . . . . . . . . . . . . . . . . . . . .

49

C.2

Seznam p°iloºeného CD, 2. £ást . . . . . . . . . . . . . . . . . . . . . . . . . .

49

modulu, [cmd] - p°íkaz, [params] - parametry, [accepted] - výsledek p°íkazu

.

11

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

17

xiii

xiv

SEZNAM OBRÁZK

Seznam tabulek 4.1

Identika£ní °et¥zce modul· . . . . . . . . . . . . . . . . . . . . . . . . . . . .

11

4.2

P°íkazy datového modulu

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

12

4.3

P°íkazy jádra

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

12

4.4

P°íkazy výstupního modulu

4.5

P°íkazy °ídicího modulu

4.6

Odpov¥di datového modulu

4.7

Odpov¥di jádra . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

14

4.8

Odpov¥di výstupního modulu . . . . . . . . . . . . . . . . . . . . . . . . . . .

14

4.9

Odpov¥di °ídicího modulu . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

15

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

13

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

13

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

4.10 Parametry °ídicího modulu - tracker

14

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

19

4.11 Výchozí hodnoty prom¥nných inicializa£ního souboru . . . . . . . . . . . . . .

20

5.1

Parametry testovacího stolního po£íta£e

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

23

5.2

Funk£ní a nefunk£ní kodeky . . . . . . . . . . . . . . . . . . . . . . . . . . . .

24

5.3

Testování souboru £. 1 - parametry souboru a výsledky testování

. . . . . . .

25

5.4


. . . . . . .

25

5.5


. . . . . . .

26

5.6


. . . . . . .

26

5.7


. . . . . . .

27

5.8


. . . . . . .

5.9

Testování kamery p°i rozli²ení 160x120 pixel· - testování ve£er a v poledne.

.

29

5.10 Testování kamery p°i rozli²ení 320x240 pixel· - testování ve£er a v poledne.

.

30


.

30


31

xv

27

xvi

SEZNAM TABULEK

Kapitola 1

Úvod Tato bakalá°ská práce obsahuje n¥kolik etap vývoje softwarového systému pro sledování objekt· v reálném £ase. Systémy podobného typu, jiº existují [1], ale jejich vyuºití pro speciální pot°eby je komplikované. V¥decká pracovi²t¥ po celém sv¥t¥ proto vyvíjejí systémy vlastní, které odpovídají jejich speciálním poºadavk·m. P°ínosem této práce je poskytnutí relativn¥ jednoduchého nástroje, který bude dopl¬ovat existující komplikované systémy, bude spl¬ovat nároky zadavatele a bude jednodu²e p°izp·sobitelný speciálním poºadavk·m. Celý systém se skládá ze £ty° £ástí, z nichº kaºdá vykonává specickou £ást úlohy. První £ást systému získává data obrazu ze za°ízení nebo souboru. Dal²í £ást data zpracovává a provádí samotné sledování objekt·. T°etí £ást °e²í problematiku zobrazování dat a sledovaných objekt· a poslední £ást °ídí b¥h celého systému a slouºí k interakci s uºivatelem. V²echny £ásti jsou navrºeny tak, aby byly schopny b¥ºet na r·zných po£íta£ích v lokální síti nezávisle na sob¥. ídicí £ást obsahuje gracké uºivatelské rozhraní, pomocí kterého uºivatel získává p°ehled o aktuálním stavu ostatních £ástí systému a je schopen online pomocí °ídicího protokolu nastavit systém pro vlastní pot°eby. Text práce je rozd¥lena do n¥kolika kapitol, z nichº kaºdá se zam¥°uje na jinou etapu vývoje systému. V kapitole 2 Popis problému, specikace cíle je uveden popis °e²eného problému spole£n¥ s vymezením cíl· a poºadavk· na implementovaný systém. Cílem kapitoly je co nejlépe vymezit obsah problému, který práce °e²í. Kapitola 3 Analýza a návrh °e²ení obsahuje detailní analýzu °e²ené problematiky, návrh °e²ení problému, popis prost°edk·, kterých bylo vyuºito pro spln¥ní poºadavk· na systém. Kapitola 4 Realizace popisuje implementaci systému. S d·razem kladeným na nestandardní £ásti °e²ení. V této kapitole je v¥nována zvlá²tní pozornost prvk·m, které by mohly být d·leºité pro budoucí pokra£ování ve vývoji systému. Dal²í £ást práce je Testování, které je obsahem kapitoly 5. Tato kapitola je roz£len¥na na n¥kolik podkapitol, z nichº kaºdá se zam¥°uje na testování jiné funk£ní £ásti systému. Poslední kapitola 6 Záv¥r hodnotí spln¥ní cíl· a vlastního p°ínosu bakalá°ské práce. Obsahuje také souhrn moºností dal²ího pokra£ování ve vývoji systému. Práce také obsahuje Instala£ní a uºivatelskou p°íru£ku (p°íloha B). Instala£ní a uºivatelská p°íru£ka je ur£ena pro uºivatele za£ínající pouºívat systém. Obsahuje také návod

1

2

KAPITOLA 1.

ÚVOD

krok za krokem, který by m¥l pomoci uºivateli rychle spustit systém i bez detailní znalosti programu.

Kapitola 2

Popis problému, specikace cíle 2.1

Popis problému

Sledování objekt· ve videu je proces, p°i kterém se snaºíme ur£it pozici pohybujících se objekt· v jednotlivých snímcích videosekvence. Sledovací algoritmus analyzuje posloupnost snímk· videa a v kaºdém snímku ur£uje pozici sledovaných objekt·. Mezi klasické odv¥tví vyuºívajících algoritm· pro sledování objekt· ve videu pat°í výrobní pr·mysl, doprava, sport, vojenský pr·mysl a mnoho dal²ích. Asi nejobtíºn¥j²ím úkolem algoritm· pro sledování objekt· ve videu v reálném £ase je schopnost reagovat na rychlé zm¥ny sledovaných objekt· v pr·b¥hu n¥kolika málo snímk· videosekvence. V¥decké skupiny po celém sv¥t¥ se stále snaºí vytvá°et nové a zdokonalovat existující algoritmy. Nedílnou sou£ástí tohoto procesu je mimo jiné i testování t¥chto algoritm· pomocí referen£ních videosekvencí nebo p°ímo pomocí kamery po°izující obraz v reálném £ase. Existuje n¥kolik systém·, které umoº¬ují takové testování, ale pro jejich sloºitost se v¥t²ina v¥deckých týmu uchyluje k implementaci systém· vlastních. Výhodou vlastních systém· je p°edev²ím jejich specializace na konkrétní vyvíjené algoritmy, jejich jednoduchá obsluha a rychlé spou²t¥ní. Vývoj £ásti takového systému je náplní této bakalá°ské práce.

2.2

Vymezení cíl·

Cílem práce je implementace modulárního softwarového systému pro sledování objekt· ve videu v reálném £ase. Práce na systému je rozd¥lena na dv¥ £ásti, jeº jsou °e²eny ve dvou r·zných bakalá°ských pracích. První £ást zahrnuje implementaci algoritm· pro sledování objekt· ve videu a je °e²ena v práci [10]. Druhá £ást problematiky, která je obsahem této bakalá°ské práce, se zam¥°uje na zpracování vstupu pro sledovací algoritmy, zobrazení výstupu sledování a zprost°edkovává rozhraní pro uºivatelskou interakci se systémem. Sou£ástí bakalá°ské práce je analýza, návrh, implementace a testování druhé £ásti systému. Vývoj algoritm· pro sledování objekt· se stále posouvá kup°edu. Vznikají nové postupy a techniky a tím se algoritmy neustále m¥ní. V¥decký tým, který se zabývá studií a vývojem algoritm· v této oblasti, proto pot°ebuje testovací systém, který je schopen se t¥mto zm¥nám p°izp·sobovat. Z tohoto d·vodu je jedním z hlavních poºadavk· na systém jeho modularita.

3

4

KAPITOLA 2.

POPIS PROBLÉMU, SPECIFIKACE CÍLE

Rozd¥lení na jednotlivé moduly je rozepsáno v kapitole 3.1 Návrh modul·. Rozhraní systému by m¥lo být navíc navrºeno tak, aby umoºnilo snadnou vým¥nu jednotlivých modul·. To by m¥lo do budoucna zaru£ovat schopnost systému p°izp·sobovat se novým algoritm·m. Dal²ím poºadavkem na práci je moºnost výb¥ru vstupu pro sledování z videosekvence (AVI) nebo z on-line kamery p°ipojené pomocí USB nebo Fireware. Tester m·ºe na p°edem p°ipravených referen£ních videosekvencích srovnávat výsledky r·zných algoritm· za stejných podmínek. Vstup z kamery zase umoº¬uje variabilní testování, které si m·ºe testovací osoba p°izp·sobit p°ímo podle svých pot°eb v daný okamºik. Tento typ vstupu také slouºí pro demonstrace sledovacích algoritm· v reálném £ase. Systém musí být kontrolovatelný jak pomocí grackého uºivatelského rozhraní, tak i z p°íkazové °ádky. Práce z p°íkazové °ádky umoº¬uje rychlé spu²t¥ní aplikace a integraci s jinými aplikacemi. Gracké uºivatelské rozhraní se vyzna£uje se svojí p°ehledností a intuitivním ovládáním. V¥t²inu program· s grackým uºivatelským rozhraním m·ºe zku²en¥j²í uºivatel pouºít bez p°edchozích znalostí práce s tímto programem. V grackém reºimu je jedním ze st¥ºejních úkol· aplikace interaktivní tvorba sledovaných objekt·. Výstup programu je rozd¥len na dva typy: on-line a o-line. Reºim on-line vizualizuje výstup sledovacího algoritmu. Vizualizace dat je procesorov¥ pom¥rn¥ náro£ný problém. Proto by tento typ výstupu m¥l být optimalizovaný tak, aby co nejmén¥ brzdil £innost sledovacího algoritmu. Výstup o-line je realizován ukládáním informací o pr·b¥hu sledování ve form¥ textových ASCII soubor·. Tento typ výstupu aplikace je p°edev²ím ur£en pro pe£livou analýzu chování algoritmu.

2.3

Existující systémy pro sledování objekt·

Mezi nepropracovan¥j²í knihovny pro práci s digitálním obrazem pat°í knihovna OpenCV [1]. OpenCV je multiplatformní otev°ená knihovna, která se zam¥°uje p°edev²ím na zpracovávání videa v reálném £ase. Tato knihovna vznikla za podpory spole£nosti Intel v roce 1999. OpenCV se m·ºe uplatnit v mnoha odv¥tvích jako jsou rozpoznávání gest a obli£ej·, detekce a identikace objekt·, segmentace obrazu a dal²ích. Je to obsáhlá knihovna, kterou je relativn¥ komplikované p°izp·sobit si konkrétním speciálním pot°ebám. Pro vývoj nových sledovacích algoritm· je ale zapot°ebí sostikovaných systém· pro jejich testování, jak jiº bylo °e£eno v kapitole 2.1 Popis problému.

Kapitola 3

Analýza a návrh °e²ení Tato kapitola obsahuje základní rozbor problému, rozd¥leného do n¥kolika sekcí. V první sekci je °e²en poºadavek na jednoduchou vým¥nu jednotlivých £ástí aplikace. Druhá sekce kapitoly se poté zam¥°uje na ostatní poºadavky spojené s výb¥rem opera£ního systému, programovacího jazyka a dal²ích otázek týkajících se technologických prost°edk· pouºitých pro vývoj aplikace.

3.1

Návrh modul·

Obrázek 3.1: P°ehled modul· a datových cest

Systém je v vzhledem k poºadavku na jednoduchou vým¥nu jednotlivých £ástí rozd¥len do £ty° modul·: datový, výpo£etní jádro, výstupní a °ídicí (viz. obrázek 3.1). Kaºdý

5

6

KAPITOLA 3.

ANALÝZA A NÁVRH EENÍ

ze zmín¥ných modul· je samostatným procesem a vykonává v systému specickou úlohu. Moduly mezi sebou vzájemn¥ komunikují pomocí °ídicího protokolu. Návrh zárove¬ umoº¬uje spou²t¥ní jednotlivých modul· na r·zných po£íta£ích a komunikaci prost°ednictvím sít¥ LAN. Tato práce se zam¥°uje na v²echny zmín¥né moduly vyjma modulu jádra, který je p°edm¥tem jiné bakalá°ské práce [10].

3.1.1 Datový modul Hlavním úkolem datového modulu je zásobovat jádro systému daty pro výpo£et. Vstupem datového modulu je videosekvence formátu AVI nebo ºivý výstup kamery. Pro tyto ú£ely

1

pouºívá modul knihovny avile a unicap . Výstupem modulu je sekvence dat obsahující jednotlivé snímky ve formátu 24bitový RGB nebo 8bitový ²edotónový. Výb¥r vstupu, formát vstupu i formát výstupu modulu je zaji²óván °ídicím modulem prost°ednictvím °ídicího protokolu. Po výb¥ru vstupu je datový modul p°ipraven postupn¥ vy£ítat jednotlivé snímky ze vstupu, vy£tená data p°evád¥t na jeden ze dvou zmín¥ných výstupních formát· modulu a posílat data na dal²í zpracování.

3.1.2 Jádro Modul jádra, který není sou£ástí implementace této bakalá°ské práce, má za úkol zpracovávat proud dat z datového modulu a aplikovat na n¥ algoritmy pro sledování konkrétních objekt·. Objekty pro sledování dodává jádru °ídicí modul. Výstupem jádra je obrazový proud videosekvence spojený s informacemi o polohách hledaných objekt·.

3.1.3 Výstupní modul Výstupní modul slouºí k vizuálnímu zobrazení výstupu modulu jádra. Pomocí funkcí OpenGL zobrazuje jednotlivé snímky videosekvence s gracky znázorn¥nými polohami sledovaných objekt· a pomocnými doprovodnými informacemi. Zobrazování je pomocí standardních optimaliza£ních technik zjednodu²eno tak, aby co nejmén¥ zat¥ºovalo CPU. O optimaliza£ních technikách se tato práce zmi¬uje v kapitole 3.2 Pouºité technologie. Výstupní model je také vybaven moºností vyºádat si vytvo°ení nového objektu pro sledování nebo znovunalezení konkrétního hledaného objektu v b¥ºícím videu.

3.1.4 ídicí modul ídicí modul zaji²úje, kontroluje a °ídí chod a synchronizaci v²ech modul· tvo°ících aplikaci. Z kongura£ního souboru modul na£te informace pot°ebné pro spu²t¥ní jednotlivých modul· a pro navázání spojení s moduly b¥ºících samostatn¥ na lokálním po£íta£i nebo vzdálen¥ na LAN. Modul pracuje v reºimu grackého uºivatelského rozhraní (GUI) nebo p°íkazového °ádku (CLI). V reºimu GUI se uºivateli zobrazí okno na obrázku 3.2, roz£len¥né na n¥kolik £ástí, z nichº kaºdá p°edstavuje jeden konkrétní modul systému. V t¥chto £ástech okna jsou potom 1

Knihovny unicap [9] a avile [7] nejsou multiplatformní. Pro moºnost p°enosu aplikace na jiné opera£ní

systémy musí být nahrazeny knihovnami multiplatformními.

3.2.

7

POUITÉ TECHNOLOGIE

Obrázek 3.2: Okno GUI

zobrazeny informace o stavu jednotlivých modul·. V £ásti pro datový modul má uºivatel moºnost výb¥ru zdroje vstupních dat a vstupních a výstupních formát·. V £ásti pro modul výpo£etního jádra uºivatel vybírá objekty pro sledování, dále má moºnost vytvá°et nové objekty, ukládat vytvo°ené objekty, p°idávat uloºené a odstra¬ovat sledované. U výstupního modulu m·ºe uºivatel nastavit typ výstupu. Nastavení modul· lze na£ítat nebo ukládat z/do kongura£ního souboru. Reºim p°íkazového °ádku °ídicího modulu umoº¬uje rychlé spou²t¥ní systému. V tomto reºimu má uºivatel moºnost pomocí p°epína£· p°ímo nastavit jednotlivé moduly, na£íst konguraci d°íve uloºenou pomocí GUI do kongura£ního souboru nebo kombinovat oba zmín¥né zp·soby.

3.2

Pouºité technologie

Výchozím opera£ním systémem pro práci byl zvolen GNU/Linux, jehoº volba opera£ního systému byla pod°ízena poºadavk·m zadavatele s ohledem na dal²í p°enositelnost vytvo°eného kódu na jiné opera£ní systémy. V¥t²ina práce je implementována pomocí multiplatformních knihoven, a proto je p°echod na odli²ný opera£ní systém do budoucna otev°en. Jednotlivé moduly jsou implementovány v programovacím jazyce C++ s vyuºitím populární multiplat-

8

KAPITOLA 3.

ANALÝZA A NÁVRH EENÍ

formní knihovny Qt [2]. Jazyk C++ byl zvolen pro jeho univerzálnost a rychlost, která je p°i zpracovávání objemných dat nespornou výhodou. Kód napsaný v tomto jazyce je také zárove¬ p°enositelný na dal²í platformy a tím spl¬uje podmínku pro budoucí moºnost p°enosu aplikace na dal²í opera£ní systémy. Knihovna Qt je framework, který disponuje ²irokou ²kálou funkcí a objekt· pro zjednodu²ení a zefektivn¥ní implementace v jazyce C++. Mimo jiné obsahuje moduly pro práci s grackým uºivatelským rozhraním, sítí a OpenGL, které jsou v této práci vyuºity. Za zmínku stojí také dokumentace knihovny Qt, která je na velmi vysoké úrovni. V Qt se vyskytují n¥které speciální konstrukce. Mezi n¥ pat°í signály a sloty, pouºívané v Qt pro komunikaci mezi objekty. Sloty jsou denovány jako standardní £lenské funkce objektu. Signály jsou denovány preprocesorem Qt [3]. P°enos informací mezi jednotlivými moduly zaji²úje °ídicí protokol. Ten je textov¥ orientován a realizován na bázi rodiny protokol· TCP/IP [4]. P°enos dat pomocí TCP/IP p°iná²í °adu výhod. Je to pln¥ duplexní, transparentní a spolehlivé spojení, které vytvá°í virtuální okruh mezi koncovými aplikacemi, a tedy zaru£uje dodání v²ech dat adresátovi, a to ve správném po°adí. Knihovna Qt obsahuje modul QtNetwork ur£ený p°ímo pro implementaci síóvých aplikací. Jednotlivé moduly jsou implementovány jako vícevláknové aplikace. Vícevláknovou aplikací rozumíme samostatný proces, který je rozd¥len do n¥kolika men²ích podproces· b¥ºících paraleln¥. Na rozdíl od samostatných proces· m·ºou vlákna jednoho procesu sdílet informace ve spole£né pam¥ti. Jednotlivá vlákna se v b¥hu st°ídají. O p°epínaní kontextu se stará jádro opera£ního systému. V této bakalá°ské práci je vyuºívána t°ída QThread, která je sou£ástí frameworku Qt a která poskytuje rozhraní pro jednoduchou a kvalitní práci s vlákny. P°i implementaci se v n¥kterých modulech vyskytují sloºité výpo£ty v cyklech, které nadm¥rn¥ zat¥ºují CPU. To je neºádoucí p°edev²ím p°i b¥hu n¥kolika modul· na jednom PC. Modul jádra vyºaduje maximální moºnou kapacitu výkonu procesoru pro kvalitní b¥h sloºitých algoritm· slouºících pro vyhledávání objekt·. Proto je vhodné pouºít optimaliza£ní techniky jazyka C [5]. Pouºitím t¥chto technik docílíme kvalitn¥j²ího p°ekladu do strojového kódu a tím vy²²í efektivitu a sníºení nárok· systému na CPU. Pro vývoj aplikace bylo zvoleno vývojové prost°edí QtCreator [6], které je produktem vývojá°· knihovny Qt. Jedná se o sostikované IDE pro vývoj v jazyce C++ a podporou frameworku Qt. QtCreator obsahuje kvalitní editor zdrojového kódu, rozhraní pro debugger, dob°e zpracovanou navigaci v projektu a mnoho dal²ích utilit pro pohodlné psaní C++/Qt aplikací. Dal²í jeho nespornou výhodou je multiplatformnost, jak je u Qt aplikací zvykem. U kaºdého v¥t²ího projektu, na jehoº vývoji se podílí více programátor·, se neobejdeme bez nástroje pro správu verzí. Celý tento projekt, zabývající se sledováním objekt· ve videu v reálném £ase, je výsledkem dvou bakalá°ských prací. Proto projekt vyuºívá systém Subversion (zkrácen¥ SVN). Je to nástroj pat°ící do kategorie version control software a lze jej provozovat na v²ech platformách.

Kapitola 4

Realizace Následující kapitola popisuje implementaci projektu. Tento popis je pro p°ehlednost rozd¥len do n¥kolika £ástí, podle logického umíst¥ní v aplikaci. V první £ásti 4.1 Standardy psaní kódu je seznam pravidel formátování textu, pojmenovávání prom¥nných, t°íd a funkcí. Tato pravidla by m¥la být jednotná pro celou aplikaci, zp°ehled¬ovat napsaný kód a napomáhat p°i studiu implementace aplikace. Pro následné pokra£ování ve vývoji bude výhodné tato pravidla dodrºovat. Je zde také zmínka o Demeterov¥ zákon¥, jehoº dodrºování by m¥lo být závazné p°i psaní v²ech aplikací. Následující £ást 4.2 Komunika£ní protokol popisuje detailn¥ protokol, pouºitý pro komunikaci mezi jednotlivými moduly. Rozbor protokolu je zde rozveden do podrobností, aby v budoucnu usnadnil vývojá°·m p°ípadnou vým¥nu n¥kterého z modul· a navázání nového modulu do aplikace.

4.1

Standardy psaní kódu

Existuje n¥kolik r·zných standard· pro psaní kódu v C++. Obecn¥ je pravidlem, ºe p°i pojmenovávání prom¥nných, t°íd, metod i funkcí se volí inteligentní jména, která vystihují

1

podstatu denovaného objektu . Seznam pravidel je rozd¥len do n¥kolika oddíl·.

4.1.1 T°ída •

Název t°ídy vºdy za£íná velkým písmenem (nap°. Module, Window).

•

Víceslovný název t°ídy spojíme do jednoho slova, kde je kaºdé slovo psáno s velkým po£áte£ním písmenem. (nap°. DataModule, MyMainWindow).

•

V denici t°ídy zachováváme dané po°adí denovaných prvk·. 1. public, 2. signals, 3. private signals, 4. private, 5. protected.

•

2

T°ída má public pouze metody a funkce . Pro nastavení atribut· t°ídy se pouºívají metody set a get.

1

Zde se objektem myslí prom¥nná, t°ída, metoda nebo funkce.

2

Výjimku tvo°í t°ídy pouºité jako struktury

9

10

KAPITOLA 4.

REALIZACE

4.1.2 Metoda a funkce 3

Mezi metody a funkce °adíme v Qt i signály a sloty .

•

Název funkce a metody vºdy za£íná malým písmenem (nap°. main, print).

•

Víceslovný název funkce a metody spojíme do jednoho slova, kde je kaºdé slovo psáno s velkým po£áte£ním písmenem vyjma prvního, které psáno písmenem malým. (nap°. printStack, getX).

4.1.3 Prom¥nná •

Název prom¥nné je psán s malými písmeny.

•

Víceslovné názvy prom¥nných jsou odd¥leny _.

•

P°i výslovné shod¥ názvu metody nebo funkce s názvem prom¥nné se p°ejmenuje prom¥nná.

4.1.4 Zachování Demeterova zákona Demetr·v zákon [11] se p°edev²ím zabývá kvalitou zdrojového kódu. Zvy²uje vzájemnou ortogonalitu

4 jednotlivých objekt·. Demeter·v zákon je také znám jako Zásada nesm¥lého

kódu. Podle tohoto zákona smí metoda volat pouze:

•

Jiné metody objektu

•

Metody objekt· které vlastní

•

Metody objekt· které vytvo°ila

•

Metody objekt· které jsou parametrem metody

4.2

Komunika£ní protokol

Protokoly mezi sebou komunikují pomocí °ídicího protokolu. Ten byl navrºen tak, aby vyhovoval základním poºadavk·m obsluhy a nastavení jednotlivých modul·. Centrálním uzlem komunikace modul· je °ídicí modul. Ten je spojen se v²emi ostatními moduly, shromaº¤uje a distribuuje informace a nastavení celého systému. Tento zp·sob komunikace by m¥l eliminovat duplicitu r·zných nastavení a synchronizuje moduly podle nastavení zmín¥ného °ídicího modulu. ídicí protokol je textový (ASCII) protokol rodiny TCP/IP. V protokolu se vyskytují t°i typy zpráv: inicializace (INIT), poºadavek (REQ) a odpov¥¤ (RES). Struktura jednotlivých typ· je patrná z obrázku 4.1. Odd¥lova£em mezi jednotlivými poloºky zpráv je znak #. Ukon£ovacím znakem kaºdé zprávy je znak nové °ádky. 3

O signálech a slotech pojednává kapitola 3.2 Pouºité technologie v odstavci popisující framework Qt.

4

Ortogonalitou m·ºeme denovat jako vzájemnou nezávislost £ástí kódu.

4.2.

11

KOMUNIKANÍ PROTOKOL

Obrázek 4.1: Základní typy zpráv v protokolu. Zkratky: [ts] - timestamp, [name] - jméno modulu, [cmd] - p°íkaz, [params] - parametry, [accepted] - výsledek p°íkazu

Název modulu Identika£ní °et¥zec Datový modul

DATA_MODULE

Výpo£etní modul

CORE_MODULE

Výstupní modul

OUTPUT_MODULE

Tabulka 4.1: Identika£ní °et¥zce modul·

První £ást zprávy obsahuje °et¥zec odpovídající typu zprávy (INIT, REQ nebo RES). Druhá poloºka [ts] vºdy obsahuje £íslo, které udává £asovou zna£ku odeslání dané zprávy. Dal²í £ásti se li²í v závislosti na typu konkrétní zprávy. Následuje popis jednotlivých typ· zpráv.

4.2.1 Identikace modulu - INIT •

name = identika£ní °et¥zec modulu

5

Zpráva INIT slouºí v komunika£ním protokolu jako handshake . Kaºdý modul posílá tuto zprávu ihned po navázání spojení s °ídicím modulem. Konkrétní identika£ní °et¥zce popisuje tabulka 4.1.

4.2.2 Poºadavek - REQ

5

•

cmd = p°íkaz

•

params = parametry p°íkazu

Handshake je automatický proces vyjednávání, který dynamicky nastavuje parametry komunika£ního

kanálu mezi dv¥ma entitami p°ed za£átkem klasické komunikace po kanálu.

12

KAPITOLA 4.

REALIZACE

P°íkaz Parametry poºadavku DEVICES_LIST STREAM_PORT DEVICES_FORMATS_LIST SET SET_FILE

[název datového zdroje] [datový zdroj]#[za°ízení] [za°ízení]#[formát]#[výstupní formát] [soubor]#[výstupní formát]

START

-

STOP

-

PAUSE

-

TERMINATE

-

Tabulka 4.2: P°íkazy datového modulu

P°íkaz Parametry poºadavku STREAM_PORT CONNECT_DATA_MODULE START NEW_MODEL

[adresa]#[port] [vý²ka snímku]#[²í°ka snímku]#[výstupní formát] [id modelu]#[vý²ka]#[²í°ka]#[formát]

DETECT_MODEL

[id modelu]

REMOVE_MODEL

[id modelu]

SET_DUMP_FILE

[oine vystup]

SET_OFFLINE_FILE TERMINATE

[oine vstup] -

Tabulka 4.3: P°íkazy jádra

Poºadavek REQ je zpráva obsahující p°íkaz ur£ený pro daný modul a zpráva zahrnuje dotazy na nastavení modul·, p°íkazy slouºící pro konkrétní nastavení a dal²í funk£ní zprávy. Konkrétní implementované p°íkazy spole£n¥ s doprovodnými parametry jsou shrnuty v tabulkách 4.2 (datový modul), 4.3 (jádro), 4.4 (výstupní modul) a 4.5 (°ídicí modul). P°íkaz TREMINATE slouºí u v²ech modul· k zaslání informace o ukon£ování systému. Díky tomuto p°íkazu mají moduly £as pro korektní ukon£ení. Pokud tohoto denovaného £asu nevyuºijí jsou ukon£eny bez ohledu na jejich stavy. P°íkaz DEVICES_LIST datového modulu slouºí k získání za°ízení p°ipojených k danému datovému zdroji. V sou£asné verzi je jediným datovým zdrojem za°ízení Unicap. STREAM_PORT je poºadavek na získání adresy a portu pro p°ipojení modulu jádra na datový tok. DEVICES_FORMATS_LIST získá z konkrétního datového zdroje a jeho za°ízení seznam formát· podporovaných daným za°ízením. SET nastaví datový modul na na£ítání dat z daného za°ízení o konkrétním formátu a ur£í výstupní formát datového toku. SET_FILE slouºí k inicializaci datového modulu pro na£ítání dat ze souboru a zárove¬ ur£í výstupní formát. START spustí datový tok, STOP datový tok zastaví a PAUSE datový tok p°eru²í nebo obnoví. U modulu jádra je STREAM_PORT ºádostí o zaslání adresy a portu datového toku.

4.2.

13

KOMUNIKANÍ PROTOKOL

P°íkaz Parametry poºadavku CONNECT_CORE_MODULE SET_VISUAL TERMINATE

[adresa]#[port] [vý²ka snímku]#[²í°ka snímku]#[výstupní formát] -

Tabulka 4.4: P°íkazy výstupního modulu

P°íkaz Parametry poºadavku NEW_MODEL DETECT_MODEL

[id modelu]

Tabulka 4.5: P°íkazy °ídicího modulu

CONNECT_DATA_MODULE p°ipojí vstup modulu jádra na výstup datového modulu na ur£enou adresu a port. P°íkaz START nastaví jádro do stavu £ekajícího na p°íjem prvního snímku datového toku od datového modulu o dané vý²ce, ²í°ce a formátu. NEW_MODEL informuje jádro o poºadavku °ídicího modulu poslat nový model o ur£ené vý²ce, ²í°ce a formátu. DETECT_MODEL je ºádostí o redetekci modelu s daným id. REMOVE_MODEL odstra¬uje ze sledovaných objekt· model s daným id. SET_DUMP_FILE denuje soubor pro ukládání oine dat sledování a SET_OFFLINE_FILE ur£uje zdroj oine dat sledování. Výstupní modul má pouze dva p°íkazy. CONNECT_CORE_MODULE p°ipojí vstup výstupního modulu na výstup modulu jádra na ur£enou adresu a port a SET_VISUAL nastaví p°ijímací buer modulu na danou vý²ku, ²í°ku a formát snímku. P°íkaz NEW_MODEL °ídicího modulu je ºádostí na vytvo°ení nového modelu z probíhajícího datového toku a DETECT_MODEL je poºadavkem, který je p°eposlán modulu jádra. Ten by m¥l zaru£it redetekci modelu s daným id.

4.2.3 Odpov¥¤ - RES •

cmd = p°íkaz

•

accepted = ACCEPTED / REFUSED

•

params = dodate£né informace odpov¥di

Odpov¥¤ v kontrolním protokolu je p°ímou reakcí na poºadavek (REQ). První d·leºitá informace odpov¥di je obsaºena v poli accepted, které informuje o úsp¥chu (ACCEPTED) nebo neúsp¥chu (REFUSED) p°edchozího poºadavku. V p°ípad¥ neúsp¥chu je pole params prázdné nebo obsahuje °et¥zec znak·, který zd·vod¬uje neúsp¥ch poºadavku. Pokud je p°íkaz úsp¥²ný je pole params op¥t prázdné nebo obsahuje odpov¥¤ a dodate£né informace k poºadavku. Detailní popis jednotlivých odpov¥dí a jejich parametr· v p°ípad¥ úsp¥chu obsahují tabulky 4.6 (datový modul), 4.7 (jádro), 4.8 (výstupní modul) a 4.9 (°ídicí modul). Odpov¥¤ DEVICES_LIST datového modulu obsahuje seznam p°ipojených za°ízení, odd¥lených znakem #, kterás jsou p°ipraveny k pouºití. STREAM_PORT obsahuje adresu

14

KAPITOLA 4.

REALIZACE

P°íkaz Parametry odpov¥di DEVICES_LIST STREAM_PORT DEVICES_FORMATS_LIST

[seznam p°ipojených za°ízení...] [adresa modulu]#[port datového streamu] [seznam formát· za°ízení]

SET

[vý²ka snímku]#[²í°ka snímku]#[výstupní formát]

SET_FILE

[vý²ka snímku]#[²í°ka snímku]#[výstupní formát]

START

-

STOP

-

PAUSE

-

TERMINATE

-

Tabulka 4.6: Odpov¥di datového modulu

P°íkaz Parametry odpov¥di STREAM_PORT

[adresa modulu]#[port datového streamu]

CONNECT_DATA_MODULE

-

START

-

NEW_MODEL

[id modelu]

DETECT_MODEL

-

TERMINATE

-

Tabulka 4.7: Odpov¥di jádra

modulu a £íslo portu, na kterém je p°ipraven datový tok. DEVICES_FORMATS_LIST nese v parametru seznam v²ech formát· podporovaných konkrétním za°ízením, odd¥lených znakem #. SET a SET_FILE informuje o vý²ce, ²í°ce a formátu výstupního datového toku. START je odpov¥dí na spu²t¥ní datového toku, STOP na zastavení datového toku a PAUSE na pozastavení nebo na spu²t¥ní datového toku. Odpov¥¤ STREAM_PORT modulu jádra obsahuje stejné informace jako u stejné odpov¥di datového modulu. CONNECT_DATA_MODULE je reakcí na poºadavek pro p°ipojení k datovému toku datového modulu. START informuje o p°ipravenosti modulu jádra na zahájení datového toku. NEW_MODEL nese id práv¥ na£teného modelu a DETECT_MODEL je odpov¥dí na ºádost redetekce modelu. Výstupní modul reaguje odpov¥dí na p°íkaz CONNECT_CORE_MODULE na poºadavek o p°ipojení na datový tok modulu jádra. SET_VISUAL informuje o správném nastavení

P°íkaz Parametry odpov¥di CONNECT_CORE_MODULE

-

SET_VISUAL

-

TERMINATE

-

Tabulka 4.8: Odpov¥di výstupního modulu

4.3.

15

STATICKÉ KNIHOVNY

P°íkaz Parametry odpov¥di NEW_MODEL

-

DETECT_MODEL

-

Tabulka 4.9: Odpov¥di °ídicího modulu

formátu a rozm¥r· datového toku. ídicí modul odpovídá na p°íkazy NEW_MODEL a DETECT_MODEL. Oba informují o správném provedení poºadovaného p°íkazu.

4.3

Statické knihovny

Sou£ástí implementace této práce jsou t°i staticky linkované knihovny

log, qtcpstream

a

cp.

Pouºití staticky linkované knihovny je výhodné pro £ásti kódu, který vkládáme do více modul·. Získáme tak moºnost jednoduché úpravy kódu pro v²echny aplikace, které danou knihovnu pouºívají. Knihovna

log

slouºí pro sjednocení formátu informa£ních a chybových výstup·. Pomocí

této knihovny m·ºeme p°esm¥rovávat dané výstupy na obrazovku nebo do soubor·. Sou£ástí knihovny je i moºnost automatického p°ipojení £asové zna£ky k jednotlivým výstup·m. Knihovna

qtcpstream

je ur£ena k realizaci datového toku pomocí protokolu TCP/IP

mezi jednotlivými moduly. Obsahuje dva objekty. Jeden pro serverovou stranu datového toku (

QTcpStreamWriter ) a druhý pro klientskou £ást datového toku (QTcpStreamReader ).

Datový tok je uvnit° knihovny realizován pomocí jednoduchého protokolu a umoº¬uje tak p°enos n¥kolika r·zných datových tok· dat na jednom portu. Statická knihovna

cp

je implementací komunikace prost°ednictvím °ídicího protokolu.

Obsahuje parser zpráv, kontrolu správné syntaxe a samotného klienta, který komunikuje s p°ipojeným modulem. Tato knihovna je pouºita ve v¥t²in¥ modul· a zaru£uje jednotnost vyhodnocování jednotlivých zpráv protokolu.

4.4

Implementace modul·

Jak jiº bylo °e£eno, systém se skládá ze £ty° modul·. Kaºdý z nich je samostatná aplikace a s ostatními moduly komunikuje pomocí °ídicího protokolu. ídicí modul spou²tí vºdy uºivatel. Ostatní moduly mohou být spou²t¥ny p°ímo °ídicím modulem na lokálním po£íta£i nebo ru£n¥ na po£íta£i v lokální síti. Typ spu²t¥ní jednotlivých modul· rozpoznává °ídicí modul z kongura£ního souboru tracker.ini, který se nachází ve sloºce spole£n¥ se spou²t¥£em °ídicího modulu. Tento soubor je strukturalizován podle jednotlivých modul·. Kaºdý modul zde má n¥kolik kongura£ních prom¥nných. T°i prom¥nné mají v²echny moduly shodné. První prom¥nnou je remote, která informuje o zp·sobu spu²t¥ní daného modulu. Pokud je remote rovno true je modul spu²t¥n v reºimu daemon. P°i spou²t¥ní v reºimu daemon vyºadují moduly jeden parametr a tím je port na kterém mají o£ekávat spojení. P°i tomto typu spu²t¥ní vyºaduje °ídicí modul

16

KAPITOLA 4.

REALIZACE

nastavení je²t¥ dvou prom¥nných: address a port. Ty denují adresu a port, na kterých m·ºe °ídicí modul navázat spojení s danými moduly. Tímto zp·sobem m·ºeme libovoln¥ kongurovat rozloºení systému mezi po£íta£i na lokální síti. P°íklad struktury kongura£ního souboru:

# konfiguracni soubor "tracker.ini" # takto se zapisuje komentar #konfigurace datoveho modulu [data_module] #spusteni v rezimu daemon - vzdalene na jinem pocitaci remote=true #port daemona port=43210 #adresa daemona address=192.168.1.14 # sekce nastaveni modulu jadra [core_module] remote=false # sekce nastaveni vystupniho modulu [output_module] remote=true port=43211 address=127.0.0.1 #adresa modulu jadra core_address=192.168.1.10

4.4.1 Datový modul - datamodule Datový modul je zdrojem dat pro výpo£ty systému. Modul vy£ítá data ze zvoleného datového zdroje (soubor nebo USB kamera), p°evádí vy£tená data na výstupní formát, posílá zpracovaná data do modulu jádra a komunikuje s °ídicím modulem, který celý proces °ídí. B¥h modulu je rozd¥len do n¥kolika vláken: vlákno pro komunikaci s °ídicím modulem, vlákno pro odesílání dat a vlákno vy£ítající a zpracovávající vstup z datového zdroje. O vy£ítání dat a jejich zpracování se starají takzvané datové zdroje. V tomto systému rozumíme datovým zdrojem libovolné za°ízení nebo soubor, který je schopný poskytovat data pro výpo£ty jádra. Reprezentace takového zdroje je v aplikaci realizována pomocí implementace abstraktní t°ídy

DataSource. Datové zdroje d¥líme na dva základní typy. Zdroje

typu FILE jsou soubory a zdroje typu LIVE kamery. Rozdílem mezi t¥mito dv¥ma zdroji je,

4.4.

17

IMPLEMENTACE MODUL

ºe na rozdíl od zdroje FILE není obecn¥ moºné zdroj typu LIVE pozastavit a poté znovu spustit (není implementován p°íkaz PAUSE). V sou£asné verzi modulu jsou implementovány dva datové zdroje. První zdroj se nazývá

AvileSource. Jak jeho název napovídá, tento zdroj je implementován pomocí knihovny avi6 le . AvileSource je zdrojem typu FILE a jeho úkolem je zpracovávat soubory formátu AVI.

P°evod na výstupní formát rgb °e²í samotná knihovna avile. Výstupní ²edotónový formát je p°epo£ítáván z formátu rgb pomocí rovnice 4.1 [12], kde £ervené barvy v rgb,

G

je sloºka zelené v rgb a

B

Y

je ²edotónová sloºka,

Y = 0.3 ∗ R + 0.59 ∗ G + 0.11 ∗ B Druhým datovým zdrojem je

UnicapSource.

R

sloºka

je sloºka modré v rgb.

(4.1)

Je to zdroj typu LIVE a provádí vy£ítání

ºivého obrazu z USB kamery p°ipojené k po£íta£i. K tomuto ú£elu vyuºívá modul knihovnu unicap. Kamera musí být p°ipojena k po£íta£i je²t¥ p°ed spu²t¥ním datového modulu, jinak nebude systémem na£tena. Tento datový zdroj má implementován p°evod pouze jediného formátu kamery YUV 4:2:2. Formát YUV 4:2:2 se pouºívá ke kompresi videa. Kaºdý pixel zde popisují t°i sloºky: je jasová sloºka a

U

a

V

Y

jsou barevné sloºky[13]. Detailní popis formátu je patrný z ob-

rázku 4.2. Na obrázku jsou £tve°ice byt· slou£eny do

makropixel·,

p°i£emº kaºdý popisuje

dva pixely výsledného obrazu. Datový objem celého obrazu se tedy p°i pouºití zmín¥ného formátu zmen²í o jednu t°etinu. První byte první a druhý pixel, druhý byte popisuje

makropixelu

popisuje sloºku

U

spole£nou pro

sloºku prvního pixelu, t°etí popisuje spole£nou

Y sloºku druhého pixelu (nap°. Y1,U0,V0 z obrázku 4.2). P°i p°evodu na ²edotónový formát se vyuºívá jiº p°ítomné sloºky Y, která je v tomto formátu denovaná

sloºku

V

Y

prvního a druhého pixelu a poslední byte udává

druhému pixelu výsledného obrazu odpovídají sloºky pro kaºdý pixel obrazu.

Rovnice 4.2 4.7 jsou p°íkladem p°evodu prvního

makropixelu

formátu YUV 4:2:2 na

formát rgb. Výsledkem t¥chto rovnic jsou hodnoty ²esti barevných sloºek dvou výsledných pixel·. První z výsledných pixel· je reprezentován t¥mito t°emi sloºkami: R0 pro £ervenou sloºku (rovnice 4.2), G0 pro zelenou sloºku (rovnice 4.3) a B0 pro modrou sloºku (rovnice 4.4). Druhý pixel je denován analogicky sloºkami: R1 (rovnice 4.5), G1 (rovnice 4.6) a B1 (rovnice 4.7). V rovnicích je pouºit symbol

>> 8. Ten zna£í bitový posun výsledného výpo£tu ve dvoj-

kové soustav¥ o osm bit· doprava. Tento obrat je v rovnicích pouºit z d·vod· optimalizace výpo£tu pro procesor, pro který je operace bitového posunu obecn¥ velice rychlá.

Obrázek 4.2: Formát YUV 4:2:2

6

Knihovna avile slouºí pro zpracovávání multimediálních soubor· známých pod zkratkou AVI v x86

Linuxu. Její sou£ástí je i schopnost komprese a dekomprese pomocí nejnov¥j²ích komprima£ních technik.

18

KAPITOLA 4.

REALIZACE

R0 = (298 ∗ (Y 0 − 16) + 409 ∗ (V 0 − 128) + 128) >> 8

(4.2)

G0 = (298 ∗ (Y 0 − 16) − 100 ∗ (U 0 − 128) − 208 ∗ (V 0 − 128) + 128) >> 8

(4.3)

B0 = (298 ∗ (Y 0 − 16) + 516 ∗ (U 0 − 128) + 128) >> 8

(4.4)

R1 = (298 ∗ (Y 1 − 16) + 409 ∗ (V 0 − 128) + 128) >> 8

(4.5)

G1 = (298 ∗ (Y 1 − 16) − 100 ∗ (U 0 − 128) − 208 ∗ (V 0 − 128) + 128) >> 8

(4.6)

B1 = (298 ∗ (Y 1 − 16) + 516 ∗ (U 0 − 128) + 128) >> 8

(4.7)

Po p°evedení obrazu na výstupní formát, odesílají v²echny datové zdroje p°evedená data knihovn¥

qtcpstream, která slouºí pro distribuci dat mezi moduly.

Celý proces spu²t¥ní n¥kterého z datových zdroj· probíhá následovn¥. V tabulce p°íkaz· 4.2 a odpov¥dí 4.6 datového modulu nalezneme i p°íkazy slouºící k nastavení a ke spu²t¥ní jednotlivých zdroj·. Pro spou²t¥ní LIVE zdroje nejprve vybereme konkrétní za°ízení a vstupní formát. Tento výb¥r realizujeme dotazy DEVICES_LIST a DEVICES_FORMATS_LIST. Poté p°íkazem SET nastavíme námi poºadované parametry a p°íkazem START spustíme tok dat. U datových zdroj· typu FILE pouze nastavíme zdrojový soubor a výstupní formát p°íkazem SET_FILE a poté op¥t p°íkazem START spustíme tok dat. U v²ech datových zdroj· je nutné, aby byl konkrétní soubor nebo kamera p°ipojena k po£íta£i, na kterém je tento

7

modul spu²t¥n .

4.4.2 ídicí modul - tracker ídicí modul je zodpov¥dný za chod a synchronizaci celého systému. Jeho primárním úkolem je interakce s uºivatelem a °ízení ostatních modul·. Interakce s uºivatelem je realizována bu¤ prost°ednictvím p°íkazové °ádky, nebo pomocí grackého uºivatelského rozhraní. ízení probíhá pomocí °ídicího protokolu popsaného v kapitole 4.2. Sou£ástí °ídicího modulu je také systém pro výb¥r sledovaných objekt· ve videu. Parametry °ídicího modulu p°i spou²t¥ní z p°íkazové °ádky popisuje tabulka 4.10. O rozpoznání vstupních parametr· se stará t°ída

ArgParser. Paramtr -i na£ítá inicializa£ní soubor.

Struktura inicializa£ního souboru je následující:

# inicializacni soubor # takto se zapisuje komentar #datovy zdroj [data] ### datovy zdroj kamera source_type=device device=UVC Camera (046d:0991) (/dev/video0) 7

P°i spu²t¥ní datového modulu a °ídicího modulu nabízí m·ºe být dialog výb¥ru souboru matoucí, protoºe

nabízí soubory nacházející se na po£íta£i °ídicího modulu.

4.4.

19

IMPLEMENTACE MODUL

Parametr Význam -i (ini_soubor) -v (verbose_level) -x -f (avi_soubor) -m (model1 model2 ...) -d (dump_soubor) -l (load_oine_data)

Na£tení nastavení z inicializa£ního souboru Úrove¬ informa£ního výstupu Spu²t¥ní grackého uºivatelského rozhraní Vstupní avi soubor Sledované objekty Výstupní soubor pro oine data Na£tení oine dat

Tabulka 4.10: Parametry °ídicího modulu - tracker

format=640&480&YUV 4:2:2 (YUYV) ( YUYV ) rgb=true ### datovy zdroj soubor #source_type=file #file=/tmp/video.avi #rgb=false #jadro [core] model=/tmp/model1.bmp, /tmp/model2.bmp offline_file=/tmp/offline.data #vystup [output] dump_file=/tmp/output.data

Sekce

[data] ozna£uje nastavení datového zdroje. Poloºka source_type informuje o poudevice, zdroj ze souboru jako

ºitém datovém zdroji. Datový zdroj kamery zde vystupuje jako

file.

Dále následuje popis konkrétního nastavení a nakonec poloºka rgb, která informuje,

zda je výstupním formátem rgb nebo ²edotón. Prom¥nné

device

a

format

jsou specické interní identikátory kamer zapojené do sys-

tému. Tyto prom¥nné se nastavují pomocí grackého uºivatelského rozhraní. Systém sám detekuje kamery, které jsou k dispozici a nabídne je k výb¥ru. Jejich ru£ní nastavování je p°íli² komplikované. Sekce

[core]

model obsahuje seznam objekt· offline_data denuje zdroj, ze kterého budou £erpána oine data.

uvádí nastavení modulu jádra. Prom¥nná

ur£ených pro sledování a Za denicí modulu

[output] následuje prom¥nná dump_file. Ta ur£uje výstupní soubor,

do kterého se budou ukládat data pro oine analýzu. V²echny prom¥nné inicializa£ního souboru jsou nepovinné a p°i jejich vynechání budou vzaty v potaz výchozí hodnoty t¥chto prom¥nných denované tabulkou 4.11.

20

KAPITOLA 4.

REALIZACE

Prom¥nná Hodnota data - source_type

"le"

data - device

""

data - format

""

data - rgb

"true"

data - le

""

core - model

""

core - oine_data

""

output - dump_le

""

Tabulka 4.11: Výchozí hodnoty prom¥nných inicializa£ního souboru

Parametr -v nastaví úrove¬ textového informa£ního výstupu na danou hodnotu. K dispozici jsou t°i úrovn¥. Úrove¬ nula zaru£uje, ºe výstup bude obsahovat pouze informace o kritických chybách. Úrove¬ jedna nastaví výstup na výpis d·leºitých informací a úrove¬ t°i vypisuje v²echny informa£ní zprávy v²ech modul·. Úrove¬ dva zobrazuje základní informace o b¥hu systému. P°epína£ -x spou²tí gracké uºivatelské rozhraní. Parametr -f spou²tí systém s datovým zdrojem souboru uvedeného za parametrem a nakonec p°epína£ -m denuje mnoºinu objekt·, které chceme systémem sledovat. P°epína£ -d ur£uje výstupní soubor pro uloºení oine dat sledovaných objekt· a p°epína£ -l slouºí pro na£tení oline dat. P°i spu²t¥ní °ídicího modulu bez parametr· modul vypí²e seznam jednotlivých parametr· a jejich stru£ný popis. Reºim grackého uºivatelského rozhraní (obrázek 3.2) je dal²í formou spu²t¥ní °ídicího modulu. Gracké uºivatelské rozhraní je podle modul· rozd¥lené do t°í £ástí. V kaºdé této £ásti je nastavení konkrétního modulu. Dále zde nalezneme informace o stavu jednotlivých modul· jak v gracké, tak v textové podob¥. Celé nastavení °ídicího modulu lze shrnout do n¥kolika stavových prom¥nných, které jsou nastavovány t°emi zp·soby: inicializa£ní soubor, parametry aplikace a gracké uºivatelské rozhraní. To znamená, ºe nastavení na£tené z inicializa£ního souboru m·ºeme modikovat nebo dopl¬ovat pomocí p°epína£· a následn¥ op¥t editovat pomocí grackého uºivatelského rozhraní. O zp·sobu vyhodnocování p°epína£· p°íkazové °ádky dále pojednává p°íloha B.3.1. Sou£ástí r°ídicího modulu je také systém na vytvá°ení objekt· z b¥ºícího datového toku ur£ených ke sledování. Jednotlivé objekty jsou reprezentovány obrázky ve formátu 24bit RGB. Uºivatel má moºnost p°idávat objekty ze soubor· nebo je vytvá°et v grackém uºivatelském rozhraní. Vytvá°ení objekt· je realizováno pomocí dialogu, ve kterém uºivatel

8

pomocí my²i ozna£í objekt, který chce sledovat v práv¥ probíhajícím videu . P°i b¥hu videa z datového zdroje FILE dojde k zastavení datového toku a k jeho obnovení dojde po ukon£ení výb¥ru objektu. 8

Video musí být pro moºnost výb¥ru modelu v b¥ºícím stavu.

4.4.

21

IMPLEMENTACE MODUL

4.4.3 Výstupní modul - outputmodule Tento modul slouºí pro gracký výstup systému. Zobrazuje probíhající video a v n¥m jednotlivé sledované objekty. Dále také zobrazuje základní informace o probíhajícím videu. Hlavním objektem tohoto modulu je

Control. Tento objekt °ídí cely modul a komunikuje

s °ídicím modulem. Za zobrazování je zodpov¥dná t°ída

QGLWidget

OutputModule, která d¥dí od t°ídy QGLWidget. T°ída

slouºí k vykreslování graky pomocí funkcí OpenGL a je sou£ástí modulu QtO-

penGL, který obsahuje sadu nástroj· pro práci s OpenGL v Qt. Samotné vykreslování se provádí pomocí mapovaní na£tených dat na texturu:

if (_f=="RGB") glTexImage2D (GL_TEXTURE_2D, 0, GL_RGB,_w, _h, 0, GL_RGB, GL_UNSIGNED_BYTE, Shared::frameData); else glTexImage2D (GL_TEXTURE_2D, 0, GL_LUMINANCE8,_w, _h, 0, GL_LUMINANCE, GL_UNSIGNED_BYTE,Shared::frameData); glBegin(GL_QUADS); glTexCoord2f(0.0f, glTexCoord2f(1.0f, glTexCoord2f(1.0f, glTexCoord2f(0.0f, glEnd();

0.0f); 0.0f); 1.0f); 1.0f);

glVertex2f( glVertex2f( glVertex2f( glVertex2f(

-1.0, 1.0, 1.0, -1.0,

1.0); 1.0); -1.0); -1.0);

Tento zp·sob vykreslování se standardn¥ pouºívá pro zobrazování streamovaného videa pomocí OpenGL. Nahrání dat do textury navíc poskytuje moºnost roztahování vykreslovaného okna podle pot°eby uºivatele, p°i£emº transformace do daného okna provádí gracká karta a nezat¥ºuje tak CPU.

22

KAPITOLA 4.

REALIZACE

Kapitola 5

Testování 5.1

Synchronizace modul·

P°i testování na n¥kterých po£íta£ích docházelo k synchroniza£ním problém·m p°i startu modul· pomocí °ídicího modulu. Problém nastával pouze u výstupního modulu, který se pokou²el navázat spojení se stále je²t¥ nep°ipraveným °ídicím modulem. Systém poté £ekal na p°ipojení tohoto modulu a z·stával v inicializa£ním stádiu. Stávajícím °e²ením tohoto problému je vypnutí a znovu spu²t¥ní aplikace. Pro korektní ukon£ení modul·, které byly spu²t¥ny °ídicím modulem, vy²le p°i ukon£ování aplikace °ídicí modul p°íkaz °ídicího protokolu

TERMINATE. Ten oznamuje modul·m

informaci o ukon£ení b¥hu systému a nechává jim p°edem stanovený £as na samostatné

1

korektní ukon£ení . e²ením neo£ekávaných problém·m v pr·b¥hu aplikace nebo p°í jejím pádu je ukon£ení b¥ºících proces· systému skriptem

clean_processes,

který je umíst¥n ve sloºce zkompilova-

ného °ídicího modulu.

5.2

Výkon aplikace

Testování výkonu aplikace probíhalo na stroji s parametry uvedenými v tabulce 5.1. Testování se zam¥°ilo na situaci spu²t¥ní v²ech modul· na jednom po£íta£i. Sledovanými veli£inami bylo 1

Korektním ukon£ením je my²leno ukon£ení pomocí denovaných destruktor·, které po procesu dealokují

alokované pam¥óvé prostory.

Kategorie Hodnota Opera£ní systém Procesor Pam¥´ Gracká karta

i686 GNU/Linux (Ubuntu 9.10) Intel(R) Core(TM)2 Duo 2.66 GHz 3,9 GiB ATI Radeon HD 4850

Tabulka 5.1: Parametry testovacího stolního po£íta£e

23

24

KAPITOLA 5.

Funk£ní kodeky

Nefunk£ní kodeky

XVID MPEG-4

H.264 / AVC

TESTOVÁNÍ

DivX MPEG-4 ITU H.264

Tabulka 5.2: Funk£ní a nefunk£ní kodeky

procentuální zatíºení procesoru po£íta£e (%CPU) a rychlost vykreslování obrazu výstupního

2

modulu (FPS ). Samotné testování je rozd¥leno do dvou kategorií. V první kategorii probíhalo testování na souborech avi, p°i kterém lze jednozna£n¥ porovnávat nam¥°ené hodnoty vzhledem k rozdílným parametr·m t¥chto soubor·. Druhou kategorií testování je test na ºivém obrazu z kamery. Jako referen£ní kamera zde byla zvolena USB kamera

Pro for Notebooks.

Logitech, Inc. QuickCam

Druhý zp·sob testování je spí²e orienta£ní, protoºe nelze zaru£it vºdy

stejn¥ kvalitní podmínky pro v²echna testování. P°i testování výkonu nebylo zapnuto sledování objekt·. Samotná implementace algoritmu pro sledování objekt· není p°edm¥tem této bakalá°ské práce. Jejím cílem je poskytnout data pro výpo£ty t¥mto algoritm·m a prost°edky pro zobrazování výsledk· algoritm· pro sledování. Proto bylo testování zam¥°eno na b¥h systému bez t¥chto sledovacích algoritm·.

5.2.1 Avi soubory Soubory pro testování byly vybírány tak, aby dob°e pokrývaly r·zné parametry avi soubor·. Nejd·leºit¥j²ími parametry pro testování jsou rozli²ení videa a hodnota FPS videa. Z t¥chto dvou hodnot m·ºeme po£ítat p°enosovou rychlost dat jednotlivých soubor·, která nám udává, jaký objem informace se p°ená²í za jednotku £asu. P°enosová rychlost je také rozdílná pro výstupní formáty rgb a ²edotón, protoºe formát rgb obsahuje t°ikrát více informací v jednom snímku neº snímek ve formátu ²edotónu stejných rozm¥r·. Cílem na²eho testování je závislost p°enosové rychlosti na výsledné rychlosti FPS nebo na procentuální zát¥ºi procesoru. Druhotnými parametry videa jsou kodeky pouºité pro kompresi a dekompresi. P°i testování soubor· byly pouºity soubory s n¥kolika r·znými druhy kodek·. Tabulka 5.2 popisuje funk£ní a nefunk£ní kodeky na zmín¥ném stolním po£íta£i v pr·b¥hu testování. Seznam kodek·, které knihovna avile podporuje, nebo které jsou ve vývoji, je umíst¥n na webu [8]. Sami auto°i knihovny neru£í za úplnou funk£nost v²ech kodek·, uvedených v tomto seznamu. Celkem bylo testováno ²est soubor· formátu avi. Po°adí testovaných soubor· bylo voleno podle jejich rozli²ení a FPS tak, aby byly ve výsledném po°adí testování se°azeny podle jejich p°enosové rychlosti.

Speed = w ∗ h ∗ bpp ∗ f ps [B/s] 2

(5.1)

FPS je zkratka anglického frames per second. Tato veli£ina vyjad°uje frekvenci zobrazovaných snímku.

Udává po£et snímku zobrazených za jednu sekundu

5.2.

25

VÝKON APLIKACE

Veli£ina RGB Parametr Hodnota Rozli²ení Frekvence snímk· Kodek

208x170 pixel· 13 FPS XVID MPEG-4

P°enosová rychlost

edotón

1,38 MB/s

460 kB/s

13 FPS

13 FPS

CPU Datový modul

2%

2%

CPU Modul jádra

1%

1%

CPU Výstupní modul

1%

1%

CPU celkem

4%

4%

Rychlost vykreslování

Tabulka 5.3: Testování souboru £. 1 - parametry souboru a výsledky testování

Veli£ina RGB Parametr Hodnota Rozli²ení Frekvence snímk· Kodek


P°enosová rychlost Rychlost vykreslování CPU Datový modul

edotón

14,2 MB/s

4,72 MB/s

22 FPS

21 FPS

11%

14%

CPU Modul jádra

8%

3%


7%

3%

26%

20%

CPU celkem


P°enosová rychlost se po£ítá z rovnice 5.1. Symbol w a h zna£í ²í°ku a vý²ku jednoho snímku videosekvence, symbol bpp je roven po£tu byt· na jeden pixel (u formátu rgb je to £íslo 3 a u ²edotónu £íslo 1) a nakonec fps je FPS videa. Takto denovaná p°enosová rychlost ur£uje kolik byt· má být datovou £ástí na£ítáno za jednu sekundu. Stolní po£íta£, na kterém toto testování probíhalo, obsahuje dva procesory. Procentuální vyuºití procesoru (CPU) v tabulkách je vztaºeno na jeden tento procesor. Maximální celkový výkon tohoto stroje je tedy 200% CPU jednoho procesoru. Prvním testovaným avi souborem byl soubor, jehoº parametry a výsledky testování jsou uvedeny v tabulce 5.3 a je ur£en pro p°ehrávání na mobilních telefonech. Tomuto faktu odpovídá i pom¥rn¥ malé rozli²ení a nízká frekvence snímk·. Systém si s tímto souborem poradil bez problém· a rychlost vykreslování odpovídala jeho originální FPS. Vyuºití procesoru bylo v tomto p°ípad¥ relativn¥ nepatrné. P°i výstupním formátu rgb i ²edotón zat¥ºoval systém jeden procesor celkem 4% jeho maximálního výkonu a tedy pouze 2% výkonu celého stroje. Druhým testovaným souborem byl oby£ejný video soubor st°ední kvality, jehoº parametry a výsledky testování uvádí tabulka 5.4. V tomto p°ípad¥ jiº dochází ke zpomalování vykreslování systému. Zpomalování je zp·sobeno zpomalením vy£ítajícího vlákna p°evád¥ním jednotlivých snímk· na poºadovaný formát. Zpomalování je vedlej²í efekt spole£ného vlákna pro tyto dv¥ £innosti. Dochází tím ke zpomalení celého videa, ale nikoliv ke ztrát¥ snímk·. Tento efekt je neºádoucí, i kdyº má vedlej²í pozitivní p°ínosy pro výsledný b¥h systému, o kterých se práce zmi¬uje v dal²ím textu. P°i rozboru vytíºení procesoru je patrné, ºe vytíºení datového modulu p°i reºimu rgb je mén¥ náro£né neº v reºimu ²edotónu. To je zp·sobeno systémem p°evád¥ní vy£ítaných dat ze souboru do výstupního formátu. Data vy£ítaná ze souboru jsou p°íbuzná formátu rgb a jejich p°evád¥ní na formát rgb knihov-

26

KAPITOLA 5.

TESTOVÁNÍ

Parametr Hodnota Rozli²ení Frekvence snímk· Kodek


Veli£ina RGB P°enosová rychlost

edotón

69,12 MB/s

23,04 MB/s

17 FPS

14 FPS

CPU Datový modul

42%

48%

CPU Modul jádra

24%

7%


17%

6%

CPU celkem

83%

61%




1280x720 pixel· 30 FPS ITU H.264


edotón

82,94 MB/s

27,65 MB/s

14 FPS

12 FPS

CPU Datový modul

55%

68%


CPU Modul jádra

23%

6%


16%

5%

CPU celkem

94%

79%


nou avile je tedy rychlej²í neº p°evád¥ní na obraz ²edotónu kombinací zmín¥né knihovny a vlastního kódu. Procesorové zatíºení modulu jádra není p°ímo p°edm¥tem studie tohoto testování. P°esto stojí za zmínku, ºe £ást vytíºení tohoto modulu má na sv¥domí p°eposílání dat a jejich ukládaní pro zpracovávání v tomto modulu. U výstupního modulu je dobré si pov²imnout rozdílu mezi vykreslováním rgb dat a ²edotónu. Jak bylo jiº zmín¥no, tak rgb data jsou t°ikrát objemn¥j²í neº data ²edotónu, proto je vykreslení rgb náro£n¥j²í. Souborem £íslo t°i pro testování byl zvoleno video formátu HD XGA+. Jeho detailní popis a výsledky testování jsou v tabulce 5.5. Výsledky testování jsou v tomto p°ípad¥ podobné výsledk·m testování p°edchozího souboru. Rozdíl mezi vytíºení procesoru výstupním modulem p°i vykreslování rgb a ²edotónu zde dosahuje uº tém¥° p°esn¥ jedné t°etiny, coº by odpovídalo pom¥ru objemu vykreslovaných dat t¥chto výstupních formát·. Dal²í testovaný soubor byl op¥t formátu HD XGA+ (tabulka 5.6). Rozdílem oproti p°edchozímu souboru byla frekvence snímkování a pouºitý kodek. Výsledky jsou op¥t p°edvídatelné. Zde je jiº pom¥rn¥ dosti patrný rozdíl zatíºení datového modulu p°i p°evodu vy£ítaných

5.2.

27

VÝKON APLIKACE




edotón

82,94 MB/s

27,65 MB/s

20 FPS

16 FPS

CPU Datový modul

46%

53%

CPU Modul jádra

18%

9%


14%

6%

CPU celkem

78%

68%




1920x800 pixel· 30 FPS ITU H.264

Veli£ina RGB P°enosová rychlost Rychlost vykreslování

edotón

138,24 MB/s

46,08 MB/s

11 FPS

10 FPS

CPU Datový modul

68%

70%

CPU Modul jádra

31%

9%


20%

7%

119%

89%

CPU celkem


dat do výstupního formátu rgb nebo ²edotónu. U výstupního modulu jsme zaznamenali více neº t°ikrát rychlej²í vykreslování ²edotónových dat. Pátý soubor byl t°etím a posledním pouºitým souborem formátu HD XGA+. Tento soubor m¥l totoºné parametry s p°edchozím testovacím souborem a jediným rozdílem byl pouºitý kodek. Z výsledk· v tabulce 5.7 je patrné, ºe p°i stejném datovém toku dosahoval kodek tohoto souboru (XVID MPEG-4) podstatn¥ lep²ích výsledk· neº kodek souboru p°edchozího (ITU H.264), z £ehoº lze usuzovat, ºe knihovna avile má na testovaném stroji rychlej²í p°evodní algoritmy pro kodek XVID. Posledním testovaným souborem byl soubor s pom¥rn¥ vysokým rozli²ením (tabulka 5.8). Tomuto rozli²ení i pouºitému kodeku odpovídají i výsledky testování na tomto souboru. Celkové zatíºení p°i reºimu rgb zde p°esahuje maximální moºné zatíºení jednoho procesoru. Hodnota frekvence vykreslování se blíºí t°etin¥ skute£né snímkovací frekvence. Celkové výsledky vzhledem frekvence vykreslování vzhledem k datovému toku jsou zaneseny v grafu 5.1. Osa

x

tohoto grafu p°edstavuje velikost datového toku v jednotkách MB/s.

28

KAPITOLA 5.

TESTOVÁNÍ

Obrázek 5.1: Graf závislosti datového toku na FPS vykreslování p°i testu soubor·

Osa

y

je relativní hodnota frekvence snímkování skute£né FPS souboru a vykreslované FPS

vynásobená £íslem sto (procentuální vyjád°ení frekvence vykreslování ku reálné rychlosti snímkování). Je patrné ºe s rostoucím datovým tokem klesá rychlost vykreslování. To je zp·sobeno jiº zmín¥ným systémem vy£ítaní dat se souboru. áste£ným °e²ením tohoto problému by bylo rozd¥lení procesu vy£ítání a p°evodu na výstupní formát mezi dv¥ nezávislá vlákna. To by ale vyºadovalo pom¥rn¥ sloºitou synchronizaci t¥chto vláken a vysoké nároky na procesor. Také by docházelo k zahlcování p°evád¥jícího vlákna. To by vedlo bu¤ ke ztrát¥ snímk·, nebo k podobnému zpomalení vy£ítání jak je tomu v tomto stavu implementace. P°i zapnutém sledování objekt· v modulu jádra je procesor pom¥rn¥ vytíºen a jádro p°i situaci, kdy nestíhá aplikovat algoritmy sledování, zahazuje snímky, které dostává od datového modulu. P°i velkém vytíºení datového modulu by algoritmy jádra stíhaly zpracovávat pouze malé mnoºství snímk· a vytíºení procesoru by ve výsledku vy²lo vnive£. Tímto zp·sobem vy£ítání datový modul um¥le reguluje rychlost vy£ítání a poskytuje modulu jádra prostor pro výpo£ty. Druhým grafem znázor¬ujícím výsledky testování je graf 5.2 popisující závislost datového

3

toku a celkového vytíºení jednoho procesoru v²emi výpo£etními moduly . Graf vykazuje p°ibliºn¥ lineární závislost mezi zmín¥nými veli£inami. Z grafu je také patrné, ºe celkové zatíºení v reºimu ²edotónu je pro v²echny p°ípady vy²²í n¥º je tomu u vytíºení v reºimu rgb. Tento fakt je podporován p°edev²ím vysokými nároky na zpracovávání ²edotónových dat v datovém modulu, které p°evy²ují nároky niº²í nároky na zpracování tohoto reºimu v ostatních modulech. 3

Výpo£etní moduly jsou datový modul, modul jádra a výstupní modul. °ídicí modul neprovádí ºádné

výpo£ty a zat¥ºuje procesor nepatrn¥ (na testovacím stolním po£íta£i maximáln¥ 1%).

5.2.

29

VÝKON APLIKACE

Obrázek 5.2: Graf závislosti datového toku na CPU modul· p°i testu soubor·

Veli£ina

Ve£er

Poledne

RGB edotón

RGB edotón

11

11

15

15

0,63

0,21

0,86

0,28

CPU Datový modul [%]

>1

>1

>1

>1

CPU Modul jádra [%]

>1

>1

1

>1

CPU Výstupní modul [%]

1

1

2

1

CPU celkem [%]

1

1

3

1

Rychlost vykreslování [FPS] P°enosová rychlost [MB/s]

Tabulka 5.9: Testování kamery p°i rozli²ení 160x120 pixel· - testování ve£er a v poledne.

5.2.2 USB kamera P°i pouºití knihovny unicap ovliv¬uje kvalita osv¥tlení snímkovací frekvenci kamer. Proto bylo testování provád¥no p°i dvou r·zných intenzitách osv¥tlení. První testování probíhalo v noci v relativn¥ dob°e osvícené místnosti. Druhé testování se uskute£nilo v poledne u okna, coº poskytovalo o poznání kvalitn¥j²í osv¥tlení pro testovanou kameru. Pro testování byla pouºita kamera

Logitech, Inc. QuickCam Pro for Notebooks.

Byla

testována na £ty°ech rozli²eních: nejniº²í rozli²ení 160x120, 320x240, 640x480 a nejvy²²í moºné rozli²ení kamery 1600x1200. Technika vy£ítání dat z kamery je odli²ná od techniky pouºité pro vy£ítání dat z avi soubor·. Data z USB kamery jsou vy£ítána v reálném £ase, nedochází ke zpoºd¥ní vykreslování a v²echna data vy£tená z kamery jsou systémem zpracována. P°i rozli²ení 160x120 pixel· (tabulka 5.9) systém vy£ítá z kamery pom¥rn¥ malé mnoºství

30

KAPITOLA 5.

Veli£ina Rychlost vykreslování [FPS] P°enosová rychlost [MB/s] CPU Datový modul [%] CPU Modul jádra [%]

Ve£er

TESTOVÁNÍ

Poledne

RGB edotón

RGB edotón

12

12

15

15

2,76

0,92

3,45

1,15

2

1

5

2

>1

>1

1

2


4

3

2

1

CPU celkem [%]

6

4

8

5


Veli£ina Rychlost vykreslování [FPS] P°enosová rychlost [MB/s]

Ve£er

Poledne

RGB edotón

RGB edotón

11

11

15

15

10,13

3,37

13,82

4,68


7

3

9

4


6

2

9

3


5

2

7

3

18

7

25

10

CPU celkem [%]


dat. To je patrné z p°enosových rychlostí. Vytíºení procesoru je tém¥° nepatrné. Dále stojí za zmínku, ºe p°i poledním osv¥tlení vzrostla frekvence snímkování kamery tém¥° o t°etinu. U testování, které popisuje tabulka 5.10, je datová rychlost uº n¥kolikanásobn¥ v¥t²í. P°esto je stále p°íli² malá, aby mohla výrazn¥ji specikovat chování systému p°i vy£ítání dat z USB kamery. Rozli²ení 640x480 poskytuje uº pom¥rn¥ zajímavé výsledky (tabulka 5.11). Modul jádra vyt¥ºuje procesor více neº výstupní modul i v p°ípad¥, ºe je vypnuto sledování objekt·. P°esto hodnocení vyt¥ºování procesoru modulem jádra není p°edm¥tem této práce. Také je dobré si pov²imnout pom¥rn¥ velkého rozdílu celkového vytíºení procesoru v rgb reºimu a reºimu ²edotónu. P°í£ina tohoto rozdílu je analyzována v následujícím odstavci. V tabulce 5.12 jsou uvedeny výsledky testování USB kamery v jejím maximálním rozli²ení 1600x1200 pixel·, p°i kterém m¥la kamera stejnou snímkovací frekvenci jak p°i ²patném, tak p°i dobrém osv¥tlení. Vytíºení procesoru vykazuje velmi podobné hodnoty pro oba druhy sv¥telných podmínek. U tohoto m¥°ení je jiº o£ividné, ºe v reºimu ²edotónu je vy£ítání dat z kamery n¥kolikrát rychlej²í neº v reºimu rgb. Data formátu rgb jsou sice t°ikrát objemn¥j²í neº formátu ²edotónu, p°esto je vy£ítání v tomto p°ípad¥ ²estkrát rychlej²í. To je zap°í£in¥no vlastnostmi formátu YUV 4:2:2, který je p°i vy£ítání dat z kamery pouºíván. V tomto formátu je jiº obsaºena ²edotónová sloºka (kapitola 4.4.1) a proto je p°evod na tento formát velice rychlý. P°i p°evodu na rgb formát se vyuºívají p°evodní rovnice, £ímº se celý proces komplikuje. Graf 5.3 popisuje závislost zatíºení procesoru datovým modulem na datovém toku ka-

5.3.

31

VÝSLEDKY TESTOVÁNÍ VÝKONU

Veli£ina Rychlost vykreslování [FPS] P°enosová rychlost [MB/s]

Ve£er

Poledne

RGB edotón

RGB edotón

5

5

5

5

28,8

9,6

28,8

9,6


18

3

17

4


18

6

16

5


13

5

13

4

CPU celkem [%]

49

14

46

13


Obrázek 5.3: Graf závislosti datového toku na CPU datového modulu p°i testu USB kamery

mery. Zajímavým elementem je, ºe p°i nízkých hodnotách datového toku je na grafu znázorn¥no, ºe zatíºení procesoru datovým modulem nabývá vy²²ích hodnot pro reºim ²edotónu. To je s nejv¥t²í pravd¥podobností zp·sobeno zkreslením m¥°ení p°i tak malých datových tocích. P°i zvy²ování datových tok· dochází p°edev²ím u k°ivky grafu pro rgb k ustálení a linearizaci zát¥ºe.

5.3

Výsledky testování výkonu

P°i testování soubor· bylo zji²t¥no, ºe systém zpomaluje frekvenci vykreslování a tím zpomaluje video. Doprovodným jevem je um¥lá regulace zát¥ºe systému a tím poskytnutí v¥t²í £ásti výkonu procesoru pro modul jádra. Dále vy²lo najevo, ºe systém si z testovaných kodek· nejlépe poradil s kodekem XVID a DivX. Dal²ím poznatkem je fakt, ºe p°i práci s avi soubory je kvalitn¥ji zpracován p°evod na rgb neº na ²edotón.

32

KAPITOLA 5.

TESTOVÁNÍ

P°i testování kamery jsme ov¥°ili, ºe práce s formátem YUV 4:2:2 je efektivn¥j²í v reºimu ²edotónu. P°i reºim ²edotónu kamery je dokonce vytíºení procesoru datovým modulem n¥kolikanásobn¥ men²í neº vytíºení v reºimu ²edotónu avi souboru.

Kapitola 6

Záv¥r 6.1

Zhodnocení spln¥ní cíl·

Prvním zásadním cílem této práce bylo splnit modulární formu systému tak, aby byly jednotlivé moduly snadno vym¥nitelné. Modularity je dosaºeno tím, ºe kaºdý z modul· je nezávislým procesem, který spole£n¥ s ostatními moduly komunikuje pomocí °ídicího protokolu. Jako komunika£ní protokol byl vybrán standardní protokol rodiny protokol· TCP/IP a je relativn¥ detailn¥ popsán v kapitole 4.2 Komunika£ní protokol. Pomocí techniky spojení samostatných proces· tímto protokolem jsme nejen dosáhli poºadavku na modularitu a snadnou vym¥nitelnost modulu, ale i moºnosti b¥hu systému distribuovan¥ mezi n¥kolika po£íta£i na lokální síti. Dal²ím cílem práce bylo zajistit vy£ítání vstupních data ze souboru a z USB nebo Fireware kamery. Vy£ítaní se souboru je v aplikaci realizováno pomocí knihovny avile. Tato knihovna poskytuje dosta£ující prost°edky pro práci s avi soubory. Knihovna ale není multiplatformní a její algoritmy pro p°evody formát· se p°i testování projevily jako nep°íli² efektivní. Navíc postrádá kvalitní dokumentaci, a proto byl vývoj s touto knihovnou pom¥rn¥ obtíºný. Z cíle vy£ítání z kamery byl spln¥n poºadavek na vy£ítání z USB kamer. Vy£ítání z kamer Fireware není v práci z £asových d·vod· implementován. Pro vy£ítání obrazu z kamer USB je vyuºita knihovna unicap. Tato knihovna není multiplatformní a neobsahuje algoritmy na p°evody do pot°ebných formát·. P°esto pracuje relativn¥ spolehliv¥ a zdá se být dobrou volbou pro tento systém. O p°evod na pot°ebný formát se stará vlastní p°evodní algoritmus, který je v porovnání s algoritmy knihovny avile velice rychlý. Toho je dosaºeno i vhodnou optimalizací p°evodního kódu. Systém je spustitelný jak z p°íkazové °ádky, tak pomocí grackého uºivatelského rozhraní. Systém navíc umoº¬uje tvorbu inicializa£ních soubor· v grackém uºivatelském rozhraní. Tyto soubory je moºné následn¥ ru£n¥ editovat, na£ítat v grackém uºivatelském rozhraní a spou²t¥t pomocí p°íkazové °ádky. Grackému uºivatelskému rozhraní byla v¥nována pon¥kud v¥t²í pozornost. Obsahuje více moºností nastavení n¥º je tomu u p°epína£· na p°íkazové °ádce. P°esto je uºivatel schopen spou²t¥t základní testování pouze pomocí p°epína£· z p°íkazové °ádky. Gracké uºivatelské rozhraní i ovládání z p°íkazové °ádky se snaºí chovat standardním zp·sobem, jak je uºivatel zvyklý u ostatních aplikací. Gracké uºivatelské rozhraní také disponuje systémem pro ozna£ování sledovaných objekt· v probíhajícím videu, coº bylo jedním z dal²ích cíl· práce. Tento systém je realizován

33

34

KAPITOLA 6.

ZÁVR

pomocí dialogu, kde si uºivatel levým tla£ítkem my²i vybere sledovaný objekt v aktuálním snímku probíhající videosekvence. Dále má uºivatel moºnost tento objekt uloºit do souboru pro dal²í pouºití. Samoz°ejmostí je na£ítání takto uloºených objekt· pro sledování v dal²ích videosekvencích. On-line výstup je realizován pomocí výstupního modulu. Ten vykresluje obraz probíhající videosekvence pomocí standardu pro vykreslování po£íta£ové graky OpenGL. Vykreslování pomocí OpenGL zaru£uje relativn¥ rychlý zp·sob zobrazování jednotlivých snímk· videa. Tato technika je pouºita i u velké £ásti dne²ních po£íta£ových program· pro p°ehrávání videa. Spole£n¥ s framworkem Qt zle jednodu²e zakreslovat do videa dal²í pot°ebné informace. Po konzultaci s autorem £ásti projektu zabývající se vývojem modulu jádra bylo rozhodnuto, ºe pro systém bude efektivn¥j²í implementovat o-line výstup v modulu jádra. Proto není tento poºadavek v této bakalá°ské práci implementován.

6.2

Pokra£ování práce

V systému chybí moºnost vy£ítání dat z Fireware kamer, coº by m¥lo být logickým pokra£ováním v implementaci datového modulu. Systém je p°ipravený na p°idávání dal²ích datových zdroj· implementací abstraktní t°ídy pro tyto zdroje (kapitola 4.4.1). V datovém modulu je implementován pouze jeden formát kamer YUV 4:2:2. Pro kvalitn¥j²í vyuºití moºností kamer je do budoucna d·leºité roz²í°it seznam podporovaných formát· nebo nahradit knihovnu unicap jiným nástrojem, který bude mít schopnost p°evád¥t obraz na poºadovaný formát. P°evád¥ní formát· externí knihovnou ale nemusí být vºdy správná cesta, jak jsme se p°esv¥d£ili u testování datového modulu a jeho p°evodu na ²edotónový formát. Dal²í pokra£ování ve vývoji systému se m·ºe ubírat n¥kolika sm¥ry. Prvním cílem do budoucna by mohla být multiplatformnost celého systému. V tuto chvíli by m¥ly spl¬ovat podmínku multiplatformnosti v²echny moduly vyjma datového modulu, protoºe datové zdroje obsaºené v tomto modulu nevyuºívají multiplatformní knihovny. Nabízí se zde n¥kolik variant, jak tento problém °e²it. V jedné z nich by byly datové zdroje dynamickými knihovnami, které by se k systému p°ipojovaly s ohledem na konkrétní opera£ní systém. V druhé variant¥ by byly v²echny zdroje implementovány £ist¥ multiplatformními knihovnami. Dal²ím cílem pro budoucí pokra£ování práce je nahradit n¥který ze stávajících modul· za jiný. Nemusí se jednat p°ímo o vylep²ování stávajících modul·. M·ºe dokonce dojít k p°idání dal²ího modulu jako mezistupn¥, coº by v²ak vyºadovalo relativn¥ velký zásah do stávající aplikace.

Literatura [1] OpenCV wiki home page

http://opencv.willowgarage.com/,

stav ze 4. 5. 2010.

[2] Qt knihovna developer zone

http://qt.nokia.com/developer,

stav ze 25. 4. 2010.

[3] Qt doc Signals and Slots

http://doc.trolltech.com/4.6/signalsandslots.html,

stav ze 18. 5. 2010.

[4] Wikipedie: otev°ená encyklopedie charakteristika TCP/IP

http://cs.wikipedia.org/wiki/TCP/IP,

stav ze 25. 4. 2010.

[5] Základní optimaliza£ní techniky jazyka C

http://www.codeproject.com/KB/cpp/C___Code_Optimization.aspx,

stav

ze

25. 4. 2010. [6] QtCreator popis

http://qt.nokia.com/products/appdev/developer-tools/developer-tools#qt-tools-at-a, stav ze 25. 4. 2010. [7] Avile home page

http://avifile.sourceforge.net/,

stav ze 25. 4. 2010.

[8] Avile Supported compression formats

http://avifile.sourceforge.net/formats.htm,

stav ze 25. 5. 2010.

[9] Unicap home page

http://unicap-imaging.org/,

stav ze 25. 4. 2010.

[10] Ji°í Va¬¥k Bakalá°ská práce [11] J. Stoklasa,

P°edná²ky p°edm¥tu ízení softwarových projekt· (X36RSF),

zdrojového kódu, strany 1617. [12] Convert RGB Image to Grayscale

http://www.dfanning.com/ip_tips/color2gray.html,

stav ze 10. 5. 2010.

[13] Denice formátu YUV 4:2:2

http://www.fourcc.org/yuv.php#UYVY,

stav ze 17. 5. 2010.

35

Kvalita

36

LITERATURA

[14] Test 3D akcelerace Ubuntu

http://wiki.ubuntu.cz/Ovlada%C4%8De%20grafick%C3%BDch%20karet, 22. 5. 2010.

stav

ze

Dodatek A

Seznam pouºitých zkratek AVC

Advanced Video Coding

AVI

Audio Video Interleave

CLI

Command-line interpreter

DivX

Digital Video Express

CPU

Central Processing Unit

FPS

Frames Per Second

GUI

Graphical user interface

HD

High Denition

IDE IP

Integrated Development Environment

Internet Protocol

LAN

Local Area Network

MPEG

Motion Picture Experts Group

OpenCV

Open Source Computer Vision

OpenGL

Open Graphics Library

RGB

Barevný model £ervená-zelená-modrá

TCP

Transmission Control Protocol

USB

Universal Serial Bus

QT

Multiplatformní knihovna C++

XGA XVID

Extended Graphics Array Free Digital Video Express

37

38

DODATEK A.

SEZNAM POUITÝCH ZKRATEK

Dodatek B

Instala£ní a uºivatelská p°íru£ka B.1

Systémové nároky a vyºadované knihovny

B.1.1 Systémové nároky Aplikace vyºaduje opera£ní systém GNU/Linux. Pro spu²t¥ní aplikace na více po£íta£ích musí být tyto po£íta£e propojeny pomocí lokální sít¥. Systém je moºné spustit jak na 32bitové, tak na 64bitové architektu°e. Pro bezproblémové vykreslování výstupu pomocí funkcí OpenGL, je podmínkou správn¥ instalovaná gracká karta podporující 3D akceleraci OpenGL. Bez plné podpory nelze zaru£it stoprocentní výsledek vykreslování výstupního modulu. Pro systémy GNU/Linux existuje jednoduchý postup [14], jakým zle ov¥°it, zda kombinace gracké karty a ovlada£e podporuje 3D akceleraci. V prvním kroku spus´te p°íkaz:

glxinfo | grep direct pokud je výstupem

direct rendering: No tak je jisté, ºe po£íta£ nemá plnou podporu 3D akcelerace. Pokud je výstupem

direct rendering: Yes s nejv¥t²í pravd¥podobností akcelerace funguje. Poté následuje test p°íkazem

glxgears Spu²t¥ní tohoto p°íkazu zobrazí okno s animací OpenGL. Na standardním výstupu potom program v ur£itých intervalech vypisuje parametry vykreslované animace. Pokud je frekvence vykreslování v parametrech animace (FPS) niº²í neº 500, tak pravd¥podobn¥ akcelerace nefunguje. V p°ípad¥, ºe po£íta£ nemá plnou podporu 3D akcelerace, není zaru£en správný výsledek vykreslování výstupního modulu (výstupní modul vyuºívá funkce OpenGL pro vykreslování). Dal²í podmínkou pro spou²t¥ní systému s USB kamerou je správn¥ nainstalovaný ovlada£ této kamery. Funk£nost kamery s knihovnou unicap m·ºete ov¥°it pomocí programu který je ke staºení na webu

http://unicap-imaging.org/download.htm.

39

ucview,

40

DODATEK B.

INSTALANÍ A UIVATELSKÁ PÍRUKA

B.1.2 Knihovny Aplikace vyºaduje p°ítomnost n¥kolika knihoven. Jejich seznam spole£n¥ s minimální verzí zaru£ující správný b¥h aplikace a domovským webem je uveden v následujícím seznamu. Ve v¥t²in¥ distribucí jsou tyto knihovny sou£ástí standardních repositá°·. Pokud nejsou obsaºeny v t¥chto repositá°ích jsou k dispozici na webu uvedeném v seznamu.

•

libqt4-dev - 4.5.2 (http://qt.nokia.com/downloads)

•

libunicap-dev - 0.9.9 (http://unicap-imaging.org/download.htm)

•

libavile-0.7-dev - 0.7.47 (http://avile.sourceforge.net/download.htm)

Pro podporu p°ehrávání avi soubor· kompresovanými r·znými kodeky instalujte avile pluginy. Konkrétn¥ balí£ky:

•

avile-divx-plugin

•

avile-xvid-plugin

•

avile-win32-plugin

•

avile-mjpeg-plugin

B.2

Instalace

Instalace systému probíhá ve dvou krocích. V prvním kroku je nutné zkompilovat statické knihovny. P°esuneme se do sloºky

lib

v ko°enové sloºce

1 aplikace a spustíme p°íkaz:

./make_libs make V druhé £ásti instalace je pot°eba zkompilovat samotné moduly systému. Toho docílíme spu²t¥ním následujícího skriptu v ko°enové sloºce aplikace:

./make_project make Oba dva kompila£ní skripty vyuºívají kompila£ního nástroje Qt

qmake,

programu

make

a n¥kterého ze standardních kompilátor· jazyka C++. P°edchozí instalace t¥chto nástroj· je nezbytná pro úsp¥²nou kompilaci systému. Po úsp¥²né kompilaci vzniknou £ty°i spustitelné soubory, z nichº kaºdý reprezentuje jeden modul systému. Následuje seznam modul· a umíst¥ní jejich spustitelných soubor· po úsp¥²né kompilaci.

1

•

Datový modul -

•

Modul jádra -

DataModule/bin/datamodule

CoreModule/bin/coremodule

Na p°iloºeném CD je ko°enová sloºka

src.

B.3.

41

PRÁCE S PROGRAMEM

•

Výstupní modul -

•

°ídicí modul -

OutputModule/bin/outputmodule

Tracker/bin/tracker

Uºivatel spou²tí program

tracker. Ostatní moduly jsou tímto programem spou²t¥ny automa-

ticky.

B.3

Práce s programem

Program pro svou úsp¥²nou £innost vyºaduje spu²t¥ní v²ech modul·, jejich spojení s °ídicím modulem a následné navázání jejich vstup· a výstup·. V²echny tyto operace se provád¥jí automaticky v závislosti na nastavení v inicializa£ním souboru °ídicího modulu. Pokud chceme spou²t¥t n¥který z modul· na jiném po£íta£i neº na kterém je spou²t¥n °ídicí modul, musíme uvést pat°i£né nastavení v tomto inicializa£ním souboru a spustit modul ru£n¥. Postup p°i spou²t¥ní modulu na vzdáleném po£íta£i popisuje kapitola B.3.3 Distribuce mezi n¥kolik po£íta£·. Pokud dojde z jakýchkoliv d·vod· k p°eru²ení b¥hu n¥kterého z modul·, nebo k p°eru²ení datových a komunika£ních cest, je nutné celý systém vypnout a spustit znovu. Pro ukon£ení v²ech modul· v p°ípad¥ pádu systému lze vyuºít skript

clean_processes, který je umíst¥n ve

sloºce zkompilovaného °ídicího modulu.

B.3.1 P°íkazová °ádka Systém je spustitelný z p°íkazové °ádky pomocí binárního souboru

tracker

ve sloºce zkom-

pilovaného °ídicího modulu s p°íslu²nými parametry. Jednotlivé parametry a jejich význam jsou popsány v kapitole 4.4.2 °ídicí modul. Pokud neuvedeme p°epína£ -x spou²tí se systém bez grackého uºivatelského rozhraní. V tomto reºimu je nutné uvést zdroj ze souboru pomocí p°epína£e -f, jinak se systém nespustí. Vyhodnocení p°íkaz· na p°íkazové °ádce probíhá zleva doprava. Následuje p°íklad, který demonstruje vyhodnocování p°epína£· na p°íkazové °ádce.

./tracker -i nastaveni.ini -f vstup.avi -d data.dump nastaveni.ini, který nastaví vnit°ní prom¥nné systému, uvedené v tomto souboru. P°epína£em -f p°epí²eme V tomto konkrétním p°ípad¥ dojde nejprve k na£tení inicializa£ního souboru

prom¥nné pro reºim systému na reºim avi souboru a prom¥nou ur£enou pro vstupní soubor

vstup.avi. data.dump.

nastavíme na na soubor

P°epína£

-d

p°epí²e p°edchozí nastavení výstupu oine souboru

B.3.2 Gracké uºivatelské rozhraní Gracké uºivatelské rozhraní systému je rozd¥leno do n¥kolika funk£ních £ástí. Jak je patrné z obrázku B.1, tyto £ásti jsou modulu jádra a pro výstupní

DATA MODULE pro datový modul, CORE MODULE pro modul OUTPUT MODULE. V kaºdé této £ásti se nacházejí

objekty pro editaci nastavení konkrétních modul·.

42

DODATEK B.


Obrázek B.1: Okno GUI

Sekce

DATA MODULE

Source ), Format ) a výb¥r výstupního formátu (Colors ). U výb¥ru zdrojem z kamery (Device ) nebo ze souboru (File ). P°i výb¥ru je roz£len¥na na dal²í t°i podsekce: výb¥r zdroje dat (

výb¥r vstupního formátu kamery ( zdroje uºivatel zvolí mezi

kamery je uºivateli nabídnut seznam kamer p°ipojených do systému. Výb¥r ze souboru je realizován pomocí tla£ítka ..., který reprezentuje tla£ítko Procházet. Pokud je jako zdroj dat vybrána kamera, je nutné zvolit v dal²í podsekci výstupní formát kamery. V sou£asné verzi systému je podporován pouze formát YUV 4:2:2. V poslední podsekci uºivatel volí mezi

Greyscale ).

výstupem v rgb nebo v ²edotónu (

Datový modul systém b¥hem svého pr·b¥hu není schopný p°ipojovat nové kamery a kamery odpojené p°i b¥hu systému se jeví stále jako p°ipojené. Proto je pot°eba kameru p°ipojit a neodpojovat p°ed ukon£ením systému. Dal²í sekce

CORE MODULE

obsahuje dv¥ £ásti. První slouºí pro správu sledovaných

objekt· a druhá na ur£ení oine dat pro video sekvenci. Správa objekt· je realizována pomocí £ty° tla£ítek. Tla£ítko Add p°idá sledovaný objekt ze souboru, který je ve formátu 24bitové bitmapy. Create slouºí pro vytvo°ení objektu v práv¥ probíhající videosekvenci. Vytvá°ení je realizováno pomocí dialogu, v n¥mº uºivatel levým tla£ítkem my²i vybere obdélníkovou plochu odpovídající novému sledovanému objektu. Tla£itko Save as je ur£eno pro ukládání vytvo°ených objekt· do soubor· a tla£ítko Remove slouºí ke zru²ení sledování objektu.

B.3.

43

PRÁCE S PROGRAMEM

Oine data jsou alternativou k seznamu objekt· pro sledování. Pokud je za²krtnuto polí£ko Use only oine data jsou nahrána modulem jádra oine data ze souboru uvedeného pod tímto polí£kem. V p°ípad¥ nahrání oine dat jsou ignorovány vybrané objekty pro sledování. Poslední sekce

OUTPUT MODULE

má pouze jeden element. Ten ur£uje, zda mají být

ukládány oine data pro pozd¥j²í analýzu. Dále obsahuje pole ur£ující umíst¥ní t¥chto dat. Gracké uºivatelské rozhraní v horní £ásti obsahuje li²tu se záloºkami V záloºce

File

File

a

Outputs.

se nachází menu pro ukládání (Save, Save as...) a na£ítaní (Load) kon-

gurace grackého uºivatelského rozhraní. Dále je v tomto menu tla£ítko pro ukon£ení aplikace (Exit). V menu

Outputs

se nachází tla£ítka pro zobrazení dialog· obsahující výstupy z jed-

notlivých modul·. Dialogy obsahují dané výpisy pouze v reºimu výpis· výstupu £íslo dva. Sou£ástí grackého rozhraní je i okno výstupního modulu. V n¥m je zobrazován pr·b¥h vi-

CTRL+C vyvolá poºadavek na vytvo°ení nového modelu v probíhajícím datovém toku. Zkratka CTRL+1, CTRL+2 ... CTRL+9 slouºí k detekci modelu s daným id. deosekvence. V tomto okn¥ m·ºeme vyuºít dvou klávesových zkratek. Zkratka

B.3.3 Distribuce mezi n¥kolik po£íta£· Sou£ástí systému je i moºnost b¥hu jednotlivých modul· na r·zných po£íta£ích v lokální síti. Kaºdý z modul· lze spou²t¥t s jedním nebo se dv¥ma parametry. Spou²t¥ní se dv¥ma parametry vyuºívá °ídicí modul p°i automatickém spou²t¥ní modul· na lokálním po£íta£i. Pro spu²t¥ní modulu na vzdáleném po£íta£i vyuºijeme spu²t¥ní s jedním parametrem, který denuje na jakém portu bude modul o£ekávat spojení s °ídicím modulem. Dále musíme pro tento modul uvést do inicializa£ního souboru systému tracker.ini nastavení portu a adresy vzdáleného po£íta£e. Konkrétní formát inicializa£ního souboru a v²echny pot°ebné parametry jsou uvedeny v kapitole 4.4.

B.3.4 Spu²t¥ní video souboru - krok za krokem Tato kapitola popisuje postup

krok za krokem

p°i spou²t¥ní systému s ukázkovým videem.

Na²ím cílem v této kapitole je uvést systém do stádia, kdy bude sledovat námi zvolený objekt ve vybraném videu. Ukázkové video je obsaºeno na CD ve sloºce

video/demo1.avi. Na videu je pohybující se

modrý £tverec na bílem pozadí.

Krok 0 - Spu²t¥ní grackého uºivatelského rozhraní:

P°ed v·bec prvním krokem

musíme systém spustit. Pro spu²t¥ní systému v reºimu grackého uºivatelského rozhraní napí²eme ve sloºce zkompilovaného programu

tracker

p°íkaz:

./tracker -x

Krok 1 - Vybrání souboru jako zdroje dat: moºností zdroje mezi v modrém obdélníku.

Device

a

File

Jak demonstruje obrázek B.2 vybereme z

druhou moºnost. Tato volba je nazna£ená i na obrázku

44

DODATEK B.


Obrázek B.2: Postup p°i spou²t¥ní videa pomocí GUI

Krok 2 - Najdeme a otev°eme video:

Vybereme si video pro p°ehrávání. Pokud nemáme

ºádné video p°ipravené, m·ºeme pouºít ukázkové demo video (umíst¥ní: video/demo1.avi) na p°iloºeném CD. Vybrání videa provedeme tla£ítkem zvýrazn¥ným na obrázku B.2 £erveným obdélníkem. Poté pomocí standardního dialogu pro výb¥r souboru vybereme vý²e zmín¥né video.

Krok 3 - Spustíme video:

Tla£ítkem

Start

(ºlutý obdélník na obrázku B.2) spustíme

video. Vybraná videosekvence se za£ne zobrazovat v okn¥ výstupního modulu

Krok 4 - Vytvo°íme objekt pro sledování: vyuºijeme tla£ítko

Create

outputmodule.

Pro výb¥r objektu ur£enému ke sledování

(alový obdélník na obrázku B.2). Video se v tu chvíli zastaví

a zobrazí se dialog pro výb¥r objektu v aktuálním okn¥. V n¥m taºením levého tla£ítka

Ok. outputmodule za£ne po chvilce probíhat sledování daného objektu

my²i ozna£íme objekt ur£ený ke sledování (obrázek B.3) a potvrdíme výb¥r tla£ítkem V okn¥ výstupního modulu

(obrázek B.4). Sledovaný objekt je ve výstupním modulu ohrani£en £erveným obdélníkem, vypln¥ným £erveným te£kováním. Rohy tohoto obdélníku jsou zvýrazn¥ny modrými kruºnicemi.

B.3.

45

PRÁCE S PROGRAMEM

Obrázek B.3: Dialog výb¥ru sledovaného objektu

B.3.5 Spu²t¥ní kamery - krok za krokem Tato kapitola popisuje postup

krok za krokem

p°i spou²t¥ní systému v reºimu USB kamery.

Krok 0 - Spu²t¥ní grackého uºivatelského rozhraní:

P°ipojíme USB kameru do

po£íta£e. Dále postupujme stejn¥ jako u kroku £íslo 0 spou²t¥ní video souboru.

Krok 1 - Výb¥r kamery a formátu:

Obrázek B.5 znázor¬uje výb¥r kamery a jejího

formátu. V modrém obdélníku na uvedené obrázku je p°íklad výb¥ru kamery. V £erveném potom výb¥r formátu. Systém je schopný zpracovávat pouze formát YUV 4:2:2, proto je podmínkou správného fungování výb¥r tohoto formátu.

Krok 2 - Spustíme video:

Viz krok £íslo 3 spou²t¥ní videa ze souboru.

Krok 3 - Vytvo°íme objekt pro sledování:

Viz krok £íslo 4 spou²t¥ní videa ze souboru.

B.3.6 Demonstra£ní video práce s kamerou Sou£ástí p°iloºeného CD je video zachycující práci se systémem v reºimu kamery. Umíst¥ní tohoto videa na CD je

video/kamera_demo.avi.

46

DODATEK B.


Obrázek B.4: Okno výstupní modulu v pr·b¥hu sledování

B.3.

PRÁCE S PROGRAMEM

Obrázek B.5: Postup p°i spou²t¥ní kamery pomocí GUI

47

48

DODATEK B.


Dodatek C

Obsah p°iloºeného CD

49

50

DODATEK C.

OBSAH PILOENÉHO CD

Obrázek C.1: Seznam p°iloºeného CD, 1. £ást

51

Obrázek C.2: Seznam p°iloºeného CD, 2. £ást

Modulární SW systém pro sledování objekt ve videu v reálném ase. Ond ej Semmler

Recommend Documents