dfn-expo - gwdg

1

© Copyright RRZN/RVS, Universität Hannover

DFN-Expo

Entwicklung und Demonstrationfortgeschrittener Online-Präsentationstechnologien

Abschlussbericht

Version 1.1 – 23.02.2000

Stephan Olbrich, Alexander von Berg, Ralf Einhorn, Stefan Heineke,Anne-Kathrin Ittmann, Wolfgang Sander-Beuermann, Helmut Pralle

Regionales Rechenzentrum für Niedersachsen (RRZN) /Lehrgebiet Rechnernetze und Verteilte Systeme (RVS)Prof. Dr.-Ing. Helmut Pralle

Universität Hannover

Inhaltsverzeichnis

1 Bezeichnung des Projektes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 Beschreibung des Projektes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.1 Ausgangssituation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32.2 Motivation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32.3 Projektziele . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.4 Projektgliederung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

3 Durchführung des Projektes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63.1 Personal. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63.2 Investitionen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63.3 Diplomarbeiten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73.4 Veröffentlichungen, Vorträge, Präsentationen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73.5 DFN-Arbeitskreis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93.6 Innovationspreis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93.7 Nutzung existierender Basisdienste und Software-Tools . . . . . . . . . . . . . . . . . . . . . . . . 10

4 Ergebnisse des Projektes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114.1 3D/VR im World Wide Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114.2 AV-Streaming. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394.3 Virtuelle Pavillons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 654.4 DFNzine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 994.5 Entwicklung einer Suchmaschine 3. Ordnung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117

5 Zusammenfassung und Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133Literaturverzeichnis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135

Das Vorhaben wurde aus Mitteln des Bundesministeriums für Bildung und Forschung (BMBF)durch den Verein zur Förderung eines Deutschen Forschungsnetzes e. V. (DFN-Verein) finanziert.

2

DFN-Expo – Abschlussbericht, Version 1.1 – 23.02.2000

2.1 Ausgangssituation 3


1 Bezeichnung des Projektes

Projekttitel: DFN-Expo – Entwicklung und Demonstrationfortgeschrittener Online-Präsentationstechnologien

Kurztitel: DFN-Expo

Ansprechpartner: Stephan OlbrichRegionales Rechenzentrum für Niedersachsen (RRZN)/Lehrgebiet Rechnernetze und Verteilte Systeme (RVS),Universität Hannover (Leiter: Prof. Dr.-Ing. Helmut Pralle)

Teilnehmende Einrichtungen: RRZN/RVS, Universität Hannover

Projektlaufzeit: 27 Monate (01.07.1997 – 30.09.1999)

2 Beschreibung des Projektes

2.1 Ausgangssituation

Multimedia-Informationsdienste, die in Kommunikationsnetzen verteilt angeboten werden, beruhenim wesentlichen auf Protokollen, Adressierungsschemata und Diensten, die im Internet etabliert sind.Dazu gehören z. B. die in RFCs beschriebenen Internet-Standards TCP/IP, URL, HTTP, HTML,MIME. Auf dieser Basis – im allgemeinen auch als „World Wide Web“ (WWW) bezeichnet – könnenAnwendungen entwickelt werden, welche Objekte beinhalten, die durch verschiedene Medientypen –wie z. B. Text, Hypertext, Bild, Graphik, Video, Audio, 3D/VR-Szenen – und Codierungsverfahrenrepräsentiert werden und gegenseitig durch sogenannte Hyperlinks referenziert werden können. Dieheute am meisten verbreitete und benutzte WWW-Client-Software stammt von der Fa. Netscape undrealisiert einen generischen Client. Dieser gestattet unter anderem die Einbettung von Multimedia-Viewern in HTML-Seiten mittels sogenannter Inline-Plugins sowie die Integration von Java-Applets.Dabei können Plugin- und Java- sowie JavaScript-Technologie auch kombiniert eingesetzt werden(„Live-Connect“).

Die Einhaltung zeitlicher Vorgaben für Realtime-Multimedia (Video, Audio) wird häufig nach derburst-artigen Übertragung einer vollständigen Datei am Client lokal bewirkt. Neuere Verfahren mithöherer Interaktivität – z. B. Streamingverfahren – werden innerhalb von Plugins angewandt. Dabeikommen spezielle Protokolle zum Einsatz, die die hierfür erforderlichen Kontrollflüsse und Transport-mechanismen bereitstellen. Außerdem können Plugins in gestaltete WWW-Seiten integriert werden.

2.2 Motivation

Generell sei auf funktionale, qualitative und leistungsmäßige Unzulänglichkeiten hingewiesen, die mitden derzeit verfügbaren, auf Internet-Standards basiserenden Werkzeugen verbunden sind. Dies stellteine wesentliche Motivation für die Projektbereiche, die sich mit der Technologie der Online-Präsenta-tion auseinandersetzen.

Um den gezielten Zugriff auf die eigentlich gewünschten Informationen zu erleichtern und damit dieNutzungseffizienz des im wesentlichen unstrukturierten Angebots an Nachrichten im WWW zu erhö-hen, werden Mehrwertdienste angeboten, die auf Suchmaschinen und/oder Datenbanken basieren.

4 2 Beschreibung des Projektes


2.3 ProjektzieleDas Projekt sollte dazu dienen, auf der Basis fortgeschrittener Online-Präsentationstechnologien einenBeitrag zur Ergebnispräsentation im Wissenschaftsbereich zu leisten. Besondere Berücksichtigungsollten neben den klassischen Medien Text und Graphik die Medien Audio (z. B. gesprochene Erläute-rungen), Video (Simulation, Visualisierung) und 3D-Szenen (Modelle) finden.

Den Ausgangspunkt bildete die erste „Virtuelle Weltausstellung“, die in den USA initiierte „Internet1996 World Exposition“ (http://park.org; seit Anfang 1997: „Central Park“), welche einen weltweitenVerbund gegenseitig gespiegelter Servermaschinen darstellt. Das RRZN/RVS beteiligte sich seit Mitte1996 daran aktiv durch den Betrieb des deutschen „Central-Park-Servers“ – unterstützt durch SiemensNixdorf AG und Deutsche Telekom AG – sowie die eigene Gestaltung und die Pflege von inhaltlichenBeiträgen.

Im Projekt „DFN-Expo“ sollten die Voraussetzungen zur adäquaten Präsentation hochwertiger Expo-nate aus dem deutschen Wissenschaftsbereich in einer eigenständig organisierten, virtuellen Ausstel-lung geschaffen werden. Als Basis dienten die auf Internet-Protokollen basierendenInformationsdienste als etablierte Plattform für Multimedia- und Virtual-Reality-Anwendungen überdie performante Kommunikationsinfrastruktur B-WiN (Breitband-Wissenschaftsnetz).

Der Schwerpunkt des Projekts lag auf der Unterstützung und Weiterentwicklung von Technologien,die eine qualitativ hochwertige Multimedia- bzw. Virtual-Reality-Online-Präsentation ermöglichen.Diese erfordern neben einem leistungsfähigen Netz die Nutzung von fortgeschrittenen Protokollen,Diensten und Anwendungen auf leistungsfähigen Client- und Server-Systemen.

Die Demonstration der Ergebnisse erfolgte durch exemplarische Exponate in virtuellen Pavillons aufdem allgemein zugänglichen WWW-Server www.dfn-expo.de.

Abb. 1. Welcome-Page des DFN-Expo-Webservers

2.4 Projektgliederung 5


2.4 Projektgliederung

Das Vorhaben gliederte sich in zwei Bereiche:

(A) Technologie-Bereich

In einem Technologie-Bereich sollten Forschungs- und Entwicklungsarbeiten zu den folgendenSchwerpunktthemen durchgeführt werden.

1. Zur Technologie der Präsentation:

3D/VR-Präsentation im WWWWeiterentwicklung des am RRZN/RVS seit 1994 implementierten Viewers „DocShow“ zueinem Inline-Plugin für WWW-integrierte „Virtuelle Realität“ hoher Qualität sowie Erarbei-tung von Prozessketten für die Erstellung von 3D-Medien und Ableitung anderer Medienty-pen.

AV-Streaming-VerfahrenWeiterentwicklung der seit mehreren Jahren am RRZN/RVS etablierten Prozessketten für dieVideopräsentation sowie des seit 1995 am RRZN/RVS erstellten Audio-Streaming-Players.

2. Verbesserung der Nutzungseffizienz durch neuartige Suchmechanismen:

Weiterentwicklung der MetasuchmaschinenZur Unterstützung für die themenorientierte Suche – z. B. nach weiteren Informationen zuden Basistechnologien der „DFN-Expo“ – sollte aus den seit 1996 am RRZN/RVS bereitge-stellten ersten deutschen Meta-Suchmaschinen ein neuer Suchmaschinentyp entwickelt wer-den.

(B) Demonstrationsbereich

Um die Ergebnisse aus dem Technologie-Bereich unmittelbar in praktische Anwendungen ein-fließen zu lassen und damit den Technologie-Transfer aktiv zu fördern, sollten in einem Demons-trationsbereich exemplarische Anwendungen präsentiert werden. Dies soll durch die Gestaltungeiner „Virtuellen Ausstellung“ sowie mit Hilfe praktischer Demonstrationen geschehen:

Gestaltung virtueller Pavillons als Rahmen für die Exponate in der „DFN-Expo“:

WerkstattDokumentation und Distribution der im Technologiebereich erarbeiteten Werkzeuge bzw.Prozessketten sowie Anwendungshilfen als MM/VR-Präsentation.

Electronic Magazine (E-Zine)Weiterentwicklung und Betrieb der am RRZN/RVS seit 1995 implementierten und betriebe-nen Online-Präsentation der DFN-Mitteilungen zur Unterstützung der Öffentlichkeitsarbeitdes DFN durch den Aufbau räumlicher Informationslandschaften und das Angebot daten-bank-basierter Mehrwertdienste.

Weitere ExponateVerwendung und Erprobung der Ergebnisse aus den zuvor genannten Teilprojekten in ver-schiedenen Informationsdienste-Anwendungsszenarien aus dem Wissenschaftsbereich inForm einer „Virtuellen Ausstellung“ mit zwei Abteilungen: einer „Galerie“ mit besondersherausragenden ausgewählten Exponaten und einer „Sammlung“ mit freiwilligen Beiträgen.

Praktische Demonstration fortgeschrittener MM/VR-Online-Präsentationstechnologie, d. h. z. B.aus den Projektergebnissen, und Bereitstellung der Basis für Vorführungen anderer DFN-Projektemit dem Bedarf für „High-Quality“-Systeme (Hardware, Software) für Multimedia- bzw. Virtual-Reality-Anwendungen:

im Haus (Multimedia-Labor des RRZN/RVS): z. B. Vorträge für entsprechende Interessenten-kreise bzw. potentielle Nutzergruppen, DFN-Arbeitskreis Informationsdienste.

vor Ort: z. B. CeBIT-Präsentationen.

6 3 Durchführung des Projektes


3 Durchführung des Projektes

3.1 PersonalAn dem Projekt waren die folgenden Personen beteiligt:

• Projektleitung– Prof. Dr.-Ing. Helmut Pralle– Dipl.-Ing. Stephan Olbrich

• Wissenschaftliche Mitarbeiter– Dipl.-Ing. Alexander von Berg– Dipl.-Ing. Ralf Einhorn– Dr.-Ing. Wolfgang Sander-Beuermann

• Designerinnen– Dipl.-Des. (FH) Anne-Kathrin Ittmann (ab 01.05.1998)– Dipl.-Des. (FH) Yvonne Scherzer (bis 31.03.1998)

• Wissenschaftliche Hilfskräfte– Frank Block– Stefan Heineke– Hulisi Karabag– Sascha-Matthias Kulawik– Darius-Nikolaus Krupinski– Claus-Michael Leonhardt– Tim Reuter– Yibing Zhao

3.2 InvestitionenWährend der Projektlaufzeit wurden die folgenden Systeme beschafft und in Betrieb genommen:

Hardware• 3D-Graphikrechner Silicon Graphics Onyx2 Infinite Reality (Racksystem), ausgestattet mit:

– 4 CPUs MIPS R10000 / 195 MHz– 2 GB Hauptspeicher, 9 GB Systemdisk– Fibre-Channel-Interface– 140 GB Fibre-Channel RAID (11 SCSI-Platten je 18 GB)– 2 Graphiksubsysteme „Infinite Reality“ mit je 2 Rastermanager-Boards und 64 MB Textur-

speicher und je einer Konsole (24“- und 20“-Monitore)– Video-Schnittstellen: PAL- und S-Video-Ausgänge, D1-Ausgang: Graphics to Video

Option (GVO), D1-Ein- und Ausgang: Digital Video I/O Option (DIVO)– Netz-Interfaces: 10/100 Mbit/s Ethernet, 155 Mbit/s ATM– System-Software: SGI Irix 6.5, SGI Varsity Development Package

• 3D-Stereo-Großbildprojektion zum Betrieb mit 3D-Graphikrechner Onyx2 (siehe oben), PC undverschiedenen Videogeräten. Dieses besteht aus:

– 2,40 m x 1,80 m „Black-Matrix“-Rückprojektionsscheibe– 2 Stck. Electrohome Marquee 9500 Projektoren mit Polarisationsfilterscheiben– PAL-/NTSC-Decoder und Switcher zur Umschaltung zwischen verschiedenen Quellen

• Audio-/Video-Ausstattung eines 3D-Stereo-Präsentationsraums am RRZN/RVS:– 6-Kanal-Verstärker (Surround-Receiver), Lautsprecher, S-VHS-Recorder, DVD-Player.– DA-Wandler zum Anschluss der Silicon Graphics Onyx2.

• Trackingsysteme:– Stereographics Crystal Eyes Virtual Reality („Desktop-VR“: ultraschall-basiert)– Polhemus Fastrak mit zusätzlichem Stylus („Wide Range“: elektromagnetisch)

• LCD-Shutterbrillen: Stereographics Crystal Eyes: 2 Emitter, 3 LCD-Stereo-Shutterbrillen

3.3 Diplomarbeiten 7


• Erweiterungen des WWW-Servers SGI Challenge L– 4 CPUs MIPS R4400 / 200 MHz– 1 GB Hauptspeicher– 140 GB SCSI RAID (11 SCSI-Platten je 18 GB)

• Arbeitsplatz zur Videobearbeitung (PC, DV-Interface, DV- und S-VHS-Videorecorder)

Software

• Desktop-Publishing, z. B. QuarkXpress (Windows, Mac)• 3D-Authoring, z. B. Kinetix 3D Studio Max (Windows)• Konvertierprogramme, z. B. MP3-Encoder (UNIX)• Hilfsbibliotheken, z. B. TGS OpenInventor, QT (Windows, UNIX)

3.3 DiplomarbeitenIm Rahmen des Projektes wurden die folgenden Diplomarbeiten angefertigt:

• Heineke, S.: Entwicklung von Suchmaschinen 3. Ordnung, 1999.• Pfuhl, W.: Zur Bewertung des Datenfluss- und Online-Präsentations-Verhaltens digitaler Reprä-

sentationen von 3D-Objekten, 1997.• Leonhardt, C.: Zur Anwendung von Streamingverfahren auf die Online-Präsentation von

Sequenzen virtueller 3D-Objekte, 1998.

3.4 Veröffentlichungen, Vorträge, PräsentationenTeilergebnisse des Projekts wurden wie folgt präsentiert:

Veröffentlichungen

• von Berg, A.: Mehr Wert Mitteilungen – Datenbank-basierte Mehrwertdienste für die DFN-Mit-teilungen. DFN-Mitteilungen, Nr. 43, März 1997.(http://www.rtb-nord.uni-hannover.de/dfn/mitteilungen/html/heft43/S10/S10.html)

• von Berg, A., Ittmann A., Quandel, G.: Web-based Magazine. DFN-Mitteilungen, Nr. 50, Juni1999.(http://www.dfn-expo.de/DFN-Zine/Ausgabe.php3?id=50)

• von Berg, A., Pralle, H.: A Concept for an Electronic Magazine. TERENA-NORDUnet Networ-king Conference (TNNC) 1999, 07.–10.06.1999, Lund University, Sweden. In: Computer Net-works, Vol. 31, Nr. 21, November 1999, Elsevier. (http://www.terena.nl/tnnc/4A/4A3/4A3.pdf)

• Olbrich, S., Pralle, H.: DFN-Expo: Wissenschaft – online präsentiert. UNI Magazin, Zeitschriftder Universität Hannover, Heft 1/1998.

• Olbrich, S., Quandel, G.: DFN-Expo – Zukunftsweisende Exponate in Virtuellen Pavillons. DFN-Mitteilungen, Nr. 44, Juni 1997.(http://www.rtb-nord.uni-hannover.de/dfn/mitteilungen/html/heft44/)

• Olbrich, S., Pralle, H.: High-Performance Online Presentation of Complex 3D Scenes. In: vanAs, H. R.: High Performance Networking – IFIP TC-6 Eighth International Conference on HighPerformance Networking (HPN ’98), Vienna, Austria, September 1998. Kluwer Academic Pub-lishers, 1998.(http://www.dfn-expo.de/Technologie/DocShow-VR/Vortraege/hpn98/)

• Olbrich, S., Pralle, H.: Online 3D – Leistungsfähige 3D / Virtual Reality Online-Präsentationkomplexer wissenschaftlicher Ergebnisse. DFN-Mitteilungen, Nr. 49, März 1999.(http://www.dfn-expo.de/DFN-Zine/Ausgabe.php3?id=49)

• Olbrich, S., Pralle, H.: Virtual Reality Movies – Real-Time Streaming of 3D Objects. TERENA-NORDUnet Networking Conference, Lund, Schweden, 1999. In: Computer Networks, Vol. 31,Nr. 21, November 1999, Elsevier. (http://www.terena.nl/tnnc/2A/2A1/2A1.pdf)

• Sander-Beuermann, W.: Die Internet-Suchmaschinen der Zukunft. c’t 13/1998.(http://www.heise.de/ct/98/13/178/)



Vorträge

• von Berg, A.: Eine flexible C++-Klassenbibliothek zum Zugriff auf ORACLE-Datenbanken ausdem WWW. 6. Treffen des DFN-Arbeitskreises Informationsdienste, Hannover, 11.02.1998.(http://www.rvs.uni-hannover.de/people/berg/Ora++-Vortrag.pdf)

• von Berg, A.: DFNzine - webbased magazine. Technisch-Wissenschaftliches Forum auf derInternationalen Funkausstellung (IFA), Berlin, 28.08.1999.

• Grüneberg, L., Olbrich, S.: Virtuelle Informationen der Zukunft: das Projekt DFN-Expo. Presse-Sondervorführung „Erkenntnisse in der 3. Dimension“, RRZN/RVS, Universität Hannover,04.03.1998.

• Olbrich, S., Pralle, H.: 3D/VR-Technologie (Tele-Immersion) zur Präsentation wissenschaftlicherErgebnisse. Workshop „Visualisierung / Bildgebende Verfahren“, Universität Hannover,26.10.1999.

• Olbrich, S.: Hochwertige Online-Präsentation virtueller 3D-Exponate aus dem Wissenschaftsbe-reich – Anforderungen und Lösungsansätze. 5. Treffen des DFN-Arbeitskreises Informations-dienste, Hannover, 24.09.1997.

• Olbrich, S.: Präsentationstechnologien im Netz – (nicht nur) für die Wissenschaft. Vortrag und3D/VR-Demonstration auf der Presse-Sondervorführung „Erkenntnisse in der 3. Dimension“,RRZN/RVS, Universität Hannover, 04.03.1998.

• Olbrich, S.: Grundlagen der Virtuellen Realität. Vortrag und 3D/VR-Demonstration beim Tref-fen des NALWR (Niedersächsischer Arbeitskreis der Leiter der Wissenschaftlichen Rechenzent-ren), RRZN, Universität Hannover, 04.06.1998.

• Olbrich, S.: Multimedia und Virtuelle Realität im Netz – Technologie und Anwendungen. Vortragund 3D/VR-Demonstration im Rahmen eines Besuchs des BMBF im RRZN/RVS, UniversitätHannover, 11.12.1998.

• Olbrich, S.: DFN-Expo – Online 3D / Virtual-Reality-Werkzeuge und Techniken zur audio-visuel-len Präsentation in Netzen. Technisch-Wissenschaftliches Forum auf der Internationalen Funk-ausstellung (IFA), Berlin, 01.09.1999.

• Olbrich, S.: Verteilte Nutzung von 3D/VR-Streamingverfahren zur Präsentation und Diskussionkomplexer Ergebnisse. Workshop „Wissenschaftliche Anwendungen auf Höchstleistungsrech-nern“, RRZN, Universität Hannover, 29.09.1999.

• Olbrich, S.: Werkzeuge für die Präsentation wissenschaftlicher Ergebnisse in Multimedia- bzw.3D/Virtual-Reality-Informationssystemen. Forum Informationsdienste/News, 31. DFN-Betriebs-tagung, Johannesstift, Berlin, 06.10.1999.

• Sander-Beuermann, W.: Meta-Strukturen und -Algorithmen in Internet-Suchmaschinen. Work-shop des Arbeitskreises Metadaten der IuK-Initiative Information und Kommunikation der wis-senschaftlichen Fachgesellschaften in Deutschland, Bonn, 11.12.1998.(http://meta.rrzn.uni-hannover.de/meta-strukt/)

• Sander-Beuermann, W.: The Next Generation of Internet Searchengines. EUSIDIC Spring Mee-ting, Strassbourg, 10.3.1999.(http://meta.rrzn.uni-hannover.de/eusidic/)

• Sander-Beuermann, W.: Suchmaschinen – die nächsten Generationen. 29. DFN-Betriebstagung,Berlin, 6.9.1998. (http://meta.rrzn.uni-hannover.de/dfn-forum/)

• Sander-Beuermann, W.: Suchmaschinen im Internet – aktuelle Entwicklungen. DGD-Online-Tagung, Frankfurt, Mai 1998. (http://meta.rrzn.uni-hannover.de/dgd)

Rundfunkberichte

• „Deutsches Forschungsnetz zeigt neue, dreidimensionale Computerbilder“. Beiträge in zweiSendungen „Forschung aktuell“ im Deutschlandfunk vom 04.03.1998 und 07.03.1998.

3.5 DFN-Arbeitskreis 9


Präsentationen

• Messen:

– DFN-Stand auf der CeBIT 1997, Hannover.

– DFN-Stand auf der CeBIT 1998, Hannover.

– Internationale Funkausstellung (IFA) 1999, 28.08.–05.09.1999, Berlin.Technisch-Wissenschaftliches Forum, Stand des DFN (Halle 6.3, Stand 11):(a) DFN-Expo – Online 3D / Audio-/Video-Aufbereitung(b) DFNzine – Vom Heft zum multimedialen Online-Magazin

• Weitere:

– Presse-Sondervorführung „Erkenntnisse in der 3. Dimension“, Hannover, 04.03.1998.

– Tag der Forschung, Universität Hannover, Oktober 1997.

– Tag der Forschung, Universität Hannover, Oktober 1998.

– Einweihung des Landeswissenschaftsnetzes Nord (LWN), Hannover, 19.03.1999:Unterstützung der Videoübertragung, Erstellung eines Videoclips, Vorführung zur WWW-basierten verteilte Visualisierung mit den Werkzeugen der „DFN-Expo“, in Kooperation mit

dem Alfred-Wegener-Institut für Meeres- und Polarforschung (Bremerhaven)1.

– Demonstration in einer konferenzbegleitenden Ausstellung: Virtual Reality Movies – Real-Time Streaming of 3D Objects. TERENA-NORDUnet Networking Conference (TNNC)1999, Lund University, Schweden, 07.–10.06.1999.

– Etliche Demonstrationen im 3D-Präsentationsraum/Multimedia-Labor des RRZN/RVS.

3.5 DFN-Arbeitskreis

Ein Mitarbeiter des Projekts „DFN-Expo“ war während der Projektlaufzeit Sprecher des DFN-Arbeitskreises „Informationsdienste“. Dieser tagte in den Jahren 1997–1999 zu den folgendenSchwerpunktthemen:

• 29.01.1997 in Berlin: Metadaten (z. B. Dublin Core, PICS)

• 24.09.1997 in Hannover: 3D-Techniken (z. B. Wissenschaftliche Visualisierung,Leistungsfähige Online-Präsentation, Automatische Modellierung, VRML-Authoring)

• 11.02.1998 in Berlin: Datenbank-Integration im WWW

• 10.03.1999 in Berlin: Verteilte Virtual-Reality-Techniken (RUS, GMD)

3.6 Innovationspreis

Ein Mitarbeiter des Projekts „DFN-Expo“ erhielt am 14. Oktober 1999 für seine Entwicklungen zur„Leistungsfähigen Integration komplexer virtueller 3D-Szenen in Informationssystemen“ den Multi-media-Innovationspreis 1999 der Hannover-Region. Die Preisverleihung fand im Rahmen der Veran-staltung „Das 21. Jahrhundert – Neue Herausforderungen für die Arbeitswelt” der „ZukunftsfabrikKommunikation” im Technologie-Centrum Hannover (TCH) statt, an der ca. 420 Gäste aus Wirt-

schaft, Wissenschaft, Politik und Verwaltung teilnahmen2.

1. Siehe auch www.dfn-expo.de/lwn/2. Siehe auch www.zukunftsfabrik.hannover.de/4/4_5.html



3.7 Nutzung existierender Basisdienste und Software-ToolsEs wurden u. a. folgende Komponenten eingesetzt:

• Basisdienste– FTP-Client/Server– WWW-Clients: Netscape Navigator, Microsoft Explorer und Mosaic– WWW-Server: Apache-httpd

• Public-Domain-Software– Aladdin Ghostscript– ImageMagick– Netpbm-Tools– Independent JPEG Group‘s JPEG-Software– Sam Leffler‘s TIFF-Tools

• Kommerzielle Software– Adobe: Photoshop, Illustrator, Acrobat– ORACLE-Datenbank– QuarkXPress– Rogue Wave DBTOOLS.H++;

generische Datenbank-Klassenbibliothek, hier als Interface zu ORACLE– QT; generische User-Interface-Klassenbibliothek– Kinetix 3D Studio Max– Konverter für Audio-, Bild- und Video-Dateiformate

• RRZN/RVS-Entwicklungen– DocShow-VR– Multimedia-Konvertierdienste– ORACLE-Interface

4.1 3D/VR im World Wide Web 11


4 Ergebnisse des Projektes

4.1 3D/VR im World Wide Web

4.1.1 Motivation und AnforderungenAnwendungsfelder zur Nutzung von 3D/Virtual-Reality-Technologien – diese umfassen anwendungs-reife Methoden zur stereoskopischen Betrachtung und intuitiven 3D-Navigation und -Interaktion –können wie folgt eingeteilt werden:

• Informationsräume / 3D-Nutzeroberflächen– z. B. Navigation in räumlichen Informationsdarstellungen, 3D-Interaktion

• Geometrische Visualisierung (Modellierung / Rekonstruktion)– z. B. Virtual Design, Architektur- und Landschaftsplanung

• Wissenschaftliche Datenvisualisierung– Exploration und Demonstration von Simulations- oder Mess-Ergebnisdaten.

Bereits mit den ersten beiden Klassen sind außerordentliche Herausforderungen verbunden, die jenach Anwendungsfall leistungsstarke Rechner und Spezialperipherie erfordern, in denen insbesonderehohe Renderingleistung und hochqualitative Displaygeräte erforderlich sind. Im Kontext des „HighPerformance Computing“ (HPC) gewinnt jedoch die 3D-Visualisierung mit Unterstützung durchMethoden der Virtuellen Realität eine besondere Bedeutung, da die Komplexität der Ergebnisdatenhäufig so hoch ist, dass nur durch adäquate visuelle Aufbereitung ein – insbesondere interdisziplinäres– Verständnis der Ergebnisse ermöglicht werden kann.

Die verschiedenen am Markt erhältlichen Visualisierungssysteme beinhalten generell Viewer zur drei-dimensionalen Betrachtung. Nutzeroberflächen, Funktionalität sowie unterstützte Plattformen undGeräte (z. B. stereoskopische Displays, Tracking) unterscheiden sich jedoch je nach verwendetemWerkzeug erheblich. Eine homogenere Nutzbarkeit der 3D-Technologie – besonders auch im Internet– ließ die Entwicklung eines Standardformats zum Austausch von polygonalen 3D-Modellen erwar-ten: Virtual Reality Modeling Language (VRML97) gemäß ISO/IEC 14772 [16]. Allerdings weisenVRML-Viewer derzeit verschiedene Unzulänglichkeiten auf, die Performance, Darstellungsqualitätund Funktionalitäten betreffen. Besonders zu nennen sind wesentlich zu hohe Startup-Zeiten, meistnicht unterstützte Stereo-Displays sowie fehlende Streamingfähigkeit, d. h. Funktionen zum Abspie-len von 3D-Szenensequenzen, in denen während der ablaufenden Animation frei – in Raum und Zeit-achse – navigiert werden kann [30].

4.1.2 EntwicklungsschritteUnter Berücksichtigung wesentlicher Gesichtspunkte zur Systemauslegung sowie existierender Stan-dards waren für das Systemdesign einige Entscheidungen zu treffen, die aufgrund der in den aufge-stellten Forderungen vorliegenden Gegenläufigkeiten unter Umständen Kompromisse auf der Basisvon sorgfältigen Abwägungen darstellten. Die durchgeführten Entwicklungen basieren auf demZusammenspiel von Komponenten, Protokollen, Dienste und Formaten. Damit sollten für den Nutzerdes WWW-Clienten leistungsmäßige, qualitative und funktionale Verbesserungen bei der Online-Prä-sentation virtueller 3D-Objekte auf der Basis geometrischer Beschreibungen erzielt werden.

4.1.2.1 Leistungsfähige Online-Präsentation statischer 3D-Szenen

Anhand der Abb. 2 bis Abb. 4 sollen die vollzogenen Entwicklungsschritte zur Hochleistungs-Online-Präsentation von statischen 3D-Szenen veranschaulicht werden:

1. Ursprünglich stellten VR-Systeme Standalone-Systeme dar. Die jeweils zu bearbeitenden Szena-rien – bestehend aus den geometrie-orientierten 3D-Modelldaten sowie entsprechende Methoden– wurden zunächst aus einem Dateisystem eingelesen. Nach einer Startup-Phase, die wegen deraufwendigen Vorbereitungsschritte – z. B. Parsen, Aufbau eines Szenengraphen – relativ langedauern konnte, wurde letztlich auf der Basis von im Speicher liegenden, optimierten Datenstruk-turen gearbeitet (Abb. 2).

12 4 Ergebnisse des Projektes


2. Nachdem Kommunikationsaspekte – z. B. Multimedia-/Virtual-Reality-Daten auf verteilten Ser-vern, Zugriff von verteilten Client-Systemen, kooperative Nutzungsformen – eine zunehmendeRolle spielten, wurden derartige Systeme für die Anwendung im WWW-Kontext angepasst.Nach der Standardisierung eines dafür zu verwendenden Dateiformats „VRML“ konnte eingemäß Abb. 2 realisiertes Viewer-System somit unmittelbar als „Helper Application“ konfigu-riert und aufgerufen werden. Um auch WWW-Links zu unterstützen, die von Teilen einer 3D-Szenen ausgehen, wurden entsprechende VRML-Sprachelemente (WWWAnchor) zur Aktivierungweiterer WWW-Dokumente genutzt. Externe VRML-Viewer rufen dazu üblicherweise denWWW-Browser mit einer speziellen Option auf, die ihn veranlasst, die gewünschte URL zuladen (Abb. 3). Beispielsweise arbeitet der VRML-1.0-Viewer Webspace der Firma Silicon Gra-phics nach diesem Verfahren.

3. Eine engere Integration des Viewers in den WWW-Browser wurde durch die Plugin-Architekturermöglicht, die von der Firma Netscape für alle signifikanten Plattformen spezifiziert wurde[26][27] und auch vom Microsoft-Browser Internet Explorer unterstützt wird. Die gebräuchli-chen VRML-Viewer, wie z. B. CosmoPlayer, liegen heute üblicherweise als Plugin-Softwarevor. Die potenziellen Leistungsengpässe, die durch Programmaufrufe sowie durch Schreiben undLesen von Zwischendateien entstehen, werden hier dadurch vermieden, dass die Plugin-Soft-ware als Shared Library zur Laufzeit Bestandteil des Browser-Prozesses wird und mittels Call-back-Routinen bidirektionale Schnittstellen bereitgestellt werden. Für die im Rahmen dieserArbeit durchgeführte Viewer-Implementierung wurde daher diese Architektur ausgewählt(Abb. 4). Darüber hinaus wurde ein neues Dateiformat, genannt „DVR“, definiert, um die auf-wendigen Vorverarbeitungsschritte („Parse“, „High-Level-Traverse“, „Optimize“ in Abb. 3) zuumgehen. Das DVR-Format ist prinzipiell auf dem Niveau der „Low-Level-Display-List“ inAbb. 3 angesiedelt, d. h. die 3D-Rendering-Routinen (hier: OpenGL) können unmittelbar aufdiese Datenstrukturen zugreifen.

ParseHigh-Level-

Traverse /

Optimize

Low-Level-

Traverse

Select Render

Repräsentation

auf Datei

Szenen-Graph

im Speicher

Display-List

im Speicher

Präsentation

Interaktion

3D-Geom.

2D-PixelAuswahl-Aktion, z. B.

Zugriff auf neue Szene

Tracking

Navigation

Auswahl

Abb. 2. Standalone-VR-System – Lokale Arbeitsweise

ParseHigh-Level-

Traverse /

Optimize

Low-Level-

Traverse

Select Render

Szenen-Graph

im Speicher

Display-List

im Speicher

Präsentation

Interaktion

3D-Geom.

2D-Pixel

get URL

Tracking

Navigation

AuswahlWWW-

Browser

WWW-

Server

Repräsentation

auf Datei

Repräsentation

auf Datei

HTTP

VRML

exec

Kopie

Externer Viewer (VRML)Client

Abb. 3. Externer VRML-Viewer – „Helper Application“ für WWW-Browserim verteilten System: Zugriff auf entfernte Dokumente



4.1.2.2 Eine Architektur zur Ausspielung von 3D-Szenensequenzen

Durch die Plugin-Architektur sowie die auf Effizienz ausgelegte Spezifikation des DVR-Formats undImplementierung des DVR-Viewers konnten die Updates von Szenen der geforderten Komplexität inrelativ kurzer Zeit durchgeführt werden, d. h. in der Größenordnung von einer Sekunde. Dadurchwurde die Realisierung eines Streamingverfahrens ermöglicht, welches die Ausspielung von Szenen-Sequenzen ermöglicht, die, vergleichbar mit Audio-/Video-Streaming (z. B. RealMedia), auf einemseparaten Streaming-Server bereitgestellt werden. Während der Abspielung eines solchen „3D-Films“kann sich der Nutzer weiterhin frei in der virtuellen 3D-Szene bewegen, d. h. mittels Tracking- oder3D-Interaktionsgerät kann interaktiv navigiert werden.

Da es bislang keinen flexiblen Mechanismus zur Erweiterung von WWW-Browsern um neue Proto-kolle gibt, wird dabei zunächst über HTTP ein kleiner Metadatensatz, genannt „DVRS“, geladen, deraufgrund einer separaten MIME-Kennzeichnung eine spezielle Plugin-Variante aktiviert. Die DVRS-Daten enthalten z. B. die Referenz auf die eigentlichen 3D-Daten, wodurch letztlich ein im DVRS-Plugin enthaltener Streaming-Client initiiert wird (Abb. 5). Dieser kommuniziert direkt mit dem Strea-ming-Server, wobei als Steuerprotokoll RTSP (Real Time Streaming Protocol, RFC 2326 [44]) und als3D-Datentransportprotokoll das DVR-Format mit eingefügten Szenen-Trenndatenelementen (genannt„DVRP“), beide über TCP/IP, verwendet werden.

Der in Abb. 5 dargestellte Ablauf ist durch die folgenden Schritte gekennzeichnet:

1. Der WWW-Client liest ein DVRS-Objekt (MIME-Typ: application/x-docshow-vrs,Datei-Endung: .dvrs) über HTTP ein. Dieses wurde vom Browser z. B. durch ein EMBED-Tagangefordert, das in einer HTML-Webseite eingebettet war.

Low-Level-

Traverse

Select Render Präsentation

Interaktion

3D-Geom.

2D-Pixel

NPN_GetURL

Tracking

Navigation

AuswahlWWW-

Browser

WWW-

Server

Repräsentation

auf Datei

HTTP

DVR

Plugin (DVR)

NPP_WriteDisplay-List

Memory-

Buffer

Client

Abb. 4. Inline-Plugin für das DVR-Format – integriert in WWW-Browser

Low-Level-

Traverse

Select Render Präsentation

Interaktion

3D-Geom.

2D

-Pix

el

NPN_GetURL

Tracking

Navigation

Auswahl

Stream-Steuerung

WWW-

Browser

WWW-

Server

Metadaten

HTTP

DVRS

Plugin (DVRS)

NPP_Write

Display-List

Memory-

Double-Buffer

Streaming-

ClientStreaming-

Server

3D-Daten

RTSP über TCP/IP

DVR

Commands:

Play, Stop, Goto, Slow Motion

1

2

DVRP über TCP/IP

3

4

Client

Abb. 5. Inline-Plugin für das DVRS-Format – 3D-Streaming-System



2. Nachdem das dazu passende DVRS-Plugin (Erweiterung des DVR-Plugins, siehe auchAbschn. 4.1.3.2) in den WWW-Browser geladen wurde, baut dieses eine Verbindung zum 3D-Streaming-Server auf. Die dazu erforderlichen Startup-Informationen sind im DVRS-Datensatzspezifiziert, der dem Plugin im Callback NPP_Write() bereitgestellt wird. Zu den darin gespei-cherten Metadaten gehören:

– Referenz auf den 3D-Streaming-Server(Protokoll, IP-Adresse, Port-Nummer),

– Ort der 3D-Daten (Pfad, Namens-Template) und– Darstellungsattribute (z. B. Frame-Rate, Level of Detail).

3. Der 3D-Streaming-Server (siehe Abschn. 4.1.3.3) liest die 3D-Szenen aus Dateien im DVR-For-mat (siehe Abschn. 4.1.3.1) und liefert diese an den Client aus, wobei jeweils noch Szenen-End-markierungen eingefügt werden. Der Client liest diese in einen Wechsel-Puffer ein, umasynchron die folgenden Aktivitäten zu ermöglichen:

4. Rendering, Navigation, Auswahl und Stream-Steuerung:– Rendering:

Sowohl durch das Eintreffen einer Szenen-Endmarkierung als auch durch Änderung der vir-tuellen Kameraperspektive wird eine Aktualisierung der Display-Ausgabe aktiviert.

– Navigation:Entsprechend der Steuerung durch die Eingabegeräte, wie z. B. Maus, SpaceBall oderHeadtrackingsystem, werden die Parameter der virtuellen Kamera modifiziert: Position,Orientierung und Blickwinkel. Kamerafahrten können als „Views“ bzw. „Cameras“ inVRML- bzw. DVR-Dateien auch vordefiniert werden, um dann wahlweise automatischabzulaufen.

– Auswahl:Eine Aktivierung von Hyperlinks in 3D-Szenen ist durch Anklicken der entsprechend attri-butierten Objekte im „Pick“-Modus des Plugins bzw. durch „Doppelklick“ möglich. Liefertdie „Select“-Traversierung eine URL, so wird diese vom WWW-Browser mittelsNPN_GetURL() angefordert.

– Stream-Steuerung:Befehle, die die Streamingsteuerung betreffen, können vom Benutzer über einen fensterori-entierten Dialog, ähnlich der Wiedergabesteuerung eines Videorecorders, gegeben werden.Dazu gehören: Anhalten, Positionierung, Ausspielung mit geänderter Framerate, Wahleines alternativen Streams mit reduzierter Komplexität. Die Steuerung erfolgt über dasRTSP-Protokoll.

Üblicherweise

verwendeter

squid

webfilt

wrltoDVR

squid

WWW-Clientz. B. Netscape,

PAC

Beliebige

WWW-Server

HTTP HTTP

Konvertierender

Proxy-Cache-Server

HTTP

DVR

HTT

PD

VR Konfiguration

einer URL-

abhängigen

Proxy-Auswahl

HTTP

VR

ML

URL endet .wrl

URL endet nicht .wrl

Cache

Cache

DVR

VRML

Abb. 6. Konvertierende Proxy-Cache-Server-Konfiguration



4.1.2.3 Interoperabilität mit VRML-Generatoren

Um eine Kompatibilität zum VRML-Standard zu erzielen, wurden mehrere Mechanismen vorgeschla-gen und realisiert [29]:

1. Eine Konvertierung mittels batchorientiertem Kommandozeilen-Programm (Abschn. 4.1.3.1).

2. Ein interaktiver Online-Konvertierdienst über eine Webseite mittels Upload einer VRML-Dateiüber ein WWW-Formular [24], Konvertierung in einem CGI-Programm auf einem WWW-Ser-ver und Auslieferung der Ergebnisdatei über HTTP; dabei erfolgt wahlweise eine Abspeicherungin Datei oder die direkte Anzeige im Plugin.

3. Ein transparenter Konvertiervorgang (siehe Abb. 6, S. 14), der als konvertierender Caching-Proxy realisiert ist und dazu die Proxy-Cache-Software squid, einen konfigurierbaren HTTP-Fil-ter – webfilt [55] – sowie die oben genannten Konvertierprogramme anwendet. In einer Mach-barkeitsstudie wurde auf Client-Seite in der „Proxy Automatic Configuration“ (PAC), einerflexiblen Spezifikation der zu nutzenden Proxy-Server, festgelegt, dass mit .wrl endende URLsüber einen speziellen Konvertier-Proxy verarbeitet werden. Dieser holt die gewünschte VRML-Datei auf übliche Weise aus dem WWW, konvertiert sie jedoch in das DVR-Format und liefertdiese dem Client mit dem passenden MIME-Type, so dass das 3D-Modell letztlich im DVR-Plu-gin angezeigt wird. Beim zweiten Abruf dieser URL kann die DVR-Datei direkt aus dem Cacheausgeliefert werden.Aus dieser Vorgehensweise ließe sich prinzipiell ein generelles Konzept für universelle Multime-dia-Konvertierungsdienste entwickeln, welches zur Realisierung automatisiert ablaufenderAbleitungsketten dienen könnte. Dieses wäre dann z. B. auch direkt auf WWW-Serverseite ein-setzbar.

4.1.3 Implementierung

Aus den vorgenannten Gründen wurden ein eigenes Format (DVR) einschließlich Generierungssoft-ware, ein leistungsfähiger Viewer (DocShow-VR) sowie ein Streamingserver (und zugehöriges Meta-datenformat DVRS) entwickelt. Die gestellten Anforderungen führten, unter Berücksichtigungrelevanter Standards, zu einer adäquat ausgelegten, prototypischen Implementierung dieser Kompo-nenten.

4.1.3.1 Einlesen von VRML, Vorverarbeitung, Aufbau und Generierung des 3D-Formats „DVR“

Es wurden zwei Programme implementiert, die VRML-Dateien der beiden derzeit relevanten VRML-Standards in das eigene DVR-Format konvertieren:

• wrl1toDVR konvertiert VRML-1.0-Dateien in DVR-Dateien,• wrl2toDVR konvertiert VRML97-Dateien in DVR-Dateien.

Die Ausgangsbasis für die Implementierung des Konverters bildeten zunächst die frei verfügbare C++-Klassenbibliothek QvLib [53] zum Parsen von VRML 1.0 [2], ein OpenGL-Programmfragment zumTraversieren und Rendern auf Basis von QvLib aus einer Email von Jan Hardenberg [12] und Informa-tionen aus den Quellen des frei verfügbaren read_vrml-Moduls für die Visualisierungssoftware AVS.

Inzwischen wurde VRML 2.0 als ISO-Standard VRML97 [16] verabschiedet. Das hat dazu geführt,dass sich die Export-Möglichkeiten verschiedener Generierungswerkzeuge von VRML 1.0 nach 2.0entwickelt haben und in neueren Versionen zum Teil keine Option für das VRML-1.0-Format mehrbesteht.

Beispielhaft sind die folgenden Werkzeuge zu nennen:

• 3D-Modelliersoftware: CosmoWorlds• Visualisierungssoftware: Ensight, VTK (Visualization Toolkit) [42]

Daher wurde eine Lösung erarbeitet, die eine Konvertierung aus dem VRML-2.0-Dateiformat gestat-tet. Eine Marktübersicht ergab, dass mehrere Toolkits angeboten werden, die zur offenen Unterstüt-zung des Parsens von VRML-2.0-Dateien sowie zum Aufbau von Szenengraphen dienen können. ZurStabilität, Effizienz und strategischen Bedeutung der Produkte waren allerdings nur wenige Informati-onen verfügbar. Zum Teil handelte es sich um noch in Entwicklung befindliche Werkzeuge, bei denen



auch die Abschätzung von Terminen zur Fertigstellung wesentlicher Funktionalitäten zu Schwierig-keiten führen könnte. Daher wurde die von der Firma TGS angebotene und um VRML-2.0-Ein- undAusgabe-Funktionen erweiterte Standard-Graphikbibliothek OpenInventor 2.5 zunächst als befristeteDemoversion getestet. Nachdem die Machbarkeit auf dieser Basis gezeigt war, wurden Entwicklungs-lizenzen für SGI Irix und Microsoft Windows 95/NT beschafft und installiert. Durch den Einsatz die-ses Standardprodukts war es auch möglich, anderweitig vorliegende Hilfsbibliotheken, z. B. zurBerechnung von Normalenvektoren, auf relativ einfache Weise in den Konvertierprozess einzubinden.

Ein besonderes Problem stellte sich allerdings dadurch heraus, dass in den „Viewpoints“ (in VRML1.0: PerspectiveCamera) keine focalDistance spezifiziert wird. Diese Angabe ist jedoch erfor-derlich, um eine korrekte stereoskopische Darstellung zu produzieren und einen Anhaltspunkt für dieNear- und Far-Clipping-Ebenen zu bieten (siehe auch Abschn. 4.1.3.2). Daher wurde diese Angabe alsweitere Kommandozeilen-Option vorgesehen. Auf die Berechnung eines Schätzwertes wurde verzich-tet.

Zusätzlich wurde eine Option zum Aufsplitten von Teilszenen implementiert, die in einer „Switch“-Gruppe angeordnet sind. Dies war erforderlich, um die Visualisierung zeitabhängiger Phänomene mitHilfe der Visualisierungssoftware Ensight zu unterstützen. Hier werden die Ergebnisse sämtlicherZeitschritte in einer VRML-Datei abgelegt, die üblicherweise in einem VRML-Browser nacheinander„durchgeklickt“ werden können. Der im Rahmen dieses Projekts realisierte Streaming-Mechanismus,dem Sequenzen von einzelnen Szenen im DVR-Format zugrunde liegen, stellt eine bessere Lösung desProblems der Präsentation von Zeitserien dar.

Aufbau des DVR-Formats

Das DVR-Format wurde anhand folgender Gesichtspunkte entworfen:

Decodierung mit geringstmöglichem Rechenaufwand und Bereitstellung für Immediate-Mode-OpenGL-Rendering

Das DVR-Format verwendet zur Zahlendarstellung das Binärformat gemäß IEEE 754 in Network-Byte-Ordering, d. h. entsprechend der rechnerinternen Zahlendarstellung der meisten UNIX-basier-ten Arbeitsplatzrechner. Ausnahmen sind Intel- und DEC-CPUs, auf welchen die Client-Softwareeinmal nach der Übertragung eine Konvertierung durchführen muss. Dies wird durch das imSocket-API zur Netzwerkprogrammierung enthaltene Makro ntohl() erledigt, das auf 32-Bit-Integer- und – obwohl eher unüblich und nicht allgemein bekannt – auch auf -Float-Werte im 32-Bit-IEEE-Format angewandt werden kann. Exotischere Zahlendarstellungen sind inzwischen, wennüberhaupt, nur noch auf speziellen Hochleistungsrechnern anzutreffen, die aber als Client-Plattformhier ohnehin nicht in Frage kommen.

In VRML-Teilobjekten ohne explizite Normalenvektor-Spezifikationen werden bereits bei der Kon-vertierung die Normalenvektoren berechnet und abgespeichert. Besonders für geglättet darzustel-lende große polygonale Netze, in denen über die Spezifikation eines Grenzwinkels (VRML:creaseAngle) differenziert wird, ob über eine Kante zu interpolieren ist, können so erheblicheRechenaufwände auf Client-Seite vermieden werden, wenn diese Vorberechnung auf Server-Seitebereits erfolgt ist.

Kürzestmöglicher StartupEs werden direkte Koordinaten- und Attribut-Werte (im Gegensatz zu den indizierten Werten inVRML) in den DVR-Records verwendet, um unmittelbar mit dem Rendern beginnen zu können.

Unterstützung effizienten Renderings in OpenGL, d. h. Verwendung von Triangle-Strip- und Triangle-neben den allgemeineren Polygon-Primitiven

In einem Vorverarbeitungsschritt werden die im VRML-Format vorliegenden aufeinander folgen-den unabhängigen Polygone (IndexedFaceSet) analysiert, Dreiecke miteinander verglichen undgegebenenfalls in die Triangle-Strip- oder Triangle-Primitive des DVR-Formats umgewandelt.

Optimierung der OpenGL-StatuswechselBei der DVR-Generierung werden nur die notwendigen Statusänderungen (z. B. Materialeigen-schaften, Transformationen) in entsprechenden Records ausgegeben.



Eine DVR-Datei besteht aus einer Sequenz von PDUs (Protocol Data Unit), die jeweils aus einen Hea-der mit fester Länge (64 bit) und einem Datensatz variabler Länge (Vielfaches von 32 bit) bestehen(siehe auch Abb. 7).

Die Bedeutung der Felder in den DVR-PDUs ist wie folgt (siehe auch Tabelle 1):

1. Type (8 bit) – Funktion der PDU

– Generator-Informationen („Header“: Version, Datum, Uhrzeit)– Graphik-Elemente („AsciiText“, „Cone“, „Cube“, „Cylinder“, „FaceSet“, „LineSet“,

„PointSet“, „Sphere“)– Graphik-Attribute („Material“)– Text-Elemente („Info“: für AsciiText, Hyperlinks, Textur-URLs, Kameraname)– Transformationen („ProjectionMatrix“, „Texture2“, „Texture2Matrix“)– Virtuelle Kameras („Camera“)– Virtuelle Lichtquellen („Light“, „MaxLight“)– Steuerung („End“)

2. Topology (8 bit) – zur Unterscheidung verschiedener Topologie-Klassen in den Graphikele-mente-PDUs FaceSet, LineSet und PointSet bzw. diverse Parameter in anderen PDUs.

3. Bindings (8 bit) – zur Spezifikation der im Graphikelement-Datensatz optional enthaltenen Attri-bute: Normalenvektoren, Farben, Texturkoordinaten, jeweils unterschieden nach

– globaler Attributierung: 0– Attributspezifikation je Eckpunkt: 1– Attributspezifikation je Polygon: 2– Zusätzlich wird unterschieden, welche Materialeigenschaft durch die Farbspezifikation

beeinflusst werden soll:– Emissive = 0: diffuseColor– Emissive = 1: emissiveColor

4. Flags (8 bit) – für weitere PDU-spezifische Optionen, z. B.– Bit 7 = 1: Byte-Ordering des Datensatzes ist nicht systemspezifisch (Text),

Bit 7 = 0: Datensatz enthält 32-bit-Wörter, die gegebenenfallsvor der ersten Benutzung mit ntohl() konvertiert werden müssen.

5. Length (32 bit) – Länge des an den Header folgenden Datensatzes, in Network-Byte-Order.

6. Data (8 x Length bit) – Parameter des jeweiligen Elements, abhängig von der Spezifikation imHeader, ergänzt auf ganzzahliges Vielfaches einer Länge von 32 bit.

Abb. 7. Aufbau einer PDU im DVR-Format

Type Topology Bindings Flags Length8 bit 8 bit 8 bit 8 bit 32 bit

Header64 bit

Data8 x Length bit (ganzzahlige Vielfache von 32 bit)

Normals Colors TextureCoord Emissive2 bit 2 bit 2 bit 2 bit



Zur Illustration sind in Abb. 8 und Tabelle 2 VRML- und DVR-Formate am Beispiel eines Triangle-Strips gegenübergestellt.

Type Bedeutung Topology Inhalt des Data-Feldes

0 Header „D“ 2 int-Werte: version=2, timestamp

1 ASCII-Text –float- und int-Werte: spacing, justification, width, size, family, style

2 Conebit 0: Sides

2 floats: bottomRadius, heightbit 1: Bottom

3 Cube – 3 floats: width, height, depth

4 Cylinder

bit 0: Sides

2 floats: radius, heightbit 1: Top

bit 2: Bottom

5 FaceSet

1: polygon

Koordinaten, Normalen,Farben (optional),Texturkoordinaten (optional)

2: triangles

3: triangle strip

4: quad

5: quad strip

6 LineSet ähnlich FaceSet

7 PointSet ähnlich FaceSet

8 Sphere – Radius; optional: n Mittelpunkte

9 Info

0: Attribute 2 strings, z.B. „BackgroundColor\01 1 1“

1: CameraName

string2: TextString

3: TextureURL

4: AnchorURL

10 Material –17 float-Werte:ambientColor, diffuseColor, specularColor,emissiveColor, shininess

11 ProjectionMatrix – 4x4 matrix (16 floats)

12 Texture2 – –

13 Texture2Matrix – 3x3 matrix (9 floats)

14

bindings=0:OrthogonalCamera

bindings=1:PerspectiveCamera

number9 float-Werte:position (3), orientation (4),focalDistance (1), heightAngle (1)

15 Light

1: directional 18 float-Werte:diffuse (4), specular (4), position (4),spotDirection (4), linearAttenuation (1),spotCutoff (1)

2: point

3: spot

16 MaxLight number –

17 End of Scene – –

Tabelle 1. PDU-Typen im DVR-Format



Generierung des DVR-Formats

Als Programmierschnittstelle zur Generierung von DVR-Dateien oder -Datenströmen wurde in C++eine Klassenbibliothek „OutputDVR“ entwickelt. Diese dient in den Konvertierwerkzeugenwrl1toDVR und wrl2toDVR zur DVR-Ausgabe. Darüber hinaus können hiermit auch direkt DVR-PDUs erzeugt werden; z. B. wurde auf dieser Basis zum Visualization Toolkit (VTK) eine KlassevtkDVRExporter, in Anlehnung an die bereits vorhandene vtkVRMLExporter-Klasse, hinzugefügt.

4.1.3.2 Ein Hochleistungs-Plugin als DVR-Viewer: „DocShow-VR“

Zur Plugin-Implementierung dienten zunächst einfache Beispiel-Plugins aus dem Plugin-Develop-mentkit von Netscape [26]. Für das 3D-Rendering wurde die Industriestandard-3D-Graphikprogram-mierschnittstelle OpenGL [25] verwendet, da diese für sämtliche Plattformen verfügbar ist. Vorteile inder Verwendung höherer Schnittstellen wie OpenInventor, Performer oder Optimizer, die auf Szenen-graphen basieren, waren nicht erkennbar, weil Szenengraphen nicht benötigt wurden. Außerdem wer-den diese APIs nur auf besonderen Plattformen unterstützt. Als OpenGL-Ersatz wurde die freierhältliche Mesa-Library [36] auf Plattformen verwendet, auf denen keine OpenGL-Laufzeitumge-bung installiert ist. Zur Vereinfachung des Installationsvorgangs wurden diese speziellen Plugin-Versi-onen mit der Mesa-Bibliothek statisch gelinkt. Die GUI-Module, die zur Realisierung von Popup-Menüs, Dialogen und zum Eventhandling (Timer,Maus, Windows) dienen, wurden plattformabhängig implementiert. Um weitere Software-Installationund Lizenzierung zu umgehen und eine schlankere Realisierung zu ermöglichen, wurden zwei Varian-ten entwickelt: unter UNIX wurde auf X-Windows (Xlib) und OSF/Motif [35] aufgesetzt und dieOpenGL-Integration über die GLX-Bibliothek vorgenommen, für Microsoft Windows 95/98/NT wur-den die Win32- und WGL-Bibliotheken verwendet (Abb. 9).

Lfd.Nr.

HeaderData

Type Topology Bindings Flags Length

1 0 „D“ „V“ „R“ 8 2, timestamp

2 9 1 0 0x80 8 „Default“ (Kamera-Name)

3 14 1 1 0 36 0.0, 0.0, 3.0, 0.0, 0.0, 1.0, 0.0, 3.0,

4 5 3 1 0 120

0.0, 0.0, 1.0, -1.0, 0.95, 0.0,0.0, 0.0, 1.0, -0.5, -1.0, 0.0,0.0, 0.0, 1.0, 0.0, 1.0, 0.0,0.0, 0.0, 1.0, 0.5, -1.2, 0.0,0.0, 0.0, 1.0, 1.0, 1.1, 0.0

Tabelle 2. DVR-Format eines „Triangle-Strips“, generiert aus VRML (siehe Abb. 8)

#VRML V1.0 ascii

DEF Default PerspectiveCamera { position 0 0 3 focalDistance 3}

NormalBinding { value PER_VERTEX }

Coordinate3 { point [ -1 0.95 0, -0.5 -1 0, 0 1 0,

0.5 -1.2 0, 1 1.1 0 ]}Normal {vector [ 0 0 1, 0 0 1, 0 0 1, 0 0 1,

0 0 1 ]}IndexedFaceSet { coordIndex [ 0, 1, 2, -1, 2, 1, 3, -1,

2, 3, 4, -1 ]}

(a) Dateiformat: VRML 1.0

#VRML V2.0 utf8

DEF Default Viewpoint { position 0 0 3}

Shape { geometry IndexedFaceSet { coord Coordinate { point [ -1 0.95 0, -0.5 -1 0,

0 1 0, 0.5 -1.2 0, 1 1.1 0 ] } normal Normal { vector [0 0 1, 0 0 1, 0 0 1,

0 0 1, 0 0 1 ] } coordIndex [ 0, 1, 2, -1, 2, 1, 3, -1,

2, 3, 4, -1 ] }}

(b) Dateiformat: VRML 97

Abb. 8. VRML-1.0- und VRML-97-Dateien eines „Triangle-Strips“, bestehend ausdrei zusammenhängenden Dreiecken mit Normalenspezifikation je Eckpunkt

π 4⁄



Schleifenoptimierung

Um den CPU-Engpass durch die rechenaufwendigen, ständig wiederkehrenden Abfragen im Schlei-fenkern beim Rendering attributierter Dreieckssequenzen mit OpenGL zu reduzieren, wurden diegrundsätzlich möglichen Fälle klassifiziert und für die daraus resultierenden Klassen separate Funktio-nen implementiert. Da die Nummer der entsprechenden Fallgruppe im DVR-Recordheader codiert ist,kann der Renderingprozess die jeweils passende Routine direkt ausführen. Die einzelnen Routinenwurden z. T. handoptimiert, z. B. durch Loop-Unrolling sowie optionale Verwendung optimierter Ren-dering-Primitive (glVertexArray() in OpenGL 1.1 bzw. glVertexArrayEXT() als OpenGL-1.0-Extension, z. B. in SGI Irix).

Colormanagement

Colormanagement [9] wurde integriert, um die Wiedergabe-Qualität von Bildern zu erhöhen, die alsTextur auf Komponenten der 3D-Szene gemappt werden. Bilder, die im RGB- oder CMYK-Farbmo-dell als TIFF-Format [1] vorliegen, werden mit der im Quelltext frei verfügbaren C-Bibliothek „SamLeffler’s TIFF Library“ (ftp://ftp.sgi.com/graphics/) decodiert. Diese wurde modifiziert, umdie im TIFF-Format gegebenenfalls eingebetteten ICC-konformen Quell-Farbprofil-Informationensowie ein konfigurierbares, monitor-spezifisches ICC-Zielprofil in die Farbraum-Konvertierung einzu-beziehen. Die Implementierung erfolgte für SGI Irix 6.5, Sun Solaris und Microsoft Windows 98,indem die verschiedenen – da nicht standardisierten – APIs der auf der jeweilige Plattform verfügba-ren Colormanagement-Systeme (CMS) Coloratura [46], KCMS [54] bzw. ICM 2.0 [22] angewandtwurden. Ältere Microsoft-Betriebssysteme, dazu zählen Windows 95 und Windows NT 4.0, konntenhier nicht berücksichtigt werden, da der Funktionsumfang der darin enthaltenen ICM-Version 1.0 nichtausreichte [21].

Die verwendeten CMS-Funktionen sind in Tabelle 3 aufgeführt. Auf diesen Plattformen unterstütztdas Plugin auch die farbkorrigierte, direkte Betrachtung von Bildern im TIFF-Format (MIME-Typ:image/tiff oder image/x-tiff, Datei-Endung: .tif) im WWW-Browser.

Microsoft Windows 98ICM 2.0

SGI Irix 6.5Coloratura

Sun SolarisKCMS

Initialization – cmsOpen KcsAvailable

Open Profile OpenColorProfile cmsImportProfile KcsLoadProfile

Close Profile CloseColorProfile cmsCloseProfile KcsFreeProfile

Get Tag Value GetColorProfileElement cmsGetTag KcsGetAttribute

Create Color Transformation

CreateMultiProfile-Transform

cmsCreateTfm KcsConnectProfiles

Transform Colors

TranslateBitmapBits cmsApplyTfm KcsEvaluate

Tabelle 3. CMS-Funktionen in den APIs der verschiedenen Betriebssysteme

Abb. 9. Aufruf-Hierarchie von OpenGL-Anwendungen unter UNIX und Microsoft WindowsGLU: OpenGL Utility Library (z. B. High-Level-Primitive, NURBS),GDU: Graphics Device Utility Library (Win32).(Quelle: http://www.opengl.org/About/Architecture.html)



3D-Text

Zur Bereitstellung von perspektivisch innerhalb von 3D-Szenen darstellbaren Text-Elementen sindPixelfonts und Strichgraphiken (z. B. Hershey-Fonts) aus qualitativen Gründen ungeeignet. Skalier-bare Schriften werden derzeit als Outline-Fonts in verschiedenen Formaten angeboten, die z. B. vonden Firmen Adobe (Type1) und Microsoft (TrueType [23]) spezifiziert wurden. Eine frei erhältlicheFont-Triangulierungssoftware (Font3D Version 1.1 von Todd A. Prater) wurde weiterentwickelt, ummehrere TrueType-Fonts in Dreieckslisten zu konvertieren. Diese wurden zwecks effizienter Einbin-dungsmöglichkeit in Form von C-Quelltexten erzeugt.

Räumliche Navigation und Selektion

Auf der Basis von Quaternionen, die Rotationen mathematisch beschreiben und mit der Maus mittels„Virtual Trackball“-Bedienparadigma gesteuert werden können, ist es möglich, sowohl relativ zur vir-tuellen Kamera als auch relativ zum Objekt intuitiv zu navigieren (siehe auch [11][17]). Neben dem„Rotate Object“-Navigationsmodus wird ein „Rotate Camera“-Navigationsmodus mit separaten Qua-ternionen unterstützt. Die „Translate XY“- und „Translate Z“-Modi dienen der Verschiebung in denBildschirmachsen bzw. senkrecht dazu. Eine „Walk“-Navigation ermöglicht eine intuitive automati-sche Vor- bzw. Rückwärtsbewegung jeweils in Richtung der Kamera-Orientierung. Über die Bewe-gung der Maus, bei gedrückter linker Maustaste, werden dabei Beschleunigung (Mausbewegung inVertikalrichtung) und Richtung (Horizontalrichtung) bestimmt.

Darüber hinaus wurde eine Methode implementiert, die dazu dient, die Objekt- bzw. Kamera-Rotationauch nach dem Loslassen der Maustaste weiterzuführen. Damit lassen sich z. B. Objekte in eine Dre-hung versetzen, indem der Nutzer diese „in Schwung“ bringt. Als Kriterium wird der zeitlicheAbstand der Mouse-Events herangezogen. Ist beim Loslassen der Maustaste seit dem letzten Move-Event weniger als eine Sekunde vergangen, wird die entsprechende Rotationstransformation wieder-holt mit den zuletzt ermittelten Quaternionen beaufschlagt.

Im „Pick Hyperlinks“-Modus bzw. bei gleichzeitig gedrückten Ctrl- und Alt-Tasten (unter UNIX) oderdurch Doppelklick (unter Windows 95/NT) können sensitive Bereiche in der 3D-Szene (Hyperlinks)aktiviert werden. Dadurch wird der Browser angewiesen, eine URL zu laden, die im entsprechendenWWWAnchor-Node der VRML-1.0-Szenenbeschreibung festgelegt wurde. Ein Target-Frame kann imEMBED-Tag spezifiziert werden.

Unterstützung von Trackingsystemen und 3D-Interaktionsgeräten

Es wurde die Unterstützung mehrerer Headtracking-Systeme und 3D-Interaktionsgeräte integriert, dieüber eine serielle Schnittstelle (RS-232) Koordinaten- und Winkelwerte zum jeweiligen Rechner über-tragen. Dazu gehören:

• das ultraschallbasierte Headtracking-System Stereographics/Logitech CE-VR zur Unterstützungvon „Desktop-VR“-Szenarien (Abb. 13, S. 29),

• das magnetfeldbasierte Tracking-System Polhemus Fastrak [38],• das ultraschallbasierte Tracking-System InterSense IS-600 Mark II [15][18],• SpaceBall, SpaceMouse.

In diesem Zusammenhang wurden die grundsätzlichen Zusammenhänge zwischen den Sichtbedingun-gen und notwendigen Transformationsvorschriften für eine korrekt angepasste stereoskopische Wie-dergabe analysiert und eine Parametrisierung eingeführt.

Stereoskopische Transformation aus VRML-Daten

Es wird zwar in der Fachliteratur zum Teil behauptet, dass VRML nicht zur Stereodarstellung sowiegenereller VR-Anwendung geeignet ist [13]. Tatsächlich sind diesbezüglich jedoch nicht Unzuläng-lichkeiten des Dateiformats zu bemängeln, sondern der verfügbaren Viewer-Implementierungen. Zurkorrekten Stereopräsentation in DocShow-VR war es nun erforderlich, die Spezifikation der Betrach-tungsperspektive in adäquate OpenGL-Calls zu überführen. Dazu dienten zunächst die in VRML 1.0im Node PerspectiveCamera spezifizierten Parameter position, orientation, focalDis-tance und heightAngle. In VRML97 steht das Sprachelement Viewpoint mit entsprechendenAngaben (außer focalDistance) zur Verfügung.



Die durch den tatsächlichen Betrachterstandpunkt und die dazu relative Anordnung der Darstellungs-fläche (z. B. Monitor, Projektionsscheibe) des VR-Präsentationssystems vorgegebenen Verhältnissestimmen allerdings im allgemeinen nicht mit den VRML-Vorgaben überein. Um virtuelle Objekte, diesich in einer Ebene im Abstand focalDistance vom Betrachter entfernt innerhalb des vertikalenBlickwinkelbereichs heightAngle befinden, auf eine gerätespezifische Darstellungsfläche der HöheprojHeight abzubilden, ist eine Maßstabstransformation im Verhältnis

: (1)

erforderlich. Da der tatsächliche Betrachterabstand allerdings generell von dem zu focalDistancemaßstäblich entsprechenden Abstand abweicht, wird in der durchgeführten Implementierung dieheightAngle-Vorgabe aus VRML ignoriert und entsprechend den gerätespezifischen Konfigurati-onswerten projHeight und viewDistance neu gesetzt (heightAngle’):

(2)

bzw.

. (3)

Letztlich ergibt sich eine Maßstabstransformation im Verhältnis

(4)

mit dem Problem, dass je nach Abweichung des Wertes heightAngle’ von heightAngle gegebenenfallsein Ausschnitt des beabsichtigten abgebildet wird, dafür aber die Perspektive erhalten bleibt. DieAlternative wäre, den virtuellen Betrachterstandort in der Szene zu variieren. Diese Vorgehensweisestellt jedoch einen gravierenden Eingriff in die Szenenkonfiguration dar, der in der vorliegenden Imp-lementierung nur in Verbindung mit der Nutzung von Trackingsystemen realisiert wird.

Zur stereoskopischen Transformation wird noch eine vom Augabstand eyeDistance mit abhängendeSzenen-Translation eyeTranslation sowie eine Verzerrung der Sichtpyramide um eyeShift berücksich-tigt:

(5)

(6)

2 focalDistanceheightAngle

2-----------------------------

tan⋅ ⋅ projHeight

heightAngle ′2

------------------------------ tan

projHeight 2⁄viewDistance---------------------------------=

heightAngle ′ 2projHeight

2 viewDistance⋅---------------------------------------

atan⋅=

mfocalDistanceviewDistance---------------------------------=

eyeTranslationeyeDistance

2-----------------------------

focalDistanceviewDistance---------------------------------⋅=

eyeShifteyeDistanceprojWidth

-----------------------------=

projWidth

projHeight

ϕ

viewDistance

Betrachter

Präsentationsfläche

Abb. 10. Illustration der gerätespezifischen Sichtbedingungen. (siehe Gleichung 2)ϕ heightAngle ′≡



Da der üblicherweise auf einem Z-Buffer-Verfahren basierende interaktive Renderingprozess Hin-weise über den Bereich der Tiefenwerte benötigt, wurde auch für diesen Zweck eine Annahme anhanddes focalDistance-Wertes getroffen:

(7)

Bei eingeschaltetem Trackingsystem werden sowohl die Szenen-Translation als auch der Sichtpyrami-denstumpf entsprechend der Abweichung der Position des Betrachters vom Referenzort, der durch denKonfigurationsparameter viewDistance festgelegt ist, beeinflusst.

Problematisch für die perspektivisch korrekte Stereo-Präsentation sowie eine brauchbare Konfigura-tion der Near- und Far-Clipping-Ebenen (gemäß Ungleichung 7) ist die Tatsache, dass VRML-1.0-Dateien zum Teil keine oder unvollständige PerspectiveCamera-Elemente beinhalten und dass derVRML97-Standard überhaupt keine focalDistance-Spezifikation mehr zulässt. Daher wurde derVorverarbeitungsprozess mit einer entsprechenden Kommandozeilen-Option versehen:

wrl2toDVR -focalDistance value datei.wrl > datei.dvr

Konfigurationsmöglichkeiten

Zur Anpassung an die individuelle Nutzungsumgebung sowie zur Konfiguration bzw. Auswahl voninhalts- bzw. darstellungsspezifischen Optionen wurden drei Konfigurationsmöglichkeiten implemen-tiert:

1. Popup-Menüs, die aus dem Plugin heraus interaktiv bedient werden können.

2. Eine Konfigurationsdatei, die Bestandteil der Browser- bzw. Plugin-Installation ist und miteinem Texteditor bearbeitet werden kann (Tabelle 4).

Option Wert Erläuterung

Konfiguration der Sichtbedingungen

projWidthfloat(default: 35)

Breite der Darstellungsfläche in cm(Monitor, Projektion)

projHeightfloat(default: 28)

Höhe der Darstellungsfläche in cm(Monitor, Projektion)

eyeDistfloat(default: 6.5)

Augen-Abstand des Betrachters in cm(für Stereodarstellung)

viewDist float (def.: 35) Betrachterabstand in cm

Systemspezifische Einstellungen für Stereo-Ausgabe

dualPipestring(default: „“)

X-Server-Adresse der zweiten Graphik-Pipe für den Dual-Pipe-Stereo-modus (z. B.: „:1“)

stereoEmbedint(default: 0)

0: Stereowiedergabe nur im Fullscreen-Modus1: Stereowiedergabe in sämtlichen Windows, auch im Inline-Plugin (nur für Quadbuffer-Stereomodus geeignet)

stereoOldStyleint(default: 0)

0: Quadbuffer-Stereomodus1: Oldstyle-Stereomodus

stereoHeight int (def.: 492) Zeilenanzahl im Oldstyle-Stereomodus

stereoOffset int (def.: 532) Zeilenoffset im Oldstyle-Stereomodus

setmonStereo stringBefehl für Oldstyle-Stereomodus(default: /usr/gfx/setmon -n STR_RECT)

setmonDefault stringBefehl zum Zurückschalten vom Oldstyle-Stereomodus(default: /usr/gfx/setmon -n 72HZ)

Beeinflussung des Renderings und Optimierungsoptionen

Tabelle 4.Globale Voreinstellungen in der DVR-Konfigurationsdatei dvrconf.txt

0,05 focalDistance⋅ z 50 focalDistance⋅≤ ≤



antiAliasingint(default: 1)

0: Antialiasing ausgeschaltet1: Multisampling-Antialiasing aktiviert (soweit möglich)2: Accumulation-Buffer-Antialiasing aktiviert

antiAliasingSamples int (def.: 4) Anzahl Subsamples für Multisampling-Antialiasing

quadric-ResolutionHQ

int(default: 6)

Hohe Auflösung der Quadric-Highlevel-Primitive(Cone, Cylinder, Sphere)

quadric-ResolutionLQ

int(default: 20)

Niedrige Auflösung der Quadric-Highlevel-Primitive(Cone, Cylinder, Sphere)

progressive-Foreground

int(default: 1)

0: Progressives Rendering im Backbuffer1: Progressive Rendering im Frontbuffer

useOpengl-VertexArray

int(default: 1)

0: Keine Nutzung der OpenGL-1.1-VertexArrays1: Ausnutzung der OpenGL-1.1-VertexArray

useExt-VertexArray

int(default: 1)

0: Keine Nutzung der VertexArray-Extension1: Ausnutzung der OpenGL-VertexArray-Extension

useOpengl-TextureObject

int(default: 1)

0: Keine Nutzung der OpenGL-1.1-Texture-Objects1: Ausnutzung der OpenGL-1.1-Texture-Objects

useExt-TextureObject

int(default: 1)

0: Keine Nutzung der Texture-Object-Extension1: Ausnutzung der OpenGL-Texture-Object-Extension

useRendering-Optimization

int(default: 1)

0: Keine Nutzung der fallspezifisch optimierten Renderingroutinen in DocShow-VR1: Ausnutzung der fallspezifisch optimierten Routinen

useDisplayListint(default: 0)

0: Keine Nutzung der OpenGL-Displaylists1: Ausnutzung von OpenGL-Displaylists

useMipMapint(default: 1)

0: Texturemapping ohne Mipmaps1: Texturemapping mit Mipmaps

textureModeint(default: 0)

0: „Replace“; 1: „Decal“; 2: „Modulate“

textureQualityint(default: 2)

0: Texturfilterung: „Nearest“1: Texturfilterung: „Linear“2: Texturfilterung: „Linear Mipmap“

Tracking- und 3D-Interaktionsgeräte

headTrackingint(default: 0)

0: Head-Tracking ausgeschaltet1: Head-Tracking eingeschaltet: Polhemus / Intersense2: Head-Tracking eingeschaltet: Logitech / Crystal Eyes

fastrakStylusint(default: 1)

Nummer des Eingangskanals für den Fastrak-Stylus

fastrakTrackerint(default: 2)

Nummer des Eingangskanals für den Fastrak-Trackingsensor (Head-Tra-cking)

fastrakDevicestring(default:/dev/ttyd4)

Device-Name der seriellen Schnittstelle, an der das Trackinggerät Polhe-mus Fastrak oder InterSense IS-600 Mark II angeschlossen ist

logiDevicestring(default:/dev/ttyd2)

Device-Name der seriellen Schnittstelle, an der das Trackinggerät Stereo-graphics/Logitech CE-VR angeschlossen ist

useSpaceBallint(default: 0)

0: Nutzung eines SpaceBall1: Nutzung eines SpaceBall (über X-Windows-Input-Extension)

useSpaceMouseint(default: 0)

0: Nutzung einer SpaceMouse1: Nutzung einer SpaceMouse (über Windows-95/98/NT-Treiber)





3. Plugin-Optionen, die im EMBED-Tag auf der HTML-Webseite mit angegeben werden können(Tabelle 5).

CSCW-Konfiguration (Computer-Supported Cooperative Work)

cscwDestination-Host

string (default: localhost)

Internet-Adresse des Kommunikationspartners

cscwDestination-Port

int(default: 9090)

Port-Nummer des Kommunikationspartners

cscwOwnPortint(default: 9090)

Eigene Port-Nummer zur CSCW-Kommunikation


Generelle Optionen (Auswahl, siehe auch Netscape-Plugin-Dokumentation [27])

SRC string URL

WIDTH int Breite des Plugin-Windows

HEIGHT int Höhe des Plugin-Windows

TYPE string MIME-Typ (z. B. applicaton/x-docshow-vr)

PLUGINSPAGE string URL (CGI) einer passenden Plugin-Homepage

Plugin-spezifische globale Funktionseinstellungen

ANTIALIAS int0: Antialiasing ausgeschaltet1: Multisampling-Antialiasing aktiviert (OpenGL-Extension)2: Antialiasing mittes Accumulation-Buffer-Verfahren

BGCOLOR #rrggbb Hintergrundfarbe im Plugin-Window

DOUBLEBUFFER int0: Rendering-Window single-buffered1: Rendering-Window double-buffered

PROGRESSIVE int0: Progressives Rendering ausgeschaltet1: Progressives Rendering aktiviert (default)

TARGET string Frame-Name für im Plugin aktivierten Hyperlink

Beeinflussung des Renderings (Beleuchtung, Culling, Texturing, Transparenz, Normalisierung)

AMBIENTLIGHT int0: Umgebungslicht ausgeschaltet1: Umgebungslicht aktiviert (default)

AMBIENT-LIGHTINTENSITY

int Intensität des Umgebungslichts in % (default: 20)

HEADLIGHT int0: Kamera-Licht ausgeschaltet1: Kamera-Licht aktiviert (default)

HEADLIGHT-INTENSITY

int Intensität des Kamera-Lichts in % (default: 100)

SCENELIGHT int0: Szenen-Beleuchtung ausgeschaltet1: Szenen-Beleuchtung aktiviert (default)

SCENELIGHT-INTENSITY

int Intensität der Szenenbeleuchtung in % (default: 100)

TWOSIDE int0: Polygone auf einer Seite beleuchtet1: Polygone auf beiden Seiten beleuchtet (default)

CULLING int0: Culling ausgeschaltet1: Culling aktiviert

Tabelle 5.Plugin-Optionen des EMBED-Tags





CULLFACE stringCulling-Orientierung:• FRONT: Culling der Polygon-Vorseite• BACK: Culling der Polygon-Rückseite

TEXTURING int0: Texture-Mapping ausgeschaltet1: Texture-Mapping aktiviert (default)

TRANSPARENCY int0: Transparenz (Blending) ignoriert1: Transparenz aktiviert (default)

NORMALIZE int0: keine Normalisierung der Normalenvektoren1: Normalisierung der Normalenvektoren (default)

Darstellung von Flächen und Linien

LINEWIDTH float Linienbreite in Pixel (default: 1)

POLYGONMODE string

Polygon-Renderingmodus• FILL: Flächenfüllung (default)• LINE: Liniendarstellung der Kanten• POINT: Punktdarstellung der Eckpunkte

ASPECTPIXEL float Seitenverhältnis eines Pixels (default: 1.0)

Sicht und Navigation

CAMERA int Setzt Kamera-Nummer (default: erste Kamera)

NAVIGATION string

Art der Navigation durch Maussteuerung:• ROTATE: Rotation des Objektes (default)• ROTATE_CAMERA: Rotation der Kamera• SCALE: Skalierung des Objekts• TRANSLATE_XY: Translation X/Y• TRANSLATE_Z: Translation Z• WALK: Vor- und Seitwärtsbewegung

TRANSLATION 3 floats Translation des Objekts (x, y, z)

QUATOBJECT 4 floats Rotation des Objekts (Quaternionen)

QUATCAMERA 4 floats Rotation der Kamera (Quaternionen)

MAXSUB-CAMERA

intAnzahl interpolierter Positionen und Orientierungen zwischen zwei Vie-wpoints in der „Replay Cameras“-Funktion, sofern „Interpolate Came-ras“ aktiviert

INTERPOLATEint(default: 0)

0: Keine Interpolation von Viewpoints in der „Replay Cameras“-Funktion1: Interpolation von Viewpoints aktiviert

LOOPCAMERASint(default: 0)

0: Kein Loop-Modus in der „Replay Cameras“-Funktion1: Loop-Modus der „Replay Cameras“-Funktion aktiviert

PLAYCAMERASint(default: 0)

0: Kein Autostart der „Replay Cameras“-Funktion1: Autostart der „Replay Cameras“-Funktion aktiviert

Szenen-Sequenzen

SEQUENCE url;from–to,fps

url: URL der dynamischen Szenen mit Numerierung durch z. B. %03d entsprechend Formatierung in C

from:erste Frame-Nr.

to: letzte Frame-Nr.

fps: Frame-Rate (Frame je Sekunde)

LOOPSEQUENCEint(default: 0)

0: Kein Loop-Modus in der „Replay Sequence“-Funktion1: Loop-Modus der „Replay Sequence“-Funktion aktiv

PLAYSEQUENCEint(default: 0)

0: Kein Autostart der „Replay Sequence“-Funktion1: Autostart der „Replay Sequence“-Funktion aktiv


Tabelle 5.Plugin-Optionen des EMBED-Tags



4.1.3.3 DVR-Streaming und „DVRS“-Metadaten

Neben einem gewöhnlichen WWW-Server, welcher für die besprochenen Mechanismen einzelne 3D-Szenen im DVR-Format bzw. Meta-Informationen im DVRS-Format bereitstellt, wird ein spezieller3D-Streaming-Server benötigt. Dieser wurde in einer Studie [20] auf einem UNIX-Betriebssystem(SGI Irix) prototypisch implementiert und anschließend weiterentwickelt. Dabei wurde das zunächstnur als Internet-Draft vorliegende, inzwischen in RFC 2326 standardisierte Real Time Streaming Pro-tocol (RTSP) [44] für den Steuer-Datenfluss angewandt.

Es handelt sich dabei um ein Client-Server-Protokoll, welches für die Steuerung der Ausspielung oderAufzeichnung kontinuierlicher Medienströme, wie Audio und Video, ausgelegt ist. Spezielle Proto-kolldatenelemente können über einen Steuerungskanal die an der Kommunikation beteiligten Server-und Client-Prozesse gegenseitig in bestimmte Zustände versetzen (siehe Abb. 11).

Über einen separaten Datenkanal werden dann, in Abhängigkeit vom jeweiligen Zustand, Medien-ströme transportiert. Im hier vorliegenden Anwendungsfall wurde dafür ein eigenes DVR-Transport-Protokoll (DVRP) definiert. Im Gegensatz zu anderen Audio-/Video-Streaminganwendungen, die dasTransport Protocol for Real-Time Applications (RTP) gemäß RFC 1889 [43] über UDP/IP verwenden,wurde hier eine TCP/IP-basierte Übertragung festgelegt, da hier Verluste, Fehler oder Reihenfolge-Inkonsistenzen nicht toleriert werden können. Der DVRP-Datenstrom beinhaltet die im DVR-Datei-format spezifizierten PDUs und fügt nach jeder Szene eine Szenen-Ende-Markierung ein (PDU-Typ =17, siehe Tabelle 1, S. 18), um damit dem Client den Update-Befehl zu geben. Eine Intra-Stream-Syn-chronisierung wurde auf Basis der serverseitigen Auslieferungszeitpunkte realisiert. Die geforderteFramerate wird dabei im Mittel dadurch eingehalten, dass entweder entsprechende Wartephasen ein-gefügt werden oder gelegentlich Szenendateien ausgelassen werden.

Die Kommunikations- und Präsentationsvorgänge wurden in der DVRS-Plugin-Software in einerWeise implementiert, die ein effizientes Pipelining erlaubt. Dazu wurde ein Wechsel-Puffer – zumgleichzeitigen Rendern einer aktuellen 3D-Szene und Einlesen einer neuen 3D-Szene – mit demDatenvolumen von zwei 3D-Szenen je Stream konfiguriert und dieser als „Shared Memory“ den betei-ligten, parallel ablaufenden „Light-Weight Processes“ (LWP) – in SGI Irix: sproc() [49] – bereitge-stellt:

• Der Hauptprozess ist Bestandteil des WWW-Browsers und erledigt das Rendering einer jeweilsvollständig übertragenen Szene auf dem primären Graphiksubsystem.

• Ein LWP realisiert den DVRP-Datentransport der jeweils aktuell neu übertragenen 3D-Szene.• Ein weiterer LWP dient im Dual-Pipe-Stereobetrieb dazu, die jeweils aktuelle 3D-Szene auf dem

zweiten Graphiksubsystem parallel zum primären zu rendern.

Die Interprozess-Kommunikation zur Synchronisierung der Aufgaben wurde über bidirektionale Pipesrealisiert, die zum Teil über den Event-Mechanismus des X-Windows-Toolkits entsprechend regist-rierte Callback-Funktionen des Hauptprozesses auslösen. Beispielsweise erfolgt eine Mitteilung desDVRP-Prozesses über eine jeweils fertig übertragene 3D-Szene an den Hauptprozess, der daraufhineinen neuen Renderingvorgang ausführt, während der DVRP-Prozess bereits die nächste 3D-Szene inden – inzwischen gewechselten – Lesepuffer einliest.

Init Ready Playing

Setup Play

Teardown Pause

Teardown

Teardown Setup Play oder Setup

Abb. 11. Real Time Streaming Protocol (RTSP): Zustandsübergangsdiagramm für einen Ausspiel-Server



Zur Initialisierung des Clients werden Startup-Informationen benötigt, die in einem eigenen Klartext-Dateiformat abgelegt werden. In diesen „DVRS“-Metadaten werden die Eigenschaften eines odermehrerer 3D-Streams spezifiziert, die z. B. durch Server-Adresse und Darstellungsattribute gekenn-zeichnet sind (siehe auch Abb. 5, S. 13). Die derart beschriebenen Streams werden dann synchronabgerufen und präsentiert. Dadurch ist es möglich, statische Szenenkomponenten zu definieren, dienur einmal am Beginn übertragen werden müssen – für diese wird die Framerate 0 spezifiziert.

Auf dem 3D-Streaming-Server liegen die „3D-Filme“ in Form von Serien einzelner DVR-Dateien.Dabei wird ein Teil des jeweiligen Dateinamens als Bildnummer, die standardmäßig mit 0 beginnt,durchnummeriert. Das jeweils benutzte Nummerierungsschema wird im DVRS-Datensatz durch einNamens-Template spezifiziert, in dem an Stelle der Nummer eine bestimmte Anzahl „*“-Zeichen ste-hen. Dem Server wird dieses nach dem Verbindungsaufbau über das RTSP-Protokoll übermittelt. Die-ser setzt die Bildnummer-Parameter in der jeweiligen „Play“-Anforderung dann in dieses Templateein, um die einzelnen 3D-Szenen der Reihe nach einzulesen und als DVRP-Datenstrom auszuspielen.

4.1.4 Anwendung und Bewertung

4.1.4.1 Erprobung und Demonstration in Anwendungen

Unterstützung verschiedener Stereo-Präsentationssysteme

Grundsätzlich ist eine Reihe verschiedener Verfahren zur stereoskopischen Bildwiedergabe zu unter-scheiden (siehe auch [14][51]), von denen am RRZN/RVS einige für den praktischen Anwendungsbe-trieb installiert wurden (siehe auch Abb. 12 und Abb. 13):

• Ein einzelnes Display – Bildschirm oder Projektion – ermöglicht die abwechselnde Präsentationder beiden Bilder, wobei der Betrachter eine aktive LCD-Shutterbrille trägt, die synchron mit derDarstellung jeweils ein Auge abdunkelt. Im Zusammenhang mit leistungsfähigen Arbeitsplatz-rechnern (z. B. SGI Octane in Abb. 13 (a)) sind dadurch auf dem Desktop gewisse VR-Methodenanwendbar („Desktop-Virtual-Reality“). Dazu kann z. B. ein stereofähiger Monitor in Kombina-tion mit einer LCD-Shutterbrille und einem integrierten ultraschallbasierten Trackingsystem(z. B. Stereographics/Logitech CE-VR in Abb. 13 (a)) verwendet werden. Die jeweils eingesetz-ten Graphik-Subsysteme unterstützen unterschiedliche Stereo-Shutter-Modi:

– Der „Old Style“-Modus ermöglicht „Full-Screen Stereo“ durch Halbierung der Zeilenan-zahl bzw. Verdopplung der Vertikal-Synchronfrequenz: z. B. 1280x492 Pixel, 120 Hz. Die-ser Modus wird auf sämtlichen SGI-Workstations unterstützt, z. B. Onyx Reality Engine2(RE2) und Onyx2 Infinite Reality (IR), Indigo2 Extreme, Indy, O2.

– Der „Quad Buffer“-Modus ermöglicht „Stereo in a Window“. Hier muss nicht zwischenzwei verschiedenen Modi umgeschaltet werden, da das entsprechende Window-System (X-Window bzw. Windows 95/98/NT) die Synchronisierung der Darstellung auf den beidenabwechselnd präsentierten Framebuffern bewirkt. Da 3D-Graphik standardmäßig im„Double-Buffer“-Modus produziert wird, muss die Graphikkarte letztlich vier Bildspeicheranbieten (LEFT_BACK, RIGHT_BACK, LEFT_FRONT, RIGHT_FRONT); daher dieBezeichnung „Quad Buffer“. Dieser Modus wird z. B. auf der SGI Onyx RE2 (Irix 5.3), aufder SGI Onyx2 IR (Irix 6.5.4), auf der Sun Elite 3D (Solaris 2.6), auf der HP Kayak fx6(Windows NT) sowie auf der Fire GL 1000 Pro (Windows NT) angeboten.

• Zwei getrennte Displays können entweder durch die Augen eines einzelnen Nutzers direktbetrachtet werden, wie HMD oder BOOM, oder durch Großbildprojektion mit vorgeschaltetenPolarisationsfiltern einem größeren Zuschauerkreis die Betrachtung mit passiven Polfilterbrillengestatten (Abb. 13 (b)). Ein Großbild-Rückprojektionssystem entsprechend dieser Technikwurde Ende 1997 am RRZN/RVS installiert. Es handelt sich dabei um zwei Marquee-9500-Pro-jektoren sowie eine Black-Matrix-Rückprojektionsscheibe mit 2,40 m Breite und 1,80 m Höhe.Der entsprechend ausgestattete 3D-Präsentationsraum bietet Platz für maximal ca. 20 Zuschauer.Zunächst wurden die Projektoren mit zwei Videosignalen gespeist, die über einen „Dual StereoEncoder“ aus der 3D-Graphikworkstation SGI Onyx RE2 erzeugt wurden. Dadurch wurde eineKompatibilität zu dem für Bildschirm-Stereodarstellung adäquaten Shuttermodus der Worksta-



tion erreicht. Später, nach Inbetriebnahme des leistungsfähigeren Graphikrechners SGI Onyx2mit 2 Infinite-Reality-Graphikpipelines Ende 1998, konnte jeder Projektor an den Ausgang eineseigenen Graphiksubsystems angeschlossen werden (Abb. 12 (a)). Durch diesen Parallelbetriebkönnen höhere Bildqualitäten und Frameraten erzielt werden.

Infinite Reality,2 Raster Manager

Graphics toVideo Option

Graphik-Subsystem 1

VideoDiskrecorder

D1


Graphik-Subsystem 0

Digital VideoI/O Option

D1

Renderingprozess

D1

Clientprozess

Betacam-SPVideorecorder

D1

D1/YUVConverter

YUV

Video-Kamera etc.

PAL

D1

3D-Geometrien

2D-Rasterbilder Cache etc.

Audio-I/O

D1

OpenGL

IP

DisplayGenerator

Workstation-Monitor

RGB

DisplayGenerator

Workstation-Monitor

RGB

Stereo-Projektion


GeneratorGraphics toVideo Option

Graphik-Subsystem 1

Workstation-Monitor

RGB

VideoDiskrecorder

D1


DisplayGenerator

Graphik-Subsystem 0

Workstation-Monitor

RGB

Digital VideoI/O Option

D1

Rendering-Prozess Rendering-Prozess

D1

Client-ProzessClient-Prozess

D1

IP

Betacam-SPVideorecorder

D1

D1/YUVConverter

YUV

Video-Kamera etc.

PAL

Serverprozeß

IP

D1

RAID

2D-Rasterbilder3D-Geometrien2D-Rasterbilder Cache etc.Cache etc.

Audio-I/O Audio-I/O

D1

(alt.)

OpenGLOpenGL

(a) Stereoskopische Online-Präsentation

komplexer 3D-Szenen, Video-Integration;

Digitalvideosignal D1 lt. ITU-R 601:

• D1-Input z. B. für Videotexturen,• D1-Output z. B. für Videomitschnitt.

(b) Demonstrator für verteilte Visualisierung

Abb. 12. Anwendungsbeispiele des 3D/VR-Hochleistungsrechners SGI Onyx2 Infinite Reality

Display

3D-Geometrien

(a) Stereo-Monitor, LCD-Shutterbrille, Head-

Tracking und SpaceBall: „Desktop-VR“

(b) Stereo-Großbildprojektion im 3D-Präsentations-

raum für ca. 20 Personen (RRZN/RVS)

Abb. 13. Beispiele nutzbarer Virtual-Reality-Gerätetechnik für 3D-Präsentation und -Interaktion



Unterstützung verschiedener Plattformen

Die entwickelte Software wurde auf mehrere Plattformen, d. h. Hardware-Architekturen / Betriebssys-teme, portiert:

• UNIX– Hewlett-Packard (PA-RISC): HP/UX– Silicon Graphics (MIPS): IRIX– Sun (SPARC): Solaris

• Microsoft Windows 95/98/NT– Intel-PCs (Pentium)

Anwendungsbeispiele

Auf der Basis der entwickelten Systemkomponenten wurden mehrere praktische Anwendungen ausverschiedenen Fachgebieten unterstützt. Zum Teil wurden diese als virtuelle Exponate veröffentlicht.

Beispielhaft seien hier einige genannt (siehe auch Abb. 14 und Abb. 15):

• Statische 3D-Objekte– Architektur,– Fertigungstechnik,– Rekonstruktion eines Regenwurmgangsystems,– Thermodynamik,– Virtuelle Bronchoskopie.

• 3D-Streaming– Ozeanische Konvektion,– Meeres- und Polarforschung,– Molekulardynamik,– Verfahrenstechnik.

Abb. 14. Anwendung „Ozeanische Konvektion“ in der Nutzeroberfläche „DocShow-VR“



Abb. 15. Anwendungsbeispiele – Screendumps aus „DocShow-VR“siehe auch www.dfn-expo.de/Technologie/DocShow-VR/show/

3D-Rekonstruktion tomographischerMessergebnisse (Verfahrenstechnik)

3D-Rekonstruktion einer Tomographie(Virtuelle Bronchoskopie)

3D-Rekonstruktion einer Tomographie(Regenwurmgangsystem)

Messung der Rauhheit einer Oberfläche(Fertigungstechnik / Werkzeugmaschinen)

Molekulardynamische Simulation(Thermodynamik)

Ozeanische Konvektion(Meteorologie und Klimatologie)

WXOD – Wetterbericht On Demand(Deutscher Wetterdienst)

Visualisierung des Zirkumpolarstroms(Alfred-Wegener-Institut)

CAD-Modell – Golf 4(Volkswagen AG)

Kirchenpavillon – Expo 2000(Architektur-Visualisierung)



4.1.4.2 Online-Präsentation statischer 3D-Objekte

Für die Evaluierung der Implementierung wurden die Datenvolumina, Startup-Zeiten und Rendering-Raten in einigen typischen Anwendungen gemessen. Dazu wurde das Plugin DocShow-VR an geeig-neten Stellen instrumentiert, d. h. Zeiten gemessen. In der UNIX-Implementierung diente dazu derSystem-Call gettimeofday(), unter Windows wurde die Win32-Funktion GetCurrentTime()verwendet. Am Plugin CosmoPlayer konnten die Renderingzeiten über eine eingebaute Funktionalitätermittelt werden, die durch Drücken der Taste „+“ aktiviert wird. Die Startup-Zeit wurde „von Hand“gestoppt.

Es wurde die 3D-Szene „DX-03“, welche Bestandteil des OpenGL-Benchmarks viewperf [34] ist, ver-wendet. „DX-03“ repräsentiert das Ergebnis einer Visualisierungsanwendung. Es wurde mit dem IBMData Explorer erzeugt und enthält 91.584 Dreiecke, die als 976 „Triangle-Strips“ mit je ca. 100 Dreie-cken repräsentiert werden (siehe auch Abb. 16, S. 33); an den Eckpunkten liegen Normalenvektorenvor. Dieses Objekt wurde zunächst aus dem viewperf-spezifischen MSH-Dateiformat („trianglemesh“) mit Hilfe eigener Software, die im Rahmen einer Studie entwickelt wurde [37], in VRML-For-mate (Version 1.0 und 2.0) konvertiert. Die VRML-1.0-Datei wurde schließlich in das DVR-Formatkonvertiert, wobei eine Variante mit Triangle-Strip-Optimierung und eine Variante mit separaten Drei-ecken erzeugt wurde.

DocShow-VR versus CosmoPlayer

In Tabelle 6 werden Ergebnisse eines Vergleichs bei der Nutzung der Inline-Plugins CosmoPlayer (fürVRML-Formate, zum Testzeitpunkt: Version 1.02) und DocShow-VR (DVR-Format, zum Testzeit-punkt: Version 0.9) zur Online-Präsentation der Beispielszene „DX-03“ gegenübergestellt.

In der beschriebenen Testkonfiguration wurden die folgenden Beobachtungen gemacht:

• Das Datenvolumen der optimierten DVR-Datei ist ähnlich wie das der gzip-komprimiertenVRML-2.0-Datei.

• Die Startup-Zeit wurde gegenüber der Anwendung mit dem CosmoPlayer auf ca. 1/28 reduziert.• Die Renderingrate ist in DocShow-VR 2- bis 4-mal so hoch wie im CosmoPlayer. Es wurde die

im SGI-Datenblatt des Reality-Engine2-Graphiksubsystems spezifizierte Peak-Polygonrate –„3D triangle meshes, smooth shaded, z-buffered, phong lighting: 1,07 Mio. triangles/s“ – er-reicht. Diese sind auch vergleichbar mit entsprechenden Mess-Ergebnissen aus dem OpenGL-Benchmark viewperf.

DocShow-VR 0.9 / DVR-Format CosmoPlayer 1.02 / VRML 2.0

Triangle Strips Independant Triangles uncompressedcompressed

(gzip)

Datenvolumen [byte] 2.252.744 6.601.928 9.768.093 2.266.695

Startup-Zeit („progressive aus“: ohne Renderingzeit)

0,795 s,progressive: 0,911 s

1,709 s,progressive: 1,894 s

ca. 25 s ca. 25 s

Äquivalente Bitrate (Startup)22,7 Mbit/s,

progressive: 19,8 Mbit/s30,9 Mbit/s,

progressive: 27,9 Mbit/s3,1 Mbit/s 0,73 Mbit/s

Rendering-Zeit0,155 s,

optimized: 0,084 s0,151 s,

optimized: 0,144 sca. 0,36 s

Renderingrate [Dreiecke/s]590.864,

optimized: 1.090.286606.517,

optimized: 636.000254.400

Äquivalente Bitrate (Rendering)116 Mbit/s

optimized: 214 Mbit/s350 Mbit/s

optimized: 367 Mbit/s

Tabelle 6. Leistungsvergleich des Szenarios „DX-03“ – DocShow-VR versus CosmoPlayer.Fenstergröße 512 x 512 Pixel auf einer Silicon Graphics (SGI) Onyx Reality Engine2 (2 x R4400, 200 MHz, 2 RMs); Zugriff auf einen WWW-Server Apache auf einer SGI Challenge L (2 x R4400, 200 MHz), Verbindung: TCP/IP über ATM, 155 Mbit/s. Varianten in der DVR-Messung:(a) „Progressive“ – mit inkrementeller Darstellung während des Transports(b) „Optimized“ – ohne „Normalize Normals“, „Two-sided Lighting“, „Transparency“



Allerdings musste dazu in der Vorverarbeitung die Triangle-Strip-Optimierung durchgeführt werden,und die Plugin-Optionen „Normalize Normals“, „Two-sided Lighting“ und „Transparency“ musstenabgeschaltet werden („optimized“ in Tabelle 6). Werden diese Optimierungsmöglichkeiten nichtbeachtet, so sind Nachteile bezüglich der Datenvolumina, Startup-Zeiten und der Rendering-Perfor-mance die Folge.

Jedoch können die genannten erheblichen Vorteile nicht verallgemeinert werden, da die Optimierungder Modell-Repräsentation sowie der Rendering-Optionen nicht generell anwendbar sind, z. B. weilandere 3D-Objekte nicht in diesem Maße automatisch optimierbar sind oder je nach Anwendungskon-text ineffizientere Graphik-Attribute verwendet werden müssen.

Optimierungen in Vorverarbeitung und Renderingvorgang

Zur Beurteilung der Auswirkungen verschiedener implementierter Optimierungsoptionen wurden dreiverschiedene, anwendungsnahe Beispielszenen verwendet, die jeweils eine Komplexität in der Grö-ßenordnung von ca. 100.000 Polygonen aufwiesen. In Abb. 16 sind Beispielansichten sowie Charakte-ristika dargestellt.

Auswirkung der Optimierungen bei der Vorverarbeitung

Die in Abb. 16 dargestellten 3D-Szenen lagen als VRML-Dateien vor und wurden zunächst in dasDVR-Format konvertiert. Dabei wurden jeweils zwei Varianten erzeugt: eine mit unabhängigen Dreie-cken und eine weitere, die, soweit möglich, automatisch erkannte Triangle-Strips repräsentiert. Wiedie Ergebnisse in Tabelle 7 zeigen, sind die Vorteile dieser Optimierung sowohl in bezug auf dasDatenvolumen als auch auf die Renderingzeit deutlich.

Das Datenvolumen wird durch die eingeschaltete Optimierung bei der Vorverarbeitung der Szenen (a)und (b) nahezu um den prinzipiell erreichbaren Faktor 3 reduziert. Die VRML-Polygondaten wurdennahezu vollständig in die Triangle-Strip-Primitive des DVR-Formats umgewandelt.

Die Renderingleistung wurde auf verschiedenen Plattformen gemessen:

• 3D-Graphikworkstation der Firma Hewlett-Packard (Pentium, Windows NT),

• 3D-Graphiksupercomputer der Firma Silicon Graphics (MIPS, Irix).

Abb. 16. Anwendungsszenarien der durchgeführten Messungen

(a) „DX-03“

Anwendung des IBM

Data Explorer (aus dem

OpenGL-Benchmark viewperf [34])

91.584 Dreiecke mit

Normalen je Eckpunkt

(c) „Ozeanische Konvektion,

Zeitschritt Nr. 492“

AVS/Express-Ergebnis (Institut für

Meteorologie und Klimatologie,

Universität Hannover)

96.412 Primitive;

verschiedene Attribute

(b) „Messung der Rauhheit

einer Oberfläche“

AVS-Ergebnis (Institut für

Fertigungstechnik,

Universität Hannover)

130.050 Dreiecke;

Normalen und Farben je Eckpunkt



Die Renderingzeit beträgt für die Triangle-Strip-Repräsentation in einigen Fällen ca. 1/3 gegenüberder mit unabhängigen Dreiecken. Die absolute Zeit liegt je nach Modell zum Teil deutlich unter 100ms, der für eine interaktive Navigation maximal tolerierbaren Update-Zeit. Die getesteten Graphiksys-teme sind für Anwendungen mit 3D-Szenen der hier vorliegenden Komplexität von ca. 100.000 Poly-gonen also geeignet.

Die Renderingrate eines aktuellen Hochleistungs-PCs übertrifft sogar die des für VR-Anwendungenüblicherweise eingesetzten High-End-Graphikrechners. Allerdings bietet das PC-Graphiksystem kei-nen Hardware-Support für Global-Scene-Multisampling-Antialiasing und ist daher aufgrund der rela-tiv geringen Bildqualität für immersive VR-Anwendungen ungeeignet.

Die Renderingbitraten, die den Datendurchsatz zwischen dem Hauptspeicher und dem Graphiksubsys-tem charakterisieren, liegen hier zwischen 0,3 und 1,2 Gbit/s.

Auswirkungen der Optimierungsoptionen des Renderingvorgangs

Um zu zeigen, welche Vor- oder Nachteile die in Abschn. 4.1.3.2 diskutierten Maßnahmen bringen,wurden die Rendering- und Display-List-Compilationszeiten für die Szene „DX-03“ unter verschiede-nen Bedingungen gemessen:

• „No Optimization“: Rendering mit einer Universal-Routine.

• „Loop Unrolling“: Rendering mittels spezialisierter Routine, die der jeweiligen Topologie (hier:Triangle-Strips) besonders angepasst ist; je 4 Normalen- und Koordinatenvektoren werdenblockweise verarbeitet.

• „Vertex Array“: Rendering mittels OpenGL-Erweiterung „Vertex Array“.

• „Display List“: Rendering als Display-List; dabei wurde auch der Compile-Vorgang separatgemessen.

Datenvolumen derDVR-Dateien

RenderingleistungHP Kayak

fx6+SGI Onyx2

Infinite Reality

(a)„DX-03“

Triangle strips:2.252.744 byte

Renderingzeit:-polygonrate:

-bitrate:

15 ms6,11 Mio./s1,20 Gbit/s


Independant triangles:6.601.928 byte


-bitrate:



(b)„Messung der Rauhheit einer Oberfläche“



-bitrate:

31 ms4,195 Mio./s0,944 Gbit/s

62 ms2,095 Mio./s0,471 Gbit/s



-bitrate:

125 ms1,040 Mio./s0,699 Gbit/s

193 ms0,675 Mio./s0,453 Gbit/s

(c)„Ozeanische

Konvektion, Zeit-schritt Nr. 492“



-bitrate:

47 ms2,051 Mio./s0,531 Gbit/s

86 ms1,118 Mio./s0,289 Gbit/s



-bitrate:

109 ms1,002 Mio./s0,666 Gbit/s

141 ms0,684 Mio./s0,454 Gbit/s

Tabelle 7. Datenvolumina, Renderingzeiten, -polygonraten, -bitraten in den Anwendungsszenarien gemäß Abb. 16.Plugin: DocShow-VR 1.4. Fenstergrößen: (a) 512x512, (b) und (c) 640x480 Pixel.Rendering: OpenGL immediate mode, vertex arrays, 1 light, one-sided lighting (außer c: two-sided),disable transparency. Plattformen:– HP Kayak XW, fx6+, 2 x Pentium III Xeon, 550 MHz, Windows NT 4.0 SP4– SGI Onyx2 Infinite Reality, 4 x MIPS R10000, 195 MHz, Irix 6.5.5



Die auf verschiedenen Plattformen ermittelten Ergebnisse sind in Tabelle 8 aufgeführt.

Es wurde beobachtet, dass die Nutzung der OpenGL-Vertex-Array-Erweiterung nicht in jedem Fallden erhofften Vorteil bringt, sondern je nach Plattform auch zu einem Performance-Verlust führenkann. Die Ursache hierfür liegt vermutlich in einer unzulänglichen Treiber-Implementierung derjeweiligen Graphikkarte.

Die Anwendung von OpenGL-Display-Listen ist generell mit einer erheblichen Startup-Zeit für die„Compile“-Aktion, in der OpenGL eine Optimierung durchführt und die Graphikdaten gegebenenfallsin einem hardwarespezifischen Cache ablegt, verbunden. Für den Fall statischer Szenenpräsentationund -Navigation liegt diese zwar in einem tolerierbaren Bereich, und die Renderingrate wird zum Teildeutlich erhöht.

Im Zusammenhang mit der hier betrachteten Ziel-Anwendung „3D-Streaming“, bei der häufig nachjedem Szenen-Update nur ein einziger Renderingvorgang erfolgt, ist jedoch die Summe aus Compila-tion und Rendering zu betrachten – diese ist wesentlich höher als die Renderingzeit im OpenGL-„Immediate Mode“. Daher sind Display-Listen in diesem Anwendungsfall ungeeignet.

4.1.4.3 3D-Streaming – „Virtual Reality Movies“

Zur Evaluierung des Produktionsprozesses in einer typischen Anwendung aus der „WissenschaftlichenVisualisierung“ wurde ein Testbed [33] aufgebaut, welches aus den folgenden Komponenten bestand:

DVR-Datensatz:

Aus einer Simulationsrechnung eines instationären Strömungsphänomens (Ozeanische Konvektion[39]), welche auf einem Supercomputer Siemens/Fujitsu VPP 300 durchgeführt wurde, resultiertenRohdaten von 940 Zeitschritten. Diese beinhalteten jeweils Temperaturwerte und Strömungsge-schwindigkeiten an 161x161x31 orthogonalen Gitterpunkten, gespeichert als float-Werte in 32 bitGenauigkeit. Das Datenvolumen dieser Ergebnisdaten betrug demnach:

940 x 161 x 161 x 31 x (1 + 3) x 4 byte = 12.085.407.040 byte

Die Ergebnisdaten jedes einzelnen Zeitschritts wurden dann mit Hilfe von Modulen einer mit AVS/Express implementierten Visualisierungsanwendung in eine dreidimensionale Szene aufbereitet.Dabei wurde das Temperaturfeld durch einen gemäß Farbtabelle eingefärbten vertikalen „Slicer“sowie eine „Isosurface“ eines festgelegten Temperaturwertes und das Geschwindigkeitsfeld an äqui-distanten Positionen auf einer festgelegten, horizontalen Ebene als „Arrows“ visualisiert. Aus AVS/Express heraus wurde mit dem Modul „OutputVRML“ jede einzelne 3D-Szene im Format VRML 1.0gespeichert. Aus diesen VRML-Dateien wurde schließlich durch Konvertierung mit dem Werkzeugwrl1toDVR eine Szenensequenz im DVR-Format erzeugt.

940 DVR-Dateien in einer Größe von jeweils ca. 5–9 Mbyte standen letztlich für eine Leistungsbewer-tung zur Verfügung, wobei jede ca. 100.000 Primitive (Linien, Polygone) repräsentierte.

Ein Beispiel (Szene Nr. 492) ist in Abb. 16 (c) dargestellt.

Immediate Mode Display List

No Optimization Loop Unroll. Vertex Array Compilation Rendering

Onyx 2 IR 37 ms 29 ms 21 ms 100 ms 15 ms

HP Kayak XW fx6+ 15 ms 15 ms 15 ms 46 ms 15 ms

PC / Elsa Erazor II 85 ms 80 ms 135 ms 130 ms 60 ms

PC / Elsa Synery II 65 ms 60 ms 50 ms 195 ms 50 ms

Tabelle 8. Renderingzeiten für Szene „DX-03“ mit verschiedenen Optimierungsoptionen.Plugin: DocShow 1.4. Fenstergröße: 512x512. Plattformen wie in Tabelle 7 und– PC, Elsa Erazor II (Treiber 4.11.01.0301-0023), Pentium II, 400 MHz, Windows 98– PC, Elsa Synergy II (Treiber 4.11.01.0300-0016), Pentium III, 500 MHz, Windows 98



Client-Server-Konfiguration für 3D-Streaming:

Als Client-System, bei dem es hauptsächlich auf 3D-Renderingleistung ankommt, wurde ein SiliconGraphics (SGI) Onyx2 Racksystem (4 Prozessoren R10000/195 MHz, 2 Gbyte Hauptspeicher,9 Gbyte SCSI-Disk, Betriebssystem Irix 6.5.4) verwendet, das mit zwei Graphiksubsystemen vom Typ„Infinite Reality“ (jeweils mit zwei 64 MB Raster Managern) ausgestattet war.

Ein 3D-Streaming-Server wurde ebenfalls auf dieser Maschine installiert, und zwar für Entwicklungs-zwecke und Testmöglichkeiten eines High-Performance-TCP/IP-Szenarios über die Loopback-Kom-munikation. Die DVR-Dateien wurden auf einem 140-Gbyte-RAID-System – bestehend aus 10 SCSI-Disks mit je 18 Gbyte – gespeichert, welches über Fibre Channel (800 Mbit/s) an die Onyx2 ange-schlossen war.

Ein separater 3D-Streaming-Server wurde auf einem Server vom Typ SGI Origin200 (R10000/225 MHz, 512 Mbytes Hauptspeicher, 9 + 18 Gbyte SCSI-Disk, Betriebssystem Irix 6.5.4) installiert.In diesem Fall wurden einige DVR-Dateien auf einer eingebauten SCSI-Disk (18 Gbyte) gespeichert.

Als Datennetz zwischen der Onyx2 und der Origin200 diente eine Back-to-back-Verbindung auf derBasis von Gigabit-Ethernet. Zur Optimierung der Leistungsfähigkeit wurde auf beiden Maschinen dieUnterstützung von „Alteon Jumbo-Frames“ durch eine Konfiguration im Betriebssystemkern aktiviert.Wie in anderen Untersuchungen gezeigt wurde, kann durch Nutzung dieser Option, die allerdings bis-lang proprietär ist, das hohe Leistungspotenzial dieser Netzinfrastruktur erheblich besser ausgenutztwerden, da wegen der größeren MTU – 9000 byte statt der standardisierten Größe von 1500 byte – dieEndgeräte (hier: Onyx2, Origin200) wesentlich weniger durch Interrupts belastet werden. In der hierverwendeten Konfiguration konnten bis zu ca. 720 Mbit/s (Memory-to-memory, von der Origin200zur Onyx2) umgesetzt werden [4].

Zunächst wurde der Durchsatz jeweils an den kritischen Pfaden (Lesen von Datei, Übertragung überTCP/IP, 3D-Rendering über OpenGL) separat gemessen. Schließlich wurde noch die „Über-alles“-Performance der gesamten Streaming-Verarbeitungskette bewertet, wobei die vorgegebene Frameratevariiert wurde.

In Tabelle 9 sind einige charakteristische Größen zusammengestellt.

ClientSGI Onyx2

Client / Server 1SGI Onyx2

Client / Server 2SGI Origin200

Lesen von DVR-Dateien, ein Leseblock je Datei (in Klammern zweiter Leseversuch: aus dem Betriebssystem-Cache)

–250–350 Mbit/s

(980–1020 Mbit/s)109–110 Mbit/s

(1090–1170 Mbit/s)

TCP/IP-Übertragung vom Server zum Client mit dem Mess-Programm ttcp(ttcp -l1048576 -n100 -b262144)

–790–950 Mbit/s

(TCP/IP-Loopback)

560–670 Mbit/s(TCP/IP über

Gigabit-Ethernet)

3D-Rendering: OpenGL im„immediate mode“ (DocShow-VR)

380–420 Mbit/s – –

Client-Server-Streaming-Pipeline (DocShow-VR)

Maximale Framerate – 280–320 Mbit/s 324–326 Mbit/s

4 frames / Sekunde – 251 Mbit/s 251 Mbit/s

2 frames / Sekunde – 126 Mbit/s 126 Mbit/s

Tabelle 9. Ergebnisse der Messungen des lokalen und netzverteilten Durchsatzes (typische Werte) in einerlokalen (Client und Server auf einem Rechner, TCP/IP-Verbindung über Loopback-Interface) undin einer verteilten Konfiguration (Client und Server über Gigabit-Ethernet verbunden) im Szenario „Ozeanische Konvektion“ (Szenen Nr. 720–739, 165.353.764 byte)



Die wesentlichen Beobachtungen aus diesem Szenario werden im folgenden zusammengefasst:

• Der Durchsatz in der verteilten Konfiguration ist höher als im Fall der Ausführung von Clientund Server auf derselben Maschine. Die Ursachen hierfür sind:

– die geringere Taktrate auf der Client-Maschine(195 MHz gegenüber 225 MHz),

– der Overhead, der dadurch entsteht, dass auf einer Maschine 3 Prozesse bzw. Threadsgleichzeitig laufen und dabei um gemeinsame Betriebsmittel konkurrieren: der Serverpro-zess (Lesen von Datei, Senden über TCP/IP-Socket), der Clientprozess (im wesentlichenRendering) und ein Client-Thread, der den Empfang der 3D-Daten über einen TCP/IP-Socket durchführt.

• Die Dauerrate der Streaming-Pipeline ist deutlich geringer als die separat gemessene Renderin-grate. Sofern die abgerufenen Szenensequenzen klein genug sind, um im Cache des Betriebssys-tems gehalten zu werden (was hier der Fall war), stellt die Renderingrate in der vorliegendenKonfiguration jedoch den limitierenden Faktor dar. Die weitere Verringerung des Durchsatzeskann durch folgende Ursachen begründet werden:

– Im „Double-Buffer“-Betrieb des Graphiksystems entsteht nach der Fertigstellung jedes Bil-des durch Abwarten der Vertikal-Synchronisierung eine „Swap-Buffer“-Latenz. Diese ent-spricht maximal dem Kehrwert der Bildrate des Displaysystems:

. (8)

Im vorliegenden Fall mit 72 Hz Bildwiederholrate also:

. (9)

– Innerhalb der Plugin-Software signalisiert der Transport-Thread dem Hauptprozess jeweilsdie Beendigung der Übertragung einer Szene über eine Pipe. In X-Windows/Motif-Anwen-dungen, wie im hier verwendeten WWW-Browser Netscape Communicator, werden sämtli-che Ein-/Ausgabe-, Timer- und X-Windows-Events in einer zentralen Funktion aus dem X-Toolkit der X-Windows-Library XtAppMainLoop() behandelt. Diese dient als Dispatcherund arbeitet die auftretenden Events sequentiell durch den Aufruf anwendungsspezifischzur Laufzeit registrierter Callback-Routinen ab. Zur Auffrischung des Inhalts eines Fensterswird üblicherweise der Xlib-Aufruf XClearArea() verwendet, der zusätzlich noch einenRound-Trip-Vorgang über den X-Server nach sich zieht. Darüber hinaus wurde dafür einTimer verwendet, um der Anwendung die Gelegenheit zu geben, auf weitere Events reagie-ren zu können, z. B. von der Maus. Die Reaktionszeit bis zum Start des nächsten Rende-ringvorgangs liegt nach eigenen Messungen in der Größenordnung von 10–20 ms.

– Die Initialisierung des OpenGL-Status zu Beginn jedes Renderingvorgangs benötigt auchZeit, die allerdings im Vergleich zu den bislang diskutierten Einflüssen vernachlässigbar ist.

tSwapBuffer1

DisplayFrameRate---------------------------------------------≤

tSwapBuffer1

72------ s≤

Abb. 17. Zeitablauf der Einlese- und Renderingvorgänge im 3D-Streaming-Client mit 4 frames/s.Balken: Übertragung einer 3D-Szene (Lesen von TCP/IP-Socket), Röhren: Dual-Pipe-Rendering (OpenGL)

t [s]

Rendering Pipe 1Rendering Pipe 0

Transport: ankommende Daten

Datenvolumen [byte]der jeweiligen 3D-Szene

(Szenen-Nummern)

Zeitpunkte der jeweiligen

3D-Szene Nr. 720

relativ zum Beginn desEinlesevorgangs von

Rendering-Initialisierung,



In Abb. 17 ist der zeitliche Ablauf der auf Client-Seite auftretenden Aktivitäten veranschaulicht, auchum die korrekte Funktion der implementierten Modulen qualitativ zu demonstrieren. Dazu wurden dieZeitpunkte relevanter Ereignisse sowie Datenvolumina innerhalb der Client-Software gemessen undgespeichert. Diese Daten wurden nach Ablauf des Anwendungsszenarios auf Datei geschrieben.Schließlich wurden die Ergebnisdaten des Mess-Protokolls visualisiert.

Zunächst wurde der 3D-Streaming-Server durch den „Sequence“-Dialog der Nutzeroberfläche des„DocShow-VR“-Plugins veranlasst, die Szenen 720 bis 739 mit 4 Frames je Sekunde auszuspielen. Dadie verfügbare Datenrate höher ist als für diese Anforderung nötig, legt der Server zur Synchronisie-rung nach der Übertragung einer Szene jeweils eine Pause ein, um die Übertragung der nächsten Szenejeweils im vorgegebenen Zeitraster zu beginnen. Dies ist an dem unteren Balken, der die transportier-ten Datenpakete illustriert, zu erkennen. Der Client wurde hier im Dual-Pipe-Modus konfiguriert, d. h.die Szenen werden nicht nur im Hauptprozess des Plugins auf dem ersten Display gerendert, sondernzusätzlich wird in einem separaten Thread eine Aktualisierung des Bildes auf dem zweiten Displayvorgenommen. Dieser Parallelbetrieb wird mit den oben angeordneten Röhren dargestellt, die sichzeitlich wiederum mit dem Datentransport der nächsten Szene überlappen.

Kritisch anzumerken ist, dass die Synchronisierung derzeit nur grob erfolgt, da diese nur serverseitigbewirkt wird. Daher wirken sich Jitter der Kommunikationsstrecke sowie variable Renderingzeitenunmittelbar auf die aktuelle Update-Rate aus. Im Mittel wird die Rate jedoch eingehalten, da derBeginn der Ausspielung als Bezugspunkt dient und der Server gegebenenfalls auch Frames auslässt,wenn die Daten aufgrund der in TCP/IP integrierten Flusskontrolle nicht genügend schnell gesendetwerden können.

Zur Glättung wäre als weitere Maßnahme eine clientseitige Pufferung – eventuell in Kombination miteinem Regelungsmechanimus (siehe z. B. [10]) – vorteilhaft, die im Rahmen weiterer Forschungs-und Entwicklungsarbeiten hinzugefügt werden sollte.

4.2 AV-Streaming 39


4.2 AV-Streaming

4.2.1 Übersicht

Erprobung

Bei den durchgeführten Arbeiten wurde zunächst das Hauptaugenmerk auf den Kernpunkt, das AV-Streaming, gelegt. Hierzu wurde vorab eine umfangreiche Übersicht über die existierenden Produkteund deren Eigenschaften erstellt. Diese Zusammenstellung liefert einen ersten Überblick über die zuerreichende Darstellungsqualität.

Zu fast allen Produkten konnte die (frei erhältliche) Client-Software getestet werden, so dass auch soein Eindruck von den verschiedenen Produkten gewonnen werden konnte.

Aus der erstellten Übersicht wurden nach verschiedenen Kriterien vier Produkte ausgewählt, zu denenauch der AV-Streaming-Server installiert und erprobt wurde. Zu dieser Software wurden auch die ent-sprechenden Konvertierungs-Programme eingesetzt, um so eigenes Material zu erzeugen.

Hinzu kommt die Erprobung von Generierungsverfahren. Hier wurde die Konfiguration des Multime-dia-Labors des RRZN/RVS verwendet. Auf dieser Basis sind komplette Prozessketten vom Rohmate-rial bis zur Online-Präsentation entwickelt worden.

Die erprobte Software ist primär auf die Bearbeitung von realem Filmmaterial („Videoschnitt“) ausge-richtet, bietet jedoch zudem die Möglichkeit zur Einbindung von im Rechner erzeugten Bilddaten(etwa in Form von Einzelbildfolgen).

Speziell für die Produktion von künstlich (rechnergestützt) erzeugten Bildsequenzen sind auch andereVerfahren einsetzbar, so wie es bei der Videoverfilmung im RRZN/RVS der Fall ist.

Online-Dienste zur Generierung von AV-Daten

Exemplarisch wurde ein Online-Dienst zur Konvertierung von Audiodaten entwickelt, implementiertund getestet. Hiermit ist über ein HTML/CGI-Interface die Komprimierung von aiff- und wave-Dateien in die Formate mp2, mp3 und real realisiert worden. Die erzeugten Daten können als Dateiübertragen werden und sind über ein Streaming-System abrufbar.

In einem nächsten Schritt wurde ein ähnlich aufgebauter Online-Service zur Generierung von MPEG-1, QuickTime und AVI-Videos aus Einzelbildfolgen implementiert.

Dokumentation

Zur Generierung von AV- bzw. Multimedia-Daten wurden Informationen zusammengestellt, die demBenutzer die Anwendung entsprechender Hard- und Software vermitteln. Die hier vorgestelltenMethoden wurden in verschiedenen Exponaten unmittelbar zur Erzeugung von MM-Elementen einge-setzt.

Sämtliche Ergebnisse wurden als Exponate aufbereitet und auf dem DFN-Expo Web-Server integriert.

Im Bereich „AV-Werkstatt“ sind die zusammengestellten Richtlinien zur MM-Daten-Generierungabrufbar. Ergänzend wurden grundsätzliche Zusammenhänge in Schemata zusammengefasst underläutert.

Die Audio-Konvertierung wurde zusammen mit Informationen für den Benutzer ebenfalls auf demWeb-Server eingerichtet. Sowohl Web-Interface als auch die Bearbeitung der Daten erfolgt auf demDFN-Expo-Server.

4.2.2 Material

Im folgenden wird typisches Material für AV-Streaming-Anwendungen vorgestellt und grob klassifi-ziert. Prinzipiell kann jedes auf bekannten Medien (Hörfunk, Fernsehen, Bändern, CD, etc.) transpor-tierte Material auch beim AV-Streaming eingesetzt werden. Da die Randbedingung hier derzeit die vonkonventionellen Transportwegen bekannten Qualitätsanforderungen nicht erfüllen können, ist eineBetrachtung des benutzten Materials in Hinblick auf die Eignung für vorhandene Streaming-Systemenotwendig.



4.2.2.1 Video

Beim Ausgangs- oder Rohmaterial werden grundsätzlich zwei Quellen unterschieden.

• Künstlich, d. h. mit einem Rechner erzeugtes Material. Dieses liegt bereits in digital gespeicher-ter Form vor, etwa als Folge von Einzelbildern. Die Generierung dieser Daten erfolgt mit Visua-lisierungstools (z. B. AVS, Ensight, VTK), Animationsprogrammen (z. B. 3D Studio Max,Wavefront, SoftImage) oder auch mit DocShow-VR.Dieses Material stellt meist hohe Anforderungen an die Auflösung, weniger an die Farbtiefe(Anzahl der Farben).

• Reales Bildmaterial wird mit einer Videokamera aufgenommen. Das so aufgenommene Materialbefindet sich in der Regel auf einer Videokassette, und muss zur Bearbeitung in digitaler Formauf Festplatte übertragen werden. Wurde als Aufzeichnungsformat Digital Video verwendet, sokann dies 1:1 kopiert werden. Bei analogen Aufzeichnungsformaten ist an dieser Stelle die Digi-talisierung notwendig.Im Gegensatz zu künstlich generierten Bildern hat hier die Farbtiefe eine größere Bedeutung alsdie Pixel-Auflösung.

Die beiden Arten Quellmaterial stellen somit unterschiedliche Anforderungen an ein AV-Datenformat.Bei der Verwendung eines gemeinsamen Mediums sind daher in den meisten Fällen Kompromisse ein-zugehen.

Während im wissenschaftlichen Rahmen das künstlich erzeugte Material für Visualisierungszweckeeine große Rolle spielt, trifft man im kommerziellen Bereich hauptsächlich auf reales Bildmaterial.Reales Video gewinnt jedoch auch universitären Bereich zunehmend an Bedeutung, etwa bei derÜbertragung von Lehrveranstaltungen. Zudem werden häufig Vorgänge mit Standard-Videotechnik(Kameras, Mikroskope mit Videoaufsatz) dokumentiert.

4.2.2.2 Audio

Beim Audio-Material werden lediglich „reale“ Quellen betrachtet. Künstlich erzeugter Ton, etwadurch Musikbeschreibungssprachen definiert, soll an dieser Stelle außer acht gelassen werden.

Eine grundsätzliche Unterscheidung lässt sich jedoch zwischen Sprache und Musik treffen. Sprachestellt aufgrund des geringeren Frequenzumfangs geringere Anforderungen an das Übertragungsme-dium.

Für die Produktionskette ist jedoch von Bedeutung, ob die Daten auf analogen Tonträgers oder bereitsdigitalisiert vorliegen.

• Analoges Material, das mit Hilfe von Mikrofonen und analogem Band aufgenommen und imRechner digitalisiert wird. Dies können z. B. verbale Erläuterungen zu visuell dargestelltenInhalten sein, aber auch live aufgenommener Ton von „akustisch interessanten“ Exponaten.

• Digitales Material, das bereits auf CD (Audio-CD) oder DAT (Digital Audio Tape) vorliegt, z. B.als musikalische Untermalung einer Präsentation.

4.2.2.3 Live-AV

Eine weitere Unterscheidung, z. B. bei der Aufbereitung von Lehrverstaltungen, betrifft die Übertra-gung als Live-Datenstrom oder als Abruf des gespeicherten Materials.

Bei Live-Übertragungen ist vorrangig reales Bildmaterial von Bedeutung, etwa das Bild des Dozenten.

Parallel dazu besteht jedoch oft die Notwendigkeit, auch das – künstlich erzeugte – Tafelbild bzw. Pro-

Quelle Art Auflösung Bildrate Audio

Vortragender real gering hoch Sprache

Tafelbild künstlich hoch gering -ohne-

Tabelle 10. Typisches Vorlesungsszenario

4.2 AV-Streaming 41


jektionsbild zu übertragen. Insbesondere bei schmalbandiger Übertragung ist hier die Nutzung einesgemeinsamen Datenkanals problematisch. Hier bietet sich die Verwendung getrennter Übertragungs-wege an.

Diese und ähnliche Szenarien gewinnen im Kontext Tele-Education immer stärkere Bedeutung. Nebender Live-Übertragung lässt sich das parallel aufgezeichnete Material für den späteren Abruf konservie-ren, auf einem Streaming-Server zur Verfügung stellen und somit mehrfach und individuell nutzen.

4.2.3 AV-Formate

Bei der Auswahl geeigneter Formate für Audio- und Videodaten ist grundsätzlich zwischen Produk-tion und Publikation zu unterscheiden. Nicht zuletzt, weil Publikationsformen gemäß der technischenEntwicklung einem ständigen Wandel unterliegen, ist die Produktion des Materials auf einem mög-lichst hohen Qualitätsniveau sinnvoll.

4.2.3.1 Produktion

Als Referenz für die Video-Produktion wird der aktuelle TV-Standard herangezogen. Das europäischePAL-System besitzt nach ITU-R-601 eine Auflösung von 720*576 Pixeln mit 25 Bildern pro Sekunde.Bei einer Kodierung mit 16 bit je Pixel ergibt sich damit eine Datenrate von 166 Mbit/s, was oft alsStudio- oder Sende-Standard bezeichnet wird. Zum Teil verwendet man eine 24 bit-Kodierung, wor-aus eine Datenrate von 249 Mbit/s folgt.

Eine Vielzahl von analogen und digitalen Geräten basiert auf diesem Verfahren, so dass bei der Her-stellung auf eine große Palette von Standardgeräten zurückgegriffen werden kann. Dabei ist zu beach-ten, dass nicht jedes Gerät die oben genannte Auflösung erreicht. So beträgt bei z. B. bei VHS-Recordern die horizontale Auflösung nur etwa 220 Zeilen.

Für den Bereich Audio kann man den auf CDs verwendeten Standard als Vergleich anführen. ZweiStereokanäle werden mit 44100 Hz Samplingrate und 16 bit Auflösung abgetastet und ergeben damiteine Datenrate von 1,4 Mbit/s. Bei der Aufzeichnung auf DAT (Digital Audio Tape) steht optionalauch eine Abtastrate von 48 kHz zur Verfügung.

Empfehlungen

In der Praxis hat sich im Videobereich DV (Digital Video) bewährt, da es trotz verlustbehafteter Kom-pression eine gute Bildqualität liefert, die dem Sendestandard sehr nahe kommt. Zwar findet bei derAufnahme mit dem Standard-DV Verfahren eine Datenreduktion des Videosignals auf 25 Mbit/s statt,die jedoch für die meisten Anwendungen akzeptabel ist. Die Kodierung stellt einen guten Kompromisszwischen Qualität und Speicherbedarf dar. Auch die parallel stattfindende unkomprimierte Audio-Aufzeichnung liefert eine sehr gute Qualität.

DV-Hardware eignet sich zudem gut für den Produktionseinsatz, da das zugrunde liegende Format ver-lustfrei weiterbearbeitet werden kann. Das Material kann verlustfrei von DV-Tape auf rechnerbasierteSchnittsysteme übertragen werden.

Wenn die komplette Bearbeitung auf DV-Niveau durchgeführt wird, ist eine Speicherung auf DV-Kas-sette und eine spätere Neukonvertierung für kommende Streaming-Datenformate leicht realisierbar.

Für (Nur-)Audio-Aufnahmen ist die Verwendung von DAT-Recordern optimal, da hier im Gegensatzzu anderen digitalen Verfahren (etwa MiniDisc mit einer Datenreduktion von 1:5) ohne Kompressiongearbeitet wird. Analoge Audio-Aufnahmetechnik ist weitgehend vom Markt verschwunden.

Gerade bei stationärer Anwendung ist mit einem Rechner auch die direkte Aufzeichnung auf Fest-platte möglich. Hier können jedoch Störungen entstehen, die von der Interferenz der Sound-Karte mitder übrigen Rechner-Hardware hervorgerufen werden. Bei Mikrofonaufnahmen kommen störendeGeräusche durch Lüfter oder Festplatten hinzu.

Audiodaten stellen heute selbst im unkomprimierten CD-Format (raw, wav o. ä.) keine Kapazitätspro-bleme dar, so dass sich hier eine Archivierung, z. B. auf Audio-CD anbietet.



4.2.3.2 Publikation

Zur Publikation mittels AV-Streaming ist das Material in ein Format zu konvertieren, das von dem ein-gesetzten Streaming-System verarbeitet werden kann. Das Produktionsdatenformat muss dabei oftstark komprimiert werden, um die geforderten Randbedingungen, wie z. B. die Netzwerkanbindungdes Clients, zu erfüllen.

Mit Ausnahme der Netzwerkaspekte gilt gleiches auch entsprechend für die – oft parallel zum Strea-ming genutzte – Publikation auf Datenträgern wie CD-ROM, VideoCD, DVD.

In jedem Fall kommt bei den Publikationsdatenformaten neben dem darzustellenden Inhalt dieBetrachtung der Zielgruppe hinzu. Zu den technischen Aspekten Netzwerkanbindung und Perfor-mance des Client-Systems ist weiterhin im Einzelfall zu entscheiden, ob die technisch realisierbareDarstellungsqualität vom potenziellen Betrachter akzeptiert wird. Weiterhin ist es der Akzeptanz för-derlich, wenn der Benutzer zum Abruf der AV-Daten nicht zunächst ein Programm (Plugin, Viewer)auf seinem System installieren muss.

Beobachtet man die Entwicklung der Publikationssysteme, so stellt man insbesondere beim Streamingeinen schnelleren Wandel als bei den Produktionssystemen fest. Schnellere Netzwerke und steigendePerformance (insbesondere der Client-Systeme) führen zu einer stetigen Qualitätssteigung. Dement-sprechend verändern sich auch die eingesetzen Datenformate, so dass zuvor produziertes Material inneue Formate konvertiert werden muss.

Empfehlungen

Aufgrund des letztgenannten Zusammenhangs lassen sich keine langfristigen Empfehlungen fürPublikationsdatenformate aussprechen, jede Empfehlung kann sich nur auf die aktuelle Situationbeziehen. Da das Datenformat in der Regel durch das zur Publikation verwendete Streaming-Systemvorgegeben wird, sind beide Aspekte gemeinsam zu betrachten. Grundsätzlich sollten folgende Punkteberücksichtigt werden.

• Verbreitetes System (Software ist beim Benutzer installiert).

• Format sollte auf möglichst vielen Rechner-Plattformen abspielbar sein.

• Um eine große Zielgruppe zu erreichen, können mehrere Versionen eines AV-Clips (etwa fürunterschiedliche Netzwerkanbindungen) nötig sein.

Weitere Kriterien bzw. Empfehlungen befinden sich im Abschnitt „Streaming-Systeme“.

Formate für die Audio-Publikation lassen sich gemäß ihrer Anwendung grob in zwei Kategorien ein-ordnen. In der einen Gruppe finden sich Verfahren, mit denen Musik in CD oder CD-ähnlicher Quali-tät reproduzierbar ist, die andere Gruppe bilden Verfahren für die möglichst hohe Kompression vonSprache.

Bei der Verwendung für Musik in „CD-Qualität“ aber auch für die qualitativ hochwertige Sprachwie-dergabe hat derzeit das MPEG-Verfahren die größte Bedeutung. Ursprünglich als Kompressionsver-fahren für Audiodaten in MPEG-1-Videos („Audio-Layer“) entwickelt, wird es zunehmend auch fürreine Audio-Daten verwendet. Gemäß der Layer-Bezeichnung 1 bis 3 werden MPEG-kodierte Audio-daten als mp2 bzw. mp3 bezeichnet. Layer 1 wird gegenüber der stärker komprimierenden Layer 2 undinsbesondere Layer 3 kaum verwendet

Weitere, hier nicht betrachtete Formate für den kommerziellen Einsatz berücksichtigen zudem Copy-right-Aspekte (Liquid Audio, WMA) und sind lediglich auf MS Windows-Plattformen implementiert.

4.2.3.3 Speicherbedarf/Datenraten

Die Datenraten von AV-Datenformate haben unmittelbaren Einfluss auf zwei Parameter: Zum einendefinieren sie die erforderliche Bitrate für einen Datenübertragungskanal zwischen Server und Clientbeim Streaming, zum anderen wird hierdurch die für das Material benötigte Platten-Kapazität auf demServer bestimmt.

4.2 AV-Streaming 43


Insbesondere qualitativ hochwertige Video-Produktionsdatenformate erfordern große Speicherkapazi-täten, weshalb sie meist nur zur Bearbeitung auf dem entsprechenden System abgelegt werden. Für dieArchivierung eignen sich Video-Kassetten, wobei mit DV hiermit keine Verluste auftreten.

Zum aus der Bitrate rechnerisch ermittelten Speicherbedarf kommen bei einigen Streaming-Formatennoch Metainformationen hinzu. Diese werden z. B. für die schnelle Navigation beim Streaminggenutzt. Die Zusatzinformationen werden bei entweder in externen Dateien abgelegt (ScenVCR) odersind in der AV-Datei enthalten (Real). SGI MediaBase legt ebenfalls in weiteren Dateien Informatio-nen an, wobei die von MediaBase kopierte oder konvertierte AV-Datei selbst als solche im Dateisys-tem nicht mehr erkennbar ist.

4.2.4 Generierungsverfahren

Neben der Erprobung und dem Einsatz von AV-Generierungsverfahren für projektinterne Exponatewurden Richtlinien aufgestellt, die die erprobten Verfahren dokumentieren. Erprobung und Dokumen-tation stellten einen gleichzeitig ablaufenden Prozess dar, in dessen Vordergrund die Dokumentationauf unterschiedlichen Abstraktionsebenen stand.

Hier wurden daher zum einen im AV-Streaming-Bereich Schemata dargestellt, welche die zugrundlie-genden Prozessketten verdeutlichen, und zum anderen die AV-Werkstatt eingerichtet, die zu den einzel-nen Arbeitsschritten konkrete Hinweise liefert. In einem weiteren Konkretisierungsgrad wird dieAudio-/Video-Arbeitsumgebung im MultiMedia-Labor des RRZN/RVS beschrieben.

4.2.4.1 Erstellung von Richtlinien zur Generierung von AV-Daten

Ziel dieses Projektteils ist es, dem (potenziellen und aktiven) Anwender Möglichkeiten und Wege zurGenerierung von Multimediadaten von der Aufnahme bis zur Publikation vorzustellen. Dabei sollensowohl die grundsätzlichen Verfahren verdeutlicht werden, als auch Hinweise zur konkreten Erstel-lung gegeben werden.

Für die Herstellung von Multimedia-Daten wie Audio und Video lässt sich eine allgemeine Prozess-kette definieren.

An erster Stelle steht das Erstellen des Materials, etwa die Tonaufnahme auf Band, das Filmen oderFotografieren der realen Umwelt. Dieses Material muss nun zur Weiterverarbeitung auf einen Rechnertransferiert werden, Eingelesen werden. An dieser Stelle wird es spätestens digitalisiert. Es folgt dieBearbeitung der nun auf Festplatte vorliegenden Daten, z. B. die Nachbearbeitung von Ton und Bild,

Standard Format fps Bitrate Kapazität/min Kapazität/h A/V

ITU-R-601 720*576, 16 bit 25 166 Mbit/s 1186 Mbytes 69,5 Gbytes V

DV-Video 720*576 25 25 Mbit/s 179 Mbytes 10,5 Gbytes V

MPEG-1 352 *288 25 1,4 Mbit/s 10 Mbytes 606 Mbytes A+V

Real (lo) 160*120 <15 20 kbit/s 146,5 Kbytes 8,58 Mbytes A+V

Real (hi) 320*240 <15 220 kbit/s 1,57 Mbytes 94,4 Mbytes A+V

Audio-CD 44,1 kHz, 16 bit, Stereo - 1,4 Mbit/s 10 Mbytes 606 Mbytes A

mp2 44,1 Stereo - 384 kbit/s 2,75 Mbytes 165 Mbytes A

mp3 44,1 Stereo - 128 kbit/s 937,5 Kbytes 54,9 Mbytes A

Tabelle 11. Speicherbedarf verschiedener AV-Formate

Abb. 18. AV-Herstellungs-Prozesskette



das Zusammenstellen des Materials. Die fertiggestellte Präsentation, etwa ein Videofilm, wirdanschließend konvertiert, um damit ein Datenformat zu erhalten, das zur Publikation geeignet ist.Neben der Speicherung auf Medien wie CD-ROMs steht hier natürlich das Streaming im Vordergrund.

4.2.4.2 Schemata, Verfahren, Prozessketten

Beschreibung allgemeiner Verfahren zur Audio- und Video-Produktion und AV-Streaming

Unter den URLs http://www.dfn-expo.de/Technologie/Video-Produktion/ sowie http://www.dfn-expo.de/Technologie/Audio-Produktion/ findet man zwei Schemata, in denen die Abläufe der Audio-und Videoerzeugung erklärt werden. Ein weiteres Schema beschreibt ein AV-Streaming-System.

Die Abläufe der Prozessketten (bei der AV-Generierung sind es die Arbeitsschritte, beim Streamingdie Vorgänge auf Server und Client-Rechner) werden jeweils in einer Grafik illustriert. Klickt derBetrachter auf eines der Elemente im Schema, so erhält er in einem zusätzlichen Fenster weitere Infor-mationen zu dem gewählten Objekt. Auf diese Weise lässt sich der gesamte Ablauf übersichtlich dar-stellen; detaillierte Informationen können interaktiv abgerufen werden.

4.2.4.3 Erprobung

Die Erstellung des Materials ist individuell verschieden, wobei im Abschn. 4.2.3 einige Methoden vor-geschlagen wurden. Die Punkte Konvertierung und Publikation werden im Abschn. 4.2.5 näherbetrachtet. Dazwischen befinden sich die Arbeitsschritte Einlesen und Bearbeitung, die im folgendenexemplarisch kurz skizziert werden.

Einlesen und Bearbeitung

Vor einer Bearbeitung (Post-Production, Schnitt) besteht der erste Schritt darin, das produzierte Mate-rial auf ein entsprechendes System zu transferieren. Für Audio und Video werden jeweils primär Wegebetrachtet, die bei digitalen Datenträgern beginnen. Bei Video (und Audio) gilt dies für DV, bei Audiofür DAT und Audio-CD. Bei analogen Systemen ist die Digitalisierung während des Einlesens mittelsentsprechenden Hardware (Soundkarte, Videokarte) möglich.

Abb. 19. Schema: Video-Produktion

4.2 AV-Streaming 45


Um AV-Material zu bearbeiten, ist eine Reihe von Software erhältlich. In den meisten Fällen handeltes sich hierbei um Programme, die interaktiv mittels grafischer Benutzeroberfläche bedient werden.

Video

Zum Einlesen der Videodaten vom DV-Band gibt es mehrere Hardwarelösungen für PC und AppleMacIntosh, die den Rechner um eine IEEE 1394 (auch Firewire oder I-Link genannte) Schnittstelleerweitern. Neben der AV-Datenübertragung erfolgt auch die Steuerung des zuspielenden bzw. aufneh-menden Recorders über diese Verbindung. Das Überspielen wird entweder durch proprietäre Softwareoder direkt aus dem Post-Production-Programm gesteuert.

Hier kam als Hardware FAST DV Master und als Software Adobe Premiere auf einem Pentium/Win-dows-PC zum Einsatz. Mit Premiere ist eine umfangreiche Bild- und Tonbearbeitung möglich. Nebender eigentlichen Nachbearbeitung können bei der Ausgabe auch Skalierungen der Bildgröße und Fra-merate vorgenommen werden, so dass auch simple Formatkonvertierungen durchführbar sind. Nebeneiner Vielzahl von Effekten (Überblendungen) und Bildmanipulationen sind auch die für wissen-schaftliche Anwendungen oft wichtigere Funktionen wie etwa der Import von Einzelbildfolgen enthal-ten.

Als Endprodukt erhält man eine Datei im AVI-Format. AVI dient dabei lediglich als Containerformatfür eine Reihe verschiedener Codecs (bis hin zum DV-Format).

Audio

Titel von Audio-CDs lassen sich unter dem Betriebssystem IRIX mit Hilfe des mitgelieferten Pro-gramms CD-Player als AIFF-Datei in CD-Qualität mit 44,1 kHz Abtastrate und 16 Bit Auflösungspeichern. Für andere Betriebssysteme existieren weitere, ähnliche Programme („CD-Ripper“), die dieSpeicherung von Audio-CD-Tracks als AIFF, WAV oder PCM-Datei erlauben, z. B. cdda odercdda2wav. Diese Audio-Dateien sind unkomprimiert und erfordern etwa 10 MByte pro Minute Spiel-dauer. Alle diese Formate können z. B. mit MPEG-Encodern komprimiert werden.

Auch vom DAT lassen sich Tracks als Audio-Dateien speichern. Unter IRIX geschieht dies mit demProgramm datman, einem X11-Programm oder kommandozeilenorientiert mit dodat. Auch hier erhältman unkomprimierte AIFF-Dateien.

Beispiele

Die vorgestellten Arbeitsschritte wurden in einigen Exponaten angewendet:

• Otto-von-Guericke Universität: Virtuelle Bronchoskopie

• Institut für Verfahrenstechnik: Tomographie

• Institut für Kartographie: Überflutungssimulation

Die dabei gewonnenen Erfahrungen sind wiederum in die Seiten der AV-Werkstatt eingeflossen.

4.2.4.4 AV-Werkstatt

Die AV-Werkstatt beschäftigt sich mit der konkreten Erstellung von AV-Daten. Hier werden die erfor-derlichen Geräte und Programme beispielhaft vorgestellt und Hinweise zu dessen Handhabung gege-ben. Auch das auf den Exponatsseiten zu findendende Multimediamaterial wurde mit den hiervorgestellten Verfahren erzeugt.

Zur Präsentation der AV-Werkstatt-Seiten wurden die Arbeitsschritte in die fünf Abschnitte Erstellen,Einlesen, Bearbeiten, Konvertieren und Publizieren eingeteilt.

Aufgeteilt in die Bereiche Audio, Video und Allgemeines findet der Benutzer in einem Menü auf derlinken Seite die behandelten Themen. Über die drei Drop-Down-Menüs gelangt er zur entsprechendenBeschreibung. Zur Orientierung wird hier in der Bearbeitungskette der aktuelle Standpunkt farbiggekennzeichnet. Außerdem finden sich hier allgemeine Informationen, z. B. zum Thema DV (DigitalVideo), die nicht direkt in der Bearbeitungskette zu finden sind.



Die folgenden Themen sind enthalten:

• Audio: Aufnahme, CDs digital einlesen, DAT digital einlesen, Audio-Aufnahme auf DAT, Enco-der, Speicherbedarf

• Video: DV-Format, DV-Karten, Filmen (DV-Camcorder), Schnitt, Speicherbedarf, Verfilmungwissenschaftlicher Daten

• Allgemeines: Übersicht, Konvertierung, Streaming

Hinzu kommen zwei exemplarische Beispiel-„Fahrpläne“ für die Publikation von Audio und Video-Material, die den Nutzer durch die Webseiten führen.

Der Aufbau der Webseiten ist so gestaltet, dass eine Erweiterung jederzeit problemlos möglich ist.Nach dem Einfügen einer neuen Seite wird das Inhaltsverzeichnis mit Hilfe eines Shell-Skripts aktua-lisiert; Bereich und Überschrift werden aus dem Dateinamen bzw. der Datei extrahiert. Eine genaueBeschreibung ist unter http://www.dfn-expo.de/Technologie/AV-Werkstatt/readme.txt zu finden.

Neben Soft- und Hardware, die unmittelbar im Audio- und Video-Kontext stehen, sind oft weitereHilfsmittel notwendig, die im weiteren Umfeld „Multimedia“ stehen. Diese Geräte sind auf den Seitendes Multimedia-Labors beschrieben. Hier befinden sich z. B. Erläuterungen zu einer digitalen Fotoka-mera, etwa für die Herstellung von QuickTime-VR-Daten, zum Scannen, zur CD-ROM-Herstellungusw.

4.2.4.5 MultiMedia-Labor

Während sich im AV-Werkstatt-Bereich weitgehend allgemeine, produktunabhängige Beschreibungenfinden, behandelt das MultiMedia-Labor (MML) des RRZN/RVS die praktische Anwendung anhandkonkreter Hard- und Software.

Die zuvor beschriebenen Vorgehensweisen werden im Zusammenhang mit den vorgestellten Hilfsmit-teln detailliert, so dass der Benutzer zum Teil in die Lage versetzt wird, eigene Projekte zu realisieren.

Abb. 20. dfn-expo: Audio & Video Werkstatt

4.2 AV-Streaming 47


Es zeigt sich jedoch, dass in komplexere Systeme – etwa zum Videoschnitt – längere Einarbeitungszei-ten notwendig sind. An dieser Stelle wird der Benutzer mit Tipps zu oft auftretenden Problemen unter-stützt.

Während der Projektlaufzeit hat sich das Multimedia-Labor am RRZN/RVS zu einer häufig genutztenEinrichtung entwickelt. Diverse Institute konnten in verschiedenen Projekten beraten werden oder mitder Nutzung von Geräten und Software unterstützt werden. Praktische Erfahrungen aus dem MMLsind direkt in das DFN-Expo-Projekt eingeflossen, während in der DFN-Expo gewonnenen Erkennt-nisse im MML genutzt wurden.

Das MultiMedia-Labor ist unter http://www.rrzn.uni-hannover.de/mml/ öffentlich zugänglich.

4.2.5 AV-Streaming-Systeme

AV-Streaming-Verfahren ermöglichen das interaktive Abrufen von Audio- und Videodaten im Netzohne die Notwendigkeit eines kompletten Datei-Downloads (Burst-Übertragung).

Hierzu wurden teils im universitären, teils im kommerziellen Rahmen verschiedene Systeme entwi-ckelt und implementiert, deren wesentliche Eigenschaften zusammengetragen wurden.

Zum AV-Streaming wurde nach zunächst aufgestellten Kriterien eine Markt-Übersicht der verfügbarenSysteme zusammengestellt, die während des Projekts laufend gepflegt wurde. Einige Systeme (SCen-VCR, Vosaic, Mediabase, Xing, Real) wurden nach den gefundenen Kriterien ausgewählt und erprobt.

Zur Nutzung der AV-Streaming-Systeme wurden die Mechanismen zur Erzeugung von AV-Materialbeschrieben und erprobt. Neben der Zusammenstellung der verfügbaren Konvertierungs-Software galtdies auch der Entwicklung von Online-Diensten, die dem Benutzer eine einfache Nutzung von Strea-ming ermöglicht.

4.2.5.1 Kriterien

In der folgenden Tabelle sind die Kriterien für Streaming-Systeme zusammengestellt und erläutert.Die aufgeführten Punkte bildeten die Grundlage für die Recherche zu den verfügbaren AV-Streaming-Systemen.

Zu den verschiedenen Produkten wurden außerdem die Kosten für die erforderliche Software (Server,Client, Konverter) aufgeführt.

Abb. 21. RRZN/RVS: MultiMedia-Labor, Beispiel: Audio



4.2.5.2 Systeme: Client- und Server-Software

Während der Projektlaufzeit ist eine Reihe von Produkten entstanden, die zum Teil schon wieder vomMarkt verschwunden sind. Die Aufstellung der Systeme befindet unter http://www.dfn-expo.de/Tech-nologie/Streaming/. Darin sind die Angaben aus der oben aufgeführten Tabelle – soweit recherchierbar– zusammengetragen.

Die in den Systemen eingesetzten Verfahren (AV-Kompression, Transportprotokolle, Regelungsme-chanismen) sind oft ähnlich oder identisch. Sämtliche Verfahren sind für eine Einbindung der AV-Inhalte in Web-Seiten ausgelegt. Audio- und/oder Video-Elemente können somit direkt in HTML-Sei-ten eingebunden sein oder via Link referenziert werden. Zur Realisierung ist neben dem entsprechen-den Server beim Anbieter beim Nutzer ein passender Viewer zur Wiedergabe der Daten notwendig.Dieser wird vom Web-Browser als eigenständiges Programm („Helper-Application“) bzw. PlugIngestartet. Diese Integration in Webseiten ist bei allen Systemen obligatorisch.

Demgegenüber existieren Unterschiede bei den Dateiformaten, Datenraten und damit der erreichbarenDarstellungsqualität, aber auch der benötigten Speicherkapazität auf dem Server. Letztlich ist auch dieImplementierung des Regelungsmechanismus zur Adaption des Playouts an die aktuelle Netzwerkaus-lastung und die Performance des Client-Systems für die Qualität entscheidend.

Tendenziell sind die vorgestellten Produkte in erster Linie für die Verwendung mit Modem- oderISDN-Verbindungen und damit vergleichsweise niedrige Bitraten ausgelegt. Auch sind die genutztenCodecs (wie MPEG-1) meist für natürliches, reales Bildmaterial ausgelegt. In künstlich erzeugten,wissenschaftlichen Daten oft auftauchende scharfe Konturen können daher zu Artefakten führen.

Kriterium Erläuterung

Video-/Audio-Fähigkeit

Welche Arten von Daten können mit dem System übertragen werden?

Dateiformate für Audio- undVideodaten

Neben dem Einfluss auf die Darstellungsqualität und die erforderlichen Speicherkapazitäten auf Serverseite ist hier relevant, welche Werkzeuge zur Erzeugung der Daten genutzt werden können.

Plattform-Unterstüt-zung für Server undClient (Player)

Das System sollte, insbesondere auf Seite des Clients, möglichst viele Plattformen (UNIX, Windows, Mac) unterstützen.

Inline-Plugin? Ein Plugin ermöglicht die direkte Einbindung in HTML-Seiten und bietet damit weitergehende Gestaltungsmöglichkeiten als eine „Helper Applica-tion“. Oft werden beide Varianten angeboten.

Transportprotokoll(e) Protokolle wie UDP und RTSP ermöglichen effektiven AV-Datentrans-port. Einige Systeme verwenden alternativ TCP, um auch die Übertragung auf Systeme hinter Firewalls zu realisieren. Ferner kann eine Bandbreiten-reservierung (vgl. ATM, RSVP) von Bedeutung sein.

Maximale Qualität, dabei erforderliche Bitrate

Die Begrenzung der Darstellungsqualität ist meist durch das hochwer-tigste, vom System unterstützte Datenformat gegeben.

Minimale Bitrate, dabei erzielteQualität

Die kleinste Bitrate, bei der eine Übertragung überhaupt möglich ist.Oft ist diese durch den verwendeten Übertragungskanal gegeben(z. B. Modemverbindung).

Tabelle 12. Kriterien für AV-Streaming-Systeme

4.2 AV-Streaming 49


Als wichtiges Kriterium stellt sich auch die Verfügbarkeit von Server- und Client-Software für unter-schiedliche Plattformen dar. So unterstützen viele Systeme mindestens einen MS Windows- und Mac-Client, während Implementierungen für UNIX-Plattformen teilweise nicht erhältlich sind.

Bei der Implementierung der Client-Systeme kann zwischen eigenständigen Applikationen und Web-Browser-Plugins unterschieden werden, in einigen Fällen werden beide Varianten angeboten, d. h. derAV-Browser fungiert sowohl als Helper-Application als auch als Plugin. Die Verwendung als Pluginbietet insbesondere Vorteile bei der Gestaltung von Webseiten; die AV-Elemente können damit an defi-nierten Stellen positioniert werden und teilweise ist auch eine Steuerung über das HTML-Dokumentmöglich.

Für die Erprobung von AV-Streaming wurden vier Systeme ausgewählt und installiert.

• VirtualVCR („virtueller Videorecorder“) ist ein frei verfügbares System, das am Oregon Gradu-ate Institute of Science and Technology entwickelt wurde und ausschließlich unter UNIX imple-mentiert ist. MPEG-1-Video und Sun Audio (in separaten Dateien) werden als AV-Formategenutzt. VirtualVCR ermöglicht aufgrund eines Framedirectorys einen schnellen nichtlinearenZugriff. Implementierungen für Nicht-UNIX-Systeme sind nicht erhältlich.

• Xing Streamworks nutzt das MPEG-1-Format (Audio/Video/Systems) und unterstützt auf Ser-ver- und Client-Seite eine Vielzahl von Plattformen. Mit dem System war eine gute Wiedergabeauf UNIX-Rechnern und PCs erreichbar, unter UNIX allerdings nur mit 8 bit Farbtiefe.

• RealNetworks (ehemals Progressive Networks, RealAudio) unterstützt ebenfalls diverse Plattfor-men und weist eine hohe Verbreitung auf, nutzt jedoch für AV-Daten ein proprietäres Format undist primär für niedrige Bitraten, typischerweise unter 100 kbit/s, ausgelegt. Der RealPlayer istauch als Inline-Plugin verwendbar; Videos lassen sich so individuell in Web-Seiten einbinden.

• SGI Mediabase ist serverseitig auf Silicon-Graphics-Rechner ausgelegt und wird als Hochleis-tungssystem angeboten, das hohe Anforderungen an den einzusetzenden Server stellt. Client-Software, teils von Drittanbietern wie CompCore und Xing, liegen für alle gängigen Plattformenvor. Außer MPEG-1 und -2 wird, speziell für geringere Bandbreiten, das RealMedia-Formatsowie H.263 Video/G.723 Audio unterstützt, wobei MPEG-2 Hardwareunterstützung beim Cli-ent-Rechner erfordert. Weiterhin können bereits installierte Videos zu „Clips“ zusammengestelltwerden. Neben dem primären Streamingfunktionen sind in dem Paket auch umfangreiche Admi-nistrationswerkzeuge, eine Datenbank für die Metadaten zu den AV-Beiträgen sowie ein Web-Userinterface enthalten. Mediabase ist primär für die Anwendung im LAN konzipiert.

Soweit die vorliegenden Dokumentationen Einblick in die Implementierungen ermöglichen, verwen-den die Streaming-Systeme UDP, RTP, RTSP oder darauf basierende Verfahren. Alternativ wird meistTCP/IP unterstützt, um Systeme hinter entsprechenden Firewalls zu erreichen.

Für die kommerziellen Systeme sind Testversionen erhältlich, in denen die Anzahl der parallel abruf-baren Beiträge begrenzt ist. Die Software zum Abspielen der Daten ist für alle Systeme frei erhältlich.RealNetworks bietet für $30 eine erweiterte Plus-Version (mit verbesserter Qualität für Modemnutzer,Aufnahmemöglichkeit, Support u. a.) ihres RealPlayers an.

Es zeigte sich, dass die vorliegenden Portierungen der Client-Software unterschiedliche Qualität auf-wiesen. So liefert etwa die PC-Implementierung des RealPlayers eine wesentlich bessere Performanceals die UNIX-Portierung. Demgegenüber ist die Wiedergabe des SGI-Mediabase-Player auf einer SGIflüssiger als auf dem PC. Hinzu kommt der unterschiedliche Entwicklungsstand der Portierungen. Soexistiert bereits der RealPlayer für Windows in der Version 7, während für die UNIX-Versionen ledig-lich die Version 5 erhältlich ist.

Weiterhin wurde deutlich, dass die Darstellungsqualität stark von den Implementierung des Video-players abhängig ist. Als Beispiel sei hier der RealPlayer angefügt. Während sämtliche Daten über dasNetzwerk übertragen wurden, war der Player nicht in der Lage, das Video darzustellen; es erschienlediglich das erste Bild, alle folgenden wurden aufgrund „mangelnder Systemperformance“ über-sprungen. Der gleiche Effekt ergab sich bei lokaler Wiedergabe.

Die Empfehlung für ein System ist daher nicht ohne weiteres möglich, da die erreichbare Perfor-mance, insbesondere auf Seite des Clients, systemspezifisch stark schwankt.



Da drei der vorliegenden Systeme mit dem MPEG-1-Format arbeiten, ist es möglich, die Server aufdieselbe Datei zugreifen zu lassen. Hierbei sind jedoch einige Einschränkungen zu beachten. Der Vir-tualVCR kann keine MPEG-1-System-Streams (d. h. multiplexed Audio/Video) verarbeiten, Xing-Streamworks keine MPEGs mit variabler Bitrate. MediaBase legt grundsätzlich Kopien der Dateien ineinem eigenen Filesystem ab.

Empfehlung

Aufgrund der großen Verbreitung der Real-Software kann man momentan von einem de-facto-Stan-dard sprechen. Viele große Anbieter von AV-Material verwenden Real, so ist z. B. die ARD Tages-schau von VDOlive auf Real umgestiegen. Auch bietet eine Reihe von Rundfunksendern wie dieDeutsche Welle ein Programm via Real Streaming an.

Dementsprechend groß ist auch die Verbreitung der Client-Software, so ist der RealPlayer auch. imInstallationspaket des Netscape-Browsers enthalten. Das NetShow-System von Microsoft gewinntzwar langsam auch an Verbreitung, ist allerdings nur eingeschränkt einsetzbar, da die Software nur fürMS-Windows-Systeme verfügbar ist.

Das große Manko für den Einsatz in wissenschaftlichen Anwendungen ist die Begrenzung der Bitrateauf maximal 1024 kbit/s. Selbst wenn im Intranet oder B-WiN die Kapazität für breitbandige Übertra-gung bereitstehen, stehen keine entsprechenden Codecs zur Verfügung. Real ist wie andere kommerzi-elle Internet-Streaming-Systeme primär für die Benutzung über Modem und ISDN ausgelegt.

Für hochqualitatives Video sind derzeit keine Softwarelösungen erhältlich, verfügbare Systeme basie-ren auf Spezialhardware, so dass eine Verwendung stets eine Insellösung ohne Interoperabilität mitanderen Systemen darstellt. Möglicherweise wird es für existierende Systeme wie Real Erweiterungenfür höhere Bitraten und damit für bessere AV-Qualität geben.

4.2.5.3 Konvertier-Software

Die Konvertier-Software dient der Erzeugung von für die Übertragung mit einem Streaming-Servergeeigneten Dateien. Als Eingangsmaterial werden die von der Schnittsoftware gelieferten AV-Datenverwendet.

Abhängig vom Streaming-Verfahren kann im Bereich dieser Software zwischen zwei Varianten unter-schieden werden.

• Proprietäre Software, die direkt auf den eingesetzten Streaming-Server abgestimmt ist. Da einigeStreaming-Systeme (wie etwa RealMedia) eigene AV-Dateiformate verarbeiten, wird hier diebenötigte Konvertierungs-Software meist zum Server mitgeliefert.

• Standard-Encoder. Einige Streaming-Produkte arbeiten mit Standard-AV-Formaten wie MPEG-1. In diesem Fall können diverse Konverter genutzt werden, wobei eventuelle Randbedingungendes AV-Servers berücksichtigt werden müssen; so benötigt etwa der Xing-Streamworks-ServerMPEG-Daten mit konstanter Bitrate.

Die Konverter liegen z. T. als Export-Plugin für Schnittsoftware vor. Damit ist z. B. die Ausgabe vonRealMedia-Daten direkt aus Adobe Premiere möglich.

Audio

Die Erzeugung von MPEG-Audio-Dateien aus unkomprimierten Audio-Dateien im AIFF-, WAV- oderRAW-PCM-Format erfolgt mit entsprechenden Encodern. Neben Programmen für die Herstellung vonMPEG-AV-Dateien (die ebenfalls einen Audio-Layer erzeugen) gibt es verschiedene auf Audio spezi-alisierte Programme. Für die verschiedenen MPEG-Layer existieren i. d. R. separate Encoder, einigeunterstützen mehrere Layer. Drei Encoder wurden eingesetzt und erprobt:

4.2 AV-Streaming 51


• musicin von der MPEG-Gruppe der ISO, ein Encoder für Layer 1 und 2, der AIFF-und RAW-PCM-Dateien verarbeitet.

• l3enc vom Fraunhofer Institut für integrierte Schaltungen, ein Encoder für Layer 3, der alle dreiFormate verarbeitet. Dieser Encoder gilt als Referenz-Encoder für mp3. Er kostet in einer einge-schränkten Version $ 50, der Preis für die Vollversion beträgt $ 200.

• MediaConvert von SGI, ein Tool, das die Konvertierung zwischen den verschiedensten Formatenerlaubt. Für MPEG sind Codecs für Layer 1 und 2 vorhanden, nicht Layer 3.

Die beiden erstgenannten Encoder laufen auf verschiedenen Unix-Plattformen und auf Windows 9x/NT und arbeiten kommandozeilenorientiert. MediaConvert läuft mit grafischer Oberfläche unter IRIX5.x/6.x. Eine Reihe von Parametern lassen sich einstellen, z. B. Bitraten, Anzahl der Kanäle usw.

Man erreicht mit MPEG-Layer 2 eine Komprimierung von ca 1:6–1:8, d. h. pro Minute Spielzeit wer-den etwa 1,2 bis 1,6 MByte Dateigröße erreicht. Mit Layer 3 wird eine Komprimierung bis zu 1:12,entsprechend 800 kByte pro Minute Spielzeit, erzielt ohne dass die Qualität subjektiv merkbar leidet.Die zum Streaming erforderliche Datenrate sinkt damit von 1411,2 kbit/s für unkomprimierte Daten(44100 Samples/s * 2 Kanäle * 16 bit/Sample) auf 384 kbit/s für Layer 2 und auf 112–128 kbit/s fürLayer 3.

Für die Herstellung von RealAudio-Daten sind für verschiedene Plattformen Konverter erhältlich, diein der Basis-Version kostenfrei verfügbar sind. Zu den Werkzeugen mit grafischer Oberfläche für Win-dows und Linux (die auch Videodaten konvertieren) gibt es Kommandozeilen-Tools für verschiedeneUNIX-Versionen. Wie beim RealPlayer sind diese Programme ab Version 5 nicht weiterentwickeltworden und mittlerweile vom Webserver http://www.real.com/ verschwunden.

Video

Auf einem PC wurden der proprietäre RealEncoder von RealNetworks sowie der Standard-MPEG-1-Encoder von Xing Technologies erprobt. Beide unterstützen unterschiedliche Qualitäts-Profile, wobeider RealEncoder keine Skalierung der Bildgröße erlaubt, dafür aber die Auswahl eines Bildausschnit-tes (cropping). Die entsprechende Bildgröße ist daher bereits bei der Ausgabe mit dem Video-Bearbei-tungssystem zu berücksichtigen. Demgegenüber ermöglicht der Xing-Encoder eine Skalierung derBildgröße und bietet vordefinierte Profile für das Streaming in verschiedenen Datenraten und dieVideoCD-Herstellung an.

Ein weiterer Aspekt stellt die für die Konvertierung notwendige Rechnenzeit dar. Da in Streaming-AV-Systemen das zu präsentierende Bildmaterial oft in unterschiedlichen Auflösungen vorliegen sollte(z. B. für LAN-, ISDN- und Modem-Benutzer) wird eine mehrfache Konvertierung des Materials not-wendig.

Auf dem zur Verfügung stehenden System (Pentium-II, 233 MHz) benötigt der Xing-Encoder für dieKonvertierung von AVIs (DV-Codec, 720 * 576 Pixel, 25 Bilder/s) zu Standard-MPEG-1 (CIF, 25 fps)etwa 2,4 Sekunden pro Bild, entsprechend einer Stunde pro Filmminute.

Der RealEncoder ermöglicht eine Echtzeitkodierung von Audio- und Video; Voraussetzung hierfür istein mit einer Video-Grabber-Karte ausgestatteter PC. Die dabei erzeugten Daten können über einenRealServer live gestreamt werden und/oder lokal zum späteren Abruf gespeichert werden.



4.2.5.4 Schema

Wie auch die AV-Produktionsabläufe wurde auch der Ablauf eines AV-Streamings in Form eines Sche-mas beschrieben.

Die Übersicht unter http://www.dfn-expo.de/Technologie/Streaming/Schema/ erläutert den Weg vomAbruf der Datei bis hin zum Ausspielen an das Client-System unabhängig vom verwendeten Strea-ming-System.

4.2.6 Online-Dienste (Konvertierungsservices)

In diesem Teil wurden netzbasierten („Online-“) Dienste implementiert, die dem Nutzer das Publizie-ren von eigenen Daten auf einem Streaming-Server ermöglichen. Das Erstellen von anspruchsvollenAV-Präsentationen erfordert in der Regel ein interaktives Vorgehen. Insbesondere die Arbeit mitSchnitt- und AV-Bearbeitungssystemen lässt sich kaum automatisieren. Ziel der Services ist es daher,dem Benutzer Standard-Arbeitsschritte möglichst einfach und netzgestützt zur Verfügung zu stellen.

Der Benutzer muss somit nicht einen speziellen Encoder installieren und sich mit dessen Anwendungbefassen; stattdessen kann er unter über ein ähnliches Web-Interface verschiedene Encoder nutzen.

Für die vorgestellten Verfahren sind verschiedene Einsatzbereiche denkbar. Neben der reinen „Auslie-ferung“ der hergestellten Datei z. B. Audio-Archive, in denen das Rohmaterial in unkomprimierterForm geliefert wird, und nach einer entsprechenden Konvertierung unmittelbar mittels eines Strea-ming-Servers abrufbar ist.

4.2.6.1 Audio-Konvertierung

Es wurde ein Web-basierter Online-Service für die Audio-Konvertierung konzipiert, implementiertund getestet. Der Benutzer überträgt seine unkomprimierten Audiodatei über das Netz. Die Datei wirdnach seinen Vorgaben in ein streaming-fähiges Format konvertiert und auf dem DFN-Expo-Server zurVerfügung gestellt.

Im folgenden sind die wichtigsten Eigenschaften zusammengestellt und die Nutzung des Dienstesbeschrieben.

Abb. 22. Schemata: AV-Streaming

4.2 AV-Streaming 53


Eigenschaften

Audiodaten im umkomprimierten WAVE- oder AIFF-Format können in die Formate MPEG-1/Layer-II(mp2), MPEG-1/Layer-III (mp3) sowie das RealAudio-Format umgewandelt werden.

Dabei sind jeweils diverse Parameter (wie etwa die Bitrate) durch den Benutzer wählbar. Als Encoderkommen entsprechende Programme zum Einsatz, neben dem im SGI IRIX-Betriebssystem enthalte-nen mediaconvert der Optibase mp3-Encoder sowie die UNIX-Version des RealEncoders. Leider istder verfügbare UNIX-RealEncoder nicht auf dem Stand der Windows-Version, so dass nicht alleCodecs der aktuellen G2-Version zur Verfügung stehen. Auf der anderen Seite sind die erzeugtenAudiodaten auch mit den UNIX-Versionen des RealPlayers abspielbar.

Integriert wurde der Service in eine reine WWW-Umgebung – an Kommunikations-Software sindlediglich der Web-Browser auf Client-Seite und der Web-Server auf Serverseite erforderlich, zurDatenübertragung wird http und wahlweise ftp eingesetzt.

Nutzung

Zur Verwendung des Services findet der Benutzer unter http://www.dfn-expo.de/Technologie/Audio-Konvertierung/ für jedes Format ein Formular zum Initiieren einer Konvertierung. Neben den für alleFormate identischen Angaben zur Quelldatei und den administrativen Daten (e-mail-Adresse etc.) fin-det sich hier ein formatspezifischer Abschnitt, mit dem die Parameter der Konvertierung festgelegtwerden. Neben den verfügbaren Bitraten sind hier zum Teil weitere Angaben nötig. So können beiRealAudio-Dateien etwa zusätzliche Informationen (Titel, Autor, Copyright) in die AV-Datei integriertwerden.

Die als Quelle dienende Audio-Datei kann sich im lokalen Dateisystem des Benutzers befinden undmit Hilfe des Web-Browsers direkt übertragen werden. Wahlweise kann aber auch eine beliebige URLangegeben werden, unter der die Audio-Datei mit http oder ftp abrufbar ist.

Neben weiteren Parametern kann der Benutzer auch die gewünschte Zielbitrate sowie seine e-mail-Adresse angeben und festlegen, ob die Datei später löschbar sein soll.

Außerdem ist eine Online-Hilfe abrufbar. Nach dem Absenden der Daten erscheint eine alle 10 Sekun-den aktualisiere Ausgabe des Status der Konvertierung. Falls der Anwender das Ergebnis nicht abwar-ten möchte, kann er optional per e-mail benachrichtigt werden, wenn die Umwandlung abgeschlossenist. Selbstverständlich werden auch eventuell auftretende Fehler auf diesem Weg übermittelt.

Format Bitratenprimäre

Anwendungeingesetzter Encoder

mp2 64 bis 384 kbit/s Musik SGI mediaconvert

mp3 8 bis 256 kbit/s Musik Optibase mp3-Encoder

Real 5 bis 80 kbit/s Sprache Real Encoder

Tabelle 13. Audio-Konvertierung



Der Abruf der fertiggestellten Audiodatei erfolgt ebenfalls über das WWW. Der Anwender kann jeder-zeit eine Liste aller oder seiner – Entscheidungsmerkmal ist die IP-Adresse seines Rechners – konver-tierten Daten abrufen.

Von hieraus bekommt er eine detaillierte Übersicht zu jeder Konvertierung und kann das Ergebnis alsDatei, aber auch über den auf dem DFN-Expo-Server installierten Streaming-Server abspielen. Optio-nal kann auch die Originaldatei auf dem Server verbleiben. Wenn er es beim Start der Konvertierungzugelassen hat, kann der Auftraggeber mit seinem Passwort hier auch seine Daten löschen.

Abb. 23. RealAudio-Konvertierung, Eingabemaske und Hilfefenster

4.2 AV-Streaming 55


Bemerkungen

Bei der Anwendung des implementierten Services fielen die relativ langen Zeiten für die Übertragungder Quelldaten vom Benutzer zum Web-Server mit Hilfe des http-Upload auf. Zwar ist demgegenüberist die Konvertierungs-Leistung der eingesetzten Soft- und Hardware so hoch, dass sich in vielen Fäl-len die Übertragung der Daten auf den Server lohnt, selbst wenn eine Konvertierung auch auf dem Cli-ent-Rechner möglich wäre.

Dennoch galt es, für die Übertragung der Daten vom Client zum Server eine Alternative zu finden. Imfolgenden sind einige Lösungsansätze skizziert.

• Nutzung des vom Drucken bekannten lpr-Protokolls. Dies erfordert administrativen Aufwandbeim Benutzer (Einrichten eines Druckerdienstes).

• Auf dem Konvertierungs-Server selbst wird ein Upload-Bereich bereitgestellt, in den derAnwender seine Daten via ftp übertragen kann. Anschließend erfolgt der Zugriff durch den Kon-verter direkt über das Filesystem.

• Statt Übertragung der Datei übergibt der Benutzer lediglich eine Referenz in Form eines URL(http://... ftp://...). Der Konverter holt sich anschließend die Daten vom angegebenen Server. Die-ser Mechanismus ist sehr flexibel, der Benutzer muss allerdings seine Daten auf einem Web-oder ftp-Server zur Verfügung stellen, bzw. auf seinem lokalen Rechner einen entsprechendenZugang einrichten.

Wie in der Beschreibung bereits erläutert, wurde die letztgenannte Methode implementiert. Sie bildetauch die Grundlage für den im folgenden beschriebenen Video-Generierungs-Dienst.

Abb. 24. Audio-Konvertierung: Kennung und Passwort, Balkendiagramm während der Konvertierung, Wiedergabe



4.2.6.2 Video-Generierung

Analog zur Audio-Konvertierung wurde ein weiterer Online-Service aufgesetzt, der die Erstellung vonVideos aus Einzelbildfolgen ermöglicht. Diverse Visualisierungs-Werkzeuge, die teilweise auf spezi-elle Anwendungen zugeschnitten sind, können Folgen von nummerierten Einzelbildern exportieren.Auch DocShow-VR verfügt über eine entsprechende Funktion, um vordefinierte Folgen von (zweidi-mensionalen) Bildern zu erzeugen.

Die Bildfolgen können mit dem implementierten Service in standardisierte Videoformate konvertiertwerden. Neben der leichteren Handhabbarkeit (nur eine Datei, stärkere Kompression, Plattformunab-hängigkeit) kann damit auch ein festes Zeitraster für die erzeugten Bilder vorgegeben werden.

Durch diese Aufgabenteilung zwischen Bilderzeugung (Rendering) auf dem Clientsystem und Video-Kompression auf dem Server kann außerdem entsprechende Hardware effizient genutzt werden. Diesbetrifft insbesondere das Rendering von 3D-Szenen auf Grafik-Rechnern wie etwa der SGI Onyx2.Für die Videogenerierung wiederum könnten parallel arbeitende Systeme eingesetzt werden.

Eigenschaften

Als Quelldaten dienen Folgen nummerierter Einzelbilder in diversen Bildformaten wie bmp, tiff, gifusw. Daraus werden Videos in den Formaten MPEG-1, QuickTime und AVI generiert. Ein wesentli-cher Unterschied zur Audio-Konvertierung besteht darin, dass die einzelnen Bilder grundsätzlich perftp oder http vom Service „abgeholt“ werden. Der direkte Upload mit dem Web-Browser ist nichtmöglich – und bei der Vielzahl von Quelldaten auch nicht sinnvoll.

Zur Generierung der Videos wird (wie auch bei der mp2-Audio-Konvertierung) das Programm dmcon-vert von SGI genutzt. Der Service wurde mit Hilfe von cgi-Shell-Skripten implementiert, die leicht anveränderte Bedürfnisse anpassbar sind. Auf Client-Seite ist zur Interaktion lediglich ein Web-Browsererforderlich.

Wünschenswert wäre auch eine Herstellung von Videos im Real-Format. Der oben erwähnte RealEn-coder für UNIX unterstützt leider keine Videodaten, so dass ein solcher Dienst derzeit nicht angebotenwerden kann.

Nutzung

Der Benutzer gibt beim Start einer Generierung daher zunächst den Server und das Verzeichnis desRechners an, auf dem seine Bilddaten liegen. Mit einem Template bestimmt er der Dateinamen-For-mat der Einzelbilder. Es enthält eine fortlaufende Nummerierung, den Dateityp (entsprechend derEndung) sowie frei wählbare Zeichenfolgen, so könnte das 76. Bild einer Folge z. B. pic0075-a.gifbenannt sein. Die Namenserweiterung entspricht dem Bildformat und ist aus einer Liste wählbar. DieEingabe kann mit Klick auf den „Test“-Button überprüft werden.

Weiterhin wird das Format des zu erzeugenden Videos (Framerate und -größe) bestimmt. Für dieadministrativen Daten existieren die gleichen Felder wie bei der Audio-Konvertierung. Als Ergänzungkann hier das Kennwort zum späteren Löschen der Daten vom Benutzer vorgegeben werden.

4.2 AV-Streaming 57


Die generierten Videofilme sind über eine Liste eigner oder sämtlicher Daten zugänglich. Neben demDatum der Konvertierung ist in der Liste auch der Status der Verarbeitung, das Videoformat und dervom Benutzer angegebene Kommentar aufgeführt.

Zu jedem Auftrag erhält der Benutzer eine Übersicht der vorliegenden Daten. Neben den Logfiles zurVideo-Generierung und zur Dateiübertragung kann das erzeugte Video als Datei und zur Darstellungim Plugin abgerufen werden.

Ein Abruf von MPEG-Dateien über einen Streaming-Server (Xing) wäre ebenso möglich. Da Xing dieEntwicklung für die beim DFN-Expo-Projekt verwendete Server-Plattform eingestellt hat, wird derentsprechende Link nicht mehr ausgegeben.

Abb. 25. Video-Generierung: Eingabemaske, Template-Test, Hilfe

Abb. 26. Video-Generierung: Abruf der MPEG-Datei mit Plugin (Windows)



Bemerkungen

Seit einigen Jahren ist am RRZN/RVS bereits ein Video-Verfilmungsservice in Betrieb, der die netzge-stützte Verfilmung von Visualisierungsdaten in voller TV-Qualität auf Betacam-Kassetten ermöglicht(http://video.rrzn.uni-hannover.de). Dieser Dienst wurde für Preview-Zwecke auf die optionale Aus-gabe des Materials als MPEG-1 erweitert.

Für die Übertragung der Daten wird dabei das für Drucker entwickelte lpr-Protokoll genutzt. DerBenutzer muss daher zunächst auf seinem UNIX-System einen Netzwerkdrucker einrichten. Zudemist für der Verfilmung ein Skript zu erstellen, dass die Anordnung der Bilder definiert.

Im Vergleich zum bestehenden Preview-Service ist der hier implementierte Dienst leichter zu handha-ben, insbesondere erscheint die Nutzung mittels Web-Browser intuitiver. Zudem entfällt die Einrich-tung des lpr-Druckers, sofern sie auf dem System des Benutzers überhaupt möglich ist.

Die einfache Handhabung geht jedoch auf Kosten der Flexibilität: so müssen beispielsweise längerdauernden Standbilder durch das Duplizieren von Bildern erzeugt werden, eine entsprechende „Gene-rierungs-Anweisung“ fehlt. Für Standard-Anwendungen sind die gegebenen Möglichkeiten jedochausreichend.

4.2 AV-Streaming 59


4.2.7 MPEG-Audio-Plugin

4.2.7.1 Einleitung

Die Darstellung von Audio/Video-Daten im WWW erfolgt häufig in der Weise, dass zunächst diegesamte Mediendatei vom Webserver heruntergeladen wird, bevor ein geeigneter Viewer gestartetwird. Der Nachteil dieses Verfahrens besteht darin, dass vor der Darstellung der Daten zusätzlich zurStartup-Zeit des Viewers noch die Download-Zeit vergeht, die bei AV-Daten unter Umständen erheb-lich sein kann. Besser ist hier ein Verfahren, bei dem der Viewer die Daten selbständig lädt und simul-tan während des Downloads darstellt. Dieses Verfahren kann bei normalen HTTP-Servern angewandtwerden, wobei nur ein linearer Download ohne Flusskontrolle möglich ist. Es können aber auch spezi-elle Server benutzt werden, die über Steuerdaten sprungweises Vor- und Zurückfahren im Datenstromermöglichen. Eine neuere Entwicklung auf diesem Gebiet ist z. B. das Realtime Streaming ProtocolRTSP, das als RFC in [44] spezifiziert ist.

Bei der Verwendung von Netzstrecken, die Quality-Of-Service-Dienste (QoS, z. B. Garantie derDatenrate) anbieten, lassen sich diese QoS-Dienste für den AV-Datenstrom einsetzen. Dadurch kanneine stabile Datenrate erzielt werden, die bei der Übertragung von AV-Daten besonders wichtig ist.

Für die Integration von Audio-Clips in hoher Qualität in WWW-Präsentationen eignen sich in ersterLinie Inline-Plugins für Netscape, da sich Inline-Plugins direkt in die Präsentation (Webseite) einbet-ten lassen. Es existiert jedoch zur Zeit kein Inline-Plugin für MPEG-Audio, das die gängigen Unix-Plattformen und Windows 9x/NT gleichermaßen unterstützt.

Projektziel in diesem Bereich ist es, eine leistungsfähige, plattformübergreifende Streaming-Softwarefür Audio-Beiträge in Form eines Plugins für Netscape und den Internet Explorer bereitzustellen.

4.2.7.2 Entwurf

Ausgehend von einem am RVS entwickelten MPEG-Player (xaodplayer) für UNIX-Plattformen solldaher ein Netscape-Inline-Plugin implementiert werden, das spezielle Features für die Verwendung inWWW-Präsentationen enthält. Dazu gehört neben der zu erzielenden Audio-Qualität vor allem einveränderbares Interface, das je nach Einsatzzweck entweder komfortable Bedienelemente enthält oderplatzsparend nur mit den notwendigsten Funktionen ausgestattet ist. Zusätzlich zur UNIX-Welt solldieses Plugin ebenfalls in der für den Wissenschaftsbereich immer wichtiger werdenen Windows-Welteinsetzbar sein.

Damit ergeben sich folgende Anforderungen an die zu entwickelnde Software:

• Abspielen von MPEG-Audio (Layer 2 und 3), entspricht CD-Qualität mit 44.1 kHz Stereo• Realisierung als Netscape-Plugin und Applikation• breite Plattformunterstützung (IRIX, Solaris, Linux, Windows 9x/NT)• Zugriff auf MPEG-Dateien per HTTP• Anzeige einer Liste von MPEG-Dateien zum Abspielen• veränderbares Interface (einfach oder komfortabel) je nach Anforderung

Der vorhandene xaodplayer verwendet als MPEG-Decoder das frei verfügbare maplay der Techni-schen Universität Berlin. Maplay gilt allerdings als CPU-intensiv und unterstützt nicht Layer 3, sodass für das Plugin der ebenfalls frei verfügbare Decoder mpg123 von der Universität Tübingen ausge-wählt wurde. Messungen ergaben, dass mpg123 nur ca. 2/3 der CPU-Auslastung von maplay erreicht.Mpg123 liegt im Quellcode vor und läuft auf den gängigen Unix-Plattformen sowie unter Windows9x/NT.

Für die Erstellung der grafischen Bedienelemente fiel die Wahl auf die Klassenbibliothek Qt des nor-

wegischen Herstellers Troll Tech1. Qt ist für Unix frei einsetzbar und steht für auch für Windows 9x/NT, allerdings lizenzpflichtig, zur Verfügung. Es enthält spezielle Klassen, die die Erstellung von Net-scape-Plugins erleichtern und erschien daher für dieses Projekt besonders geeignet.

1. http://www.troll.no/



4.2.7.3 Implementierung

Auf der Basis des Entwurfs wurde mit der Implementierung eines Prototyps begonnen, der zunächstnur unter IRIX und Linux lauffähig war und noch nicht alle Anforderungen erfüllte. Für die Portierungauf Windows musste noch eine Lizenz für Qt beschafft werden.

Im Verlauf der weiteren Implementierung wurde, so weit möglich, unter Windows und IRIX parallelimplementiert und an geeigneter Stelle jeweils eine Portierung auf Solaris und zusätzlich auf Linuxvorgenommen. Dabei hat sich besonders die Klassenbibliothek Qt als sehr hilfreich erwiesen. Die mitQt implementierten Teile des Plugins haben auf allen Plattformen einen identischen Quellcode.

Eine wesentliche Funktion ist die Unterstützung von Playlists, d. h. es können Folgen von Audio-Clipsgeladen und abgespielt werden. Zwischen den Clips kann mit Hilfe zusätzlicher Tasten vor und zurückgesprungen werden. Die Bedienung ähnelt damit einem CD-Spieler. Eine Übersicht der Clips erhältman im Untermenü „Playlist“ des Pop-Up-Menü des Plugins. Hier kann man die Clips auch direktstarten. Die Playlists liegen als Textdatei auf dem Webserver und werden über den EMBED-Tag imHTML-Dokument geladen. Sie tragen die Endung „.aod“, für Audio On Demand, und erhalten alsMIME-Type vom Webserver „audio/x-audio-on-demand“. Die AOD-Dateien enthalten die URLs dereigentlichen Audio-Dateien, zeilenweise angeordnet. Eine besondere Syntax ist damit nicht erforder-lich. Die Playlist-Funktionalität ermöglicht es, mehrteilige Erläuterungen zu Exponaten anzubieten,deren Abschnitte gezielt ausgewählt werden können. Zudem können aus Teil-Clips zu einem Exponatsowohl ausführliche, als auch kompakte Audio-Erläuterungen zusammengestellt werden, ohne dassdie Clips neu zusammengeschnitten, neu gesprochen oder mehrfach gespeichert werden müssen. Abb.28 zeigt ein Beispiel für eine Playlist mit 4 Clips.

Abb. 27. Das MPEG-Audio-Plugin auf einer Exponatsseite

4.2 AV-Streaming 61


Weitere Arbeiten betrafen die interne Implementierung des Plugins. So wurde eine Kommunikations-schnittstelle zwischen Plugin-Rumpf und Decoder-Thread auf Basis von Pipes eingerichtet, die vor-nehmlich der Abfrage von Informationen aus dem Decoder und der Steuerung des Decoders dient. AbVersion 0.3.7 wird auch der Internet Explorer von Microsoft unterstützt, so dass das Plugin von denmeisten WWW-Usern genutzt werden kann.

Parameter Werte Erklärung

AUTOSTART TRUE/FALSE Automatisches Abspielen ein/aus

BGCOLOR Farbe Hintergrundfarbe in der Notation #RRGGBB

LOOP TRUE/FALSE Automatische Wiederholung ein/aus

NOGUI TRUE/FALSE Anzeige des Benutzerinterfaces ein/aus

SHOWSKIP TRUE/FALSE Anzeige der Playlist-Navigationstasten ein/aus

SHOWTIME TRUE/FALSE Anzeige der Spielzeit ein/aus

SHOWVOLUME TRUE/FALSE Anzeige des Lautstärkestellers ein/aus

Tabelle 14. Parameter des EMBED-Tags

Abb. 28. Playlist im Pop-Up-Menü

Schließlich wurde es ab Version 0.3.9 ermöglicht, das Plugin auch ohne Benutzerinterface zu betrei-ben. Dazu wird im EMBED-Tag der Parameter NOGUI=TRUE gesetzt. Das Plugin startet dann dieWiedergabe automatisch und beendet sie nur mit Ablauf des Clips oder beim Verlassen der Seite. DieLautstärke muss in diesem Fall extern eingestellt werden.

Das Plugin lässt sich über den EMBED-Tag konfigurieren. Beispielsweise:

<EMBED SRC=“audioclip.mp2“ WIDTH=“110“ HEIGHT=“60“ BGCOLOR=“#fffdf0“

AUTOSTART=TRUE>

Die Variablen WIDTH und HEIGHT sind Standardvariablen des EMBED-Tags und bestimmen dieGröße des Fensters, das dem Plugin auf der Webseite zur Verfügung gestellt wird. Zusätzlich lassensich weitere Parameter innerhalb des Plugins implementieren. Diese weiteren Parameter für dasMPEG-Audio-Plugin, die neben den üblichen implementiert wurden, sind in Tabelle 14 zusammenge-fasst

Abb. 29. MPEG-Audio-Plugin in einer Präsentation

4.2 AV-Streaming 63


4.2.7.4 Aufbereitung als Exponat

Die Arbeit wird als Exponat auf dem DFN-Expo-Server dokumentiert1. Hier finden sich Hintergrund-informationen zu dem Plugin, Verweise auf weitere Informationen zum Thema MPEG-Audio, sowieHinweise zur Installation und Konfiguration des Plugins. Da die Software einer breiten Nutzerschaftzur Verfügung stehen soll, werden vorkompilierte Dateien für die vier Betriebssysteme auf dem DFN-Expo-Server zum Download angeboten. Der Source-Code wird dabei nicht freigegeben. Der aktuelleSoftware bei Projektende trägt die Versionsnummer 1.0. Bis Projektende wurden über 1000 Exemplaredes Plugins von externen Benutzern abgerufen.

Zur Demonstration stehen auch abrufbare Beispiele für den Einsatz des Plugins zur Verfügung, sieheAbb. 27.

4.2.7.5 Erprobung im Rahmen von Beispiel-Anwendungen (Exponaten)

Die Erprobung des MPEG-Audio-Plugins im Rahmen von Exponaten auf dem DFN-Expo-Webserversoll nicht nur dem Test der Software selbst dienen, sondern auch für die Exponate einen Mehrwertschaffen und insbesondere auch dazu beitragen, das Zusammenwirken verschiedener Präsentati-onstechnologien zu demonstrieren.

Das Exponat „Tomographische Messverfahren in der Verfahrenstechnik“ enthält eine Reihe von 3D-Objekten, die mit gesprochenen Erläuterungen eines Wissenschaftlers angereichert sind. Diese Audio-Dateien werden mit dem MPEG-Audio-Plugin abgespielt. Ein Beispiel zeigt Abb. 29.

Auch im Teilprojekt DFNzine (vgl. Abschn. 4.4) wird das MPEG-Audio-Plugin eingesetzt, um Artikelmit Audio-Clips anzureichern. Während der Präsentation des DFNzine auf der Internationalen Funk-ausstellung 1999 in Berlin wurden Beispiele solcher Artikel demonstriert.

1. http://www.dfn-expo.de/Technologie/MPEG-Audio/

4.3 Virtuelle Pavillons 65


4.3 Virtuelle Pavillons

4.3.1 Die Idee Virtuelle Pavillons

Kommunikationsnetze sind wichtige Medien zur Information im Wissenschaftsbereich. Bei der Ver-mittlung wissenschaftlicher Inhalte über diese Medien müssen Form und Inhalt einander ergänzen, umden komplexen darzustellenden Themen gerecht zu werden. Die Aufarbeitung der Inhalte und einstrukturiertes User-Interface müssen den Benutzer bei seiner Informationsrecherche leiten und moti-vieren. Auf der Basis aktueller Online-Technologien und der im Internet etablierten Protokolle werdeninnerhalb der virtuellen Pavillons der DFN-Expo Beispiele für derartige Präsentationen gezeigt.

Nach dem Vorbild einer realen Ausstellung präsentiert die virtuelle Ausstellung „DFN-Expo“ in ihrenThemenpavillons Beiträge aus verschiedenen Wissenschaftsbereichen. Der Besucher bewegt sich perMaus durch die virtuelle Ausstellung, in der ihm die Exponate thematisch geordnet vorgeführt werden.Begleitet wird der Betrachter bei seinem Gang durch die Ausstellung von einem Ausstellungskatalog,der detailliert Aufschluss über die Inhalte und Ziele der präsentierten Projekte gibt. Die Exponats- undKatalog-Bereiche grenzen sich deutlich voneinander ab, um Suchmaschinen zielgerichtet in den texto-rientierten (Katalog-) Bereich leiten zu können und eine wechselseitige Referenzierung zu erleichtern.

Das Bild eines Puzzles zitierend setzt sich die DFN-Expo aus den virtuellen Pavillons Technologie,Infrastruktur und Demonstration zusammen (s. Abb. 30). Der Schwerpunkt des DFN-Expo-Technolo-giebereichs war die Entwicklung von Werkzeugen, die im Demonstrationsbereich exemplarisch prä-sentiert werden. Die zugrunde liegende Entwicklungs- und Präsentationsumgebung dokumentiert derBereich Infrastruktur. Der Demonstrationsbereich ist in die Themenpavillons Kommunikation, Medien, Technik, Natur undMedizin gegliedert. Die wissenschaftlichen Informationen in den Themenpavillons sind multimedialaufbereitet, um innovative Formen der Ergebnispräsentation zu demonstrieren. Neben den MedienText und Graphik werden alle Exponate durch zusätzliche Medien ergänzt, insbesondere durch Audio-dateien (z. B. in Form gesprochener Erläuterungen), Videodateien (Simulationen, Visualisierung) und3D-Szenen (Modelle).

Abb. 30. Gliederung der DFN-Expo



4.3.2 Gliederung der Virtuellen Pavillons

4.3.2.1 Technologiebereich

Die Entwicklung von Werkzeugen und Technologien zur Online-Darstellung wissenschaftlicherErgebnisse im WWW war das Ziel der Arbeit im Technologiebereich. Er besteht aus den BereichenVirtual Reality, Audio & Video, Suchmaschinen und Datenbanken (s. Abb. 31).

Virtual Reality

Im Bereich Virtual Reality wird das im Rahmen des Projekts weiterentwickelte Plug-In DocShow-VRdokumentiert (s. Abschn. 4.1). Es ermöglicht die stereoskopische Betrachtung und interaktive Naviga-tion durch virtuelle 3D-Modelle.

Audio & Video

Audio/Video-Streaming-Verfahren ermöglichen das interaktive Abrufen von Audio- und Videodatenim Netz, ohne dass zunächst ein vollständiger Datei-Download notwendig ist. Neben der Vorstellungverschiedener Verfahren werden Produktionsketten zur Erstellung von Audio- und Videodaten gezeigt(s. Abschn. 4.2).

Abb. 31. Die Einstiegsseiten der Exponate im Technologie-Pavillon



Weiterentwicklung von Metasuchmaschinen

In diesem Technologiebereich wird die Nutzungseffizienz und Unterstützung für die themenorientierteSuche durch neuartige Suchmechanismen verbessert. Aus den seit 1996 am RRZN/RVS bereitgestell-ten ersten deutschen Meta-Suchmaschinen wird ein neuer Suchmaschinentyp entwickelt, der aus denDatenquellen des Internet themenspezifische Suchmaschinen nach Benutzerwünschen automatischgeneriert (s. Abschn. 4.5).

Datenbanken

Ora++ ist eine am RVS entworfene und in diesem Projekt weiterentwickelte C++-Klassenbibliothek,die den Zugriff auf Oracle-Datenbanken ermöglicht. Es setzt auf das OCI (Oracle Call Interface) aufund kapselt dessen wichtigste Funktionen. Mit Ora++ wurden verschiedene Techniken zur Anbindungvon Oracle-Datenbanken auf das WWW realisiert.

4.3.2.2 Demonstrationsbereich

Um die Ergebnisse aus dem Technologie-Bereich unmittelbar in praktische Anwendungen einfließenzu lassen und damit den Technologie-Transfer aktiv zu fördern, werden im Demonstrationsbereichexemplarische Anwendungen präsentiert und Werkzeuge zur Verfügung gestellt.

Werkstatt

Die Werkstatt dient der Dokumentation und Distri-bution der im Technologiebereich erarbeitetenWerkzeuge und Prozessketten. Sie bietet Anwen-dungshilfen zur Multimedia- und Virtual Reality-Präsentation durch die Bereitstellung der Plug-Insund verschiedene Konvertierungsangebote (s. Abb.32). Die Werkstatt bietet die Möglichkeit zurOnline-Konvertierung von 3D-, Video- und Audio-Dateien. Ein Video-Generierungsservice erzeugtaus Bild-Daten Videofilme im MPEG-, AVI- oderQuickTime-Format. Das Ausgangsmaterial hierfürsind Sequenzen von durchgehend nummeriertenEinzelbildern gleicher Größe. Es können verschie-dene Formate wie Bitmap, TIFF, JPEG etc. verar-beitet werden.

Electronic Magazine (E-Zine)

Das DFNzine ist die Weiterentwicklung der amRRZN/RVS betriebenen Online-Präsentation derDFN-Mitteilungen. Neu im „DFNzine“ sind dieIntegration multimedialer Elemente wie Audio,Video, Virtual Reality, die Abkehr von der strengenEinteilung der Beiträge in Ausgaben und die konse-quente Nutzung der Datenbank (s. Abb. 33). DieErstellung der Beiträge und die Administrationerfolgt komplett über ein Web-Interface. Dabeiwerden nicht die Datenbanktabellen einzeln mani-puliert, sondern es wird eine Abstraktionsebenegeschaffen, welche die Objekte des DFNzine –Artikel, Bilder, Autoren, usw. – darstellt und derenManipulation erlaubt. Die notwendigen Änderun-gen an den darunter liegenden Tabellen werdendann automatisch durchgeführt (s. Abschn. 4.4).

Abb. 32. Exponatseite Werkstatt

Abb. 33. Startseite des DFNzine



Exponate

Unter dem Stichwort Exponate findet der Besucher die virtuellen Pavillons zu den Themen Kommuni-kation, Medien, Technik, Natur und Medizin. Hier wird die Verwendung und Erprobung der Ergeb-nisse aus den zuvor genannten Teilprojekten in verschiedenen Anwendungsszenarien demonstriert.Die Beiträge aus den verschiedenen wissenschaftlichen Einrichtungen sind jeweils einem der Schlag-worte untergeordnet. Anhand einer Liste kann sich der Besucher über die behandelten Themen und dieenthaltenen Medien (Audio, Video, VR-Modelle) informieren (s. Abb. 34). Die Ergänzung der Listeum die Mediensymbole ermöglicht es dem User, an dieser Stelle wahlweise nach Themen oderMedienarten zu suchen.

Bei der Gestaltung der Exponate wurde die Absicht verfolgt, durch die gezielte Zusammenstellungverschiedener Medien, Inhaltspräsentationen zu zeigen, die alle dem Menschen zur Verfügung stehen-den Kommunikationskanäle nutzen. Die multimediale Darstellung verbindet statische und dynamischeFormen der Webpräsentation. Voraussetzung für die erfolgreiche Interaktion zwischen Besucher undExponat ist die Konzeption und Realisierung eines verständlichen und intuitiven Userinterfaces. Einebenutzerfreundliche Oberfläche bietet einen schnellen Zugang zu allen Informationen und hilft demBesucher bei der Navigation und der Orientierung innerhalb der Seiten.

Nach dem Prinzip eines Puzzles setzt sich jedes Exponat aus vielen Einzelteilen zusammen, sowie dieunterschiedlichen Bereiche des Servers ebenfalls als Puzzleteile ineinander greifen und ein Ganzesergeben. Diese Seitenstruktur ermöglicht es dem Besucher, die Zeit und den Aufwand, die er in dieExploration der Seiten investieren möchte, selbst zu bestimmen.

Abb. 34. Einstiegsseite Exponate



4.3.3 Gestaltungselemente

Die Gestaltung einer benutzerfreundlichen, d. h. einer gleichermaßen ansprechenden und zweckmäßi-gen Oberfläche erfordert eine sinnvolle Strukturierung der Seiten. Die wichtigsten Gestaltungsele-mente beim Erstellen der Exponate auf dem DFN-Expo-Server waren die Fensterstruktur, einVorgabenkatalog für das Design der Seiten und die Textvorlage für die Katalogeinträge.

4.3.3.1 Strukturierung der Fensteranordnung auf dem WWW-Server „DFN-Expo“

Es existieren vier Fenstertypen, die – mit entsprechenden Namen assoziiert – wiederverwendet werden(s. Abb. 35). Die Exponate werden im Hauptfenster dargestellt, der Katalog wird grundsätzlich parallel zum Inhaltin einem Extrafenster dargestellt. Die Fenster für temporäre Informationen werden beim Verlassen derreferenzierenden Seite automatisch geschlossen.

Im Hauptfenster, in dem auch die Einstiegsseite dar-gestellt wird, gelangt der Benutzer in die verschie-denen Themenpavillons und in die Exponate. Erbleibt innerhalb des Hauptfensters, umgeben vonder History-Liste im rechten Frame sowie dem per-manent dargestellten unteren Rahmen mit verschie-denen Serviceangeboten. Dem Hauptfenster wirdbeim Abruf der Homepage via JavaScript der Name„dfn_expo“ zugeteilt, das funktioniert ab NetscapeVersion 3.0. Der Name ermöglicht die Referenzie-rung des gesamten Framesets vom Katalog aus. IstJavascript ausgeschaltet und der Name wird nichtzugewiesen, wird beim ersten Aufruf eines Expo-nats ein neues Fenster aufgebaut, das den Namen„dfn_expo“ trägt und damit angesprochen werdenkann.

Über das aktuell betrachtete Exponat gelangt der User zum entsprechenden Katalogeintrag. Diesererscheint in einem zusätzlichen Katalogfenster parallel zu dem im Hauptfenster dargestellten Exponat.Der Katalog kann alternativ auch über die Startseite angesprochen werden. Das Katalogfenster wirdaußerdem für die Plugin-Liste genutzt, zu der neben dem Katalog-Verweis ein Link in den Exponatenverweist. Der Benutzer kann so zwischen den beiden Fenstern hin- und herschalten oder sie nebenein-ander auf dem Bildschirm darstellen.

Abb. 35. Fensterstruktur DFN-Expo Server

Abb. 36. Frameset DFN-Expo

Der Katalog erscheint grundsätzlich in dem Extrafens-ter „More_Info“. Er kann ebenfalls über http://www.dfn-expo.de/Katalog/ im Frameset aufgerufenwerden, verweist dann aber auf das Extrafenster. ImKatalog referenzierte Exponate erscheinen im Haupt-fenster mit dem gesamten Frameset. Die Plug-in-Listeerscheint im Fenster „More_Info“, wenn sie direkt ausdem Exponat aufgerufen wird. Der Katalog verschwin-det dann, da aber im Exponat grundsätzlich neben demLink auf Plug-ins auch ein Link auf den Katalog vor-handen ist, kann er durch den Benutzer wieder zurück-geholt werden. Zur Anzeige von weiterführenden Informationen zueinem Exponat werden temporäre Fenster erzeugt, diekeine Navigationselemente des Browsers enthalten.Hier werden weiterführende Erklärungen, Grafikenetc. angezeigt, die unmittelbar mit dem Exponat ver-knüpft sind. Verlässt der Betrachter das Exponat, sowerden diese Fenster automatisch geschlossen. Wirdim Hauptfenster eine Übersicht angezeigt, so kann der Benutzer genauere Beschreibungen zu den dar-gestellten Elementen in diesem Fenster erhalten (s. Abb. 49, S. 78). Da diese Informationen nur dannsinnvoll erscheinen, wenn das entsprechende Hauptfenster angezeigt wird, wird das Tmp-Windowbeim Verlassen der (Haupt-)seite geschlossen. Dazu wird im <BODY>-Tag die Anweisung onUn-load="closeTI()" angegeben. Die Größe des Fensters kann mit den Variablen TIw (Breite) und TIh(Höhe) vorgegeben werden.

Externe Seiten, d. h. Webseiten anderer Server, werden in einem eigenen Fenster angezeigt. Es wirdein neues Standard-Browserfenster geöffnet, in dem ein Hinweis bezüglich des Verlassens des DFN-Expo-Servers angezeigt wird, und dann automatisch die entsprechende Seite geladen wird.

4.3.3.2 Design

Für die Gestaltung der Benutzerschnittstelle „Exponatseite“ gelten folgende Kompositionselemente:

• Seitenaufbau:Die Exponatseiten erscheinen innerhalb des Framesets immer im Hauptfenster. Die farblicheGestaltung der Frames leitet den Blick des Benutzers durch den Hell-Dunkel-Kontrast in diesesfür die Inhalte relevante Fenster. Die dargestellte Seite ist aufgeteilt in funktionale und inhaltli-che Flächen. Die funktionalen Navigationsbuttons in Form verlinkter Textgrafiken befinden sicham linken Bildrand. Das Hauptfenster, in dem die Inhalte und die Querverweise zum Katalogenthalten sind, ist eingerahmt vom unteren Frame mit den Serviceangeboten (Kalender, Sucheusw.) und dem History-Frame. Der History-Frame zeigt dem User als Orientierungshilfe denzurückgelegten Weg und seine aktuelle Position.

• Logo:Ein Puzzleteil befindet sich als Logo für die DFN-Expo auf allen Seiten, es stellt eine Art visuel-les Etikett der Seiten dar. Das Puzzleteil steht als Symbol für ein offenes System, das sich durchjedes dazukommende Teil vervollständigt.

• Informationsgrafik:Die Exponate enthalten eine Informationsgrafik, in der die Arbeitsinhalte und Arbeitsweise illus-triert werden und den begleitenden Katalogtext. Die Informationsgrafiken sind in der Mitte desFrames platziert, der User kann sie ansehen ohne scrollen zu müssen. Die Infografik zeigt sche-matisch die wichtigsten Merkmale des dargestellten Objekts oder Vorgangs. Realistische Abbil-dungen innerhalb des Schemas erleichtern dem Betrachter ein Wiedererkennen desDargestellten. Geeignete Bilder bzw. Bilderfolgen unterstützen den Betrachter beim Verstehender illustrierten Sachverhalte und Methoden.

Abb. 37. Katalogseite Virtuelle Bronchoskopie



• Medien:Der Einsatz vielfältiger Medien ermöglicht eine dynamische Informationsvermittlung unterAnsprache verschiedener Sinne. Alle im Exponat enthaltenen Medien erhalten ein Icon und wer-den in einer Tabelle unter der Informationsgrafik bereitgestellt. Der User kann in diesen Bereichscrollen, um zu diesen ergänzenden Informationen zu gelangen.

• Farbe:Die Zusammenstellung der Farbpalette ist für die Wahrnehmung von Webseiten ein entscheiden-der Faktor. Die farbliche Gestaltung der Präsentationsumgebung bestimmt ihre Gesamtwirkungund hilft die Aufmerksamkeit des Betrachters zu steuern und ihn zu motivieren.Für die Wahl einer Hintergrundfarbe gilt, dass der rückbeleuchtete Monitor auf die Netzhautstrahlt und die höchste Belastung durch weißes Licht entsteht. Als Hintergrundfarbe für dieExponatsseiten wird deshalb ein helles Gelb eingesetzt, von dem sich die Typographie gut lesbarabhebt ohne das Auge zu stark zu belasten. Als alternative Hintergrundfarbe wird auf strukturie-renden Seiten (z. B. Einstiegsseite Exponate) blau als Hintergrundfarbe verwendet. Der Einsatzunterschiedlicher Hintergrundfarben ermöglicht es dem Betrachter, die Funktion der jeweiligenSeite zu erkennen. Die bestimmenden Farben der Exponatsseiten sind:

– Gelb: strahlend, abweisend, heiter, leicht– Blau: kalt, passiv, technisch, seriös, ernst– Orange: warm, aktiv, dynamisch

• Schrift:Die Typographie trägt ebenso zur Wirkung einer Seite bei wie die gewählten Farben. Für dieExponatseiten werden wegen der guten Lesbarkeit am Bildschirm zwei serifenlose Schriften ver-wendet. Als Grafikschrift wird die Industria Solid verwendet, in ihr sind alle funktionalen Ver-weise geschrieben. Sie stehen als eingefügte Buttons am linken Bildrand und führen zumKatalog und zu den Plug-Ins. Die Schriftart für den Fließtest ist Helvetica bzw. Arial, die sichaufgrund ihrer Verfügbarkeit auf allen Systemen insbesondere für Textdarstellungen im WWWeignet.

• Katalogtext:Für die Gestaltung von Bildschirmtexten ist es wichtig, neben einer gut lesbaren Schrift nochweitere Gestaltungsmerkmale zu beachten. Die Erläuterungen zu den Exponaten in Form vonKatalogtexten sind nach einem Vorgabenkatalog gegliedert und in mehrere Informationseinhei-ten zerlegt. Sie werden in einem Fenster mit festgelegter Breite angezeigt. Die Anzahl der Zei-chen ist durch die Zeilenbreite begrenzt, die Zeilen enthalten nur ca. 8 - 10 Worte. DieBeschränkung der Zeichen in einer Zeile ermöglicht dem User ein lückenloses Zeilenscanningund vereinfacht die Informationsaufnahme.

4.3.3.3 Textvorlage

Die Texte des „Ausstellungskataloges“ dienen im wesentlichen der näheren Erläuterung eines Expo-nats und der dahinter stehenden wissenschaftlichen Arbeit. Die Katalogtexte sind logisch aufgebautund entsprechend durch Abschnitte und Überschriften gegliedert. Die Vorgaben für die Texte sind mitdem Ziel entstanden, ein hohes Maß an Lesbarkeit zu erreichen und die Inhalte sinnvoll zusammenzufassen. Sie sind nach folgenden Stichworten strukturiert:

• Titel, eventuell mit max. 2-zeiligem Untertitel• Abstract• Bisheriger Stand der Forschung,• Ziel der eigenen Entwicklung und Forschung• Was ist Besonderes an dieser Entwicklung? Was ist der eigene Lösungsansatz?• Erläuterung des Anwendungsbeispiels bzw. der Umsetzung• Zusammenfassung und Ausblick• Institution, Ansprechpartner, Telefonnummer, Mailadresse, Fax, WWW-Adresse, Datum• Schlüsselworte

Anhand dieses Gerüstes haben die Verantwortlichen der einzelnen Exponate ihre Texte formuliert unddie Vorlage entsprechend den Erfordernissen des Exponats adaptiert.



4.3.4 Realisierte Exponate

4.3.4.1 Molekulardynamische Simulationen der thermodynamischen und Transporteigenschaften im

Gasgebiet einfacher Modellfluide

Institut für Thermodynamik, Universität Hannover, 1999

Inhalt:

Das Exponat aus der Thermodynamik erläutert die Verläufe der Wärmekapazitäten und Viskositäteneiniger fluorierter Kohlenwasserstoffe, die in ihrem Gasgebiet ein ungewöhnliches Verhalten aufwei-sen. Dieses Verhalten ist experimentell und theoretisch wenig untersucht und noch nicht verstanden.Es wird vermutet, dass dieser Effekt auf die Bildung von Clustern im Gasgebiet nahe der Tauliniezurück zuführen ist. Experimente im Gasgebiet nahe der Taulinie sind aufgrund von unvermeidbarenAdsorptionseffekten an den Messzellenwänden nur schwierig durchzuführen. Daher wird versucht,anhand molekulardynamischer Simulationen die Frage zu klären, ob Minima tatsächlich existieren.

Medien:

Animierte Übersichtsgrafik, DocShow-VR Modelle, MPEG.

Abb. 38. Exponatseite Molekulardynamische Simulation einfacher Modellfluide



4.3.4.2 Tomographische Messverfahren in der Verfahrenstechnik

Institut für Verfahrenstechnik, Universität Hannover, 1998

Inhalt:

Am Institut für Verfahrenstechnik werden unterschiedliche tomographische Messverfahren entwickeltund eingesetzt. Das Ziel einer tomographischen Messung das Erzeugen eines zweidimensionalenSchnittbildes vom zu untersuchenden Körper. Das Schnittbild ist dann die Informationen über die Ver-teilung einer bestimmten physikalischen Eigenschaft in der Messebene. Derzeit wird an dem Institutmit folgenden Verfahren gearbeitet: Kapazitive Tomographie, Konduktive Tomographie, OptischeTomographie und Röntgentomographie.

Das Exponat zeigt die Anwendungsgebiete, die Sensoren und die Messergebnisse der Verfahren.

Abb. 39. Exponatseite Tomographische Messverfahren in der Verfahrenstechnik



Kapazitive Tomographie

Inhalt:

Die kapazitive Tomographie wird zum Messen derAnteile von gasförmiger und flüssiger Phase imLückenvolumen von Rieselbettreaktoren eingesetzt.Diese bestehen aus einer regellosen Schichtung kataly-tisch wirksamer Partikel, die von Gas und Flüssigkeitim Gleichstrom abwärts durchströmt wird. Für diekapazitive Tomographie werden mehrere Elektrodenperipher um den Messquerschnitt angeordnet. Die inte-grale Messgröße ist die Kapazität, die jeweils zwischenzwei der Elektrodensegmente gemessen wird. DerMessvorgang erfolgt, indem je zwei Elektroden aufverschiedene Potentiale gelegt werden und der sicheinstellende Strom gemessen wird.

Medien:

DocShowVR-Modelle, VRML-Modelle, Xing-MPEG,Audio-Erläuterungen der 3D-Modelle.

Abb. 40. Messkette in der kapazitiven Tomographie

Abb. 41. Ergebnisse der kapazitiven Tomographie



Konduktive Tomographie

Inhalt:

In vielen industriellen Anlagen treten Gas-Flüssig-keitsströmungen auf. Für die sichere Auslegung derRohrleitungen muss die Form der Strömung bekanntsein. Von besonderer Bedeutung ist das Entstehen dersogenannten Schwallströmung. Sie ist durch schnellströmende Flüssigkeitspfropfen gekennzeichnet, dieeine hohe mechanische Belastung für die Rohrleitungund nachgestellte Apparate bedeutet. Am Institut fürVerfahrenstechnik wurde ein tomographisches Mess-verfahren entwickelt, mit dem das schnelle undgenaue Vermessen von Gas-Flüssigkeitsströmungenmöglich ist.

Medien:

DocShowVR-Modelle, VRML-Modelle, Audio-Erläuterungen der 3D-Modelle, Xing-MPEG.

Abb. 42. Darstellung der Messergebnisse in der konduktiven Tomographie

Abb. 43. DocShow-VR Modell und MPEG-Video



Röntgentomographie

Inhalt:

Röntgentomographische Verfahren sind zur Diagnostikin der Medizin und zur Bauteilkontrolle in der Material-forschung weit verbreitet. Zur Prozessüberwachung undSteuerung werden sie nur zögerlich eingesetzt, da dieGeräte, die bisher zur Verfügung standen, Messzeiten imBereich einiger Minuten benötigten, so dass nur Vor-gänge beobachtet werden konnten, die einen quasi-stati-onären Charakter hatten oder für die nur zeitgemittelteWerte von Interesse waren. Mit neuen Systemen sindjetzt Messzeiten möglich, die im Bereich wenigerSekunden liegen. Dadurch wird die Röntgentomographieals Messtechnik auch für Prozesse bedeutsam, in denendie Strömungsfelder großen zeitlichen Schwankungenunterliegen.

Medien:

DocShowVR-Modelle, VRML-Modelle, Audio-Erläute-rungen der 3D-Modelle, Xing-MPEG.

Abb. 44. Darstellung der Messergebnisse in der Röntgentomographie

Abb. 45. Messkette Röntgentomographie



Optische Tomographie

Inhalt:

Das Homogenisieren mischbarer Flüssigkeiten wird inMakro- und Mikromischen unterteilt: Im Zuge desMakromischens nimmt der charakteristische Längen-maßstab der Segregation, z. B. die Dicke einer Lamelle,ab. Es entsteht ein Makrofluid, das mikroskopisch voll-ständig segregiert, d.h. inhomogen ist. Das Mikromi-schen in der molekularen Größenordnung erfolgt durchDiffusion und verringert die Intensität der Segregation.Für den Ablauf chemischer Reaktionen ist es wichtig,die Reaktanden schnell molekular miteinander zu ver-mischen. Da sich die Vorgänge während des Mischensnicht vollständig theoretisch beschreiben lassen, wirddas Makro- und Mikromischen in Rührgefäßen experi-mentell untersucht.

Medien:

DocShowVR-Modelle, VRML-Modelle, Audio-Erläu-terungen der 3D-Modelle, Xing-MPEG.

Abb. 46. Exponat zur optischen Tomographie

Abb. 47. Messergebnis Optische Tomographie



4.3.4.3 Ein Spaziergang durch die thermodynamischen Zustandsgrößen

Institut für Thermodynamik, Universität Hannover, 1997

Inhalt:

In diesem Exponat werden verschiedene thermodynamische Grö-ßen und Diagramme in räumlichen Modellen visualisiert. Eine sen-sitive Übersichtsgrafik zeigt thermodynamische Größen wieDruck, Volumen, Temperatur und Wärmekapazität sowie die dar-aus resultierenden Zustandsgleichungen. Per Mausklick erscheintein Informationsfenster mit den Erläuterungen zu Größen undBerechnungen. Die Visualisierung der Zustandsdiagramme in derThermodynamik dient als Hilfsmittel zur Auslegung und Veran-schaulichung von Prozessen in der Energietechnik. Durch die Projektion der Zustandsflächen in verschiedene Ebenenerhält man bedeutsame Darstellungen für technische Anwendun-gen, beispielsweise in der Kälte- und Klimatechnik.

Medien:

Sensitive Übersichtsgrafik, DocShowVR-Modell, VRML Modelle.

Abb. 48. Thermodynamische Zustandsgrößen

Abb. 49. Beispiel Entropie



4.3.4.4 Scannen eines Objektes mittels eines 3D-Scanners

Institut für theoretische Nachrichtentechnik, Universität Hannover, 1997

Inhalt:

Für die Erzeugung realistischer, virtueller 3D-Welten sind besondere Verfahren notwendig, um dreidi-mensionale Modelle von realen Objekten zu erzeugen. Am Institut für Theoretische Nachrichtentech-nik und Informationsverarbeitung der Universität Hannover wurde ein 3D-Scanner entwickelt, mitdem es in kürzester Zeit möglich ist, reale Objekte zu digitalisieren und in hochrealistische 3D-Abbil-dungen zu überführen. Das Verfahren arbeitet vollkommen berührungsfrei und verwendet auch keineaktiven Komponenten wie beispielsweise Laserstrahlen oder strukturiertes Licht. Einzig durch Aus-nutzung der Objekt-Silhouetten wird die 3D-Geometrie rekonstruiert und in Form eines Dreiecksnet-zes gespeichert. Typischerweise werden 18 bis 36 Bilder in einer Auflösung von 768 x 576 Pixelnaufgenommen. Anschließend wird die original Bildinformation wieder auf das Modell aufgebracht,um den gewünschten hochrealistischen Eindruck zu erzielen.

Medien:

Animierte GIFs, VRML-Modelle, DocShowVR-Modelle.

Abb. 50. Exponat 3D-Scanner



4.3.4.5 Level3 ist der Name einer neuen Generation von Internet Suchmaschinen

Regionales Rechenzentrum für Niedersachsen, Universität Hannover, 1997

Inhalt:

Das Exponat beschreit die Funktionsweise verschiedener Suchmaschinen. Suchmaschinen arbeitenmit unterschiedlichen Strategien: Die Suche wird entweder über möglichst viele Datenquellen geführt,hieraus resultieren die Meta-Suchmaschinen (Level2-Maschinen). Alternativ wird die Suche von vorn-herein mit Filtermechanismen nur über ein begrenztes Gebiet geführt. Hieraus resultieren themenspe-zifische Suchmaschinen (Level3-Maschinen). Die Ansätze sind zwar gegensätzlich, ergänzen sichaber. Eine Level3-Suchmaschine besteht aus einer lokalen themenspezifischen Datenbank, derenQuellen (URLs) aus einer Meta-Suche (Level2) gewonnen werden, und die automatisch und regelmä-ßig regeneriert wird.

Medien:

Animierte Übersichtsgrafik.

Abb. 51. Exponat Level 3 Suchmaschinen



4.3.4.6 Personalroboter ODRADEK

Hochschule für bildende Künste Hamburg, Fachbereich Industrial Design, 1997

Inhalt:

Ähnlich einem Personalcomputer, der es dem Menschen in derprivaten Atmosphäre des persönlichsten Lebensraumesermöglicht, umfangreiche mathematische Gleichungenberechnen zu lassen, führt der Personalroboter Odradek imAuftrag des Menschen manuelle Tätigkeiten im privatenBereich aus. Diese sind ebenso Ergebnis von Berechnungeneines Computers, die nicht mehr lediglich mittels eines Bild-schirms dargestellt werden, sondern in raum-, objekt- und per-sonenbezogene Aktivitäten umgesetzt werden

Medien.

Übersichtsgrafik, Quicktime-Movie, MPEG.

Abb. 52. Exponat Odradek

Abb. 53. Filmausschnitt Odradek



4.3.4.7 Rekonstruktion des Herrenhäuser Schlosses

Fachbereich für Architektur, Universität Hannover, 1997

Inhalt:

Hannover besitzt einen in seinem Umfang einzigartigen Garten- und Schlossbereich von ungewöhnli-cher Qualität und Erlebnisdichte, der die Geschichte vom geometrisch-regelmäßigen Barockgarten des17./18. Jahrhunderts bis zum Landschaftsgarten des 19.Jahrhunderts beispielhaft veranschaulicht. DasModell zeigt eine Rekonstruktion des Schlosses im Großen Garten im klassizistischen Zustand vonLaves. Man geht den Weg in der Hauptachse entlang vom Südrand des Parterres bis direkt vor dieTreppe im Schloss-Innenhof. Das Konzept eines Gesamtkunstwerkes ist heute nur noch partiell erleb-bar, weil einige wesentliche architektonische Elemente nicht mehr vorhanden sind. Das Schloss alsDominante wurde1943 zerstört. Zwei stattliche barocke Gartenkabinette, die einst die Achsen derKaskade und Grotte nach Süden abschlossen, gingen im 19. Jahrhundert verloren. Das westliche Kabi-nett wurde 1864 wiederaufgebaut, aber 1937 erneut entfernt. Die barocken Domestikenhäuser am Vor-hof wurden 1965 abgerissen.

Medien:

VRML 1.0, VRML 2.0, DocShow-VR.

Abb. 54. Exponat Herrenhäuser Schloss



4.3.4.8 Drifttrajektorien im Zirkumpolarstrom

Alfred-Wegener-Institut für Polar- und Meeresforschung, Bremerhaven, 1999

Inhalt:

Die einzigartige Zirkulation im Südpolarmeer verläuft ringförmig und ist nicht durch kontinentaleBarrieren unterbrochen. Starke, nach Osten gerichtete Winde und geringe Schichtung in Temperaturund Salzgehalt erzwingen eine kräftige, tiefreichende Strömung, die etwa 130 Millionen KubikmeterWasser pro Sekunde transportiert. Um den Austausch zwischen dem Wedellmeer und dem zirkumpo-laren Regime zu untersuchen, wurde am AWI ein hochauflösendes Ozeanmodell im Bereich desWedellmeeres (bis 20 km), das in ein grob auflösendes zirkumpolares Ozeanmodell eingearbeitet ist,verwendet.

Medien:

Übersichtsgrafik, DocShow-VR Modell, MPEG, Xing-MPEG, Real-Video (gestreamt).

Abb. 55. Exponat Drifttrajektorien im Zirkumpolarstrom



4.3.4.9 Videogalerie AWI

Filmausschnitte eines Informationsvideos des AWI

Inhalt:

Aus einem Informationsfilm desAWI Bremerhaven werden Filmaus-schnitte als Real-Videos, bzw.MPEG gezeigt. Ausgewählt sindbesonders interessante Ausschnittedes Informationsfilms, so Aufnah-men der ersten Polarexpedition vonAlfred Wegener oder antarktischeUnterwasseraufnahmen.

Medien:

Real-Videos (gestreamt), MPEG.

Abb. 56. Videoausschnitte AWI Bremerhaven

Abb. 57. Real-Videoausschnitte



4.3.4.10 Weather on Demand- Visualisierung von Wettervorhersagen

Deutscher Wetterdienst, Offenbach, 1999

Inhalt:

Um den hohen Anforderungen einer informativen undzugleich unterhaltsamen Aussage über das Wetter gerechtzu werden, ist vom Deutschen Wetterdienst in Zusammen-arbeit mit den Fraunhofer Institut für Graphische Daten-verarbeitung in Darmstadt das VisualisierungssystemTriVis™-Weathergrafix entwickelt worden. Die Daten fürdiese Wettervorhersagen werden beim Deutschen Wetter-dienst in Offenbach auf einem Supercomputer täglichmehrfach aus den aktuellen Daten der über Europa verteil-ten Mess-Stationen neu generiert.

Medien:

Übersichtsgrafik, DocShow-VR Modell, Real-Video(gestreamt), MPEG, Xing-MPEG (gestreamt).

Abb. 58. Exponat DWD

Abb. 59. Videoausschnitt DWD



4.3.4.11 Digitale Geländemodellierung Burg Holte

Institut für Kartographie, Universität Hannover, 1999

Inhalt:

Die Erstellung digitaler, EDV-gestützter, dreidimensionaler Modelle gehört inzwischen in vielenZweigen von Industrie, Verwaltung, Dienstleistung und Forschung zum Alltag. Auch in der Archäolo-gie finden derartige Modelle schon seit langem Anwendung. Die Studierenden des Vermessungswe-sens der Universität Hannover vermessen einmal jährlich historische Burganlagen. Hierbei werden dieGrundlagen der methodischen topographischen Erfassung von Geländeformen am praktischen Bei-spiel eingeübt. Archäologen, Bauforscher und Historiker erhalten eine detaillierte Dokumentation desIst-Zustandes für Denkmalpflege, Denkmalschutz und weitere Forschung in Form einer druckfähigenKarte, deren abschließende Bearbeitung in enger Abstimmung mit dem Niedersächsischen Landesamtfür Denkmalpflege erfolgt.

Medien:

Animierte und sensitive Übersichtsgrafik, DocShow-VR Modell.

Abb. 60. Exponat Digitale Geländemodellierung Burg Holte



4.3.4.12 Überflutungssimulation eines Leinetals

Institut für Kartographie, Universität Hannover, 1998

Inhalt:

Für die Vermittlung von raum- und zeitbezogenen Geo-Informationen kann bei sachgerechtem Einsatzmoderner Informationstechnologie eine Verbesserung der kartographischen Kommunikation erzieltwerden. Als Beispiel dafür dient die computeranimierte audio-visuelle Darstellung einer Überflutungdes Leinetals südlich von Hannover. Für die Gestaltung derartiger kartographischer Animationen istderzeit jedoch noch ein Mangel an Gestaltungsprinzipien erkennbar. Er betrifft das kartographischeDesign einer Animation ebenso wie ihre zweckmäßige Verwendung und Integration in eine hyper- undmultimediale Visualisierungsumgebung. Am Institut für Kartographie wird daher versucht, entspre-chende Gestaltungsprinzipien aus verschiedenen Theorien der Wahrnehmung abzuleiten.

Medien:

Animierte Übersichtsgrafik, Real-Video (gestreamt), Xing-MPEG (gestreamt).

Abb. 61. Exponatseite Computeranimation eines Überflutungsprozesse



4.3.4.13 Quantifizierung und Visualisierung von Regenwurmgangsystemen

Zoologisches Institut, Technische Universität Braunschweig, 1998

Inhalt:

Regenwürmer leisten einen großen Beitrag zur Umsetzung organischen Bodenmaterials, indem siedarin gebundenen Nährstoffe wieder verfügbar machen. Ihre Gangsysteme verbessern den Gas- undWasserhaushalt des Bodens. Ihrer Größe und ihrer aktiven Grabtätigkeit wegen, die sie in ständigemBodenkontakt stehen lässt, sind sie äußerst geeignete Indikatoren für die Diagnostik des Bodenmilieusund der Dynamik bodenbildender Prozesse. Folgende Fragen werden im Exponat behandelt: Wie ver-ändert sich das Grabverhalten von Regenwürmern im Vergleich zwischen verschiedenen Bodenbear-beitungsverfahren und zwischen unverdichtetem und verdichtetem Boden, gemessen an denParametern Ganglänge, Gangvolumen, Gangtortuosität und Gangkontinuität?Welches sind geeignete Verfahren zur Messung dieser Parameter und wie können die erhaltenen Infor-mationen quantifiziert und visualisiert werden?

Medien:

Übersichtsgrafik, JPEG, VRML 1.0, DocShow-VR Modell.

Abb. 62. Exponat Quantifizierung von Regenwurmgangsystemen



4.3.4.14 Numerische Simulation eines Temperaturfeldes im Bereich einer Konvektionszone

Institut für Meteorologie und Klimatologie, Universität Hannover, 1997

Inhalt:

Das kalte Tiefenwasser der Ozeane wird nur innerhalb weniger Gebiete der Weltmeere gebildet, soz. B. in der Grönland-See und im Weddell-Meer (Antarktis). Hier wird während der Übergangsjahres-zeiten das Oberflächenwasser durch sehr kalte, von den inländischen Eismassen abfließende Luftmas-sen stark abgekühlt. Die dadurch angeregte Tiefenkonvektion reicht bis zum Grund des Ozeans undbreitet sich im Verlauf von Jahrhunderten über die gesamten Weltmeere aus. Große Mengen an Koh-lendioxid werden so der Erdatmosphäre für entsprechend lange Zeiträume entzogen. Daher ist dasVerständnis dieser Tiefenkonvektion gerade für zukünftige Klimaprognosen (Stichwort Treibhausef-fekt) besonders wichtig. Das Exponat zeigt das Temperaturfeld im Bereich einer solchen Konvektions-zone als Ergebnis einer numerischen Simulation mit einem sogenannten Grobstruktur-Simulationsmodell. Die horizontalen Abmessungen betragen 50 x 50 km, die vertikale Erstreckungdes Modells beträgt 2 km.

Medien:

Übersichtsgrafik, VRML 1.0, VRML 2.0, DocShow-VR Modell, MPEG-Video, VCR-Video.

Abb. 63. Exponat Numerische Simulation eines Temperaturfeldes im Bereich einer Konvektionszone



4.3.4.15 DocShow- VR – ein Hochleistungs-Plugin zur Online- Präsentation komplexer 3D-Szenen

Projektinternes Exponat

Inhalt:

Bei der im Rahmen dieses Projektes durchgeführten Entwicklung wurde das Ziel verfolgt, eine Platt-form bereitzustellen, mit der hochkomplexe 3D-Szenen, wie sie bei der dreidimensionalen Aufberei-tung wissenschaftlicher Ergebnisse entstehen, möglichst effizient transportiert und dargestellt werdenkönnen. Dabei wird vorausgesetzt, dass leistungsfähige Client/Server-Systeme auf einer breitbandigenNetzinfrastruktur – z. B. Breitband-Wissenschaftsnetz (B-WiN, G-WiN), bzw. Intranet-Umgebungen –betrieben werden. Für die schmalbandige Anwendung werden Konzepte erarbeitet, die eine ange-passte Darstellung ermöglichen.

Medien:

DocShow-VR Modelle, Dokumentation in Postscript und PDF.

Abb. 64. Exponat DocShow-VR



4.3.4.16 Videoverfilmung im Netz

Regionales Rechenzentrum für Niedersachsen, Lehrgebiet Rechnernetze und Verteilte Systeme,Universität Hannover, 1997

Inhalt:

Videoproduktionen sind oft das Ergebnis aufwendiger Computersimulationen und werden in Wissen-schaft, Werbung und Unterhaltungsindustrie eingesetzt. Die Produktionsschritte „Bildgenerierung“und „Videoaufzeichnung“ sind über ein Kommunikationsnetz komfortabel verteilbar. Hierbei werdendie lokal erzeugten Bild- und Ton-Daten zusammen mit „Regieanweisungen“ zur Verfilmung an eineentfernte Produktionsmaschine übertragen. Ein Video-Server erzeugt aus den vom Nutzer über dasNetz abgegebenen Aufträgen Videofilme in Fernsehstudio-Qualität. Der Nutzer erhält Videocassetten,zum Beispiel VHS, S-VHS oder Betacam-SP, oder digitale Videos, beispielsweise im MPEG-Format,zur Online-Präsentation.

Medien:

Übersichtsgrafik.

Abb. 65. Exponat Videoverfilmung im Netz



4.3.4.17 Audio-Produktion


Inhalt:

In einer sensitiven Grafik werden die aufeinanderfolgenden Arbeitsschritte zum Erstellen einer Audio-Datei erläutert. Quellen wie Mikrofone, Cassettenrecorder oder ähnliches liefern ein analoges Aus-gangssignal und können meist direkt an das Sound-Device eines Rechners angeschlossen werden. DieDigitalisierung von analogen Eingangssignalen (die z. B. von hochwertigen Mikrofonen geliefert wer-den) findet im Recorder statt und liefert dabei meist bessere Ergebnisse als die Digitalisierung mitHilfe eines PCs oder einer Workstation. Die von den verschiedenen Programmen gelieferten Audio-Daten werden zunächst in Dateien auf einer Festplatte gespeichert. Die editierten Daten werdenabschließend mit dem Ziel konvertiert, das Datenvolumen für die Speicherung oder Netzübertragungzu reduzieren.

Medien:

Sensitive Übersichtsgrafik.

Abb. 66. Exponat Übersicht Audio-Produktion



4.3.4.18 Audio/Video-Streaming


Inhalt:

Die sensitive Grafik zum Thema Streaming zeigt die Grundlagen von Streaming-Verfahren. Die Anforderung des Beitrags erfolgt auf Seite des Betrachters mit Hilfe des Web-Browsers durchAnklicken eines Links oder das Absenden eines Formulars. Die Anfrage wird – analog zum Abrufeiner WWW-Seite – an den Web-Server gerichtet. Typischerweise enthält diese Datei eine Text-Zeilemit dem gewählten Titel, es sind jedoch keine AV-Daten enthalten. Für den Start der AV-Wiedergabeübergibt der Web-Browser die vom Server gelieferten Metadaten an den entsprechenden Player. MitHilfe des über HTTP gelieferten MIME-Types wird die passende Applikation assoziiert und gestartet.

Medien:

Sensitive Übersichtsgrafik.

Abb. 67. Exponat Übersicht Audio/Video-Streaming



4.3.4.19 Ableitungsketten visueller Medien

Projektinternes Exponat, 1997

Inhalt:

Ein dreidimensionales Modell stellt den Zusammenhang zwischen 3D-Animationen in Form von Geo-metrien, 3D-Szene und daraus resultierenden Rasterformaten wie Film und Bild dar. Es stellt eine derersten Studien zum Einsatz verschiedener 3D-Formate des gleichen Modells auf den DFN-Expo Sei-ten dar.

Medien:

VRML 1.0, DocShow-VR.

Abb. 68. Exponat Ableitungsketten visueller Medien



4.3.4.20 Video-Galerie - Visualisierung wissenschaftlicher Forschungsergebnisse


Inhalt:

Die Videogalerie zeigt Videobeispiele aus verschiedenen Fachbereichen, z. B. Strömungsmechanik,Baumechanik und Kartographie. Zur Verdeutlichung der Qualitätsunterschiede beim Einsatz verschie-dener Bandbreiten bei der Online-Videoübertragung sind einzelne Sequenzen mehrfach gespeichert.Es wird der direkte Vergleich der Formate Real, Xing-MPEG und MPEG bei unterschiedlichen Über-tragungraten ermöglicht.

Medien:

VCR-Viewer, Real-Video, Xing-MPEG, MPEG.

Abb. 69. Exponat Video-Galerie - Visualisierung wissenschaftlicher Forschungsergebnisse



4.3.4.21 Entwicklung eines MPEG-Audio-Players


Inhalt:

Die Darstellung von AV-Daten im WWW erfolgt häufig noch in der Weise, dass zunächst die gesamteMediendatei vom Server heruntergeladen wird und dann ein geeigneter Viewer gestartet wird. DerNachteil dieses Verfahrens besteht darin, dass vor der Darstellung der Daten zusätzlich zur Startup-Zeit des Viewers noch die Download-Zeit vergeht, die bei AV-Daten unter Umständen erheblich seinkann. Der Mpeg-Audio-Player für Audio-Beiträge stellt ein leistungsfähiges, plattformübergreifendesStreaming-Plugins für Netscape und den Internet Explorer dar.

Medien:

Mpeg-Audio Layer 2, Mpeg-Audio Layer 3, Real-Audio.

Abb. 70. Exponat Entwicklung eines MPEG-Audio-Players



4.3.4.22 Die Virtuelle Bronchoskopie

Klinik für Diagnostische Radiologie, Otto-von-Guericke Universität, Magdeburg, 1997

Inhalt:

In medizinischen Anwendungen sind die Aufgaben der Bildvorverarbeitung und der virtuellen Navi-gation eng verbunden. Die Evaluierung der Relevanz für Diagnose und Therapie ist bislang nur in eini-gen Veröffentlichungen berücksichtigt. Ziel ist die Bereitstellung eines Prototypen zur Navigationunter weitestgehender Verwendung von Standardsoftware für die Bildverarbeitung und Oberflächenre-konstruktion. Der Prototyp soll die Basis für die Evaluierung des virtuellen Ansatzes und die Planungder Weiterentwicklung bilden. Beispielhaft für die virtuelle Endoskopie stellt die virtuelle Bronchos-kopie eine sinnvolle Ergänzung in diesem Fall für die Tumordiagnostik dar.

Medien:

Übersichtsgrafik, TIFF, VRML 1.0, DocShow-VR Modell, VCR-Video, Xing-MPEG, Real-Video.

Abb. 71. Exponat Virtuelle Bronchoskopie



4.3.5 Informationsdienst Forschungslandkarte Deutschland

Dieser Arbeitspunkt ist nicht im Projektantrag enthalten. Er wurde nachträglich mit dem DFN-Vereinvereinbart.

Die Forschungslandkarte Deutschland1 ist ein Informationsdienst des BMBF, der deutsche For-schungseinrichtungen präsentiert. Vorgestellt werden über 800 öffentlich geförderte Einrichtungen.Das Spektrum reicht dabei von den Hochschulen über die Max-Planck- und Fraunhofer-Institute sowiedie Helmholtz-Zentren bis hin zu den Fachinformationszentren und den Technologietransferstellen.Zur Darstellung werden Texte, Bilder, Audio- und Video-Clips verwendet. Suchfunktionen erleichternden Zugriff auf die Daten.

Im Rahmen des DFN-Expo-Projekts stellt das RRZN/RVS den WWW-Server und einen RealMedia-Server für die Forschungslandkarte Deutschland bereit, da durch die Arbeiten zum AV-Streaming hierbereits Know-How vorhanden ist. Die Inhalte des WWW-Servers werden von der Firma Nexum (frü-her ATW Interactive) erstellt und per FTP auf den Webserver überspielt. Für die Volltextsuche auf demWebserver der Forschungslandkarte Deutschland wurde die Harvest-Installation des RVS genutzt.

Die geleisteten Arbeiten zu diesem Thema umfassen:

• Einrichtung, Betrieb und Pflege des WWW-Servers Forschungslandkarte Deutschland• Einrichtung, Betrieb und Pflege eines RealMedia-Servers• Konfiguration und Betrieb zweier Harvest-Suchmaschinen (deutsch/englisch)• Unterstützung der Firma Nexum bei der Einbringung von Inhalten auf den Server• Monatliche Zusammenstellung der Log-Einträge des Webservers für statistische Auswertungen

Diese Arbeiten wurden während der Projektlaufzeit kontinuierlich durchgeführt.

1. http://www.forschung.bmbf.de/

4.4 DFNzine 99


4.4 DFNzine

4.4.1 Einleitung

Ziel dieses Projektteils war die Weiterentwicklung der elektronischen DFN-Mitteilungen aus demRTB-Nord-Projekt „Onlinedokumente“ zu einem komfortablen, datenbankbasierten Multimedia-Magazin. Gleichzeitig sollten hier alle im Technologie-Bereich des DFN-Expo-Projektes erarbeitetenWerkzeuge – wie Viewer, Konvertierungsautomatismen und Suchmaschinen – exemplarisch zum Ein-satz kommen.

Bereits seit 1995 sind die DFN-Mitteilungen im Web verfügbar. Im Rahmen des RTB-Nord-Projektes„Onlinedokumente“ wurden Mitte der 90er Jahre Verfahren entwickelt, um aus der Quark-XPress-basierten (Druck-)Vorlage des Heftes verschiedene für das Web geeignete Formate, wie HTML, Post-script und PDF zu erzeugen. Meta-Informationen können aus einer Datenbank abgefragt werden. EineWeiterentwicklung dieser elektronischen DFN-Mitteilungen hin zu einem multimedialen „ElectronicMagazine“ ist Teil des DFN-Expo-Projekts.

Die wesentlichen neuen Merkmale dieses DFNzine sind die Integration multimedialer Elemente wieAudio, Video, Virtual Reality, die Abkehr von der strengen Einteilung der Beiträge in Ausgaben unddie konsequente Nutzung der Datenbank. Die Erstellung der Beiträge und die Administration erfolgtkomplett über ein Web-Interface.

Mit dem DFNzine wird ein multimediales Magazin realisiert, in dem der Leser, bzw. Benutzer dieInformationen aus der zugrunde liegenden Datenbank in einer zwei- und dreidimensionalen Informati-onslandschaft visualisiert findet. Es stellt zielgruppenorientiert unterschiedliche Beitragsformen wieArtikel, Filme, 3D-Objekte bereit, die beliebig miteinander kombiniert und dargestellt werden können.Dem Nutzer stehen verschiedene Möglichkeiten zur Informationssuche zur Verfügung, er kann überein thematisch geordnetes Navigationsmenü oder über eine intuitive, optische Orientierung in einemvirtuellen Modell an die Magazininhalte gelangen. Der menügesteuerte Zugriff auf die Inhalte desDFNzine ermöglicht die direkte Auswahl eines Themas und der dahinterliegenden Artikel.

4.4.2 Sicht des Lesers

Zunächst soll das DFNzine aus Sicht des Leser, bzw. Betrachters beschrieben werden, bevor auf dietechnische Realisierung eingegangen wird. Das DFNzine befindet sich bis zur Aufnahme des Produk-tionsbetriebes noch auf dem DFN-Expo-Webserver unter dem URL:

http://www.dfn-expo.de/DFN-Zine/

Die Startseite ist zweigeteilt und enthält links einen Frame mit Menüeinträgen und rechts einen Frame,in dem die jeweiligen Inhalte, z. B. Artikel, angezeigt werden. Abb. 72 zeigt die Startseite des DFN-zine.

Das Menü im linken Frame enthält folgende Einträge:

1. Recherche: Möglichkeit zur Volltextsuche über alle Artikel. Mehrere Suchbegriffe könnenlogisch miteinander verknüpft werden und es kann nach Datum oder nach Relevanz sortiert wer-den. Die Ergebnisse werden in einem neuen Fenster dargestellt, das ebenfalls zweigeteilt ist undlinks ein Inhaltsverzeichnis der Suchergebnisse anzeigt und rechts einen ausgewählten Artikel.Suchergebnisse haben einen eindeutigen, dauerhaften URL und können daher z. B. als Lesezei-chen im Browser abgelegt oder von anderen Webservern aus referenziert werden.

2. Kurz notiert: Hier werden die zehn aktuellsten Kurzmeldungen, d. h. Artikel der Rubrik „Kurz-meldungen“ hintereinander angezeigt, ähnlich der auf vielen Webservern üblichen Seite „News“.

3. Forum - Sicherheit: Diese Menüpunkte führen auf Übersichtsseiten der gleichnamigen Rubriken,auf denen die vorhandenen Artikel nach Datum sortiert verzeichnet sind. Diese Punkte könnenleicht verändert werden, wenn neue Rubriken wichtig werden.

4. Extrakt: Eine Übersicht aller Rubriken mit der Anzahl der vorhandenen Artikel und Links aufentsprechende nach Rubriken getrennte Artikelübersichten.

5. Impressum: Impressum des DFNzine



4.4.3 Technik

4.4.3.1 Überblick

Die technische Realisierung des DFNzine unterscheidet sich wesentlich von klassischen Webservern[3][7]. Im DFNzine wird weitgehend auf statische HTML-Seiten verzichtet und stattdessen ein Ver-fahren zur dynamischen Erzeugung der HTML-Seiten angewandt. Lediglich die Einstiegsseite mitMenüleiste und einige andere Seiten, wie das Impressum, liegen als HTML-Datei auf dem Webserver.

Die Speicherung der Artikel und aller Metadaten erfolgt in einer relationalen Datenbank (Oracle). BeiAbruf eines Artikel werden seine Elemente (Text, Bilder, Audio, Video, etc.) entsprechend den Lay-outvorgaben als HTML-Dokument zusammengefügt und verschickt. In der ursprünglichen Online-

Version der DFN-Mitteilungen1 werden nur die Metadaten in der Datenbank gespeichert, die Artikel

1. http://www.rtb-nord.uni-hannover.de/dfn/mitteilungen/

Abb. 72. Startseite des DFNzine

4.4 DFNzine 101


liegen als fertige HTML-Dokumente vor. Dies steht einer flexiblen Kombination der Artikel, je nachInteressenlage des Lesers, im Wege. Außerdem ermöglicht der Einsatz der Datenbank für die Speiche-rung der Artikeltexte komfortablere Mehrwertdienste, z. B. verbesserte Volltextsuche mit Hervorhe-bung der Suchbegriffe und ein besser strukturiertes Artikelarchiv.

Neue Beiträge werden jederzeit in das Multimedia-Magazin aufgenommen. Die entsprechendenArbeitsschritte werden in Form eines Formulars mittels eines Browsers (z. B. Netscape) vorgegeben.Damit sind Redaktion und langfristig auch die Autoren selbst in der Lage, Informationen in jederForm (Texte, Bilder, Audio, Videos, 3D-Szenen) in die Datenbank einzugeben.

Die folgenden Abschnitte sollen einen Überblick über die Software-Komponenten und die interneDatenstruktur des DFNzine geben. Anschließend folgt eine Beschreibung des Redaktionssystems.

4.4.3.2 Eingesetzte Software

In diesem Projekt wurde, abgesehen von der Datenbank, weitgehend freie Software eingesetzt. DasRedaktionssystems wurde vollständig selbst implementiert. Das DFNzine besteht aus vier wesentli-chen Software-Komponenten:

1. Webserver mit PHP-Interpreter

Als Webserver wird der Apache (Version 1.3.9)1 mit PHP- (Version 3.0.12)2 und OpenSSL-

Modul (Version 0.9.4)3 eingesetzt. Die Gründe hierfür sind die bekannte Zuverlässigkeit, diegute Performance, der hohe Funktionalitätsumfang und die weite Verbreitung des Apache.

2. DatenbankAls Datenbank wird Oracle (Version 8i Enterprise) eingesetzt. Es wird allerdings nur der Daten-bank-Server selbst, die integrierte Volltext-Suche und die OCI-Schnittstelle genutzt. Weitereneuere Komponenten, wie WebDB, Java-Servlets, etc. werden nicht benutzt.

3. Redaktionssystem mit HilfsprogrammenDas Redaktionssystem ist auf Basis der OCI-Schnittstelle von Oracle in der Projektlaufzeit imp-lementiert worden. Als Programmiersprache wurde C++ verwendet. Das System besteht auseiner Reihe von CGI-Programmen, die der Redaktion die Bearbeitung der Datenbankinhalteermöglicht.

4. Webseiten und PHP-SkripteDiese bilden die Schnittstelle für den Leser des DFNzine.

Die Abb. 73 zeigt diese vier Komponenten und ihr Zusammenwirken.

Zusätzlich zu den hier erwähnten Software-Komponenten werden vom Redaktionssystem noch einigeHilfsprogramme benötigt, um Mediendateien zu bearbeiten. Dabei handelt es sich um externe Appli-kationen, zu denen zum Beispiel die Programme „Ghostscript“ und „Convert“ für die Konvertierungvon Bilddateien zählen, sowie weitere für Audio- und Video-Dateien. Diese Programme werden vonden CGI-Programmen des Redaktionssystems aufgerufen.

Die Kommunikation mit der Datenbank erfolgt über ORACLE-eigene Protokolle, so dass auch ent-fernte Datenbanken, für die Anwendung transparent, angesprochen werden können. Im folgendenAbschnitt werden die hier verwendeten Methoden, die Datenbank anzusprechen, erläutert.

4.4.3.3 Datenbankschnittstellen

Zu Beginn des Projekts wurde zunächst die bereits im RTB-Nord-Projekt „Onlinedokumente“ einge-setzte C++-Klassenbibliothek „DBTools.h++“ von Rogue-Wave kritisch betrachtet. Dabei ergabensich folgende Nachteile:

• Die Klassenbibliothek ist sehr umfangreich und enthält wesentlich mehr Klassen, als benötigtwurden. Daher entstehen sehr große Programmdateien mit höheren Ladezeiten und höheremSpeicherbedarf.

1. http://www.apache.org/2. http://www.php.org/3. http://www.openssl.org/



• Die Klassenbibliothek muss für jede Plattform lizenziert werden. Am RRZN/RVS wird Oracleauf drei verschiedenen Plattformen eingesetzt. Es wären also mindestens zwei weitere Lizenzenzu beschaffen gewesen.

• Es waren auf der Entwicklungsplattform (SGI/IRIX) nicht alle Klassen nutzbar, da der C++-Compiler nicht den ANSI-C++-Standard erfüllte. Außerdem traten einige Fehler auf, die auchdazu führten, dass bestimmte Klassen nicht mehr genutzt wurden.

Aufgrund dieser Nachteile wurde beschlossen, die erforderlichen C++-Klassen selbst zu implementie-ren. Das Ergebnis sind die Ora++-Klassen, die sowohl für die CGI-Programme, als auch zunächstnoch für die Oracle-Schnittstelle für PHP verwendet wurden.

Version 2.0 von PHP verfügte nicht von Anfang an über eine eigene Schnittstelle zu Oracle, so dassauch diese implementiert wurde [5][6]. Sie zeichnet sich gegenüber der späteren PHP2-eigenenSchnittstelle durch folgende Merkmale aus:

• persistente Verbindungen zur Datenbank: ein Verbindungsaufbau mit der Datenbank findet nurbeim ersten Request statt, weitere Requests können die bestehende Verbindung nutzen. Für dieApplikation bedeutet dies einen virtuellen Verbindungsaufbau, der nur darin besteht, die richtigeVerbindung aus dem Speicher auszuwählen und zurückzuliefern. Messungen haben ergeben,dass sich die Zeit für den Verbindungsaufbau von ca. 300 ms bei lokalen Verbindungen und vonca. 1,5 s bei Verbindungen über Netz auf unter 500 µs für einen virtuellen Verbindungsaufbausenken lässt. Dies entspricht einer Reduktion der Verbindungsaufbauzeit auf ca. 160 ‰ fürlokale Verbindungen, bzw. auf ca. 33 ‰ für Verbindungen über das Netz.

PHP-QuellcodeStatische Webseiten

ORACLEDatenbank

PHP-ModulApache-

Webserverzum Browser

CGI

SQLNET

SQLNET

HTTP

File-Zugriffe

CGI-Programmedes Redaktions-

Systems

Abb. 73. Software-Komponenten des DFNzine

4.4 DFNzine 103


• Zugriff auf LONG-Felder: Normale String-Felder in Oracle-Tabellen können maximal 2000 Zei-chen enthalten. Längere Texte können in LONG-Feldern gehalten werden, die bis zu 2 GByteText aufnehmen können.

Die PHP-Schnittstelle ist als Apache-Modul auf folgenden Plattformen zum Einsatz gekommen: IRIX6.x, Solaris 2.5.1, Reliant 5.43 (SINIX), HPUX 10.x. Für dieses Projekt ist die IRIX-Version weiterhindie Entwicklungsbasis. Mittlerweile wird PHP in der Version 3.0 eingesetzt, in der eine geeignete Ora-cle-Schnittstelle vorhanden ist. Daher werden die Ora++-Klassen nur noch im Redaktionssystemgenutzt.

Abb. 74 zeigt die Ora++-Klassen JOraCon, JOraCursor und JOraEngine. JOraEngine stellt einen Con-nection- und Cursor-Pool dar, der besonders für die Implementierung eines Middleware-Servers inter-essant wäre und im DFNzine nicht mehr verwendet wird. Diese Klasse stammt noch aus der selbstimplementierten Oracle-Schnittstelle für PHP2.

JOraCon- und JOraCursor-Objekte werden von den CGI-Programmen des Redaktionssystems erzeugt,wenn Datenbankzugriffe erfolgen sollen. Ein JOraCon-Objekt kapselt eine Verbindung zur Datenbank,ein JOraCursor-Objekt erlaubt die eigentliche Kommunikation mit der Datenbank. Auf einer Verbin-dung können mehrere Cursor geöffnet werden. Dazu erhält der Cursor einen Zeiger auf eine geöffneteVerbindung. Mit der Methode JOraCusor::execSql() lassen sich SQL-Befehle ausführen. Auf Abfrage-ergebnisse hat man mit den Methoden JOraCusor::fetch(), JOraCusor::getValue() und JOraCusor::get-LONG() Zugriff.

Das Code-Fragment in Abb. 75 zeigt beispielhaft eine Datenbank-Abfrage mit den Ora++-Klassen.

JOraEngine

instance()getNewConnection()getCachedConnection()closeConnection()

con[]cur[]cacheflag[]

JOraCursor

getConnection()open()close()isOpen()hasResult()cancel()execSql()fetch()fetchNextPiece()getColName()getType()isNull()getPw()getValue()getLONG()setParameter()clearParameters()setDebugLevel()

JOraCon

open()close()isOpen()getlda()commit()rollback()setAutoCommit()getAutoCommit()getUsername()getPassword()

Abb. 74. Ora++-Klassen (gestrichelt: wird im DFNzine nicht mehr benutzt)

Die Ora++-Klassen haben sich während der Projektlaufzeit als sehr hilfreich bei der Realisierung vonDatenbank-Anwendungen erwiesen und wurden auch in anderen Entwicklungen des RRZN/RVSerfolgreich eingesetzt.

4.4.3.4 Datenbank-Design

Dieser Abschnitt befasst sich mit dem Entwurf der Datenbank und mit der Struktur der gespeichertenDaten. Anhand von Objekt-Diagrammen wird die Datenstruktur erläutert.

Die Daten des DFNzine sollen möglichst vollständig in der Datenbank gehalten werden, im Gegensatzzu üblichen Anwendungen, die nur die Metadaten in einer Datenbank halten und die Nutzdaten imFilesystem. Folgende Anforderungen wurden an die Datenbankstruktur gestellt:

1. vollständige Erfassung der Daten

2. möglichst geringe Redundanz

3. hohe Flexibilität für verschiedene Abfragen

4. leicht erweiterbar

// Oeffnen einer Verbindung zur Datenbank MYDB // mit dem User-Namen DBUSER und dem Passwort DBPASSWORD

JOraCon *con = new JOraCon ("DBUSER@MYDB", "DBPASSWORD"); if (!con->open()) { fprintf(stderr, "Datenbank-Login nicht möglich, Abbruch!\n"); exit(0); }

// Erzeugen eines Cursors auf der Verbindung con JOraCursor *cur = new JOraCursor (con); if (!cur->open()) { fprintf(stderr, "Fehler beim Öffnen des Cursors, Abbruch!\n"); exit(0); }

// Ausfuehren eines SQL-Selects if (cur->execSql ("SELECT ID,NAME,DESCRIPTION FROM MY_TABLE") <= 0) { fprintf(stderr, "Fehler beim Datenbank-Zugriff, Abbruch!\n"); exit(0); }

// Zugriff auf die Elemente des Ergebnisses // Reihe fuer Reihe mit fetch() while (cur->fetch()>0) { printf("%s\n", cur->getValue(0)); // Zugriff auf den 1. Wert

der aktuellen Reihe printf("%s\n", cur->getValue(1)); // Zugriff auf den 2. Wert

der aktuellen Reihe printf("%s\n", cur->getValue(2)); // Zugriff auf den 3. Wert

der aktuellen Reihe }

// Schliessen von Cursor und Verbindung cur->close(); con->close();

Abb. 75. Beispiel-Code einer Datenbankabfrage mit den Ora++-Klassen

4.4 DFNzine 105


Die erste Forderung ist trivial: Alle benötigten Daten müssen in der Struktur berücksichtigt werden.Die Vermeidung von Redundanz ist wichtig zum einen aus Speicherplatzgründen, zum anderen, weilbei redundanten Daten die Gefahr besteht, dass es zu Inkonsistenzen kommt. Die dritte Forderungbedeutet, dass die Datenbankstruktur verschiedene Sichten auf die Daten erlauben muss. Der zubetrachtende Ausschnitt der Daten muss vom Benutzer bestimmbar sein und darf nicht durch dieDatenbankstruktur eingeschränkt werden. Die vierte Forderung ist obligatorisch für Softwareentwürfe.Erweiterungen dürfen nicht zu kompliziert sein und vor allem nicht zu Inkompatibilitäten führen.

Die Datenstruktur enthält Objekte und Relationen zwischen diesen Objekten. Folgende Objekte sinddefiniert:

1. Absatz

2. Artikel

3. Format

4. Info

5. Institution

6. Medium

7. Name

8. Rubrik

9. Sammlung

Abb. 76 zeigt das aktuelle Objekt-Diagramm des DFNzine. Die Objekt sind als zweigeteilte Rechteckedargestellt, deren oberer Teil den Objektnamen enthält. Im unteren Teil sind die Attribute des Objektsaufgelistet. Jede Instanz eines Objekts verfügt über eine eindeutige ID, anhand derer es identifiziertwird. Die Relationen sind als Verbindungslinien zwischen den Objekten ausgeführt. Kreise an denLinienenden bezeichnen Mehrfachrelationen. Zum besseren Verständnis sind diese Beziehungen zumTeil benannt, z.B. „gehört an“ oder „enthält“. Einige Relationen haben zusätzliche Attribute, wie z.B.die zwischen Absatz und Medium, die als Attribut eine Bildunterschrift enthalten kann. Eine vollstän-dige Erklärung der Syntax findet sich beispielsweise in [40].

Jedes Objekt und jede Relation ist in der Datenbank als Tabelle gespeichert. Die Tabellennamen sindim Objekt-Diagramm mit eingetragen (in Großbuchstaben beginnend mit EZ2_ neben dem zugehöri-gen Objekt/der zugehörigen Relation).

Die Objekte und Relationen werden im folgenden beschrieben.

Absatz

Das Objekt Absatz enthält den eigentlichen Text der Artikel. Durch unterschiedliche Formate, die denAbsätzen zugeordnet werden, können Strukturinformationen gespeichert werden, beispielsweise Auf-zählungen oder eingerückter Text. Die ID des Formats ist eines der Attribute des Absatzes. Neue For-mate lassen sich jederzeit hinzufügen. Das Grundformat ist unformatierter Text. Jeder Absatz enthälteine optionale Absatz- oder Zwischenüberschrift und beliebig viel Text. Einem Absatz können belie-big viele Medien-Objekte und beliebig viele Textboxen zugewiesen werden. Dazu dienen die Relati-onstabellen EZ2_REL_MEDIA und EZ2_REL_BOX. Eine Relation zwischen Absatz und Mediumenthält noch eine optionale Unterschrift, bzw. Untertitel. Die Zuordnung eines Absatzes zu einemArtikel erfolgt über die Relation EZ2_REL_PARAGRAPH. Die Reihenfolge einzelner Absätze einesArtikels ist durch die Sortierung der Relationseinträge festgelegt. EZ2_REL_PARAGRAPH enthältdazu eine Sequenz-Nummer.

Format

Das Objekt Format bestimmt das Aussehen eines Absatzes. Ein Format ist ein Text-String, der printf-Format-Befehle und HTML-Befehle enthält. Über den (s)printf-Aufruf in C/C++ kann so aus demAbsatz-Text ein formatiertes HTML-Code-Fragment erzeugt werden. Im einfachsten Fall wird umeinen Absatz herum der HTML-Absatzbefehl „...“ gelegt, wie in Abb. 77 dargestellt ist.



Über verschiedene Klassen von Absätzen lässt sich in Verbindung mit Stylesheets das Aussehen desArtikels bestimmen, und zwar ohne den Datenbestand zu verändern. Änderungen an der Stylesheet-Datei wirken sich so unmittelbar auf alle Artikel aus.

Das Formatkonzept ist darüberhinaus unabhängig von dem gewählten Ausgabeformat (hier HTML)und lässt sich problemlos an zukünftige Ausgabeformate, z. B. XML, anpassen.

Medium

Das Objekt Medium enthält alle Multimedia-Elemente eines Artikels, gegenwärtig Bilder, Audio- undVideo-Clips und DVR-Objekte (zum DVR-Format siehe Abschn. 4.1.2). Die Dateien der Multimedia-

Institution

NameZusatzStraßeOrtTelefonnummerFaxnummerE-Mail-AdresseHomepage-URL

Absatz

TextÜberschriftFormat_ID

Rubrik

NameBeschreibung

Artikel

TitelUntertitelErstellungsdatumStatusVolltext

{geordnet}enthält enthält

gehört an

Medium

MIME-TypURLEmbed-Code

Unterschrift

Format

NameCode

EZ2_RUBRIK EZ2_FORMAT

EZ2_ARTICLE

EZ2_NAME

EZ2_PARAGRAPH

EZ2_INST

EZ2_REL_RUBRIK

EZ2_REL_AUTHOR

EZ2_REL_PARAGRAPH

Info

TitelZusatzFotoTelefonnummerFaxnummerE-Mail-AdresseHomepage-URL

EZ2_INFO

EZ2_REL_AUTHOR_ARTICLE

Datum

Kontakt

Name

NameVorname

EZ2_MEDIA

Sammlung

TitelListe

EZ2_COLLECTION

EZ2_REL_BOX

ListeenthältArtikel-IDs

ordnet den Absätzendie Textboxen zu

Textbox

Artikel

EZ2_REL_MEDIA

Abb. 76. Objekt-Diagramm des DFNzine

4.4 DFNzine 107


Elemente liegen im Dateisystem des Webservers und sind über das Attribut URL des Medien-Objektszugänglich. Weitere Attribute sind der MIME-Type [8] und ein String, der Parameter für den EMBED-Tag, der zur Darstellung des Medien-Objekts im Artikel verwendet wird, enthalten kann. Für DVR-Objekte lassen sich dadurch zum Beispiel Beleuchtungswerte oder Skalierung der 3D-Objekte anpas-sen.

Artikel

Das Objekt Artikel enthält alle Artikeldaten außer dem eigentlichen Text, den Rubriken und den Auto-ren. Der Text wird, in Absätze aufgeteilt, im Objekt Absatz gespeichert, und die Rubriken und Autorenwerden über je eine Relationstabelle mit den Artikeln verknüpft.

Jedem Artikel ist eine eindeutige Nummer zugeordnet, über die Relationen zu anderen Objekten defi-niert werden. Das Datum-Feld enthält das Erstellungsdatum des Artikels. Das Status-Feld gibt an, obder Artikel bereits fertig gestellt ist oder sich noch in der Bearbeitungsphase befindet. Das Volltext-Feld enthält den gesamten Artikeltext einschließlich des Titels, des Untertitels und der Autorennamenund dient der Volltextindizierung. Der Inhalt des Volltext-Feldes sowie der Index werden automatischaktualisiert, sobald Änderungen am Artikel vorgenommen werden.

Die Verknüpfung mit den Autoren erfolgt über die Relation EZ2_REL_AUTHOR_ARTICLE. JedeVerknüpfung beinhaltet ein Kontakt-Flag, das anzeigt, ob der Autor als Kontaktperson für den Artikelzu nennen ist, denn bei mehreren Autoren wird häufig nur ein Autor als Kontaktperson genannt.

Name/Info/Institution

Diese Objekte bilden zusammen den Autor eines Artikels. Die Aufteilung auf drei Objekte dient dazu,die veränderlichen von den konstanten Attributen des Autors zu trennen, bzw. zusammengehörigeAttribute in eigenen Objekten zu speichern. Auf diese Weise brauchen die Institutionsdaten für meh-rere Autoren einer Institution nur einmal abgelegt zu werden. Autoren, welche die Institution wech-seln, erhalten ein neues Info-Objekt, behalten aber das Namens-Objekt, so dass alle ihre Artikel auchnur einer Person zugeordnet werden. Info enthält den akademischen Titel, einen optionalen Zusatz, derz. B. eine Funktion, ein Tätigkeitsfeld o. ä. enthalten kann, ein Foto des Autors, Telefonnummer, E-Mail-Adresse, und so weiter. Institution enthält den Namen, die Anschrift und Telefonnummer, usw.der Institution. Die Relationstabelle EZ2_REL_AUTHOR verknüpft die drei Objekte zu einem Autor,wobei zwei Autoren die gleiche Person darstellen, wenn das Namens-Objekt die gleiche ID hat. DieVerknüpfung EZ2_REL_AUTHOR enthält zusätzlich noch das Eingabedatum der Verknüpfung.

Rubrik

Das Objekt Rubrik enthält die Rubriken, denen die Artikel zuzuordnen sind. Dies können pro Artikelmehrere sein. Außer dem Namen der Rubrik enthält das Objekt noch eine optionale Beschreibung, diemomentan nicht verwendet wird. Die Zuordnung eines Artikels zu einer Rubrik wird in der Relations-tabelle EZ2_REL_RUBRIK abgelegt.

Das Format

%s

erzeugt angewendet auf den Absatz

Dies ist ein Probetext.

den HTML-Code

Dies ist ein Probetext.

Abb. 77. Beispiel für die Anwendung eines Formats

Sammlung

Das Objekt Sammlung stellt einen Sonderfall dar, da es mit den übrigen Objekten nur indirekt verbun-

den ist. Mit einem Sammlungs-Objekt lassen sich Artikel gruppieren und gemeinsam auf einer Web-

seite anzeigen. Ein Sammlungs-Objekt enthält eine Liste von Artikel-IDs und einen optionalen Titel.

Angewendet wird das Sammlungs-Objekt zur Erzeugung der Ausgaben der DFN-Mitteilungen und

zur Präsentation von Suchergebnissen. Die Ausgabe erfolgt über eine in zwei Frames geteilte Web-

seite, die links die Liste der Artikel enthält und rechts einen Artikel anzeigt.

4.4.3.5 Aufbau des Redaktionssystems

Dieser Abschnitt beschreibt den technischen Aufbau des Redaktionssystems, bzw. die Programme und

Dateien, aus denen es gebildet wird. Eine Beschreibung der Bedienoberfläche und des Ablaufs der

administrativen Tätigkeiten erfolgt in Abschn. 4.4.3.6.

Wie bereits erwähnt ist das Redaktionssystem komplett in C++ programmiert und besteht aus einer

Reihe von CGI-Programmen, die alle nach dem gleichen Muster aufgebaut sind. Zur Erläuterung dient

Abb. 78. Der Programmcode stützt sich auf vier wichtige Teile, die als C++-Klassen implementiert

sind.

Die Klasse HtmlTags dient der Ausgabe der HTML-Seite, die als Ergebnis des CGI-Aufrufs zurückge-

liefert wird. HtmlTags enthält Methoden, welche die wichtigsten HTML-Befehle an Standard-Out

schreiben, z. B. die Methode HtmlTags::title(), die den Title-Tag (<TITLE>Titel</TITLE>) ausgibt.

Von HtmlTags abgeleitet wird die Klasse SimplePage, die ein klassisches HTML-Seitengerüst liefert.

Durch weitere Vererbung gewinnt man Klassen, die HTML-Seiten in einem beliebigen Layout, bzw.

Design erzeugen. Die Klassen InputTable und OutputTable erleichtern das Anlegen von HTML-Tabel-

len und Formularen.

CgiEnv sorgt für die Verbindung über die CGI-Schnittstelle zum Webserver. CgiEnv liefert dem Pro-

gramm beim Start die CGI-Variablen, die Aufrufmethode und weitere Informationen. Beim Upload

von Dateien sorgt CgiEnv für deren Speicherung als temporäre Dateien und liefert die Filenamen

zurück.

Die Ora++-Klassen dienen der Kommunikation mit der Oracle-Datenbank. Über SQL-Befehle können

die DFNzine-Tabellen abgefragt und geändert werden. Diese Klassen werden in Abschn. 4.4.3.3 aus-

führlich beschrieben.

Über die Properties-Klasse schließlich können allgemeine Parameter der Programme geändert werden.

Beim Start liest die Klasse die Konfigurationsdatei ezine.cfg aus dem Filesystem, in der die Para-

meter und ihre Werte zeilenweise abgelegt sind:

Betriebssystem (IRIX)

DB-API (OCI)

Ora++HtmlTags CgiEnv

Filesystem

Properties

Programmcode

Abb. 78. Aufbau der CGI-Programme

4.4 DFNzine 109


Generell existiert für jedes Objekt ein Administrationsprogramm mit dem beschriebenen Aufbau. Jenach den vom Webbrowser übergebenen CGI-Variablen werden unterschiedlichen Aufgaben ausge-führt, im einfachsten Fall ohne CGI-Variablen wird in der Regel eine Liste der gespeicherten Instanzendes Objekts angezeigt.

4.4.3.6 Beschreibung des Redaktionssystems

Dieser Abschnitt beschreibt das Redaktionssystem des DFNzines. Aufbauend auf die zu Anfang ent-worfene Datenbankstruktur wurde eine webbasierte Text- und Medienverwaltung implementiert, diees erlaubt, Beiträge zum DFNzine zu erstellen, zu pflegen und zu löschen. Dabei wird der gesamteText in den Datenbanktabellen gespeichert, die Medien (d. h. Bilder, Ton-Beiträge, Videos, 3D-Sze-nen) werden im Filesystem abgelegt und in der Datenbank referenziert.

Name Beispielwert Beschreibung

usrbase /DFN-Zine Pfad zum Hauptverzeichnis des DFNzine vom Document-Root aus gesehen

admbase /intern/DFN-Zine Pfad zum internen Bereich (DFN-zine-Office) vom Document-Root aus gesehen

author_imgbase /DFN-Zine/author_images Pfad zum Verzeichnis der Autoren-bilder vom Document-Root aus gesehen

imgbase /DFN-Zine/images Entsprechend für Bilder

audiobase /DFN-Zine/audio Entsprechend für Audio-Dateien

videobase /DFN-Zine/video Entsprechend für Videos

dvrbase /DFN-Zine/dvr Entsprechend für DVR-Dateien

server_root /sw/DFN-Expo absoluter Pfad zum Document-Root-Verzeichnis

server_url http://www.dfn-expo.de Basis-URL des Webservers

NLS_LANG American_America.we8iso8859p1

Sprach- und Zeichensatz-Angabe für Oracle

ORACLE_HOME /opt/oracle/app/oracle/product/7.3.2

Oracle-Hauptverzeichnis

small_img_width

70 Breite (in Pixeln) des kleinen Bildes für die Vorschau

normal_img_width

150 Breite des normalen Bildes im Arti-kel

big_img_width 300 Breite des großen Bildes für die Dar-stellung im Bildfenster

Tabelle 15. Konfigurationsparameter des Redaktionssystems



Redaktionsrechner

Die Bearbeitung der Inhalte kann so von einem beliebigen Rechner aus erfolgen, wobei jedoch einigeRandbedingungen zu beachten sind.

1. Es wird ein leistungsfähiger Webbrowser benötigt, der Formulare, Frames, Javascript, Datei-Upload und SSL-Verschlüsselung beherrscht. Netscape Communicator Version 4.x und Micro-soft Internet-Explorer 4.x/5.x erfüllen diese Kriterien.

2. Der Rechner sollte über eine gute Netzverbindung zum Webserver verfügen, da die Datenmenge,die zwischen Redaktionsrechner und Webserver ausgetauscht wird, je nach Anzahl und Umfangder Mediendateien erheblich sein kann. Innerhalb eines lokalen Netzes mit mindestens 10–100Mbps sollte der Arbeitskomfort ausreichend sein. Bei zu kleinen Datenraten treten entspre-chende Verzögerungen im Arbeitsablauf auf.

3. Der Redaktionsrechner sollte über Bildbearbeitungswerkzeuge und das Desktop-Publishing-Sys-tem Quark-XPress verfügen und ausreichend leistungsfähig für Bildbearbeitungsfunktionensein.

Während der Entwicklung des DFNzine wurde als Redaktionsrechner ein PC mit Pentium II mit333 MHz und 128 MB Hauptspeicher eingesetzt. Die Anbindung an den Webserver erfolgte über meh-rere Router auf ein ATM-Interface und betrug maximal 34 Mbps. In dieser Konfiguration war einkomfortables Arbeiten mit dem Redaktionssystem möglich.

Webserver

Das Redaktionssystem ist im internen Bereich des DFN-Expo-Webservers untergebracht und dort nurüber HTTPS, d. h. mit SSL verschlüsseltes HTTP zugänglich. Für den Entwicklungsbetrieb wurde eineigenes, nicht beglaubigtes Zertifikat ausgestellt. Im Produktionsbetrieb sollten hier sowohl für denWebserver als auch für den Redaktionsrechner, bzw. den Webbrowser, beglaubigte Zertifikate und einebeidseitige Authentifikation verwendet werden, um das Redaktionssystem optimal vor Missbrauch zuschützen.

Einstiegsseite

Abb. 79 zeigt die Einstiegsseite des Redaktionssystems. Für die wichtigsten der in Abschn. 4.4.3.4beschriebenen Objekte existiert hier je eine Menü-Zeile. Dies sind die Objekte

1. Artikel

2. Autor bzw. Name

3. Institution

4. Rubrik

5. Medien-Datei

6. Format

7. Ausgabe bzw. Sammlung

Die übrigen Objekte, Absatz und Info. werden transparent mitverwaltet. Je Menüzeile enthält ver-schiedene Bearbeitungsmöglichkeiten für das Objekt, standardmäßig die Anzeige einer Liste der vor-handenen Instanzen und die Möglichkeit eines Neueintrags. Für die Artikel besteht zusätzlich dieMöglichkeit eine manuelle Aktualisierung des Volltext-Feldes durchzuführen. Ein Link am Ende derSeite führt zur Einstiegsseite des DFNzine.

Listen

Soll eine vorhandene Instanz eines Objekts bearbeitet werden, wird zunächst die Liste der entspre-chenden Instanzen aufgerufen und dann eine Instanz zur Bearbeitung ausgewählt. Abb. 80 zeigt einBeispiel für eine Liste der Autoren.

Diese Liste der Instanzen stellt für alle Objekte das jeweilige Hauptmenü für Bearbeitungsfunktionendar. In der oberen Menüzeile lässt sich die Liste aktualisieren, da es durch die Navigationstasten unddie Cache-Funktionen des Webbrowsers dazu kommen kann, dass eine veraltete Liste angezeigt wird.

4.4 DFNzine 111


Weiter ist es hier möglich, eine neue Instanz anzulegen, zur Einstiegsseite zurückzukehren oder zumDFNzine selbst zu springen.

Die Listen sind in der Regel alphabetisch oder nach Datum sortiert und in mehrere Seiten unterteilt,um die Übersichtlichkeit zu erhöhen. Die Autorenliste in Abb. 80 ist nach den Anfangbuchstaben desNachnames unterteilt. Die Instanzen sind in der ersten Spalte durchnummeriert, und zusätzlich wirddie interne, eindeutige ID angegeben, die der Datenbank zur Herstellung der Relationen dient. Für dieRedaktion ist diese ID ohne Bedeutung.

In der rechten Spalte sind die Bearbeitungsfunktionen in einem Menü untergebracht. Standardfunktio-nen sind das Bearbeiten und das Löschen der Instanz. Einige Objekte, wie z. B. die Artikel, verfügenüber weitere Bearbeitungsfunktionen, die im weiteren Verlauf erläutert werden.

Bei Neuanlage (z. B. eines Autors) werden die Attribute in Textfelder eines HTML-Formulars einge-geben und abgeschickt. Das CGI-Programm auf dem Webserver nimmt dann die Speicherung in derDatenbank vor. Bei der Bearbeitung werden die Textfelder im HTML-Formular mit den Werten ausder Datenbank vorbelegt und können geändert werden. Ein Beispiel zeigt Abb. 81.

Abb. 79. Einstiegsseite des Redaktionssystems



Artikelerstellung

Die Erstellung eines Artikel läuft, im Gegensatz zur Erstellung anderer Objekte, in mehreren Schrittenab. Dabei wird unterschieden zwischen dem Anlegen eines Artikels und dem Hinzufügen von Text undMedien. Das Anlegen des Artikels ist der erste Schritt und umfasst die Eingabe der Stammdaten.Damit sind Informationen über den Artikel gemeint, nicht der Artikel selbst. Dies entspricht demInhalt des Artikel-Objekts, umfasst also die Daten

• Erstellungsdatum,• Überschrift,• Unterüberschrift,• Status

sowie zusätzlich die Autoren und die Rubriken. Letztere werden aus Listen, welche die aktuell verfüg-baren Instanzen anzeigen, ausgewählt. Dieser erste Schritt wird durch ein HTML-Formular mit dennotwendigen Eingabefeldern realisiert. Das Abschicken dieses Formulars löst noch keine Datenbank-

Abb. 80. Liste der Autoren mit Bearbeitungsfunktionen

4.4 DFNzine 113


Einträge aus, sondern erzeugt ein zweites Formular. In diesem zweiten Schritt werden die Kontaktper-sonen unter den gewählten Autoren bestimmt. Alle bis hier gesammelten Informationen werden durchAbschicken des zweiten Formulars in der Datenbank gespeichert. Damit ist ein neuer Artikel angelegtworden, der jedoch noch keinen Text enthält.

In weiteren Schritten werden die Absätze hinzugefügt. Während dieser Phase wird der Artikel in einerArbeitsansicht gezeigt, die es über HTML-Links ermöglicht, neue Absätze einzufügen oder beste-hende zu bearbeiten, siehe Abb. 82. In die Arbeitsansicht gelangt man nicht automatisch, sondernwählt im Optionen-Menü des Artikels den Punkt „Absätze bearbeiten“. Die Eingabe des Textes erfolgtmittels HTML-Textboxen. Unterhalb der Textbox kann aus einer Liste das gewünschte Absatzformatausgewählt werden. Durch Abschicken des Eingabe-Formulars wird der Absatz in der Datenbankabgelegt und die Verknüpfung mit dem Artikel hergestellt.

In der Arbeitsansicht können ebenfalls jedem Absatz auch Mediendateien und Textboxen hinzugefügtwerden. Ein entsprechender Link führt auf eine Auswahlbox mit vorhandenen Medien. Der gewähltenMediendatei kann ein optionaler Untertitel beigefügt werden. Textboxen sind spezielle Artikel ohnebestimmten Autor, ohne Abstrakt und in der Regel (aber nicht zwingend) ohne Bilder. Textboxen bein-

Abb. 81. Dialog „Autor bearbeiten“



halten Zusatzinformationen zu den Artikeln und werden in der rechten Spalte eines Artikels, grau hin-terlegt, dargestellt. Textboxen erscheinen nicht den Artikelübersichten oder als Ergebnis derVolltextsuche.

Jeder Arbeitsvorgang in der Arbeitsansicht führt nach einem oder mehreren Schritten wieder zurückauf die aktualisierte Arbeitsansicht, so dass Änderungen sofort sichtbar sind. Von der Arbeitsansichtkann in die Präsentationsansicht (und wieder zurück) gewechselt werden, die den Artikel so zeigt, wieer später vom Leser abgerufen werden wird.

Abb. 82 zeigt die Absätze 12 bis 14 eines Artikels. Absatz 13 enthält bereits ein Bild mit Bildunter-schrift. Die Links unter dem Bild ermöglichen weitere Bearbeitungsschritte, so z. B. Ändern der Bild-unterschrift oder Verschieben des Bildes im Artikel. Bild steht hier analog für Mediendatei, d. h. dieanderen Medientypen werden entsprechend behandelt.

Abb. 82. Arbeitsansicht eines Artikels

4.4 DFNzine 115


Mediendateien

Im Unterpunkt Mediendateien werden alle im DFNzine verwendeten Mediendateien verwaltet. Dieeigentliche Datei wird im Filesystem gehalten, während die Dateiinformationen, d. h. Filename undFiletyp, in der Datenbank stehen. Dabei werden alle Medientypen zunächst gleich behandelt, also auchzusammen in einer Tabelle gespeichert.

Die Einbindung der Mediendateien erfordert im 1. Schritt die Speicherung und damit den Upload aufden Webserver. Der Upload von Dateien ist spezifiziert in [24] und wird durch die bereits beschriebeneKlasse CgiEnv durchgeführt. Das Formular zum Upload einer Mediendatei zeigt Abb. 83. Vor demUpload wird der Filetyp ausgewählt. Anhand dieser Information wird im 2. Schritt die Konvertierungauf dem Webserver durchgeführt. Bis jetzt ist die automatische Konvertierung von Bilddateien in denFormaten TIFF, JPEG, GIF und EPS und von Audio-Dateien im WAV-Format implementiert. Video-Dateien müssen im MPEG-1-Format und 3D-Objekte im DVR-Format vorliegen. Alle anderen Datei-typen werden zurückgewiesen.

Die Konvertierung der Bilddateien erfolgt mit den Public-Domain-Programmen convert aus der Ima-geMagick-Sammlung und pnmscale aus dem Netpbm-Toolkit. Für das Rendering von EPS-Dateien

Abb. 83. Hinzufügen einer Mediendatei



wird zusätzlich Ghostscript verwendet. Dabei wird auf die Erfahrungen zum Thema Antialiasing ausdem RTB-Nord-Projekt „Onlinedokumente“ [31] zurückgegriffen, und entsprechende Methoden kom-men hier zum Einsatz.

In die Produktionskette wurde auch eine Color-Management-Komponente eingebaut. TIFF-Dateienmit integriertem ICC-Profil, wie sie für die Druckversion der DFN-Mitteilungen verwendet werden,werden mit Hilfe eines selbst entwickelten Konverters (tiff2ppm) zunächst ins PPM-Format gewandelt,wobei auch eine Umwandlung des Farbprofils ins sRGB-Profil erfolgt, und anschließend ins GIF- oderJPEG-Format. Auf diese Weise wird sichergestellt, dass auch Bilder, die schon ein Farbprofil für denDruck erhalten haben, im Web farblich korrekt wiedergegeben werden.

Nach der Konvertierung werden dem Benutzer die Ergebnisse des Vorgangs angezeigt. Im 3. Schrittkann er die Speicherung der neuen Mediendatei im Filesystem und in der Datenbank anordnen.

4.4.4 Stand

Während der Implementierung des Redaktionssystems sind bereits Artikel erstellt worden, um dieFunktionalität zu testen. Dazu wurden alte Ausgaben der DFN-Mitteilungen verwendet, die nachAbschluss der Tests nicht gelöscht zu werden brauchten, sondern als Grundbestand weiterhin vorhan-den sind. Zudem wurde jede während des Projektzeitraums neu erschienene Ausgabe in den Bestandeingepflegt. Zum Projektende umfasst das DFNzine damit die insgesamt 75 Artikel der Ausgaben 46–50.

Das Redaktionssystem arbeitet stabil und in der gegenwärtigen Installation ausreichend performant.Die Antwortzeiten beim Aufruf von Artikeln liegen im Bereich von 2 bis 3 Sekunden. Da Webserverund Datenbank-Server in der Projektkonfiguration getrennt sind und die Netzverbindung zwischenihnen lediglich 10 Mbps beträgt, lassen sich diese Zeiten aller Voraussicht nach noch verkürzen.

Die Nutzung des DFNzine ist während der Entwicklungsphase meist stetig gewachsen. Seit der CeBit1999 läuft ein öffentlicher Probebetrieb. Dazu wurden Links sowohl vom DFN-Webserver als auchvon den bestehenden DFN-Mitteilungen im Web auf das DFNzine gelegt. Ende 1999 besuchten imtäglichen Durchschnitt zwischen 15 und 20 Leser das DFNzine, was etwa 450 bis 600 Besuchen proMonat entspricht. Abb. 84 zeigt die Nutzung des DFNzine von Februar 1999 bis Mitte Januar 2000.

Der überwiegende Teil der Leser stammt aus Deutschland, ein geringer Teil aber auch aus Österreichund der Schweiz.

4.4.5 Ausblick

In Absprache mit dem DFN-Verein ist geplant, das DFNzine nach einer Übergangsphase in den Web-server des DFN-Verein zu integrieren und gleichzeitig den Produktionsbetrieb aufzunehmen. Damitgeht auch die redaktionelle Arbeit, d. h. das Erstellen und Pflege der DFNzine-Artikel, in die Hand derDFN-Geschäftsstelle über. Die Länge der Übergangszeit soll ein halbes Jahr nicht überschreiten undwird in Gesprächen mit der DFN-Geschäftsstelle festgelegt. Während dieser Zeit findet eine Einwei-sung der Redaktion in die Bedienung des Redaktionssystems statt.

Abb. 84. Nutzung des DFNzine im Probebetrieb von Februar 1999 bis Mitte Januar 2000

4.5 Entwicklung einer Suchmaschine 3. Ordnung 117


4.5 Entwicklung einer Suchmaschine 3. Ordnung

4.5.1 Beschreibung des Projekts

4.5.1.1 Motivation

Internet-Suchmaschinen haben die Aufgabe, die zu einer gegebenen Suchanfrage relevanten Doku-mente schnellstmöglich aus dem World Wide Web (WWW) zu ermitteln. Es existieren zur Zeit zweiprinzipielle Ansätze zur Lösung dieses Problems: Index-Suchmaschinen und Meta-Suchmaschinen.

Index-Suchmaschinen durchsuchen das WWW in regelmäßigen Abständen und legen die gefundenenDokumente in einem lokalen Indexspeicher ab. Suchanfragen können dann mit Hilfe dieses Indexspei-chers beantwortet werden. Der Indexspeicher ermöglicht einen schnellen Zugriff auf diejenigen Doku-mente, die die gegebenen Suchterme enthalten.

Die heute verwendeten Index-Suchmaschinen erlauben die Verwendung von booleschen Operatoren,um komplexere Suchanfragen zu konstruieren. Die zur Zeit realisierten Index-Suchmaschinen errei-

chen einen maximalen Abbildungsgrad1 von ca. 35 %. Dies liegt einerseits an der Problematik, alle imWWW enthaltenen Dokumente zu ermitteln und andererseits an den hohen technischen Anforderun-gen, die an den Index-Speicher gestellt werden. So erfassen die größten Internet-Suchmaschinen heut-zutage ca. 110 Millionen Dokumente aus dem WWW. Aufgrund der großen Anzahl an Dokumentenkönnen die meisten Suchmaschinen nur einfachste Relevanzbeurteilungen durchführen, z. B. in derArt, dass einfach alle Dokumente als relevant betrachtet werden, die die gegebenen Suchterme enthal-ten. Dies schlägt sich in einer geringen Präzision nieder, d. h. dass die Antwortmengen von großenSuchmaschinen einen hohen Anteil nicht-relevanter Dokumente enthalten.

Meta-Suchmaschinen wurden aus der Erkenntnis heraus entwickelt, dass einzelne Index-Suchmaschi-nen zwar nur einen maximalen Abbildungsgrad von ca. 35 % erreichen, aber die Kombination dergrößten Index-Suchmaschinen das WWW zu ca. 65 % abbilden. Eine Meta-Suchmaschine fragt dem-nach mehrere Index-Suchmaschinen parallel ab und bildet aus den erhaltenen Antwortmengen die Ver-einigungsmenge, indem die Ergebnisse kombiniert und doppelte Einträge eliminiert werden. Dies istein wirkungsvoller Ansatz, um den Abbildungsgrad zu erhöhen, um also ein größere Anzahl Doku-mente zu erfassen. Dies ermöglicht eine breitere Suche und erhöht somit die Wahrscheinlichkeit, rele-vante Dokumente zu ermitteln.

Sowohl die Index- als auch die Meta-Suchmaschinen leiden unter prinzipiellen Nachteilen. Das grund-sätzliche Problem ist hauptsächlich die Größe des WWW, also die Anzahl der zu erfassenden Doku-mente. Die größten Index-Suchmaschinen vermögen gerade einmal ein Drittel der im WWWbefindlichen Dokumente abzubilden. Dennoch ist diese Anzahl so groß, dass nur einfachste Methodenzur Relevanzbestimmung eingesetzt werden können, damit die Antwort auf eine Suchanfrage inakzeptabler Zeit gegeben werden kann. Meta-Suchmaschinen verbessern zwar den Abbildungsgrad,haben jedoch kaum Einfluss auf die ermittelten Dokumente. Dies liegt daran, dass der Meta-Suchma-schine nur die URL der ermittelten Dokumente bekannt ist und nicht das Dokument selbst und somit

1. mit stark fallender Tendenz.

D okum en te G a the re r/Indexe r B roke r

index ie rteD okum en te

D a tenb ank

In te rne t

Abb. 85. Prinzip der Index-Suchmaschine



keine tiefergehende Relevanzprüfung durchgeführt werden kann. Demzufolge enthalten die durch-schnittlichen Antwortmengen der Meta-Suchmaschine zwar mehr relevante Dokumente, als die derIndex-Suchmaschinen, aber auch mehr nicht-relevante Dokumente.

4.5.1.2 Projektziel

Das generelle Problem bei der Entwicklung einer Internet-Suchmaschine ist die Größe des WWW. Dievollständige Abbildung aller Dokumente des WWW in einem Index-Speicher übersteigt die momenta-nen technischen Möglichkeiten, so dass heutige Index-Suchmaschinen eine nur unvollständige Inde-xierung durchführen, was sich auf die Qualität der Suchmaschine auswirkt.

Mit der Entwicklung einer Level-3-Suchmaschine soll ein Divide-And-Conquer-Ansatz verfolgt wer-den. Dieser Lösungsansatz basiert auf der Idee, dass ein großes, praktisch zunächst unlösbares Pro-blem in mehrere kleinere Teilprobleme aufgeteilt werden kann, die jeweils lösbar sind. Das Ziel istdemnach nicht die Entwicklung einer allgemeinen, umfassenden Suchmaschine, sondern die Entwick-lung kleiner, spezialisierter Suchmaschinen, die jeweils einen kleinen Bereich des WWW vollständigabbilden können. Die Spezialisierung erfolgt bei Level-3-Suchmaschinen durch Spezifikation einesThemas, d. h. dass eine Level-3-Suchmaschine nur thematisch ähnliche Dokumente erfasst, wodurchsich die Anzahl der abzubildenden Dokumente erheblich verringert. Dies ermöglicht die Realisierungeiner aufwendigeren Verarbeitung der Dokumente, insbesondere in Hinblick auf eine Volltext-Indexie-rung und Relevanzfilterung. Das Ziel ist die Entwicklung einer themenspezifischen Suchmaschine, diedas gegebene Thema möglichst umfassend und präzise abzubilden vermag.

In te rne t

In d e x-S u ch m a sc h in e n

Benutzer-Anfrage

Antwort

Benutzer

Leve l 1

Leve l 2

R e levanz filte r

Them en-beschre ibung

Leve l 3

M e ta -S uchm asch inethem enbezog ene D okum ente

relevan te D okum ente

Adm in istra tiveSeite

Benutzerseite

D a te nb a sis

Abb. 86. Level-3-Suchmaschine



4.5.2 Realisierung des Projektes

Die Elemente einer Level-3-Suchmaschine lassen sich in zwei Funktionsgruppen einteilen. Die admi-nistrative Seite und die Benutzerseite, wie in Abb. 86 dargestellt.

Die Benutzerseite nimmt Suchanfragen entgegen und beantwortet sie mit Hilfe der themenspezifi-schen Datenbasis. Die administrative Seite befasst sich hauptsächlich mit der Ermittlung neuer Doku-mente und der Verwaltung der Datenbasis. Die Erzeugung einer neuen Level-3-Suchmaschine beginntmit einer Themenbeschreibung, da die Dokumente in der Level-3-Datenbasis themenspezifisch seinmüssen. Die Themenbeschreibung besteht aus einem booleschen Ausdruck, der die Operatoren ANDund OR sowie Anführungszeichen zum definieren von Zeichenketten enthalten darf. Eine typischeThemenbeschreibung für eine Level-3-Suchmaschine sähe wie folgt aus:

Beispiel: Themenbeschreibung zum Thema „Java“

Java AND Applet

OR Java AND Virtual AND Machine

OR JDK

Diese Themenbeschreibung könnte zur Erzeugung einer Level-3-Suchmaschine zum Thema „Java“verwendet werden. Zur Erzeugung einer Datenbasis werden aus dem WWW diejenigen Dokumenteermittelt, die dieser Themenbeschreibung entsprechen. Dazu wird die Themenbeschreibung als Such-anfrage an eine Meta-Suchmaschine gegeben, deren Antwortmenge die gesuchten Dokumente enthält.Zur Generierung einer Datenbasis sind Meta-Suchmaschinen aufgrund des erweiterten Suchraumesbesser geeignet als Index-Suchmaschinen, da die Datenbasis das Thema der Level-3-Suchmaschine soumfassend wie möglich abdecken sollte. Da nur die Dokumente eines spezifischen Themas in dieDatenbasis aufgenommen werden, benötigt eine themenspezifische Level-3-Suchmaschine weitausweniger Indexspeicher, als allgemeine Index-Suchmaschinen:

Generell besitzen Level-3-Suchmaschinen den Vorteil höherer Precision gegenüber Index-Suchma-schinen, da die Level-3-Datenbasis hauptsächlich themenspezifische Dokumente enthält, d. h. dass dieAntwortmengen nur Dokumente zu dem gesuchten Themenbereich enthält. Dies ist besonders wir-kungsvoll bei allgemeinen Suchbegriffen. Die im Vergleich zu Index-Suchmaschinen kleinen Daten-bestände erlauben neben kürzeren Antwortzeiten eine aufwendigere Relevanzfilterung, die einehöhere Precision erwarten lässt. Es lassen sich aufwendigere Broker und Indexer erstellen, und dervorhergehende Relevanzfilter erhöht die Precision nochmals durch Elimination nicht-relevanter Doku-mente. Da der Level-3-Suchmaschine eine Meta-Suchmaschine mit großem Abdeckungsgradzugrunde liegt, lässt sich erwarten, dass das gegebene Thema im Bereich der Themenbeschreibungumfassend abgebildet wird.

Im Rahmen dieser Diplomarbeit wurde die Grammatik des Harvest-Brokers um den logischen Opera-tor NEAR erweitert. Dieser Operator liefert WAHR, wenn die minimale Wort-Distanz zwischen bei-den Operanden einen gegebenen Wert n unterschreitet.

Beispiel: Wort-Distanz

"The quick brown fox jumps over the garden fence."

Distanz (fox, garden) = 4

Die Erweiterung wurde in zwei Schritten vorgenommen. In einem ersten Schritt werden alle NEAR-Operatoren durch AND-Operatoren ersetzt. Dies erfordert, dass die Suchanfrage eine logische Tiefevon 1 besitzt, also keine Klammerstrukturen enthält, da die Substitution ansonsten nicht durchgeführtwerden kann, ohne die vorhandenen Klammern aufzulösen. Eine mögliche Lösung wäre es, die vor-handenen Suchanfrage höherer Ordnung durch logische Umformungen, also durch Ausklammern, ineine äquivalente Suchanfrage der Tiefe 1 umzuformen. Die Operanden der ersetzten NEAR-Operato-ren werden paarweise in einer Liste gesichert. Wenn die Antwortmenge des Indexers vorliegt, dannwerden die Objekte der Antwortmenge daraufhin untersucht, ob sie das NEAR-Kriterium erfüllen,ansonsten werden diese Objekte aus der Antwortmenge entfernt. Zur Überprüfung des NEAR-Kriteri-ums werden die SOIF-Objekte aus der Datenbasis des Brokers gelesen und der Dokumententext extra-



hiert, d. h. dass alle Dokumente in der Datenbasis als Volltext indexiert werden müssen. Der NEAR-

Operator unterstützt die Optionen „Wortgrenzen beachten“ und „Groß-/Kleinschreibung“ aus der Bro-

ker-Eingabemaske.

Bei der Darstellung der Antwortmenge ist es vorteilhaft, zu jedem ausgegebenen Objekt den zugehöri-gen Titel auszugeben, um die Aussagekraft zu erhöhen. Dies ist bei der verwendeten Harvest-Software

jedoch nicht der Fall, so dass die hierfür notwendigen Erweiterung vorgenommen werden mussten. Es

ist ein zusätzlicher Zugriff auf die SOIF-Datenbasis des Brokers notwendig, wobei zu jedem relevan-

ten Dokument der zugehörige Dokumententext ermittelt wird. Aus diesem Dokumententext wird danndas title-Tag gesucht, um den Titel des Dokumentes zu erhalten. Dieser wird in einer Variablen abge-

legt, die in der Broker-Konfigurationsdatei verwendet werden kann, um den Titel des Dokumentes

auszugeben.

Abb. 87. Screenshot Suchergebnisse ("Data Warehouse")



4.5.2.1 Administration

Das wichtigste Element einer Level-3-Suchmaschine ist neben der Benutzerschnittstelle eine adminis-trative Schnittstelle. Diese muss Möglichkeiten zur Verwaltung, Bearbeitung und Optimierung derLevel-3-Datenbasis zur Verfügung stellen, um eine hohe Präzision bei Suchanfragen zu gewährleisten.

Nach Eingabe eines System-Passwortes und Auswahl einer Level-3-Suchmaschine kann eine Aktionzur Administration der Level-3-Suchmaschine ausgewählt werden:

• Broker- und Gatherd-Prozesse startenStarten der notwendigen Harvest-Prozesse, die die Benutzeranfragen verarbeiten.

• Dokumente in die Datenbasis übernehmenNachdem die relevanten URLs ermittelt und gefiltert wurden, werden die zugehörigen Doku-mente in die Datenbasis des Brokers übernommen.

• Log-File zurücksetzenDas Log-File enthält Statusmeldungen über alle administrativen Vorgänge der Level-3-Suchma-schine. Hier kann es gelöscht werden.

• Datenbasis bearbeitenDirektes Bearbeiten der URLs in der Datenbasis. Es können URLs gelöscht, zugefügt undgesucht werden.

• Relevanzfilter bearbeitenBearbeitung der Relevanzfilter Parameter

• Relevanzfilter auf die Datenbasis anwendenDie Relevanzfilterung kann auf die Datenbasis angewendet werden, um z. B. nachträgliche Rele-vanzfilter Parameter anzuwenden.

• Themenbeschreibung bearbeitenErweiterung und Bearbeitung der Level-3 Themenbeschreibung.

• Datenbank löschenLöschen der gesamten Datenbank und aller Dateien und Prozesse.

• Neue URLs ermittelnStarten eines Prozesses, der mittels einer Meta-Suchmaschine neue, themenrelevante URLsermittelt und der Level-3-Datenbasis zufügt.

• Begutachtung von neuen URLsManuelle Begutachtung von neu ermittelten URLs. Dieser Punkt ist nur bei halb-automatischerRelevanzfilterung notwendig.

• Begutachtung verworfener URLsManuelle Begutachtung von verworfenen URLs, die durch automatische Relevanzfilterung aus-gefiltert wurden.

• Negativliste verwaltenErweiterung oder Verkleinerung der Negativliste. In der Negativliste stehen die URLs, dieunmittelbar verworfen werden, nachdem sie ermittelt wurden.

• Negativliste verifizierenAnwendung des Relevanzfilters auf die Negativliste, um relevante, oder nicht-existente Einträgeautomatisch zu entfernen.

4.5.2.2 Relevanz-Filterung

Die Relevanz-Filterung ist ein wichtiges Element um die Präzision der Level-3-Suchmaschine zu ver-bessern. Je weniger nicht-relevante, also nicht-themenbezogene, Dokumente in der Datenbasis derLevel-3-Suchmaschine enthalten sind, desto besser wird die durchschnittliche Precision bei Benutzer-suchanfragen sein.

Es ist ohne grammatikalische Analyse des Dokumenteninhaltes nicht möglich, die Relevanz einesDokumentes zu einer Suchanfrage mit Sicherheit zu bestimmen. Dies liegt einerseits daran, dass dieFormulierung einer Suchanfrage eine grobe Vereinfachung des eigentlichen Suchproblems darstellt,während andererseits nur bestimmte Eigenschaften oder Strukturen überprüft werden können. Als Bei-spiel sei ein Suchproblem gegeben, welches die Technik von Schweizer Uhren zum Ziel hat. Dies lässtsich als Suchanfrage mittels weniger Suchterme umschreiben:



Suchanfrage: Schweiz AND Uhr AND Technik

Es sei eine Volltextsuche angenommen, in der ein Suchterm „Uhr“ auch auf „Uhrmacher“ passt.Dann könnten folgende Dokumente als relevant ermittelt werden:

Dokument A: „Die Schweizer Uhrmachertechnik zählt zu den besten der Welt...“

Dokument B: „...eine Spieltechnik so präzise wie eine Schweizer Uhr...“

Dabei wird es sich bei Dokument A um ein Dokument über Schweizer Uhrentechnik handeln, wäh-rend Dokument B wahrscheinlich einen Sportler beschreibt. Beide würden einen ähnlichen RSV erzie-len und vermutlich als relevant eingestuft. Es ist also ersichtlich, dass bei der Konzeption einerRelevanzfilterung versucht werden muss, möglichst unabhängige Kriterien zu entwickeln, die einepräzise Relevanzbeurteilung zulassen, um die Streuung möglichst gering zu halten.

Die Level-3-Relevanz-Filterung wirkt sich auf die an den Gatherer übergebenen URLs aus. Das Pro-blem der Relevanz-Filterung kann als Ranking-Problem gelöst werden. Es muss zu jedem Dokumentein RSV ermittelt werden, der die Relevanz des Dokumenteninhaltes zu einer gegebenen Suchanfrageausdrückt. Aus den Dokumenten und einer Suchanfrage lassen sich verschiedene Kriterien K erstellenund die Übereinstimmung zueinander überprüfen. Ein Dokument, das ein Kriterium Ki voll erfüllt,erhielte beispielsweise einen Parameter Ki=1, ein Dokument, das dieses Kriterien nur zur Hälfte erfüllt

erhielte für diesen Parameter einen Wert von 0,5. Weiterhin lassen sich die verschiedenen Kriteriengewichten, so dass ein Kriterium K1 wichtiger sein kann, als ein Kriterium K2. Mit einer Gewichtung

g lässt sich dann die Berechnung eines RSV aus N Kriterien und N Gewichten für jedes Dokumentbestimmen:

Gleichung 1: Berechnung RSV

Die Relevanz eines Dokumente ist im Allgemeinen leichter zu verstehen, wenn der RSV in einemBereich von 0 % bis 100 % liegt, so dass ersichtlich ist, inwiefern ein Dokument mit der Suchanfrageübereinstimmt. Dies lässt sich durch zwei weitere Bedingungen erreichen:

Bedingung 1:

Bedingung 2:

Die in der Level-3-Suchmaschine implementierte Relevanzfilterung berechnet für jedes Dokumenteinen RSV nach Gleichung 1 unter Beachtung von Bedingung 1 und Bedingung 2.

Die Überprüfung der Dokumente anhand verschiedener Kriterien setzt voraus, dass der gesamteDokumententext bekannt ist. Dabei ergeben sich zwei Probleme: Zuerst muss ein Dokument in mög-lichst kurzer Zeit aus dem Internet geladen werden und anschließend muss der gesamte Text desDokumentes extrahiert werden. An dieser Stelle zeigt das Konzept der Level-3-Suchmaschinen seinenwichtigsten Vorteil, da beide Probleme bedingt durch die relativ kleinen Datenmengen in der Level-3-Datenbasis lösbar sind. Level-1-Suchmaschinen, also Index-Suchmaschinen, können Dokumente auf-grund der großen Datenmenge meist nicht als Volltext verarbeiten, sondern extrahieren bestimmteSchlüsselwörter und Textelemente. Level-2-Suchmaschinen, die Meta-Suchmaschinen, haben prinzi-piell keinen Zugriff auf den Dokumententext sondern müssen sich auf die Relevanz-Filterung derzugrunde liegenden Index-Suchmaschinen verlassen.

Nachdem die zur Themenbeschreibung passenden URLs für die Level-3-Datenbasis von MetaGerermittelt worden sind, werden die zu diesen URLs gehörenden Dokumente geladen. Um den Ladevor-gang zu beschleunigen, werden die Dokumente in P parallelen Prozessen geladen. Außerdem wurde

RSV giKii

N

∑=

gii 1=

N

∑

K 0 K 1≤ ≤( )∀



ein TIMEOUT definiert, der ausdrückt, wie viele Sekunden der Ladevorgang für ein einzelnes Doku-ment dauern darf, bis das Dokument verworfen wird. Für die Level-3-Suchmaschine wurden die Para-meter P=32 und TIMEOUT=60s gewählt. Kürzere TIMEOUT-Zeiten erhöhen die Wahrscheinlichkeit,dass Dokumente die sich auf langsamen oder ausgelasteten Servern befinden nicht geladen werden.Längere TIMEOUT-Zeiten erhöhen die Gesamtladezeit. Die Anzahl paralleler Prozesse wird begrenztdurch die zur Verfügung stehende Rechenleistung. Da sich die Level-3-Suchmaschine auf einemWWW-Server befindet, sollte dieser Parameter so klein wie möglich gewählt werden, um andere Netz-aktivitäten nicht zu behindern. Außerdem muss berücksichtigt werden, dass mitunter mehrere Level-3-Suchmaschinen parallel auf derselben Maschine laufen. Eine Verbesserung des Ladevorganges wäredie Verwendung eines einzelnen Prozesses, der mehrere parallele nicht-blockierende Verbindungenverwalten kann. Diese Methode hat sich in Versuchen bisher jedoch als zu instabil für die Level-3-Suchmaschine erwiesen.

Die Extraktion des Volltextes aus den Dokumenten erfolgt unmittelbar nachdem das Dokument erfolg-reich geladen wurde. Es werden alle HTML-Tags entfernt, sowie JavaScript-Programme. Außerdemwerden folgende Textbereiche aus dem Dokumententext extrahiert:

• Titel• Meta-Tags• Überschriften

Diese Textbereiche haben in einem Dokument eine höhere Aussagekraft und werden bei der RSV-Berechnung höher bewertet als der Dokumententext.

Für die in der Level-3-Suchmaschine implementierten Relevanz-Filterung werden für jedes Dokumentdie folgenden Kriterien ausgewertet, aus denen ein RSV berechnet wird:

• K1: Term-Vorkommen: „Anzahl der Terme im Dokument“

• K2: Term-Kontext: „Entfernung der Suchterme zueinander“

• K3: Term-Verteilung: „Verteilung der Terme im Dokument“

• K4: Wort-Varianz: „Anzahl verschiedener Wörter im Dokument“

Außerdem besteht die Möglichkeit, zusammenhängende Dokumente in der Datenbasis zu ermitteln,um diese Zusammenhänge beizubehalten. Optional kann ein Ranking der Suchmaschine AltaVistadurchgeführt werden, das aus der Anzahl der Backlinks die Popularität eines Dokumentes bestimmt,mit dem Ziel, besonders populäre Dokumente in die Datenbasis zu übernehmen.

Die aus dem Dokumententext berechneten Werte K1 bis K4 werden zusammen mit der zugehörigen

URL abgespeichert. Aus diesen Kriterien wird gemäß Gleichung 1 der RSV berechnet. Die Werte fürdie Gewichte g1 bis g4 können durch den Administrationspunkt „Relevanzfilter bearbeiten“ variiert

werden. Diese Vorgehensweise hat den Vorteil, dass der zeitaufwendige Vorgang, das Laden der Doku-mente und die Berechnung der Kriterien K1 bis K4 nur einmal durchgeführt werden muss. Anschlie-

ßend erfolgt die Berechnung des RSV, wobei auf die aktuellen Gewichtungen der einzelnen Kriterienzurückgegriffen werden kann.

Die Berechnung des RSV auf Grundlage der vorher berechneten Kriterien wird bei verschiedenenZeitpunkten durchgeführt.

Bei automatischer Übernahme von URLs in die Datenbasis:

• Erzeugung einer neuen Level-3-Suchmaschine• Ermitteln neuer URLs• Begutachtung verworfener URLs

Bei manueller Übernahme von URLs in die Datenbasis:

• Begutachtung neuer URLs• Begutachtung verworfener URLs

Die folgenden Kapitel erläutern die Wirkungsweise der verschiedenen Kriterien, aus denen sich derRSV zusammensetzt.



4.5.2.3 Kriterium K1: Term-Vorkommen

Der Berechnung des Kriteriums K1 wird die Anzahl der im Dokument vorkommenden Suchterme Np

zugrunde gelegt. Entscheidend ist die Tatsache, dass ein Suchterm im Dokument enthalten ist undnicht die Häufigkeit des Suchterms im Dokument. Ein Dokument erhält ein K1=1, wenn alle Such-

terme der Suchanfrage im Dokument enthalten sind.

Das Kriterium K1 ist das Verhältnis der im Dokument vorkommende Suchterme Np zu der Anzahl der

Suchterme NQ:

Gleichung 2: Kriterium Term-Vorkommen

Beispiel: Term-Vorkommen

Suchanfrage: "Bank AND Geld AND Haus“NQ=3

Dokumente: "Bring das Geld zur Bank !"

"Lieber mit Geld als ohne Geld"

4.5.2.4 Kriterium K2: Term-Kontext

Die Idee zur Berechnung des Kriterium K2 „Term-Kontext“ entstammt der Inquirus-Suchmaschine der

NEC Research Laboratories. Die Grundüberlegung basiert auf der Annahme, dass Terme, die in einemKontext stehen auch eine räumliche Nähe innerhalb des Dokumentes besitzen. Je kleiner der Abstandzweier Suchterme innerhalb des Dokumentes ist, desto höher ist die Wahrscheinlichkeit, dass beideSuchterme in einem Kontext stehen. Aus der Summe der Abstände aller Suchterme innerhalb einesDokumentes zueinander lässt sich dann ein Wert ermitteln, der mit der Relevanz des Dokumenteszusammenhängt.

Definition:

Die Funktion dist(D, t1, t2) liefert den minimalen Abstand der Terme t1 und t2 in einem Doku-ment D. Wenn nicht beide Terme in D vorhanden sind wird eine 0 zurück gegeben.

Mit Hilfe der dist()-Funktion lässt sich eine Berechnungsvorschrift für das Kriterium K2 für ein Doku-

ment D aufstellen:

Gleichung 3: Kriterium Term-Kontext

Die Konstante NQ bezeichnet die Anzahl der Suchterme in der Suchanfrage. Die Konstante C definiert

einen Schwellwert, ab dem die Distanz zweier Terme als zu groß angenommen wird. Die beiden Sum-men addieren mit Hilfe der dist()-Funktion die minimale Entfernung aller Suchterme zueinander imDokument D. Der subtrahierte Wert Dmin bezeichnet die minimal mögliche Distanz von NQ Suchter-

men in einem Dokument, die dann erreicht wird, wenn alle Suchterme in jeweils unmittelbarer Nach-barschaft zueinander stehen.

Gleichung 4: Minimale Distanz von N Suchtermen

K1Suchterme im Dokument

Suchterme in der Suchanfrage------------------------------------------------------------------------

Np

NQ-------= =

K2 1min dist D ti tj, ,( ) C( , )

j i 1+=

NQ

∑i 1=

NQ 1–

∑ Dmin–

C Dmin×-----------------------------------------------------------------------------------------------------------------–=

Dmin12--- NQ

2 NQ–( )=



Der Wert Dmin wird von der Summe über alle Suchterm-Distanzen subtrahiert und definiert das ideale

Dokument, welches einen K2-Wert von 1 erhält. Wenn die Summe über alle Suchterm-Distanzen den

Wert C überschreitet, erhält das Dokument einen K2-Wert von 0. In der momentanen Implementierung

der Relevanzfilterung besitzt C den Wert 30.

Das Kriterium K2 „Term-Kontext“ stellt eine relativ zuverlässige Aussage über die Relevanz eines

Dokumentes zu einer Suchanfrage dar, die zudem schwer durch Spamming-Maßnahmen zu manipu-lieren ist. Das ideale Spamming-Dokument müsste eine große Anzahl von Suchtermen enthalten, diealle miteinander in Nachbarschaft stehen. Somit stellen die beiden Kriterien K1 „Term-Vorkommen“

und K2 „Term-Kontext“ zwei wichtige Aussagen über ein Dokument dar und sollten in einer Rele-

vanz-Filterung mit hohen Gewichten versehen werden.

4.5.2.5 Kriterium K3: Term-Verteilung

Grundlage des Kriteriums K3 „Term-Verteilung“ ist die Annahme, dass ein Dokument in dem ein

Suchterm gleichmäßig verteilt enthalten ist relevanter sein muss, als ein Dokument, in dem die gleicheAnzahl von Suchtermen konzentriert auftreten, z. B. nur am Anfang oder nur am Ende. Es lässt sichalso ein ideales Dokument definieren, indem angenommen wird, dass der Abstand zwischen gleichenSuchtermen konstant ist. Dieser Abstand wird Dh bezeichnet:

Mit der Länge des Dokumentes LD in Zeichen und der Zeichenlänge des Suchterms Lt berechnet sich

die Distanz Dh zwischen den ideal-verteilten Suchtermen wie folgt:

Gleichung 5: Abstand bei idealer Verteilung

In Gleichung 5 bezeichnet Nt die Häufigkeit des Suchterms im Dokument. Diese Berechnung wird nurfür einen Suchterm durchgeführt, das heißt, dass Dh den Abstand zwischen gleichen Suchtermen

beschreibt. Mit Dh lässt sich nun für jedes Dokument die Abweichung vom idealen Dokument berech-

nen und als Kriterium K3 ausdrücken. Hierfür werden die Zwischenräume zwischen gleichen Suchter-

men, die größer sind, als Dh summiert (abzüglich Dh) und diese Summe in Verhältnis zum gesamten

Zwischenraum gesetzt.

Definition:

Die Funktion distz(D, t, i, j) liefert die Anzahl an Zeichen zwischen dem i-ten Vorkommen unddem j-ten Vorkommens des Terms t in einem Dokument D.

Mit Hilfe der Funktion distz() lässt sich eine Formel für das Kriterium K'3 aufstellen:

Gleichung 6: Kriterium Term-Verteilung

Term Term Term

D okum ent L D

D hD hD hD h

Abb. 88. Ideale Verteilung

Dh

LD Nt Lt×( )–

Nt 1+---------------------------------=

K'3 1max 0 distz D t i i 1+, , ,( ) Dh–,( )

i 1=

Nt 1–

∑LD Nt Lt×( )–

------------------------------------------------------------------------------------------------–=



Die Verteilung des Suchterms in diesem Beispiel entspricht also zu 75 % der Idealverteilung. Das Kri-terium K'3 erreicht einen Wert gegen Null, wenn sehr viele Suchterme am Anfang oder am Ende eines

großen Dokumentes stehen. Untersuchungen haben gezeigt, dass dies jedoch praktisch nicht passiert.Zur Verbesserung der Präzision sollte dieses Kriterium in Kombination mit einem anderen Kriteriumverwendet werden. Es bietet sich an, die Termfrequenz tf oder die Termhäufigkeit Nt als weitere Kom-

ponente zu verwenden, da schon ein einzelner Term eine ideale Verteilung in einem Dokument darstel-len könnte und somit die Verteilung alleine wenig Aussagekraft besitzt. In der implementierten Level-3-Suchmaschine wird die Termfrequenz tf verwendet, wobei zusätzlich spezielle Textelemente (Titel,Überschriften, META-Daten) um den Faktor 3 gewichtet werden. Die Termfrequenz wird anschlie-ßend mit einer Konstanten mit dem Wert 20 multipliziert und für Werte größer als 1 geprüft.

Mit dieser Modifikation lässt sich das Kriterium K3 berechnen:

Gleichung 7: Kriterium Term-Verteilung erweitert

Die Konstante C hat im der implementierten Relevanz-Filterung einen Wert von 20. Die min()-Funk-tion bewirkt, dass K3 keine Werte größer als 1 annehmen kann. Das Kriterium K3 besitzt hohe Werte

für Dokumente, in denen ein Suchterm sowohl mit hoher Termfrequenz als auch mit einer gleichmäßi-gen Verteilung auftritt. Da dieses Kriterium nur auf einen Suchterm anwendbar ist, sollte das Ergebnisfür Np Suchterme durch arithmetisches Mittel berechnet werden:

Gleichung 8: Arithmetisches Mittel

4.5.2.6 Kriterium K4: Wortvarianz

Neben den Kriterien K1 bis K3, die verschiedene Eigenschaften des Dokumentes bezüglich der Such-

terme untersuchen, sollte auch das Dokument selbst untersucht werden, um seine Relevanz zu beurtei-len. Hierfür wurde in der Level-3-Suchmaschine das Kriterium K4 „Wortvarianz“ implementiert.

Dieses Kriterium basiert auf der Annahme, dass relevante Dokumente eine hohe Wortvarianz aufwei-sen, während nicht-relevante Dokumente solche sind, die nur aus wenigen verschiedenen Wörternbestehen. Betrachtet werden bei dieser Berechnung des Kriteriums K4 ausschließlich die Nicht-Such-

terme. Es wird die Varianz der Nicht-Suchterme im Verhältnis zu der Gesamtanzahl der Nicht-Such-terme berechnet:

Gleichung 9: Kriterium Wortvarianz

Es macht Sinn, nur Wörter zu berücksichtigen, die mindestens eine Länge von vier Zeichen besitzen,um häufige Präpositionen, Artikel und andere Nebenwörter auszublenden. Generell eignet sich diesesKriterium dazu, Spamming zu ermitteln:

Beispiel: Wortvarianz

Suchanfrage: "Bank AND Geld"

Dokumente: "Bring bitte sofort dein Geld zur Bank !" K4=1

"Haus Haus Haus Haus Geld Geld Geld" K4=0,25

Das gespammte Dokument, gekennzeichnet durch häufiges Wiederholen weniger Worte, erhält einensehr viel schlechteren K4-Wert als ein grammatikalisch-korrekter Text. Es ist empfehlenswert, für das

Kriterium K4 einen Schwellwert zu setzen, um gezielt Spamming-Dokumente zu filtern.

K3 i,12--- K'3 tfi+( )=

K31N---- K3 i,

i 1=

Np

∑=

K4Anzahl verschiedener Nicht-Suchterme

Gesamtanzahl Nicht-Suchterme----------------------------------------------------------------------------------------------=



4.5.2.7 Option: Zusammenhänge beibehalten

Trotz der Bemühungen, einen wirkungsvollen Relevanz-Filter zu implementieren, ist nicht auszu-schließen, dass auch relevante Dokumente als nicht-relevant bewertet werden. Es sollten also weitereKriterien herangezogen werden, um die Relevanz eines Dokumentes zu bestimmen. Diese Kriteriensollten möglichst unabhängig gegenüber Spamming-Maßnahmen sein, um Manipulationen zu verhin-dern. Der durch Hyperlinks gebildete Web-Graph ist relativ gut gegen Manipulationen durch einzelneDokumentenautoren geschützt. Es liegt also nahe, den Web-Graphen für eine zusätzliche Filterung zuverwenden.

Als ersten Ansatz könnte die Anzahl der auf ein Dokument verweisenden Hyperlinks (Backlinks) alsQualitätskriterium verwendet werden. In der themenspezifischen Level-3-Datenbasis sind jedoch nureine geringe Anzahl von Dokumenten enthalten, so dass der aus diesen Dokumenten gebildete Web-Graph sehr unzusammenhängend ist. Dies verdeutlicht die Abb. 89. Die Dokumente A bis D sind inder Datenbasis einer Level-3-Suchmaschine enthalten, verdeutlicht durch einen grauen Bereich.Außerdem sind die Dokumente A bis D Elemente des Web-Graphen, d. h. sie sind mit anderen Doku-menten im WWW durch Hyperlinks verbunden. Wie aus Abb. 89 ersichtlich, sind die Dokumenteinnerhalb der Datenbasis nicht zusammenhängend, d. h. es ist nicht möglich, nur durch Betrachtungder Dokumente in der Datenbasis eine Aussage über den Web-Graphen zu machen. Dazu müssten alleDokumente des WWW betrachtet und ausgewertet werden.

Die folgende Tabelle belegt diese Annahme durch Untersuchung zweier Level-3-Datenbasen:

Wie Tabelle 16 zeigt, existieren in der Datenbank der Level-3-Suchmaschine „Streaming“ 2393 Doku-mente, die insgesamt 25642 Hyperlinks besitzen. Von diesen Hyperlinks verweisen aber nur 121 auf

Datenbasis „Streaming“ „3DVR“

Anzahl Dokumente 2393 5890

Anzahl Hyperlinks 25642 196117

Anzahl interne Hyperlinks 121 241

Dokumente mit Backlinks 66 142

Tabelle 16. Web-Graph in Level-3-Datenbasis

AB

CD

Le vel-3 -D a ten basis

W W W

D okum ent

Abb. 89. Zusammenhänge im WWW

Dokumente innerhalb der Level-3-Datenbasis. Insgesamt existieren nur 66 Dokumente, die einen odermehrere Backlinks von einem Dokument aus der eigenen Datenbasis besitzen. Dieser sehr unzusam-menhängende Graph lässt die Anwendung des HVV-Modells nicht zu.

Die Ausnutzung des Web-Graphen kann z. B. derart erfolgen, dass versucht wird, zusammenhängendeDokumente zu ermitteln, um diese Zusammenhänge beizubehalten. Dies kann durch die Option„Zusammenhänge beibehalten“ veranlasst werden. Es werden dann die Hyperlinks aller relevantenDokumente daraufhin überprüft, ob sie auf ein Dokument verweisen, welches sich in der Menge dernicht-relevanten Dokumente befindet. Ist dies der Fall, wird dieses Dokument als relevant betrachtetund in die Datenbasis übernommen. Anschließend werden auch diejenigen Dokumente in die Daten-basis übernommen, die zwar verworfen wurden, aber auf ein Dokument in der Datenbasis verweisen.Diese Überprüfungen werden durchgeführt, bis kein Dokument in der Datenbasis mit einem verworfe-nen Dokument zusammenhängt.

Abb. 90 verdeutlicht die Wirkungsweise dieser Funktion. Es existieren acht Dokumente, von denenvier einen RSV größer und vier einen RSV kleiner als die Akzeptanzgrenze besitzen. Es werden aller-dings sechs Dokumente in die Datenbasis übernommen, obwohl nur vier von ihnen einen RSV besit-zen, der über der Akzeptanzgrenze liegt. Die anderen zwei Dokumente werden in die Datenbasisübernommen, weil sie zu einem zusammenhängenden Web-Graphen gehören, von dem mindestens einDokument in die Datenbasis übernommen wurde.

4.5.2.8 Option: Backlinks

Eine weitere Möglichkeit, das im vorigen Kapitel angesprochene Problem des unvollständigen Web-Graphen innerhalb der Level-3-Datenbasis zu umgehen ermöglicht die Option „Backlinks“. Um dieAnzahl der Backlinks eines Dokumentes zu ermitteln, müsste eine sehr große Anzahl von Dokumen-ten untersucht werden. Dies ist zum Beispiel bei großen Index-Suchmaschinen der Fall und so bietetes sich an, eine Index-Suchmaschine zu benutzen, um die Anzahl der Backlinks eines Dokumentes zu

In d ie D a te n ba s is ü b e rn o m m e n e D o kum e n te

Verw orfen e D o ku m e n te

R S V > A kze p ta n zgre nze R S V < A kze p ta n zgre nze

H yp e rlink

Abb. 90. Zusammenhänge beibehalten



ermitteln. Ist die Anzahl der Backlinks eines Dokumentes bekannt, so lässt dies Rückschlüsse auf diePopularität dieses Dokumentes zu. Verbunden mit der Popularität ist meistens auch die Relevanz einesDokumentes, jedoch sagt die Anzahl der Backlinks in diesem Fall nichts darüber aus, inwiefern dasDokument für die gegebene Suchanfrage (die Level-3-Themenbeschreibung) relevant ist. Trotzdemscheint es sinnvoll zu sein, solche Dokumente in die Datenbasis zu übernehmen, die besonders vieleBacklinks besitzen.

Die Suchmaschine AltaVista ermöglicht die Suche nach den Backlinks eines Dokumentes. DieseMöglichkeit wird bei der Option „Backlinks beachten“ angewandt, um unter den verworfenen Doku-menten diejenigen zu ermitteln, die eine Mindestanzahl von Backlinks besitzen. Überschreitet dieAnzahl der Backlinks eines Dokumentes einen gegebenen Schwellwert, so wird dieses Dokument indie Datenbasis übernommen. Es wäre denkbar, ein Ranking-Kriterium auf der Basis der von AltaVistaermittelten Backlinks zu definieren, das auf alle in der Datenbasis enthaltenen Dokumente angewendetwird. Dies führt zu zwei Problemen: Zum einen dauert die Anfrage an AltaVista eine nicht unerhebli-che Zeit, die jedoch durch Parallelisierung der Abfrage verringert werden kann. Zum anderen ist esnicht unbedenklich, die Kapazitäten von AltaVista, oder einer andere Index-Suchmaschine, zum Ran-king mehrerer kompletter Datenbasen zu verwenden. Aus diesem Grunde wird diese Funktion nur aufdie relativ kleine Menge der verworfenen Dokumente angewendet.

4.5.3 Ergebnisse

Die in dieser Diplomarbeit beschriebene Level-3-Suchmaschine basiert auf einem Projekt von MarioSchomburg. Es wurden eine Reihe von Erweiterungen durchgeführt, unter anderem eine Übersetzungder bisherigen shell-Skripte in die Hochsprache Perl. Wichtigstes Ziel war es, ein Relevanzfilter-Kon-zept zu entwickeln, welches sowohl eine automatische, als auch eine manuelle Unterstützung für dieOptimierung der Level-3-Datenbasis ermöglicht. Der in der Level-3-Suchmaschine implementierteRelevanzfilter kann vielseitig angewendet werden, unter anderem bei der automatischen, als auch beider manuellen Übernahme neuer URLs in die Level-3-Datenbasis verwendet werden. Es kann eineRelevanzfilterung auf die bestehende Datenbasis durchgeführt werden. Bei der Begutachtung neueroder verworfener URLs kann als Sortierkriterium der aus der Relevanzfilterung ermittelte RSV ver-wendet werden. Außerdem kann der Relevanzfilter eingesetzt werden, um die Negativliste auf nicht-existierende oder relevante Dokumente zu überprüfen, mit dem Ziel, relevante oder nicht-existierendeEinträge automatisch aus der Negativliste zu entfernen.

Da die Relevanzprüfung mit einer gewissen Unsicherheit bei der Beurteilung der Dokumente behaftetist, muss versucht werden, die Parameter der Relevanzprüfung, insbesondere die Gewichtung der Kri-terien und der Schwellwerte, so zu optimieren, dass möglichst wenige relevante Dokumente und mög-lichst viele nicht-relevante Dokumente verworfen werden. Zur Untersuchung des Relevanzfilterswurden 20 Dokumente verwendet, die für die Level-3-Suchmaschine „Das Millenium“ ermittelt wur-den. Die Themenbeschreibung dieser Suchmaschine lautet:

Themenbeschreibung Level-3-Suchmaschine „Das Millenium“:

millenium

OR y2k

OR year AND 2000

OR new AND years AND day

OR jahrhundertwende

OR jahrtausendwende

OR jahr AND 2000

OR silvester

Durch diese Themenbeschreibung soll eine Level-3-Suchmaschine erstellt werden, die Dokumentezum Thema „Jahrtausendwende“ enthält. Passende Dokumente sind beispielsweise solche, die denMillenium Bug behandeln, das Jahr-2000-Problem (Y2K) in der Computerindustrie, aber auch solche,die Millenium-Kreuzfahrten oder Silvester-Aktivitäten beinhalten.



Nach einem Aufruf des Administrationspunktes „Neue URLs ermitteln“ dieser Suchmaschine wurdeninsgesamt 399 neue URLs ermittelt. Von diesen konnten 106 nicht zur Relevanzprüfung angefordertwerden, da sie einen „404-Not Found“-Fehler erzeugten. Dies ist dadurch gekennzeichnet, dass dieWerte für die Kriterien „Term-Vorkommen“ und „Term-Verteilung“ jeweils 0,000 besitzen. Es wäredenkbar, diese Dokumente in Zukunft gesondert zu behandeln. Zur Zeit werden diese Dokumente derRelevanzfilterung zugeführt und ggf. verworfen. Von denjenigen URLs, zu denen ein Dokument ange-fordert werden konnte, wurden 20 URLs als Referenz für den Relevanzfilter ausgewählt. Die Auswahlerfolgte zufällig.

URLs in der Referenzmenge (von MetaGer ermittelt):

Relevante Dokumente:

URL1: http://www.y2k-pak.comAngebot für ein Y2K-Überlebens-Paket (Wasser, Taschenlampe und Disketten)

URL2: http://www.y2ktested.comBerichte und Produktangebote (T-Shirts) zum Y2K-Thema

URL3: http://www.sordes.deEine Millenium-Seite einer Musik-Band

URL4: http://www.year2000center.comEine Seite um das Y2K-Problem

URL5: http://www.zlinks.comVerschiedene elektronische Grußkarten, u.a. zum New Years Day.

URL6: http://www.y2k.deWeb-Design für das neue Millenium

URL7: http://www.microsoft.com/intlkb/germany/support/kb/D34/D34671.htmUpdate für den Windows File-Manager, der das Jahr-2000-Problem behebt

URL8: http://www.appenzellernews.ch/appon/brauchtum/silvester.htmSilvesterveranstaltungen im Appenzeller Land

URL9: http://www.cop.de/jahr2000.htmY2K-Lösungen der Firma Navision Financials

URL10:http://www.jahr-2000.de/forum/programm.htmEine Programmübersicht des Jahr-2000 Forums

URL11:http://www.shaping-the-future.de/Pages/welcome2.htmDie EXPO 2000 in Hannover

Nicht-Relevante Dokumente:

URL12:http://www.laum.uni-hannover.de/arl/arbeitsprogramm/teil1.htmForschungsvorhaben der nächsten zwei Jahre

URL13:http://www.igc.org/igc/labornetHomepage einer Gewerkschaft in den USA

URL14:http://rc.amazing.ch/LinuxApocalypse/lapocalypse.htmlBericht über Linus Thorwald

URL15:http://www.capecod.net/coastlinAusflugsangebote für einen Angelurlaub

URL16:http://www.ockham.philos.phil.tu-bs.de/Texte/Bacon_F/Atlantis.htmlReisebericht in Peru um 1626

URL17:http://www.stadt.lauf.de/sehens/index.htmlSehenswürdigkeiten in der Stadt Lauf

URL18:http://www.meto.de/news.htmlProduktangebote eines Druckerherstellers

URL19:http://www.multicon.de/fun/legofaq.htmlFAQ-Sammlung um das Thema Lego-Spielzeug

URL20:http://www.usatoday.com/sports/sd.htmSport in den USA



Die Beurteilung der Relevanz beruht auf manueller Begutachtung der Dokumente. Alle nicht-relevan-ten Dokumente gehören nicht zum Thema „Millenium“, sie sind aber von der Meta-Suchmaschineaufgrund der gegebenen Themenbeschreibung ermittelt worden. Dafür kann es verschiedene Gründegeben. So enthält zum Beispiel das Dokument der URL15 den Text „Captain J.R. Silvester will guideyou“ und wurde aufgrund des Suchterms „Silvester“ von MetaGer ermittelt. Der Inhalt dieses Doku-mentes bezieht sich jedoch auf einen Angelurlaub und somit ist dieses Dokument für die Suchma-schine „Das Millenium“ nicht relevant. Das Ziel der Relevanzfilterung ist es, solchen nicht-relevantenDokumenten einen niedrigeren RSV zuzuweisen, als den relevanten Dokumenten. Die für die Rele-vanzbestimmung notwendigen Kriterien wurden wie folgt ermittelt:

Die Ergebnisse in Tabelle 17 deuten darauf hin, dass sich die relevanten URLs besser von den nicht-relevanten URLs abheben, wenn das Kriterium K2 stärker bewertet wird, als die Kriterien K3 und K4.

Dies ist aufgrund der Definition des Kriteriums K2 nachvollziehbar, wie vorangehend erläutert. Das

Kriterium K4 hat für die Berechnung eines RSVs eine weniger große Bedeutung, als die Kriterien K2

und K3, da das Kriterium K4 nur einen geringen Bezug zur Themenbeschreibung hat. Das Kriterium

K4 beschreibt vielmehr die Qualität eines Dokumentes bezüglich Wortvarianz und so sollte dieses Kri-terium weniger stark gewichtet, sondern eher mit einem höheren Schwellwert versehen werden, umgezielt solche Dokumente zu ermitteln, die durch wiederholtes Vorkommen einiger Suchterme einenhohen RSV erzielen würden (Spamming). Gemäß dieser Überlegungen wurden die Kriterien für dieBerechnung des RSVs wie folgt gewichtet:

Kriterium K1: 80%

Kriterium K2: 60%

Kriterium K3: 40%

Kriterium K4: 20%

Kriterien relevant nicht-relevant Differenz

K2 Term-Kontext 0,795 0,371 0,424

K3 Term-Verteilung 0,677 0,417 0,260

K4 Wort-Varianz 0,744 0,532 0,212

Tabelle 17. Durchschnittliche Kriterienberechnung



Damit lassen sich die RSVs für alle URLs berechnen:

Das Ergebnis der RSV-Berechnung in Tabelle 18 folgt den vorangegangenen Überlegungen. Wieerwartet erhielt aufgrund der gewählten Gewichtung die Mehrzahl der relevanten URLs einen höherenRSV als die nicht-relevanten URLs. Es gibt zwei Ausnahmen (URL15 und URL17), die aufgrund häu-figer Benutzung der Worte „Jahrhundertwende“ (URL17) und „Silvester“ (URL15) einen hohen RSVerhielten, für das Thema „Millenium“ jedoch nicht relevant sind. Die Betrachtung der Tabelle 3 legtden Schluss nahe, dass URLs, die einen RSV von über 70% besitzen, mit hoher Wahrscheinlichkeitauf ein relevantes Dokument verweisen. Dies lässt jedoch keine allgemein gültige Aussage über denidealen Wert der Akzeptanzgrenze zu, da sich die Berechnung des RSVs aufgrund verschiedenerGewichtungen stark von einzelnen Level-3-Suchmaschinen unterscheiden kann. Es ist empfehlens-wert, den Relevanzfilter für jede Level-3-Suchmaschine manuell zu optimieren. Dies gilt insbesonderefür die Wahl einer geeigneten Akzeptanzgrenze bei automatischer Relevanzfilterung. Hierzu sind dieAdministrationspunkte „Begutachtung verworfener URLs“ und „Begutachtung neuer URLs“ geeignet.

RSV Relevanz URL Beschreibung

95,62 4 Dokument über Y2K-Problem

92,09 3 Millenium-Seite einer Musik-Gruppe

90,59 - 15 Angebote für Angelreisen

89,91 2 Berichte und Produkte zum Y2K-Thema

88,16 5 Elektronische Grußkarten (New Years Day)

86,24 11 EXPO 2000 in Hannover

86,05 1 Angebot für ein Y2K-Überlebenspaket

84,05 8 Silvesterveranstaltungen

79,53 6 Web Design für das neue Millenium

77,70 - 17 Sehenswürdigkeiten in der Stadt Lauf

75,57 9 Kommerzielle Y2K-Lösungen

73,66 7 Software-Update gegen den Millenium Bug

69,44 10 Jahr-2000 Forum

63,64 - 14 Bericht über Linus Thorwald

63,10 - 20 Sport in den USA

60,97 - 12 Forschungsplan der nächsten 2 Jahre

59,87 - 19 FAQ-Sammlung über Spielzeug

59,45 - 18 Produkte eines Druckerherstellers

59,04 - 13 Gewerkschaft in den USA

58,02 - 16 Reisebericht aus Peru

Tabelle 18. Ergebnisse RSV-Berechnung

133


5 Zusammenfassung und Ausblick

Die geplanten Ziele wurden im wesentlichen erreicht. Aufgrund von aufgetretenen weiteren Anforde-rungen sowie durch geänderte eigene Einschätzungen bezüglich der Relevanz wurden jedoch Modifi-kationen des Arbeitsablaufs im Detail vorgenommen. Bei der Entwicklung und Erprobung innovativerWerkzeuge zur 3D/Virtual-Reality(VR)- und Multimedia(MM)-Online-Präsentation sowie deren Nut-zungseffizienz durch neuartige Suchmaschinen wurde eine Reihe interessanter Erkenntnisse gewon-nen. Dies kann u. a. durch die Veröffentlichungen und Vorträge (siehe Abschn. 3.4 auf S. 7) sowieeinen Innovationspreis (siehe Abschn. 3.6 auf S. 9) belegt werden. Die entwickelten und konfiguriertenDienste und Werkzeuge wurden im Projektzeitraum erfolgreich in einen produktiven Betrieb über-führt. Zur Demonstrierbarkeit der Ergebnisse wurden in einer virtuellen Ausstellung Exponate gestal-tet, die sich auf die Bereiche Technologie, Demonstration und Infrastruktur beziehen und Inhalte mitexemplarischem Charakter repräsentieren (www.dfn-expo.de). Darüber hinaus wurden etliche Vorfüh-rungen veranstaltet, sowohl am RRZN/RVS (3D-Präsentationsraum / Multimedia-Labor) als auch aufMessen und Konferenzen (siehe Abschn. 3.4 auf S. 7), um das Potential und den möglichen deutlichenZuwachs an Leistungsfähigkeit, Qualität und Funktionalität bei der effizienten Nutzung aktueller 3D/VR- und MM-Technologien – auch im Vergleich zu den im Internet derzeit verbreiteten Werkzeugen –zu demonstrieren.

Nachnutzung

Das erworbene Know-how und die installierten Hard- und Software-Systeme werden nach Projek-tende weiter genutzt. Dies wird an den folgenden Beispielen verdeutlicht, in denen die Projektergeb-nisse sowie die leistungsfähige Infrastruktur Ausgangspunkte für weitere Projekte oder Regeldienstedarstellen:

Lokal / Regional• Audio/Video-Streaming und Webdesign:

– Das Know-how sowie Hard- und Software-Systeme fließen in die Beratungsfunktionen undRegeldienste des Multimedia-Labors am RRZN/RVS ein. Dadurch werden sowohl Gruppendes RRZN (z. B. Ausbildung/Dokumentation/Informationssysteme) als auch Institute nie-dersächsischer Hochschulen und Fachhochschulen unterstützt.

– Zur Innovationsoffensive „Educational Technology Lab“ an der Universität Hannover wirdbeigetragen, z. B. bei der Planung eines „Multimedia-Hörsaals“ im Neubau der Techni-schen Informatik.

• 3D/Virtual Reality, Audio/Video-Streaming, Virtuelle Pavillons und Webdesign:– Die leistungsfähigen Werkzeuge und Systeme sowie Know-how zur Ergebnis-Visualisie-

rung haben den Aufbau eines Kompetenzzentrums für die Ergebnispräsentation ermöglicht.In Kooperation mit anderen Rechenzentren aus Niedersachsen und dem norddeutschenRaum wird ein Kompetenzverbund zum Thema Visualisierung aufgebaut.

– Struktur und Templates aus dem Exponatsbereich können zur Online-Präsentation von visu-alisierten Ergebnissen des Höchstleistungsrechnens im geplanten „Höchstleistungsrechen-zentrum Nord“ (HLRN), einem Verbund von 6 norddeutschen Bundesländern mitInstallationen in Berlin und Hannover, verwendet werden.

• 3D/Virtual Reality:– Beratung und regelmäßige Nutzung im Rahmen von Forschungsprojekten und Lehrveran-

staltungen an der Universität Hannover (z. B. Architekturvisualisierung, Meteorologie undKlimatologie, Thermodynamik, Verfahrenstechnik).

– Interesse an Kooperationen für weitere Nutzungsszenarien und entsprechende Weiterent-wicklungen, z. B. Institut für Theoretische Nachrichtentechnik: Interesse an der Nutzungdes 3D-Viewers (auch unter Linux), Institut für Mikroelektronische Systeme: Chip-Visuali-sierung, Medizinische Hochschule Hannover: VR-Einsatz in der Neuropsychologie, Volks-wagen AG: 3D-Streaming zur Visualisierung von Finite-Elemente-Simulationsergebnissen.

– Kooperation im geplanten Forschungsbereich „Visualisierung und Medizin“ [28].

134 5 Zusammenfassung und Ausblick


Überregional• DFN-Zine:

– Regelbetrieb durch DFN (Redaktion) und RRZN/RVS (Betrieb).• 3D/Virtual Reality und Audio/Video-Streaming:

– Geplantes DFN-Projekt „Anwendung der Tele-Immersion in Weitverkehrsnetzen“ (s. u.,Projektbeginn: Frühjahr 2000).

– Interesse am 3D-Streamingverfahren wurde auch von der „Working Group VRML Strea-

ming“1 des Web3D-Konsortiums bekundet (Email 09.08.1999 von Bernie Roehl).– Kooperationsbeitrag in der „TERENA Streaming Task Force“ (TF-ESME). Beim ersten

Treffen am 10.12.1999 war das RRZN/RVS als einziger deutscher Teilnehmer vertreten.• Suchmaschine 3. Ordnung:

– Einfluss auf weiteres Vorgehen bei der Entwicklung von Meta-Suchmaschinen am RRZN/RVS, z. B. Metager – derzeit (04.01.2000) bis zu 200.000 Zugriffe/Tag – und Metaworld.

Ausblick

Im geplanten Projekt „Anwendung der Tele-Immersion in Weitverkehrsnetzen“, welches mit Mittelndes DFN-Vereins/BMBF gefördert werden soll, sollen unter der Federführung des RRZN/RVS sowiedes ZIB (Konrad-Zuse-Zentrum für Informationstechnik, Berlin) die im Projekt „DFN-Expo“ entwi-ckelten Mechanismen im Kontext des Höchstleistungsrechnens erprobt und weiterentwickelt werden.Dazu werden – in Kooperation mit dem Institut für Meteorologie und Klimatologie und dem Institutfür Thermodynamik, Universität Hannover – Anwendungsszenarien der wissenschaftlichen Visualisie-rung verfolgt.

Das geplante Projekt weist folgende Besonderheiten auf [19][32]:

Szenarien• Präsentationsszenario:

Informationssystem zum interaktiven Abruf von Ergebnispräsentationen in Form von navigier-baren 3D-Animationen – „Virtual Reality Movie“ – mittels 3D-Streaming-Verfahren.

• Explorationsszenario:Virtuelle Experimentierumgebung mit interaktiver, bidirektionaler Kopplung von Simulations-,Visualisierungs- und Darstellungsmodulen.

• Diskussionsszenario:Erweiterung des Präsentationsszenarios um computergestützte Zusammenarbeit – Computer-Supported Cooperative Work (CSCW).

Innovative Netz-InfrastrukturStreamingserver und Client kommunizieren über Gigabit-Ethernet, wobei zur Erhöhung des Durch-satzes „Jumbo-Frames“ zum Einsatz kommen. Die Weitverkehrskommunikation soll über WDM(Wave Division Multiplex) erfolgen.

3D-Geometrie-Generierung auf dem SupercomputerDie Filter- und Mapper-Funktionalitäten, welche zur Aufbereitung von Ergebnisdaten in 3D-Geo-metrien dienen, sollen in die Simulationsrechnung integriert werden. Diese durchaus rechenauf-wendigen Aufgaben können dann durch Anwendung auf die jeweiligen Teilergebnisse – je nachGebietszerlegung – parallelisiert durchgeführt werden. Gegenüber dem üblicherweise zwischenzu-speichernden oder zu übertragenden Datenvolumen der Rohdaten, welches – mit n Gitterpunkten jeDimension bei regulärem Gitter – näherungsweise mit ansteigt, wird hier eine Reduktionerzielt, da das Datenvolumen der generierten 3D-Symbole nur mit (z. B. Isosurface, Slicer)bzw. (z. B. Streamline) ansteigt.

Synchronisationsaspekte• intra-stream: z. B. feste Framerate,• inter-client: z. B. Synchronisation der Navigation, Tele-Pointer,

„VCR“-Steuerung im Diskussionsszenario.

1. http://www.vrml.org/WorkingGroups/vrml-streams/

O n3( )O n

2( )O n( )

135


Literaturverzeichnis

1. Adobe Systems Inc.: Tagged Image File Format (TIFF) Specification, Revision 6.0, 1993.

2. Bell, G., Parisi, A., Pesce, M.: The Virtual Reality Markup Language – Version 1.0 Specification.09.11.1995. (http://www.web3d.org/Specifications/VRML1.0/)

3. von Berg, A., Pralle, H.: A Concept for an Electronic Magazine. Terena-NORDUnet NetworkingConference 1999 in Lund, Schweden.

4. von Berg, A.: Gigabit Ethernet Performance Tests on SGI Machines – TCP Bulk Data Transferwith and without Jumbo Frame Option. Technical Report. Universität Hannover, RegionalesRechenzentrum für Niedersachsen (RRZN) / Lehrgebiet Rechnernetze und Verteilte Systeme(RVS), 1999.

5. von Berg, A.: Mehr Wert Mitteilungen. DFN-Mitteilungen Ausgabe 43, März 1997, DFN-Verein,Berlin.

6. von Berg, A.: Ora++ - Eine C++-Klassenbibliothek zum Zugriff auf ORACLE-Datenbanken ausdem WWW. Vortrag im Arbeitskreis Informationsdienste auf dem DFN-Symposium "Fortgeschrit-tene Kommunikationstechnik" am 11.2.98 in Berlin

7. von Berg, A., Ittmann, A. , Quandel G.: Web-based Magazine. DFN-Mitteilungen Ausgabe 50,Juni 1999, DFN-Verein, Berlin

8. Borenstein N., Freed N.: Multipurpose Internet Mail Extensions (MIME). Part Two: Media Types.RFC 2046, November 1996.

9. Burger, R. E.: Colormanagement. Springer, 1997.

10. Chen, S., Pu, C., Staehli, R., Cowan, C., Walpole, J.: A Distributed Real-Time MPEG Video AudioPlayer. Proceedings of NOSSDAV (International Workshop on Network and Operating SystemSupport for Digital Audio and Video) 1995, Lecture Notes in Computer Science, Vol. 1018,Springer, 1995. (http://www.cse.ogi.edu/~scen/)

11. Felger, W.: Innovative Interaktionstechniken in der Visualisierung. Springer, 1995.

12. Hardenberg, J.: RE: QvLib questions. VRML Hypermail Archive, 27.03.1995.(http://vag.vrml.org/www-vrml/arch/1107.html)

13. Hennig, A.: Die andere Wirklichkeit – Virtual Reality – Konzepte, Standards, Lösungen. Addison-Wesley, 1997.

14. Hodges, L. F.: Time-multiplexed Stereoscopic Computer Graphics. IEEE Computer Graphics andApplications, Vol. 12, No. 2, 1992.

15. InterSense Inc.: IS-600 Mark II. User Manual, 1999.

16. ISO/IEC 14772-1: The Virtual Reality Modeling Language (VRML97) – Part 1: Functional speci-fication and UTF-8 encoding, 1997. (http://www.web3d.org/Specifications/VRML97/)

17. Kilgard, M. J.: OpenGL Programming for the X Window System. Addison-Wesley, 1996.

18. Kuhlen, T. et al: Ziel erfaßt! Tracking-System-Test. In: 3D Live, IWT, 2/99.

19. Leigh, J. et al: Visualization in Teleimmersive Environments. IEEE Computer, Vol. 32, No. 12,December 1999.

20. Leonhardt, C.: Zur Anwendung von Streamingverfahren auf die Online-Präsentation von Sequen-zen virtueller 3D-Objekte. Diplomarbeit, Universität Hannover, Regionales Rechenzentrum fürNiedersachsen (RRZN) / Lehrgebiet Rechnernetze und Verteilte Systeme (RVS), 1998.

21. Microsoft: Color Management in Microsoft Windows Operating Systems – An Overview of Micro-soft Color Management Technology. White Paper, April 1997.(http://www.microsoft.com/Windows/platform/icmwp.htm)

22. Microsoft: ICM 2.0 SDK Web site.(http://www.microsoft.com/msdn/sdk/icm20.htm)

23. Microsoft: TrueType 1.0 Font Files. Technical Specification, Revision 1.66, November 1995.

24. Nebel, E., Masinter, L.: Form-based File Upload in HTML. RFC 1867, 07.11.1995.

136 Literaturverzeichnis


25. Neider, J., Davis, T., Woo, M.: OpenGL Reference Manual: The official reference document forOpenGL, Release 1. Addison-Wesley, 1992.

26. Netscape: Netscape Navigator LiveConnect/Plug-In Software Development Kit. 1998.(http://home.netscape.com/comprod/development_partners/plugin_api/)

27. Netscape: Plug-In Guide – Communicator 4.0. January 1998.(http://developer.netscape.com/docs/manuals/communicator/plugins/)

28. Olbrich, S., Pralle, H.: 3D/VR-Technologie (Tele-Immersion) zur Präsentation wissenschaftlicherErgebnisse. Workshop „Visualisierung / Bildgebende Verfahren“, Universität Hannover,26.10.1999.

29. Olbrich, S., Pralle, H.: High-Performance Online Presentation of Complex 3D Scenes. In: van As,H. R. (Ed.): High Performance Networking – IFIP TC-6 Eighth International Conference on HighPerformance Networking (HPN ’98), Vienna, Austria, September 1998. Kluwer Academic Publis-hers, 1998.(http://www.dfn-expo.de/Technologie/DocShow-VR/Vortraege/hpn98/)

30. Olbrich, S.: Hochwertige Online-Präsentation virtueller 3D-Exponate aus dem Wissenschaftsbe-reich – Anforderungen und Lösungsansätze, Vortrag auf dem DFN-Arbeitkreis Informations-dienste, Hannover, 24.09.1997.

31. Olbrich, S., Pralle, H., et al: Regionales Testbed Nord, Projekt P5.1 – Online-Dokumente,Abschlußbericht. Universität Hannover, Regionales Rechenzentrum für Niedersachen (RRZN) /Lehrgebiet Rechnernetze und Verteilte Systeme (RVS), 04.04.1997.(http://www.rtb-nord.uni-hannover.de/onlinedokumente/)

32. Olbrich, S.: Verteilte Nutzung von 3D/VR-Streamingverfahren zur Präsentation und Diskussionkomplexer Ergebnisse. Workshop „Wissenschaftliche Anwendungen auf Höchstleistungsrech-nern“, RRZN, Universität Hannover, 29.09.1999.

33. Olbrich, S., Pralle, H.: Virtual Reality Movies – Real-Time Streaming of 3D Objects. TERENA-NORDUnet Networking Conference, Lund, Sweden, 1999.(http://www.terena.nl/tnnc/2A/2A1/2A1.pdf)

34. OPC – The OpenGL Performance Characterization Projekt: Viewperf Information and Results.(http://www.specbench.org/gpc/opc.static/viewin~1.html)

35. Open Software Foundation: OSF/Motif Programmer’s Guide, Programmer’s Reference, StyleGuide, Revision 1.2. Prentice Hall, 1993.

36. Paul, B.: The Mesa 3-D graphics library. (http://www.ssec.wisc.edu/~brianp/Mesa.html)

37. Pfuhl, W.: Zur Bewertung des Datenfluß- und Online-Präsentations-Verhaltens digitaler Reprä-sentationen von 3D-Objekten. Diplomarbeit, Universität Hannover, Regionales Rechenzentrumfür Niedersachsen (RRZN) / Lehrgebiet Rechnernetze und Verteilte Systeme (RVS), 1997.

38. Polhemus Inc.: 3Space Fastrak User’s Manual. Revision F, November 1993.

39. Raasch, S., Etling, D.: Modeling Deep Ocean Convection: Large Eddy Simulation in Comparisonwith Laboratory Experiments. Journal of Physical Oceanography, Vol. 28, 1998.

40. Rumbaugh, J., Blaha, M., Premerlani, W., Eddy, F., Lorensen, W.: Objektorientiertes Modellierenund Entwerfen. Hanser, Prentice-Hall, 1993.

41. Rust, L. F., de Saqui-Sannes, P., Courtiat, J.-P.: Basic Synchronization Concepts in MultimediaSystems. Proceedings of NOSSDAV (International Workshop on Network and Operating SystemSupport for Digital Audio and Video) 1995, Lecture Notes in Computer Science, Vol. 712, Sprin-ger, 1992.

42. Schroeder, W., Martin, K., Lorensen, B.: The Visualization Toolkit. 2nd Edition. Prentice Hall,1997.

43. Schulzrinne, H., Casner, S., Frederick, R., Jacobson, V.: RTP: A Transport Protocol for Real-TimeApplications. RFC 1889, January 1996.

44. Schulzrinne, H., Rao, A., Lanphier, R.: Real Time Streaming Protocol (RTSP). RFC 2326,14.04.1998.

137


45. Shneiderman, B.: Response Time and Display Rate in Human Performance with Computers.ACM Computing Surveys, Vol. 16, Nr. 3, 1984.

46. Silicon Graphics, Inc.: Coloratura Programmer’s Guide. 1998.

47. Silicon Graphics, Inc.: Onyx2 Reality and Onyx2 Infinite Reality. Technical Report, 1996.

48. Silicon Graphics, Inc.: Origin Servers. Technical Report, 1997.

49. Silicon Graphics, Inc.: Topics in IRIX Programming. 1999.

50. Simon, R. J.: Windows 95 Win32 Programming API Bible. Waite, 1996.

51. StereoGraphics Corp.: CrystalEyes Software Development Kit. A StereoGraphics Product.Updated: 01.12.1997. (http://www.stereographics.com/support/developers/ce_sdk.pdf)

52. Stokes, M., Anderson, M., Chandrasekar, S., Motta, R.: A Standard Default Color Space for theInternet – sRGB. Version 1.10, November 5, 1996. (http://www.color.org/sRGB.html)

53. Strauss, P., Bell, G.: The VRML Programming Library – QvLib, Version 1.0 beta 1. 1995.(http://vag.vrml.org/www-vrml/vrml.tech/qv.html)

54. Sun Microsystems, Inc.: KCMS Application Developer’s Guide. 1997. (http://docs.sun.com/)

55. Vöckler, J.-S.: A quick glance at webfilt. Universität Hannover, Lehrgebiet Rechnernetze und Ver-teilte Systeme (RVS), 03.09.1997.

56. Web 3D Consortium: The VRML Repository. (http://www.web3d.org/vrml/vrml.html).

dfn-expo - gwdg

Documents