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