-
Die vorliegende Erfindung bezieht sich auf eine Vorrichtung zum Rendern von Bewegtbildern und einen Set von Datencontainern mit Timecode. Die vorliegende Erfindung betrifft des Weiteren ein Verfahren zum Rendern von Bewegtbildern.
-
Hintergrund
-
Bewegtbildinhalte tendieren gegenwärtig zunehmend dazu, aus Bildbereichen, die mit einer Kamera aufgenommen werden, und Bildbereichen, die Computergrafik enthalten, zusammengesetzt zu sein.
-
So ist es beispielsweise üblich, vollständige Bilder der Bewegungen eines Schauspielers in einem Studio vor einem einfarbigen Hintergrund aufzunehmen und später Hintergrundinhalte hinzuzufügen. Zu diesem Zweck werden „Garbage-Matte“-Daten generiert, die als Korrekturmaske zur Trennung der vollständigen Bilder in eine zu erhaltende Vordergrundebene und eine später zu beseitigende oder zu ersetzende Hintergrundebene dienen. Die Erstellung von Masken wird auch als „Keying“ bezeichnet.
-
Die computergrafischen Elemente werden normalerweise unter Verwendung computergrafischer Assets erstellt. Unter Verwendung der Assets und der Positionsdaten der Kamera, die die Kameraposition im 3D-Raum inklusive Schwenkwinkel und Neigungswinkel der betreffenden Aufnahme umfassen, können computergrafischer Hintergründe für die Kombination mit der aus der betreffenden Aufnahme extrahierten Vordergrundebene generiert werden. Die für die Erzeugung der Computergrafik benötigte Zeit variiert in Abhängigkeit von der Komplexität der Computergrafik.
-
Zusammenfassung der Erfindung
-
Aufgrund der Variabilität der für die Erstellung der Computergrafik erforderlichen Zeit, werden computergenerierte Inhalte asynchron zur Verfügbarkeit der Bilddaten verfügbar gemacht.
-
Die Erfinder haben erkannt, dass trotz des benannten Mangels an Synchronität ein Echtzeit-Rendern und eine Vorschau des vollständigen Inhalts möglich werden, wenn die Erstellung der computergenerierten Inhalte ein wenig im Voraus durchgeführt werden kann. Dazu schlagen die Erfinder vor, die zukünftige Kameraposition eines zukünftigen Zeitpunkts vorherzusagen und computergenerierte Inhalte für die zukünftige Kameraposition zu erstellen.
-
Das heißt, es wird eine Vorrichtung gemäß Patentanspruch 1 und ein Verfahren gemäß Patentanspruch 5 für das Rendern von Bewegtbildern vorgeschlagen, die Bildbereiche, die mittels einer an einen Timecode-Generator angeschlossenen Kamera aufgenommen werden, wie auch computergraphische Bildbereiche enthalten. Des Weiteren wird ein Datencontainer gemäß Patentanspruch 9 vorgeschlagen.
-
Gemäß eines Aspekts der Erfindung beinhaltet die Vorrichtung zum Empfang von Timecodes eine Timecode-Schnittstelle zur Verbindung mit dem Timecode-Generator. Für den Empfang mit Timecode versehener, vollständiger Bilddaten und für den Empfang mit Timecode versehener Kameratrackingdaten beinhaltet die Vorrichtung eine Bild- und Kameradatenschnittstelle zur Verbindung mit der Kamera. Des Weiteren hat die Vorrichtung die Möglichkeit, unter Verwendung der vollständigen Bilddaten Garbage-Matte-Daten mit Timecode zu generieren. Die Vorrichtung hat des Weiteren die Möglichkeit, zukünftige Kamerapositionsdaten eines zukünftigen Zeitpunkts unter Verwendung der aktuellen Kameratrackingdaten eines aktuellen Zeitpunkts vorherzusagen und zumindest die Vorhersage zukünftiger Kamera-Tracking-Daten zu übermitteln und computergenerierte Inhalte eines zukünftigen Zeitpunkts zu empfangen wie auch eine Renderengine-Schnittstelle zur Verbindung mit einer Rendervorrichtung. Darüber hinaus gibt es auch die Möglichkeit, eine Timecode-basierte Vorschau zumindest unter Verwendung der Bilddaten, der Garbage-Matte-Daten und der computergenerierten Inhalte zu erstellen.
-
In einer Ausführungsform wird der zukünftige Zeitpunkt so weit voraus in der Zukunft gewählt werden können, dass die computergenerierten Inhalte vorab gerendert werden können.
-
Auf diese Weise können computergenerierte Inhalte zusammen mit den Garbage Mattes und den vollständigen Bilddaten bereitgestellt werden, so dass eine Echtzeit-Vorschau möglich wird.
-
In einer Ausführungsform kann die Vorrichtung eine Datenverwaltungsvorrichtung zum Erzeugen timecode-basierter Datencontainer beinhalten, wobei der Datencontainer eines entsprechenden Timecodes zumindest den jeweiligen Timecode, die Kameratrackingdaten des betreffenden Timecodes, die vollständigen Bilddaten des betreffenden Timecodes und die Garbage-Matte-Daten des jeweiligen Timecodes beinhaltet.
-
In einer Ausführungsform kann die Vorrichtung eine Speichergeräts-Schnittstelle zum Abrufen computergrafischer Assets von einer Speichervorrichtung beinhalten, wobei die Renderengine-Schnittstelle im Hinblick auf die Übermittlung computergrafischer Assets an die Rendervorrichtung angepasst ist.
-
Das Verfahren gemäß der Erfindung umfasst die folgenden Schritte: Empfang von Timecodes vom Timecode-Generator; Empfang timecode-basierter vollständiger Bilddaten und Empfang timecode-basierter Kameratrackingdaten aus der Kamera; Generierung von timecode-basierten Garbage-Matte-Daten unter Verwendung der vollständigen Bilddaten; Vorhersage zukünftiger Kamerapositionsdaten eines zukünftigen Zeitpunkts auf Basis der aktuellen Kameratrackingdaten eines aktuellen Zeitpunkts; Übertragung zumindest der vorhergesagten zukünftigen Kameratrackingdaten an eine Renderengine und Empfang timecode-basierter computergenerierter Inhalte für den betreffenden zukünftigen Zeitpunkt von der Rendervorrichtung; sowie Erstellung einer timecode-basierten Vorschau unter Verwendung zumindest der Bilddaten, der Garbage-Matte-Daten und der computergenerierten Inhalte.
-
In einer Ausführungsform des Verfahrens wird der zukünftige Zeitpunkt so weit voraus in der Zukunft gewählt werden können, dass die computergenerierten Inhalte vorab gerendert werden können.
-
In einer Ausführungsform kann das Verfahren das Erzeugen von timecode-basierten Datencontainern beinhalten, wobei der Datencontainer eines entsprechenden Timecodes zumindest den jeweiligen Timecode, die Kameratrackingdaten des betreffenden Timecodes, die vollständigen Bilddaten des betreffenden Timecodes und die Garbage-Matte-Daten des jeweiligen Timecodes beinhaltet.
-
In einer Ausführungsform kann das Verfahren das Abrufen computergrafischer Assets von einer Speichervorrichtung und die Übermittlung computergrafischer Assets an die Rendervorrichtung beinhalten.
-
Bei einem Set timecode-basierter Datencontainer gemäß dieser Erfindung, beinhaltet jeder Datencontainer zumindest den entsprechenden Timecode, die Kamera-Tracking-Daten des betreffenden Timecodes, die vollständigen Bilddaten des betreffenden Timecodes und die Garbage-Matte-Daten des betreffenden Timecodes. In einer Ausführungsform beinhaltet jeder Datencontainer darüber hinaus eine timecode-basierte Vorschau.
-
Weitere vorteilhafte Ausführungsformen der Erfindung sind in den abhängigen Patentansprüchen und der detaillierten Beschreibung aufgeführt.
-
Zeichnungen
-
Exemplarische Ausführungsformen der Erfindung werden im Folgenden anhand von Abbildungen detailliert beschrieben. Es zeigen:
-
ein exemplarisches System, in dem die Erfindung verwendet werden kann;
-
schematisch und exemplarisch, wie das in beschriebene exemplarische System bei einem Dreh verwendet werden kann;
-
Module, die in exemplarischen Ausführungsformen der erfindungsgemäßen Vorrichtung enthalten sind, und
-
Details der in dargestellten Module.
-
Ausführungsformen der Erfindung
-
zeigt ein exemplarisches System, in dem die Erfindung verwendet werden kann. Für die Wireless-Konnektivität beinhaltet die Vorrichtung eine Antenne 100, die WLAN-(WiFi-), GPRS- oder ETL-Verbindungen ermöglicht, so dass Videosignale empfangen und/oder übertragen werden können.
-
Ein HD-SDI-Monitor 200 ermöglicht die Betrachtung von Videoinhalten. Zur Fernsteuerung eines Kamera-Rigs beinhaltet die dargestellte Vorrichtung einen Joystick 400, andere Möglichkeiten zur Fernsteuerung der Kamera sind jedoch gegeben. Das System beinhaltet darüber hinaus Möglichkeiten 500 zum Empfangen von Benutzereingaben, beispielsweise über eine Tastatur, ein Touch-Pad und/oder eine Maus. Für die Aufnahme von Video-Inhalten ist HD-Recorder 800 integriert. Erzeugte Daten werden im Datenspeicher 1000 gespeichert, der zum Beispiel als Festplatten-Array angelegt sein kann. Zur Datenverarbeitung beinhaltet das System zwei CPUs 600, 900, die jeweils über eine zugeordnete System-Festplatte verfügen. Darüber hinaus ist eine Fernsteuerung 3 für ein Keying-Modul und eine Stromversorgung 1200 integriert. Eine Anschlussleiste 1100 ermöglicht den Anschluss an andere Systeme oder Vorrichtungen. Der HD-SDI-Monitor 200 ermöglicht die Echtzeit-Vorschauanzeige von Videoinhalten, die sich aus der Kombination der aktuell am Set aufgezeichneten Realfilmaufnahmen und statischen und/oder animierten digitalen Elementen ergeben wie auch die Anzeige einer grafischen Benutzeroberfläche zur Steuerung und Parametrierung der verschiedenen Module sowie der Hard- und Software.
-
zeigt schematisch und exemplarisch, wie das exemplarische System am Set verwendet werden kann. Eine Kamera CAM erfasst Einzelbilder mit einer Frame-Rate, vorzugsweise aber nicht notwendigerweise, digital und in hoher Auflösung. Die Kamera ist an einen Timecode-Generator TCG gekoppelt. Der von dem Timecode-Generator TCG erzeugte Timecode wird über eine Schnittstelle einer exemplarischen Ausführungsform der erfindungsgemäßen diVERT Vorrichtung verfügbar gemacht. Die Schnittstelle kann derart ausgestaltet sein, dass der Timecode-Generator TCG ein Plug-in der diVERT Vorrichtung ist.
-
Die Vorrichtung empfängt darüber hinaus über eine weitere Schnittstelle Kameradaten, die von einem Tracking-System TRK erfasst und von der Tracking-Software TKS verarbeitet werden. Die Kameradaten umfassen im Minimum Schwenkwinkel und Neigungswinkel, Zoom und Fokus. Dies ist für eine auf ein Stativ montierte Kamera ausreichend. In einer Ausführungsform beinhalten die Kameradaten darüber hinaus 3D-Positionsdaten der Kamera CAM und Kamerabewegungsdaten wie sie von einer servomotorbetriebenen Kamerarobotik für Motion Control Zwecke benötigt werden.
-
Eine servomotorbetriebenen Kamerarobotik für Motion Control Zwecke beinhalten eine Bewegungsregelung, zum Beispiel durch ein Fly-by-Wire-System für die Kamerabewegungen. Eine Motion-Control-Kamera ist mit einem System für die computergesteuerte identische Wiederholung von Kamerabewegungen ausgestattet. Sie wird häufig in Kinoproduktionen und anderen Produktionen, die eine komplexe multiple Bildsynthese erfordern, eingesetzt. Eine Kompatibilität der Kameradaten mit dem Industrie-Standard, wie z.B. MAYA 3D-Software, erhöht die Effizienz des Drehs, da sie eine Vorabsimulation der Bewegung der Kamerarobotik ermöglicht. Die Leichtigkeit mit der identische Kamerabewegungen reproduziert werden können, verringert die Zeit, die für multiple und computergrafische Bildsynthesen bei Spezialeffekt-Produktionen benötigt wird. In dem in dargelegten exemplarischen System ist die Kamera CAM an einem Kran oder Dolly befestigt, der von Elektromotoren unter Verwendung von Joysticks 400 bewegt wird.
-
Die Tracking-Software TKS beinhaltet beispielsweise eine Mensch-Maschine-Schnittstelle (MMI) und einer Robotiksteuerung, die Fahrbefehle für den Kran erzeugt. Die Kranposition einer jeden Achse wird unter Verwendung des Joystick 400 ausgewählt. Die Positionssteuerdaten werden dann über analoge E/A in die MMI eingegeben. Die Bewegungsbahn (Spline-Kurve) vom Ausgangspunkt bis zum Ziel der Robotikbewegung wird generiert, sobald die Positionsdaten für alle Keyframes in die MMI eingegeben worden sind.
-
Wenn von der MMI ein Fahrbefehl für die Bewegungsregelung gesendet wird, werden die Daten an die Robotiksteuerung übergeben, um in die Steuerdaten der einzelnen Frames umgewandelt zu werden. Die Bewegungssteuerung innerhalb der Robotiksteuerung sendet das Befehlssignal an alle Motorantriebe in dem Steuerkasten und jeder Servomotor des Krans bewegt sich entsprechend, um den Kranbetrieb zu erreichen. Alternativ zur Steuerung über eine Fernbedienung kann das Rig manuell betätigt werden, wozu die Steuerservos auf passiv geschaltet werden.
-
Die Kamerapositionsdaten eines jeden Frames werden in ein 3D-Computergrafik Softwareformat übertragen. Das System kann daher die Bewegung der Kamerarobotik in 3D auf dem Schnittstellen PC simulieren, bevor die Dreharbeiten stattfinden.
-
Die diVERT Vorrichtung dieser exemplarischen Ausführungsform verwendet diese Daten, um eine perfekte geometrische und optische Kohärenz zwischen einer realen und einer virtuellen Kamera zu erreichen. Dies wird durch Encoder erreicht, die kontinuierlich Daten über die Rotation, die Schwenkachse (oder Horizontalpanoramaachse), die Neigungsachse (oder Vertikalpanoramaachse), den Zoom und die Fokusringe liefern. Dies erfolgt mittels einer Verzahnung der Encoder mit den jeweiligen Drehachsen und durch den Controller, der Informationen sammelt und über eine LAN Verbindung an die Tracking CPU übermittelt.
-
Der durch die Kamera CAM erfasste Bildinhalt wird der diVERT Vorrichtung entweder direkt durch eine digitale Videoschnittstelle zugeleitet (sofern er digital erfasst wurde), oder aber durch einen Filmscanner FSC oder andere Schnittstellen (sofern er analog erfasst wurde).
-
Die diVERT Vorrichtung erzeugt unter Verwendung eines Datenmanagementmoduls für jedes erfasste Frame einen Datencontainer mit dem Timecode des Frames und den Bilddaten des Frames. Darüber hinaus werden Garbage-Matte-Daten für die enthaltenen Bilddaten in den Datencontainer aufgenommen. Optional kann der Datencontainer darüber hinaus eine Vorschau des Timecodes, computergrafische Assets und/oder eine computergrafische Renderausgabe des betreffenden Timecodes enthalten.
-
Die in dargestellte exemplarische Ausführungsform der diVERT Vorrichtung enthält darüber hinaus optionale Schnittstellen zur Verbindung mit einer Speicherungs-SSD, der 3D Software 3DS, der Compositing-Software COM und zur Vorschau auf dem Dreh PVW.
-
Sofern vorhanden, ermöglicht eine Schnittstelle den Abruf computergrafischer Assets von der Speicherungs-SSD
-
Sofern vorhanden, ist die Schnittstelle für die Verbindung mit der 3D-Software 3DS bidirektional ausgelegt und ermöglicht zumindest die Übertragung der Kameradaten von der diVERT Vorrichtung zur 3D-Software 3DS wie auch die Übertragung des 3D gerenderten Outputs von der 3D-Software 3DS an die diVERT Vorrichtung. Für den Zugriff auf computergrafische Assets kann die 3D-Software 3DS über eine Schnittstelle direkt auf die Speicherungs-SSD zugreifen bzw. über die gleiche Schnittstelle die von der diVERT Vorrichtung von der Speicherungs-SSD abgerufenen computergrafischen Assets erhalten, die der 3D-Software 3DS zusammen mit den Garbage-Matte-Daten und den Kameradaten zugeleitet werden.
-
Sofern vorhanden, ermöglicht eine Schnittstelle der Compositing-Software Datencontainer für die weitere Verarbeitung, die Nachbearbeitung und/oder das finale Rendern zu importieren.
-
Sofern vorhanden, kann eine Schnittstelle verwendet werden, um eine Vorschau auf einen Monitor zu leiten.
-
Zum Beispiel können Plug-Ins für ausgewählte 3D- und Compositing-Softwarepakete bereitgestellt werden, die einen direkten 1-Klick-Import aller verknüpften Daten ermöglichen.
-
zeigt exemplarisch Module in exemplarischen Ausführungsformen der erfindungsgemäßen diVERT Vorrichtung. Das exemplarische Tracking-Modul TM zeichnet synchronisiert durch den über die Schnittstelle empfangenen Timecode die Kameradaten auf, die die Kamera-Tracking-Daten wie die Position und Ausrichtung der Kamera im 3D Raum beinhalten.
-
Das in der diVERT Vorrichtung enthaltene Tracking-Modul TM verwendet die von den Encodern des Rigs bereitgestellten Rohdaten, um alle virtuellen 3D-Kamera-Parameter zu berechnen, so dass das virtuelle Bild zu den geometrischen Merkmalen des tatsächlichen Bildes passt.
-
Das Format, in dem die Daten dann gespeichert werden, ist vorzugsweise eines, das eine Handhabung durch bekannte 3D-Softwarepakete wie Autodesk Maya, 3D MAX oder ähnliche Programme ermöglicht. Die Daten werden zum Beispiel im FBX und/oder COLLADA Dateiformat gespeichert. Diese Kompatibilität erleichtert den weiteren Workflow.
-
Das Bewegungssteuerungssystem verwendet vorzugsweise ein reserviertes Ethernet-Netzwerk zur Datenübertragung. Dies ist vorteilhaft, um unerwünschte Wechselwirkungen mit anderen unbekannten Geräten zu vermeiden und die Bandbreite aufrechtzuerhalten.
-
Die synchronisierten Kameradaten werden zusammen mit den entsprechenden Bilddaten dem Keying Modul KM zur Verfügung gestellt, das die Garbage-Matte-Daten und den Vordergrundbildinhalt für die Bilddaten festlegt.
-
Das Keying Modul KM ist dazu ausgelegt, bei jedem Frame des aufgenommenen Inhalts den Vordergrund (FG) von einem einheitlichen, beispielsweise grünen oder blauen, Hintergrund (BG) zu trennen und Garbage Mattes zu generieren, die für Postproduktionszwecke gespeichert werden. In einer Ausprägungsform ist das Keying Modul KM darüber hinaus ausgelegt, den festgelegten Vordergrundbildinhalt mit computergenerierten Hintergrundinhalten zu kombinieren, die vom Vorschaumodul (PVM) generiert werden. Das Keying wird vorzugsweise als integrierter Schaltkreis umgesetzt, um die Leistung zu maximieren, softwarebasierte Lösungen sind jedoch ebenfalls möglich.
-
Das Keying Modul KM einer exemplarischen Ausführungsform beinhaltet einen Dual Link 4:4:4:4 RGBA Eingang und/oder Ausgang (Vordergrund (FG) In, Hintergrund (BG) In und FG + BG Out) für beste Compositing-Ergebnisse, Umgehung der Vorverarbeitungsstufen und die Bereitstellung eines unveränderten Bildes für die Hauptverarbeitungsstufen. Um eine maximale Flexibilität zu gewährleisten, kann es ermöglicht werden, den FG Input, den BG Input oder den FG + BG Output individuell als 4:4:4:4 oder 4:2:2 zu wählen.
-
Je nach Ausführungsform kann der Alphamasken- oder Alphakey-Input als Teil des Dual-Link-Signals geliefert werden und/oder ein separater Input sein. Ebenso kann Alpha out Teil des Dual-Link-Signals und/oder ein separater Output sein.
-
Das Keying Modul KM einer exemplarischen Ausführungsform ist dafür ausgelegt, 4:2:2 (Y, Cb, Cr)-Signale zu empfangen und eine Artefaktkorrektur in den 4:2:2 (Y, Cb, Cr)-Signalen vorzunehmen, bei denen Objekte mit hohem Kontrast und scharfen Übergängen einen unerwünschten Ringing-Artefakt beim Bluescreen- / Greenscreen-Compositing aufweisen können.
-
Die 4:2:2 Artefaktkorrektur beseitigt oder reduziert Ringing-Artefakte in dem Übergangsbereich der FG-Objekte gegenüber der Unterlage (dem Bildschirm) unter Beibehaltung des ursprünglichen Bildes innerhalb des opaken FG-Objekts. Kein Detail des FG-Objekts geht bei diesem Prozess verloren. Nur das Ringing-Element wird aus den Übergangsbereichen entfernt, während jede Haarsträhne oder semitransparente Objekt erhalten bleibt
-
Digitale Bilderfassungsvorrichtungen wie CCD- oder CMOS sind von Natur aus mit Rauschen belegt und sind nicht in gleicher Weise für alle Wellenlängen des sichtbaren Spektrums empfindlich. Dies führt zu höheren Rauschpegeln im roten und im blauen Kanal eines RGB-Bildes im Vergleich zum Grünkanal. Beim Bluescreen- oder Greenscreen-Bildcompositing tragen alle drei Kanäle des FG gleichermaßen zur Bearbeitung des Originalbildes bei. Daher wird der Kanal mit dem stärksten Rauschen (blau) einen Einfluss auf den Kanal mit dem geringsten Rauschen (grün) ausüben.
-
Das Keying Modul KM kann weiter angepasst werden, um die Rauschpegel der Rot- und Blaukanäle des FG signifikant zu reduzieren, ohne dass eine sichtbare Verringerung in der feinen Detailinformation des Bildes auftritt (alle Regler in der Standardeinstellung). Der grüne Kanal wird den ihm innewohnenden Rauschpegel beibehalten (z.B. basierend auf den Verstärkungseinstellungen der Kamera), da auf diesen Kanal keine Rauschunterdrückung angewendet wird.
-
Das Keying Modul KM verwendet mindestens eines der folgenden Keying-Verfahren: Luma-Keying, Differenz-Keying, Chroma-Keying, HLS-Keying Farbdifferenz-Keying und 3D-Keying. Jedes Verfahren hat seine Vorteile und Nachteile. So ist zum Beispiel Luma-Keying aufgrund seiner Farbenblindheit für die Mehrheit der Keying-Aufgaben ohne Nutzen, während es bei speziellen Keying Aufgaben wie der Textextraktion (schwarzer Text auf weißem Hintergrund) durchaus hilfreich sein kann.
-
Beim Differenz-Keying oder Chroma-Keying lässt die Qualität nach, je stärker die Wertvariation der Hintergrundpixel ausfällt, die stets in den Bildern enthalten ist. Daher kombiniert das Keying Modul KM in einer Ausführungsform zwei oder mehr dieser Keying-Verfahren.
-
Das Keying Modul KM trennt somit die Bilddaten in die Bilddaten der Vordergrundschicht und die der Hintergrundschicht, wobei Erstere die zu erhaltenden aufgenommenen Bildbereiche zeigt und Letztere diejenigen Bildbereiche zeigt, die zu entfernen oder zu ersetzen sind, zum Beispiel durch computergenerierte Inhalte oder durch Inhalte, die zu einem anderen Zeitpunkt oder von einer anderen Position aufgenommen wurden. Dies erfolgt in einer synchronisierten Art und Weise, so dass Garbage-Matte-Daten mit Timecode zur Verfügung gestellt werden können.
-
Ein Daten-Streaming-Verwaltungsmodul DSM stellt die Synchronisation der Abläufe während der Aufnahme sicher. Optional kann das DSM Modul die Bilddaten auch hoch oder runter skalieren. Das Daten-Streaming-Verwaltungsmodul DSM kann darüber hinaus "Container" erstellen, die alle Daten in Bezug auf einen Take einer bestimmten Aufnahme enthalten. Dann werden alle Dateien mit einem bestimmten Shot / Take verknüpft sein. Hierzu werden zusätzlich zu den grundlegenden Bilddaten Metadaten verwendet, die in die Datei mit aufgenommen werden. Eine Datenbank ermöglicht es dem Benutzer, auf benötigte Informationen mittels eines Datei-Browsers zuzugreifen, wobei die relevanten Daten basierend auf den Metadaten gruppiert sind. Die Metadaten beinhalten zumindest den Timecode. Der Timecode ist die wichtigste Information, die während der Produktion verwendet wird: von der Aufnahme bis zum Schnitt und schließlich zur Postproduktion. Der Timecode wird verwendet, um Shots zu identifizieren, ihre Länge festzulegen, etc.
-
Weitere Metadaten können Informationen zu Produktion / Shot / Take beinhalten, spezifizieren, ob der betreffende Shot „gut“ oder „schlecht“ ist und/oder die Rollennummer angeben (wenn die Aufnahme mit analogen Medien erfolgt).
-
Der Timecode kann aus verschiedenen Quellen zur Verfügung gestellt werden. Daher ist es vorzuziehen, wenn eine Auswahl des Timecodes erfolgen kann. Beispiele für Timecodes unter denen eine Auswahl erfolgen könnte, sind Vertical Intervall Time Code (VITC) gemäß SMPTE 12M-1-2008; Ancillary Time Code (ATC, früher als DVITC bekannt) nach SMPTE 12M-2-2008; Linear Time Code (LTC) nach SMPTE 12M-1-2008 und der Timecode aus der Anwendung, die die MXF-Encoder steuert (z.B. Echtzeit-Aufnahmegerät oder Software-Encoder).
-
Der generische Datencontainer beinhaltet die Essence mit dem Timecode im Essence Stream. Die Essence enthält die Bilddaten und kann darüber hinaus Tondaten, zusammengesetzte Daten und/oder Systemdaten enthalten. Die Metadaten, die Container zu Quellpaketen verbinden, zeigen bis zu n Timecode-Spuren an, wodurch Diskontinuitäten enthalten sein können. Die Metadaten, die die Container zu Materialpakete verbinden, zeigen maximal eine Timecode-Spur an, so dass keine Diskontinuitäten enthalten sein können.
-
Das Daten-Streaming-Verwaltungsmodul DSM gibt einen Timecode aus, wobei der Standardtimecode für den Output dem Steuerungstimecode entspricht. Angeschlossene Geräte mit fortgeschrittener Technik können es darüber hinaus zulassen, dass der Output Timecode wie folgt konfiguriert wird: als Preset Timecode oder als Quelltimecode, der in dem Essence Container gespeichert wird, der durch das abgespielte Paket beschrieben wird (d.h. das Materialpaket einer OP1a-, OP2a- oder OP3a-Datei oder das Quellpaket einer Datei mit einem beliebigen Betriebsmuster).
-
Da mehrere Module parallel laufen, muss sichergestellt sein, dass alle Module Daten erzeugen, die basierend auf dem gleichen Timecode den gleichen IN- und OUT-Punkt aufweisen. Dies bedeutet, dass die Module synchronisiert werden müssen, wenn die Aufnahme beginnt und stoppt.
-
In einer Ausführungsform verwendet die diVERT Vorrichtung ein auf dem Master-Slave-Verfahren basierendes Protokoll, beispielsweise ein „Video Disk Control Protocol“, das auch als "Sony Protocol" bekannt ist, bei dem in einer Point-to-Point-Topologie eine Steuervorrichtung die Initiative im Hinblick auf die Kommunikation zwischen dem steuernden Automatisierungsgerät und der gesteuerten Vorrichtung übernimmt.
-
Die Garbage-Matte-Daten und die Bilddaten werden dann von dem Datenmanagementmodul DMM zusammen mit dem Timecode und den Kameradaten in einem gemeinsamen Container gespeichert. Passende Attribute können ebenfalls hinzugefügt werden. Der Container kann die Kameradaten als eine Datei in dem Format, in dem sie durch das Tracking-Modul TM aufgezeichnet werden, enthalten. Der Container wird auf dem Speichergerät SSD gespeichert, zum Beispiel auf einem Solid State Videorecorder mit zwei oder mehr Steckplätzen für SSDs, die ein "Hot-Swap" während des Betriebs und der Aufnahme ermöglichen. Die Daten werden basierend auf einem SMPTE Timecode mittels der in den einzelnen Dateien und einer internen Datenbank enthaltenen Metadaten verknüpft.
-
Der Container kann dann für die Erzeugung des endgültigen Outputs FO verwendet werden.
-
Zusätzlich ist ein Vorschau-Modul PVM vorhanden, dass unter Verwendung der generierten Container auf dem Set in Echtzeit eine Vorschau erstellt. Die Vorschau kann zu dem Container hinzugefügt werden, was für die weitere Verarbeitung oder zukünftige Vorschauzwecke von Nutzen ist.
-
Das Vorschau-Modul PVM beinhaltet, wie in dargestellt, eine 3D-Renderengine RND, die einen visuellen Output FO ausgibt. Das Vorschau-Modul PVM erhält als Input zumindest die Kamera-Positionsdaten. Die Hauptaufgabe der Echtzeit-3D-Renderengine RND ist es, basierend auf der Eingabe (XYZ-Koordinaten, Rotation, Zoom, Fokus) seitens des Tracking-Moduls TM das virtuelle 3D-Modell inklusive Animation mit der richtigen Perspektive wiederzugeben. Die visuelle Ausgabe FO ist das Ergebnis dieses Prozesses; sie kann betrachtet, erneut betrachtet und abgespeichert werden. Das Vorschau-Modul PVM ist bidirektional mit dem Keying Modul KM verbunden, welches ein Hintergrundbild mit computergeneriertem Inhalt von der 3D Renderengine RND des Vorschaumoduls erhält und ein zusammengefügtes Bild bestehend aus dem erhaltenen Hintergrundbild und dem Vordergrundbild, das aus den vollständigen Bilddaten der Kamera extrahiert wurde, zurückgibt. Das Vorschaumodul PVM empfängt das zusammengesetzte Bild vom Keying-Modul KM und erzeugt den endgültigen visuellen Output FO, der als Vorschau angezeigt und/oder zur Speicherung kodiert werden kann. Der visuelle Output kann zum Beispiel gemäß dem H.264-Videokomprimierungsstandard hardwaremäßig codiert und im Speichergerät SSD entweder als Teil der Datencontainer oder einzeln abgespeichert werden.
-
Die diVERT Vorrichtung einer exemplarischen Ausführungsform der Erfindung ist so ausgelegt, dass das Vorschau-Modul nicht mit den der aktuellen Kameraposition entsprechenden Kamerapositionsdaten versehen wird, sondern mit den Daten einer vorhergesagten Kameraposition. Hierzu verfügt die Vorrichtung dieser Ausführungsform über ein Kamerapositionsvorhersagemodul. Das Modul erstellt eine Vorhersage der zukünftigen Kameraposition für einen zukünftigen Zeitpunkt basierend auf der aktuellen Kameraposition und/oder der aktuellen Kamerabewegungsinformation. Der zukünftige Zeitpunkt wird so gewählt, dass die Vorhersageunsicherheit minimal bleibt, die Renderengine jedoch genügend Zeit für das Rendern eines Hintergrundbildes aus computergenerierten Inhalten hat, bevor der betreffende zukünftige Zeitpunkt erreicht wird. Dann sind das aufgenommene Bild und der computergenerierte Inhalt gleichzeitig verfügbar und können in Echtzeit gerendert werden.
-
In einer exemplarischen Hardware-Realisierung der Erfindung synchronisiert eine Masterclock CPU das System durch das Erzeugen eines Timecodes beispielsweise unter Verwendung eines Black&Burst Signals (Bi-Level-Sync.), das von einem Synchrongenerator ausgegeben wird, wobei der Host-Timecode-Generator an das Black&Burst Signals gekoppelt ist, während die HD-Kamera und die Filmklappe mittels eines HD Sync Signals (Tri-Level-Sync.) synchronisiert werden, das vom HD-Sync-Generator ausgegeben wird. Die Filmklappe und das Motion Control-System arbeiten auf der Basis dieser Zeitachse, wobei die Filmklappe die Synchronisation von Bild und Ton unterstützt und die Bezeichnung und Kennzeichnung bestimmter Szenen während der Aufnahme ermöglicht.
-
Eine Echtzeit-Render-CPU rendert alle digitalen Elemente (Animationen und/oder statischen Hintergrund) in Übereinstimmung mit den von der Tracking CPU bereitgestellten Tracking-Daten und dem Timecode. Die Keying-CPU rendert die Keying-Masken oder Garbage Mattes zur Trennung des Hintergrunds von den beizubehaltenden Elementen. Die Garbage Mattes ermöglichen die Integration / Zusammenfügung der beibehaltenen Elemente mit den digitalen Elementen. Dies erfolgt im Spezialeffekt-Studio, wo das endgültige Bild unter Verwendung von Computergrafikelementen erzeugt wird. Auf dem Set wird eine Echtzeit-Vorschau ermöglicht.
-
In einer Ausführungsform ist eine Renderengine implementiert, die High-Level-Shader und Multi Texturierung unterstützt und lokale und globale Mehrfachdurchgänge ermöglicht.
-
Die implementierte Renderengine verfügt über einen leistungsoptimierten Datenspeicher. Statische Geometriedaten können direkt auf der Grafikvorrichtung, z.B. in einem OpenGL Vertex Buffer-Objekt oder einer Anzeigeliste gespeichert werden. Die implementierte Renderengine verfügt darüber hinaus über ein Effect Framework, aus dem Standardeffekte wie „Normal Mapping“ und „Shadow Mapping“ ausgewählt und in das problemlos neue Effekte integriert werden können (für eine schnelle Erstellung von Prototypen). Dieses Effect Framework ist flexibel in Bezug auf die Anzahl der Lichter und verwendeten Texturen. Es ermöglicht die Hinzufügung zusätzlicher Effekte auf alle Objekte einer Szene, welche mit den auf den einzelnen Objekten bereits enthaltenen Effekten verschmelzen sollten. Darüber hinaus ermöglicht es die einfache Erzeugung einer Tiefen-Version eines Effekts. Die implementierte Renderengine nutzt Cg, GLSL oder HLSL Programme für das Rendern und stellt ein Postproduktions-Effect-Framework bereit, dass für „Tone-Mapping“, „Blooming“ und andere Effekte verwendet werden kann, die mit Fragmenten der Bildpuffer arbeiten.
-
Die implementierte Renderengine bietet die Möglichkeit, mehrere Renderziele anzugeben und unterstützt damit Rendertechniken wie das „Deferred Rendering“. Unterstützte Dateiformate sind zumindest das Maya-Dateiformat, unterstützte Bildformate umfassen bmp, JPEG, OpenEXR und png. Die implementierten Abschattungstechniken der Engine wie volumetrische Stencilschatten und „Shadow Maps“ werden wie jeder andere Render-Effekt behandelt. Die implementierte Engine unterstützt Effekte, die lokale oder globale Mehrfachdurchgänge benötigen, durch das Handling der Anzahl an Durchläufen, die zur Anwendung eines Effekts benötigt werden. Die Engine nutzt das „Culling“ der Szene und die Sortieren der renderbaren Objekte. Szenengraph-Algorithmen sind enthalten, die eine einfache Möglichkeit des Zugriffs auf Szenengraph-Daten sowie eine Überquerung eines gegebenen Szenengraphen mittels der Entwicklung eines neuen Szenengraph-Algorithmus ermöglichen. Entwickler können komplexe „Render States“ einfach einstellen. Die Engine ist mittels einer gängigen Skriptsprache wie Lua, Python oder JavaScript skriptfähig. Die Renderengine ist unabhängig von der Grafik-API, somit können z.B. OpenGL oder Direct3D für die Wiedergabe verwendet werden. Für ein beschleunigtes Rendern ermöglicht die Engine Hardware-Okklusionsabfragen. Ein einfacher Editor ermöglicht es, Szenengraphen zu erstellen und Effekte auf die Objekte anzuwenden.
-
Um die Funktionalität der Renderengine nach Thema und Software-Ebene zu gruppieren, werden als Level organisierte Module eingeführt. Diese Module werden als Kern, Graphik, GraphicsGL und GraphicsD3D bezeichnet.
-
Das Kernmodul arbeitet auf der untersten Softwareebene der Engine und bietet Submodule wie Systemfunktionen, ein allgemeines Anwendungs-Framework und gemeinsame Dienstprogrammfunktionen.
-
Das Grafikmodul baut auf dem Kernmoduls auf und stellt eine Schnittstelle für 2D- und 3D-Grafiken bereit.
-
Neben weiteren Submodulen beinhaltet das Grafikmodul eine Grafik-API-unabhängige Renderschnittstelle, ein Effect Framework, einen Szenengraphen und Importer für mehrere Dateiformate von 3D-Modellen.
-
Die Module GraphicsGL und GraphicsD3D implementieren die Grafik-API-unabhängige Renderschnittstelle, die vom Grafikmodul zur Verfügung gestellt wird.
-
Diese Implementierung schlägt die Brücke zwischen der Renderschnittstelle und OpenGL bzw. Direct3D.
-
Das Engine Framework implementiert ein Aktorenkonzept, bei dem ein Aktor eine Klasse darstellt, die durch bloße Bereitstellung ihrer Type ID instantiiert werden kann und deren Eigenschaften von einem Daten-Chunk konfiguriert werden. Das bedeutet, dass durch die Bereitstellung einer XML-Darstellung eines Chunks ein Aktor und alle seine Kinder instantiiert und konfiguriert werden können. Die Aktor-Klasse ist auch die Basisklasse für alle veröffentlichten Klassen, z.B. Klassen, die von einer Skriptsprache her zugänglich oder serialisierbar sein sollten. Es gibt einige vordefinierte Aktoren für das Laden von XML-Beschreibungsdateien und Plugins.
-
Der Szenengraph wird verwendet, um die Objekte einer Szene in einer hierarchischen Weise zu organisieren. Der Benutzer kann verschiedene Arten von Knoten erstellen, um die Netzlinien, Lichter und Kameras einer Szene zu arrangieren. Die Rendereffekte werden nicht direkt auf die Netzlinien angewandt, sondern werden der Szene übergeben, indem Instanzen spezieller Knotenklassen erstellt werden.
-
Bei jeder Aktualisierung des Szenengraphen, werden seine renderbaren Objekte mit dem zugrunde liegenden „DrawGraph“ synchronisiert. Renderbare Objekte bestehen in diesem Zusammenhang aus einem Geometrieobjekt in Kombination mit einem Effekt, der die Art und Weise definiert, in der die Geometrie gerendert wird.
-
CgFX Effekt-Dateien werden unterstützt. Daher ersetzt der verwendete Effekt-Code das Cg Framework Programm während des Rendervorgangs. Effektdateien sind ein komfortables Mittel für die schnelle Prototypenerstellung bei neuen Effekten.
-
Die Engine ermöglicht eine Verkettung kleiner Code-Fragmente, um den gewünschten Shader-Code auf einem anderen Level als dem Quellcode zu erstellen, wodurch eine Neuanordnung und/oder Deaktivierung von nicht benötigten Fragmenten möglich ist. Aufgrund der Verwendung der Cg-Schnittstellenfunktion muss sich DIVERT nicht um Variablennamen, Registerzuweisungen und andere Ursachen möglicher Programmabbrüche kümmern. Darüber hinaus können die Shader-Fragmente (in diesem Zusammenhang als Techniksegmente bezeichnet) „Render States“ enthalten, die zusammengeführt und vom System automatisch angewandt werden. „Abstract Shade Trees“ werden entworfen, um den Quellcode für einen Rendereffekt zu erzeugen und werden verwendet, um Abhängigkeiten auf der Quellcode-Ebene aufzulösen.
-
Der Szenengraph der Renderengine nimmt keine direkten Grafik-API-Aufrufe vor. Der Szenengraph mit seinen Knoten, die untereinander in einer Eltern-Kind-Beziehung verbunden sind, wird nur bereitgehalten, um es dem Benutzer zu ermöglichen, die Objekte in einer hierarchisch strukturierten Weise zu organisieren. Es ist nicht vorgesehen, dass die auf dem Graphen verlaufenden Algorithmen die Blattknoten direkt referenzieren, sie finden sie vielmehr, indem sie von der Wurzel ausgehend zum Blatt fortschreiten.
-
Wenn Szenengraphen jedoch hunderttausende von Objekten enthalten, die in tausenden von Gruppen gruppiert sind (z.B. ein Szenengraph zur Modellierung einer Stadt) führt die Durchquerung zu einem nicht zu vernachlässigenden Verarbeitungsaufwand. Der Durchquerungsaufwand ist am niedrigsten, wenn alle Knoten direkte Kinder des Wurzelknotens sind, was nicht zulässt, dass vom Benutzer logisch oder räumlich organisierte Gruppen gebildet werden.
-
Um es dem Benutzer zu ermöglichen, die Knoten in strukturierter Form zu organisieren und gleichzeitig eine schnelle Durchquerung zu ermöglichen, wird eine Szenendatenbank bereitgestellt, die den Algorithmen einen direkten Zugang zu den Daten der Szenen-Knoten ermöglicht, zum Beispiel, um eine Liste aller Netzlinien der Szene zu erstellen; wie auch zu den strukturellen Kontextdaten eines jeden Knotens für eine direkte Abfrage, zu einer Auflistung aller ausgegebenen Variablen und Effekte des Szenengraphen, zu einer Auflistung aller Culling-Objekte, zu einer Liste aller Controller und zu einer Auflistung aller renderfähigen Elemente.
-
Die Szenendatenbank ist daher nur eine andere Sicht auf die Daten der Szene – sie beinhaltet die gleichen Daten wie der Szenengraph, jedoch in einer flachen und schnellen Art und Weise. Wenn ein Controller Daten im Szenengraphen ändert, werden diese Änderungen an die Szenendatenbank weitergeleitet, um ihren internen Status zu aktualisieren.
-
Um die Datenansicht des Szenengraphen mit der Szenendatenbank zu synchronisieren, wird ein ereignis-basiertes System verwendet. Die Verarbeitungsreihenfolge von einer registrierten Änderung des Szenengraphen hin zu einem Update in der Szenendatenbank kann die folgenden Schritte aufweisen:
- • Erzeugung einer Liste von Aufgaben, die in der Szenendatenbank durchgeführt werden müssen, wenn Daten an einem Knoten des Szenengraphen geändert werden.
- • Seitens des Knotens Aussendung eines Ereignisses an den globalen Scenengraph Kontext unter Spezifikation der Ereignis-ID, die angibt, welche Datenart geändert worden ist, und dem Knoten selbst als Absende-Objekt.
- • Verarbeitung aller ausgelösten Ereignisse zu Beginn eines Frames des globalen Szenengraph Kontexts.
- • Erstellung von Aufgaben für jedes Ereignis und Zusammenstellung der generierten Aufgaben in einer Auflistung
- • Durchforsten der Liste nach doppelten Aufgaben und Sortierung der Listen. Zum Beispiel müssen zuerst die Welt Transformationsmatrizen der Knoten aktualisiert werden, bevor ihre Hüllvolumina im Raum der Welt neu berechnet werden können. Aufgaben, die sich auf Erstere beziehen, werden so einsortiert, dass sie vor den Aufgaben, die sich auf Letztere beziehen, abgearbeitet werden.
- • Ausführung der aufgelisteten Aufgaben.
-
Mit diesem Konzept wird redundante Arbeit im Hinblick auf die einzelnen Szenengraph-Knoten verhindert. Dies wird, wie oben ausgeführt, durch die Beseitigung doppelter Aufgaben erreicht; ein weiterer Vorteil ist, dass eine Aufgabe nur auf den Knoten ausgeführt wird, die Ihre Daten aktualisieren müssen. So aktualisiert das System zum Beispiel nur den strukturellen Kontext derjenigen Knoten, die durch eine Datenänderung innerhalb des Szenengraphen beeinflusst werden.
-
Um eine Liste der Aufgaben für ein gesendetes Ereignisse zu erzeugen, wird eine Schnittstelle eingeführt, bei der jede Implementationsklasse eine Ereignis-ID darstellt. Jede konkrete Klasse generiert nur die Aufgaben, die erforderlich sind, um das Ereignis, das sie repräsentiert, zu verarbeiten. Die erzeugte Aufgabe ist nur eine Klassen-Instanz, die einen Aufgabencode, wie oben aufgelistet, zusammen mit einer Liste der Knoten enthält. Wenn die Aufgabe ausgeführt wird, wird der Arbeitsprozess der Aufgabe nur auf diese Liste von Knoten angewandt.
-
Jeder Aufgaben-Code hat eine korrespondierende Klassen-Instanz, die nur eine bestimmte Aufgabe ausführen kann. Diese Ausführungs-Klassen unterstützen eine korrespondierende Schnittstelle. Somit wird, wenn der globale Szenengraph Kontext eine bestimmte Aufgabe ausführt, letzterer ein Objekt suchen, das den Code der Aufgabe handhaben kann. Dann wird die Execute()-Methode des zurückgegebenen Objekts aufgerufen. Diese Methode erhält die Liste der Knoten als Parameter, mit denen der Executor zu arbeiten hat. Sowohl das Konzept der Aufgabengenerierung als auch das Konzept der Aufgabenausführung folgen dem Befehlsentwurfsmuster.
-
Das implementierte Besuchermuster, das doppelten Versand verwendet, ist ebenfalls im Szenengraphen integriert. Dies ermöglicht eine Unterstützung der Algorithmen anderer Szenengraph-Frameworks wie auch die einfache Portierung für den Szenengraphen in Übereinstimmung mit der implementierten Renderengine. Der Aufgabenausführer für das Aktualisieren des strukturellen Kontexts der Knoten verwendet das Besuchermuster, um die Daten aus dem Szenengraphen zu entnehmen. Darüber hinaus wird das Konzept eines Ressourcenmanagers eingeführt.
