Fotos am Beispiel der Notre Dame

(1)

Erzeugung synthetischer

Trainingsdaten für die Deep

Learning basierte Bestimmung von GPS-Koordinaten aus

Fotos am Beispiel der Notre Dame

FAKULTÄT TECHNIK UND INFORMATIK Department Informatik

Faculty of Computer Science and Engineering Department Computer Science

Betreuung durch: Prof. Dr. Kai von Luck Eingereicht am: 30. September 2020

(2)

Inhaltsverzeichnis

1 Einleitung 1

1.1 Ziel der Arbeit . . . 2

1.2 Aufbau . . . 2

2 Problemanalyse 3 2.1 Qualität der realen Trainingsdaten . . . 3

2.2 Synthetische Datengenerierung . . . 4

2.2.1 Domain Randomization (DR) . . . 4

2.2.2 NVIDIA Deep Learning Dataset Synthesizer (NDDS) . . . 5

2.2.3 Datensatz: Falling Things Datensatz (FAT) und eigener Datensatz 5 3 Durchführung 7 3.1 Erzeugung eines synthetischen Datensatzes . . . 7

3.1.1 3D-Modell . . . 7

3.1.2 Koordinatensystem . . . 7

3.1.3 Synthese-Aufbau . . . 9

3.1.4 S2-Zellen Integration in das Koordinatensystem . . . 11

3.2 Integration in die bestehende Pipeline . . . 12

3.2.1 Koordinaten-Import . . . 12

3.2.2 Datenverteilung . . . 14

3.3 Training . . . 16

3.4 Exemplarisches Testen . . . 17

4 Ergebnisdiskussion 18 4.1 Datenverteilung . . . 18

4.2 Training . . . 19

4.3 Tests der trainierten Modelle . . . 21

4.4 Fazit . . . 22

4.5 Ausblick . . . 23

5 Anhang 24

Literatur 31

(3)

In dieser Arbeit wird ein synthetischer Datensatz für das Trainieren eines neuronalen Netzes zur Bestimmung von GPS-Koordinaten aus Fotos anhand der Pixel erzeugt. Basierend auf ein 3D-Modell der KathedraleNotre Dame in Paris wird mit der Spiel-EngineUnreal Engine 4 ein Trainings-Datensatz erzeugt und in eine für diese Arbeit erweiterte Pipeline für die Bestimmung der GPS-Koordinaten integriert. Durch den gezielt synthetisch erzeugten Trai- ningsdatensatz soll die Fehlerhaftigkeit der realen Trainings-Fotos aus dem vorangegangenen Projekt ausgeglichen werden.

1 Einleitung

Wenn mit Deep Learning Algorithmen gearbeitet wird, um Vorhersagen über bestimmte Daten treﬀen zu können, ist einer der substantiellsten Faktoren die Qualität der Daten, mit denen das Modell trainiert wird [3]. In dem dieser Arbeit vorausgehenden Projekt [5] wurde eine Pipeline zum Trainieren von neuronalen Netzen aufgebaut, mit denen Geo-Koordinaten von Fotos nur auf Grundlage der Pixel bestimmt werden sollen. In An- lehnung an [15] wurde ein Klassiﬁkator entwickelt, der ausschließlich mit „geogetaggten“

realen Fotos der Notre Dame in Paris trainiert wurde. Der aus ca. 35.000 Bildern bestehende Trainingsdatensatz wurde mithilfe derFlickr-API erzeugt. Mit diesem Datensatz sollte überprüft werden, ob die Qualität der Fotos ohne aufwändige Nachbearbeitung für ein erfolgreiches Training ausreichen würde. Mehrere Gründe führten jedoch dazu, dass sich das Netz kaum an die Trainingsdaten anpassen konnte und der Datensatz faktisch unbrauchbar ist. Laut Gudivada et al. gibt es einige Mechanismen, wie im Big Data Kontext Datensätze aufbereitet werden können, was das Training insgesamt allerdings zu einer sehr komplexen und aufwändigen Angelegenheit macht [1]. Besonders bei der Objekterkennung haben viele Faktoren wie die Komposition, Belichtung, Abstand der Objekte zur Kamera etc. großen Einﬂuss auf die Erkennungsrate und müssen manuell erarbeitet und markiert werden [7].

Tremblay et al. [13] begegnen diesem Problem mit der Erstellung synthetischer Daten, bei der durch gezielte Randomisierung der variablen Eigenschaften eines realen Szenari- os synthetische Trainingsfotos erzeugt und trainiert werden. Durch dieses Vorgehen soll das Netz gezwungen werden, sich auf die wesentlichen Eigenschaften des zu erkennenden Objektes zu beschränken.

(4)

1 Einleitung

1.1 Ziel der Arbeit

Im Zuge dieser Arbeit soll mithilfe der Spiele-Engine Unreal Engine¹ ein synthetischer Datensatz in Anlehnung an [13] speziell für das Training der Notre Dame Kathedrale erstellt und in die Pipeline zur Erkennung von Geodaten aus Fotos aus dem vorangehenden Projekt [5] integriert werden. Die Pipeline wird dafür so erweitert, dass sowohl synthetische als auch reale Daten erzeugt, aufbereitet und trainiert werden können. Um sich einen Vorteil gegenüber der arbeitsintensiven Verarbeitung realer Daten zu verschaﬀen, ist die Motivation hierbei, den Datensatz möglichst einfach halten zu können, um die Erstellung auch potenziell für weitere Objekte in Betracht ziehen zu können. Abschlie- ßend sollen beide Vorgehensweisen verglichen und eine Einschätzung gegeben werden, inwieweit die Vorgehensweise für die Problemstellung der Ortsbestimmung von Fotos für weitere Arbeiten behilﬂich sein kann.

1.2 Aufbau

Zuerst werden in der Problemanalyse die Ergebnisse und damit die noch offenen Heraus- forderungen der vorangegangenen Arbeit [5] aufgegriffen. Am Beispiel der Arbeiten von Tremblay et al. [13] wird das Konzept der Datensynthetisierung erläutert und theoretisch auf die aktuelle Fragestellung angewandt. In der Durchführung wird beschrieben, wie die synthetischen Fotos des Notre Dame erstellt wurden und welche Anpassungen an die bestehende Pipeline nötig waren. Abschließend werden die Ergebnisse präsentiert, bewertet und Möglichkeiten zur Fortführung dieser Fragestellung skizziert, die dieses Projekt für folgende Arbeiten eröffnet.

1https://www.unrealengine.com/, 19.09.20

(5)

2 Problemanalyse

Dieses Kapitel behandelt die Herausforderungen, die sich beim Trainieren von Fotos für neuronale Netze ergeben. Es wird insbesondere auf die vorausgehende Arbeit eingegangen und mit dem Synthetisieren eines eigenen Datensatzes eine weiterführende Vorgehens- weise präsentiert.

2.1 Qualität der realen Trainingsdaten

In [5] wurde ein Mehrklassen-Klassiﬁzierungsmodell in Anlehnung an Weyand et al. [15]

auf Basis eines Flickr-Datensatzes von mit Geo-Tags versehenen User-Fotos der Notre Dame trainiert. Wie dem Ergebnis der Arbeit entnommen werden kann, ist die Aufteilung der Fotos auf die mit der S2 Geometry Library² vordeﬁnierten Klassen im Umkreis von ca. 4 km um die Notre Dame herum äußerst ungleich (siehe Abbildung 1). Die Nutzung des S2-Level 18 ergibt schließlich 910 Klassen mit einer Zellengröße³ von ca. 900m².

(a) Verteilung der realen Fotos im Umkreis von ca. 4 km

(b) Darstellung der Verteilung als Balkendiagramm.

Ein Balken entspricht einer Klasse. y-Achse: An- zahl der Fotos.

Abbildung 1: Verteilung der realen Testdaten. x-Achse: Längengrad, y-Achse: Breitengrad.

Mit dem in [5] verwendeten Quad-Tree-Verfahren⁴ wurde durch eine dynamische Zel- leneinteilung auf Basis der Anzahl von Fotos die Anzahl der Klassen auf 111 begrenzt.

Zellen mit weniger als 20 Fotos wurden aus dem Datensatz entfernt. Bei einem Datensatz mit 32.559 Fotos konnte mit diesem Verfahren allerdings nur eine Validierungsgenauig- keit von 7,47 % erreicht werden. Als hauptsächliche Fehlerquelle konnte der Inhalt der Flickr-Fotos identiﬁziert werden: Neben zahlreichen Fotos, die zwar mit dem Titel „Notre

2S2 Geometry Library: https://s2geometry.io/ (Letzter Zugriﬀ: 18.01.20)

3https://s2geometry.io/resources/s2cell_statistics, 16.09.20

4Quad-Tree Wikipedia Artikel: https://de.wikipedia.org/wiki/Quadtree (Letzter Zugriﬀ: 04.09.2020)

(6)

2 Problemanalyse

Dame“ getaggt wurden, jedoch andere Motive wie Pﬂanzen, Personen oder diverse Ge- bäude und Gegenstände in der Nähe zeigten, ist ein großer Teil der Geodaten inkorrekt.

Eine Vielzahl der getaggten Koordinaten repräsentieren den Mittelpunkt der Kirche, der vermutlich in vielen Fällen als Standard gesetzt wurde, wenn die Geodaten nicht auto- matisch ermittelt werden konnten. Den Großteil machen jedoch Innenaufnahmen aus, die für dieses Training ignoriert werden sollen, da sich diese Arbeit auf die Außenaufnah- men konzentrieren soll. Dementsprechend müssen diese Fotos aus dem Trainingsdatensatz entfernt werden, wofür entweder hoher manueller Aufwand oder Algorithmen zur Unter- scheidung von Innen- und Außenaufnahmen notwendig wären. Abbildungen 12 und 14 im Anhang gewähren hier einen kleinen Einblick, welche Trainingsfotos sich innerhalb in einer Klasse beﬁnden.

In dieser Arbeit soll demzufolge ein eigener synthetischer Datensatz erzeugt werden, um ein von externen Störfaktoren unabhängiges Training zu ermöglichen. In dem Zusam- menhang soll das bisher verwendete neuronale Netz und die Anzahl der Klassen sowie die Datenverteilung kritisch hinterfragt und in Hinblick auf bessere Ergebnisse angepasst werden.

2.2 Synthetische Datengenerierung

Für die Erzeugung des synthetischen Trainingsdatensatzes orientiert sich dieses Projekt an der Arbeit von Tremblay et al. [13], in der die Autoren eine neuronale Netzarchitek- tur auf Basis synthetischer Daten trainieren, um die Position und Lage im Raum von verschiedenen Haushaltsgegenständen - also die Objekt-Pose - innerhalb eines einzigen Bildes zu bestimmen. Die Erkennung wird schließlich für einen Roboter genutzt, der die trainierten Haushaltsgegenstände in der Realität in Echtzeit erkennen und greifen kön- nen soll. Damit unterscheidet sich der Anwendungsfall in großen Teilen von dem dieser Arbeit. Es soll hier deshalb nicht auf die Details eingegangen, sondern sich die Methodik der Datenerzeugung zunutze gemacht und überprüft werden, inwiefern sie sich auf den Anwendungsfall dieser Arbeit übertragen lässt.

2.2.1 Domain Randomization (DR)

Tremblay et al. [13] weisen auf einige vorausgehende Arbeiten hin, bei denen eine große Problematik der hohe Aufwand beim Annotieren realer Trainingsdaten war. Die dazu- gehörigen Testdaten ähnelten sich aufgrund der Nutzung gleicher Kameras, Objekte,

(7)

Lichtverhältnisse etc. stark, wodurch das Netz nur bedingt - nämlich bezüglich der Test- daten - generalisieren konnte. Aus diesem Grund verweisen sie auf die von Tobin et al.

[12] eingeführte Domain Randomization. Bei diesem Verfahren wird ein synthetischer Datensatz mit zufälliger Anzahl und Anordnung von verdeckenden Objekten, Texturen, Position und Orientierung von Kamera und zu trainierenden Objekten sowie wechseln- den Hintergründen und Lichtverhältnissen bei bewusst niedrig gehaltener Genauigkeit erzeugt. Somit lässt sich in relativ kurzer Zeit eine enorme variable Datenmenge pro- duzieren, wodurch das trainierte Modell besser gegenüber realen Daten generalisieren kann. Dies soll letztendlich dazu beitragen, den sogenannten Reality Gap [4], die Lücke zwischen Simulation und Realität, zu schließen.

2.2.2 NVIDIA Deep Learning Dataset Synthesizer (NDDS)

Der NVIDIA Deep Learning Dataset Synthesizer (NDDS) ist ein von Thang et al. [11]

für NVIDIA entwickelter Simulator in Form eines Plugins für die Unreal Engine zur Ge- nerierung synthetischer Daten nach dem Prinzip der Domain Randomization voranging für das in [13] vorgestellte Projekt zur Erkennung von Position und Pose von Objekten.

Dieses Plugin ermöglicht es, innerhalb einer Szene in der Unreal Engine beliebig viele Objekte zu platzieren und dann dessen Position, Lage und Aussehen (durch z.B. Aus- tauschen der Texturen und Verändern von Lichtverhältnissen) zufällig zu verändern. Dies können sowohl Objekte sein, die vom neuronalen Netz trainiert werden sollen als auch verdeckende Störobjekte, sogenannte Distraktoren. Zusätzlich lassen sich Kamerabewe- gungen deﬁnieren, sodass diese sich beispielsweise entlang eines vorgegebenen Pfades oder sich willkürlich innerhalb einer deﬁnierten Region bewegt. Mit der Exportfunktion werden während der Simulation Screenshots des Kamerabildes als png-Dateien exportiert, zu denen zusätzliche Exportbilder optional Tiefeninformationen, Segmentierungen oderBounding Boxes⁵ enthalten können. In einer JSON-Datei werden pro exportiertem Bild Metainformationen wie die Position der Objekte und Kamera und diverse weitere Einstellungen innerhalb der Szene festgehalten.

2.2.3 Datensatz: Falling Things Datensatz (FAT) und eigener Datensatz Wie ein mit dem NDDS-Plugin erstellter Datensatz aussehen kann, zeigt der Falling Things (FAT) [14] Datensatz, der gewöhnliche Haushaltsgegenstände sowohl nach dem

5Bounding Box: Ein Rechteck zum Einrahmen eines Objekts

(8)

2 Problemanalyse

soeben beschriebenen Domain Randomization Prinzip als auch fotorealistische Umgebun- gen in verschiedenen Szenen mit je unterschiedlicher Anordnung von Objekten enthält.

In diesem Projekt soll der FAT-Datensatz nur grob als Orientierung dienen, da hier versucht werden soll, mit einem durch minimalem Aufwand erstellten Datensatz ein zeitlich effizientes Training zur Bestimmung der Geodaten zu erreichen. Statt einer Auswahl an Objekten soll hier nur ein Objekt (die Notre Dame) trainiert werden, wodurch die vari- ierende Anzahl und Komposition von Objekten entfällt. Da die Notre Dame zusätzlich geografisch an einem statischen Ort gebunden ist, entfallen die zufällige Beweglichkeit des zu annotierenden Objektes und intuitiv auch die Generierung unterschiedlicher fotorealis- tischer Umgebungen. Stattdessen sollten sich die synthetischen Bilder auf die Umgebung aus touristischer Perspektive konzentrieren. Im FAT-Datensatz wurden zudem fünf unterschiedliche Positionen für einen kleinen Bereich, in dem sich die Kamera bewegen kann, definiert - hier soll sie sich allerdings vollständig um das Bauwerk herum bewegen können.

Da nach [5] die Geopositionen mit einem Klassiﬁkator bestimmt werden und die geograﬁ- sche Umgebung deshalb mit der S2 Geometry Library in ein Raster eingeteilt wurde, bei dem jede Zelle einer zu trainierenden Klasse entspricht, soll es auch dementsprechend viele Kamerapositionen geben. Zuletzt soll der hier erstellte Datensatz vorerst ohne Export von Bounding Boxes, Segmentierung und Tiefeninformation arbeiten, da als Zielwerte keine Posen oder Positionen des Objektes auf dem Bild, sondern Geo-Zellen verwendet werden. Durch die reine Generierung synthetischer Momentaufnahmen mit der Hinzu- nahme von Distraktoren soll eine Vergleichbarkeit zu realen Fotos erzeugt werden.

(9)

3 Durchführung

In diesem Abschnitt wird im Kontext der Erstellung eines eigenen synthetischen Daten- satzes das NDDS-Plugin näher beschrieben und einige Probleme diskutiert, welche sich bei der Integration in die bestehende Pipeline ergaben. Um die Nützlichkeit des Daten- satzes zu ergründen, wird ein Vergleich mit den realen Daten angestrebt und dafür eine Vergleichbarkeit erzeugt, die im Ergebnisteil in Abschnitt 4 diskutiert wird.

3.1 Erzeugung eines synthetischen Datensatzes

Für die Erzeugung des synthetischen Datensatzes wurde der in Abschnitt 2.2.2 beschrie- bene NVIDIA Deep Learning Dataset Synthesizer genutzt. Dieses Plugin wird in die Unreal Engine 4.22 installiert und bietet einige Tools für das Organisieren und Verän- dern von graﬁschen Objekten und virtuellen Kameras.

3.1.1 3D-Modell

Für die Erzeugung der Fotos wurde zuerst auf diversen Marktplätzen für 3D-Computer- graﬁken im Internet nach einem qualitativ angemessenem und mit der Unreal Engine kompatiblem Modell der Notre Dame gesucht. Letztendlich wurde auf dem Webportal Turbosquid⁶ ein für diesen Einsatzvorerst ausreichendes⁷ Modell⁸ erworben und in die Unreal Engine (ab hier mit „UE4“ abgekürzt) importiert.

3.1.2 Koordinatensystem

UE4 arbeitet mit einem eigenen Koordinatensystem, dessen Einheit „Unreal Unit (UU)“

standardmäßig einem Zentimeter entspricht. Alle Objekte und Kameras werden innerhalb dieses Koordinatensystems - dem „Welt-Koordinatensystem“ - angeordnet, deren

6https://turbosquid.com - Eines der größten Webportale zum Vertrieb von 3D-Modellen für 3D- Computergraﬁk, 09.09.2020

7Die Bewertung des 3D-Modells mit „vorerst ausreichend“ basiert auf der Grundlage des aktuellen eigenen Wissensstandes. An dieser Stelle soll oﬀen bleiben, ob sich bei einer späteren detaillierten Analyse der trainierten Features des neuronalen Netzes herausstellt, dass das Modell über ungenügende De- tails verfügt und somit nicht zu zufriedenstellenden Ergebnissen führt.

8https://www.turbosquid.com/FullPreview/Index.cfm/ID/959011, 09.09.2020

(10)

3 Durchführung

Positionen mit der x-, y- und z-Achse bestimmt werden. Um die zu exportierenden Bil- der für das spätere Training labeln zu können, bedarf es eines geograﬁschen Referenz- punktes innerhalb dieses Koordinatensystems, weshalb das 3D-Modell der Notre Dame als Mittelpunkt der Szene mit den Koordinaten x=0, y=0, z=0 festgelegt wurde. Als Mittelpunkt des 3D-Modells wiederum wurde der Kirchturm des Mittelschiﬀes gewählt und das Modell dementsprechend platziert (Abbildung 2).

(a) Markierter Punkt in Google Maps dient als Referenz-Koordinate

(b) Referenz-Koordinate als Nullpunkt im UE4 Koordinatensystem (Draufsicht)

Abbildung 2: Wahl und Positionierung des Notre Dame Mittelpunkts in UE4

Von diesem Punkt ausgehend soll schließlich die Kamera platziert werden, sodass bei der Annotation der exportierten Bilder der jeweilige Abstand der Kamera zum Gebäude gemessen und daraus schließlich die entsprechenden GPS-Koordinaten berechnet werden können.

Um die Optik bei der Generierung von Fotos den realen räumlichen Verhältnissen an- zupassen und die spätere Umrechnung der UU-Koordinaten in Längen- und Breitengrad zu vereinfachen, sollten sowohl die reale Größe der Notre Dame als auch die Rotation im Raum angepasst werden. Als Hilfe diente OpenStreetMap-Kartenmaterial aus einem Umkreis von ca. 700 m um die Notre Dame herum, das über die Exportfunktion der OpenStreetMap-Website⁹ beschaﬀt wurde. Das Kartenmaterial wird im OSM-Format zur Verfügung gestellt, das sich über dasStreet Map Plugin for UE4¹⁰ in die UE4 Szene importieren lässt. Das Plugin unterstützt derzeit Straßen und Gebäudeumrisse, sodass die Umgebung in originaler Größe in sehr vereinfachter Form dargestellt werden kann.

9OpenStreetMap Kartenausschnitt um die Notre Dame:

https://www.openstreetmap.org/export#map=17/48.85306/2.34998, 10.09.20

10https://github.com/keru1264/StreetMap, 10.09.20

(11)

Dadurch ließ sich das Notre Dame 3D-Modell exakt auf die richtige Position platzieren, sodass im weiteren Verlauf die Geodaten korrekt berechnet werden können (siehe Abbildung 4).

3.1.3 Synthese-Aufbau

In diesem Abschnitt wird die Nutzung einiger Module des NDDS-Plugins beschrieben.

Hier wird allerdings nicht ins Detail gegangen und auch auf eine Beschreibung der Unreal Engine wird verzichtet, da beides den Rahmen dieser Arbeit sprengen würde. Für weitere Details sei hier auf die Dokumentation des NDDS-Plugins¹¹ sowie der Unreal Engine¹² verwiesen.

SceneCapturer Die Hauptkomponente des Szenen-Aufbaus stellen die SceneCaptur- er-Actors dar. Ein SceneCapturer simuliert die verwendete Kamera und erzeugt die ge- wünschten Fotos durch den Export von Screenshots. Durch zusätzliche Komponenten werden mit dem SceneCapturer sowohl Bewegung als auch Blickfokus konﬁguriert. Der RandomMovement Komponente wird ein Volume - ein dreidimensionales Rechteck, in dem sich die Kamera bewegen darf - zugewiesen und dann so konﬁguriert, dass die Ka- mera pro Frame eine zufällige neue Position innerhalb des Volumes einnimmt. Mit der RandomLookAt Komponente wird der Blick der Kamera auf das Notre Dame Modell fokussiert und durch einen zusätzlich an der Spitze des Modells angebrachten Dummy- Actor die Ausrichtung etwas variiert.

Tabelle 1 zeigt einige der vorgenommenen Einstellungen:

Tabelle 1: Exemplarischer Auszug aus einer Komponenten-Konfiguration

Komponente Parameter Wert

SceneCapturer Location (x,y,z) in UU (10450,5920,180) SceneCapturer Max Number Of Frames To Export 5000

SceneCapturer CapturedImageSize 256x256 px

RandomMovement RandomLocationVolume CameraVolume_front

RandomMovement Should Teleport True

RandomLookAt Focal Target Actors NotreDameModel, NotreDameTop RamdomLookAt RotationSpeed (in degree per second) 29

11https://github.com/NVIDIA/Dataset_Synthesizer/blob/master/Documentation/NDDS.pdf, 12.09.20

12https://docs.unrealengine.com/en-US/GettingStarted, 12.09.20

(12)

3 Durchführung

Insgesamt wurden vier SceneCapturer (front, back, left, right) mit den dazugehörigen Volumes auf Personenhöhe platziert, sodass die Notre Dame von jeder Seite getrennt

„fotograﬁert“ werden konnte (innere vier Rechtecke in Abbildung 2b). Eine zusätzliche Einstellung im SceneCapturer verhindert, dass die Kamera mit dem 3D-Modell kollidieren kann. Dadurch wird versucht, ein virtuelles Szenario zu erstellen, das sich an Ort und Blickwinkel von Touristenfotos orientiert.

Distraktoren Um Objekte, die gelegentlich die direkte Sicht auf die Notre Dame ver- sperren, sogenannte Distraktoren, in die Fotos zu integrieren, wurde ein großes das 3D- Modell überlagerndes Volume angelegt (äußeres großes Rechteck in Abbildung 2b). Über den DistractorManager¹³ können Anzahl, Typ und Aussehen von Objekten sowie deren Positionen und Bewegungen bestimmt werden. Hier wurden vorerst die im Plugin mit- gelieferten Standardformen (Zylinder, Dreieck etc.) mit unterschiedlichen Farben, Po- sitionen und Rotation genutzt, von denen aktuell 40 bis 60 Instanzen vor jeder Seite des 3D-Modells erzeugt werden (Abbildung 3). Ziel der Distraktoren ist, mit minimalem Aufwand Personen, Autos und weiteren Verdeckungen, die auf realen Fotos vorhanden sein können, zu ersetzen, um das Training robuster und weniger störanfällig dagegen zu machen.

Abbildung 3: Distraktoren verdecken die freie Sicht und werfen Schatten

13Neben dem DistractorManager existiert auch der GroupActorManager, der für die randomisierte Er- scheinung der zu trainierenden Objekte genutzt wird. Dieser hat hier allerdings keine Funktion, da die Notre Dame statisch in die Szene eingebunden wurde, und wird deshalb nicht näher beschrieben.

(13)

Lichtverhältnisse Es wurden zwei randomisierte direkte Lichtquellen des Plugins ein- gesetzt, um die Beleuchtung der Notre Dame variabel zu machen. Da dies zu einem sehr hohen Kontrast zwischen hell und dunkel führte, wurde mit drei direkten Lichtquellen eine Grundhelligkeit hinzugefügt.

Zufälliger Hintergrund Mit dem RandomBackgroundActor wird der Hintergrund durch eine Vielzahl zufälliger Bilder aus dem COCO-Datensatz¹⁴entnommen. Die Wahl dieses Datensatzes hatte keine besonderen Gründe, hier können auch diverse andere verwendet werden. Mit dem Austauschen der Hintergründe soll das neuronale Netz beim Training gezwungen werden, sich auf den wesentlichen Inhalt des Fotos - die Notre Dame - zu konzentrieren. Sie soll das einzige Objekt sein, das wiederkehrend auf jedem Foto zu ﬁnden ist.

Eine Auswahl von Beispielen beﬁndet sich im Anhang in Abbildung 11, in der exportierte Fotos von allen Seiten gezeigt werden.

3.1.4 S2-Zellen Integration in das Koordinatensystem

Wie in der Problemanalyse bereits dargestellt, ist die Verteilung der Trainingsdaten beim Training des neuronalen Netzes mit realen Daten eine große Herausforderung. Ein Ziel der synthetischen Datenerzeugung soll sein, die Verteilung der generierten Fotos voll- ständig kontrollieren zu können. Für die Weiterentwicklung der in [5] vorstellten Pipeline bedeutet das, dass die dort als Zielklassen fungierenden S2-Zellen möglichst gleichmäßig mit Fotos versorgt werden müssen. Wünschenswert wäre somit, die Kamerapositionen gezielt auf die Positionen der gewünschten Zellen positionieren zu können. Damit ließe sich eine Vielzahl diverser Datensätze für unterschiedliche Anwendungsfälle erstellen.

Eine Idee für die Umsetzung war, die vorhandenen S2-Zellen aus dem vordeﬁnierten Notre Dame Areal mit den jeweiligen Bounding Boxes¹⁵ als GeoJson¹⁶-Datei zu expor- tieren und ein C++-Skript für den Import der Zell-Koordinaten in UE4 zu schreiben, damit diese dann automatisiert als Volumes in die Szene integriert werden. Aufgrund des problematischen Kosten-Nutzen-Verhältnisses dieser Vorgehensweise wurde sich schließ- lich für eine pragmatischere visuelle Lösung entschieden:

14Speziell für Objekterkennungsaufgaben erstellter Datensatz: https://cocodataset.org/, 12.09.20

15In diesem Fall die Geopositionen der Kanten der S2-Zellen

16https://geojson.org, 14.09.20

(14)

3 Durchführung

In JOSM¹⁷, einem in Java geschriebenen Editor für OpenStreetMap-Karten, wurden das Notre Dame Areal als OSM-Datei und das S2-Raster als GeoJson Datei importiert, sodass das Raster als zweite Ebene über dem Kartenmaterial angezeigt werden konnte.

Innerhalb des Editors wurde das Raster als Straßenebene deﬁniert, in das Kartenmaterial integriert und als OSM-Datei exportiert. Diese Datei ließ sich schließlich wieder mit dem Street Map Plugin for UE4 importieren, sodass das S2-Raster als Mesh¹⁸ dargestellt werden kann. Dies eröﬀnete die Möglichkeit, die Kamera-Volumes optisch an die Zellen anzuordnen und damit Fotos gezielt zu erstellen (vgl. Abbildung 4).

(a) Draufsicht mit S2-Zellen Raster des realen Daten- satzes (gelbe Markierung)

(b) Perspektivische Ansicht

Abbildung 4: Notre Dame Szene mit eingeblendeter OpenStreetMap Umgebung und S2-Zellen- Raster in UE4.

3.2 Integration in die bestehende Pipeline

3.2.1 Koordinaten-Import

Das NDDS-Plugin exportiert die Metadaten der synthetisierten Bilder in einer JSON- Datei pro Bild. Innerhalb der JSON-Datei werden unter anderem die Positions- und Rotationsdaten der zu annotierenden Objekte angegeben. Da es sich hier nur um ein Objekt von Interesse handelt, dieses jedoch im Nullpunkt¹⁹ liegt, wurden diese Informa- tionsausgabe nicht aktiviert. Stattdessen sind hier die Positionsdaten der Kamera von Interesse, sodass die Pipeline um einen JSON-Parser für dessen x-, y- und z-Koordinaten

17https://josm.openstreetmap.de/, 14.09.20

18Aus einem Satz von Polygonen bestehendes Geometrie-Objekt in UE4:

https://docs.unrealengine.com/en-US/Engine/Content/Types/StaticMeshes/index.html, 14.09.20

19x-, y- und z-Wert Triple: (0, 0, 0)

(15)

erweitert wurde. Die importierten Koordinaten liegen im UU-Format vor und entspre- chen daher dem Abstand der Kamera zum Mittelpunkt des Notre Dame 3D-Modells in Zentimetern.

Die Python-Anwendung der zu erweiternden Pipeline wurde um einen Konverter der Kameraposition erweitert. Dafür wurde der Notre Dame Nullpunkt als Referenzwert im UTM²⁰ Format deﬁniert. Im UTM-Koordinatensystem wird die Erde in vertikale Zonen eingeteilt, deren Berechnung jeweils in einem eigenen kartesischen Koordinatensystem durchgeführt werden. Eine Koordinate wird hier mit einem Nord- und einem Ost-Wert in Meter beschrieben. Dies ermöglicht eine einfache Addition der aus UE4 importierten UU- Werte auf die UTM-Referenzwerte. Mit der Proj-Bibliothek²¹ für Python können UTM Werte in Längen- und Breitengrade und zurück umgewandelt werden. Als Referenzwert für die Notre Dame wurde 48.85306^◦ als Breiten- und 2.349976^◦ als Längengrad genutzt, was im UTM-Format dem Ostwert 452316 m und dem Nordwert 5411325 m in der Zone 31U entspricht. Dadurch ergeben sich die beiden Formeln (1) und (2):

U T M_north= 452316 +U U_x/100 (1)

U T Meast= 5411325−U Uy/100 (2) Mit Proj werden diese Werte schließlich zu Längen- und Breitengrad zurückgerechnet und zusammen mit den Dateinamen der Bilder in eine neue Metadaten-CSV-Datei geschrie- ben, sodass sie von der Python-Anwendung gelesen werden können. Abbildung 5 zeigt die Verteilung der Fotos nach der Generierung mit vier CameraVolumes, anschließender Umrechnung auf Längen- und Breitengrad und Import in die Python-Anwendung. Die Dichte der Punkte im linken Bereich des Bildes ist weniger hoch, da hier ein größeres Volume bei gleichbleibenden Gesamtfotos genutzt wurde.

20Universal Transverse Mercator: https://www.killetsoft.de/t_0901_d.htm, 14.09.20

21https://proj.org, 14.09.20

(16)

3 Durchführung

Abbildung 5: Verteilung der synthetischen Fotos

3.2.2 Datenverteilung

Minimal- und Maximalwerte Im Gegensatz zu den realen Trainingsdaten, bei denen eine ausgeglichenere Verteilung der Fotos auf die Zellen durch die Quad-Tree-Teilung ermöglicht wurde, ist dies bei der Nutzung synthetischer Daten nicht mehr nötig, da die Anzahl der Fotos pro Zelle selbst kontrolliert werden kann. Dieser Teilungs-Mechanismus wurde somit optional gemacht und hier nicht mehr angewandt. Über eine Konﬁgurations- datei wurde die Anzahl der Fotos auf minimal 50 und maximal 600 pro Zelle bestimmt und auf beide Datensätze angewandt. Bei Unter- bzw. Überschreiten dieser Werte werden die Klassen und die dazugehörigen Fotos außerhalb des deﬁnierten Bereichs aus der Trainingsmenge entfernt. Abbildung 6a zeigt die Verteilung beider Datensätze als Heatmap (links) und Balkendiagramm (rechts) nach der Anwendung von Minimum und Maximum.

Datensatz-Synchronisation Als neues Feature der Python-Anwendung wurde ein Synchronisations-Mechanismus implementiert, der es ermöglicht, die möglichen Zellen bzw. Zielklassen des neu erstellten Datensatzes mit denen eines anderen Datensatzes ab- zugleichen und jeweils alle Fotos der Zellen zu entfernen, die in dem anderen Datensatz nicht vorkommen. Dieses Feature soll genutzt werden, um die Nutzbarkeit zweier Daten- sätze unmittelbar miteinander auf Basis der gleichen Zielklassen und der Verteilung der Fotos darin vergleichen zu können. Konkret kann damit ein neuer synthetisch erstellter mit dem realen Datensatz aus [5] verglichen werden, indem beide die selben Zellen mit gleichen Indizes in der Zielmenge enthalten. Ein Import des S2-Zellen Rasters aus dem

(17)

(a) Realer Datensatz

(b) Synthetischer Datensatz

Abbildung 6: Darstellung der Fotoverteilung nach Anpassung durch Minimal- und Maximalwert Heatmap (links): Zahl in Kästen: S2-Index, Farbbalken: Anzahl der Fotos

Balkendiagramm (rechts): x-Achse: S2-Index, y-Achse: Anzahl der Fotos

realen Datensatz in UE4 (vgl. gelb markiertes Raster in Abbildung 4a) hilft, ein übermä- ßiges Erstellen von Fotos, die nicht im Bereich der realen Daten liegen, durch das gezielte Setzen der CameraVolumes innerhalb des Rasters zu vermeiden.

In der Python-Anwendung sieht ein Synchronisationsprozess anschließend wie folgt aus:

• Entfernen aller S2-Zellen und der dazugehörigen Fotos aus dem realen Datensatz, die nicht im synthetischen Datensatz gefunden werden können

• Übernahme der S2-Zellen Indizes aus einerS2CellId-Index-Mapping Tabelle des synthetischen Datensatzes

• Entfernen aller S2-Zellen und der dazugehörigen Fotos aus dem synthetischen Da- tensatz, die nicht im realen Datensatz gefunden werden können

Abbildung 7 zeigt die nach der Synchronisation übrig gebliebenen Zellen mit den darin geplotteten Geopositionen der Trainingsfotos.

(18)

3 Durchführung

(a) Realer Datensatz (b) Synthetischer Datensatz

Abbildung 7: Synchronisierte Datensätze mit gleichem S2-Zellen Raster

3.3 Training

Um auf der Infrastruktur der HAW lauﬀähig zu sein, die in einer Arbeit von Matthias Nitsche und Stefan Halbritter [8] beschrieben wird, wurde das Projekt „dockerisiert “ und mit der Keras API für die Parallelisierung des Training auf multiplen GPUs konﬁguriert.

Die bisherige für lokale Proof-of-Concept Tests bei geringer Verfügbarkeit von Hardware Ressourcen erstellte 3-Schicht-CNN-Modell sollte zudem durch ein State-of-the-art Mo- dell ersetzt werden. Dafür liefern Khan et al. [6] ein umfangreiches Survey-Paper über eine Vielzahl von CNN-Modellen. Hier wurde sich vorerst für das 48-schichtige Incep- tionV3-Modell [10] entschieden, das sich direkt über die Keras API einbinden lässt²². Da das Modell standardmäßig mit Daten aus dem ImageNet²³ vortrainiert ist, wurden die Gewichte entfernt und der Input-Layer durch die eigenen Trainingsdaten ersetzt.

Als Loss-Funktion wurde die Categorical Crossentropy²⁴ mit dem Stochastic Gradient Descent (SGD)-Optimizer verwendet.

Insgesamt wurden Trainings mit verschiedenen Datensatz-Varianten und Trainings-Para- metern durchgeführt, von denen im Ergebnisteil dieser Arbeit hauptsächlich auf die Trai- nings der synchronisierten Datensätze eingegangen wird. Zur Vergleichbarkeit werden das bisherige CNN-Modell (nachfolgend „Custom“-Modell genannt) und die InceptionV3 Ar- chitektur genutzt. Jedes Training wurde über 50 Epochen mit einer Batch Size von 150 Features durchgeführt.

22https://keras.io/api/applications/inceptionv3, 15.09.20

23http://www.image-net.org/, 15.09.20

24https://peltarion.com/knowledge-center/documentation/modeling-view/build-an-ai-model/loss- functions/categorical-crossentropy, 18.09.20

(19)

3.4 Exemplarisches Testen

Eine zentrale Herausforderung des Machine Learning ist, dass die trainierten Modelle gut mit bisher ungesehenen Daten umgehen können und nicht nur mit denen, womit sie trainiert wurden [2]. Da die Validierungsdaten des realen und synthetischen Datensatzes aus unterschiedlichen Domänen (jeweils den eigenen) stammen, wurde ein unabhängiger Testdatensatz mit Screenshots aus Google Street View und eigenen Urlaubsfotos unter der Annahme, dass dessen Ground Truth Daten ausreichend korrekt sind, erstellt. Durch die Python-Anwendung wurden die Längen- und Breitengrade wie üblich in das S2- Format übertragen und den verfügbaren Zellen zugewiesen (Abbildung 8).

Abbildung 8: Test-Datensatz Verteilung im synchronisierten Raster

Somit blieben 48 Fotos, die in die synchronisierten InceptionV3-Modelle des realen und synthetischen Datensatzes (inkl. wechselnder Hintergründe) gegeben und vorhergesagt wurden. Da mit einer geringen Trefferzahl der exakten Zellen zu rechnen war, wurde die Distanz in Metern zwischen den geografischen Mittelpunkten der Test- und der vorherge- sagten Klasse berechnet und in die Modellausgabe integriert. Dadurch können genauere und flexible Grenzwerte festgelegt werden, wann eine Vorhersage als Treffer gelten darf.

Das Ergebnis folgt in Abschnitt 4.3.

(20)

4 Ergebnisdiskussion

In diesem Abschnitt soll das Potenzial des synthetischen Datensatzes evaluiert werden, indem dieser mit dem realen Datensatz aus der vorausgegangenen Arbeit verglichen wird.

Dabei folgt zuerst ein Blick auf die Datenverteilung und anschließend auf die Trainings- ergebnisse mit exemplarischem Test. Auf Basis dieser Ergebnisse wird versucht, Rück- schlüsse auf die Datenqualität zu ziehen und sich daraus ergebene oﬀene Fragen für weiterführende Arbeiten zu sammeln.

4.1 Datenverteilung

In Abbildung 1 wurde zu Beginn dieser Arbeit die Verteilung der mit der Flickr API her- untergeladenen realen Fotos der Notre Dame aus einem Umkreis von etwa 4 km gezeigt.

Wie hier deutlich zu sehen ist, findet eine Anhäufung aufgrund touristisch favorisierter Orte besonders am Haupteingang und an der Südseite statt. Die höchste Dichte befindet sich allerdings innerhalb der Klassen, die direkt auf dem Zielobjekt liegen, was unter anderem auf die Innenaufnahmen zurückzuführen ist. Abbildung 6a macht dies in Form einer Heatmap-Darstellung besonders sichtbar, die nach der Begrenzung der Fotos auf mindestens 50 und maximal 600 pro Zelle erstellt wurde. Durch den Wegfall von Zellen ergibt sich bei diesem Vorgehen der Nachteil, dass sich das Netz folglich nicht für alle Klassen trainieren lässt. Geopositionen als Klassifizierungs-Problem mit diesem Detail- grad und statischen Klassen zu betrachten, stößt hier somit an seine Grenzen.

Diese Problematik entsteht bei der synthetischen Datengenerierung jedoch nicht: Die Generierung der Fotos erfolgt zwar zufällig, wodurch sich ebenso eine ungleiche Verteilung ergibt (siehe Abbildungen 5 und 6b), allerdings sind die zu erstellenden Klassen und die Gesamtzahl der Fotos frei wählbar. Der Datensatz kann schließlich so lange und beliebig groß produziert werden, bis jede Klasse ausreichend abgedeckt ist.

Um beide Datensätze einigermaßen „fair“ insbesondere beim Training miteinander vergleichen zu können, wurden deren Zielklassen - die S2-Zellen - miteinander synchronisiert (siehe Abschnitt 3.2.2). Abbildung 7 zeigt die daraus resultierenden Verteilungen im realen und synthetischen Datensatz mit gleicher Klasseneinteilung und Indizierung. Durch die Synchronisation wurden 2.483 Fotos aus dem realen Datensatz entfernt, sodass die Größe nur noch 11.768 Fotos entspricht, von denen zusätzlich 25% für die Validierung verwendet werden. Intuitiv ist dies eine sehr kleine Menge für das Training.

(21)

Unter Berücksichtigung der beschriebenen geringen Datenqualität (siehe Abschnitt 2.1) müssten zudem einige Trainingsdaten mit falschen Inhalten oder Labels entfernt werden, weshalb hier weitreichendere Quellen zur Aufstockung der Datenmenge erforderlich wären. Allerdings entfällt durch die Synchronisation auch ein großer Teil der unbrauchba- ren Innenaufnahmen, da für den synthetischen Datensatz nur Außenaufnahmen erstellt und dadurch zumindest vier Zellen, die sich direkt auf dem Gebäude befänden, nicht abgedeckt wurden.

Der synthetische Datensatz enthält aktuell²⁵ nach der Synchronisation 11.000 Fotos.

Auch wenn die Verteilung dadurch mit der des realen Datensatzes vergleichbar ist, kann diese hingegen ohne großen Aufwand durch Anhebung der Gesamt-Exportmenge verän- dert werden, was ein deutlicher Vorteil gegenüber der Nutzung von realen Daten ist.

Dieser Datensatz entstand aus einer Gesamtmenge von 20.000 Fotos, in dem die Anzahl der Fotos in keiner Zelle den Minimalwert von 50 unterschritt.

4.2 Training

Für die Vergleichbarkeit der Datensätze wurden Trainings mit dem Custom-Modell aus [5] sowie dem InceptionV3-Modell für die realen und synthetischen Daten nach der Syn- chronisation durchgeführt, deren Verläufe der ersten 50 Epochen anhand der Validie- rungsgenauigkeit in Abbildung 9 zu sehen sind.

Der synthetische Datensatz wurde mit und ohne zufällige Hintergründe trainiert („Synth rBG“ bzw. „Synth sBG“). Die Validierungsgenauigkeit der realen Daten erreicht einen Maximalwert von 12 % (Custom Modell) bzw. 17 % (InceptionV3). Aufgrund dieses nied- rigen Wertes ist anzunehmen, dass die Varianz des Inhaltes der Daten so hoch ist, dass das Netz enorme Schwierigkeiten hat, Features zu erkennen. Da das Validierungs-Set eine zufällig gewählte Teilmenge der Gesamtdaten ist, können hier ebenso diverse irreführende Objekte und fehlerhafte Metadaten enthalten sein, wodurch das Netz kaum Ähnlichkeiten im Trainings-Set ﬁndet.

Bei der Verwendung des synthetischen Datensatzes hingegen kann bereits nach der 8. Epo- che unabhängig von Trainingsmodell und Datensatz-Variation eine Validierungsgenauig- keit von mehr als 50 % erreicht werden. Das beste Ergebnis liegt bei 89 % und wird mit statischem Hintergrund und dem InceptionV3 Modell erreicht. Mit dem Einsatz des

25Zum Zeitpunkt des Abschlusses dieser Arbeit ﬁnden noch weitere Versuche bezüglich der Datenqualität und Größe des Datensatzes statt

(22)

Abbildung 9: Training der synchronisierten Datensätze.

Synth sBG: Synthetischer Datensatz mit statischem Hintergrund,Synth rBG: Syn- thetischer Datensatz mit zufälligem Hintergrund,Real: Realer Datensatz

randomisierten Hintergrundes sinkt dieser Wert auf ca. 76 %. Bei Einsatz des Custom- Modells liegen beide Werte etwa 15 % darunter. Die Vermutung liegt hier nahe, dass die deutlich geringere Komplexität des Datensatzes für eine bessere Anpassung sorgt. Da- durch, dass das Validierungs-Set zudem keine fehlerhaften Daten enthält und die Komple- xität der des Training-Sets (Anzahl der Objekte, Lichtverhältnisse etc.) entspricht, wird eine höhere Genauigkeit erreicht werden können. Da es sich hierbei allerdings um reine synthetische Daten handelt, wird es sich vermutlich nur um eine angemessene Generali- sierung auf die synthetische statt reale Domäne handeln - dem Problem, dem Tremblay et al. [13] mit der Durchmischung der Daten zum Überbrücken des „Reality Gap“ begegnen.

Ferner sind hier weitreichende Tests und darauﬀolgende Anpassungen nötig.

Generell zeigt der Vergleich jedoch bereits, dass mit dem InceptionV3 Modell deutlich bessere Ergebnisse erzielt werden. Dies kann vorerst weiter verwendet werden, um iterativ eine gute Trainingsdatengrundlage schaﬀen zu können. Anschließend kann in Betracht gezogen werden, das bestmögliche Modell zu ﬁnden und die Hyperparameter wie die verwendete Loss-Funktion, Optimizer, Learning Rate etc. zu optimieren und geeignete Metriken aufzustellen, mit denen das Modell realistisch auf entsprechende Erwartungen geprüft werden kann.

Auch wenn hier generell noch viel Spielraum nach oben existiert, stützen diese Werte die

(23)

Vermutung, dass das Synthetisieren der Daten Potential bietet, ein geeignetes Trainings- modell zu erstellen.

4.3 Tests der trainierten Modelle

Der exemplarische Test der InceptionV3-Modelle der Datensätze Synth-rBG und Real mit dem manuell erstellten Test-Datensatz fiel erwartungsgemäß bescheiden aus: Von 48 realen getaggten Fotos konnte das synthetische Modell nur ein Foto richtig klassifizieren, das reale immerhin zwei. Daraus könnte schlussgefolgert werden, dass es sich hierbei um zufällige Treffer handelt. Abbildung 10a zeigt das einzige durch Synth-rBG richtig klassifizierte Foto (Index 45 bei einer Wahrscheinlichkeit von 81,8 %). In der Auswahl der zu dieser Klasse gehörenden Trainingsfotos (Abbildung 10b) können mit dem bloßen Auge aber durchaus Gemeinsamkeiten erkannt werden. Das reale Modell hingegen tippt mit 93,6 % auf Index 114 und landet damit auf einer der maximal unsauberen Klassen inmitten des Gebäudes (siehe Abbildung 10c).

(a) Eingabe: Google Street View Testfoto mit S2-Index 45

(b) Klasse 45 (synthetisch) (c) Klasse 114 (real)

Abbildung 10: Vorhersagen von Klassen beider Modelle und Auszug aus dessen Trainingsfotos Im Anhang beﬁnden sich alle Ergebnisse des realen (Tabelle 3) und synthetischen Mo- dells (Tabelle 4). Da in Abschnitt 3.4 die Distanz zwischen Test- und vorhergesagter Klasse ausgerechnet wurde, kann anhand dieser Tabellen nun beispielsweise die Anzahl der Vorhersagen, die unterhalb von 50 Metern von den Testklassen entfernt sind, bestimmt werden. Dadurch ergibt sich schließlich eine etwas optimistischere Statistik, die in Tabelle 2 festgehalten ist.

Im Anhang sind je ein Positivbeispiel (Abbildungen 12 und 13) und Negativbeispiel (Ab- bildungen 14 und 15) für beide Datensätze zu ﬁnden, bei denen zufällige ungelabelte

(24)

Tabelle 2: StreetView-Test mit synthetischem InceptionV3-Modell (synchronisiert) Modell Anzahl richtiger

Klassen

Anzahl < 50 m Differenz

Synthetisch 1 9

Real 2 11

Bilder aus dem Internet vorhergesagt wurden. Das synthetische Modell scheint generell bei größerer Entfernung zum Zielobjekt auf Probleme zu stoßen (z.B. Abbildung 15), was an der zu geringen Bildauﬂösung der Trainingsfotos und eventuell nicht ausreichender Be- leuchtung oder falscher Farbgebung liegen könnte. Zudem beﬁnden sich im synthetischen Datensatz einige Nahaufnahmen, auf denen nichts zu erkennen ist (vgl. Abbildung 11), die eventuell negativ zur Erkennung beitragen.

Generell ist jedoch weder die Testmenge groß genug, um wissenschaftlich triftige Aussagen treﬀen zu können, noch sind die Modelle im aktuellen Status ausreichend trainiert und optimiert. Für angemessene Tests müssen also noch weitreichende Optimierungen der Trainingsdatensätze erfolgen.

4.4 Fazit

Der Vergleich der Trainings mit unterschiedlichen Datensätzen und deren Abwandlung zeigte bei variierender Datenqualität und -komplexität unmittelbare Auswirkungen auf die Trainingsergebnisse. Während der reale Datensatz aufgrund der Diversität der einzel- nen Fotos und Metadaten sowie unausgeglichener Verteilung mit den hier verwendeten Methoden keine akzeptablen Validierungsergebnisse erzielen kann, weist der synthetische Datensatz dort eine weitaus bessere Genauigkeit vor - im exemplarischen Test mit realen Daten sind beide Modelle in der aktuellen Phase allerdings noch nahezu unbrauchbar.

Dieser Versuch hat aber gezeigt, dass es zum einen nicht unmöglich ist, mit rein synthetischen Daten die Geoposition von Fotos bzw. der Kamera zu bestimmen. Zum anderen wurde bewusst auf einen qualitativ simplen Datensatz gesetzt, der in viele Richtungen verbessert werden kann. Durch diese Arbeit konnte eine weitere Variante der Datenge- winnung für Deep Learning Aufgaben vorgestellt und damit einhergehend eine Samm- lung von oﬀenen Fragen, die sich in diesem Umfeld ergeben, präsentiert werden. Um also abschließend die Frage beantworten zu können, wie eine akzeptable Nutzbarkeit des synthetischen Modells zu realisieren ist, werden Folgearbeiten nötig sein.

(25)

4.5 Ausblick

Wie in der Diskussion bereits angemerkt, hinterlässt diese Arbeit weitere Aufgaben, die zur Realisierung einer akzeptablen Nutzbarkeit der Bestimmung von Geokoordinaten mit neuronalen Netzen angegangen werden können. Folgende Punkte könnten z.B. in Betracht gezogen werden:

• Vergrößern der Foto-Auﬂösung

• Anpassung von Anzahl der (Gesamt-) Fotos und Klassen

• Anpassung der Randomisierung in Bezug auf unterschiedliche Lichtverhältnisse, Art und Anzahl der Distraktoren etc. (Komplexität)

• Überprüfung des Notre Dame 3D-Modells und dessen Texturen auf Realismus, Detailgrad und Farbgebung

Es ist unklar, inwiefern diese Punkte zu einer verlässlicheren Erkennung von realen Fotos durch ein synthetisches Modell führen können und wie genau diese sein kann. Als weiterer Schritt kann somit versucht werden, den Datensatz mit teils fotorealistischen Elementen oder sogar realen Fotos aufzustocken, was Tremblay et al. [13] als „Fine-Tuning“ be- zeichnen. Neben dem bereits genannten Optimieren der Hyperparameter des genutzten CNN-Modells kann auch darüber nachgedacht werden, statt eines Klassiﬁkators auf eine Regressions-Lösung zu setzen. Alternativ könnte die Masterarbeit von Dustin Spallek [9]

herangezogen werden, in der er auf [13] aufbauend beweist, dass mit dem Training synthe- tisierter Datensätze die Lage und Position von Objekten im Raum durch neuronale Netze bestimmt werden kann. Hier böte sich ein Test an, inwiefern diese Architektur mit dem Notre Dame 3D-Modell harmoniert und ob sich anhand der Lageschätzung der dann ortsdynamischen Notre Dame die Kamerapositionen zurückrechnen lassen. Hier bietet sich eine vielversprechende Chance, sowohl die Genauigkeit der Bestimmung zu steigern als auch durch Parallelisieren mehrerer Objekte einen Mehrwert in der Nutzbarkeit zu schaﬀen.

Sollte sich dieses Projekt zukünftig unabhängig von der weiteren Vorgehensweise als zufriedenstellend funktionsfähig erweisen, kann es letztendlich dazu genutzt werden, die unsauberen GPS-Informationen aus den Flickr-Fotos und weiteren Internetquellen zu bereinigen. Damit wäre dann das Ursprungsproblem aus der vorangegangen Arbeit [5]

behoben.

(26)

5 Anhang

(a) Vorderseite

(b) Rechte Seite

(c) Rückseite

(d) Linke Seite

Abbildung 11: Beispielbilder aus dem synthetischen Datensatz mit zufälligen Hintergrundbildern

(27)

(a) Eingabe: Testfoto (b) Ausgabe: S2-Zelle mit Index 126

(c) Realer Datensatz für S2-Index 126 (Auszug)

Abbildung 12: Realistische Prediction eines Fotos mit dem synchronisierten realen Datensatz

(28)

5 Anhang

(c) Synthetischer Datensatz S2 Index 126 (Auszug)

Abbildung 13: Realistische Prediction eines Fotos mit dem synchronisierten synthetischen Da- tensatz

(29)

(c) Realer Datensatz für S2-Index 113 (Auszug)

Abbildung 14: Fehlerhafte Prediction eines Fotos mit dem synchronisierten realen Datensatz

(30)

5 Anhang

(c) Synthetischer Datensatz S2 Index 126 (Auszug)

Abbildung 15: Fehlerhafte Prediction eines Fotos mit dem synchronisierten synthetischen Daten- satz

(31)

Tabelle 3: StreetView-Test mit realem InceptionV3-Modell (synchronisiert)

Filename Real

S2-Idx

Predicted S2-Idx

Probability in %

Distance diff in m

Next 3 Predictions

IMG_20190623_155317.jpg 7 8 0,245 34,979 [ 14 79 126]

IMG_20190623_155527.jpg 13 14 0,982 25,669 [ 42 111 57]

IMG_20190623_155631.jpg 12 113 0,85 191,284 [ 34 111 104]

sv000003.png 44 57 0,996 83,828 [36 40 39]

sv000005.png 45 114 0,936 85,795 [111 7 54]

sv000006.png 45 45 0,433 0 [100 110 105]

sv000007.png 110 100 0,23 122,879 [117 101 110]

sv000008.png 110 113 0,473 43,872 [101 114 34]

sv000011.png 91 82 0,493 75,084 [ 14 103 104]

sv000012.png 82 104 0,663 128,691 [82 14 80]

sv000013.png 81 114 0,593 171,588 [ 80 126 125]

sv000013a.png 81 82 0,364 34,978 [ 81 79 103]

sv000015.png 125 81 0,273 77,01 [110 113 13]

sv000019.png 19 10 0,898 102,814 [ 7 9 38]

sv000020.png 39 7 0,508 132,229 [ 79 113 19]

sv000021.png 41 43 0,863 42,898 [ 54 101 34]

sv000022.png 44 43 0,749 25,67 [34 13 44]

svp0000002.png 117 35 0,617 85,794 [ 34 118 119]

svp0000003.png 117 34 0,477 73,949 [ 35 45 112]

svp0000004.png 33 45 0,364 104,937 [104 33 82]

svp0000005.png 36 57 0,387 171,59 [113 36 34]

svp0000006.png 36 104 0,865 109,251 [ 39 33 125]

svp0000007.png 40 40 0,484 0 [38 45 39]

svp0000008.png 40 14 0,858 85,795 [39 58 36]

svp0000009.png 12 57 0,88 43,872 [ 13 102 100]

svp0000010.png 58 119 0,171 290,153 [113 126 84]

svp0000011.png 9 79 0,456 388,954 [38 10 57]

svp0000015.png 91 81 0,536 108,616 [15 29 84]

svp0000018.png 105 91 0,302 83,83 [ 84 82 103]

svp0000019.png 101 84 0,731 34,979 [ 42 111 100]

svp0000020.png 101 19 0,173 231,028 [84 29 14]

svp0000021.png 100 110 0,149 122,879 [ 14 102 81]

svp0000022.png 102 113 0,458 83,829 [126 29 38]

svp0000024.png 100 126 0,366 117,903 [114 79 81]

svp0000001.png 79 114 0,41 189,429 [ 81 100 15]

svp0000002.png 126 35 0,617 187,626 [ 34 118 119]

svp0000003.png 80 34 0,477 187,627 [ 35 45 112]

svp0000004.png 80 45 0,364 243,416 [104 33 82]

svp0000005.png 125 57 0,387 315,842 [113 36 34]

svp0000006.png 118 104 0,865 117,903 [ 39 33 125]

svp0000008.png 38 14 0,858 107,443 [39 58 36]

svp0000009.png 8 57 0,88 85,325 [ 13 102 100]

svp0000010.png 7 119 0,171 289,441 [113 126 84]

svp0000011.png 10 79 0,456 368,627 [38 10 57]

(32)

5 Anhang

Tabelle 4: StreetView-Test mit synthetischem InceptionV3-Modell (synchronisiert)

Filename Real

S2-Idx

Predicted S2-Idx

Probability in %

Distance diff in m

Next 3 predictions

IMG_20190623_155317.jpg 7 9 99.106 43.871 [ 8 12 58]

IMG_20190623_155527.jpg 13 41 59.562 83.827 [ 8 103 9]

IMG_20190623_155631.jpg 12 102 21.647 275.021 [117 81 103]

sv000003.png 44 10 93.5 133.819 [45 7 8]

sv000005.png 45 45 81.788 0.0 [109 110 112]

sv000006.png 45 109 25.912 83.829 [ 41 110 45]

sv000007.png 110 109 80.92 25.67 [111 114 104]

sv000008.png 110 109 56.277 25.67 [ 45 104 112]

sv000011.png 91 57 94.84 335.315 [36 13 54]

sv000012.png 82 79 72.206 75.083 [81 18 8]

sv000013.png 81 8 86.694 411.879 [39 7 18]

sv000013a.png 81 8 93.297 411.879 [10 7 9]

sv000015.png 125 10 33.269 307.189 [7 9 8]

sv000019.png 19 41 64.759 87.743 [104 115 114]

sv000020.png 39 41 38.423 43.872 [109 104 110]

sv000021.png 41 114 52.683 107.691 [113 115 110]

sv000022.png 44 114 46.713 122.878 [110 115 109]

svp0000002.png 117 109 78.532 117.904 [19 9 8]

svp0000003.png 117 10 49.777 228.402 [19 8 7]

svp0000004.png 33 109 71.373 105.254 [ 8 9 110]

svp0000005.png 36 109 79.73 125.601 [114 110 104]

svp0000006.png 36 19 91.997 77.008 [ 91 109 111]

svp0000007.png 40 109 62.147 133.823 [104 110 41]

svp0000008.png 40 110 62.353 109.251 [109 41 104]

svp0000009.png 12 109 74.94 232.845 [110 116 45]

svp0000010.png 58 9 64.715 43.871 [82 10 8]

svp0000011.png 9 8 53.477 25.669 [10 7 9]

svp0000015.png 91 18 50.255 283.709 [39 58 8]

svp0000018.png 105 8 48.71 314.269 [45 10 9]

svp0000019.png 101 9 73.53 323.073 [81 8 58]

svp0000020.png 101 104 24.676 61.439 [ 9 109 8]

svp0000021.png 100 8 78.874 372.004 [58 13 9]

svp0000022.png 102 8 33.588 323.071 [58 45 9]

svp0000024.png 100 58 83.097 335.313 [13 12 9]

svp0000001.png 79 8 36.936 409.221 [102 91 7]

svp0000002.png 126 109 78.532 176.168 [19 9 8]

svp0000003.png 80 10 49.777 350.621 [19 8 7]

svp0000004.png 80 109 71.373 181.109 [ 8 9 110]

svp0000005.png 125 109 79.73 174.893 [114 110 104]

svp0000006.png 118 19 91.997 144.721 [ 91 109 111]

svp0000008.png 38 110 62.353 147.615 [109 41 104]

svp0000009.png 8 109 74.94 283.705 [110 116 45]

svp0000010.png 7 9 64.715 43.871 [82 10 8]

svp0000011.png 10 8 53.477 42.897 [10 7 9]

(33)

Literatur

[1] Chen, X. ; Lin, X.: Big Data Deep Learning: Challenges and Perspectives. In:

IEEE Access 2 (2014), S. 514–525

[2] Goodfellow, Ian ; Bengio, Yoshua ; Courville, Aaron: Deep Learning. MIT Press, 2016. – http://www.deeplearningbook.org

[3] Gudivada, Venkat ;Apon, Amy ; Ding, Junhua: Data quality considerations for big data and machine learning: Going beyond data cleaning and transformations.

In: International Journal on Advances in Software 10 (2017), Nr. 1, S. 1–20 [4] Jakobi, Nick ;Husbands, Phil ; Harvey, Inman: Noise and the reality gap: The

use of simulation in evolutionary robotics. In:Morán, Federico (Hrsg.) ;Moreno, Alvaro (Hrsg.) ; Merelo, Juan J. (Hrsg.) ; Chacón, Pablo (Hrsg.): Advances in Artificial Life. Berlin, Heidelberg : Springer Berlin Heidelberg, 1995, S. 704–720. – ISBN 978-3-540-49286-3

[5] Kanne-Schludde, Thomas: Aufbau einer Pipeline zur Bestimmung von GPS-Koordinaten aus Fotos mithilfe neuronaler Netze. (2020), Feb. – URL https://users.informatik.haw-hamburg.de/~ubicomp/projekte/

master2020-proj/kanne.pdf

[6] Khan, Asifullah ; Sohail, Anabia ; Zahoora, Umme ; Qureshi, Aqsa S.: A survey of the recent architectures of deep convolutional neural networks. In: Arti- ficial Intelligence Review (2020), Apr. – URL http://dx.doi.org/10.1007/

s10462-020-09825-6. – ISSN 1573-7462

[7] Liu, Li ; Ouyang, Wanli ; Wang, Xiaogang ; Fieguth, Paul ; Chen, Jie ; Liu, Xinwang ;Pietikäinen, Matti: Deep learning for generic object detection: A survey.

In: International journal of computer vision 128 (2020), Nr. 2, S. 261–318

[8] Nitsche, Matthias ;Halbritter, Stephan: Development of an End-to-End Deep Learning Pipeline, Hochschule für Angewandte Wissenschaften Hamburg, 2019 [9] Spallek, Dustin: Deep Learning basierte Erkennung von 3D-Objektposen auf Basis

synthetisch erzeugter Daten, Hochschule für Angewandte Wissenschaften Hamburg, 2020

[10] Szegedy, Christian ; Vanhoucke, Vincent ;Ioffe, Sergey ; Shlens, Jonathon ; Wojna, Zbigniew:Rethinking the Inception Architecture for Computer Vision. 2015

(34)

Literatur

[11] To, Thang ; Tremblay, Jonathan ; McKay, Duncan ; Yamaguchi, Yukie ; Leung, Kirby ; Balanon, Adrian ; Cheng, Jia ; Hodge, William ; Birch- field, Stan: NDDS: NVIDIA Deep Learning Dataset Synthesizer. 2018. – https:

//github.com/NVIDIA/Dataset_Synthesizer

[12] Tobin, Josh ;Fong, Rachel ;Ray, Alex ;Schneider, Jonas ;Zaremba, Wojciech ; Abbeel, Pieter: Domain Randomization for Transferring Deep Neural Networks from Simulation to the Real World. 2017

[13] Tremblay, Jonathan ;Prakash, Aayush ;Acuna, David ;Brophy, Mark ;Jam- pani, Varun ;Anil, Cem ; To, Thang ; Cameracci, Eric ; Boochoon, Shaad ; Birchfield, Stan: Training Deep Networks with Synthetic Data: Bridging the Reality Gap by Domain Randomization. In:2018 IEEE/CVF Conference on Com- puter Vision and Pattern Recognition Workshops (CVPRW) (2018), Jun. – URL http://dx.doi.org/10.1109/CVPRW.2018.00143. ISBN 9781538661000 [14] Tremblay, Jonathan ;To, Thang ;Birchfield, Stan: Falling Things: A Synthetic

Dataset for 3D Object Detection and Pose Estimation. In: CoRR abs/1804.06534 (2018). – URL http://arxiv.org/abs/1804.06534

[15] Weyand, Tobias ;Kostrikov, Ilya ;Philbin, James: PlaNet - Photo Geolocation with Convolutional Neural Networks. In:European Conference on Computer Vision (ECCV), 2016