České vysoké učení technické v Praze Fakulta elektrotechnická Katedra počítačů Bakalářská práce 3D rekonstrukce objektů ze stránek pro sdílení fotografií Ondřej Macoszek Vedoucí práce: Ing. David Sedláček Studijní program: Softwarové technologie a management, Bakalářský Obor: Softwarové inženýrství 30. května 2011
iv
v Poděkování Rád bych poděkoval panu Ing. Davidu Sedláčkovi za trpělivost a podporu při realizaci této bakalářské 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. 2011.............................................................
viii
Abstract The aim of bachelor thesis is to design and implement application for automatic 3D reconstruction of photo from photo-sharing websites (such as Flickr). App will integrate existing components for 3D reconstruction (Bundler - the structure from motion tool, CMVS - multiview stereo tool). Input will be search keyword or collection of already downloaded photos. App will prepare all necessary structures for 3D reconstruction. Integrated existing componets will be able to configure and replace. Test solution on two collections from internet and one one given by supervisor. Abstrakt Cílem práce je navrhnout a implementovat nástroj pro automatickou 3D rekonstrukci objektů z fotografií volně dostupných na internetu (např. Flickr). Nástroj bude integrovat již hotové komponenty pro 3D rekonstrukci (structure from motion program Bundler a program pro rekonstrukci hustého mračna bodů - CMVS). Vstupem budou data z kolekce fotografií (vyhledávací výraz) a nebo již stažené fotografie. Nástroj automaticky připraví potřebné datové struktury pro následující kroky 3D rekonstrukce. Jednotlivé části rekonstrukčních programů budou konfigurovatelné a zaměnitelné (např. výběr SIFT detektoru). Řešení otestujte na 2 kolekcích z internetu a na jedné kterou dodá vedoucí práce. ix
x
Obsah 1 Úvod 1 2 Specifikace cíle 3 2.1 Vymezení požadavků................................ 3 2.2 Případy užití.................................... 4 2.3 Rešerše existujících implementací......................... 5 2.3.1 Photo Tourism............................... 5 2.3.2 Photosynth................................. 5 2.3.3 Photo City Game.............................. 5 2.3.4 Google Street View............................. 5 3 Analýza 7 3.1 Typický průběh práce při 3D rekonstrukci.................... 7 3.2 Fungování podpůrných aplikací.......................... 8 3.2.1 SIFT..................................... 8 3.2.2 Bundler................................... 8 3.2.3 PMVS.................................... 9 3.2.4 CMVS.................................... 9 3.3 Průzkum možností technologií používaných při realizaci............ 10 3.3.1 Sítě pro sdílení obrázků.......................... 10 3.3.1.1 Flickr............................... 10 3.3.2 Google Image Search a Facebook..................... 10 3.3.3 Guice.................................... 11 3.3.4 Operační systém.............................. 11 4 Návrh a realizace 13 4.1 Architektura.................................... 13 4.2 Deploy model.................................... 13 4.3 Model tříd a entit.................................. 15 4.3.1 Byznys vrstva................................ 15 4.3.2 Uživatelské rozhraní............................ 23 4.4 Jednotkové testovaní................................ 24 xi
xii OBSAH 5 Testování 27 5.1 Experimenty s vlastnoručně nafocenými fotkami................. 27 5.2 Experiment s daty staženými z internetu..................... 27 5.3 Experiment s daty od vedoucího BP....................... 28 5.4 Experiment s testovacími obrázky z distribuce Bundleru............ 28 6 Závěr 31 A Seznam literatury 33 B Seznam použitých zkratek 35 C UML diagramy 37 D Instalační a uživatelská příručka 43 D.1 Instalace....................................... 43 D.2 Popis obrazovek................................... 43 D.2.1 Dashboard................................. 43 D.2.2 Search query................................ 43 D.2.3 Search results................................ 45 D.2.4 Download.................................. 45 D.2.5 SFM Setup................................. 45 D.2.6 SFM running................................ 47 D.2.7 MVS..................................... 47 D.2.8 Settings................................... 47 E Obsah přiloženého CD 49
Seznam obrázků 4.1 Architektura aplikace a rozložení komponent................... 14 4.2 Diagram nasazení.................................. 15 4.3 Model tříd, Přehled tříd byznys vrstvy...................... 16 4.4 Model tříd, balíček downloader.......................... 17 4.5 Model tříd, balíček images............................. 18 4.6 Model tříd, balíček search............................. 19 4.7 Model tříd, balíček SFM.............................. 20 4.8 Model tříd, balíček MVS.............................. 21 4.9 Model tříd, balíček settings............................ 22 4.10 Model tříd, balíček tools.............................. 22 4.11 Model tříd UI, obecné třídy............................ 23 4.12 Model tříd UI, třídy pro vyhledávání a stahování................ 24 4.13 Model tříd UI, třídy PMVS a CMVS....................... 25 5.1 Testování, Čajová konvice............................. 27 5.2 Testování, Srní, meshlab.............................. 28 5.3 Testování, Srní, fotografie............................. 29 5.4 Testování, Kermit, meshlab............................ 29 5.5 Testování, Kermit, fotografie............................ 30 C.1 Analýza, Vztahy mezi soubory, které zpracovává Bundler............ 37 C.2 Analýza, Závislosti Bundleru........................... 38 C.3 Analýza, Závislosti CMVS............................. 38 C.4 Analýza, Závislosti PMVS............................. 39 C.5 Případy užití, hlavní................................ 39 C.6 Případy užití, stahování.............................. 40 C.7 Případy užití, multi-view-stereo.......................... 40 C.8 Případy užití, výběr fotek............................. 41 C.9 Případy užití, vyhledávání............................. 41 C.10 Případy užití, structure from motion....................... 42 D.1 UI, Dashboard................................... 44 D.2 UI, Search query.................................. 44 D.3 UI, Search results.................................. 45 D.4 UI, Download progress............................... 46 D.5 UI, SFM setup................................... 46 xiii
xiv SEZNAM OBRÁZKŮ D.6 UI, SFM running.................................. 47 D.7 UI, MVS....................................... 48 D.8 UI, Settings..................................... 48
Seznam tabulek xv
xvi SEZNAM TABULEK
Kapitola 1 Úvod Za posledních několik let zažil svět vznik množství sociálních sítí a za poslední 2 roky nevídaný nárust mobilních aplikací. To vše usnadnilo lidem sdílet své každodenní zážitky okamžitě se svými přáteli, nebo rovnou s celým světem. Portál Flickr zabývající se sdílením fotografií zaznamenal 1 koncem roku 2010 pět miliard obrázků. Uživatelé tohoto webu navíc přidají 3000 fotek každou minutu. Tyto čísla ovšem hravě strčí do kapsy sociální síť Facebook, která zaznamenává 200 miliónů nahraných fotek každý den a se současnými přibližně 90 miliardami fotek celkem tvoří pravděpodobně největší databázi fotek na internetu 2. Velikou výhodou je, že fotky jsou popsány především klíčovými slovy, ale mnohdy jsou opatřeny i gps souřadnicemi nebo dalšími informacemi. Takové to množství pojmenovaných fotek samozřejmě nabízí nejrůznější příležitosti. Jednou z těchto příležitostí je právě 3D rekonstrukce objektů. Existující aplikace pro 3D rekonstrukci dokážou předané fotky zpracovat a vytvořit často velmi věrohodný 3D model vyfocených objektů. Bylo by úžasné spojit vyhledávání v některé z veřejných internetových fotobank a 3D rekonstrukci, pak by stačilo zadat například klíčové slovo "notre dame"a vysledkem by byl 3D model této pařížské katedrály. 1 Flickr Blog, 5,000,000,000: http://blog.flickr.net/en/2010/09/19/5000000000/ 2 Dotaz na Quora.com: http://www.quora.com/how-many-photos-are-uploaded-to-facebook-each-day 1
2 KAPITOLA 1. ÚVOD
Kapitola 2 Specifikace cíle 2.1 Vymezení požadavků Hlavním cílem bakalářské práce je vyvinout nástroj usnadňující 3D rekonstruci objektů z fotografií volně dostupných na internetu. Aplikace bude schopna přijmout určité klíčové slovo, volitelně nějaké upřesňující informace (GPS souřadnice, datum pořízení snímku) pomocí, kterých vyhledá na internetu odpovídající fotografie. Nalezené fotografie budou uživateli prezentovány k ručnímu vyfiltrování nevhodných záběrů. Tyto vybrané fotografie budou následně staženy do předem určené složky na počítači. Alternativně bude možné aplikaci předat složku s již staženými fotkami ke zpracování. Aplikace dále uživateli umožní konfigurovat a spustit programy pro 3D rekonstrukci. K nefunkčním požadavkům řadíme zajištění plynulosti ovládání aplikace. Protože 3D rekonstrukce i stahování fotek jsou úkony velmi výpočetně a časově náročné, bude víc než užitečné tyto činnosti přesunout od samostatných vláken, kde nebudou zpomalovat ovládání hlavní aplikaci a její uživatelské rozhraní. Mezi systémové požadavky bude patřit nezávislost na aplikacích zajišťující detekci významných bodů (SIFT) a zpracování structure-from-motion (Bundler) a multi-view-stereo (CMVS). Primárně bude aplikace určená pro operační systém linux, ale při návrhu i implementaci se bude počítat i s jinými platformami. Aplikace bude vytvořena v Javě jednak kvůli budoucímu snadnějšímu propojení s již existujícími vizualizačními programy. Další výhodou je také snadnější přenos aplikace mezi platformami a v neposlední řadě, že autor práce se v prostředí vyzná a vyhovuje mu. Uživatelské rozhraní si klade za cíl být přehledné a jednoduché. Bez prvků zbytečných pro aktuální činnost. Pro práci s aplikací je typický postup určitými fázemi zpracování množiny dat, proto uživatelské rozhraní obsahuje navigační prvky usnadňující rozhodnutí kam pokračovat dál. Například po stažení sady fotek má uživatel možnost postoupit k fázi nastavení a spuštění programu Bundler. Aplikace ovšem umožňuje také skok do libovolné fáze a začít pracovat právě tam - pro případy, kdy uživatel potřebuje například opravit či porovnat výstup z určité fáze. Součástí bakalářské práce bude také ověření funkčnosti aplikace na dvou kolekcích fotografií stažených z internetu (notre dame a orloj na staroměstském náměstí) a na jedné dodané vedoucím bakalářské práce (faustův dům). 3
4 KAPITOLA 2. SPECIFIKACE CÍLE 2.2 Případy užití Případy užití vyjadřují jak bude uživatel se systémem pracovat, konkrétně jaké úkony tam bude provádět. Vycházejí z požadavků, ale dotahují detailněji popis typických činností uživatele. Hlavními akcemi uživatele v aplikaci bude výběr fotografií ke zpracování, nastavení a spuštění structure-from-motion, dále nastavení a spuštění multi-view stereo aplikace a konečně nastavení cest k nezbytným souvisejícím aplikacím. Při výběru fotografií bude mít uživatel na výběr mezi dvěmi možnostmi. Jednou je stažení kolekce fotek z internetu a druhou je výběr složky na počítači s již připravenou sadou obrázků. Budou zaznamenávány posledně hledaná klíčová slova a posledně používané složky a uživatel tak může přeskočit rovnou do předvyplněného formuláře, nebo začít nastavovat SFM s již doplněným adresářem se zdrojem obrázků. Bude-li uživatel chtít hledat fotky na internetu, uvítá ho nejprve formulář, ve kterém vyplní co by potřeboval nalézt. Uživatel vyplní klíčová slova typická pro hledaný objekt, případně vyplní GPS souřadnice hledaného místa, nebo datum upřesňující okamžik pořízení nebo nahrání fotky na internet. Dále uživatel může nastavit počet zobrazených výsledků na stránce. Bez vyplněného klíčového slova nepůjde formulář odeslat. Kromě formuláře pro vyhledávání bude mít uživatel v tomto okamžiku také možnost zvolit složku pro stažení případných vybraných obrázků a nastavení zda každý stažený obrázek zmenší a předvypočítat mu významné body pomocí SIFT. Stav stahování uživatel nebude ovlivňovat a bude jej smět jen prohlížet. Uživatel uvidí průběh stahování jednotlivých fotografií. Stav bude informovat o tom, zda obrázek čeká ve frontě na stažení, zda je právě stahován, zda byl kvůli nějakým problémům přeskočen a zda byl zdárně stažen. Méně podrobněji pak bude uživatel informován o průběhu úprav fotek po stažení (zmenšení velikost a předvypočítání SIFT). Před přesunutím k prvnímu kroku 3D rekonstrukce bude muset uživatel počkat na stažení všech fotografií ve frontě. První krok 3D rekonstrukce structure-from-motion nabídne uživateli výběr složky ke zpracování, pokud ještě nebyla vybrána. Uživatel bude také moci upravit nastavení spouštěného SFM programu. V případě, že fotografie byly pořízeny fotoaparátem, o kterém aplikace nemá informace o optice, bude na to při zpracování uživatel upozorněn a může pak zpátky v nastavení doplnit informace o optice ručně. Po spuštění rekonstrukce bude uživatel průběžně informován o stavu rekonstrukce. Budou zde také ovládací prvky pomocí, kterých půjde právě probíhanou rekonstrukci zastavit anebo prohlédnout složku s výsledkem zpracování. Po dokončení rekonstrukce bude uživateli nabídnuto postoupení k druhému kroku rekonstrukce. Druhý krok 3D rekonstrukce multi-view-stereo uživatele požádá o zadání adresáře s výstupem z prvního kroku (SFM). Uživatel může pomocí formuláře upřesnit volby aplikací CMVS a PMVS. Obdobně jako u prvního kroku bude po spuštění rekonstrukce uživatel informován o průběhu, a bude mít možnost rekonstrukci zastavit, nebo prohlédnout výsledek. Čast s nastavením bude od uživatele požadovat upřesnění umístění aplikací, které jsou nezbytné pro 3D rekonstrukci. Při zadání cesty k aplikaci, bude uživatel informován zda aplikace skutečně existuje a zda je spustitelná.
2.3. REŠERŠE EXISTUJÍCÍCH IMPLEMENTACÍ 5 2.3 Rešerše existujících implementací Zatím neexistuje veřejně dostupná aplikace zajišťující dohromady vyhledávání fotek na internetu a jejich 3D rekonstrukci. Existující implementace se zaměřují spíše na způsob prohlížení a prezentace fotek a rekonstruovaného modelu scény. 2.3.1 Photo Tourism Photo Tourism 1 si klade za cíl vytvořit z fotek 3D prostředí a umožnit uživateli prostředím interaktivně procházet a prohlížet fotky v místech odkud byly foceny. Navigace mezi místy existuje ve dvou módech. První nabízí pohyb mezi scénami formou prolínání fotek mezi sebou. Druhý způsob umožňuje plný pohyb 3D prostorem, kde jsou fotografie umístěny na místech odkud byly foceny, a navíc dokáže zobrazit pomocné informace a náhled mapy z ptačí perspektivy. Jádro aplikace pro 3D rekonstrukci bylo uvolněno pod názvem Bundler. Aplikaci vytvořil Noah Snavely a jeho tým z laboratoře GRAIL na University of Washington. 2.3.2 Photosynth Photosynth 2 je software pro tvorbu panoramat a prohlížení fotografií v 3D prostoru. Vznikl na základě Photo Tourism a přenesl možnost pohybu 3D prostorem do prostředí webového prohlíže. Vizualizace scény v prohlížeči funguje prostřednictvím technologie Silverlight. Využívá také softwaru firmy Seadragon pro optimalizované prohlížení fotek bez ohledu na jejich původní velikost. Později byla přidána také možnost tvorby panorarmat. 2.3.3 Photo City Game Photo City Game 3 je zajímavý nápad jak spojit dohromady zábavu a praktické využití. Pomocí mobilních telefonů a digitálních fotoaparátů hráči "dobývají"budovu tím, že fotí chybějící části. Body se počítají podle toho kolik 3D bodů fotografie do modelu přidá. Více bodů znamená větší skóre a větší šance na vítězství. 2.3.4 Google Street View Google ve svém Street View používá princip z Photo Tourist tak, že během procházení ulice nabízí uživateli možnosti kliknout na místo ulice, které bylo nafoceno detailněji a prohlížet jej zblízka. Navíc při prohlížení této fotky se lze opět posouvat dál na další detailněji nafocená místa. Toto vylepší funguje dokonce i v místech, kde vůz Street View nedokázal projet. 1 Oficiální web Photo Tourism: http://phototour.cs.washington.edu/ 2 Oficiální web Photosynth: http://www.photosynth.net/ 3 Oficiální web Photo City Game: http://www.photocitygame.com/
6 KAPITOLA 2. SPECIFIKACE CÍLE
Kapitola 3 Analýza 3.1 Typický průběh práce při 3D rekonstrukci Během 3D rekonstrukce scény je zapotřebí projít několika nezbytnými kroky. Nastavení v jednotlivých krocích mnohdy výrazně ovlivňuje výsledek příslušné fáze. Nejprve je potřeba vybrat vhodné fotografie. Snímky by měly zabírat rekonstruovaný objekt pokud možno postupně ze všech stran. Pokud jde o veřejně známý objekt může pomoci i vyhledávání na internetu. Pro účely programu Bundler je nezbytné aby fotografie byly opatřeny EXIF informacemi, ze kterých aplikace získá podrobnosti o optice fotoaparátu, ze kterého bylo foceno. Díky aplikací PMVS nemusíme vyřazovat fotografie obsahující nestatické objekty, tj. například lidi, auta, cyklisty. Velikost fotografií je nejlepší ponechat původní. Zpracování je pak sice výpočetně i časově náročnější, ale zato rekonstrukce scény by měla být mnohem přesnější. Pokud experimentujeme může být kvůli rychlé zpětné vazbě vhodné velikost fotografí zmenšit a případně také vyřadit ze zpracování některé nadbytečné snímky. Dalším krokem je již spuštění programu Bundler. Spouští se pomocí shellového skriptu RunBundler.sh dodávaného v distribuci aplikace. Skript zajistí nezbytnou přípravu zahrnující zjištění optiky fotoaparátu pomocí EXIF informací uložených ve fotografiích, detekci významných bodů pomocí algoritmu SIFT, a následná identifikace shodných významných bodů mezi různými fotografiemi. Po předzpracování sady fotek se konečně spustí samotná aplikace Bundler, které skript předá právě zjištěné informace o optice, a dále nalezené shody významných bodů mezi fotografiemi, společně s nastavením řídícím další zpracování. Bundler spočítá umístění významných bodů a kamer v 3D prostoru a výsledek vrátí. Následně se spustí nástroj Bundle2PMVS, který výstup z Bundleru převede na formát kompatibilní s formátem očekávaným na vstupu PMVS. Nástroj vytvoří shellový skript který provede nezbytnou přípravu fotek pro další krok. Pokračuje se spuštěním aplikace CMVS, která množinu obrázků rozdělí na menší kousky. Tyto kousky je možné zpracovávat nezávisle, lze tedy případně využít síly více strojů běžících paralelně. Na jednom počítači se však pokračuje nástrojem genoption, který vytvoří shellový skript automatizující spuštění PMVS a sjednocení clusterů. 7
8 KAPITOLA 3. ANALÝZA Jakmile PMVS dokončí svou práci pokračuje se obvykle zkoumáním výsledků v aplikacích jako Meshlab. Výsledný model lze dále upravovat například pomocí Poissonovy rekonstrukce do polygonů. 3.2 Fungování podpůrných aplikací 3.2.1 SIFT SIFT je zkratka názvu algoritmu Scale-invariant feature transform. Tento algoritmus se především v oboru počítačového vidění používá k detekci významných bodů v obrázku. Algoritmus vytvořil v roce 1999 kanadský vědec David Lowe. 1. Algoritmus zpracovává fotku čtyřmi hlavními kroky. První fáze nazývaná detekce extrémů nezávislých na velikosti (anglicky: Scaleinvariant extrema detection) zajístí vybrání prvních kandidátů na významné body. Stejný obrázek nejprve rozmaže pomocí Gaussových filtrů s různou intenzitou. Tím vznikne několik variant obrázků rozmazaných postupně čím dál víc. Dále se vypočítá rozdíl mezi dvěmi rozmazanými obrázky (jeden silněji rozmazaný a druhý slaběji), v algoritmu nazývaný jako Difference of Gaussian (DoG). Kandidáti na významné body pak vyberou jako lokální minima a maxima rozdílových DoG obrázků. Výběr se provádí pro každý pixel DoG obrázku tak, že se porovná s osmi sousedy svého obrázku a zároveň s devíti sousedícími pixely postupně na všech dalších DoG (které reprezentují zbývající úrovních rozmazání původního obrázku). Pokud je hodnota pixelu nějvětší nebo nejmenší mezi všemi ostatními porovnávanými pixely, pak je bod vybrán jako významný. Druhou fází je lokalizace významných bodů (anglicky: Keypoint localization), která se postará o zužení výběru významných bodů, tak aby zůstaly jen ty stabilní. Pro každého kandidáta se určí pozice pomocí interpolace jeho sousedních bodů. Pokud se zjistí, že bod leží velmi blízko jiného kandidáta, pak se bod zahodí a test se spustí znova od tohoto blízkého kandidáta. V opačném případě bod zůstává v množině kandidátů. Dále se v této fázi vyřadí body zastupující místa obrázku s nízkým kontrastem. Třetí fáze přiřazení orientace bodů (anglicky: Orientation assignment) učiní bod nezávislým na natočení obrázku. Přiřadí každému bodu orientaci podle toho, kterým směrem je v místě bodu na obrázku nasměrován přechod barev. Čtvrtá fáze výpočet deskriptoru pro významný bod (anglicky: Obtaining keypoint descriptor) slouží k vytvoření unikátního identifikátoru bodu. Identifikátor bude vyjadřovat směr, umístění a velikost. Nyní je tento bod vybavený deskriptorem výborně odlišitelný od ostatních a zůstává také částečně nezávislý na vlivu osvětlení a deformace v 3D prostoru. 3.2.2 Bundler Bundler je aplikace pro rekonstrukci umístění kamer v 3D prostoru z množiny neuspořádaných obrázků. Autorem je Noah Snavely, který tento software napsal pro svůj projekt Photo Tourism. 1 Object recognition from local scale-invariant features
3.2. FUNGOVÁNÍ PODPŮRNÝCH APLIKACÍ 9 Jde o implementace principu structure-from-motion, který v oboru počítačového vidění označuje postupy pro nalézání trojdimenzionálních objektů v signálech a strukturách reprezentujících pohyb. Na vstupu aplikace očekává cestu ke zpracovávaným obrázkům, informace o šířce CCD čipu fotoaparátu, který snímky pořídil, dále významné body detekované pomocí SIFT algoritmu, a konečně vztahy mezi obrázky zjištěné pomocí KNN (k nejbližších sousedů) algoritmu. Výstupem je shluk rozptýlených významných bodů a rekonstruované umístění kamer v 3D prostředí. Bundler rekonstruuje scénu přírustkově, tj. zpracovává se jen několik obrázků současně. Uvnitř Bundler postupuje tak, že vybere několik podobných (blízkých) významných bodů a provede nad nima operaci RANSAC. Tím se určí 3D umístění významných bodů a umístění fotoaparátu. Příslušný paprsek pohledu z místa odkud byla fotografie focena se pak musí protnout v určitém 3D bodě s paprskem pohledu z místa pořízení druhé fotky, která obsahuje stejný právě analyzovaný významný bod jako fotografie druhá. Poté jsou zjištěné informace o pozicích kamer přidáný do výsledného modelu scény. Takto postupně (pár obrázků současně) se pokračuje v identifikaci pozic kamer dokud nejsou zpracovány všechny významné body. 3.2.3 PMVS PMVS neboli patch based multi-view stereo je program, který pomocí sady obrázků a informací o nastavení kamer (výstup Bundleru) dokáže rekonstruovat 3D strukturu objektů nebo scény zaznamenané na obrázcích. PMVS rekonstruuje pouze statické objekty. Proměnlivé objekty (například auta nebo chodci) jsou ignorovány. Vnitřní logika dokáže urychlit výpočty pokud jsou známy informace o viditelnosti (které obrázky vidí společné body povrchu) z SfM aplikací. PMVS je výborně propojitelná s programem Bundler. Bundler ve své distribuci obsahuje nástroj, kterým lze převést jeho výstup na vstup očekávaný v PMVS. 3.2.4 CMVS CMVS řeší problém škálovatelnosti pro multi-view stereo aplikace, především pro PMVS. Program postupuje tak, že rozdělí množinu zpracovávaných obrázků na menší části (clustery) a ty se pak nechají v MVS aplikaci zpracovat samostatně. Pokud je k dispozici více strojů, lze nechat úlohu řešit paralelně a dosáhnout tak daleko rychlejšího zpracování. Tvůrci aplikace doporučují 2 používat CMVS po zpracování sady Bundlerem a před PMVS. A to i když je počet obrázků malý, protože PMVS, pokud využívá clustery, poběží vždy rychleji a dodá přesnější výsledky. Vytváření clusterů z množiny obrázků odstraňuje nadbytečné obrázky, které nejsou potřebné pro MVS rekonstrukci. Toto opět zrychlí proces PMVS a zlepší přesnost rekonstrukce. Nadbytečné obrázky bez dostatečné baseline degradují přesnost rekonstrukce. Dalšího zrychlení je možné dosáhnout pomocí souboru vis.dat, který CMVS vytváří a který obsahuje informace o sousedních obrázcích (zjištěné KNN algoritmem). 2 http://grail.cs.washington.edu/software/cmvs/
10 KAPITOLA 3. ANALÝZA 3.3 Průzkum možností technologií používaných při realizaci 3.3.1 Sítě pro sdílení obrázků 3.3.1.1 Flickr Flickr je jednou z nějvětších sociálních sítí pro sdílení fotografií. Vývojářům poskytuje kvalitní API, které je velmi dobře zdokumentováno, poskytuje interaktivní pískoviště, kde je možné si vše okamžitě vyzkoušet. Výhodou je také existence otevřených nádstaveb API pro mnoho programovacích jazyků. Pro komunikaci s rozhraním je k dispozici široká škála podporovaných protokolů. Dotazovat se lze pomocí REST, XML-RPC a SOAP. Odpověď na požadavek lze získat opět v REST, XML-RPC a SOAP, ale navíc je možné využí formátu JSON, případně serializovaného řetězce pro PHP. Formát odpovědi se v požadavku určuje argumentem format. Všechny požadavky do API vyžadují dva nezbytné argumenty. Prvním je method značící volanou metodu a druhým je api"_"key pro API klíč komunikující aplikace. Dokumentace upozorňuje na skutečnost, že identifikátory všech objektů jsou řetězce a proto by neměly být přetypovávany na číslo. Zatím jsou identifikátory většinou čísla, ale to se může v budoucnu změnit. Dále tvůrci deklarují, že všechna data v komunikaci budou zakódována v kódování UTF-8. API umožňuje navázat ověřené spojení přihlášením přes Authentication API. Aplikace po přihlášení obdrží token a podpis, který musí předávat v každém dalším požadavku. Výhodou je pak přístup k fotkám spřátelených účtů. Pro účely bakalářské práce však přihlášení nemá velký význam, protože pokud by nebyl k dispozici účet s velkým množstvím přátel, nenalezlo by se o mnoho více fotek než při neautorizovaných požadavcích. Pro komunikaci s rozhraním v jazyce Java, existují dvě implementované open-source nádstavby (Flickrj a Jickr), avšak jsou již neudržované a místy lehce zastaralé (zvláště v části pro vyhledávání). Bakalářská práce si pro odesílání požadavků vystačí s principem REST, který je založen na zakódování požadavku přímo do URL. V javě lze odpověď jednoduše přečíst přes BufferedStream. Nejvhodnějším formátem odpovědi bude JSON čitelný v javě například prostřednictvím jednoduché nenáročné knihovny Json Simple 3. 3.3.2 Google Image Search a Facebook Nabízelo se také využití databáze některých jiných gigantů na poli sdílení fotek. Databáze Google Image Search by měla obsahovat všechny obrázky veřejně dostupné na internetu. K dispozici je také kvalitně zdokumentované rozhraní s principy fungování podobnými rozhraní Flickru. Datáze fotek na Facebooku přes svoji lákavou rozsáhlost zůstává volnějšímu vyhledávání uzavřena. Nabízejí také velmi dobré API, avšak umožňující přistupovat pouze fotkám předem známé stránky či uživatele, nedovoluje vyhledávat podle klíčových slov. Podobně funguje také služba Google Picasa Web. 3 http://code.google.com/p/json-simple/
3.3. PRŮZKUM MOŽNOSTÍ TECHNOLOGIÍ POUŽÍVANÝCH PŘI REALIZACI 11 Bakalářská práce bude počítat s návrhem tak, aby bylo možné postupem času přidat kromě Flickru i další služby. Flickr působí jako nejlepší kandidát, protože jeho uživatelé obvykle fotí cíleně a rádi, obvykle slouží také jako galerie vzpomínek na dovolené, proto lze předpokládat, velké množství dobrých fotek turisticky atraktivních míst. 3.3.3 Guice Nástroj Guice pro správu závislostí objektů v jazyce Java vyvinuli vývojáři společnosti Google. Jde o nástroj zajišťující v Javě podporu principu dependency injection pomocí anotací. Princip dependency injection (DI) tkví v tom, že vyžadovaný objekt je úsporně uchován v nějakém repozitáři a v případě, že je objekt požadován na určitém místě kódu, pak je na toto místo automaticky podsunut, takže tento místní kód může počítat s příslušnou instancí objektu. Obvykle lze také nastavit okruh platnosti ve kterém může stejná instance stále fungovat, například request, session, singleton a další. Odprosťuje od nutnosti používat pro vytváření instancí tříd operátor new nebo továrny. Výhodou je skutečnost, že třídy pak nejsou tolik svázané k sobě a tím pádem i snadněji rozšiřitelné a upravitelné. Pokud například třída implementuje určité rozhraní a v jiná třída na tomto rozhrání závisí, pak je nutné objektu této třídy nějak předat instanci, která toto rozhraní podporuje. Obvykle se toto činí pomocí operátoru new následovaného jménem specifické třídy implementující příslušné rozhraní. Pokud je toto nutné provést na více místech, hrozí do budoucna riziko, že v případě nutnosti výměny této specifické třídy za jinou, bude nutné projít postupně všechna místa v kódu a upravit je. Další vyhodou je podpora okruhu platnosti objektu. Pak je možné například vytvořit z obyčejné nestatické třídy objekt typu singleton a používat jej takto v části kódu, kde je takové chování příhodné. V jiné části kódu se může chovat opět jako klasická instance třídy s platností omezenou blokem, ve kterém je definovaná. Princip dependency injection je také velká výhra pro testování softwaru. Pokud například v některém unit testu potřebujeme nasimulovat chování závislého objektu, můžeme vytvořit vlastní testovací (mock) implementaci splňující rozhraní očekáváné v závislém objektu. Pomocí Guice ji podsunout všem potřebným objektům a pak už jen testovat chování. Guice funguje tak, že se vytvoří třída nazývaná modul, ve které se upřesní vztahy používaných typů k instancím. Například pokud máme navržené určité rozhraní, a k němu naimplementovanou třídu, pak v modulu pro Guice propojíme rozhraní s implementací a případně nastavíme nějaký okruh platnosti (třeba singleton). Když pak nástroji Guice řekneme, aby nám, s pomocí námi vytvořeného modulu, zajistil instanci požadovaného typu - Guice zjistí které instance je na typ napojena a tuto instanci vrátí (nebo případně vytvoří, pokud ještě nebyla). V takto vytvořených objektech jsou pak automaticky podsunuty instance pro proměnné (nebo argumenty metod) označené anotací @Inject. 3.3.4 Operační systém Nástroje pro rekonstrukci Bundler a MVS jsou silně svázány s platformou Linux. Ve zdrojových kódech lze například nalézt několik závislostí na linuxové chování adresářové struktury.
12 KAPITOLA 3. ANALÝZA Přesto Bundler je možné spustit i pod operačním systémem Windows pomocí programu Cygwin, který simuluje linuxové prostředí.
Kapitola 4 Návrh a realizace 4.1 Architektura Architektura aplikace je třívrstvá - rozdělená do uživatelského rozhraní, byznys logiky a podpůrných aplikací. Byznys logika aplikace bude tvořena třemi hlavními částmi. Na obrázku jsou barevně odlišeny. Fialová barva označuje komponenty zajišťující 3D rekonstrukci. Béžovou barvou je vyznačená část upravující nebo pracující s obrázky. A poslední část obarvená zeleně má na starosti procesy kolem vyhledávání a následného stahování. Komponenty Downloader, Editor, MVS a SFM jsou proti ostatním vyjímečné tím, že jejich výpočetně náročná činnost je přesunuta do samostatných vláken, takže neblokují kód, který je volal. Volající kód pak bude v případě potřeby sám zjišťovat zda byla činnost dokončena. Tyto komponenty také poskytuj možnost naslouchat jejich vnitřním změnám, prostřednictvím mechanismu Observer-Observable. Rozhraní Observable je implementováno již v základní třídě BaseBusiness všech tříd byznys vrstvy, protože je předpoklad, že uživatelské rozhraní bude zajímat aktualizace stavu byznys vrstvy okamžitě. Uživatelské rozhraní bude tvořit okno s ovládacím menu a prostorem nazývaným epicentrum, které bude sloužit pro umístění obrazovek právě prezentovaných uživateli. 4.2 Deploy model Aplikace bude běžet v linuxovém prostředí na platformě Java 6. Před spuštěním částí aplikace s 3D rekonstrukcí je potřeba mít v operačním systému nainstalovanou knihovnu liblapack3gf, kterou program Bundler využívá pro matematické výpočty. Dále je potřeba zkopírovat do sdíleného adresáře knihoven s aplikací dodanou knihovnu libann"_"char.so, zajišťující v Bundleru porovnávání významných bodů. Dále v případě, že uživatel hodlá využívat vyhledávání fotek na internetu, je nutné aplikaci povolit HTTP přístup k serverům společnosti flickr.com. 13
14 KAPITOLA 4. NÁVRH A REALIZACE Obrázek 4.1: Architektura aplikace a rozložení komponent.
4.3. MODEL TŘÍD A ENTIT 15 Obrázek 4.2: Diagram nasazení 4.3 Model tříd a entit 4.3.1 Byznys vrstva Hlavní logika aplikace je organizována do balíčků podle druhu zaměření. Veškeré třídy obstarávající vyhledávání, zpracování obrázků, stahování obrázků, 3D rekonstrukci nebo nastavení jsou soustředěny do samostatných balíčků. Návrh řídících tříd ctí princip návrhu chování přes rozhraní a pak následnou implementaci tohoto chování v třídě. V celém kódu se bude důsledně dodržovat ukládání instancí právě do těch rozhraní, které jsou v tom momentě potřeba. Uložit instanci třidy do specifického typu této třídy lze použít jen při testování. Pokud mají nějaké závislosti na jiných třídách byznys vrstvy, pak pokud je to jen možné, se využije připraveného dependency-injection mechanismu pro podsunutí správné instance. Třída BaseBusiness bude tvořit jádro všech řídících tříd vrstvy. Obsahuje již naimplementované metody rozhraní Observable, takže je připravena rozesílat registrovaným posluchačům, zprávy o aktualizaci dle potřeby. V rámci byznys vrstvy tento návrhový vzor využijí třídy DownloadManager a Editor, které spolupracují na zpracování stahovaných obrázků. Balíček download se stará o plynulé stahování požadovaných obrázků. Obrázky plánované ke stažení se kumulují do fronty a po spuštění stahování se začnou postupně stahovat. Obrázek se do fronty zařadí v přestrojení za objekt DownloadItem, který sebou nese URL adresu cíle, umístění kam se obrázek bude lokálně stahovat a v neposlední řadě údaj o stavu stahování tohoto obrázku. Stav stahování položky může nabývat čtyř možností: waiting, který se přiřazuje nově příchozím obrázkům, dále downloading pro právě stahované, pak finished pro
16 KAPITOLA 4. NÁVRH A REALIZACE Obrázek 4.3: Model tříd, Přehled tříd byznys vrstvy úspěšně stažené obrázky a nakonec skipped pro položky které z nejrůznějších důvodů nebyly staženy v pořádku, nebo byly po stažení rozpoznány jako zbytečné. Samotný proces stahování dat obrázků z internetu probíhá v samostatném vlákně. To proto, aby nezpomaloval chod dalších částí aplikace. Metodou start je vytvořeno nové vlákno vždy když jsou položky ke stažení a vlákno ještě nebylo vytvořeno. Metodou stop se vlákno zruší a tím se i zastaví proces stahování. Pokud byla stahovaná položka právě na půli cesty, nemá ještě nastavený stav finished, takže bude při opětovné startu stahování stažena celá od znova. Balíček images se postará o všechy činnosti týkající se zpracování fotek. Obsahuje třídu Editor, která se fungováním dosti podobá tříde DownloadManager. Totiž, Editor slouží opět k zajištění plynulé úpravy fotek na pozadí mimo ostatní procesy. Rozhraní ImageManager popisuje její implementaci BasicImageManager souhrn služeb, které musí být schopná zajistit. Jde o změnu velikosti fotky pomocí nástroje mogrify, spočtení významných bodů pomocí algoritmu SIFT, pomůcky pro zjištění zda pro obrázek soubor s vypočtenými body již existuje. Mimo to, ji byla také svěřena detekce informací o šířce CCD čipu fotoaparátu, který zpracovávaný snímek pořídil. Databáze informací o CCD čipech lze za běhu aplikace rozšiřovat, a proto musí být uchovávána do souboru, aby je bylo možné načíst po opětovném spuštění aplikace. Návrh balíčku pro vyhledávání počítá již od základů s možným rozšířením o další vyhledávací služby. Proto je algoritmus dotazování vyhledávače vytažen do samostatné třídy SearchEngine a dotazování je na něj delegováno z třídy ImageSearch, která slouží k uchovávání a tvoření aktuálního vyhledávacího dotazu. Třída SearchEngine poskytuje také metody pro zjištění URL k obrázku. Lze získa zvlášť URL pro náhled, pro obrázek střední velikost a pro obrázek v původní velikosti.
4.3. MODEL TŘÍD A ENTIT 17 Obrázek 4.4: Model tříd, balíček downloader
18 KAPITOLA 4. NÁVRH A REALIZACE Obrázek 4.5: Model tříd, balíček images Balíček pro první fázi 3D rekonstrukce structure from motion zahrnuje implementaci nádstavby nad aplikací Bundler. Fungování třídy Bundler je z výkonostních důvodů opět navrženo tak, aby bylo spuštěno v samostatném vláknu a nezatěžovalo tak zbytek systému. Třída kompletně zastupuje skript RunBundler.sh, distribuovaný s programem Bundler. Automaticky zajistí přejmenování přípon na malá písmena, dále vytvoří soubory s informacemi o optice fotoaparátů, provede nalezení shodných významných bodů a nakonec spustí samotný Bundler. Balíček mvs se stará o druhou fázi 3D rekonstrukce multi-view stereo. Třída je Basic- MultiViewStereo bude implementována opět tak aby časově náročná část procesu běžela v samostatném vlákně. Třída si klade za cíl zastoupit shelové skripty v původní distribuci programů PMVS a CMVS. Třídu Settings hojně využívají třídy byznys vrstvy, které závisejí na nějaké externí aplikaci. Totiž, právě prostřednictvím této třídy lze zjistit cestu k příslušné aplikaci. Nastavení těchto cest lze prostřednictvím uživatelského rozhraní kdykoli změnit. Třída nastavení automaticky ukládá do souboru, takže zvolené volby zůstanou i po opětovném startu aplikace. Balíček tools obsahuje nástroje plnící rutiní procedury používané hojně napříč všemi částmi aplikace. Třídy tohoto balíčku se vyznačují svou statickou implementací. Jde totiž o jednoúčelové příkazy, proto byl tento způsob implementace považován za nejvhodnější. Třída FileHelper obsahuje funkce pro usnadnění manipulace se složkami, soubory, jejich sestami a příponami. Dále je schopná kopírovat a binárně porovnávat soubory. Třída OS umožňuje identifikovat operační systém. Třída StreamHelper zajišťuje snadnou manipulaci s proudy (nyní jen se vstupními proudy). Součásti balíku jsou také vlastní volnější implementace návrhového vzoru Observer- Observable. U standartní javovské implementace těchto vzorů překážela nutnost dědit od
4.3. MODEL TŘÍD A ENTIT 19 Obrázek 4.6: Model tříd, balíček search
20 KAPITOLA 4. NÁVRH A REALIZACE Obrázek 4.7: Model tříd, balíček SFM
4.3. MODEL TŘÍD A ENTIT 21 Obrázek 4.8: Model tříd, balíček MVS
22 KAPITOLA 4. NÁVRH A REALIZACE Obrázek 4.9: Model tříd, balíček settings Obrázek 4.10: Model tříd, balíček tools
4.3. MODEL TŘÍD A ENTIT 23 Obrázek 4.11: Model tříd UI, obecné třídy třídy Observable. Avšak nejdůležitější součástí je třída DI, zabalující rozhraní dependency-injection frameworku Guice do jedné třídy. Usnadňuje tak potom ovládání frameworku zejména nutností psát menší počet znaků. 4.3.2 Uživatelské rozhraní Uživatelské rozhraní je navrženo tak, aby bylo možné snadno, operativně a odkudkoli vyslat příkaz ke změně obrazovky za jinou. Centrem je hlavní okno MainWindow, které kromě ovládacího menu, drží také instanci JPanel nazývanou epicentrum. Do tohoto epicentra se vždy načte aktuální požadovaná obrazovka. Pomocí metod changeepicenterto lze změnit aktuální obrazovku. Tato metoda má specifikum v tom co provádí před změnou a po změně obrazovky. Totiž, přijímá pouze typ BaseUi, který dedí všechny třídy uživatelského rozhraní objevující se v epicentru, a tato třídá poskytuje metody init, start a close, které metoda changeepicenterto volá postupně: close při zrušení aktuální okna, init pro inicializaci okna, a po přiřazení do epicentra zavolá start. Díky těmto metodám, lze ovlivňovat spuštění nějaké činnosti pravě v okamžiku kdy je to vhodné. Například pomocí start a close se registrují a ruší obrazovka jako posluchač v příslušných třídách implementující Observable. Ještě by bylo vhodné zmínit, že je to právě metoda changescreen tříd BaccordApp přes, kterou se obrazovky mění. Jde o třídu typu singleton, takže je jediná instance dostupná vždy všude. Zde tato skutečnost nevadí, protože aplikace bude mít vždy jen jediné okno. Tato třída drží instanci na MainWindow. Metoda changescreen vždy požádá dependency-injection framework o instanci obrazovky a následně instanci uloží do epicentra MainWindow. Role DI frameworku zde, hraje důležitou roli protože, díky ní zde budou naplněny místa označená anotací @Inject. Univerzální třídou je Dialog, která poskytuje rychlý přístup k vytvoření okna s upozorněním nebo zprávou. Mimo to také dokáže vyvolat formulář pro zadání cesty k souboru či adresáři a vybraný adresář pak vrátit. Implementace tříd obrazovek pro vyhledávání a stahování již hojně využívá DI frameworku pro doplnění instancí požadovaných tříd z byznys vrstvy. Předávání dat z formulářových políček do objektů byznys vrstvy probíhá obvykle v okamžiku stisknutí tlačítka
24 KAPITOLA 4. NÁVRH A REALIZACE Obrázek 4.12: Model tříd UI, třídy pro vyhledávání a stahování určeného pro odeslání nebo potvrzení akce. Informace z formuláře je předáná vždy přímo do byznys vrstvy. Po změně obrazovky je informace v případě potřeby z byznys objektu opět načtena. Zde stojí za zmínku třída SingleResult, která ve vyhledávání reprezentuje jeden nalezený obrázek. Je schopná držet stav o tom zda je nebo není označená. Tento stav také vizuálně prezentuje, díky přetížení metody paint. Třída ImagesDownloadProgress ukazuje napojení na DownloadManager pomocí mechanismu Observer-Observable. Proto okamžitě, když se změní stav stahované položky, bude o této změně upozorněna i třída ImagesDownloadProgress. Diagram znázorňuje dohromady dvě velmi podobné části reprezentující implementaci uživatelského rozhraní pro ovládání 3D rekonstrukce. Třídy s příponou Setup vždy předají nastavení do příslušného byznys objektu, tj. buď implementace StructureFromMotion nebo MultiViewStereo. Po stisknutí tlačítka pro běh se obrazovka změní obrazovku s informacemi o průběhu zpracování. Obrazovky implementují rozhraní Observer a proto mohou sledovat aktuální zprávy z průběhu 3D rekonstrukce. 4.4 Jednotkové testovaní Vývoj byznys vrstvy provázelo od začátku testování správného fungování často používaných součástí. Zejména balíček tools s nástroji bylo nutné důkladně otestovat. Dalšími otesto-
4.4. JEDNOTKOVÉ TESTOVANÍ 25 Obrázek 4.13: Model tříd UI, třídy PMVS a CMVS vanými částmi byl správce stahování obrázků, nástroj pro vyhledávání a třída pro úpravu fotografií. Otestování těchto tříd pomocí unit testů bylo místy poměrně zapeklité, ale vyplatilo se. Není tak potřeba například ručně zkoušet pouštět změnu velikosti fotografie nebo kontrolovat výsledek vyhledávání. Vývoj souběžně s testováním dodává vývojáři mnohem větší jistotu o správném fungování otestovaných součástí a může se tak soustředit na hledání chyb jinde, často právě v neotestovaných místech aplikace. Bohužel některé místa jsou na testování opravdu náročná. Zejména ověření správného fungování částí, které která závisejí na externích programech a jsou pro vývojáře do určité míry černou skřínkou. Dalším problémovou oblastí testování je unit testing uživatelského rozhraní. Přesto pro webová prostředí jsou známy nástroje (např. Selenium), které tuto činnost zpříjemňují. Pro desktopová prostředí, jsem bohužel nenalezl vhodný nástroj. Výhodou je, že ruční testování má zde velmi rychlou zpětnou odezvu, takže je možné změny dělat operativněji.
26 KAPITOLA 4. NÁVRH A REALIZACE
Kapitola 5 Testování 5.1 Experimenty s vlastnoručně nafocenými fotkami Vybral jsem si konvici a umístil na stůl. Konvici jsem nafotil ze všech stran, tak aby se fotky vzájemně překrývaly. V počítači jsem fotky zmenšil na maximálně 1024px v každé straně. Dále jsem přidal informace o optice mého fotoaparátu do souboru extract"_"focal.pl. Bundler, CMVS i PMVS fotky zpracovali bez problému. Zkoušel jsem podobný experiment ještě s houslemi, u kterých jsem ale stál na jednom místě a postupně otáčel houslemi. Rekonstrukce se, ale bohužel nezdařila. Pravděpodobně kvůli tomu, že jsem během otáčení houslemi hýbal s houslemi vůči rigidnímu pozadí příliš moc a tak software bral významné body na houslích za nerigidní a tedy je ze zpracování odstranil. 5.2 Experiment s daty staženými z internetu Zde jsem bohužel neuspěl. Jediné fotky stažené z Flickru, které obsahují EXIF informace jsou totiž fotografie v původní velikosti. Problémem je, že většina uživatelů si původní velikosti Obrázek 5.1: Testování, Čajová konvice 27
28 KAPITOLA 5. TESTOVÁNÍ Obrázek 5.2: Testování, Srní, meshlab fotek zamyká a jsou tak nedostupné ke stažení. Zkoušel jsem stahovat fotografie zachycující Orloj na Staroměstském náměstí, bohužel však výsledná rekonstrukce tvořila jeden dlouhý pruh bodů. 5.3 Experiment s daty od vedoucího BP Fotografie domu jsem nejprve ručně příkazem mogrify zmenšil na velikost 800x600 a poté fotografie otevřel v aplikaci a nechal spustit fázi structure-from-motion. Rekonstrukce umístění kamer a významných bodů se povedla, proto jsem se přepnul do příkazové řádky a spustil ručně fázi MVS. Podařilo se rekonstruova jednu stěnu budovy. 5.4 Experiment s testovacími obrázky z distribuce Bundleru Fotografie jsem bez změn otevřel v aplikaci a spustil 3D rekonstrukci. Poté opět jako u předchozího experimentu jsem ručně provedl druhou fázi.
5.4. EXPERIMENT S TESTOVACÍMI OBRÁZKY Z DISTRIBUCE BUNDLERU 29 Obrázek 5.3: Testování, Srní, fotografie Obrázek 5.4: Testování, Kermit, meshlab
30 KAPITOLA 5. TESTOVÁNÍ Obrázek 5.5: Testování, Kermit, fotografie
Kapitola 6 Závěr Téma 3D rekonstrukce bylo velmi zajímavé a pro mě dříve neutušená oblast počtačové vědy, o kterou s budu pravděpodobně zajímat i v budoucnu. Během analýzy aplikací Bundler a MVS jsem nasbíral také mnoho zkušeností s kompilováním těchto aplikací. Odhalil jsem také některé chyby v původním kódu, které bránily spuštění. Vývoj aplikace provázela místy překvapení, jak některé části fungují proti mým očekáváním. Zejména u nástroje pro stahování obrázků z Flickru bylo nemilé překvapení, že potřebné EXIF informace s sebou nesou pouze orignální verze fotografií (nikoli ty zmenšené), což si vyžádalo nepříliš elegantní opravu, která nyní stahování fotek trochu zdržuje. Bohužel se mi nepodařilo stihnout implementovat část zajišťující MVS rekonstrukci, proto jsem tyto části zatím prováděl ručně pomocí příkazové řádky. Řešení se mi bohužel nepodařilo otestovat na sadách stažených z internetu, protože snímky často neobsahovaly potřebné EXIF informace nebo se jich mnoho nepodařilo stáhnout a aplikace tak neměla dostatek fotografií pro rekonstrukci. Nicméně aplikaci se podařilo úspěšně spustit na vzorovém příkladu z původní distribuce Bundleru a na množině fotek Srní dodané vedoucím práce. Architektura aplikace byla navržena s ohledem na modularitu závislých aplikací a na možnou budoucí rozšířitelnost dalších vyhledávačů obrázků. Práci by v budoucnu mohlo být dobré vylepšít tak aby dokázala přes síť spolupracovat s dalšími instalacemi této aplikace a spolupracovat tak na paralelním zpracování 3D rekonstrukce. 31
32 KAPITOLA 6. ZÁVĚR
Příloha A Seznam literatury Ambler, Scott W. The Object Primer - third edition, Cambridge university press, ISBN - 10 0-521-54018-6 Agarwal; Furukawa; Snavely; Curless; Sietz; Szeliski; Reconstructing Rome, IEEE Computer Society Goesele; Ackermann; Fuhrmann; Klowskz; Langguth; Mucke; Scene Reconstruction From Community Photo Collections, IEEE Computer Society 33
34 PŘÍLOHA A. SEZNAM LITERATURY
Příloha B Seznam použitých zkratek SIFT Scale-invariant feature transform DoG Difference of Gaussians SFM Structure from motion PMVS Patch based multi-view stereo CMVS Clustering views for multi-view stereo KNN K-Nearest Neighbors algorithm API Aplication Programming Interface SOAP Simle Object Access Protocol XML-RPC Remote procedure call based on XML JSON JavaScript Object Notation PHP PHP: Hypertext Processor REST Representational State Transfer GPS Global position system URL Uniform resource locator. 35
36 PŘÍLOHA B. SEZNAM POUŽITÝCH ZKRATEK
Příloha C UML diagramy Obrázek C.1: Analýza, Vztahy mezi soubory, které zpracovává Bundler 37
38 PŘÍLOHA C. UML DIAGRAMY Obrázek C.2: Analýza, Závislosti Bundleru Obrázek C.3: Analýza, Závislosti CMVS
39 Obrázek C.4: Analýza, Závislosti PMVS Obrázek C.5: Případy užití, hlavní
40 PŘÍLOHA C. UML DIAGRAMY Obrázek C.6: Případy užití, stahování Obrázek C.7: Případy užití, multi-view-stereo
41 Obrázek C.8: Případy užití, výběr fotek Obrázek C.9: Případy užití, vyhledávání
42 PŘÍLOHA C. UML DIAGRAMY Obrázek C.10: Případy užití, structure from motion
Příloha D Instalační a uživatelská příručka D.1 Instalace Aplikace je prozatím otestovaná pouze na opearčním systému Linux Ubuntu 10.10 (32b). Pro úspěšný běh aplikace je potřeba provést následující příkaz. Slovo HOME vyjadřuje adresář kde je aplikace nainstalována. sudo apt-get install liblapack3gf sudo cp HOME/lib/libANN_char.so /usr/local/lib sudo ldconfig /usr/local/lib D.2 Popis obrazovek Organizace uživatelského rozhrání vychází z nezávislosti jednotlivých dílčích aplikací. Každá z částí může být použita nezávisle na ostatních. Například je možné použít program jen na stažení fotek, případně rovnou přeskočit ke generování pomocí MVS pokud máme vstup již připraven odjinud. Proto jsem zvolil navigaci ve formě záložek. Navigace bude vždy viditelná v horní části okna aplikace. Podle zvolené záložky se načte odpovídající uživatelské rozhraní do prostoru epicentra aplikace. D.2.1 Dashboard Dovede uživatele provést výběrem skupiny fotek, která se později použije pro generování 3D modelu. Nejjednodušší možnost je vybrat některou složku na disku. Další možností je najít fotky na internetu (např. na Flickru) a vhodné fotky uložit na disk. Pro usnadnění používání aplikace umožňuje vybrat přímo některé z nedávno použitých klíčových slov, nebo některou z posledně použitých složek. D.2.2 Search query Umožňuje nastavit žádaná klíčová slova, gps souřadnice, omezení data podle kterých se budou fotky vyhledávat. Lze také nastavit zda rovnou při stahování provést SIFT algoritmus a změnu velikosti fotografie. 43
44 PŘÍLOHA D. INSTALAČNÍ A UŽIVATELSKÁ PŘÍRUČKA Obrázek D.1: UI, Dashboard Obrázek D.2: UI, Search query
D.2. POPIS OBRAZOVEK 45 Obrázek D.3: UI, Search results D.2.3 Search results Jakmile aplikace dostane odpověď od serveru, na kterém se fotky hledaly, zobrazí náhledy obrázků. Počet vrácených obrázků na dotaz lze upravit roletkou nahoře. Hned vedle roletky je tlačítko umožňující uživateli vrátit se zpět k zadání/upřesnění vyhledávacího dotazu. Všechny vypsané obrázky jsou standartně označeny ke stažení. Kliknutím na náhled obrázku bude dříve určený obrázek ke stažení ze stažení vyjmut. Opětovným kliknutím pak lze obrázek opět zařadit mezi stahované. Stažení a vrácení dalších výsledků na dotaz je sloučeno pro uživatele do jednoho tlačítka uplně dole. Napravo je přehled právě stahovaných nebo stažených obrázků. D.2.4 Download Uživatel zde může sledovat stav stahovaných obrázků. D.2.5 SFM Setup Před spuštěním samotného structure-from-motion programu Bundler je potřeba upřesnit složku s obrázky, které bude Bundler zpracovávat. Toto je nutné nastavit pouze pokud uživatel přeskočil sekci Pick Photos (předchozí záložka). Pokud uživatel souhlasí aplikace vyčistí složku a nechá tam jen obrázky. Poslední důležitou částí je prostor pro úpravu parametrů, které se předávají programu Bundler při spuštění - zde lze upravit libovolný argument, který Bundler přijímá.
46 PŘÍLOHA D. INSTALAČNÍ A UŽIVATELSKÁ PŘÍRUČKA Obrázek D.4: UI, Download progress Obrázek D.5: UI, SFM setup
D.2. POPIS OBRAZOVEK 47 Obrázek D.6: UI, SFM running D.2.6 SFM running Obrazovka informuje uživatele o provedených úkonech a o aktuálním průběhu zpracování fotek. Uživatel má možnost proces zastavit a vrátit se k předchozímu kroku nastavení. Po dokončení práce Bundleru se úplně dole pod výpisem průběhu prací aktivují tlačítka - první nalevo pro otevření adresáře s výsledky a druhé napravo pro přesun k dalšímu kroku (MVS). D.2.7 MVS V případě, že uživatel nezpracovával fotky pomocí sekce SFM, pak musí upřesnit adresář s výsledky zpracování fotek přes Bundler. Další části obrazovky obsahují výchozí nastavení parametrů pro programy CMVS a PMVS (potažmo genoption, který připravuje dávku příkazů využívající PMVS). D.2.8 Settings Sekce sloužící pro definování výchozích voleb používaných v aplikaci. Například cesty k programům Bundler, PMVS, CMVS, detektoru významných bodů.
48 PŘÍLOHA D. INSTALAČNÍ A UŽIVATELSKÁ PŘÍRUČKA Obrázek D.7: UI, MVS Obrázek D.8: UI, Settings