Ultra HDR-Bildformat (Version 1.0)

Einführung

In diesem Dokument wird das Verhalten eines neuen Dateiformats definiert, das ein logarithmisches Bereichsergebniskartenbild in einer JPEG-Bilddatei codiert. Legacy-Reader, die das neue Format nicht unterstützen, lesen und zeigen das konventionelle Bild mit niedrigem dynamischem Bereich aus der Bilddatei an.Leser, die das Format unterstützen, kombinieren das Hauptbild mit der GainMap und rendern ein High Dynamic Range-Bild auf kompatiblen Displays.

Im weiteren Verlauf dieses Dokuments werden die Methoden der Prozesse beschrieben, die zur Verwendung dieses Formats erforderlich sind. Auf übergeordneter Ebene sieht der Lebenszyklus eines Bildes in diesem Format so aus:

1. Codierung

   1. Kartenerstellung steigern
   2. Kartenkomprimierung erhöhen
   3. Kartencontainer generieren

2. Decodierung

Abbildung 1: Beispieldateilayout und relevante Metadaten.

Ziel

Das Ziel dieses Dateiformats besteht darin, zusätzliche Informationen in SDR-Bilddateien zu codieren, die in Kombination mit der Anzeigetechnik verwendet werden können, um die optimale HDR-Darstellung in einer einzigen Datei zu erstellen.

Damit das praktikabel ist, muss das Dateiformat folgende Anforderungen erfüllen:

• Es muss abwärtskompatibel sein, damit auf „einfachen Betrachtern“ das herkömmliche SDR-Bild angezeigt wird.
• Sie nehmen nicht zu viel Platz ein.

Darüber hinaus muss das Anzeigeverfahren folgende Anforderungen erfüllen:

• Zum Decodieren ist keine aufwendige Verarbeitung erforderlich.
• Es muss in der Lage sein, sich an ein beliebiges Verhältnis zwischen den HDR- und SDR-Weißpunkten eines Displays anzupassen, das je nach Gerät oder sogar vorübergehend auf einem einzelnen Gerät erheblich variieren kann.

Außerdem muss das Verfahren in der Lage sein, alle der vorherigen Aktionen auszuführen, ohne:

• Spitzlichter werden zugeschnitten.
• Schatten zerquetschen.
• Lokalen Kontrast ändern oder komprimieren
• Ändern der relativen tonalen Beziehungen (zwischen Objekten in der Szene)

Abhängigkeiten

Im Folgenden sind normative Verweise für diese Spezifikation aufgeführt:

• Adobe XMP-Spezifikation, Teil 3: Speicherung in Dateien
• ISO 16684-1:2019 XMP-Spezifikation, Teil 1
• ISO/IEC 14496-12 ISO-Basismediendateiformat
• T.81 (09/92) Digitale Komprimierung und Codierung von Standbildern mit Tonsignalen
• Whitepaper des CIPA DC-x 007-2009 Multi-Picture Format

Definitionen

• SDR-Anzeige

  • Ein herkömmliches Display, das nicht für die Anzeige von HDR-Inhalten entwickelt wurde. Diese Displays erzeugen in der Regel eine nominale Spitzenhelligkeit von etwa 400 cd/m² oder weniger.

• HDR-Display

  • Ein Display, das für HDR-Inhalte optimiert ist Diese Displays haben in der Regel eine höhere Nominalhelligkeit als ein SDR-Display von 800 cd/m² oder mehr und haben in der Regel auch bessere Kontrastverhältnisse als SDR-Displays.

• Primäres Bild

  • Die erste Instanz eines Bildes in einer GContainer-Datei, an die sekundäre Mediendateien angehängt sind. Das primäre Image enthält GContainer XMP-Metadaten, die die Reihenfolge und Attribute nachfolgender sekundärer Medienelementdateien im Dateicontainer festlegen.

• Sekundäres Bild

  • Nachfolgende Medienelementdateien, die an das primäre Image in einer GContainer-Datei angehängt werden.

• Bereichskomprimierung

  • In der Fotografie haben reale Szenen oft einen größeren Dynamikumfang, als eine SDR-Anzeige abbilden kann. Vorgänge wie die Bereichskomprimierung oder lokale Tone-Zuordnung sind erforderlich, um den dynamischen Bereich eines Bildes zu reduzieren. Bei dieser Reduzierung müssen Spitzlichter oder Schatten nicht abgeschnitten werden, während der lokale Kontrast so weit wie möglich erhalten bleibt.Sie versuchen, die Größe der großen Helligkeitsränder im Bild zu reduzieren, was den globalen Kontrast stärker beeinflusst, während gleichzeitig die Größe der kleinen Leuchtdichtekanten beibehalten wird, also die Details.Obwohl es viele verschiedene Implementierungen gibt, ist ein solcher Vorgang bei den meisten modernen Digitalkameras heute Standard.

• SDR-Weißpunkt

  • Die maximale lineare Leuchtdichte von SDR-Inhalten auf einem Bildschirm zu einem bestimmten Zeitpunkt.

• HDR-Weißpunkt

  • Die maximale lineare Leuchtkraft von HDR-Inhalten auf einem Display zu einem bestimmten Zeitpunkt. Dieser Wert ist in der Regel höher als der SDR-Weißpunkt.

• Verstärkung

  • Der HDR-Weißpunkt geteilt durch den SDR-Weißpunkt.

• Max. Inhalts-Boost (max_content_boost in Gleichungen)

  • Mit diesem Wert kann der Creator einschränken, wie viel heller ein Bild bei der Wiedergabe auf einem HDR-Display relativ zur SDR-Darstellung sein kann.
  • Dieser Wert ist eine Konstante für ein bestimmtes Bild. Bei einem Wert von vier darf die lineare Leuchtdichte der angezeigten HDR-Darstellung für jedes Pixel höchstens viermal so hoch wie die lineare Leuchtdichte der SDR-Darstellung sein. In der Praxis bedeutet dies, dass die hellen Teile der Szene bis zu 4-mal so hell angezeigt werden können.
  • In der Praxis ist dieser Wert in der Regel größer als 1, 0.
  • Ist immer größer oder gleich Mindestinhalts-Boost.

• Min. Content-Boost (min_content_boost in Gleichungen)

  • Mit diesem Wert kann der Creator einschränken, wie viel dunkler ein Bild relativ zur SDR-Darstellung bei der Anzeige auf einem HDR-Display werden kann.Dieser Wert ist eine Konstante für ein bestimmtes Bild.
  • Wenn der Wert beispielsweise 0,5 ist, muss die lineare Leuchtdichte der angezeigten HDR-Darstellung für ein bestimmtes Pixel (mindestens) 0,5-mal so hoch wie die lineare Leuchtdichte der SDR-Darstellung sein.
  • In der Praxis ist dieser Wert normalerweise gleich oder kleiner als 1, 0.
  • Immer kleiner oder gleich Maximale Anzahl von Inhalten.

• Max. Display-Optimierung (max_display_boost in Gleichungen)

  • Die maximal verfügbare Optimierung, die von einer Anzeige zu einem bestimmten Zeitpunkt unterstützt wird. Dieser Wert kann sich im Laufe der Zeit je nach Geräteeinstellungen und anderen Faktoren wie Umgebungslichtbedingungen oder der Anzahl der hellen Pixel auf dem Bildschirm ändern.
  • Wenn dieser Wert beispielsweise 4,0 ist, kann auf der Anzeige ein Pixel angezeigt werden, das höchstens viermal heller als der Weißpunkt des SDR ist. Dieser Wert ist immer ≥ 1,0, da das HDR-Weiß immer mindestens so hell wie SDR-Weiß angezeigt werden kann.

• Display-Optimierung

  • Entspricht dem niedrigeren Wert der maximalen Inhalts- und der maximalen Anzeige-Optimierung. Dieser Wert ist immer ≥ 1,0.
  • Wenn beispielsweise die maximale Inhalts-Boosterzahl 4,0 und die maximale Anzeige-Booster 3,0 ist, dann ist die Display-Optimierung 3,0. Pixel werden bis zu dreimal heller als SDR angezeigt, da die Anzeigefunktionen der begrenzende Faktor sind.
  • Wenn die maximale Inhalts-Optimierung beispielsweise 4,0 und die maximale Anzeige-Optimierung 5,0 beträgt, dann ist die Anzeige-Optimierung 4,0. Pixel werden bis zu 4-mal heller als SDR dargestellt, da die Absicht des Inhalts der begrenzende Faktor ist.

• Ziel-HDR-Wiedergabe

  • Die ideale HDR-Wiedergabe, so der Creator.

• Angepasste HDR-Wiedergabe

  • Die endgültige HDR-Darstellung, die auf dem Display angezeigt wird, nachdem die HDR-Darstellung des Ziels an die aktuelle Display-Optimierung angepasst wurde.

• Gewinnkarte (recovery(x, y) in Gleichungen)

  • Eine Karte, die angibt, wie stark jedes Pixel in der SDR-Darstellung aufgehellt werden soll, um die gewünschte HDR-Wiedergabe zu erzeugen. Diese Zuordnung kann ein- oder mehrere Kanäle sein. Eine Karte mit mehreren Kanälen zeigt einen separaten Verstärkungsgrad für jeden Farbkanal, z. B. Rot, Grün und Blau. In diesem Dokument wird der Fall einer Karte mit einem einzelnen Kanal veranschaulicht.

• clamp(x, a, b)

  • Setzen Sie den Wert x auf den Bereich [a, b].

• exp2(x)

  • Exponentiation zur Basis 2; 2^x.

• floor(x)

  • Gibt die nächste Ganzzahl zurück, die kleiner oder gleich x ist.

• log2(x)

  • Logarithmus zur Basis 2; Log₂(x)

• pow(b, x)

  • Exponentiierung; b^x.

• XMP

  • Erweiterbare Metadatenplattform Ein Standard, der eine Methode zum Codieren von Metadaten in einem Image-Container definiert; definiert durch ISO 16684-1:2011(E) XMP Specification Part 1.

• Mehrfachbildformat

  • Das Multi-Picture-Format wurde von der Camera and Imaging Products Association (CIPA) entwickelt, um mehrere JPEG-codierte Bilder in einer einzigen JPEG-Datei zu speichern.
  • Weitere Informationen finden Sie im Whitepaper von CIPA DC-x 007-2009 Multi-Picture Format (in englischer Sprache).

• GContainer

  • GContainer ist eine Methode zum Speichern mehrerer Images in einem Image-Container, wobei ein Image als primäres Image gilt. Zusätzliche Images gelten als alternative Versionen oder Hilfs-Images. XMP-Metadaten werden verwendet, um das Vorhandensein und die Bedeutung zusätzlicher Bilder zu kommunizieren. Weitere Informationen finden Sie im Abschnitt GContainer-Details.

Codieren

In diesem Abschnitt wird beschrieben, wie eine konforme JPEG-Datei codiert wird. Weitere Informationen zum JPEG-Format finden Sie unter T.81 (09/92) Digitale Komprimierung und Codierung von Standbildern mit kontinuierlichem Ton im Abschnitt „Abhängigkeiten“.

Kartenerstellung steigern

Bildverarbeitungspipelines für Kameras führen in der Regel eine Bereichskomprimierung durch, um Leuchtdichtedaten mit höherem dynamischen Bereich in einem niedrigeren Bereich von herkömmlichen SDR-Bildschirmen zu komprimieren. Die Verstärkungskarte bietet einen Mechanismus zum Speichern von Daten, die ausreichen, um die ursprünglichen Leuchtdichtedaten mit höherem dynamischen Bereich wiederherzustellen.

Bei den folgenden Berechnungen in diesem Abschnitt wird von einer Gleitkommaarithmetik ausgegangen.

Die folgenden Funktionen beschreiben das SDR-Image:

• SDR'(x, y) ist ein nicht lineares (in der Regel Gamma-codiertes) primäres Bild mit drei Kanälen.
• SDR(x, y) ist die lineare Version des dreikanaligen Hauptbilds, das durch Umwandlung in eine lineare Version des Farbraums des primären Bilds ermittelt wird. Zum Beispiel von einem Farbraum mit einer sRGB-Übertragungsfunktion zu einem linearen Farbraum, der Grundfarben im sRGB-Format beibehält.

Die Funktion Ysdr(x, y) ist für einen Bereich von 0,0 bis 1,0 definiert und ist die standardmäßige lineare Leuchtdichte des primären Bilds mit einem dynamischen Bereich:

Ysdr(x, y) = primary_color_profile_to_luminance(SDR(x, y))

Für das HDR-Bild gibt es ähnliche Definitionen.

• HDR'(x, y) ist ein nicht lineares Drei-Kanal-Bild, d. h. ein PQ- oder HLG-codiertes Bild.
• HDR(x, y) ist das lineare HDR-Bild mit drei Kanälen.

Yhdr(x, y) ist die Leuchtdichte an einem bestimmten Punkt des HDR-Bilds:

Yhdr(x, y) = primary_color_profile_to_luminance(HDR(x, y))

Yhdr(x, y) ist im Bereich von 0,0 bis zur maximalen Inhaltserhöhung definiert.

Die SDR- und HDR-Bilder müssen dieselbe Auflösung haben. Das Farbprofil des SDR-Bildes definiert den Farbraum des HDR-Bilds.

Wenn das SDR-Hauptbild beispielsweise ein Display-P3-Farbprofil hat, wird das HDR-Bild relativ zu den Primärfarben dieses Profils definiert. Das bedeutet, dass für das HDR-Bild auch Farbräume des Display-P3 verwendet werden können.

Die Verstärkungskarte wird aus zwei linearen Bildern berechnet, die die gewünschte HDR-Bildleuchtdichte Yhdr(x, y) und das Standardleuchtdichtebild Ysdr(x, y) enthalten.

Die Funktion pixel_gain(x, y) ist als Verhältnis zwischen der Funktion Yhdr(x, y) und der Funktion Ysdr(x, y) definiert:

pixel_gain(x, y) = (Yhdr(x, y) + offset_hdr) / (Ysdr(x, y) + offset_sdr)

Das Verhalten der Funktion pixel_gain(x, y), bei dem Ysdr(x, y) und offset_sdr null sind, ist implementierungsdefiniert.

Implementierungen können beispielsweise den Fall bewältigen, dass Ysdr(x, y) und offset_sdr beide null sind, indem pixel_gain(x, y) als 1.0 definiert wird. Alternativ können Implementierungen dieses Szenario auch vermeiden, indem eine offset_sdr ungleich null verwendet wird.

Bei der Implementierung werden möglicherweise die Werte offset_sdr und offset_hdr ausgewählt.

Die Verstärkungszuordnung ist eine Skalarfunktion, die pixel_gain(x, y) in einem logarithmischen Bereich codiert, bezogen auf die maximale und die minimale Inhaltserhöhung:

map_min_log2 = log2(min_content_boost)
map_max_log2 = log2(max_content_boost)

log_recovery(x, y) = (log2(pixel_gain(x, y)) - map_min_log2)
                   / (map_max_log2 - map_min_log2)
clamped_recovery(x, y) = clamp(log_recovery(x, y), 0.0, 1.0)
recovery(x, y) = pow(clamped_recovery(x, y), map_gamma)

Die Implementierung der Funktion recovery(x, y), bei der pixel_gain(x, y) den Wert null hat, ist definiert, da log2(0) nicht definiert ist.

map_gamma ist eine Gleitkommazahl, die größer als 0,0 sein muss und von der Implementierung ausgewählt wird.

Die Werte für die maximale und minimale Inhalts-Booster werden durch die Implementierung definiert und können vom Creator willkürlich festgelegt werden. Maximale Inhaltsoptimierung muss größer oder gleich 1,0 sein. Die Mindestinhaltsverstärkung muss im Bereich (0.0, 1.0] liegen.

Werte in recovery(x, y) sind auf den Bereich [0,0, 1,0] begrenzt.

Die Gain Map wird in einer sekundären JPEG-Bilddatei gespeichert und muss daher mit 8-Bit-Ganzzahlwerten ohne Vorzeichen codiert werden, die sich im Bereich [0, 255] befinden. Jeder Wert stellt einen recovery(x, y)-Wert dar und wird in einem Pixel des sekundären Bilds gespeichert.

Bei einem vorzeichenlosen 8-Bit-Ganzzahlspeicher wird der codierte Wert so definiert:

encoded_recovery(x, y) = floor(recovery(x, y) * 255.0 + 0.5)

Die Berechnung der Codierungsfunktion erfolgt in Gleitkomma und wird am Ende durch Rundung wie angegeben in das vorzeichenlose 8-Bit-Ganzzahlergebnis konvertiert.

Diese Codierung führt zu einer vorzeichenlosen 8-Bit-Ganzzahldarstellung von recovery(x, y)-Werten im Bereich von 0,0 bis 1,0. Die codierte Verstärkungskarte muss in einem sekundären Bildelement als JPEG gespeichert werden. Die Implementierung wählt das Maß an Komprimierung, das bei der JPEG-Codierung verwendet werden soll.

Nachdem die Gain Map in einem sekundären Image gespeichert wurde, wird sie an ein primäres Image mit MPF- und GContainer XMP-Metadaten angehängt. Das GContainer-Verzeichnis des primären Images muss ein Element für das GainMap-Bild enthalten.

Die Auflösung der gespeicherten Verstärkungskarte ist implementierungsdefiniert und kann von der Auflösung des Hauptbilds abweichen. Falls die GainMap zum Speichern auf eine andere Auflösung als das primäre Bild skaliert wird, muss die Stichprobenmethode bilinear oder besser sein und eine Implementierung definiert.

Die Ausrichtung der Verstärkungskarte muss der des Hauptbilds entsprechen. Falls vorhanden, werden die Metadaten der Ausrichtung im gespeicherten GainMap-Bild, z. B. in EXIF, nicht verwendet.

Falls vorhanden, wird das Farbprofil der Verstärkungskarte nicht verwendet.

Kartencontainer erhalten

Farbprofil

Das Farbprofil des Bilds muss über ein ICC-Profil für das primäre Bild angegeben werden.

XMP-Attribute

Das Hauptbild enthält XMP-Metadaten, mit denen mindestens zwei Bilder mit zusätzlichen semantischen Informationen für das HDR-Gewinnkartenformat definiert werden.

Die folgenden Unterabschnitte enthalten Details speziell für dieses Format. Weitere Informationen zur allgemeinen Konformität mit GContainer finden Sie im Abschnitt GContainer-Details.

In den folgenden Tabellen beschriebene Attributwerte werden als einfache XMP-Werte der angegebenen grundlegenden XMP-Werttypen gespeichert.

Semantische Werte für Elemente

Das Attribut Item:Semantic definiert die anwendungsspezifische Bedeutung der einzelnen Medienelemente im Containerverzeichnis.

Kartenmetadaten: HDR Gain

Mit GainMap-Metadaten werden Informationen zum Interpretieren und Anwenden der Verstärkungskarte codiert, um die HDR-Darstellung des Hauptbilds zu erstellen.

Der XMP-Namespace-URI für die XMP-Erweiterung der GainMap-Metadaten lautet http://ns.adobe.com/hdr-gain-map/1.0/. Das Standard-Namespace-Präfix ist hdrgm.

Diese Metadaten werden im XMP-Paket des GainMap-Bildes gespeichert und die folgenden Attribute müssen in der rdf:Description des GainMap-Bildes enthalten sein:

Beispiel für XMP-Gewinnkarte

Das folgende Beispiel für ein gültiges XMP-Paket für Verstärkungskarten enthält Metadaten aus der im Abschnitt Einführung dargestellten Beispieldatei.

<x:xmpmeta xmlns:x="adobe:ns:meta/" x:xmptk="XMP Core 5.5.0">
  <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
    <rdf:Description rdf:about=""
     xmlns:hdrgm="http://ns.adobe.com/hdr-gain-map/1.0/"
     hdrgm:Version="1.0"
     hdrgm:GainMapMin="-0.57609993"
     hdrgm:GainMapMax="4.7090998"
     hdrgm:Gamma="1"
     hdrgm:OffsetSDR="0.015625"
     hdrgm:OffsetHDR="0.015625"
     hdrgm:HDRCapacityMin="0"
     hdrgm:HDRCapacityMax="4.7090998"
     hdrgm:BaseRenditionIsHDR="False"/>
  </rdf:RDF>
</x:xmpmeta>

MPF-Speicherung der Gain Map

Das GainMap-Bild muss als zusätzliches Bild gemäß der Definition in CIPA DC-x 007-2009 Multi-Picture Format gespeichert werden, auf die im Abschnitt Abhängigkeiten verwiesen wird.

Decodieren

In diesem Abschnitt wird beschrieben, wie die GainMap aus einer konformen JPEG-Datei decodiert wird.

Signal des Formats

Eine JPEG-Datei in diesem Format wird möglicherweise durch hdrgm:Version="1.0" im XMP-Paket des primären Images identifiziert, wobei hdrgm der Namespace-URI http://ns.adobe.com/hdr-gain-map/1.0/ ist.

Bild zur Gewinnkarte suchen

Details zum Parsen und Decodieren des Images finden Sie im folgenden Abschnitt GContainer-Details. Das semantische „GainMap“-Element im rdf:Directory des XMP wird verwendet, um den Standort eines GainMap-Bildes zu signalisieren. Alternativ werden der MPF-Index IFD und XMP von Scanbildern verwendet, um den Standort einer Verstärkungskarte zu bestimmen.

Mit ungültigen Metadaten umgehen

Metadaten gelten als ungültig, wenn ein Pflichtfeld nicht oder ein Feld mit einem ungültigen Wert vorhanden ist. Ein Wert ist möglicherweise ungültig, weil er nicht mit dem angegebenen Typ geparst werden kann oder außerhalb des erwarteten Bereichs liegt.

Wenn ungültige Metadaten festgestellt werden, sollte die Gain Map ignoriert und das SDR-Image angezeigt werden.

Display

Dateien, die im HDR GainMap-Format codiert sind, können entweder auf konventionellen SDR-Displays oder auf HDR-Displays gerendert werden, die eine höhere Leuchtdichte liefern.

Mit der Verstärkungskarte die angepasste HDR-Wiedergabe erstellen

Bei den folgenden Berechnungen in diesem Abschnitt wird von einer Gleitkommaarithmetik ausgegangen.

encoded_recovery(x, y) ist die vorzeichenlose 8-Bit-Ganzzahl mit einem einzelnen Kanal aus dem GainMap-Bild.

Wenn die Verstärkungskarte eine andere Auflösung als das Hauptbild hat, wird encoded_recovery(x, y) stattdessen durch eine gefilterte Stichprobe des Verstärkungskartenbilds für x und y im Bereich der Breite bzw. Höhe des primären Bilds bestimmt. Die Filtermethode muss bilinear oder besser sein und ist Implementierung definiert.

map_gamma wird durch das Metadatenfeld hdrgm:Gamma bestimmt.

log_recovery(x, y) ist der normalisierte Gleitkomma-Pixelgewinn in einem logarithmischen Raum:

recovery(x, y) = encoded_recovery(x, y) / 255.0
log_recovery(x, y) = pow(recovery(x, y), 1.0 / map_gamma)

Die maximale Display-Optimierung ist ein skalarer Gleitkommawert, der als Verhältnis zwischen dem aktuellen HDR-Weißpunkt und dem aktuellen SDR-Weißpunkt dividiert ist. Dieser Wert wird vom Anzeigesystem bereitgestellt und kann sich im Laufe der Zeit ändern.

hdr_capacity_max wird durch das Metadatenfeld hdrgm:HDRCapacityMax bestimmt. hdr_capacity_min wird durch das Metadatenfeld hdrgm:HDRCapacityMin bestimmt.

weight_factor wird so bestimmt, wenn hdrgm:BaseRenditionIsHDR „False“ ist:

unclamped_weight_factor = (log2(max_display_boost) - hdr_capacity_min)
                        / (hdr_capacity_max - hdr_capacity_min)
weight_factor = clamp(unclamped_weight_factor, 0.0, 1.0)

Wenn hdrgm:BaseRenditionIsHDR „Wahr“ ist, lautet stattdessen die zweite Gleichung:

weight_factor = 1.0 - clamp(unclamped_weight_factor, 0.0, 1.0)

gain_map_max wird durch das Metadatenfeld hdrgm:GainMapMax bestimmt. gain_map_min wird durch das Metadatenfeld hdrgm:GainMapMin bestimmt. offset_sdr wird durch das Metadatenfeld hdrgm:OffsetSDR bestimmt. offset_hdr wird durch das Metadatenfeld hdrgm:OffsetHDR bestimmt.

Die linear angepasste HDR-Wiedergabe kann so berechnet werden:

log_boost(x, y) = gain_map_min * (1.0f - log_recovery(x, y))
                + gain_map_max * log_recovery(x, y)
HDR(x, y) = (SDR(x, y) + offset_sdr) * exp2(log_boost(x, y) * weight_factor)
          - offset_hdr

Bei Bedarf kann die Implementierung eine Transformation auf HDR(x, y) anwenden, um die Daten in den von der Anzeige erwarteten Bereich zu verschieben. Diese Transformationen müssen kolimetrisch korrekt sein.

GContainer-Details

In diesem Abschnitt werden zusätzliche Anforderungen beschrieben, damit dieses Format den GContainer-XML-Metadaten entspricht. Die Metadaten werden gemäß ISO 166841:2011(E) XMP Specification Part 1 seriell und in die primäre Bilddatei eingebettet, wie unter Adobe XMP Specification Part 3 Speicher in Dateien beschrieben. Die primäre Bilddatei enthält die folgenden Elemente im RDF/XML-Format.

Anforderungen an XMP-Pakete

Das XMP-Paket muss die XMP-Erweiterung der GainMap-Metadaten über den Namespace-URI http://ns.adobe.com/hdr-gain-map/1.0/ enthalten. Das Standard-Namespace-Präfix ist hdrgm.

Das XMP-Paket definiert hdrgm:Version="1.0".

Container element

Der XMP-Namespace für die GContainer-XMP-Erweiterung ist http://ns.google.com/photos/1.0/container/. Das Standard-Namespace-Präfix ist Container.

Das primäre Image enthält ein Container:Directory-Element in XMP-Metadaten, das die Reihenfolge und Attribute der nachfolgenden Mediendatei im Dateicontainer festlegt. Jede Datei im Container hat ein entsprechendes Medienelement im Container:Directory. Das Medienelement beschreibt den Speicherort im Dateicontainer und die grundlegenden Eigenschaften jeder verketteten Datei.

Das Containerelement wird in die XMP-Metadaten des primären Bildes codiert und definiert ein Verzeichnis mit Medienelementen im Container. Die Medienelemente müssen sich in der Containerdatei in derselben Reihenfolge wie die Medienelemente im Verzeichnis befinden und dicht beieinander befinden.

Das Verzeichnis darf nur ein „primäres“ Bildelement enthalten und muss das erste Element im Verzeichnis sein.

Elementelement

Elementelemente beschreiben, wie die einzelnen Medienelemente von der App verwendet werden.

Der XMP-Namespace-URI für die XMP-Erweiterung des GContainer-Elements lautet http://ns.google.com/photos/1.0/container/item/. Das Standard-Namespace-Präfix ist Item.

Das erste Medienelement muss das Hauptbild sein.Er muss Item:Semantic = "Primary" und Item:Mime angeben, die unter Werte für den MIME-Typ für Elemente aufgeführt sind.

Die Länge des primären Image-Elements wird bestimmt, indem das primäre Image basierend auf seinem MIME-Typ geparst wird, beginnend am Anfang des Dateicontainers.

Medienelemente können ein Item:Padding-Attribut enthalten, mit dem zusätzliche Abstände zwischen dem Ende des Medienelements und dem Anfang des nächsten Medienelements festgelegt werden. Wenn Item:Padding im letzten Medienelement im Container:Directory vorhanden ist, gibt es den Abstand zwischen dem Ende des Elements und dem Ende der Datei an.

Jedes Medienelement muss den Typ Item:Mime und Item:Semantic-Attribute enthalten. Die sekundären Bildmedienelemente müssen Item:Length-Attribute enthalten.

Sequenzielle Medienelemente können Ressourcendaten innerhalb des Dateicontainers freigeben. Das erste Medienelement bestimmt den Speicherort der Ressource im Dateicontainer. Für nachfolgende freigegebene Medienelemente wird Item:Length auf 0 gesetzt. Falls die Ressourcendaten selbst ein Container sind, kann mit Item:URI der Speicherort der Medienelementdaten innerhalb der Ressource ermittelt werden.

Der Standort der Medienelementressourcen im Container wird durch Addition der Länge der primären Bildcodierung, der Item:Length-Werte der vorherigen sekundären Medienelementressourcen und aller vorhergehenden Item:Padding-Werte bestimmt. Für Ressourcen von Medienelementen, für die kein Wert angegeben ist, wird Item:Padding als 0 betrachtet.

MIME-Typ-Werte des Elements

Das Attribut Item:Mime definiert den MIME-Typ der einzelnen Medienelementdaten.

GContainer-XMP-Beispiel

Das folgende Beispiel für ein gültiges GContainer-XMP-Paket enthält Metadaten aus der Beispieldatei, die im Abschnitt Einführung veranschaulicht wird.

<x:xmpmeta xmlns:x="adobe:ns:meta/" x:xmptk="Adobe XMP Core 5.1.2">
  <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
    <rdf:Description
     xmlns:Container="http://ns.google.com/photos/1.0/container/"
     xmlns:Item="http://ns.google.com/photos/1.0/container/item/"
     xmlns:hdrgm="http://ns.adobe.com/hdr-gain-map/1.0/"
     hdrgm:Version="1.0">
      <Container:Directory>
        <rdf:Seq>
          <rdf:li rdf:parseType="Resource">
            <Container:Item
             Item:Semantic="Primary"
             Item:Mime="image/jpeg"/>
          </rdf:li>
          <rdf:li rdf:parseType="Resource">
            <Container:Item
             Item:Semantic="GainMap"
             Item:Mime="image/jpeg"
             Item:Length="66171"/>
          </rdf:li>
        </rdf:Seq>
      </Container:Directory>
    </rdf:Description>
  </rdf:RDF>
</x:xmpmeta>