Transloadit

Was ist eine EXR-Datei?

Eine EXR-Datei ist ein Bild mit hohem Dynamikumfang im OpenEXR-Format: ein oder mehrere benannte Kanäle mit Gleitkomma-Samples von 16 Bit oder 32 Bit oder vorzeichenlosen Ganzzahl-Samples von 32 Bit sowie Header-Attribute, die diese beschreiben. Pixeldaten können unkomprimiert sein oder eines von mehreren verlustfreien oder verlustbehafteten Kompressionsverfahren nutzen.

So funktionieren EXR-Dateien

Eine OpenEXR-Datei beginnt mit einer vier Byte langen magischen Zahl (76 2f 31 01) und einem Versionsfeld, dessen Flag-Bits eine einteilige gekachelte Datei, eine mehrteilige Datei oder das Vorhandensein von Deep-Daten kennzeichnen. Das Kachel-Flag wird nur für ein einteiliges gekacheltes Bild gesetzt. Bei mehrteiligen Dateien und Dateien mit Deep-Daten gibt das Attribut type jedes Teils an, ob er Bildzeilen oder Kacheln enthält. Darauf folgt für jeden Teil ein Header mit benannten Attributen; channels, compression, dataWindow, displayWindow, lineOrder, pixelAspectRatio, screenWindowCenter und screenWindowWidth sind in jedem Header erforderlich. Pixel werden in Blöcken aus Bildzeilen oder in Kacheln gespeichert, deren Positionen über eine Offset-Tabelle ermittelt werden. Nur gekachelte Dateien können mehrere Auflösungsstufen enthalten (Mipmaps oder Ripmaps); eine Datei mit Bildzeilen enthält eine. Seit OpenEXR 2.0 kann eine Datei mehrere unabhängige Teile und Deep-Daten enthalten, bei denen jedes Pixel eine Liste von Samples variabler Länge umfasst. Konventionsgemäß sind Farbkanäle mit Alpha vormultipliziert. In der Produktion enthält eine EXR-Datei typischerweise gerenderte oder durch Compositing erzeugte Einzelbilder, die später für die Anzeige transformiert werden.

Wichtige Fakten

  1. Gehen Sie nicht von einem einzigen RGBA-Bild aus. Jeder Kanal deklariert seinen eigenen Namen und Typ: HALF (Gleitkomma mit 16 Bit) für reguläre Bilddaten, FLOAT (32 Bit), wenn mehr Wertebereich oder Präzision benötigt wird, etwa für Tiefe, und UINT (32 Bit) für diskrete Werte wie Objekt-IDs. Nur wenige Namen wie R, G, B und A haben eine vordefinierte Bedeutung. Ebenen beruhen auf einer Namenskonvention wie light1.specular.R, und eine mehrteilige Datei ergänzt separat benannte Teile. Ein Konverter muss vorgegeben bekommen oder selbst auswählen, welche davon zum Ausgabebild werden.
  2. Die Bildgröße ergibt sich aus zwei Rechtecken, nicht aus einem. Das Anzeigefenster ist der vorgesehene Bildrahmen; das Datenfenster ist der Bereich, der tatsächlich Pixel enthält. Es kann kleiner sein (ein gerenderter relevanter Teilbereich) oder größer (Overscan, der für Unschärfe oder Kameraverwacklungen erhalten bleibt). Jedes Fenster wird durch die Koordinaten seiner Eckpixel angegeben. Ein Anzeigefenster von (0, 0) bis (1919, 1079) ist daher 1920 mal 1080 groß. Laut OpenEXR-Dokumentation werden Pixel außerhalb des Anzeigefensters normalerweise nicht angezeigt, und ein Anzeigeprogramm füllt Anzeigebereiche außerhalb des Datenfensters mit einer Standardfarbe. Software, die ihre Ausgabegröße allein aus dem Datenfenster ableitet, gibt solchen Dateien falsche Abmessungen oder eine falsche Platzierung.
  3. Ob die Kompression verlustfrei ist, hängt vom Verfahren und teilweise vom Kanaltyp ab. Das Attribut compression im Header gilt für alle zugehörigen Kanäle. Ein Verfahren muss daher für jeden gemeinsam gespeicherten Kanaltyp geeignet sein. PIZ, ZIP, ZIPS und RLE sind verlustfrei. PXR24 erhält Kanäle der Typen HALF und UINT exakt, rundet Daten vom Typ FLOAT aber auf 24 Bit. B44 und B44A sind für Kanäle vom Typ HALF verlustbehaftet und lassen Kanäle der Typen UINT und FLOAT unkomprimiert. DWAA und DWAB sind verlustbehaftete, DCT-basierte Verfahren für RGB-Daten. Deep-Daten erlauben nur unkomprimierte Speicherung, RLE, ZIPS oder ZIP. Die aktuelle Dokumentation führt auch neuere Verfahren auf: HTJ2K256 und HTJ2K32 (verlustfrei, High-Throughput JPEG 2000), LJ2K (verlustbehaftet) und ZSTD (verlustfrei). Prüfen Sie, ob jede Leseanwendung in der Pipeline das von Ihnen geschriebene Verfahren unterstützt.
  4. Konventionsgemäß verhalten sich RGB-Werte linear zum Szenenlicht, und 1,0 bildet keine Obergrenze. Die OpenEXR-Konvention setzt Mittelgrau auf 0,18. Helle Objekte wie Feuer und Glanzlichter überschreiten durchaus 1,0, sodass die Anzeige eines solchen Bildes mindestens eine Gammakorrektur und häufig Tone-Mapping erfordert. Dies ist eine Konvention, keine Garantie: Laut Dokumentation sollen Bilder linear sein, die Bibliothek verlangt aber nicht, dass ein deklarierter Farbraum linear ist. Auch die verwendeten RGB-Primärfarben sind möglicherweise nicht zuverlässig in der Datei angegeben: Laut Dokumentation gilt das Attribut chromaticities nicht mehr als verlässlich, das Fehlen von colorInteropID impliziert keine linearen Werte in Rec. 709, und colorInteropID, neu in OpenEXR 3.4, ist nun die empfohlene Kennung. Stimmen Sie den Farbraum einschließlich der Frage, ob die Werte linear sind, mit den Erstellern der Dateien ab, statt ihn abzuleiten.

Wann EXR-Dateien relevant sind

Pipelines für visuelle Effekte wählen EXR für Compositing mit linearen Lichtwerten, Render-Passes und hochpräzise Zwischenformate. Es ist ein Arbeitsformat: Konventionsgemäß beschreiben seine Farbwerte Szenenlicht und kein Anzeigesignal. Um eine darstellbare Ableitung zu erzeugen, sind daher eine gezielte Farbtransformation und eine Entscheidung über die zu verwendenden Kanäle, den Teil und das Fenster erforderlich.

So hilft Transloadit bei EXR-Dateien

Transloadits Bildformattabelle, die auf ImageMagick basierende Robots wie /image/resize abdeckt, führt EXR als Format auf, das diese Robots lesen und schreiben können. Die Zeile nennt die Version der OpenEXR-Bibliothek im ImageMagick-Build. Diese begrenzt, welche Kompressionsverfahren und Attribute der Build kennen kann.

Die Tabelle zeigt, was der ImageMagick-Build lesen und schreiben kann. Sie dokumentiert nicht, welche Kanäle, welchen Teil, welches Fenster oder welche Farbtransformation eine Konvertierung verwendet. Verarbeiten Sie eine repräsentative Datei aus Ihrer Produktion mit Ihrer Assembly und prüfen Sie das Ergebnis, bevor Sie sich darauf verlassen.

Entdecken Sie Transloadits Möglichkeiten für Dateiformate & Komprimierung

Quellen

Machen Sie aus Medienwissen eine funktionierende Pipeline

Verbinden Sie Uploads, Verarbeitung, KI, Storage und Auslieferung über eine deklarative API – um Encoding-Stack, Skalierung und ständig wechselnde Formate müssen Sie sich nicht selbst kümmern.

Transloadit kostenlos ausprobieren