Upload
others
View
4
Download
0
Embed Size (px)
Citation preview
TECHNISCHE UNIVERSITÄT DRESDEN
FAKULTÄT INFORMATIK
INSTITUT FÜR SOFTWARE- UND MULTIMEDIATECHNIK
PROFESSUR FÜR COMPUTERGRAPHIK UND VISUALISIERUNG
PROF. DR. STEFAN GUMHOLD
Bachelorarbeit
zur Erlangung des akademischen GradesBachelor of Science
RGBD-Bild-Interpolation auf Android-Geräten fürinteraktive Remote-Visualisierung
Christoph Klaus Träger(Geboren am 11. Oktober 1989 in Pirna, Mat.-Nr.: 3793861)
Betreuer: Dr. Sebastian Grottel
Dresden, 28. Juli 2014
Aufgabenstellung
Zunehmende Datenvolumen in der Simulation, die zunehmende Komplexität in der Praxis üblicher Vi-
sualisierungen und die fortschreitende Verbreitung und Nutzung mobiler Endgeräte führt zu einem Aufle-
ben der Konzepte der Remote-Visualisierung. Auf einem spezialisierten Hochleistungs-Computer, mög-
lichst eng an die Datenquellen (z.B. Simulationen) gekoppelt, werden die Visualisierungen generiert.
Anschließend werden lediglich die entstandenen Bilddaten und minimal zusätzliche Daten an einen
Thin-Client zur Darstellung übertragen. Das größte Problem bei diesem Szenario ist die Latenz bei
Interaktionen. Schnelle Netzwerke können diese minimieren, jedoch nicht auslöschen, so dass immer
ein negativ spürbarer Zeitverzug bei Eingaben bleibt. Besonders störend fällt dieses bei der interaktiven
Manipulation der virtuellen Kamera bei 3D-Visualisierungen auf. Der vielversprechendste Ansatz diese
Problem anzugehen liegt in der Client-seitigen Bildinterpolation um die Systemlatenzen zu maskieren.
In dieser Bachelorarbeit soll anhand von Vorgaben eine prototypische Anwendung entstehen, welche
durch 3D-Extrapolation von RGBD-Bilddaten eine entsprechende Latenzmaskierende Anzeige auf An-
droid-Endgeräten ermöglicht. Ausgangspunkt ist die Arbeit „View interpolation for image synthesis“von
Chen und Williams, SIGGRAPH ’93, Seite 279-288. Ausgehend hiervon soll ein aktuelles State-of-the-
Art-Verfahren implementiert werden. Als Daten soll ein RGBD-Bild und ein einfaches Kameramodell
übertragen werden. Der Thin-Client soll als Android-App mittels JAVA und OpenGL ES implemen-
tiert werden. Eine zweite Anwendung soll für PC geschrieben werden, entweder in JAVA oder C++ mit
OpenGL, und soll einen einfachen Visualisierungsserver repräsentieren. Als Kamera-Modell soll eine
Orbit-Kamera umgesetzt werden, inklusive Steuerung in der PC-Anwendung und entsprechender Steue-
rung durch intuitiver Benutzungsgesten auf dem Android-Gerät. Die Netzwerkkommunikation muss
nicht optimiert werden. Eine einfache TCP/IP-Verbindung genügt, da im Rahmen dieser Arbeit Laten-
zen durchaus erwünscht sind. Die PC-Anwendung muss sogar in der Lage sein die Latenzen künstlich zu
vergrößern, damit die Effektivität der Bild-Extrapolation auf dem Endgerät deutlicher sichtbar wird. Op-
tionale Ziele umfassen eine Steuerung einer freien Kamera und das (Re-)Design der Android-Software
als wiederverwendbare Bibliothek mit einer User-Control-Komponente zur Darstellung. Weiter ist ei-
ne Anbindung an die Video-Übertragungs-Bibliothek (RIV-Lib) die parallel am Lehrstuhl CGV entsteht
denkbar, aber nicht direkt Teil der Aufgabenstellung, da eine rechtzeitige Fertigstellung dieser Bibliothek
nicht garantiert werden kann.
Zusätzliche Bewertungskriterien der Abgabe garantieren die Weiterverwendung und Weiterentwicklung
der Ergebnisse der Arbeit. Besonderes ist hierbei die Funktionsfähigkeit der der Software auf Endgrä-
ten des Lehrstuhls und eine angemessene Dokumentation der Ergebnisse zu erwähnen. Die konkreten
Maßnahmen werden hierzu mit dem Betreuer der Arbeit vereinbart und dokumentiert.
Detaillierte Darstellung der einzelnen Ziele/Arbeitsschritte:• Literaturrecherche der State-of-the-Art-Methoden ausgehend von vorgegeben Publikationen
o Software-Design der zu entstehenden Android-App auf Basis der ausgewählten Methode
o Implementierung der Android-App, sowie einer PC-Server-Anwendung
• Einfache statische Szene
• Orbit-Kamera-Modell auf einer Datenbasis entsprechend gluLookAt und gluPerspective (Rotation
um den Fokuspunkt, freie Bewegung oder Bewegung durch Szenen-Bounding-Box begrenzt)
• Kamera-Manipulation durch intuitive Touch-Gesten
o Evaluation der entstandenen Bild-Extrapolation
• Vergleich zwischen den Interpolierten Bildern und dem Ground-Truth (Server-seitig mit identi-
schen Kameraeinstellungen gerendert)
• Qualitative Bewertung: informale Benutzerstudie zum empfundenen Bildunterschied zwischen ei-
nem interpolierten Bild und der Ground-Truth
o oder quantitative Bewertung: durch Bild-Differenz-Metriken (z.B. SSIM 1 oder PSNR 2 )
zwischen dem interpolierten Bild und der Ground-Truth
• Die Abgabe muss auf zumindest einem der PCs des Lehrstuhls (zugewiesener Rechner im Ho-
lodeck) und auf dem Android-Tablet des Lehrstuhls (Nexus 7 2013 32GB Wifi) funktionstüchtig
sein.
• Quellcode und Build-Prozess müssen für eine Weiterentwicklung ausreichend dokumentiert sein.
Optionale Ziele/Arbeitsschritte:• Design der Android-Anwendung als wiederverwendbare und erweiterbare Bibliothek mit GUI-
Benutzerkomponenten
o Darstellung ohne Extrapolation kann vorgesehen werden
o Darstellung auf Basis einer 2D-Visualisierung kann vorgesehen werden
• Zusätzliches Kamera-Modell: freie Kamera (Rotation um den Augpunkt und freie Bewegung)
o Kamera-Modelle sind kompatible und lassen sich intuitiv wechseln, bzw. durch entsprechen-
de Touch-Gesten getrennt ansteuern
• Fall die RIV-Bibliothek rechtzeitig zur Verfügung steht ist eine entsprechende Kompatibilität er-
wünscht.
• Bei den Zielen/Aufgabenschritten die in obiger Liste Alternativen darstellen können auch beide
Möglichkeiten umgesetzt werden.
Selbstständigkeitserklärung
Hiermit erkläre ich, dass ich die von mir am heutigen Tag dem Prüfungsausschuss der Fakultät Informa-
tik eingereichte Arbeit zum Thema:
RGBD-Bild-Interpolation auf Android-Geräten für interaktive Remote-Visualisierung
vollkommen selbstständig verfasst und keine anderen als die angegebenen Quellen und Hilfsmittel be-
nutzt sowie Zitate kenntlich gemacht habe.
Dresden, den 28. Juli 2014
Christoph Klaus Träger
Kurzfassung
Remote Visualisierung erlaubt es, komplexe Szenen und Simulationen auch auf leistungsschwächeren
Systemen, zum Beispiel mobilen Endgeräten darzustellen. Dabei gilt es vor allem, die durch das Netz-
werk verursachte Latenz vor dem Nutzer zu verbergen, um ihm eine interaktive Darstellung zu bieten,
die sowohl reaktionsschnell als auch kontinuierlich ist.
Das in dieser Arbeit vorgestellte Verfahren, basierend auf dem Ansatz von [MMB97], maskiert die La-
tenzen des Netzwerks durch die Erzeugung von Zwischenbildern. Diese werden durch die Extrapolation
von einem bzw. die Komposition aus mehreren Referenzbildern berechnet. Aufbauend darauf, wird eine
Anwendung für mobile Endgeräte entwickelt. Für die Beurteilung der Qualität der erzeugten Zwischen-
bilder wird die Abweichung zwischen Zwischenbild und Referenzbild auf Grundlage der PSNR ver-
wendet. Es zeigt sich, dass das Verfahren die spürbare Latenz vollständig maskieren kann. Dabei treten
grafische Ungenauigkeiten in der Darstellung auf.
Abstract
Remote visualization allows representing complex scenes and simulations on low-performance systems,
e.g. mobile devices. Therefore it is important to hide the latency, which is caused by the network, from
the user to provide him with an interactive presentation, which react quickly and works continuously. The
proposed method in this bachelor thesis, based on the approach of [MMB97], conceals the latencies of the
network by generating intermediate images. These intermediate images are calculated by extrapolation
of one or the composition of several reference images. Based on this, an application will be developed for
mobile devices. To assess the quality of the intermediate images, the deviation between the intermediate
image and the reference image will be used based on PSNR. Thereby graphical inaccuracies occur.
1
Inhaltsverzeichnis
Abbildungsverzeichnis 3
1 Einleitung 5
1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2 Ziele . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3 Struktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2 Verwandte Arbeiten 7
3 Das Verfahren 11
3.1 Bildextrapolation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.1.1 View-Transformation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.1.2 Rekonstruktion der Oberfläche . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.1.3 Kantendetektion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.1.4 Behandlung von Kantenübergängen mittels Heuristik . . . . . . . . . . . . . . . 15
3.2 Komposition aus mehreren Referenzbildern . . . . . . . . . . . . . . . . . . . . . . . . 18
3.2.1 Iterative Zusammenführung von Bildinformationen . . . . . . . . . . . . . . . . 20
3.2.2 Berechnung der Kamerasichten für Referenzbilder . . . . . . . . . . . . . . . . 21
3.2.3 Kamerasichten vom Server abrufen . . . . . . . . . . . . . . . . . . . . . . . . 23
4 Implementierung 25
4.1 Gesamtarchitektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.2 Projektstruktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.3 Der Remote-Client für Android . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.3.1 Architektur des Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.3.2 Kommunikation mit dem Server . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.3.3 Umgang mit OpenGL-Objekten . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.3.4 Optimierung der Vertex-Daten . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.4 Zwischenfazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2
5 Evaluation 33
5.1 Evaluation der Startverzögerung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
5.2 Evaluation der Bildwiederholfrequenz . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
5.3 Evaluation der Bildqualität . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
6 Fazit und Ausblick 37
Literaturverzeichnis 39
3
Abbildungsverzeichnis
3.1 (a) Menge von Vertices vor der Rücktransformation, (b) Menge von Vertices nach der
Rücktransformation, (c) Vertices verbunden durch reguläres Bild-Mesh . . . . . . . . . 14
3.2 Anwendung einer Heuristik an Objektkanten (Original [MMB97]) . . . . . . . . . . . . 16
3.3 Vordergrund-Vertex und zu findender Hintergrund-Vertex (gestrichelter Pfeil) . . . . . . 16
3.4 Verlauf des Kantenhöhenwerts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.5 Berechnung des Flächeninhalts eines Polygons mittels zusätzlicher Dreiecke . . . . . . . 19
3.6 Aktivitätsdiagramm über die Entscheidung zwischen aktuellem Zwischenbildpixel und
Referenzbildpixel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.7 Geometrische Berechnung des Schnittkreisradius . . . . . . . . . . . . . . . . . . . . . 22
4.1 Netzwerkkommunikation zwischen Android-Client und Desktop-Server als Sequenzdia-
gramm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.2 Projektabhängigkeiten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.3 Klassendiagramm der Rendering-Architektur als MVC-Pattern . . . . . . . . . . . . . . 28
4.4 Klassendiagramm der Netzwerkkommunikation des Android-Client . . . . . . . . . . . 29
5.1 Verlauf der Startverzögerung in Abhängigkeit zur Anzahl der Pixel . . . . . . . . . . . . 33
5.2 Bilder pro Sekunde in Abhängigkeit zur Anzahl der Pixel . . . . . . . . . . . . . . . . . 34
5.3 Das PSNR in Abhängigkeit zum Rotationswinkel der Orbit-Kamera . . . . . . . . . . . 35
5.4 Durch Extrapolation erzeugtes Zwischenbild bei einer Rotation des Längenwinkels (a)
um 5 Grad, (b) um 30 Grad, (c) um 60 Grad . . . . . . . . . . . . . . . . . . . . . . . . 35
4 Abbildungsverzeichnis
5
1 Einleitung
1.1 Motivation
Der Wunsch, Informationen überall und jederzeit abrufen zu können, hat in den letzten Jahren dazu
geführt, dass sich viele Bereiche des digitalen Lebens vom Desktop-Computer auf Smartphones und
Tablets verlagert haben. Doch auch wenn die Leistung mobiler Endgeräte stetig steigt, werden sie auf
Grund von begrenzenden Faktoren wie Größe oder Akkulaufzeit nie zu der Leistung aktueller stationärer
Systeme aufschließen können. Speziell in Bereichen, in denen selbst diese Systeme an ihre Grenzen
stoßen, wäre der Einsatz mobiler Endgeräte damit unmöglich.
Die wissenschaftliche Visualisierung ist einer dieser Bereiche. Durch den Umgang mit immer größeren
Datenmengen, sowie zunehmend komplexeren Verfahren diese grafisch darzustellen, ist die direkte Aus-
führung auf einem Smartphone oder Tablet nur schwer realisierbar. Stattdessen werden Hochleistungs-
Computer benötigt, die die Flut an Daten bewältigen können. Zumindest die dabei erzeugten Visualisie-
rungen können auf einem mobilen Endgerät betrachtet werden. Dieser Ansatz führt zur Umsetzung einer
Remote-Visualisierung, bei der das mobilen Endgerät als Thin-Client fungiert.
Die bei der Netzwerkkommunikation zwischen Server und Client auftretende Latenz führt dazu, dass
zum einen der Nutzer eine spürbare Verzögerung zwischen Eingabe und Ausgabe erlebt und zum anderen
eine kontinuierliche Darstellung der Visualisierung nicht immer gewährleistet werden kann.
1.2 Ziele
Ziel dieser Arbeit ist die Konzeption und Entwicklung einer Anwendung zur Remote-Visualisierung für
das mobile Betriebssystem Android, die die netzwerkbedingte Verzögerung vor dem Nutzer verbirgt. Zu
diesem Zweck wird ein Verfahren angewandt, mit dem die Latenzzeit, in der keine aktuellen Bildinfor-
mationen zur Verfügung stehen, durch die Erzeugung von Zwischenbildern überbrückt werden kann. Die
Zwischenbilder werden dabei auf Grundlage bereits empfangener Bilddaten, im Weiteren als Referenz-
bilder bezeichnet, entwickelt.
6 1. EINLEITUNG
1.3 Struktur
Die Arbeit ist wie folgt aufgebaut. In Kapitel 2 werden verwandte Arbeiten vorgestellt. Dabei wird eine
Reihe von Verfahren aufgezeigt, die für die Lösung der Problemstellung dieser Arbeit in Frage kommen.
Basierend auf den gestellten Anforderungen wird darüber hinaus eine Auswahl des Verfahrens für diese
Arbeit getroffen. In Kapitel 3 werden die theoretischen Grundlagen des gewählten Ansatzes erläutert.
Kapitel 4 widmet sich der Implementation der Android-App unter Anwendung der theoretischen Grund-
lagen. Bei der anschließenden Evaluation in Kapitel 5 werden die Ergebnisse überprüft. Ein Ausblick
wird in Kapitel 6 gegeben.
7
2 Verwandte Arbeiten
Durch den Einsatz großer Datenmengen, die in der wissenschaftlichen Visualisierung dargestellt wer-
den sollen, ist eine Visualisierung auf einem mobilen Endgerät kaum zu realisieren. Aus diesem Grund
wird ein Remote-Visualisierung umgesetzt, bei der das aufwendige 3D-Rendering von einem leistungs-
starken Server-Computer durchgeführt wird und das mobile Endgerät als Thin-Client die Darstellung
der Bilddaten übernimmt. Um die durch die Netzwerkkommunikation auftretende sichtbare Latenz zu
verbergen und damit eine kontinuierliche Darstellung zu erreichen, werden zusätzlich zu den empfan-
genen Referenzbildern Zwischenbilder erzeugt. Da für die Synthese der Zwischenbilder ausschließlich
die Bilddaten der Referenzbilder zur Verfügung stehen, wird Image-Based-Rendering angewendet. Bei
diesem Rendering-Verfahren erfolgt die Erzeugung von Bildern auf Grundlage anderer Bilddaten. Im
Gegensatz zu dem eher klassischen geometriebasierten Rendering korreliert der Aufwand dabei nicht
mit der Komplexität der zugrunde liegenden Szene. Mittlerweile wurden eine Reihe von Verfahren ent-
wickelt, die Image-Based-Rending für verschiedene Problemstellungen verwenden. Diese reichen von
der Texturierung von Oberflächen bis zur Erstellung von Panoramabildern. Dabei existieren sowohl reine
bildbasierende Ansätze, als auch Mischformen unter Verwendung von Geometriedaten. Einen allgemei-
nen Überblick über diese Verfahren und deren Einordnung bieten Shum et al. [SKC03].
Einen Ansatz von Image-Based-Rendering verfolgen Salama et al. [RSTK08] sowie Levoy und Hanra-
hanmit [LH96] mit Light-Fields. Light-Fields stellen die Lichtverteilung für jeden Punkt im dreidimen-
sionalen Raum dar. Für die Erstellung eines Light-Fields werden je nach Qualität bis zu mehrere hundert
Bilder aus verschiedenen Kameraperspektiven benötigt, die als zweidimensionale Projektion des Light-
Field betrachtet werden. Die Erzeugung eines Light-Fields ist damit sehr aufwendig. In Verbindung mit
einem langsamen Netzwerk kann dieser Initialisierungsvorgang mehrere Minuten dauern. Da eine Be-
trachtung der Visualisierung unmittelbar möglich sein soll, scheidet die Verwendung von Light-Fields
als Lösungsansatz für diese Arbeit aus.
Auf Grundlage von nur zwei Referenzbildern arbeitet das Verfahren von Stich et al. [SLW+08]. Dabei
werden die Referenzbilder in homogene Bereiche unterteilt, also Bereiche, die nach der menschlichen
Wahrnehmung als zusammengehörig empfunden werden. Die im Referenzbild dargestellte Oberflächen-
geometrie der zugrunde liegenden Szene wird durch die Translation der homogenen Bereiche von einem
8 2. VERWANDTE ARBEITEN
Referenzbild zum anderen rekonstruiert. Die Bestimmung von homogenen Bereichen ist dabei zu auf-
wendig und zu ungenau, weshalb sie hauptsächlich bei der Rekonstruktion von Realbildern angewandt
wird, da diese neben den Farbdaten keine zusätzlichen Informationen liefern können.
Handelt es sich bei den Referenzbildern um gerenderte Bilder, wie es in der wissenschaftlichen Vi-
sualisierung der Fall ist, stehen neben den Farbinformationen für gewöhnlich auch die Tiefendaten zur
Verfügung. Diese werden während des Renderings pixelgenau berechnet und liefern wertvolle Informa-
tionen über die Beschaffenheit der Szene. Diesen Umstand nutzen auch die von Shade et al. [SGHS98]
vorgestellten Layered-Depth-Images. Bei einem Layered-Depth-Image handelt es sich um eine Daten-
struktur, die im Gegensatz zu einem konventionellen Bild mehrere Pixel pro Bildpunkt in verschiedenen
Ebenen entlang des Sichtstrahls speichert. Layered-Depth-Images stellen eine Lösung für ein häufiges
Problem bei der Erzeugung von Zwischenbildern aus konventionellen Bildern dar. Durch die Bewegung
der Kamera werden im Zwischenbild zum Teil Bereiche sichtbar, die im Referenzbild verdeckt waren.
Im Gegensatz zu konventionellen Bildern, die in diesem Fall für diese Bereiche keine Farbinformationen
zur Verfügung stellen, können Layered-Depth-Images durch das Speichern mehrerer Ebenen auch In-
formationen für vormals verdeckte Bereiche liefern. Darüber hinaus kann eine Zwischenbildberechnung
mit nur einem Referenzbild durchgeführt werden. Unglücklicherweise steigern Layered-Depth-Images
die Netzwerklast abhängig von der Komplexität der Szene. Eine erhöhte Latenz ist die Folge. Als wei-
terer Kritikpunkt müsste der Server auf die Erzeugung von Layered-Depth-Images angepasst werden.
Diese Voraussetzung kann jedoch nicht garantiert werden.
Einen weiteren Ansatz für das bildbasierte Rendering von Zwischenbildern liefern Chen und Williams
[CW93]. Dabei wird, basierend auf zwei Referenzbildern, die Bewegung jedes einzelnen Pixels von ei-
nem Referenzbild zum anderen in Form eines Vektors vorberechnet und in einer Korrespondenz-Map
gespeichert. Für die Berechnung der Bewegungsvektoren wird dabei zusätzlich die View-Matrix jedes
Referenzbildes benötigt. Mit dieser kann, in Verbindung mit den Bildkoordinaten und dem jeweiligen
Tiefenwert, pixelweise die View-Transformation zwischen den Referenzbildern berechnet werden. In
den Bildraum transformiert, lassen sich daraus die Bewegungsvektoren berechnen. Die Erzeugung der
Zwischenbilder erfolgt durch die lineare Interpolation der Bewegungsvektoren. Auf Grund von Ver-
deckungen kann es vorkommen, dass mehrere Pixel eines Referenzbildes auf ein Pixel des Zwischenbil-
des abgebildet werden. Im Umkehrschluss bedeutet das, dass nicht für jedes Pixel im Zwischenbild ein
Farbwert zur Verfügung stehen muss. Die Folge sind Löcher in der Darstellung.
Diese Schwachstelle greift Mark et al. [MMB97] auf und stellt sehr detailliert ein ähnliches Verfahren
zu dem von Chen und Williams vor. Auch bei diesem Ansatz werden Tiefendaten für die Transforma-
tion der Kamerasicht herangezogen. Abweichend von [CW93] findet anschließend ein Image Warping
9
im dreidimensionalen Raum statt, bei dem die Oberfläche des durch das Referenzbild sichtbaren Sze-
nenausschnitts rekonstruiert wird. Da das Verfahren dabei bereits Zwischenbilder aus einem einzigen
Referenzbild erzeugen kann, erfüllt es die gestellten Anforderungen und wird im Folgenden als Refe-
renzverfahren für diese Arbeit verwendet.
10 2. VERWANDTE ARBEITEN
11
3 Das Verfahren
In dieser Arbeit wurde, basierend auf dem Ansatz von [MMB97], ein Verfahren umgesetzt, mit dem es
möglich ist, die negativen Effekte zu verbergen, die bei Interaktionen durch die netzwerkbedingt verzö-
gerte Kommunikation zwischen Server und Client auftreten. Dabei handelt es sich zum einen um eine
spürbare Verzögerung zwischen der Eingabe des Nutzers und der Ausgabe der entsprechenden Darstel-
lung, die die Interaktion mit der Visualisierung erschwert. Zum anderen sinkt die Bildwiederholfrequenz,
wodurch die Anzeige einer kontinuierlichen Kamerabewegung nicht mehr möglich ist.
Die Erzeugung von Zwischenbildern ist bei dem umgesetzten Verfahren bereits mit nur einem Referenz-
bild möglich. Da es in Folge der Transformation zur Darstellung von Bildbereichen kommt, die über den
Informationsgehalt des Referenzbildes hinausgehen, wird dieses Vorgehen im Weiteren als Extrapolation
bezeichnet.
Der Informationsgehalt eines Referenzbildes reicht oft nicht aus, um alle Bereiche korrekt darzustellen.
Aus diesem Grund geht das Verfahren von [MMB97] über die reine Extrapolation hinaus. Dazu werden
die Bildinformationen mehrerer Referenzbilder ausgewertet. Im weiteren Verlauf der Arbeit wird dieses
Vorgehen als Komposition bezeichnet.
3.1 Bildextrapolation
Bei der Extrapolation wird das Referenzbild auf ein regelmäßiges Mesh abgebildet, dessen Vertices mit
Hilfe der Tiefendaten in ihre Objektkoordinaten zurücktransformiert werden. Für die Erzeugung der
Zwischenbilder werden diese Objektkoordinaten anschließend in den Sichtraum der Zwischenbildkame-
ra transformiert. Anschließend wird die Oberflächengeometrie aus den Informationen des Referenzbildes
rekonstruiert. Besonders an den Objektkanten werden dabei Bereiche sichtbar, die im Referenzbild ver-
deckt wurden. Aus diesem Grund müssen die Objektkanten erkannt und gesondert betrachtet werden.
12 3. DAS VERFAHREN
3.1.1 View-Transformation
Bei der Extrapolation wird die Oberflächengeometrie der Szene aus den Referenzbilddaten extrahiert, um
dann für die neue Kamerasicht perspektivisch korrekt transformiert werden zu können. Dafür wird jeder
Bildpunkt als ein Vertex der Oberflächengeometrie betrachtet. Die Koordinaten der Vertices liegen in den
Referenzbildern in Fensterkoordinaten vor. Die Fensterkoordinaten xw und yw ergeben sich dabei aus
den Bildpunktkoordinaten. Das Tiefenbild liefert zusätzlich die z-Koordinate zw. Für die Extraktion der
Geometrie ist eine Rücktransformation der Fensterkoordinaten in die ursprünglichen Objektkoordinaten
(xobj, yobj, zobj, wobj)T notwendig. Dafür müssen die einzelnen Teiltransformationen rückgängig gemacht
werden, die bei dem klassischen geometriebasierten Rendering durchgeführt werden.
Im ersten Schritt werden die Fensterkoordinaten in die normalisierten Gerätekoordinaten (xndc, yndc, zndc)T
transformiert, das bedeutet, sie werden in den Wertebereich [0, 1] umgerechnet. Die Fensterkoordinaten
xw und yw besitzen die Wertebereiche [0, w] bzw. [0, h] basierend auf Breite w und Höhe h des Refe-
renzbildes. Die Koordinate zw liegt als Grauwert im Bereich [0, 1] im Tiefenbild. Es ergibt sich damit
folgende Umrechnung:
xndc
yndc
zndc
= 2 ·
xw/w
yw/h
zw
−1
1
1
(3.1)
Die damit berechneten Vertex-Koordinaten erzeugen ein gleichmäßiges Gitter das zwischen den Bildrän-
dern aufgespannt wird. Dies ist jedoch nicht korrekt, denn die Farbinformationen wurden entlang des
Sichtstrahls durch den Mittelpunkt jedes Pixels in die Bildebene projiziert. Für die Berechnung der Pixel-
mittelpunkte wird die Gleichung angepasst. Dabei wird 1/w als Pixelbreite wpixel und 1/h als Pixelhöhe
hpixel definiert:
xndc
yndc
zndc
=
(0, 5 · wpixel) + (2 · xw/w − 1) · (1− wpixel)
(0, 5 · hpixel) + (2 · yw/h− 1) · (1− hpixel)
2 · zw − 1
(3.2)
Für die anschließende Rücktransformation in die Clip-Koordinaten wird die Komponente wclip benötigt.
Diese Komponente geht im Zuge des w-Clip in die Koordinaten (xclip, yclip, zclip)T ein und kann somit
nicht aus den normalisierten Gerätekoordinaten rekonstruiert werden. Bei dem klassischen Rendering be-
rechnet sich wclip bei der Transformation der Augkoordinaten (xeye, yeye, zeye)T in die Clip-Koordinaten
mit Hilfe der Projection-Matrix. Die Struktur der Projection-Matrix ist dabei allgemeingültig und errech-
net sich aus den Begrenzungen des View-Frustums, links l und rechts r, oben t und unten b sowie vorn
3.1. BILDEXTRAPOLATION 13
n und hinten f .
xclip
yclip
zclip
wclip
=
2nr−l 0 r+l
r−l 0
0 2nt−b
t+bt−b 0
0 0 −(f+n)f−n
−2fnf−n
0 0 −1 0
·xeye
yeye
zeye
weye
(3.3)
Bei der Transformation von Punkten wird die Komponente wobj mit dem Wert 1 belegt. Dieser Wert
wird durch die View-Matrix nicht verändert, wodurch auch weye diesen Wert besitzt. Es ergeben sich die
Zusammenhänge:
zclip = zeye ·−(f + n)
f − n+−2fnf − n
(3.4)
wclip = −zeye (3.5)
Im Zuge des w-Clip werden xclip, yclip und zclip durch die Komponente wclip dividiert, um damit die nor-
malisierten Gerätekoordinaten zu berechnen. Für die Rücktransformation ergibt sich daraus für zndc die
Gleichung 3.6. Damit kann die Komponente wclip, unter Zuhilfenahme von Gleichung 3.4 und Gleichung
3.5 wie folgt berechnet werden:
wclip =zeye
zndc(3.6)
wclip =−2fn
zw · (f − n)− (f + n)(3.7)
Liegen die Vertices in Clip-Koordinaten vor, können sie mit Hilfe der zu dem Referenzbild gehörenden
View-Matrix MrefView und der Projection-Matrix MrefProj in ihre ursprünglichen Objektkoordinaten trans-
formiert werden. Die damit rekonstruierten Geometriedaten werden unter Verwendung der View-Matrix
MinterView und der Projection-Matrix MinterProj in die Fensterkoordinaten des Zwischenbildes übertragen.
xclip
yclip
zclip
wclip
inter
= MinterProj ·MinterView ·M−1refView ·M
−1refProj ·
xclip
yclip
zclip
wclip
ref
(3.8)
14 3. DAS VERFAHREN
3.1.2 Rekonstruktion der Oberfläche
Bei einem gerenderten Bild handelt es sich um die diskrete Farbabtastung der zugrunde liegenden Szene
(Abbildung 3.1a). Werden diese diskreten Bildpunkte in ihre ursprünglichen Objektkoordinaten zurück
transformiert, existieren die Bilddaten nicht mehr als geschlossenes Bild sondern als Menge von Vertices
im dreidimensionalen Raum (Abbildung 3.1b). Soll diese Punktwolke auf die Bildebene des Zwischen-
bildes projiziert werden, ist nicht sichergestellt, dass jeder Vertex auf genau ein Pixel abgebildet wird.
Auf Grund von Verdeckung oder perspektivischer Transformation kann es vorkommen, dass mehrere
Vertices auf ein Pixel abbilden. Ebenso können sich Vetices aus dem Bereich des sichtbaren Bildraums
herausbewegen. Sie werden damit auf kein Pixel abgebildet.
Die fehlende Bijektivität dieser Transformation hat zur Folge, dass nicht garantiert werden kann, dass je-
dem Pixel ein Farbwert zugeordnet wird, was zu sichtbaren Löchern im Bild führt. Da jeder Vertex einem
Pixel des Referenzbildes entspricht, können Werte dazwischen nur durch Interpolation bestimmt werden.
Dazu wird ein reguläres Mesh über den Vertices aufgespannt, dass eine geschlossene Oberfläche erzeugt
(Abbildung 3.1c). Für eine bessere Abgrenzung zu den Meshs, die der Server für das geometriebasier-
te Rendering verwendet, wird das Mesh des Clients im folgenden als Bild-Mesh bezeichnet. Die durch
dieses Bild-Mesh erzeugte Geometrie ist eine Approximation der im Referenzbild sichtbaren Oberflä-
chengeometrie. Wird das Referenzbild mittels Texture-Mapping auf das Bild-Mesh abgebildet, kann die
Grafikkarte die notwendigen Zwischenwerte mittels Interpolation innerhalb der Dreiecke des Bild-Meshs
berechnen.
(a) (b) (c)
Abbildung 3.1: (a) Menge von Vertices vor der Rücktransformation, (b) Menge von Vertices nach der
Rücktransformation, (c) Vertices verbunden durch reguläres Bild-Mesh
3.1. BILDEXTRAPOLATION 15
3.1.3 Kantendetektion
Durch die Erzeugung einer geschlossenen Oberfläche ist es nicht möglich, mehrere Tiefenebenen unab-
hängig darzustellen. Aus diesem Grund werden Objekte, die zwar räumlich voneinander getrennt sind,
sich aber im Referenzbild teilweise verdecken, an ihren Kanten miteinander verbunden. Dieser Effekt
tritt auch zwischen Objekten und dem Hintergrund auf. Da er den Bildeindruck erheblich verschlechtert,
ist es notwendig, Objektkanten zu lokalisieren, um die Bildpunkte dazwischen gesondert behandeln zu
können.
[MMB97] verwendet für diesen Zweck die Oberflächennormalen jedes einzelnen Bildpunktes, die vom
Server bei der Bildsynthese mitberechnet werden müssen. Da es diese Daten dann zusätzlich zu den
Farb- und Tiefeninformationen an den Client zu senden gilt, steigt die Netzwerklast.
Zur Vermeidung einer erhöhten Netzwerklast wird eine Kantendetektion eingesetzt, die ohne zusätzliche
Informationen durch den Server angewendet werden kann. Kantendetektion in Bildern wird häufig mit
Operatoren umgesetzt, die starke Änderungen von Bildeigenschaften anzeigen. So wäre es möglich, mit
Hilfe der Farbdaten, das Referenzbild in farblich homogenen Segmente aufzuteilen. Die Segmentgrenzen
würden dabei die Objektkanten darstellen. Die Kantendetektion auf Basis der Farbdaten setzt jedoch
besondere Eigenschaften an die Szene voraus. Zum einen dürfen zusammenhängende Flächen selbst
keine starken Farbwechsel aufweisen, zum anderen werden Kanten nicht erkannt, wenn sich verdeckende
Objekte ähnliche oder gar die gleiche Farbe besitzen. Da diese Eigenschaften nicht garantiert werden
können, ist eine Kantendetektion mittels Farbdaten zu fehleranfällig.
Stattdessen wird die Kantendetektion auf Grundlage der Tiefendaten durchgeführt. Im Gegensatz zu
Objektoberflächen, die in den meisten Fällen einen kontinuierlichen Verlauf der Tiefenwerte besitzen,
sind Objektgrenzen durch sprunghafte Wertänderungen erkennbar. Für die Kantendetektion wird der
Lagrange-Operator verwendet. Im Vergleich zu anderen häufig verwendeten Kantendetektionfiltern, wie
dem Sobel-Operator, kann der Laplace-Operator die Richtung der Wertänderung anzeigen [SC12]. Je
nachdem, ob es sich bei einem Kanten-Vertex um die Kante des vorderen oder des hinteren Objekts
handelt, ist der Wert positiv bzw. negativ. Dieser Eigenschaft wird für die folgende Behandlung der
Objektkanten verwendet.
3.1.4 Behandlung von Kantenübergängen mittels Heuristik
Bei den Dreiecken, die sich an Objektkanten aufspannen handelt es sich um Geometrie, die in der Aus-
gangsszene nicht vorhanden war. Anstatt diese zu entfernen, wird eine Heuristik angewandt, bei der die
Kantenregion mit dem Farbwert der dahinter liegenden Oberfläche belegt wird. Da diese verdeckt wird,
16 3. DAS VERFAHREN
stehen über diese Oberfläche jedoch keine Informationen zur Verfügung. Aus diesem Grund wird ange-
nommen, dass der Farbwert, der an den Objektgrenzen besteht, hinter dem vorderen Objekt unverändert
weitergeführt wird, wie in Abbildung 3.2 dargestellt. Dazu wird der Farbwert der Kanten-Vertices der
hinteren Oberfläche auf die Kanten-Vertices der vorderen Oberfläche übertragen. Mittels Flat-Shading
werden die Grenzdreiecke so mit einer konstanten Farbe versehen, die dem lokalen Hintergrund ent-
spricht.
Abbildung 3.2: Anwendung einer Heuristik an Objektkanten (Original [MMB97])
Die Bestimmung der Hintergrundfarbe wird nach [MMB97] für jedes Kantendreieck durchgeführt. Dazu
werden die Tiefenwerte der Vertices eines Kantendreiecks aus Sicht der Zwischenbildkamera vergli-
chen. Die Farbe des Vertex, der die größte Distanz aufweist, wird als lokale Hintergrundfarbe für das
Flat-Shading angenommen. Die dafür notwendige Zugehörigkeit der Vertices zu einem Dreieck ist je-
doch nur im Geometry-Shader bekannt. Dieser wird in der aktuellen OpenGL ES Version für Android
3.0 nicht unterstützt. Ohne die Zugehörigkeit zu einem Dreieck muss die lokale Hintergrundfarbe für
jeden Kanten-Vertex über alle acht angrenzenden Vertices bestimmt werden. Würden nicht alle Nachbar-
Vertices geprüft, könnte es vorkommen, dass die Vertices ignoriert werden, die für das Erkennen eines
Kanten-Vertex durch den Lagrange-Operator verantwortlich waren. Abbildung 3.3 zeigt diesen Fall an-
hand einer diagonal verlaufenden Kante.
Abbildung 3.3: Vordergrund-Vertex und zu findender Hintergrund-Vertex (gestrichelter Pfeil)
Die Auswahl der Hintergrund-Vertices ist nicht immer optimal. So kann es vorkommen, dass der gefun-
dene Vertex nicht Teil des Kantendreiecks ist, das aktuell betrachtet wird. Da es sich hierbei um eine
3.1. BILDEXTRAPOLATION 17
Heuristik handelt, ist diese Problematik jedoch vernachlässigbar.
Wird das Flat-Shading auf alle Bildpunkte der Kantendreiecke angewendet, sind auch diejenigen be-
troffen, die Teil der eigentlichen Objektkanten sind. Im Fall der Kante des Hintergrundobjekts ist dies
unerheblich, da dessen Farbe für das Flat-Shading verwendet wird und somit ein kontinuierlicher Über-
gang entsteht. Bei dem Vordergrundobjekt hingegen führt es zur Entfernung der Kantenpixel. Um das
zu verhindern, müssen diese Pixel von der Objektkantenverarbeitung ausgenommen werden. Dazu wird
ein künstlicher Verlauf mittels einer zusätzlichen Vertex-Variable hinzugefügt, die als Kantenhöhe be-
zeichnet werden kann. Dabei erhalten die Vertices des vorderen Objekts den Wert 1,0, die des hinteren
Objekts den Wert -1,0. Das Flat-Shading wird ausschließlich für die Kantenpixel durchgeführt, deren
Kantenhöhe unter einem definierten Schwellwert liegen (Abbildung 3.4).
Abbildung 3.4: Verlauf des Kantenhöhenwerts
Verdecken sich mehr als zwei Objekte gegenseitig, kann es vorkommen, dass Kantenpixel des mittle-
ren Objekts sowohl dem Vorder- als auch dem Hintergrund zugeordnet werden können. Dies tritt auf,
wenn die sichtbare Kante des mittleren Objekts eine Ausdehnung von nur einem Pixel besitzt. Befinden
sich diese Pixel an einer horizontal bzw. vertikal verlaufenden Kante, heben sich die Abstände bei etwa
gleicher Entfernung zu Vorder- und Hintergrundobjekt auf und die Kantendetektion erkennt diese Pixel
nicht mehr als Kantenpixel. In diesem Fall wird die Kantenhöhe nicht verändert und behält den initialen
Wert 0,0. Da ausschließlich Pixel von der Heuristik ausgeschlossen werden, die den Schwellwert nahe
1,0 überschreiten, werden die Kantenpixel mittels Flat-Shading mit den Farbwerten des Hintergrund-
objekts belegt. Für das Flat-Shading zwischen dem mittleren und dem vorderen Objekt werden jedoch
korrekterweise die Farbwerte des mittleren Objekts verwendet.
Verläuft die sichtbare Kante des mittleren Objekts weder horizontal noch vertikal oder unterscheiden sich
die Entfernungen des mittleren Objekts zu Vorder- und Hintergrundobjekt, erhalten die Kantenpixel die
selbe Kantenhöhe wie die Oberfläche, die die geringere Distanz aufweist. Erhalten sie die Kantenhöhe
-1,0, befinden sie sich unter dem Schwellwert und es tritt der selbe Fall ein, wie im vorangegangenen
18 3. DAS VERFAHREN
Abschnitt. Wird die Kantenhöhe 1,0 zugeordnet, werden alle Pixel der Kantendreiecke zwischen Vor-
dergrundobjekt und mittlerem Objekt von der Heuristik ausgenommen. Es kommt zur Interpolation der
Farbwerte. An dieser Stelle weist das Verfahren einen Schwachpunkt auf.
3.2 Komposition aus mehreren Referenzbildern
Die Erzeugung von Zwischenbildern ist mittels Extrapolation mit nur einem Referenzbild möglich. Die-
se Eigenschaft, die für eine geringe Startverzögerung sorgt, macht die Extrapolation überaus attraktiv für
die angestrebte Remote-Visualisierung. Auf der anderen Seite sind die Informationen, die aus nur einem
Referenzbild gewonnen werden können, äußerst begrenzt. Aus diesem Grund ist das in [MMB97] behan-
delte Verfahren auf die Zusammenführung von Informationen aus mehreren Referenzbildern ausgelegt.
Dabei ist es möglich, dass Bildbereiche in mehr als einem Referenzbild vorkommen. Tritt dieser Fall ein,
gilt es zu entschieden, von welchem Referenzbild die Information übernommen werden soll. Entschieden
wird auf Grundlage von drei Kriterien:
Entscheidungskriterium Objektkanten
Das erste Kriterium ist die Behandlung von Objektkanten. Wie im Kapitel 3.1.4 beschrieben, gehen Ob-
jektkanten immer mit Verdeckungen einher. Dabei wurden die verdeckten Bereiche mit Hilfe einer Heu-
ristik approximiert. Stehen in anderen Referenzbildern reale Bildinformationen über verdeckte Bereiche
zur Verfügung, sind diese in das resultierende Zwischenbild zu übernehmen.
Entscheidungskriterium transformierter Tiefenwert
Ein weiteres Entscheidungskriterium ist der transformierte Tiefenwert. Dabei handelt es sich um die z-
Komponente eines Vertex nach der View-Transformation. Unterscheiden sich die transformierten Tiefen-
werte der Referenzpixel, existiert in einem Referenzbild ein Objekt, das in dem anderen nicht vorkommt,
zum Beispiel weil es verdeckt wurde. Da es sich um eine Oberflächenrekonstruktion handelt, ist das Pixel
zu wählen, das das Objekt mit der geringeren Distanz zum Betrachtungspunkt darstellt.
Entscheidungskriterium Abtastung
Bei dem dritten Entscheidungskriterium muss entschieden werden, wie gut eine Oberfläche abgetastet
werden kann. Verursacht durch das Texture-Mapping werden Bildbereiche sowohl gestreckt als auch
gestaucht. Im Falle einer Streckung kommt es zu einer Unterabtastung, was zur Verwendung von inter-
polierten Werten führt. Unterabtastung tritt meist dann auf, wenn sich schräge Oberflächen dem Betrach-
ter zuwenden und damit der eingenommene Flächeninhalt im Bildraum zunimmt. Um ein Verhältnis
für die Abtastung zu erhalten, wird für jedes Pixel die Fläche bestimmt, die es im Referenzbild bzw.
im Zwischenbild einnimmt. Da das Pixel im Referenzbild untransformiert vorliegt, berechnet sich der
3.2. KOMPOSITION AUS MEHREREN REFERENZBILDERN 19
Flächeninhalt aus der Multiplikation von Pixelbreite wpixel und Pixelhöhe hpixel. Für das Zwischenbild
werden die Eckpunkte des Pixels auf die selbe Weise in den Bildraum des Zwischenbildes transformiert
wie dessen Mittelpunkt (vgl. Kapitel 3.1). Die Fläche des dabei resultierenden Polygons kann wie in
[Bou88] beschrieben, berechnet werden. Dazu wird ein beliebiger Referenzpunkt gewählt, zur Vereinfa-
chung in diesem Fall der Koordinatenursprung. Zwischen ihm und jeder Kante cici + 1 des Polygons wird
ein Dreieck aufgespannt (Abbildung 3.5).
Abbildung 3.5: Berechnung des Flächeninhalts eines Polygons mittels zusätzlicher Dreiecke
Der Flächeninhalt jedes Dreiecks lässt sich über das Kreuzprodukt berechnen. Dessen Betrag ist de-
finiert durch Formel 3.9. Dadurch, dass es sich um ein projiziertes Polygon handelt, besitzen die z-
Komponenten der Punktvektoren den Wert 0. Die Formel vereinfacht sich dadurch stark (Formel 3.10).
Acici + 1 =1
2· (ci × ci + 1) (3.9)
Acici + 1 =1
2· (xi · yi + 1 − xi + 1 · yi) (3.10)
Dabei besitzen die braunen Dreiecke in Abbildung 3.5 eine Orientierung im Uhrzeigersinn wogegen die
Orientierung der blauen Dreiecke gegen den Uhrzeigersinn verläuft. Das hat zur Folge, dass der Flä-
cheninhalt der blauen Dreiecke negativ ist. Dieses Verhalten ist dabei durchaus erwünscht. Denn um den
Flächeninhalt des Polygons zu berechnen, werden die Flächen der aufgespannten Dreiecke aufsummiert,
wie in Formel 3.11 zu sehen, wobei N die Anzahl der Vertices ist. Dabei gilt zu beachten, dass die brau-
nen Dreiecke neben der Fläche des Polygons zusätzlich eine Fläche außerhalb dessen einnehmen, die
exakt der der blauen Dreiecke entspricht.
Ac =1
2·
N-1∑i=0
xi · yi + 1 − xi + 1 · yi (3.11)
20 3. DAS VERFAHREN
Das Verhältnis zwischen dem Flächeninhalt vor und nach der Transformation gibt Aufschluss darüber,
wie gut die Abtastung ist. Ist der Wert größer als eins hat sich die Oberfläche dem Betrachtungspunkt
zugewandt und nimmt dadurch eine größere Fläche ein. Die Abtastung sinkt dabei. Als Entscheidungs-
kriterium stellt somit ein kleinerer Wert die bessere Abtastung dar.
3.2.1 Iterative Zusammenführung von Bildinformationen
Für die Zusammenführung mehrerer Referenzbilder wird ein iterativer Algorithmus angewandt. Das be-
deutet, dass die Informationen der Referenzbilder nacheinander in das Zwischenbild eingefügt werden.
Dieses Vorgehen ist notwendig, denn würden die Bild-Meshs aller Referenzbilder in einem Rendervor-
gang behandelt werden, würden viele Informationen auf Grund des Tiefentests bereits vor der Verarbei-
tung entfernt werden. Aus den vorangegangenen Abschnitten geht jedoch hervor, dass es neben dem Tie-
fenwert noch andere Entscheidungskriterien zu prüfen gilt. Daraus folgt, dass für jedes Referenzbild die
View-Transformation sowie die Rekonstruktion einzeln durchgeführt werden. Die resultierenden Bildda-
ten werden mittels der Entscheidungskriterien aus den vorangegangenen Kapiteln pixelweise mit denen
des aktuellen Zwischenbildes verglichen. In Abbildung 3.6 wird die Entscheidungsabfolge dargestellt.
Abbildung 3.6: Aktivitätsdiagramm über die Entscheidung zwischen aktuellem Zwischenbildpixel und
Referenzbildpixel
3.2. KOMPOSITION AUS MEHREREN REFERENZBILDERN 21
Es erscheint ungewöhnlich, dass der transformierte Tiefenwert für den Fall, dass es sich bei beiden Pi-
xeln um Kantenpixel handelt, keine Rolle spielt. Doch in diesem Fall besitzen beide Pixel keine korrekten
Informationen über das Aussehen des Pixels im Zwischenbild. Somit ist es unerheblich, von welchem
Referenzbild die Farbinformation verwendet wird. Dagegen liefert laut [MMB97] der Vergleich der Ab-
tastung weitestgehend den korrekten Farbwert.
3.2.2 Berechnung der Kamerasichten für Referenzbilder
Für die Berechnung der Kamerasichten der einzelnen Referenzbilder verwenden [MMB97] ein Vorgehen
bei dem eine Vorhersage über die zukünftige Kameraposition aus den vergangenen Positionen getroffen
wird. Aus den berechneten Referenzbildern werden zwei ausgewählt, die für die Komposition verwendet
werden. Dabei handelt es sich um das Referenzbild, das sich in der Nähe einer definierten Position der
Vergangenheit befindet und dem Referenzbild, welches nah an der vorausberechneten Position liegt.
Dieses Vorgehen weist eine gewisse Ungenauigkeit auf, die vor allem bei schnellen Richtungswechseln
eintritt.
Aus diesem Grund wurde ein Verfahren entwickelt, welches mit sich ändernden Kamerabewegungen
umgehen kann. Das Verfahren ist dabei auf die Freiheitsgrade der angestrebten Orbit-Kamera ausgelegt.
Bei einer Orbit-Kamera handelt es sich um eine Kamera, deren Sicht auf einen festgelegten Fixpunkt
ausgerichtet ist. Die Position der Orbit-Kamera wird dabei durch die Parameter Längenwinkel und Brei-
tenwinkel sowie die Entfernung zum Fixpunkt eindeutig bestimmt. Der Freiheitsgrad, der sich durch
den Roll-Winkel ergibt wird dagegen nicht weiter betrachtet. Bewegt der Nutzer die Orbit-Kamera um
die Szene herum ist nicht vorhersehbar, in welche Richtung die Bewegung ausgeführt wird. Aus diesem
Grund wird um die aktuelle Kameraposition ein gleichseitiges Dreieck aufgespannt, dessen Eckpunkte
die Kamerapositionen der Referenzbilder darstellen. Diese werden für die Erzeugung der Zwischenbil-
der mittels Komposition verwendet. Ein ähnliches Vorgehen wird in [RSTK08] für die Erzeugung eines
Light-Fields verwendet. Darin werden die Kamerapositionen auf dem Umkreis durch die Eckpunkte
eines Ikosaeders definiert.
Wie bei [RSTK08] sollen alle Kamerapositionen auf der Umkugel liegen, die durch die Distanz r1 der ak-
tuellen Kameraposition m2 zum Fixpunkt m1 definiert wird. Für die Berechnung der dreidimensionalen
Eckpunktkoordinaten des gleichseitigen Dreiecks, wird der Radius einer zweiten Umkugel r2 definiert,
der die Distanz zwischen der aktuellen Kameraposition und der Kameraposition der Referenzsichten
angibt. Der Schnittkreis beider Umkugeln bildet den Koordinatenraum der Eckpunkte des Dreiecks.
Aus den Eigenschaften der beiden Teildreiecke lässt sich der Abschnitt a1 der Abbildung 3.7 berechnen
(Formel 3.12). Außerdem lässt sich der Radius des Schnittkreises hk bestimmen (Formel 3.13).
22 3. DAS VERFAHREN
Abbildung 3.7: Geometrische Berechnung des Schnittkreisradius
a1 =2r1
2 − r22
2r1(3.12)
hk =√r12 − a12 (3.13)
Zusätzlich wird der Mittelpunkt des Umkreises m3 berechnet, indem der Vektor zwischen der aktuellen
Kameraposition und dem Fixpunkt die Länge a1 erhält, wie folgende Formeln zeigen:
~d = m2 −m1 (3.14)
m3 = a1 ·~d
|~d|+m1 (3.15)
Für die Bestimmung des ersten Dreieckspunkts wird ein Vektor benötigt, der ausgehend von m3 orthogo-
nal auf dem Richtungsvektor d steht und die Länge hk besitzt. Zu diesem Zweck erhält die Orbit-Kamera
den Vektor ~u mit den Koordinaten (0, 1, 0)T , der bei der Bewegung der Kamera mit transformiert wird.
Dieser Vektor steht orthogonal auf dem Sichtvektor der Kamera, der dem Gegenvektor von ~d entspricht.
Die Berechnung des ersten Dreieckspunkt t1 erfolgt durch die Formel:
t1 = hk · ~u+m3 (3.16)
Da es sich bei dem gesuchten Dreieck um ein gleichseitiges Dreieck handelt, können die beiden Punkte
t2 und t3 dadurch ermittelt werden, dass der Vektor ~u um jeweils einen Winkel von 120◦ gedreht wird.
Die anschließende Berechnung erfolgt wie in Formel 3.16.
3.2. KOMPOSITION AUS MEHREREN REFERENZBILDERN 23
3.2.3 Kamerasichten vom Server abrufen
Da für eine Komposition mehrere Referenzbilder benötigt werden, dauert es länger als bei der Extrapo-
lation, bis sie erste Zwischenbilder liefern kann. Aus diesem Grund wird die Komposition im Gegensatz
zum Ansatz von [MMB97], der das Augenmerk auf diese gelegt hat, in dieser Arbeit nur ergänzend zur
Extrapolation eingesetzt. Werden Referenzbilder vom Server abgerufen ist deshalb die Extrapolation zu
bevorzugen, weshalb wie folgt verfahren wird. Die Anwendung beginnt mit einer Extrapolation, um un-
mittelbar reagieren zu können. Bewegt sich die Kamera, wird weiterhin die Extrapolation angewandt.
Hat sich die Kameraposition seit der letzten Anfrage nicht verändert, ist es nicht notwendig, die selben
Bildinformationen ein weiteres Mal abzufragen. Stattdessen kann mit dem Laden der drei Referenzbilder
für die Komposition begonnen werden. Wurden diese Referenzbilder abgerufen, können die fehlenden
Referenzbilder für die angrenzenden Dreiecke abgerufen werden. Diese werden verwendet, wenn die Ka-
mera das aktuell aufgespannte Dreieck verlässt. Wird die Kamera während der Komposition nicht mehr
bewegt, wird ein Referenzbild aus der aktuellen Kamerasicht angefordert, um die exakten Bildinforma-
tionen anzeigen zu können. Erreicht die Kamera dagegen den Außenbereich eines Dreiecks, ist davon
auszugehen, dass sich die Kamera schneller bewegt, als Referenzbilder für eine Komposition geladen
werden konnten. In diesem Fall wird wieder die Extrapolation durchgeführt. Da die Komposition auch
außerhalb des Dreiecks durchgeführt werden kann, bleibt diese so lang aktiv, bis das erste Referenzbild
für die Extrapolation empfangen wurde.
24 3. DAS VERFAHREN
25
4 Implementierung
In diesem Kapitel wird dargelegt, wie die Software für diese Arbeit implementiert wurde. Die Entwick-
lung sowohl der Desktop-Anwendungen als auch der Android-App wurde mit der Programmiersprache
Java realisiert. Als Entwicklungsumgebung wurde dabei Eclipse in der Version 4.3.2 verwendet.
4.1 Gesamtarchitektur
Neben der eigentlichen Remote-Anwendung für Android, die als Client fungiert, wurde im Zuge dieser
Arbeit ebenfalls ein Remote-Server für den Desktop implementiert. Dieser Server übernimmt dabei das
klassische geometriebasierte Rendering der Szene. Der Datenaustausch zwischen Client und Server er-
folgt über eine TCP/IP Verbindung. Die Netzwerkkommunikation wird dabei durch das Java Framework
Netty 4.0.19 umgesetzt.
Abbildung 4.1: Netzwerkkommunikation zwischen Android-Client und Desktop-Server als
Sequenzdiagramm
26 4. IMPLEMENTIERUNG
Benötigt der Client ein Referenzbild, sendet er eine Anfrage an den Server. Darin ist die View-Matrix der
anzufordernden Kamerasicht hinterlegt. Die perspektivischen Informationen, wie der Öffnungswinkel
der Kamera, die vordere und hintere Begrenzung des Frustums, sowie das Verhältnis zwischen Breite
und Höhe des Sichtfensters werden nicht übermittelt. Sie werden auf Client- wie auch auf Server-Seite
auf einen identischen Wert festgelegt.
Empfängt der Server eine Anfrage vom Client verarbeitet er diese, indem er die übertragene View-Matrix
für den nächsten Rendering-Durchgang verwendet. Nach Abschluss dessen, werden die erzeugten Farb-
und Tiefendaten an den Client zurückgesendet. Ebenfalls zurückgesendet werden die Projection-Matrix
für die Rücktransformation sowie die Hintergrundfarbe der Szene damit diese zwischen Client und Ser-
ver identisch ist. Da es keine besonderen Anforderungen an den Server gibt, wurde er so implementiert,
dass er nur eine Anfrage zur selben Zeit bearbeiten kann. Im Umkehrschluss bedeutet das für den Client,
dass er eine neue Anfrage erst dann stellt, wenn die letzte Antwort empfangen wurde. Der Kommunika-
tionsablauf der Remote-Visualisierung ist in Abbildung 4.1 dargestellt.
Da es auch keine Vorgaben für die zwischen Server und Client stattfindende Kommunikation gibt, werden
sowohl die View-Matrix vom Client als auch die Bilddaten vom Server in einen Bytestream umgewandelt
und unkomprimiert übertragen. Dies mag den vorangegangenen Bemühungen widersprechen, die Netz-
werklast so gering wie möglich zu halten, doch im Gegensatz zum Inhalt der gesendeten Nachrichten ist
deren Komprimierung nicht Bestandteil dieser Bachelorarbeit.
4.2 Projektstruktur
Zu Testzwecken wurde neben dem Desktop-Server und dem Client für Android ebenfalls ein Test-Client
für den Desktop implementiert. Einige Bereiche der Implementierung sind dabei in mehreren Anwen-
dungen redundant. Diese werden in Bibliotheken ausgelagert (siehe Abbildung 4.2).
Klassen, die in allen drei Anwendungen benötigt werden, werden in der Bachelor Thesis Library zusam-
mengeführt. Dazu gehören neben Entitäten wie verschiedendimensionalen Vektoren auch die Bestandtei-
le zur Erzeugung eines Meshs. Ebenso wurde die Netzwerkfunktionalität in diese Bibliothek ausgelagert.
Für die Darstellung von dreidimensionalen Inhalten wird für den Server und den Test-Client JOGL in der
Version 2.1.4 verwendet. Dabei handelt es sich um einen OpenGL Wrapper für Java. Demgegenüber be-
nutzt der Android-Client den Android-eigenen Wrapper für OpenGL ES. Bei dem Tablet des Lehrstuhls
CGV, für das der Android-Client konzipiert wurde, handelt es sich um ein Nexus 7 Version 2013. Die-
ses besitzt sowohl die Hardware-Anforderungen als auch, mit Android 4.3, die Software-Bedingung für
die Benutzung des aktuellen OpenGL ES 3.0 für Android. Die Android-eigenen OpenGL Wrapper sind
4.3. DER REMOTE-CLIENT FÜR ANDROID 27
Abbildung 4.2: Projektabhängigkeiten
dabei strukturell anders implementiert als JOGL. So stellt Android die Funktionen von OpenGL in Form
von statischen Methoden zur Verfügung, unter JOGL handelt es sich dabei um Objektmethoden. Aus
diesem Grund wurden für Desktop und Android je eine eigene Integration mit OpenGL entwickelt. Da
sowohl der Server als auch der Test-Client JOGL verwenden, wurde die Funktionalität von JOGL eben-
falls in die Bibliothek Bachelor Thesis Desktop Library ausgelagert. Da für die Integration von JOGL
Entitäten benötigt werden, die bereits in der Bachelor Thesis Library definiert sind, greift die Bachelor
Thesis Desktop Library auf diese zu.
4.3 Der Remote-Client für Android
4.3.1 Architektur des Clients
Die Architektur des Clients folgt dem MVC-Pattern. Abbildung 4.3 stellt diese in Form eines Klassen-
diagramms dar. Das Diagramm wurde dabei auf die wesentlichen Bestandteile reduziert. Die Klasse An-
droidClientScene bildet das Model. Diese definiert die Inhalte der dreidimensionalen Szene. Im Fall des
Android-Clients handelt es sich dabei um das Bild-Mesh, auf das die Bilddaten, die vom Server erhalten
werden, abgebildet werden und die Kamera. Darüber hinaus wird in dieser Klasse das Render-Verhalten
definiert. Um den Zugriff zu erleichtern, werden sämtliche dafür notwendige OpenGL-Objekte direkt in
der AndroidClientScene angelegt. Das hat zur Folge, dass die OpenGL-Objekte gemeinsam behandelt
werden können, wie im Kapitel 4.3.3 dargestellt wird.
28 4. IMPLEMENTIERUNG
Abbildung 4.3: Klassendiagramm der Rendering-Architektur als MVC-Pattern
Bei der View handelt es sich um eine GLSurfaceView. Eine GLSurfaceView ist eine Android-eigene
Ansicht für die Darstellung von OpenGL-Inhalten. Neben der View für die Remote-Visualisierung wur-
den zwei weitere angelegt, um für die Anwendung eine bessere Handhabung zu erreichen. Bei der einen
View handelt es sich um ein Hauptmenü, das den Einstiegspunkt der Anwendung darstellt. Über das
Hauptmenü gelangt man zu den Einstellungen und der eigentlichen Render-Ansicht. Die View für die
Einstellungen bietet eine simple Eingabemaske für die Netzwerkdaten, bestehend aus IP-Adresse und
Portnummer.
Die Klasse RenderController stellt den Controller des MVC-Patterns dar und bildet den Vermittler zwi-
schen Model und View. Zum einen werden die, durch Nutzereingaben ausgelösten Events von der View
durch den Controller verarbeitet. In diesem Fall handelt es sich dabei um Touch-Eingaben, durch die
die Kamera gesteuert wird. Zum anderen reagiert der Controller auf die Events der OpenGL-Umgebung.
Folgende Ereignisse können dabei auftreten:• onSurfaceCreated: Wird aufgerufen, wenn die OpenGL-Oberfläche erzeugt wird
• onSurfaceChanged: Wird aufgerufen, wenn sich die OpenGL-Oberfläche ändert. Im Fall von Smart-
phones passiert das meist dann, wenn es gedreht wird und damit zwischen Hochformat und Quer-
format wechselt.
• onDrawFrame: Wird aufgerufen, wenn ein neues Bild gezeichnet werden soll.
Wird die OpenGL-Oberfläche geschlossen, werden alle damit verbunden OpenGL-Objekte entfernt und
deren Speicherplatz automatisch freigegeben. Aus diesem Grund existiert für dieses Ereignis keine Me-
thode.
4.3. DER REMOTE-CLIENT FÜR ANDROID 29
4.3.2 Kommunikation mit dem Server
Abbildung 4.4: Klassendiagramm der Netzwerkkommunikation des Android-Client
Neben dem Rendering der Szene durch OpenGL wird die Kommunikation mit dem Server asynchron,
also in einem eigene Thread ausgeführt. Der Aufbau der Netzwerkimplementierung ist in Abbildung 4.4
dargestellt. Darin werden Anfragen an den Server gestellt und dessen Antwort verarbeitet. Die Andro-
idClientScene dient dabei als Datenaustauschobjekt zwischen den Threads. Wird eine Anfrage an den
Server gestellt, wird ein SceneState-Objekt definiert, welches die bereits bekannten Informationen (Ka-
pitel 4.1) aus der AndroidClientScene liest. Im Detail handelt es sich dabei um Höhe und Breite des
Sichtbereichs sowie die View-Matrix. Beim Empfang einer Antwort werden die Daten vom Server in ein
SceneStateExtension-Objekt geschrieben, welches dem SceneState-Objekt übergeben wird und damit
die Informationen über die Szene vervollständigt. In jedem Render-Durchgang werden in der Andro-
idClientScene die aktuellen Informationen aus dem SceneState-Objekt gelesen und an die Grafikkarte
übergeben.
Die Entscheidung, die Bilddaten welcher Kamerasicht vom Server angefordert werden, obliegt dem
RequestManager. Dabei ist vor allem ausschlaggebend, ob eine Extrapolation oder eine Komposition
durchgeführt werden soll. Da die Extrapolation schneller erste Zwischenbilder liefern kann, ist sie zu
bevorzugen.
30 4. IMPLEMENTIERUNG
4.3.3 Umgang mit OpenGL-Objekten
Um das imperative Verhalten von OpenGL mit dem objektorientierten von Java zu verbinden, wurde für
jedes benötigte OpenGL-Objekt ein Wrapper für Java implementiert. Bei der Initialisierung des OpenGL-
Kontextes werden alle OpenGL-Objekte der AndroidClientScene mittels der Methode create() erzeugt.
Dabei wird das Flag isOnGpu auf true gesetzt. Jeder Wrapper speichert darüber hinaus individuelle
Eigenschaften des jeweiligen OpenGL-Objekts. Zum Beispiel speichert die Klasse Texture die aktuellen
Bilddaten der gewrappten OpenGL-Textur. Werden Eigenschaften geändert, wird das Flag isUpdated
auf false gesetzt. Damit ist das OpenGL-Objekt als nicht mehr aktuell markiert. Mit jedem Render-
Durchgang werden sämtliche OpenGL-Objekte der AndroidClientScene auf ihre Aktualität geprüft. Ist
ein Update notwendig, werden die Daten des Wrapper-Objekts an die Grafikkarte übermittelt und das
OpenGL-Objekte damit synchronisiert.
4.3.4 Optimierung der Vertex-Daten
Da es sich bei dem Bild-Mesh um ein regelmäßiges Mesh handelt, das in Höhe und Breite die Auflösung
der Bilddaten als Vertices aufweist, wird schnell eine hohe Anzahl an Vertices erreicht. Das Bild-Mesh ist
dabei statisch. Es wird bei jedem Renderdurchgang auf Grund der aktuellen Bilddaten ausschließlich für
die Anzeige transformiert. Um den Datenaustausch zwischen CPU und Grafikkarte zu reduzieren, wird
das Bild-Mesh in Form eines Vertex-Buffer-Objekt auf der Grafikkarte gespeichert. Der Austausch der
Mesh-Daten wird dadurch nur einmal zu Beginn der Anwendung durchgeführt, statt zu jedem Render-
Durchgang. Ein reguläres Dreiecks-Mesh, wie es für die Anwendung in dieser Arbeit notwendig ist, kann
durch Triangle-Strips definiert werden, jedoch nur schwer durch einen einzigen. Für gewöhnlich wird das
Dreiecks-Mesh in diesem Fall in einzelne horizontale Triangle-Strips unterteilt. Um den Datenaustausch
zwischen CPU und Grafikkarte so einfach wie möglich zu halten, wird das Bild-Mesh dennoch mit nur
einem Triangle-Strip erzeugt. Da dabei zwischen den Übergängen von einer Zeile zur nächsten Ver-
bindungen durch zusätzliche Dreiecke entstehen würden, muss eine Unterbrechung des Triangle-Strips
herbeigeführt werden. Dies ist erreichbar, indem der letzte Vertex jeder Zeile doppelt angegeben wird.
Der Grafikkartentreiber erkennt Dreiecke, die identische Vertices aufweisen und verwirft sie. Da damit
die Orientierung der Dreiecke umgedreht wird, wird zusätzlich der erste Vertex jeder Zeile eingefügt.
Dadurch werden bei jedem Übergang zwei Dreiecke verworfen und die Orientierung bleibt bestehen.
Durch Triangle-Strips kann der Speicheraufwand für das Bild-Mesh gesenkt werden, da Vertices, die
einen Dreieckspunkt von mehr als einem Dreieck bilden, nicht mehrfach angegeben werden müssen. Im
Fall des Bild-Meshs stellt jeder Vertex jedoch für insgesamt sechs Dreiecke einen Dreieckspunkt dar.
Ausgenommen sind die Vertices an den Mesh-Grenzen. Um die Anzahl der anzugebenden Vertices wei-
4.4. ZWISCHENFAZIT 31
ter zu reduzieren, wurde ein Index-Buffer-Objekt hinzugefügt. Dabei erhält jeder Vertex einen Index. Ein
einmal definierter Vertex kann über seinen Index mehrfach für die Erzeugung des Bild-Meshs verwendet
werden.
Die Optimierung der Vertex-Daten wirkt sich bereits bei niedrigen Auflösungen positiv auf den Spei-
cheraufwand aus. Bei einer Größe von 128 x 128 werden ohne Optimierungen für die Float-Werte der
Positions- und Texturkoordinaten insgesamt 1,8 MiB benötigt. Werden Triangle-Strips verwendet, sinkt
der Speicherbedarf aus 640 KiB. Bei der Verwendung von Index-Buffer-Objekten sind durch die zusätz-
liche Speicherung der Indizes immerhin 698 KiB notwendig. Werden Triangle-Strips in Verbindung mit
einem Index-Buffer-Objekt benutzt, reduziert sich der Speicherbedarf auf 448 KiB, also auf 24 Prozent
im Vergleich zum nicht optimierten Speicherverbrauch. Die erreichte absolute Einsparung von Speicher
korreliert mit der Größe des Bild-Meshs.
4.4 Zwischenfazit
Im Zuge der Implementierung wurde eine Android-App entwickelt, die mittels Extrapolation gemäß Ka-
pitel 3.1 Zwischenbilder für eine kontinuierliche interaktive Darstellung einer Remote-Visualisierung er-
zeugen kann. Darüber hinaus wurde mit der Klasse CompositionTriangle eine Datenstruktur geschaffen,
die bis zu drei Referenzdatensätze in Form von SceneState-Objekten aufnehmen kann. Die Berechnung
der Kamerasichten für Referenzbilder wird wie in Kapitel 3.2.2 vom CompositionTriangle durchgeführt.
Die iterative Komposition der Referenzbilder (Kapitel 3.2.1) sowie das kontrollierte Abrufen der Refe-
renzbilder für Extrapolation und Komposition konnten hingegen nicht implementiert werden.
32 4. IMPLEMENTIERUNG
33
5 Evaluation
In diesem Kapitel wird für die implementierte Remote-Visualisierung für Android eine Evaluation durch-
geführt. Dabei wird zum einen die Performance der Extrapolation geprüft und zum anderen die damit
erzeugten Bilddaten auf ihre qualitative Abweichung vom Ground-Truth geprüft. Für die Evaluation stan-
den zwei Android-Geräte zur Verfügung. Zum einen das Android-Tablet Nexus 7 (2013) vom Lehrstuhl
CGV, für das die Remote-Visualisierungs-App hauptsächlich entwickelt wurde, sowie das Smartphone
Samsung Galaxy S4.
5.1 Evaluation der Startverzögerung
Eine Bedingung, die bei der Wahl des Verfahrens in Kapitel 2 berücksichtigt wurde, war, dass es eine
geringe Startverzögerung vorweisen kann. Für die Evaluation wurde die Zeit zwischen dem Start der
Render-View und dem ersten Render-Durchlauf gemessen.
Abbildung 5.1: Verlauf der Startverzögerung in Abhängigkeit zur Anzahl der Pixel
Wie Abbildung 5.1 zeigt, korreliert die Zeit, die bis zur Darstellung des ersten Bildes vergeht, mit der
Anzahl der Pixel. Dafür sorgt vor allem die Erzeugung des Bild-Meshs. Bereits bei einer Auflösung von
1024 x 1024 Pixeln liegt die Startverzögerung bei über zwei Sekunden und wird als störend empfunden.
34 5. EVALUATION
5.2 Evaluation der Bildwiederholfrequenz
Da durch die netzwerkbedingt verzögerte Kommunikation zwischen Client und Server nicht garantiert
werden konnte, dass genug Bilder pro Sekunde zur Verfügung stehen, um eine kontinuierliche interaktive
Darstellung zu ermöglichen, werden vom Client Zwischenbilder erzeugt. Auch in diesem Fall ist der
Aufwand von der Anzahl der Bildpunkte und damit von der Auflösung abhängig, wie Abbildung 5.2
deutlich macht.
Abbildung 5.2: Bilder pro Sekunde in Abhängigkeit zur Anzahl der Pixel
Bei einer Auflösung von 128 x 128 Pixeln werden bis zu 60 Bilder pro Sekunde erreicht. Da die Displays
der meisten aktuellen mobilen Endgeräte maximal 60 Hz unterstützen, wird auf diese Bildwiederhol-
frequenz begrenzt. Es ist anzunehmen, dass die tatsächlich erreichbare Rate der Bilder pro Sekunde für
diese Auflösung höher liegt. Ab einer Auflösung von 1024 x 1024 Pixeln fällt die gemessene Bildrate bis
auf unter 10 Bilder pro Sekunde. Eine kontinuierliche Darstellung ist damit nicht mehr möglich.
5.3 Evaluation der Bildqualität
Für die Evaluation der Qualität der Zwischenbilder wird das Peak-Signal-To-Noise-Ratio, kurz PSNR
verwendet. Dabei handelt es sich um eine Metrik für die objektive Bestimmung der Bildqualität bezogen
auf ein Vergleichsbild. Der logarithmische Wert in Dezibel ist dabei umso kleiner, je stärker die Bilder
voneinander abweichen.
Die Bestimmung des PSNR erfolgt auf dem Test-Client. Verglichen werden die Zwischenbilder und die
jeweils entsprechende Ground-Truth. Wie in Abbildung 5.3 dargestellt, sinkt das PSNR erwartungsge-
mäß mit zunehmender Entfernung vom Sichtpunkt des Referenzbildes durch Rotation der Orbit-Kamera.
Wie die Abbildungen 5.4 zeigt, können mit Hilfe der Extrapolation die Objektoberflächen gut rekonstru-
iert werden. Abweichungen treten vor allem an den Objektkanten auf. Zum einen werden die Kanten des
5.3. EVALUATION DER BILDQUALITÄT 35
Abbildung 5.3: Das PSNR in Abhängigkeit zum Rotationswinkel der Orbit-Kamera
Vordergrundobjekts ausgefranst dargestellt. Das liegt an der in Kapitel 3.1.4 dargestellten Verwendung
der Kantenhöhe. Die Kante des Vordergrunds wird bis zu einem Schwellwert der Kantenhöhe gezeich-
net. Da die Kantenhöhe zwischen dem Vordergrund und dem Hintergrund linear interpoliert wird, haben
sowohl die Struktur des Vordergrundobjekts als auch die des Hintergrundobjekts einen Einfluss auf den
Verlauf der Kantenhöhe. Bei starken Änderungen der Struktur treten sichtbare Unterschiede in der Inter-
polation auf, die als ausgefranste Kante erkennbar sind.
(a) (b) (c)
Abbildung 5.4: Durch Extrapolation erzeugtes Zwischenbild bei einer Rotation des Längenwinkels (a)
um 5 Grad, (b) um 30 Grad, (c) um 60 Grad
Darüber hinaus können Objektkanten nur dann erkannt werden, wenn sich die Objekte in der Tiefe
weit genug voneinander entfernt befinden. Ist das nicht der Fall, erkennt der Lagrange-Operator die
Kante nicht. In diesem Fall werden Vordergrund- und Hintergrundobjekt miteinander verbunden, wie in
Abbildungen 5.4b dargestellt. Dieser Effekt kann behoben werden, indem der Schwellwert gesenkt wird,
der angibt, ab wann ein Sprung des Tiefenwertes als Kante identifiziert wird. Wird dieser Wert zu niedrig
eingestellt, können jedoch korrekte Oberflächen als Kantenübergang erkannt werden. Aus diesem Grund
ist dieser Wert für jede Szene individuell zu definieren.
36 5. EVALUATION
37
6 Fazit und Ausblick
Auf Grundlage eines, nach sorgfältiger Prüfung, gewählten Verfahrens, wurde in dieser Arbeit eine An-
wendung für Android entwickelt, die dem Benutzer eine interaktive Remote-Visualisierung bietet. Dabei
konnten sowohl die Verzögerung zwischen der Nutzereingabe und der Ausgabe der Darstellung sowie
die geringe Bildwiederholfrequenz durch die Erzeugung von Zwischenbildern vollständig maskiert wer-
den. Die angewandte Extrapolation liefert dank einer aufwendigen Heuristik Zwischenbilder, die die
Ground-Truth in ausreichender Qualität rekonstruieren können.
Auch wenn die Komposition nicht fertig umgesetzt werden konnte, wurde durch diese Arbeit die not-
wendige Vorarbeit geleistet. Neben der theoretischen Betrachtung des Verfahrens wurde bereits die Im-
plementierung zu großen Teilen für die Unterstützung der Komposition umgesetzt.
Die Extrapolation der Zwischenbilder ist einigen Beschränkungen unterworfen, die bereits von [MMB97]
aufgezeigt wurden. So ist das Verfahren für die Darstellung von spekularen Reflexionen nicht geeignet,
da es sich dabei um eine betrachtungsabhängige Lichtreflexion handelt, die aufwendig nachempfunden
werden muss. Einen Lösungsansatz liefert [MO95] durch die Anwendung von Deferred-Shading für die
Darstellung der rekonstruierten Oberfläche. Darüber hinaus ist das Verfahren auf statische Szenen aus-
gelegt. Die Bewegung von Objekten innerhalb der Szene kann nur schwer nachempfunden werden, wo-
durch diese ruckartig dargestellt wird. Eine Lösung soll durch die Berechnung eines Bewegungsvektors
für jeden Pixel erreicht werden, wie in [Cos93] beschrieben.
Neben den Beschränkungen des Verfahrens, besitzt auch der Android-Client eine Einschränkung. Die
Darstellung der Visualisierung ist nur möglich, wenn Breite und Höhe der Anzeige identisch sind. Wer-
den nicht quadratische Auflösungen verwendet, kommt es zu einer verzerrten Anzeige. Die Beseitigung
dieses Effekts ist ein Ziel für die weiterführende Arbeit an dem Android-Client. Ein weiteres ist die Fer-
tigstellung der Komposition. Darüber hinaus gibt es Bereiche des Verfahrens, die zukünftig verbessert
werden können. Zum einen musste die durch [MMB97] beschriebene Heuristik auf Grund des nicht un-
terstützten Geometry-Shaders in der aktuellen OpenGL ES Version durch ein aufwendigeres Verfahren
angepasst werden. Gesetz dem Fall, die Weiterentwicklung von OpenGL ES bringt die Unterstützung des
Geometry-Shaders mit sich, kann diese Anpassung verworfen werden. Zusätzlich bietet es sich an, die
Kommunikation zwischen Server und Client zu erweitern. Aktuell wertet der Server ausschließlich die
38 6. FAZIT UND AUSBLICK
View-Matrix des Clients aus. Die Parameter der perspektivischen Transformation wurden fest für Client
und Server definiert. Werden diese dynamisch durch den Client festgelegt, sendet dieser die horizontalen
und vertikalen Begrenzungen des View-Frustum an den Server. Die vordere und hintere Begrenzung des
View-Frustums ist dagegen szenenspezifisch und muss vom Server festgelegt werden.
39
Literaturverzeichnis
[Bou88] BOURKE, Paul: Calculating The Area And Centroid Of A Polygon. http:
//www.seas.upenn.edu/~sys502/extra_materials/Polygon%20Area%
20and%20Centroid.pdf. Version: 1988
[Cos93] COSTELLA, John P.: Motion Extrapolation at the Pixel Level. Unveröffentlichtes Paper
verfügbar unter. http://www.ph.unimelb.edu.au/~jpc. Version: 1993
[CW93] CHEN, Shenchang E. ; WILLIAMS, Lance: View Interpolation for Image Synthesis. In: Pro-
ceedings of the 20th Annual Conference on Computer Graphics and Interactive Techniques.
New York, NY, USA : ACM, 1993 (SIGGRAPH ’93). – ISBN 0–89791–601–8, 279–288
[LH96] LEVOY, Marc ; HANRAHAN, Pat: Light Field Rendering. In: Proceedings of the 23rd Annual
Conference on Computer Graphics and Interactive Techniques. New York, NY, USA : ACM,
1996 (SIGGRAPH ’96). – ISBN 0–89791–746–4, 31–42
[MMB97] MARK, William R. ; MCMILLAN, Leonard ; BISHOP, Gary: Post-rendering 3D Warping.
In: Proceedings of the 1997 Symposium on Interactive 3D Graphics. New York, NY, USA :
ACM, 1997 (I3D ’97). – ISBN 0–89791–884–3, 7–ff.
[MO95] MAX, Nelson ; OHSAKI, Keiichi: Rendering Trees from Precomputed Z-Buffer Views. In:
In Eurographics Rendering Workshop, 1995, S. 45–54
[RSTK08] REZK-SALAMA, C. ; TODT, S. ; KOLB, A.: Raycasting of Light Field Galleries from Vo-
lumetric Data. In: Proceedings of the 10th Joint Eurographics / IEEE - VGTC Conference
on Visualization. Aire-la-Ville, Switzerland, Switzerland : Eurographics Association, 2008
(EuroVis’08), 839–846
[SC12] SHRIVAKSHAN, G. T. ; CHANDRASEKAR, C.: Comparison of various Edge Detection Tech-
niques used in Image Processing. In: International Journal of Computer Science Issues
(IJCSI) 9 (2012), Sep, Nr. 5, S. 269ff
[SGHS98] SHADE, Jonathan ; GORTLER, Steven ; HE, Li-wei ; SZELISKI, Richard: Layered Depth
Images. In: Proceedings of the 25th Annual Conference on Computer Graphics and Interac-
40 Literaturverzeichnis
tive Techniques. New York, NY, USA : ACM, 1998 (SIGGRAPH ’98). – ISBN 0–89791–
999–8, 231–242
[SKC03] SHUM, Heung-Yeung ; KANG, Sing Bing K. ; CHAN, Shing-Chow: Survey of image-based
representations and compression techniques. In: Circuits and Systems for Video Technology,
IEEE Transactions on 13 (2003), Nov, Nr. 11, S. 1020–1037. http://dx.doi.org/
10.1109/TCSVT.2003.817360. – DOI 10.1109/TCSVT.2003.817360. – ISSN 1051–
8215
[SLW+08] STICH, Timo ; LINZ, Christian ; WALLRAVEN, Christian ; CUNNINGHAM, Douglas ; MA-
GNOR, Marcus: Perception-motivated Interpolation of Image Sequences. In: Proceedings
of the 5th Symposium on Applied Perception in Graphics and Visualization. New York, NY,
USA : ACM, 2008 (APGV ’08). – ISBN 978–1–59593–981–4, 97–106