Research Collection

Report

blue-cRäumlich-immersive Projektions- und 3D Video-Portale fürTelepräsenz

Author(s): Gross, Markus H.; Würmlin, Stephan; Naef, Martin; Lamboray, Edouard; Spagno, Christian

Publication Date: 2005

Permanent Link: https://doi.org/10.3929/ethz-a-006787977

Rights / License: In Copyright - Non-Commercial Use Permitted

This page was generated automatically upon download from the ETH Zurich Research Collection. For moreinformation please consult the Terms of use.

ETH Library

ETH CS Technical Report #495, 20. September, 2005

1

Räumlich-immersive Projektions- und 3D Video-Portale für TelepräsenzMarkus Gross Stephan Würmlin Martin Naef Edouard Lamboray Christian Spagno

ETH Zürich

ZusammenfassungDer folgende Beitrag beschreibt das Design und die Architekturvon blue-c, einem Polyprojekt der ETH Zürich, an dem über einenZeitraum von 4 Jahren bis zu 20 wissenschaftliche Mitarbeiter mit-gewirkt haben und insgesamt 9 Doktorarbeiten entstanden sind.blue-c ist ein neuartiges, immersives Telepräsenzsystem, welchesnatürliches, kollaboratives Arbeiten räumlich getrennter Benutzerermöglicht. Insbesondere erlaubt die Technologie, Kommunikati-onspartner realistisch und dreidimensional in eine virtuelle Umge-bung zu integrieren und mit dieser zu interagieren. blue-ckombiniert zum ersten Mal die simultane Verarbeitung multiplerVideoströme mit fortschrittlicher Projektionstechnologie, so wiesie in bestehenden CAVE™-Systemen eingesetzt wird und erzeugtden Eindruck der vollständigen Immersion. Um blue-c zu verwirk-lichen, mussten zahlreiche Systemkomponenten hard- und soft-wareseitig von Grund auf entworfen und integriert werden.Besonders hohe Anforderungen ergaben sich hinsichtlich Synchro-nisation und Echtzeitverarbeitung der Daten. Die Architektur vonblue-c ist skalierbar und erlaubt auch die Kombination mit wenigerleistungsstarker Hardware.

1 Einleitung1.1 Hintergrund und MotivationIn den letzten 10 Jahren hat die Bedeutung von räumlich-immersi-ven Projektionssystemen (Spatially Immersive Displays oderSIDs) signifikant zugenommen. Mittels multipler Projektorenerlauben solche SIDs dem Benutzer, in eine virtuelle Welt einzu-tauchen und mit ihr zu interagieren. Aus der Vielzahl von SID-Konzepten ist die so genannte CAVE™ [Cruz-Neira et al. 1993]sicherlich mit das Bedeutendste. Hierbei wird mittels mehrererProjektoren eine Rundumprojektion auf einem oftmals kubusför-migen Projektionszelt erzeugt. Stereoskopische Projektionen ver-stärken dabei die empfundene Immersion. Erweiterungen dieserTechnologie erlauben es auch, Bilder multipler Projektoren mitgewöhnlichen Arbeitsumgebungen zu überlagern und somit die

Gesamt-Projektionsfläche zu erhöhen. Beispiele sind PowerWallsoder die WorkWall™. Ein weiterer Vertreter ist ElumensVisionDome, ein sphärisches Einzelprojektorsystem mit allerdingsbegrenzter Auflösung. Andere immersive Systeme sind z. B. dieResponsive Workbench [Krüger et al. 1995; Agrawala et al. 1997]und die Holobench™. Einige dieser Technologien sind bereits alsProdukte erhältlich und werden auch in einem breiten Anwen-dungsspektrum, von Architektur über Kunst bis hin zur Medizineingesetzt. In der Flugzeug- und Automobilindustrie erlangen der-artige Systeme sogar eine hohe Anwendungsrelevanz und werdenbereits weiträumig verwendet.

Viele Anwendungen erfordern jedoch die Möglichkeit zurTelekollaboration, die in konventionellen CAVE-Systemen übli-cherweise nicht gegeben ist. Daher ist man in den letzten Jahrenbestrebt, den Aspekt der Telepräsenz mit SID-Technologie zukombinieren. Oftmals werden dabei zweidimensionale Videokon-ferenzsysteme eingesetzt, welche ein Videobild des Kommunikati-onspartners in die virtuelle Szene einspielen. Solche Ansätzevermitteln allerdings nur einen sehr begrenzten Eindruck mensch-licher Präsenz. Ein Beispiel für 2D Avatar-basierte Videointegra-tion ist das TELEPORT System [Gibbs et al. 1999].

Somit sind Bestrebungen, eine volle dreidimensionale Integra-tion des Benutzers zu erreichen, verständlich. Parallel zu diesenAktivitäten intensivierte sich in den letzten Jahren auch die For-schung an dreidimensionalem Video oder 3D Video. Hierbei gene-rieren Cluster von Kameras simultane Videoströme vonunterschiedlichen räumlichen Positionen und erlauben damit einefreie Navigation in Raum und Zeit. Wir unterscheiden zwischenAnsätzen, die auf langwieriger Vorverarbeitung basieren wie z. B.Moezzi et al. [1996] und Würmlin et al. [2002] und interaktivenEchtzeitsystemen wie Davis und Bobick [1998], Li et al. [2004]oder Matusik et al. [2001]. Das zentrale Problem ist hierbei diezuverlässige Extraktion von geometrischen Informationen.

Abbildung 1: Die zwei blue-c Portale in Aktion: Links ist das dreiseitige CAVE-System mit drei aktiven Projektionswänden und aktiverLED-Beleuchtung abgebildet. Das Bild rechts zeigt das einfachere PowerWall-System mit einer herkömmlichen Projektionswand. Beide Sy-steme akquirieren ein dreidimensionales Video der Benutzer mit insgesamt 16 Kameras und ermöglichen Stereo-Projektionen.

ETH CS Technical Report #495, 20. September, 2005

2

Die Kombination von immersiver Projektion und Echtzeit-3D-Videoübertragung stellt eine sehr grosse technische Herausforde-rung in der systemorientierten Grundlagenforschung dar. Eines derumfassendsten Forschungsprogramme in den USA zu diesemThema ist die National Tele-Immersion Initiative [Sadagic et al.2001]. Ein weiteres Vorläuferprojekt zu diesem Thema ist auchdas Office of the Future [Raskar et al. 1998], wo man mit unsicht-barem strukturierten Licht eine Tiefenextraktion vornimmt. Kauffund Schreer [2002] stellten ebenfalls ein interessantes 3D Video-Konferenzsystem vor; eine vollständige Integration von immersi-ver Projektion und 3D-Videoverarbeitung kann jedoch in keinemder erwähnten Systeme erreicht werden.

blue-c bietet eine Lösungsvariante für dieses schwierige Pro-blem. Ziel war es, innovative Hard- und Softwaresysteme sowieAlgorithmen zu entwickeln, welche eine Kombination von immer-siver Projektion und 3D Video zum Zweck der Telepräsenz erlau-ben. Das blue-c Projekt war interdisziplinär mit Beiträgen aus derInformatik, der Informationstechnologie, dem Hardware-Design,der Konstruktionstechnik sowie der Architektur.

Die erreichten Forschungsergebnisse des Projektes können wiefolgt zusammengefasst werden.• Es wurde ein neuartiges Konzept für Projektionswände entwik-

kelt, welches aktive Flüssigkristallwände verwendet [Spagno2004]. Diese schalten schnell zwischen einem transparentenund opaken Zustand hin und her. Synchronisiert man derartigeDisplays mit Videokameras, können diese “durch die Wändehindurch” sehen.

• Zur effizienten Verarbeitung der simultanen Videoströmemusste ein 3D Video-Verarbeitungssystem entwickelt werden[Würmlin 2004], welches den besonderen Bedürfnissen derblue-c Architektur Rechnung trägt. Sie verwendet 3D Punkt-wolken als fundamentales Videoprimitiv. Dies ermöglicht einesehr effiziente Codierung, Datenübertragung und Darstellung.

• Aufgrund der sehr hohen Anforderungen an die Datenkommu-nikation sowie der unterschiedlichen, einem solchen System zuGrunde liegenden Datentypen musste eine entsprechende Netz-werk- und Kommunikationsarchitektur [Lamboray 2004] ent-worfen werden.

• Schliesslich bedurfte es einer speziellen Anwendungsbenutzer-schnittstelle (API) [Naef 2004], welche Applikationsprogram-mierern komfortablen Zugang zu allen blue-c Funktionalitätenverschafft.

Im Folgenden geben wir zunächst einen Überblick über dieGesamtarchitektur von blue-c und beschreiben dann den Entwurfder Einzelkomponenten, inklusive der entwickelten Hardware(Kapitel 3) sowie der Software und Methoden (Kapitel 4-6). Wei-tere technische Details sind in den angegebenen Fachpublikatio-nen zu finden oder auf der Projekt-Webseite: blue-c.ethz.ch. Eineausführliche Gesamtbeschreibung des Systems ist auch in [Grosset al 2003] gegeben.

2 GesamtkonzeptAbbildung 2 zeigt die konzeptionellen Komponenten von blue-c.Insgesamt drei Doppel-LCD-Projektoren mit zusätzlichen Flüssig-kristall-Blenden dienen zur aktiven Stereo-Bilderzeugung. Eineder hardwaretechnischen Kernkomponenten stellen die aktivgeschalteten Projektionswände dar, welche es den Kameras erlau-ben “durch die Wand zu sehen”. Wie wir noch beschreiben werden,löst dieses Konzept eine Reihe von technischen Problemen.

Zur kalibrierten Beleuchtung dienen ferner insgesamt 10’000LEDs, welche synchronisiert mit den Kameras Licht in das Systemeinspeisen. Um das Auge des Betrachters vor diesen Lichtpulsenzu schützen, wurden die für Stereoprojektion typischen LC-Stere-obrillen in ihrer Arbeitsweise verändert. Zur Verarbeitung der ins-gesamt 16 Videoströme dient ein Linux PC-Cluster, die

Bildgenerierung erfolgt mittels einer SGI Onyx 3200. Die präziseSynchronisation der beteiligten Hardware-Komponenten über-nimmt eine eigens entwickelte Synchronisationshardware. Zusätz-lich beherbergt die blue-c auch Hardware für Tracking, räumlicheAudiosynthese, Sprachkommunikation und 3D-Benutzerinterak-tion. Die Übertragung der 3D Videodaten verwendet ein neuarti-ges Format, die so genannten 3D Video-Fragmente, welchesowohl auf effiziente Codierung als auch auf schnelles Renderingoptimiert sind. Die beiden an der ETH gebauten Systeme sind überein Gigabit-Ethernet, also ein IP-Netzwerk miteinander verbun-den. Die auf Echtzeit-CORBA basierte Kommunikationsarchitek-tur verarbeitet eine Vielzahl hybrider Daten inklusive 3D Video,Sprache, Events, Geometriedaten, Szenenaktualisierungen usw.

3 blue-c HardwarekomponentenDas folgende Kapitel gibt einen Überblick über die Hardwarekom-ponenten von blue-c. Technisch detailliertere Beschreibungen sindin diversen Publikationen zu finden, insbesondere in Spagno undKunz [2003] sowie in der Dissertation von Spagno [2004].

3.1 KameraanordnungDas blue-c Hauptportal ist als dreiseitiges Stereo-Rückprojektions-system aufgebaut. Die planaren Projektionswände erleichtern dieVerwendung multipler Projektoren. Ein zentrales Merkmal unseresDesigns ist, dass sich die meisten Kameras ausserhalb des Projek-tionsraums befinden und gegenüber dem Benutzer von den Projek-tionswänden verdeckt bleiben. Dies ist jedoch unumgänglich, denneine Positionierung innerhalb des Aktionsraumes würde die emp-fundene Immersion erheblich stören und zu sehr grossen nichtli-nearen Linsenverzerrungen führen. Das äussere Aluminium-Kameragerüst lässt hinreichend Freiräume für Positionsoptimie-rungen. Im Moment sind insgesamt 16 Dragonfly™ FirewireKameras von Point Grey in VGA-Auflösung im Einsatz, 11 davonausserhalb der Projektionswände. Die Positionen ergaben sichdurch Softwaresimulation der Anordnung und haben wesentlichenEinfluss auf die Rekonstruktionsgüte. Schliesslich hüllt ein blauerVorhang die gesamte Konstruktion ein.

Das Nebenportal am Standort ETH Hönggerberg ist als inter-aktiver und multimedialer Raum im Department Architektur freizugänglich. Aufgebaut wurde eine passive Plexiglas-Projektions-wand. 16 Firewire Kameras in VGA-Auflösung vom Typ 301fcder Firma Basler sind in die Wände und Decken des Raumes ein-gelassen und umrahmen die Projektionsfläche. Eine Übersicht derbeiden Portale und ihrer Anordnung ist in Abbildung 3 illustriert.Abbildung 4 a) zeigt die reale Anordnung des blue-c Hauptportalsmit dem Kameragerüst.

Abbildung 2: Gesamtkonzept von blue-c mit allen relevantenHard- und Software-Komponenten. Die in rot dargestellten Linienrepräsentieren die Synchronisation der einzelnen Hardwarekompo-nenten. Ebenfalls dargestellt sind die beiden Installationen ETH-Zentrum und ETH-Hönggerberg.

Graphik-rechner

Akquisitions-cluster

Graphik-rechner

Akquisitions-cluster

Netzwerk

blue-cSoftware

3D Video Objekt

16 Synchronisierte Kameras

Shutter-brillen

Shutter-brillen

LCDShutter

AktiveProjektionswände

16 Synchronisierte Kameras

Synchronisiertesaktives Licht

Synchronisation

Synchronisation

ETH CS Technical Report #495, 20. September, 2005

3

3.2 Aktive Projektionswände

Die aktiven Projektionswände stellen eine wesentliche Innovationdes Hauptsystems dar. Zu diesem Zweck wurden umfangreicheVersuche mit Flüssigkristall-Glasscheiben verschiedener Herstel-ler durchgeführt. Derartige Scheiben sind eigentlich für innenar-chitektonische Anwendungen entwickelt worden und für denstatischen Betrieb ausgelegt. Nach ausgiebigem Test diverserMaterialien haben wir schliesslich IsoLite™ Wände aus je 3 Seg-menten aufgebaut. Durch Anlegen einer Spannung polarisiert sichder Flüssigkristall-Film und die Scheiben werden transparent.Allerdings stellen die Scheiben der Grösse 950 mm × 2’240 mmund mit einem Gewicht von ca. 80 kg ein kapazitives Element von11 μF dar, welches durch geeignete Ansteuerelektronik kompen-siert werden muss. Insbesondere die molekulare Relaxierung beiSpannungsabfall, also der Übergang von transparent nach opak, istnicht extern beschleunigbar und setzt der oberen Taktfrequenz desSystems eine natürliche Grenze. Abbildung 5 zeigt die Projekti-onswände sowohl im opaken als auch im transparenten Zustand.

Zahlreiche Experimente [Spagno 2004] haben ergeben, dasseine Maximalfrequenz von 62.5 Hz (16 ms Periode) bei einemTaktverhältnis von 1:3.44 beste Resultate mit 70% Restopazitäterzielt.

3.3 Synchronisation und ZeitsteuerungDie einzelnen Videobilder werden in einem kurzen Zeitfensterzwischen den Projektionssequenzen des linken und rechten Augesaufgenommen. Das prinzipielle Synchronisationsdiagramm dazuist in Abbildung 6 dargestellt. Die aktiven Projektionswände schal-ten in einem kurzen Intervall von 3.6 ms transparent und ermögli-chen den synchronisierten Kameras eine ungehinderte Sicht aufden Benutzer. Während dieser Akquisitionsphase schliessen dieaktiven Flüssigkristall-Blenden der Stereoprojektoren und verdek-ken damit das projizierte Bild um Streueffekte zu verhindern. Fer-ner schliessen gleichzeitig auch die aktiven Flüssigkristall-Stereobrillen und schirmen das Licht der aktiven Beleuchtung vomAuge des Benutzers ab.

In der aktuellen Implementation von blue-c wird nur in jedemsiebten Zyklus ein Videobild aufgenommen, was zu einer Bildwie-derholrate von insgesamt 8.9 Hz führt. Ebenso müssen die Verzö-gerungszeiten der beteiligten Hardware-Komponenten genaubeachtet werden. Zur Synchronisation von Brille, Projektions-wand, Projektoren und Lichtquellen dient ein innerhalb des Pro-jektes entwickelter, programmierbarer Synchronisationsrechnerauf Basis eines Mikrokontrollers [Spagno 2004]. Abbildung 4 b)zeigt die Synchronisationshardware, welche in einem 19” Schrankeingebaut ist.

3.4 Aktive Beleuchtung und StereoprojektionEin grundsätzliches Problem bei der Kombination von Kamerasund Projektoren stellen die gegensätzlichen Anforderungen an dieBeleuchtungsbedingungen dar. Projektionen hoher Qualität bedür-fen eines möglichst streulichtfreien Umfeldes, wogegen die Video-aufnahmen eine möglichst einheitliche, kalibrierte Beleuchtungbenötigen. Diese verbessert die gesamte Videoverarbeitung, die3D-Rekonstruktion sowie die Texturwiedergabe erheblich. Ausdiesem Grund wurde eine externe Beleuchtung, bestehend ausmehreren Arrays mit insgesamt 10’000 einzelnen LEDs, entwor-fen. Die verwendeten weissen LEDs haben sehr kurze Schaltzeitenvon ca. 0.5 μs und eine hohe Lichtausbeute. Die Lichtquelle wirdsynchron zu den Videokameras mit einer Rate von 62.5 Hzgeschaltet und beleuchtet den Benutzer während der Videoaufnah-men. Aufgrund der hohen Taktraten sowie der synchronenAbschirmung durch die Flüssigkristall-Brillen sieht der Benutzernur die Dunkelphase und nimmt die Beleuchtung als starkgedämpftes, konstantes Licht wahr. Die Lichtverhältnisse im Dun-kel- und Hellzustand sind in Abbildung 7 nochmals dargestellt.Die LED Reihen sind in Abbildung 8 a) dargestellt.

In Abbildung 8 b) sind die LCD-Doppelprojektoren des TypsSanyo XF12 LCD zu sehen, welcher über eine Helligkeit von je3,500 ANSI-Lumen und über Auflösungen von Pixeln verfügen. Die speziell angefertigten und vormontierten, fer-roelektrischen Flüssigkristall-Blenden ermöglichen schliesslich

Abbildung 3: Illustration der Anordnung von Projektoren und Ka-meras in der blue-c. a) Hauptportal. b) Nebenportal.

Abbildung 4: a) Reale Anordnung im Hauptportal. b) Synchroni-sationselektronik.

Abbildung 5: Aktive Projektionswände a) opak geschaltet, b)transparent geschaltet.

ProjektionswandProjektionswände

Projektor

Kamera

Projektor

Wand

Wand

Kamera

Abbildung 6: Vereinfachtes Zeitdiagramm für die Synchronisationder beteiligten Hardware-Komponenten.

Stereorechts

Stereolinks

Bild-akquisition

Stereorechts

Stereolinks

Bild-akquisition

Aktive Projektionswand trans.

ein

ein

ein

opak

opak

opak

opak opak

opak

opak

opak

trans.

LED Beleuchtung

Kamera

Shutterbrille rechts

Shutterbrille links

Projektorshutter links

Projektorshutter rechts

0 m

s

4 m

s

8 m

s

16 m

s

12 m

s

1024 768×

ETH CS Technical Report #495, 20. September, 2005

4

einen qualitativ sehr hochwertigen Stereobetrieb mit sehr guterKanaltrennung. Diese Blenden erhalten die gleichen Synchronisa-tionssignale wie die Flüssigkristall-Brillen des Benutzers.

Das Nebenportal ist mit einem Aktiv-Stereo DLP-Projektorvom Typ Mirage 6000 der Firma Christie Digital ausgerüstet, wel-cher über eine Helligkeit von 6000 ANSI-Lumen und eine Auflö-sung von Pixeln verfügt.

3.5 Sonstige HardwarekomponentenDie Gesamtkonstruktion des Hauptportals enthält darüber hinauszahlreiche zusätzliche Komponenten, die an dieser Stelle nur kurzaufgeführt seien. Das handgefertigte Holzfundament trägt nebenden insgesamt 720 kg schweren Scheiben noch Lautsprecher, einmagnetisches Tracking-System, IR-Emitter sowie die Verkabe-lung. Ein äusseres Aluminiumgerüst dient zur Kameraaufhängungund erlaubt eine flexible Anordnung der einzelnen Kameras.Diverse 3D Interaktionsgeräte helfen bei der Navigation durch dievirtuellen Umgebungen. Ein zusätzlicher Soundserver, siehe Naefet al. [2002], dient zur Synthese von Geräuschen und Klängen.

Das Nebenportal enthält neben einem herkömmlichen 5.1Audiosystem ebenfalls diverse 3D Interaktionsgeräte.

4 3D Video-VerarbeitungDieses Kapitel beschreibt die einzelnen Komponenten des 3DVideo-Systems der blue-c. Es verarbeitet die einzelnen 2D Vide-oströme in Echtzeit zu einer dreidimensionalen Repräsentation desBenutzers und überträgt diese über das unterliegende Netzwerk.Eine umfassende technische Darstellung der 3D Videoverarbei-tung ist auch in Würmlin et al. [2004] sowie in der Dissertationvon Würmlin [2004] zu finden.

4.1 ÜbersichtAbbildung 9 zeigt die einzelnen Verarbeitungsstufen der Video-pipeline der blue-c. In einem Vorverarbeitungsschritt muss dasSystem zunächst sowohl farbvalenzmetrisch als auch geometrisch

kalibriert werden. Zur Laufzeit werden die einzelnen Videoströmeje einem Rechenknoten des Akquisitionsclusters zugeführt. Dieserberechnet in einem ersten Schritt eine Trennung von Vordergrundund Hintergrund. Danach wird die Silhouette des Benutzers extra-hiert. Die zweidimensionalen Silhouetten aus den 16 Einzelkame-ras werden einem Masterknoten zugeführt, welcher die eigentliche3D Rekonstruktion durchführt. Aufgrund der hohen Anforderun-gen hinsichtlich Echtzeitverarbeitung verwendet man dazu einVerfahren, welches die visuelle Hülle eines Objektes generiert[Matusik et al. 2000].

Die zugrunde liegende Repräsentation der 3D Videodatenbasiert auf Punkt-Samples [Pfister et al. 2000]. Das dazu entwik-kelte Konzept der 3D Video-Fragmente erlaubt es, die räumlicheund zeitliche Kohärenz des Videostroms zur Kompression undÜbertragung zu nutzen. Schliesslich übernimmt ein geeigneterPunkt-Renderer [Zwicker et al. 2001] die Darstellung auf der Seitedes Kommunikationspartners. Zusätzliche Funktionen umfasseneinen 3D Video-Rekorder zur Aufnahme und Wiedergabe vonVideosequenzen [Würmlin et al. 2002]. Diese Komponenten wer-den in den folgenden Abschnitten näher erläutert.

4.2 SystemkalibrierungDie Extraktion von Geometrie aus Bildern ist eine der Grund-

aufgaben der Bildverarbeitung. Eine Grundvoraussetzung ist dabeidie Kenntnis der so genannten extrinsischen und intrinsischenKameraparameter, welche die Abbildungsgeometrie und räumli-che Anordnung der Kameras beschreiben. Da diese vorab nichtbekannt sind, müssen sie in einem Kalibrierungsschritt berechnetwerden. Aufgrund der expliziten Synchronisation der einzelnenKameras dient dazu ein recht einfaches Verfahren, bei welchemeine Person bei laufenden Kameras mittels eines Laserpointers dasZielvolumen mit virtuellen Punkten ausfüllt [Pollefeys et al.1999]. Aufgrund der geringen Distanz der Kameras vom Benutzer(2.5 m - 3 m) ergeben sich auch radiale Linsenverzerrungen, wel-che ebenfalls auskorrigiert werden müssen. Eine detaillierteBeschreibung der geometrischen Kalibrierung von blue-c kann in[Svoboda et al. 2005] gefunden werden.

Obwohl homogene Kamerasysteme in blue-c im Einsatz sind,sind die Farbvalenzen nicht genügend homogen für unser 3DVideosystem. Ebenso führen leichte, positionsabhängige Unter-schiede in der Restopazität der Projektionswände zu Farbverzer-rungen, welche ebenso auskorrigiert werden müssen. Dies erfolgtdurch eine lineare Transformation der Eingangsfarben der einzel-nen Kameras [Reinhard et al. 2001]. Die Matrixeinträge errechnensich aus Referenzkameras, welche im Voraus definiert werden. ImFalle des Hauptportals sind dies die Kameras im Innern der blue-c.Abbildung 10 a) zeigt ein Bild einer gewählten Referenzkamera.Abbildung 10 b) zeigt das Bild einer zu korrigierenden Kamera

Abbildung 7: Beleuchtungsbedingungen in der blue-c a) ohne undb) mit Zusatzbeleuchtung. Zu sehen ist auch die zeitliche Synchro-nisation der LED Lichtimpulse.

Abbildung 8: a) LED-Arrays wie sie zur Beleuchtung in blue-cverwendet werden. b) LCD-Doppelprojektoren mit Flüssigkristall-Blenden zum Stereobetrieb.

Projektion links

Projektion rechts

Aktives Licht

1280 1024×

Abbildung 9: Einzelkomponenten und Verarbeitungsschritte der3D Videopipeline von blue-c.

Rendering der Szene

3D Rekonstruktion

Anwendung

Projektion

Silhouetten-extraktion

Hintegrunds-subtraktion

Netzwerk-übertragung

Rendering des3D Video Objektes

VideobilderSegmentierung von Vordergrund & Hintergrund

Silhouetten

Punkte mit Farbe & Normale

Objekteinlage

3D Szene Bild

Punktstrom

ETH CS Technical Report #495, 20. September, 2005

5

und c) das korrigierte Bild im Vergleich. Die Unterschiede sinddeutlich sichtbar und es zeigen sich auch homogenere Farben inBeziehung zur Referenzkamera.

4.3 Hintergrundtrennung und Silhouetten

Hintergrundtrennung. Trotz der Vielzahl der existierendenSegmentierungsverfahren zur Trennung von Vordergrund undHintergrund, schränkt die Echtzeitanforderung die Wahlfreiheiterheblich ein. Innerhalb von blue-c haben wir einen Algorithmusvon Mester et al. [2001] für unsere Bedürfnisse angepasst. Dieserbasiert auf einer einfachen statistischen Beschreibung des Hinter-grundes, welche das System in einem initialen Trainingsschrittlernt. Der Vergleich der Pixelstatistik einer kleinen räumlichenNachbarschaft mit der Hintergrundstatistik lässt eine Hypotheseüber die Zugehörigkeit des jeweiligen Pixels zu. Zusätzlich ist dasHauptportal in einen blauen Vorhang (siehe Abbildung 4 a) einge-hüllt, welcher den Hintergrund statistisch homogenisiert. DieWände und Decken des Nebenportals sind in einem homogenenroten Farbton gehalten. In Abbildung 11 ist ein typisches Video-bild (a) vor und (b) nach der Hintergrundtrennung gezeigt.

Silhouetten. Die Qualität der 3D Rekonstruktion und damit desresultierenden 3D Video hängt neben der Hintergrundtrennung vorallem von der Anzahl der möglichen Geometriepunkte und damitvon der Auflösung der Silhouette ab. Zum Zweck der adaptivenAuflösungssteuerung haben wir eine Multiskalenrepräsentationentwickelt, welche die Silhouette in sukzessiv höherer Auflösung,ausgehend vom segmentierten Bild, berechnet. Das Verfahrenunterteilt das Bild in Blöcke zusammenhängender Pixel, wobei dieBlockgrösse durch einen Parameter α vom Benutzer gesteuertwerden kann. Im praktischen Betrieb setzen wir α = 1 oder 2 underhalten 2 × 2 oder 4 × 4 Gitter.

4.4 3D Rekonstruktion und 3D Video Repräsentation

Konzeptionell betrachtet, generalisiert die von uns entwickelte 3DVideo-Repräsentation die üblichen zweidimensionalen Bildpixelhin zu Punkten im Raum, den so genannten 3D Video-Fragmenten.Dieser Ansatz kombiniert die strukturelle Einfachheit und Regula-rität eines Bildpixels mit den Leistungsmerkmalen komplexerer,dreidimensionaler Repräsentationen. Ein Videofragment ist also

ein Abtastwert auf der Oberfläche eines 3D Video-Objektes, wel-cher neben geometrischen Attributen, wie Position und Normale,auch Darstellungsattribute, wie Farbe und Textur, vorsieht. EineKonnektivität zwischen einzelnen Fragmenten wird dabei nichtberücksichtigt. Dies vereinfacht die Kompression sowie die Über-tragung erheblich. Abbildung 12 veranschaulicht die Beziehungzwischen den 2D Pixeln und den 3D Video-Fragmenten.

Differentielle Übertragung. Um die räumlich-zeitliche Kohä-renz dieser Videofragmente auszunutzen, wurden die folgendenFragment-Operatoren definiert:

• INSERT fügt ein neues 3D-Fragment in die bestehende Reprä-sentation ein, nachdem es in einer Kamera sichtbar gewordenist.

• DELETE löscht ein unsichtbar gewordenes Element aus derRepräsentation.

• UPDATE korrigiert die Attribute für Geometrie oder Darstellungeines Fragments aufgrund aktueller Videoinformationen.

Die Sequenz dieser Operatoren erzeugen einen differentiellenFragment-Operatoren-Strom, welcher eine 3D Datenstruktur beimKommunikationspartner unterhält. Ein INSERT-Operator resultiertaus der Rückprojektion eines Pixels mit Farbattributen vom Bild-raum in den dreidimensionalen Objektraum. Dazu wird ein 3DRekonstruktionsalgorithmus, basierend auf der visuellen Hülle,angewendet [Matusik et al. 2000], welcher in Echtzeit Tiefen- undNormaleninformation berechnet. Die Fragmentprimitive weiseneine bijektive Abbildung von Tiefen- und Farbwerten auf.

UPDATE-Operatoren errechnen sich aufgrund aller Pixel, wel-che in vorherigen Videobildern eingefügt wurden und sich immernoch im Vordergrund befinden. UPDATE-Operatoren werden fer-ner in drei Kategorien unterteilt: Die Erkennung von Farbverände-rungen wird zwischen zwei Videobildern ausgeführt und hat einenUPDATECOL-Operator zur Folge. UPDATEPOS-Operatoren sorgenfür Veränderungen an der Geometrie und werden auf räumlichzusammenhängenden Bereichen von Bildpixeln analysiert. Fürbestimmte Pixel eines Bereiches werden neue Tiefenwerte berech-net. Nur wenn die Differenz zu bisherigen Tiefenwerten einenGrenzwert überschreitet, wird die 3D Information für den ganzenBereich neu berechnet. Der explizite Test aller Pixel ist aufgrundder Rechenkosten für die 3D Rekonstruktion nicht möglich.Unsere Methode stellt aber eine effizient Lösung für das Problemder unkorrelierten Textur- und Tiefenbewegungsfelder dar. Positi-ons- und Farbveränderungen führen zum kombiniertenUPDATEPOSCOL-Operator. Alle anderen Pixel, welche fürUPDATEs vorgemerkt wurden, bleiben unverändert und keine wei-tere Bearbeitung ist notwendig. Die 3D Operatoren und zugehöri-gen Daten können wie folgt zusammengefasst werden:

Abbildung 10: a) Bild einer gewählten Referenzkamera. b) Bild ei-ner zu korrigierenden Kamera. c) Korrigiertes Bild aus b) mit Para-metern von a).

Abbildung 11: a) Original-Videobild. b) Hintergrundtrennung

Abbildung 12: Beziehung zwischen 2D Pixeln und 3D Video-Fragmenten.

2D Pixel 3D Fragmente

ETH CS Technical Report #495, 20. September, 2005

6

(1)

beschreibt die Koordinaten eines Pixels, die Farbe, die 3D Koordinaten des Punkt-Samples und die Oberflächen-normale.

Bewegungsschätzung im Bildraum. blue-c verwendet einVerfahren zur Bewegungsschätzung im Bildraum, welches Farb-und Positionsveränderungen im Bildraum erkennt und daraus 3DFragment-Operatoren ableitet. Wir definieren die folgenden Bool-schen Funktionen, basierend auf der zuvor berechneten Hinter-grundtrennung:• : Gibt TRUE zurück, wenn Pixel zum Vordergrund in

Bild gehört.• : Gibt TRUE zurück, wenn die Farbdifferenz von

Pixel zwischen den Bildern und einen Schwellwertüberschreitet.Mit Hilfe dieser Funktionen können wir nun jedem Videopixel

in jedem Bild eine der folgenden 5 Klassen zuordnen:

(2)

Dabei sind der Boolsche AND und der Boolsche NOTOperator. Eine solche Klassifikation des Videobildes einer derKameras ist in Abbildung 13 gezeigt.

Alle Pixel, welche als new klassifiziert werden, rufen einenINSERT-Operator auf, expired Pixel einen DELETE-Operator undcolor changed einen UPDATECOL-Operator. Wie oben beschrie-ben, können sowohl unchanged als auch color changed Pixel einenUPDATEPOS-Operator aufrufen. Für jeden Zeitschritt werden dieseOperatoren in einen 3D Videostrom eingesetzt und über das Netz-werk übertragen.

Dynamische Kamerakontrolle. Eine erste Massnahme zurBeschleunigung der 3D Video-Berechnungen für die aktuelleKameraposition des Kommunikationspartners ist die dynamischeAuswahl einer Untermenge von aktiven Kameras, typischerweise

basierend auf ihrer Distanz von dieser Position. Wir definieren fürjede Kamera einen so genannten Aktivitätslevel und gewichtendabei die Beiträge der einzelnen Kameras, gemäss eines Interpola-tionsverfahrens aus [Buehler et al. 2001]. Dabei unterscheidet manzwischen Kameras, die nur für die geometrische Rekonstruktionaktiv (geometry active) sind sowie Kameras, welche zur Berech-nung der Darstellungsattribute Informationen liefern (textureactive). Üblicherweise ist die Anzahl der geometrieaktiven Kame-ras höher als diejenige der texturaktiven Kameras. Zur Implemen-tation dieser Funktionalität muss das Kommunikationsgerüst(Abschnitt 5) die virtuelle Kameraposition des Kommunikations-partners über das Netzwerk zurückliefern. Dies erfolgt in Anleh-nung an einen Vorschlag des MPEG-Komitees für 3D Video[Smolic und Yamashita 2002].

Die beschriebene Selektion macht die 3D Videorepräsentationzwar abhängig von der aktuellen Kameraposition, beschleunigt dieBerechnung aber in signifikantem Masse. Je mehr Kameras zurBerechnung herangezogen werden, desto unabhängiger wird dieRepräsentation vom virtuellen Blickpunkt. Dies ist z. B. bei Mehr-punkt-Verbindungen mit mehreren Kommunikationspartnern vonBedeutung, wo unter Umständen viele Kamerapositionen gleich-zeitig berechnet werden müssen. Abbildung 14 illustriert die dyna-mische Kamerakontrolle.

Eine zweite Massnahme zur dynamischen Adaptierung desBerechnungsaufwandes pro Knoten sind so genannte Texturni-veaus. Diese definieren die Anzahl der 2D Bildelemente einerbestimmten Kamera, welche der 3D Rekonstruktion jeweilszugrunde gelegt sind. Das Texturniveau bestimmt damit die aktu-elle Auflösung, mit der das Videobild verarbeitet wird. Die initia-len Gewichte berechnen sich gemäss der oben angegebenenDistanzgewichtung. Zusätzlich verwenden wir zur Berechnung desTexturniveaus ein Mass für die aktuelle Systemauslastung desjeweiligen Rechner-Knotens für die 3D Rekonstruktion. Ist alsoder Berechnungsaufwand zu gross, so reduziert sich die Bildauflö-sung, was wiederum zu einer Reduktion des Berechnungsaufwan-des führt. Dies implementiert eine einfache, lineare Regelung zurStabilisierung der Bildwiederholraten. Das Bildabtastmuster fürverschiedene Texturniveaus ist in Abbildung 15 veranschaulicht.

Jede Kamera ist mit einem PC-Knoten verbunden, welcher diebeschriebene Videopipeline berechnet. Ein zentraler Masterknotenübernimmt schliesslich die silhouettenbasierte 3D Rekonstruktion.Die für einen bestimmten Zeitschritt jeweils aktuelle Repräsenta-tion wird vollständig auf der Empfängerseite gehalten und durchdie beschriebenen Operatoren entsprechend aktualisiert. Die dazuentwickelte Datenstruktur erlaubt einen zeitgleichen, asynchronenLese- und Schreibzugriff.

Abbildung 13: Die Berechnungen der 2D Pixel-Operatoren: a) Sil-houette zur Zeit . b) Silhouette zur Zeit . c) Klassifikationder Bildpixel gemäss Beschreibung im Text. Rot steht für expired,grün für new, blau für color changed, weiss für color unchangedund schwarz für Hintergrund.

INSERT: p' c,( ) P c n, ,( ) →

DELETE: p'( ) P( ) →

UPDATECOL: p' c,( ) P c,( ) →

UPDATEPOS: p'( ) Pold Pnew nnew, ,( )→

UPDATEPOSCOL: p' c,( ) Pold Pnew nnew c, , ,( )→⎩⎪⎪⎪⎪⎨⎪⎪⎪⎪⎧

p' c Pn

fg p' t,( ) p't

cd p' ti 1– ti, ,( )p' ti 1– ti

fg p' t,( ) fg p' t 1–,( ) cd¬ p' t 1– t, ,( )∧ ∧ : color unchangedfg p' t,( ) fg p' t 1–,( ) cd p' t 1– t, ,( ): ∧ ∧ color changedfg p' t,( ) fg¬ p' t 1–,( )∧ : new

fg¬ p' t,( ) fg p' t 1–,( ):∧ expiredfg¬ p' t,( ) fg¬ p' t 1–,( ):∧ background⎩

⎪⎪⎪⎨⎪⎪⎪⎧

∧ ¬

ti 1– ti

Abbildung 14: Illustration der dynamischen Kamerakontrolle.Grüne Kameras sind texturaktiv, rote Kameras sind geometrieaktiv,gelbe Kameras sind sowohl textur- als auch geometrieaktiv. GraueKameras sind inaktiv. a) für eine texturaktive Kamera, b) für 3 tex-turaktive Kameras.

ETH CS Technical Report #495, 20. September, 2005

7

Abbildung 16 zeigt Resultate aus einer Echtzeit 3D Video-Sequenz, welche im Hauptportal aufgenommen und berechnetwurde. Abbildung 16 c) zeigt auch eine korrespondierende Tiefen-karte.

5 Kommunikation und Netzwerkblue-c ist ein komplexes, verteiltes System, welches aus vielenheterogenen Subsystemen besteht. Es benötigt eine leistungsfähigeKommunikationsplattform, um alle relevanten Datenströme zuübertragen. Diese umfassen nicht nur 3D Videoinformation son-dern auch Daten für Audio, Synchronisation, Benachrichtigungen,Interaktion, 3D Szenengeometrie und andere. Eine detaillierteBeschreibung des blue-c Kommunikationssystems kann in Lam-boray et al. [2004] oder in der Dissertation von Lamboray [2004]gefunden werden.

5.1 DatentypenNeben der 3D Videoinformation unterscheiden wir zwischen denfolgenden Datentypen:• Bulk Data umfassen grosse Datenmengen der Anwendung oder

Szenenbeschreibung. Sie werden typischerweise bei Verbin-dungsaufbau einmal übertragen und nur sporadisch aktualisiert.

• Event und Message-basierte Kommunikation: Dies sind i. A.vom Benutzer initiierte Änderungen der aktuellen virtuellenSzene.

• Echtzeit-Audio: Diese ermöglichen die Sprachkommunikationin blue-c und sind sehr empfindlich gegenüber systembedingtenVerzögerungen.

• Tracking und Systeminformation: Dies sind Daten zur Ressour-cenverwaltung sowie Tracking-Daten zur dynamischen Kame-rakontrolle.

5.2 KommunikationsarchitekturDie Architektur des für blue-c entworfenen Kommunikationssy-stems ist in Abbildung 17 dargestellt. Grundsätzlich galt es, dieForderungen nach zuverlässigen Services sowie ein fortschrittli-ches Programmiermodell, wie es z. B. von CORBA zur Verfügunggestellt wird, mit den Echtzeitanforderungen der 3D Videokom-munikation in Einklang zu bringen. Zu diesem Zweck unterschei-det das Kommunikationssystem zwischen einemDatenübertragungs-API sowie einem Service-API.

5.3 Datenübertragungs-APIDas Datenübertragungs-API des Kommunikationssystems stelltKanalschnittstellen zum Versenden und Empfangen von Daten zurVerfügung. Die verteilten Anwendungsdaten sind in Nachrichten-Objekte organisiert, welche ihre Nutzdaten über Nachrichten ineinen Übertragungspuffer schreiben. Der Empfänger analysiertden Übertragungspuffer, die Nachrichten werden dekodiert und einCallback-Mechanismus informiert die Anwendung über die ange-kommene Nachricht. Flusskontrolle und erneutes Übertragen ste-hen nur für den Übertragungspuffer zur Verfügung. Ein solcherPuffer kann sowohl Nachrichten nur eines bestimmten Typs alsauch Nachrichten verschiedener Typen beinhalten. Lange Nach-richten werden zerlegt und über mehrere Puffer verteilt. Alle Puf-fer werden über Speicher-Pools behandelt, so dass dieSpeicherzuordnung nur während des Systemstarts erfolgen muss.

Die Echtzeitdaten werden über einen Kommunikationskanalübertragen, welcher aus einem Vorwärtskanal für Nutzdaten sowieeinen Rückwärtskanal für Kontrolldaten besteht. Kontrolldatenbeinhalten z. B. die aktuelle Kameraposition, Paketverlustraten,Paketschwankungen, etc. Dieser Ansatz erfolgt in Anlehnung andas RTP/RTCP Protokoll, wobei RTP die unsichere Übertragungvon Nutzdaten übernimmt und RTCP die periodische Kontrollin-formation überträgt.

Ebenso stellt das API eine Reihe von Codecs bereit. Üblicher-weise werden die Daten vor der eigentlichen Übertragung nochEntropie-codiert. Dazu verwenden wir eine effiziente Varianteeines arithmetischen Codierers [Martin 1979].

5.4 Service-APIDas Service-API umfasst eine Reihe von Diensten, welche aufdem CORBA-Standard für verteilte Objektkommunikation beru-hen. Der Naming Service dient zur Lokalisierung von verteiltenObjekten. Der Time Service erlaubt es, synchronisierte Zeitmarkeninnerhalb des Netzwerks zu vergeben. Der Notification Serviceermöglicht es, sporadische Ereignisse an interessierte Knoten zuverteilen. Das Verbindungsmanagement der Kommunikationska-näle basiert auf dem CORBA Audio/Video Streaming Service. Dieaktuelle Implementation verwendet das TAO/ACE Toolkit (http://www.cs.wustl.edu/~schmidt/TAO.html).

Die Knoten eines einzelnen blue-c Portals sind über ein Stan-dard 100 Mbps oder 1000 Mbps Ethernet Netzwerk verbunden, diebeiden Portale hingegen ausschliesslich über Gigabit-Ethernet,wobei auch ATM-OC3 grundsätzlich unterstützt ist. Das Systemermöglicht Voll-Duplex 3D Video, HiFi-Sprachkommunikationsowie eine Vielzahl von Benutzerinteraktionen.

5.5 3D Video-OperationsmodiDie in Abschnitt 4 beschriebenen 3D Video-Operatoren implemen-tieren auf Stufe des Kommunikationssystems drei verschiedeneBetriebsmodi für 3D Video in Anlehnung an den bekanntenMPEG-Standard zur konventionellen Videoübertragung. DieseModi umfassen:

Abbildung 15: Texturniveaus: a) Abtastmuster für verschiedeneAktivitätsstufen, b) Beispiel für 3 aktive Kameras auf unterschied-lichen Niveaus, gesehen von einer virtuellen Kamera aus.

Abbildung 16: 3D Video-Fragment-Objekte. a) und b) GerenderteBilder von einem virtuellen Betrachtungspunkt. c) Tiefenkarte desObjektes aus b).

0

0

0

0

0

0

0 0

00

0 0

0

1

1

1

1 1

1

1

1

2 2

2

2

2

2

2

2

3

3

3

3 3

3

3

35

5

5

5 5

5

5

56

6

6

6 6

6

6

6

4

44

4

4 4

4 4

7

7

7

7

7

77

7

Abbildung 17: Architektur der blue-c Kommunikationsstufe.

Sprachkommunikation

Akqu

isitio

n

Echtzeit-Übertragung

Rend

erin

g

Gigabit-Ethernet

CORBA

Verteilter Szenengraph

Verteilte Anwendung

3D Video

ETH CS Technical Report #495, 20. September, 2005

8

• I-Mode (volle Rekonstruktion): Das 3D Objekt wird hierbei fürjeden Zeitschritt komplett neu übertragen und rekonstruiert. Diezeitliche Kohärenz der Daten kann nicht ausgenutzt werden.

• P-Mode (zuverlässige Schätzung): Dieser Modus nutzt dieInformation des vorherigen Zeitschrittes und überträgt nur dieÄnderungen in Geometrie und Farbe. Hierbei müssen derRekonstruktionsprozess sowie der Renderingprozess eine kon-sistente Datenrepräsentation teilen. Daher wird eine zuverläs-sige Übertragung benötigt.

• R-Mode (redundante Schätzung): Auch dieser Modus nutzt diezeitliche Kohärenz der Daten und überträgt nur differentielleInformation zwischen zwei Zeitschritten. Zusätzlich werden inregelmässigen Intervallen Teile der 3D Repräsentation neuberechnet, so dass sich die gesamte 3D Datenstruktur periodischerneuert. In diesem Fall ist keine zuverlässige Übertragung not-wendig und das System wird robuster gegen Paketverluste imNetzwerk. Durch die redundante Codierung der Daten kommtes nicht zu einer Akkumulation von Fehlern. Inkonsistenzenzwischen Rendering und Rekonstruktion treten nur temporärauf.

In der Praxis haben sich I- und P-Modi als weniger leistungsfähigerwiesen. Im I-Modus kann nur eine begrenzte Anzahl vonVideofragmenten pro Zeitschritt berechnet werden, im P-Modusführt die zuverlässige Übertragung zu höheren Schwankungenbeim Rendering. Der R-Mode stellt daher einen guten Kompro-miss für unsere Bedürfnisse dar (siehe auch Abschnitt 7).

6 blue-c APIDas für den Benutzer sichtbare blue-c API stellt eine Anwen-dungsentwicklungsumgebung zur Verfügung, welche einen flexi-blen Zugriff auf alle besonderen Funktionen der blue-c zulässt.Insbesondere kann der Benutzer 3D Graphik, Sprache, Klangsyn-these und -ausgabe, 3D Video, Szenenverteilung, Interaktionsge-räte, u.ä. leicht und komfortabel in eine Anwendung einbinden.Die entsprechenden Subsysteme werden als Dienste zur Verfügunggestellt und durch den blue-c API Kern verwaltet. Eine detaillierteDarstellung des API ist in Naef et al. [2004] oder in der Disserta-tion von Naef [2004] zu finden.

Das API ist so ausgelegt, dass es eine beliebige Anzahl vonPortalen mit unterschiedlichen Hard- und Softwarekonfigurationenunterstützt. Einen konzeptionellen Überblick liefert Abbildung 18.

Der Szenengraph, welcher die komplette virtuelle Welt repräsen-tiert, basiert auf dem SGI OpenGL Performer [Rohlf and Helman1994] Toolkit, welches um Methoden zur Verteilung und Synchro-nisation erweitert wurde. Performer unterstützt mehrere synchroni-sierte Rendering-Pipes sowie Multiprozess-Rendering mit hohemGraphik-Durchsatz.

Der Szenengraph wurde um spezielle Knoten erweitert, welchedie transparente Verwendung von 3D Video-Objekten erlauben.Sie sind den konventionellen Objektknoten gleichgestellt und

unterstützen Transformationen, Culling und Okklusionsbehand-lung. Die 3D Videofragmente werden in einem Callback mit opti-miertem OpenGL Code dargestellt. Das eigentliche Renderingerfolgt über einen Algorithmus, welcher auf punkbasierte Graphikspezialisiert ist [Zwicker et al. 2001].

Ebenso sind Audio-Knoten Teil der Szene und erlauben es,räumliche Sound-Events einzubinden. Aktive Knoten unterstützenObjektinteraktion sowie die Auslösung von Animationen. Kon-ventionelle 2D Videoknoten sind sowohl für lokale Videodateienals auch für verteilte Kameras über spezielle Texturknoten imple-mentiert. Alle Knoten einer Szene besitzen eine Schnittstelle, wel-che Nachbildung und Synchronisation über die einzelnenStandorte hinweg erlaubt. Wir erreichen kurze visuelle Antwort-zeiten auf Objektmanipulationen in Verbindung mit Szenenkonsi-stenz durch ein relaxed locking Schema, bei dem kurzfristigeInkonsistenzen schnell wieder behoben werden. Dabei werdenÄnderungen lokal zugelassen, ohne dass der Benutzer Besitzer desKnotens ist. Die Änderungen werden allerdings erst versendet,wenn der Benutzer zum Besitzer des Knotens wird. Selten kann esvorkommen, dass ein Besitzer-Transfer verweigert wird. In diesemFall werden die lokalen Änderungen automatisch zurückgesetzt.Dies hat sich in der Praxis sehr bewährt. Das Synchronisationssy-stem mit leicht angepasstem Kommunikations- und Locking-System wird ebenfalls fürs Cluster-Rendering eingesetzt.

Die blue-c nutzt die volle Leistungsfähigkeit der parallelenHardware des Graphik-Servers. Die Decodierung und die Vorver-arbeitung der 3D Videoströme erfolgt in einem getrennten Prozess.Ebenso besitzen die Audio-Verarbeitung, die 2D Video-Decodie-rung sowie der Tracker eigene Prozesse. Die Interprozesskommu-nikation ist mittels message passing implementiert, welches dieVerteilung über ein PC-Cluster ermöglicht. Das API steht imMoment sowohl auf einer Shared-Memory Architektur als auchauf PC-Clustern zur Verfügung und unterstützt IRIX, Linux undWindows Betriebssysteme.

7 Resultate und AnwendungenIm Laufe des Projektes hat die Projektgruppe diverse Beispielan-wendungen aus den Bereichen Architektur, Maschinenbau undUnterhaltung realisiert. Diese illustrieren die Leistungsfähigkeitdes Systems und dienen als Plattform für Untersuchungen hin-sichtlich der Systemperformanz.

7.1 SystemleistungDie beschriebene 3D Videopipeline rekonstruiert im Moment 3D-Videos bestehend aus ca. 25’000 Fragmenten bei 5 Bildern/s oderca. 15’000 Fragmenten bei 8.9 Bildern/s. Die Bildwiederholrate istdurch die aktuelle Hardware, insbesondere die synchronisiertenFirewire-Kameras, begrenzt. Der verwendete Rechner-Cluster ent-hält 1.8 GHz Intel Pentium4 Prozessoren.

Abbildung 19 zeigt die Bandbreitenverteilung eines typischendifferentiellen 3D Videostroms, welcher mit fünf geometrieakti-ven und drei texturaktiven Kameras generiert wurde. Das Zeitfen-ster beträgt dabei 60 s, die durchschnittliche Bandbreite 2.6 Mbps.Die Spitzen in der Bitrate entsprechen den Bewegungen der Per-son und der Veränderung von aktiven Kameras, welche wiederumstark von den Veränderungen am virtuellen Betrachtungspunktabhängen. Die stärksten Spitzen werden hauptsächlich bei derÜbergabe von Kameras gemessen. Die Update-Rate der Frag-mente kann über benutzerdefinierte Schwellwerte gesteuert wer-den; damit kann die Bildqualität gegenüber dem Bandbreiten- undRechenbedarf abgestimmt werden. INSERT und DELETE-Operato-ren steuern 25% und 12% der Gesamtbitrate bei, die restlicheBandbreite wird von den UPDATE-Operatoren verbraucht. In derBeispielsequenz von Abbildung 19 werden 50’000 Operationenpro Sekunde verarbeitet. 40% der Operationen sind entwederINSERTs oder DELETEs, die verbleibenden 60% sind UPDATEs. Der

Abbildung 18: Komponenten des blue-c API

Anwendung

blue-c Kern

Synchronisations-ManagerKlassengenerator

Knoten-Manager

Netzwerk

Graphikausgabe

Audioausgabe

Szenengraph

Verteilt

ETH CS Technical Report #495, 20. September, 2005

9

Rekonstruktionsprozess erzeugt doppelt so viele Farb- wie Positi-onsveränderungen. Detailliertere Leistungsanalysen zum differen-tiellen 3D Videostrom sind in [Würmlin 2004] zu finden.

Die gesamte Systemlatenz von der 2D Akquisition bis zumRendering beim Kommunikationspartner liegt zwischen 3 und 5Zeitschritten. Die verschiedenen Betriebsmodi einer 3D Video-Übertragung werden nun in einem Experiment verglichen. Das 3DVideosystem wird in Echtzeit betrieben, allerdings werden dieimmer gleichen Bilder einer vorab aufgenommenen Videosequenzals Eingabedaten verwendet. Zusätzlich ermöglicht ein Simulati-onsmodul auf der Netzwerkebene Paketverluste nachzubilden. AlsQualitätsmerkmal für die 3D Videodarstellung verwenden wir dieAnzahl der Punkt-Samples. Abbildung 20 a) zeigt die Überlebens-funktion der Punkt-Samples für die unterschiedlichen Betriebs-modi. Die vollständige Neuberechnung aller Punkte für jedenFrame lässt nur eine verhältnismässig geringe Auflösung zu, selbstbei einer sehr kleinen Bildwiederholrate. Der nicht redundante P-Modus erlaubt die durchschnittlich höchste Auflösung bei einerverhältnismässig geringen Bitrate, siehe Abbildung 20 b). Der red-undante R-Modus—in Abbildung 20 mit zwei unterschiedlichenRedundanzgraden dargestellt—erlaubt eine vernünftige Auflö-sung, benötigt aber eine höhere Bitrate.

Der eigentliche Vorteil der redundanten Codierung zeigt sichin Abbildung 21. In diesem Versuch wurden unterschiedlich starkePaketverluste während der Übertragung simuliert. Die durch-schnittliche Anzahl Punkt-Samples bleibt im R-Modus nahezuunverändert. Im P-Modus hingegen bewirken die Paketverlustegrössere Veränderungen in der Auflösung siehe Abbildung 21 a).Die im P-Modus nötige verlustfreie Übertragung bewirkt deswei-teren unregelmässige Aufdatierungen beim Renderer siehe Abbil-dung 21 b). Die in dieser Simulation erzielten Ergebnisse konntenauch bei einer Internet-Übertragung eines Echtzeit 3D Vide-ostroms von der ETH Zürich an die University of California inDavis beobachtet werden.

Wie schon in Abschnitt 5.5 erwähnt, kommt es im R-Modus zutemporären Inkonsistenzen, die aber über die Zeit ausgeglichenwerden. Abbildung 22 a) zeigt ein Bild aus einer 3D Videoübertra-gung, in dem keine Fehler durch eine verlustbehaftete Netz-werkübertragung entstanden sind. Abbildung 22 b) zeigt einähnliches Bild mit fehlenden UPDATE- und DELETE-Operatoren. InAbbildung 22 c) ist eine Reihe von INSERT-Operatoren verlorengegangen, dies zeigt sich an den fehlenden Punkt-Samples in derrechten Bildhälfte. Detailliertere Leistungsanalysen zum blue-cSystem sind in [Lamboray 2004] zu finden.

7.2 Bildqualität und Anwendungen

Zur Demonstration der Kernfunktionalität der blue-c implemen-tierten wir zunächst einen “3D-Spiegel”. Dieser erlaubt es demBenutzer, ein dreidimensionales, stereoskopisches Bild seinerSelbst zu sehen und damit zu navigieren und zu interagieren. Der

Abbildung 19: Bitrate und Verteilung eines differentiellen 3D Vi-deostroms über 60 Sekunden Aufnahmezeit

0.0

1.0

2.0

3.0

4.0

5.0

6.0

0 10 20 30 40 50 60Zeit [s]

Ba

nd

bre

ite [

Mb

ps]

INSERT UPDATECOL UPDATEPOS DELETE

Abbildung 20: Keine simulierten Paketverluste: a) Anzahl Punktepro Frame; b) Benötigte Bitrate in Megabit pro Sekunde.

Abbildung 21: Simulierte Bündelstörung: a) Anzahl Punkte proFrame; b) Periode zwischen zwei Frames in Millisekunden.

1%

10%

100%

0 5000 10000 15000 20000 25000 30000

Anzahl Punkte pro Zeitschritt

I-Mode 3fps I-Mode 8fps P-Mode 8fps

R1-Mode 8fps R1.5-Mode 8fps

1%

10%

100%

0.0 0.5 1.0 1.5 2.0 2.5 3.0 3.5 4.0 4.5 5.0 5.5

Bandbreite [Mbps]

a)

b)

1%

10%

100%

0 5000 10000 15000 20000 25000 30000

Anzahl Punkte pro Zeitschritt

P-Mode (95, 25) P-Mode (98, 80) P-Mode (99, 50) P-Mode (99, 80)

R1-Mode (95, 25) R1-Mode (98, 80) R1-Mode (99, 50) R1-Mode (99, 80)

0.1%

1.0%

10.0%

100.0%

0 200 400 600 800 1000 1200 1400 1600

Inter-frame Periode [ms]

a)

b)

ETH CS Technical Report #495, 20. September, 2005

10

3D Spiegel im blue-c Hauptportal ist in Abbildung 23 illustriertund zeigt auch links unten das Bild der Rendering Engine, welchesauf die Flüssigkristall-Projektionswände abgebildet wird.

Aufgrund der Stereoprojektionen ist es grundsätzlich nichtmöglich, die visuelle Qualität der Projektion wiederzugeben, sowie sie vom Benutzer empfunden wird. Nichtsdestoweniger gebendie Bilder einen Eindruck von der aktuellen Leistungsfähigkeit desSystems und zeigen dessen Grenzen auf. Es sei auch darauf hinge-wiesen, dass die Glanzlichter, welche in den Bildern vom Haupt-portal auftreten, zu einem grossen Teil durch die Synchronisationder aktiven Brillen mit der Projektion eliminiert werden. Zur Auf-nahme ist das Projektionssystem zur besseren Illustration in denMonomode geschaltet worden.

Abbildung 24 gibt einen weiteren Blick in das Portal und illu-striert die immersive Projektion. Der Anwendungshintergrund istin diesem Fall Modedesign, wobei man sich vorstellt, dass einräumlich getrenntes Model aktuelle Entwürfe präsentiert. Hierbeistellt die räumliche Dimension eine bedeutende Komponente zurzwischenmenschlichen Kommunikation sowie zur Erfassung vonForm und Design dar. Eine detaillierte Untersuchung dieserAspekte ist in der Dissertation von Lang [2004] zu finden.

Abbildung 25 zeigt ein Bild einer bidirektionalen 3D Video-konferenz zwischen den zwei blue-c Portalen und illustriert dieBenutzerinteraktion. Im kleinen Bildausschnitt links unten ist eineoriginale Kameraansicht des Nebenportals gezeigt. Das grosseBild gibt wiederum einen Einblick in das Hauptportal und zeigtdas 3D Videobild des Gegenübers, welches vom Benutzer, gesteu-ertdurch eine 3D Maus, beliebig betrachtet werden kann.

Abbildung 26 zeigt eine unidirektionale Verbindung zwischenNebenportal und Hauptportal. Zur besseren Illustration der Projek-tionsqualität wurde hier auf die LED Beleuchtung verzichtet.

Neben der Kameraauflösung ist die Qualität des 3D Videosvon verschiedenen Faktoren abhängig: Erstens, ist die 3D Rekon-struktion immer noch sehr berechnungsaufwändig und führt zueiner Limitierung der Auflösung des Fragmentstromes. Eine mög-liche Erweiterung der Berechnungsknoten, welche die 3D Rekon-struktion durchführen, würde die Leistung signifikant verbessern.Abbildung 27 und Abbildung 28 zeigen Bildschirmphotos vomHauptportal einer 3D Video-Übertragung ausgehend vom Neben-portal und illustrieren die 3D Videoqualität in verschiedenen Auf-lösungsstufen.

Obwohl die Segmentierung relativ gut funktioniert, führen fal-sche Zuordnungen zu falschen Silhouetten, welche die Genauig-keit der 3D Rekonstruktion zu bestimmten Zeiten verschlechtern.Hier würde eine heuristische Schätzung der Silhouettenqualitäthelfen, um beschädigte Silhouetten einzelner Kameras zu verwer-fen. Ferner müssen die LED-Arrays des Hauptportals sehr sorgfäl-tig abgestimmt und gedämpft werden, um an gewissen Stellen desBenutzers einer Überbelichtung vorzubeugen.

Abbildung 29 präsentiert die Auflösungsgrenzen des 3DVideos in einer extremen Grossaufnahme. Wir stellen die zirkulä-ren 3D Videoprimitive in der Abbildung unten zur Illustration derAbtastverteilung opak dar. Die entsprechende Grossaufnahme desechten Benutzers ist in der Abbildung oben dargestellt. Die Farb-verteilung der Primitive gibt eine grobe Wiedergabe des hochauf-lösenden Texturmusters des Rockes.

Abbildung 22: Beispiel einer 3D Videoübertragung mit Visualisie-rung unterschiedlicher Artefakte, welche durch eine verlustbehafte-te Übertragung entstehen: a) Keine Paketverluste; b) Verlust vonUPDATE- und DELETE-Operatoren; c) Verlust von INSERT-Operato-ren.

Abbildung 23: 3D Spiegel im blue-c Hauptportal mit entsprechen-dem projizierten Bild direkt von der Rendering Engine.

Abbildung 24: 3D Spiegel im blue-c Hauptportal.

Abbildung 25: Bi-direktionale 3D Video-Übertragung.

ETH CS Technical Report #495, 20. September, 2005

11

Ein weiteres virtuelles Verkaufsszenarium ist in Abbildung 30und Abbildung 31 dargestellt. Ein Autoverkäufer präsentiert darinein Luxusauto. Der Benutzer taucht dabei in eine virtuelle Szeneein, während sein 3D Video zum Gegenüber übermittelt und dar-gestellt wird. Um die Qualität des 3D Videos zu demonstrieren,wurde die finale Szene auf die Flüssigkristallwände des Hauptpor-tals projiziert. In Abbildung 31 ist deutlich eine zu starke Aus-leuchtung des Benutzers sichtbar.

Abbildung 26: Unidirektionale 3D Video-Übertragung.

Abbildung 27: Bildschirmphoto einer bidirektionalen 3D Video-Übertragung.

Abbildung 28: Bildschirmphoto einer bidirektionalen 3D Video-Übertragung.

Abbildung 29: Grossaufnahme eines Bereichs der Person. Obendas Original, unten das korrespondierende 3D Video-Bild.

Abbildung 30: Virtuelle Verkaufsanwendung mit 3D Videobild.

Abbildung 31: Bildschirmphoto des virtuellen Autoladens.

ETH CS Technical Report #495, 20. September, 2005

12

Abbildung 32 illustriert die Benutzerinteraktion in einerSchachanwendung. Ein lebensgrosses Schachfeld wird dargestellt,in welchem zwei räumlich entfernte Benutzer gegeneinander spie-len können und dabei auch in 3D leben können.

8 Zusammenfassung und zukünftige Arbeitenblue-c ist ein neuartiges Hard- und Softwaresystem, welches dieVorteile einer CAVE™-artigen Projektionsumgebung mit gleich-zeitiger 3D Videoverarbeitung kombiniert und den Eindruck dervollständigen Immersion kreiert. blue-c ist ein bedeutender Schrittin Richtung wahrhafter Telepräsenz, also des Eindruckes “dort zusein”. Wenngleich blue-c das weltweit erste System seiner Art dar-stellt, so müssen dennoch zahlreiche Limitationen in der Zukunftüberwunden werden. Neben einer Verbesserung der Rekonstrukti-onsqualität soll blue-c insbesondere für mehrere Benutzer gleich-zeitig nutzbar gemacht werden. Ferner bedarf es neuartigerhaptischer Ausgabegeräte zur Rückkopplung taktiler Information.

Ein weiterer bedeutender Aspekt ist die Portabilität desSystems sowie seine Skalierbarkeit hinsichtlich der Anzahl derProjektoren und des Immersionsgrades. Unsere aktuellen For-schungen konzentrieren sich auf die Bereitstellung von kleinen,portablen Einheiten, so genannter “Presence Bricks”, welche Pro-jektor, mehrere Kameras sowie Lautsprecher und Mikrophone ent-halten. Mittels der Methode des “unsichtbaren strukturiertenLichtes” können wir Tiefenkarten hoher Qualität, für den Benutzerunsichtbar, erfassen und mit gleichzeitiger Projektion kombinieren[Cotting et al. 2004]. Diese und weitere Aspekte in Bezug auf neu-artige Interaktionsmöglichkeiten und kollaborative Anwendungenwerden im Rahmen des Nachfolgeprojektes blue-c-II (http://blue-c-II.ethz.ch) erforscht.

DanksagungDas blue-c Projekt wurde durch die ETH Zürich im Rahmen einesPolyprojektes, Nr. 0-23803-00, finanziert. Wir danken MaiaEngeli, Ludger Hovestadt, Esther Koller-Maier, Andreas Kunz,Silke Lang, Markus Meier, Kuk Hwan Mieusset, Gerhard Schmitt,Oliver Staadt, Kai Strehlke, Tomas Svoboda, Andrew VandeMoere und Luc Van Gool für die Mitarbeit.

ReferenzenAGRAWALA, M., BEERS, A. C., FRÖHLICH, B., HANRAHAN, P. M.,

MCDOWALL, I., AND BOLAS, M., 1997. The two-user responsiveworkbench: Support for collaboration through independentviews of a shared space. Proceedings of SIGGRAPH 97, pages327–332, ACM SIGGRAPH / Addison Wesley.

BUEHLER, C., BOSSE, M., MCMILLAN, L., GORTLER, S., UNDCOHEN, M., 2001. Unstructured lumigraph rendering. Proceed-

ings of SIGGRAPH 2001, pages 425–432. ACM Press / ACMSIGGRAPH / New York.

COTTING, D., NAEF, M., GROSS, M., FUCHS, H., 2004. Embeddingimperceptible patterns into projected images for simultaneousacquisition and display. Proceedings of the International Sympo-sium on Mixed and Augmented Reality 2004 (ISMAR 2004),pages 100–109, IEEE Computer Society Press.

CRUZ-NEIRA, C., SANDIN, D. J., UND DEFANTI, T. A., 1993. Sur-round-screen projection-based virtual reality: The design andimplementation of the cave. Proceedings of SIGGRAPH 93,pages 135–142, ACM SIGGRAPH / Addison Wesley.

DAVIS, J. W. UND BOBICK, A. F., 1998. Sideshow: A silhouette-based interactive dual-screen environment. Technical Report457, MIT Media Lab.

DEBEVEC, P., WENGER, A., TCHOU, C., GARDNER, A., WAESE, J.,UND HAWKINS, T., 2002. A lighting reproduction approach tolive-action compositing. Proceedings of SIGGRAPH 2002,pages 547–556. ACM Press / ACM SIGGRAPH / New York.

GIBBS, S. J., ARAPIS, C., UND BREITENEDER, C. J., 1999. TELE-PORT - towards immersive copresence. Multimedia Systems,7(3), pages 214–221, Springer.

GROSS, M., WÜRMLIN, S., NAEF, M., LAMBORAY, E., SPAGNO, C.,KUNZ, A., KOLLER-MEIER, E., SVOBODA, T., VAN GOOL, L.,LANG, S., STREHLKE, K., VANDE MOERE, A. UND STAADT, O.,2003. blue-c: A spatially immersive display and 3D video portalfor telepresence. Proceedings of SIGGRAPH 2003, pages 819–827, ACM Press / ACM SIGGRAPH / New York.

KAUFF, P. UND SCHREER, O., 2002. An immersive 3D video-con-ferencing system using shared virtual team user environments. InProceedings of CVE 2002, pages 105–112, ACM Press.

KRÜGER, W., BOHN, C.-A., FRÖHLICH, B., SCHÜTH, H., STRAUSS,W., UND WESCHE, G., 1995. The responsive workbench: A vir-tual work environment. IEEE Computer, pages 42–48, IEEEComputer Society Press.

LAMPERT, C., 1999. The world of large-area glazing and displays.In Switchable Materials and Flat Panel Displays, pages 2–11,SPIE.

LAURENTINI, A., 1994. The visual hull concept for silhouette-basedimage understanding. IEEE Transactions on Pattern Analysisand Machine Intelligence, 16(2), pages 150–162, IEEE Com-puter Society Press.

LAMBORAY, E., WÜRMLIN, S., UND GROSS, M., 2004. Real-timeStreaming of Point-based 3D Video. Proceedings of IEEE Vir-tual Reality Conference 2004 (VR 2004), pages 91-98, IEEEComputer Society Press.

LAMBORAY, E., 2004. A communication architecture for telepres-ence in virtual environments. Ph.D. Thesis, No. 15618, Depart-ment of Computer Science, ETH Zurich.

LANG, S., NAEF, M., GROSS, M., HOVESTADT, L., 2003. IN:SHOP:Using telepresence and immersive virtual reality for a new shop-ping experience. Proceedings of Vision, Modeling, Visualizaion2003 (VMV'03), pages 3–10, IOS Press.

LANG, S., 2004. The impact of video systems on architecture. Ph.D.Thesis, No. 15739, Department of Architecture, ETH Zurich.

Li, M., Magnor, M., Seidel, H.-P., 2004. Hardware-accelerated ren-dering of photo hulls. Computer Graphics Forum (Special issueon Eurographics 2004), vol. 23, no. 3, pages 635–642, BlackwellPublishing Ltd.

MARTIN, G., 1979. Range encoding: an algorithm for removingredu dancy from a digitised message. Video & Data RecodingConference. http://www.compressconsult.com/rangecoder/.

MATUSIK, W., BUEHLER, C., UND MCMILLAN, L., 2001. Polyhedralvisual hulls for real-time rendering. Proceedings of TwelfthEurographics Workshop on Rendering, pages 115–125,Springer.

Abbildung 32: Verteiltes, lebensgrosses Schach in der blue-c.

ETH CS Technical Report #495, 20. September, 2005

13

MATUSIK, W., BUEHLER, C., RASKAR, R., GORTLER, S. J., UNDMCMILLAN, L., 2000. Image-based visual hulls. Proceedings ofSIGGRAPH 2000, pages 369–374, ACM Press / ACM SIG-GRAPH / New York.

MESTER, R., AACH, T., UND DÜMBGEN, L., 2001. Illumination-invariant change detection using statistical colinearity criterion.DAGM2001, no. 2191 in LNCS, pages 170–177, Springer.

MOEZZI, S., KATKERE, A., KURAMURA, D. Y., UND JAIN, R., 1996.Immersive Video. Proceedings of the 1996 Virtual RealityAnnual International Symposium, pages 17–24, IEEE ComputerSociety Press.

MULLIGAN, J. UND DANIILIDIS, K., 2000. View-independent sceneacquisition for tele-presence. Proceedings of the InternationalSymposium on Augmented Reality, pages 105–110, IEEE Com-puter Society Press.

NAEF, M., STAADT, O., UND GROSS, M., 2004. blue-c API: A mul-timedia and 3D video enhanced toolkit for collaborative virtualreality and telepresence. Proceedings of VRCAI 04, pages 11–18,ACM Press.

NAEF, M., LAMBORAY, E., STAADT, O., UND GROSS, M., 2003. Theblue-c distributed scene graph. Proceedings of the IPT/EGVEWorkshop 2003, pages 125–133, ACM Press.

NAEF, M., STAADT, O., UND GROSS, M., 2002. Spatialized audiorendering for immersive virtual environments. Proceedings ofthe ACM Symposium on Virtual Reality Software and Technol-ogy 2002, pages 65–72, ACM Press.

NAEF, M.., 2004. blue-c API: Software support for collaborativevirtual reality. Ph.D. Thesis, No. 15632, Department of Com-puter Science, ETH Zurich.

NARAYANAN, P. J., RANDER, P., UND KANADE, T., 1998. Con-structing virtual worlds using dense stereo. Proceedings of theInternational Conference on Computer Vision ICCV 98, pages3–10, IEEE Computer Society Press.

PERLIN, K., PAXIA, S., UND KOLLIN, J. S., 2000. An autostereo-scopic display. Proceedings of ACM SIGGRAPH 2000, pages319–326, ACM Press / ACM SIGGRAPH / Addison Wesley.

POLLARD, S. UND HAYES, S., 1998. View synthesis by edge transferwith application to the generation of immersive video objects.Proceedings of the ACM Symposium on Virtual Reality Softwareand Technology, pages 91–98, ACM Press / ACM SIGGRAPH,New York.

POLLEFEYS, M., KOCH, R., UND VAN GOOL, L., 1999. Self-calibra-tion and metric reconstruction inspite of varying and unknownintrinsic camera parameters. International Journal of ComputerVision, 32(1), pages 7–25.

RASKAR, R., WELCH, G., CUTTS, M., LAKE, A., STESIN, L., UNDFUCHS, H., 1998. The office of the future: A unified approach toimage-based modeling and spatially immersive displays. Pro-ceedings of SIGGRAPH 98, pages 179–188, ACM SIGGRAPH/ Addison Wesley.

REINHARD, E., ASHIKHMIN, M., GOOCH, B., UND SHIRLEY, P.,2001. Color transfer between images. IEEE Computer Graphicsand Applications, 21(4), pages 34–41, IEEE Computer SocietyPress.

ROHLF, J. UND HELMAN, J., 1994. IRIS Performer: A high perfor-mance multiprocessing toolkit for real-time 3D graphics. Pro-ceedings of SIGGRAPH 94, pages 381–395, ACM SIGGRAPH/ Addison Wesley.

SADAGIC, A., TOWLES, H., LANIER, J., FUCHS, H., VAN DAM, A.,DANIILIDIS, K., MULLIGAN, J., HOLDEN, L., UND ZELEZNIK, B.,2001. National tele-immersion initiative: Towards compellingtele-immersive collaborative environments. Presentation givenat Medicine meets Virtual Reality 2001 Conference.

SMOLIC, A. UND YAMASHITA, R., 2002. Draft requirements for3DAV. JTC1/SC29/WG11 N4795. ISO/IEC.

SPAGNO, C. UND KUNZ, A., 2003. Construction of a three-sidedimmersive telecollaboration system. Proceedings of the IEEEVirtual Reality Conference 2003 (VR 2003), pages 37–44, IEEEComputer Society Press.

SPAGNO, C., 2004. Immersive virtual reality projection system withsimultaneous image acquisition using active projection screens.Ph.D. Thesis, No. 15273, Department of Mechanical and ProcessEngineering, ETH Zurich.

SUBRAMANIAN, S., RAJAN, V., KEENAN, D., SANDIN, D., DEFANTI,T., UND JOHNSON, A., 2002. A realistic video avatar system fornetworked virtual environments. Proceedings of Seventh AnnualImmersive Projection Technology Symposium.

SVOBODA, T., MARTINEC, D., UND PAJDLA, T., 2005. A convenientmulti-camera selfcalibration for virtual environments. PRES-ENCE: Teleoperators and Virtual Environments, 14(4), MITPress.

VEDULA, S., BAKER, S., UND KANADE, T., 2002. Spatio-temporalview interpolation. Proceedings of the 13th ACM EurographicsWorkshop on Rendering, pages 65–75, ACM Press.

WÜRMLIN, S., LAMBORAY, E., STAADT, O. G., UND GROSS, M.,2002. 3D video recorder. Proceedings of Pacific Graphics 2002,pages 325–334, IEEE Press.

WÜRMLIN, S., LAMBORAY, E., UND GROSS, M., 2004. 3D videofragments: Dynamic point samples for real-time free-viewpointvideo. Computers and Graphics, 28 (1), Special Issue on Coding,Compression and Streaming Techniques for 3D and MultimediaData, pages 3–14, Elsevier Ltd.

WÜRMLIN, S., 2004. Dynamic point samples as primitive for free-viewpoint video. Ph.D. Thesis, No. 15643, Department of Com-puter Science, ETH Zurich.

ZWICKER, M., PFISTER, H., VANBAAR, J., UND GROSS, M., 2001.Surface splatting. Proceedings of SIGGRAPH 2001, pages 371–378, ACM Press / ACM SIGGRAPH / New York.