Ultra HDR-Bildformat v1.1

Einführung

In diesem Dokument wird das Verhalten eines neuen Dateiformats definiert, das ein Bild mit einer logarithmischen Bereichsverstärkungskarte in einer JPEG-Bilddatei codiert. Alte Lesegeräte, die das neue Format nicht unterstützen, lesen und zeigen das herkömmliche Bild mit niedrigem Dynamikbereich aus der Bilddatei an. Lesegeräte, die das Format unterstützen, kombinieren das primäre Bild mit der Verstärkungskarte und rendern ein Bild mit hohem Dynamikbereich auf kompatiblen Displays.

Im weiteren Verlauf dieses Dokuments werden die Methoden der Prozesse beschrieben, die für die Verwendung dieses Formats erforderlich sind. Der Lebenszyklus eines Bildes, das diesem Format entspricht, sieht in etwa so aus:

1. Codierung

   1. Kartenerstellung nutzen
   2. Kartenkomprimierung nutzen
   3. Kartencontainer-Generierung

2. Decodierung

Abbildung 1. Beispiel für ein Dateilayout 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 optimale HDR-Wiedergaben in einer einzigen Datei zu erzeugen.

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

• Sie müssen abwärtskompatibel sein, damit auf nicht HDR-fähigen Geräten das herkömmliche SDR-Bild angezeigt wird.
• Es sollte nicht zu viel zusätzlichen Speicherplatz in Anspruch nehmen.

Außerdem muss die Anzeigetechnik:

• Sie erfordern keine aufwendige Dekodierung.
• Sie muss sich an jedes Verhältnis zwischen den HDR- und SDR-Weißpunkten eines Displays anpassen können, das je nach Gerät oder sogar zeitlich auf einem einzelnen Gerät stark variieren kann.

Und schließlich muss die Methode alle oben genannten Aktionen ausführen können, ohne dass Folgendes passiert:

• Highlights werden abgeschnitten.
• Schatten, die zu stark sind
• Ändern oder Komprimieren des lokalen Kontrasts
• Die relativen Tonverhältnisse (zwischen Objekten in der Szene) ändern.

Abhängigkeiten

Im Folgenden finden Sie normative Referenzen für diese Spezifikation:

• Adobe XMP Specification Part 3: Storage in Files
• ISO 16684-1:2019 XMP-Spezifikation Teil 1
• ISO/IEC 14496-12 ISO Base Media File Format
• T.81 (09/92): Digitale Komprimierung und Codierung von Standbildern mit ununterbrochenem Farbton
• Whitepaper zum Multi-Picture-Format CIPA DC-x 007-2009

Definitionen

• SDR-Display

  • 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 entwickelt wurde. Diese Displays haben in der Regel eine höhere nominelle Spitzenhelligkeit als SDR-Displays, in der Regel mindestens 800 cd/m², und in der Regel auch ein besseres Kontrastverhältnis als SDR-Displays.

• Primäres Bild

  • Die erste Instanz eines Images in einer GContainer-Datei, an die sekundäre Mediendateien angehängt sind. Das primäre Bild enthält GContainer-XMP-Metadaten, die die Reihenfolge und Eigenschaften nachfolgender Dateien mit sekundären Medienelementen im Dateicontainer definieren.

• Sekundäres Bild

  • Nachfolgende Dateien mit Medienelementen, die dem primären Bild in einer GContainer-Datei angefügt werden.

• Bereichskomprimierung

  • Bei der Fotografie haben reale Szenen oft einen größeren Dynamikbereich als ein SDR-Display darstellen kann. Vorgänge wie die Bereichskomprimierung, auch lokales Tonmapping genannt, sind erforderlich, um den Dynamikbereich eines Bildes zu reduzieren. Dabei dürfen keine Highlights abgeschnitten oder Schatten zu stark komprimiert werden. Der lokale Kontrast sollte möglichst erhalten bleiben. Sie versuchen, die Größe großer Helligkeitsränder im Bild zu reduzieren, die mehr zum globalen Kontrast beitragen, und gleichzeitig die Größe der kleinen Helligkeitsränder, also der Details, beizubehalten. Obwohl es viele verschiedene Implementierungen gibt, ist diese Funktion bei den meisten modernen Digitalkameras heute Standard.

• SDR-Weißpunkt

  • Die maximale lineare Leuchtkraft von SDR-Inhalten auf einem Display 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.

• Maximaler Inhalts-Boost (max_content_boost in Gleichungen)

  • Mit diesem Wert können Creator einschränken, wie viel heller ein Bild auf einem HDR-Display im Vergleich zur SDR-Darstellung sein kann.
  • Dieser Wert ist für ein bestimmtes Bild konstant. Wenn der Wert beispielsweise vier ist, darf die lineare Leuchtkraft der angezeigten HDR-Darstellung für jedes Pixel höchstens das Vierfache der linearen Leuchtkraft der SDR-Darstellung betragen. In der Praxis bedeutet das, dass die helleren Teile bis zu 4-mal heller angezeigt werden können.
  • In der Praxis ist dieser Wert in der Regel größer als 1,0.
  • Muss immer größer oder gleich Mindestwert für die Inhaltsoptimierung sein.

• Mindestwert für die Steigerung der Anzahl von Inhalten (min_content_boost in den Gleichungen)

  • Mit diesem Wert können Creator festlegen, wie viel dunkler ein Bild auf einem HDR-Display im Vergleich zur SDR-Darstellung werden kann. Dieser Wert ist für ein bestimmtes Bild konstant.
  • Wenn der Wert beispielsweise 0,5 ist, muss die lineare Leuchtkraft der angezeigten HDR-Darstellung für jedes Pixel mindestens 0,5-mal so hoch sein wie die lineare Leuchtkraft der SDR-Darstellung.
  • In der Praxis ist dieser Wert normalerweise gleich oder kleiner als 1, 0.
  • Muss immer kleiner oder gleich dem maximalen Inhalts-Boost sein.

• Maximaler Display-Boost (max_display_boost in Gleichungen)

  • Der maximale Boost, der von einem Display zu einem bestimmten Zeitpunkt unterstützt wird. Dieser Wert kann sich im Laufe der Zeit je nach Geräteeinstellungen und anderen Faktoren wie den Lichtverhältnissen der Umgebung oder der Anzahl der hellen Pixel auf dem Display ändern.
  • Wenn dieser Wert beispielsweise 4,0 beträgt, kann das Display ein Pixel anzeigen, das höchstens viermal heller als der SDR-Weißpunkt ist. Dieser Wert ist immer größer als 1,0, da das Display immer HDR-Weiß anzeigen kann, das mindestens so hell ist wie SDR-Weiß.

• Display-Optimierung

  • Entspricht dem jeweils niedrigeren Wert von „Maximale Steigerung der Sichtbarkeit von Inhalten“ und „Maximale Steigerung der Sichtbarkeit von Anzeigen“. Dieser Wert ist immer >= 1,0.
  • Wenn die maximale Inhaltsoptimierung beispielsweise 4,0 und die maximale Display-Optimierung 3,0 ist, beträgt die Display-Optimierung 3,0. Die Pixel werden bis zu dreimal heller dargestellt als bei SDR, da die Displayfunktionen die begrenzende Größe sind.
  • Ein weiteres Beispiel: Wenn die maximale Inhaltsoptimierung 4,0 und die maximale Display-Optimierung 5,0 ist, beträgt die Display-Optimierung 4,0. Pixel werden bis zu viermal heller als SDR angezeigt, da die Absicht des Inhalts der begrenzende Faktor ist.

• Ziel-HDR-Darstellung

  • Die ideale HDR-Wiedergabe, meint der Creator.

• Angepasste HDR-Darstellung

  • Die finale HDR-Darstellung, die auf dem Display angezeigt wird, nachdem die Ziel-HDR-Darstellung an die aktuelle Display-Steigerung angepasst wurde.

• Verstärkungskarte (recovery(x, y) in Gleichungen)

  • Eine Zuordnung, die angibt, um wie viel jedes Pixel in der SDR-Darstellung aufgehellt werden soll, um die Ziel-HDR-Darstellung zu erzeugen. Diese Karte kann eine oder mehrere Kanäle umfassen. Eine mehrkanalige Karte gibt einen separaten Gewinn für jeden Farbkanal an, z. B. Rot, Grün und Blau. In diesem Dokument wird der Fall einer einkanaligen Karte veranschaulicht.

• clamp(x, a, b)

  • Der Wert x wird auf den Bereich [a, b] begrenzt.

• exp2(x)

  • Exponentiation mit 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)

  • Exponentiation; b^x.

• XMP

  • Extensible Metadata Platform Ein Standard, der eine Methode zum Codieren von Metadaten in einem Bildcontainer definiert; definiert in der ISO 16684-1:2011(E) XMP-Spezifikation Teil 1.

• Mehrfachbildformat

  • Das Multi-Picture-Format ist eine von der Camera and Imaging Products Association (CIPA) entwickelte Technik zum Speichern mehrerer JPEG-codierter Bilder in einer einzigen JPEG-Datei.
  • Weitere Informationen finden Sie im zugehörigen Whitepaper CIPA DC-x 007-2009 Multi-Picture Format.

• GContainer

  • GContainer ist eine Methode zum Speichern mehrerer Bilder in einem Bildcontainer, wobei ein Bild als Hauptbild gilt. Alle zusätzlichen Bilder gelten als alternative Versionen oder Hilfsbilder. XMP-Metadaten werden verwendet, um die Anwesenheit und Bedeutung zusätzlicher Bilder zu kommunizieren. Weitere Informationen finden Sie im Abschnitt GContainer-Details.

Codieren

In diesem Abschnitt wird beschrieben, wie Sie eine konforme JPEG-Datei codieren. Weitere Informationen zum JPEG-Format finden Sie im Abschnitt „Abhängigkeiten“ unter T.81 (09/92) Digital compression and coding of continuous-tone still images.

Kartengenerierung

Kamera-Bildverarbeitungspipelines führen häufig eine Bereichskomprimierung durch, um Leuchtdichtedaten mit höherem Dynamikumfang auf den niedrigeren Bereich herkömmlicher SDR-Displays zu komprimieren. Die Verstärkungskarte bietet einen Mechanismus zum Speichern von Daten, die ausreichen, um die ursprünglichen, höhen Dynamikbereichs-Leuchtdichtedaten wiederherzustellen.

Bei den folgenden Berechnungen in diesem Abschnitt wird eine Gleitkommaarithmetik vorausgesetzt.

Hinweis: In diesem Dokument wird zur Veranschaulichung der folgenden Formeln davon ausgegangen, dass Sie eine einzelne Kanalgewinnkarte verwenden.Wenn dies nicht der Fall ist, können Formeln, die sich auf diese Eigenschaften beziehen, auf jeden Farbkanal extrapoliert werden. Sie überspringen die Umwandlung von SDR(x, y) und HDR(x, y) in Ysdr(x, y) und Yhdr(x, y) und definieren stattdessen pixel_gain(x, y) als Vektorfunktion relativ zu SDR(x, y) und HDR(x, y). Sie verwenden auch Metadatenwerte pro Kanal, sofern erforderlich. Verwenden Sie nach Möglichkeit eine Karte mit einem einzelnen Kanalgewinn.

Die folgenden Funktionen beschreiben das SDR-Bild:

• SDR'(x, y) ist das dreikanalige, nicht lineare (in der Regel gammacodierte) Primärbild.
• SDR(x, y) ist die lineare Version des dreikanaligen Primärbilds, die durch eine Transformation in eine lineare Version des Farbraums des Primärbilds erhalten wird. Beispielsweise von einem Farbraum mit einer sRGB-Übertragungsfunktion in einen linearen Farbraum, der die sRGB-Primärfarben beibehält.

Die Funktion Ysdr(x, y) ist für den Bereich von 0,0 bis 1,0 definiert und entspricht der linearen Luminanz des primären Bilds mit Standarddynamikbereich:

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

Für das HDR-Bild gelten ähnliche Definitionen.

• HDR'(x, y) ist das dreikanalige, nicht lineare, 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 Leuchtkraft 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 Inhaltsoptimierung definiert.

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

Wenn das primäre SDR-Bild beispielsweise ein Display-P3-Farbprofil hat, wird das HDR-Bild relativ zu den Primärfarben dieses Profils definiert. Das bedeutet, dass das HDR-Bild auch über Display-P3-Primärfarben verfügt.

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

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

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

Das Verhalten der Funktion pixel_gain(x, y), wenn Ysdr(x, y) und offset_sdr beide null sind, ist implementierungsabhängig.

Implementierungen können beispielsweise den Fall behandeln, dass Ysdr(x, y) und offset_sdr beide null sind, indem pixel_gain(x, y) als 1,0 definiert wird. Alternativ kann dieses Szenario auch durch die Verwendung eines nicht nullwertigen offset_sdr vermieden werden.

Die Implementierung kann die Werte offset_sdr und offset_hdr auswählen.

Tipp: Verwenden Sie für offset_sdr und offset_hdr den Wert 0,015625 (1/64). Mit diesen Werten soll die Möglichkeit, die Helligkeit in Bereichen mit fast schwarzen Pixeln zu erhöhen, mit der Möglichkeit, kleinere Verstärkungswerte genau zu codieren, in Einklang gebracht werden. Wenn Sie diese Offset-Werte erhöhen, können Sie Schwarztöne besser wiederherstellen und gleichzeitig einen angemessenen Wert für map_max_log2 beibehalten. Wenn Sie die Werte zu hoch ansetzen, kann die Genauigkeit der Karte beeinträchtigt werden.

Die Gewinnkarte ist eine Skalarfunktion, die pixel_gain(x, y) in einem logarithmischen Raum codiert, bezogen auf die maximale und minimale Inhaltsoptimierung:

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)

Das Verhalten der Funktion recovery(x, y), wenn pixel_gain(x, y) = 0 ist, wird durch die Implementierung definiert, da log2(0) nicht definiert ist.

Tipp: Definieren Sie recovery(x, y) als 0,0, wenn pixel_gain(x, y) = 0 ist. Das liegt daran, dass ein Wert von 0,0 dB die größte mögliche Dämpfung darstellt, die in der Verstärkungskarte gespeichert werden kann.

recovery(x, y)

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

Tipp :Verwenden Sie einen map_gamma von 1.0. Sie können einen anderen Wert verwenden, wenn die Zugewinnkarte eine sehr ungleichmäßige Verteilung der log_recovery(x, y)-Werte aufweist. Das kann beispielsweise der Fall sein, wenn eine Verstärkungskarte viele Details knapp über dem SDR-Bereich enthält (als kleine log_recovery(x, y)-Werte dargestellt) und einen sehr großen map_max_log2 für den oberen Bereich der gewünschten Helligkeit der HDR-Darstellung (als große log_recovery(x, y)-Werte dargestellt). In diesem Fall kannst du einen map_gamma-Wert größer als 1,0 verwenden, sodass recovery(x, y) das Detail sowohl am unteren als auch am oberen Ende von log_recovery(x, y) genau codieren kann.

Die Werte für die maximale und minimale Inhaltsoptimierung sind implementierungsabhängig und können vom Creator frei festgelegt werden. Der maximale Inhalts-Boost muss mindestens 1,0 betragen. Der Wert für die Mindestinhaltsoptimierung muss im Bereich [0,0, 1,0] liegen.

Hinweis: Angenommen, das Bild stammt von einer Kamera und die Bildverarbeitungspipeline der Kamera generiert das SDR-Bild, indem sie eine Bereichskomprimierung auf einen Eingang mit höherem Dynamikumfang durchführt. Dann hängen die maximale und die minimale Inhaltsverstärkung möglicherweise von der durchgeführten Bereichskomprimierung und den betroffenen Luminanzbereichen ab.

Solche Pipelines wählen für den Mindestwert des Inhalts-Boosts 1,0 aus, wenn keine Dämpfung des HDR-Bildes im Verhältnis zum SDR-Bild codiert werden soll. Wenn die Gewinnkarte anhand der SDR- und HDR-Darstellungen selbst generiert wird, können die maximale und minimale Inhaltsverstärkung anhand der maximalen und minimalen Verstärkung bestimmt werden, die für die Umwandlung zwischen den beiden Darstellungen erforderlich ist.

Creator oder Editoren können auch die maximale Inhaltsoptimierung anpassen, um den maximal zulässigen Unterschied zwischen SDR- und HDR-Leuchtkraft bei der Bildanzeige zu steuern.

Die Werte in recovery(x, y) sind auf den Bereich [0,0, 1,0] beschränkt.

Hinweis :Die hellsten Bereiche des Bildes haben normalerweise recovery(x, y)-Werte nahe 1,0, während die dunkleren Bereiche einen Wert um 0,0 haben.

Die Verstärkungskarte wird in einem sekundären JPEG-Bild gespeichert und muss daher mit 8‑Bit-unsignierten Ganzzahlwerten im Bereich [0, 255] codiert werden. Jeder Wert stellt einen recovery(x, y)-Wert dar und wird in einem Pixel des sekundären Bildes gespeichert.

Für den Speicher von 8‑Bit-Vorzeichenlosen Ganzzahlen wird der codierte Wert so definiert:

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

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

Diese Codierung führt zu einer 8-Bit-Darstellung von recovery(x, y)-Werten mit vorzeichenlosen Ganzzahlen von 0,0 bis 1,0. Die codierte Verstärkungskarte muss in einem sekundären Bildelement als JPEG gespeichert werden. Die Implementierung wählt die Komprimierungsrate aus, die bei der JPEG-Codierung verwendet werden soll.

Tipp: Beginnen Sie mit einem implementierungsdefinierten JPEG-Algorithmusqualitätsparameter von 85 bis 90 von 100 oder ähnlich für die meisten JPEG-Codierungsimplementierungen.

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

Die Auflösung der gespeicherten Verstärkungskarte wird implementierungsdefiniert und kann von der Auflösung des primären Bilds abweichen. Wenn die Gain Map für die Speicherung auf eine andere Auflösung als das primäre Bild skaliert wird, muss die Abtastmethode bilinear oder besser sein. Sie wird durch die Implementierung definiert.

Tipp :Verkleinern Sie die Gain Map vor dem Speichern auf 1⁄16 der Größe (1⁄4 in jeder Dimension) des primären Bilds, z. B. 480 × 270 für ein 1.920 × 1.080 großes primäres Bild. Die Gewinnkarte muss ein ähnliches Seitenverhältnis wie das primäre Bild haben.

Die Ausrichtung der Verstärkungskarte muss mit der des Hauptbilds übereinstimmen. Falls vorhanden, werden alle Ausrichtungsmetadaten im gespeicherten Bild der Verstärkungskarte, z. B. in EXIF, nicht verwendet.

Falls vorhanden, wird das Farbprofil der Gain-Map nicht verwendet.

Karte mit Containern für Zugriffe

Farbprofil

Das Farbprofil des Bildes muss über ein ICC-Profil für das Hauptbild angegeben werden.

Tipp :Verwenden Sie ein Display-P3-Farbprofil.

XMP-Attribute

Das Hauptbild enthält XMP-Metadaten, um mindestens zwei Bilder mit zusätzlichen semantischen Informationen für das HDR-Verstärkungskartenformat zu definieren.

Die folgenden Unterabschnitte enthalten Details zu diesem Format. Weitere Informationen zur allgemeinen Einhaltung der GContainer-Anforderungen finden Sie im Abschnitt GContainer-Details.

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

Semantische Werte von Elementen

Die Item:Semantic-Eigenschaft definiert die anwendungsspezifische Bedeutung jedes Medienelements im Containerverzeichnis.

Wert	Beschreibung
Primär	Gibt an, dass das Medienelement das primäre Bild im Container ist, das zur Anzeige bereit ist. Das Verzeichnis muss ein Element vom Typ „Primär“ enthalten.
GainMap	Gibt an, dass das Medienelement eine Verstärkungskarte ist. Der Ordner darf höchstens einen „GainMap“-Eintrag enthalten.

Metadaten für HDR-Gewinnkarte

Die Metadaten der Gain-Map enthalten Informationen dazu, wie die Gain-Map interpretiert und angewendet werden soll, um die HDR-Darstellung des Hauptbilds zu erstellen.

Der XMP-Namespace-URI für die XMP-Erweiterung der Gain-Map-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 Verstärkungskartenbildes gespeichert. Die folgenden Eigenschaften müssen im rdf:Description des XMP-Bilds des Verstärkungskartenbildes vorhanden sein:

Name	Eingeben	Beschreibung
hdrgm:Version	Text	Die Version des verwendeten Formats für Gewinnkarten. Diese Version ist „1.0“. Required.
hdrgm:BaseRenditionIsHDR	Boolesch	Gibt den Dynamikbereich des primären Bilds an. „False“ gibt an, dass das primäre Bild ein SDR-Bild ist und die Gewinnkarte damit kombiniert werden kann, um eine HDR-Darstellung zu erzeugen. „True“ gibt an, dass das primäre Bild HDR ist und die Gewinnkarte damit kombiniert werden kann, um die SDR-Darstellung zu erstellen. Muss „Falsch“ sein. Optional. Der Standardwert ist „False“.
hdrgm:VerstärkungMapMin	Reelles oder sortiertes Array von reellen Zahlen	Hier werden die Werte von map_min_log2 gespeichert. Das ist log2 des Mindestwerts für die Inhaltsoptimierung, also das minimal zulässige Verhältnis der linearen Leuchtkraft für die Ziel-HDR-Darstellung im Vergleich zu (geteilt durch) der des SDR-Bilds an einem bestimmten Pixel. Kann eine einzelne reelle Zahl oder ein sortiertes Array von reellen Zahlen sein. Ein geordnetes Array mit Realwerten kann ein Element enthalten, das für alle Kanäle gilt, oder drei Elemente für den roten, grünen und blauen Kanal. Muss kleiner oder gleich hdrgm:GainMapMax sein. Optional; Standardwert ist 0,0.
hdrgm:GainMapMax	Reelles oder sortiertes Array von reellen Zahlen	Hier werden die Werte von map_max_log2 gespeichert. Dies entspricht log2 der maximalen Inhaltsverstärkung. Dies ist das maximal zulässige Verhältnis der linearen Leuchtdichte für die HDR-Zielwiedergabe im Verhältnis zur Helligkeit des SDR-Bildes (geteilt durch) bei einem bestimmten Pixel. Kann eine einzelne reelle Zahl oder ein sortiertes Array von reellen Zahlen sein. Bei einem sortierten Array von Reals kann es ein Element enthalten, das für alle Kanäle gilt, oder drei Elemente für die roten, grünen und blauen Kanäle. Muss größer oder gleich hdrgm:GainMapMin sein. Erforderlich.
hdrgm:Gamma	Reelles oder sortiertes Array von reellen Zahlen	Speichert den Wert bzw. die Werte von map_gamma. Dies ist der Gammawert, der auf die gespeicherten Kartenwerte angewendet werden soll. Kann eine einzelne reelle Zahl oder ein sortiertes Array von reellen Zahlen sein. Ein sortiertes Array von Reals kann ein Element enthalten, das für alle Kanäle gilt, oder drei Elemente für die roten, grünen und blauen Kanäle. Muss größer als 0,0 sein. Optional; Standardwert ist 1.0.
hdrgm:OffsetSDR	Reelles oder geordnetes Array von Real	Hier werden die Werte von offset_sdr gespeichert. Dies ist der Offset, der bei der Generierung und Anwendung der Verstärkungskarte auf die SDR-Pixelwerte angewendet wird. Kann eine einzelne reelle Zahl oder ein sortiertes Array von reellen Zahlen sein. Bei einem sortierten Array von Reals kann es ein Element enthalten, das für alle Kanäle gilt, oder drei Elemente für die roten, grünen und blauen Kanäle. Muss 0,0 oder größer sein. Optional; der Standardwert ist 0,015625 (1/64).
hdrgm:OffsetHDR	Reelles oder sortiertes Array von reellen Zahlen	Hier werden die Werte von offset_hdr gespeichert. Das ist der Offset, der beim Generieren und Anwenden der Verstärkungskarte auf die HDR-Pixelwerte angewendet wird. Kann eine einzelne reelle Zahl oder ein sortiertes Array von reellen Zahlen sein. Ein geordnetes Array von Realwerten kann ein Element enthalten, das für alle Kanäle gilt, oder drei Elemente für den roten, grünen und blauen Kanal. Muss mindestens 0,0 sein. Optional. Der Standardwert ist 0,015625 (1/64).
hdrgm:HDRCapacityMin	Real	Speichert den Wert von hdr_capacity_min. Das entspricht log2 des Mindestwerts für die Display-Optimierung, ab dem die Karte angewendet wird. Dieser Wert wirkt sich auch darauf aus, wie stark die Verstärkungskarte basierend auf der Display-Optimierung angewendet wird. Muss 0,0 oder größer sein. Optional. Der Standardwert ist 0,0.
hdrgm:HDRCapacityMax	Real	Speichert den Wert von hdr_capacity_max. Das sind log2 des maximalen Werts für die Display-Optimierung, für den die Karte vollständig angewendet wird. Dieser Wert wirkt sich auch darauf aus, wie stark die Gewinnkarte basierend auf der Display-Optimierung angewendet wird. Muss größer als hdrgm:HDRCapacityMin sein. Erforderlich.

Tipp :Verwenden Sie nach Möglichkeit für jede vorausgehende Property, die einen Wert oder ein Array von Werten zulässt, nur einen einzigen reellen Wert, einen für jeden Farbkanal. Setzen Sie HDRCapacityMax auf GainMapMax und HDRCapacityMin auf den größeren Wert von GainMapMin oder 0,0. Im Rest dieses Dokuments wird davon ausgegangen, dass Sie für alle Properties einen einzelnen „real“-Wert verwenden, der ein Array von „real“-Werten haben kann. Formeln zu diesen Eigenschaften können auf jeden Farbkanal extrapoliert werden, wenn dies in der Praxis nicht der Fall ist.

Beispiel für Verstärkungskarte (XMP)

Das folgende Beispiel für ein gültiges XMP-Paket für eine Gain-Map enthält Metadaten aus der Beispieldatei, die im Abschnitt Einführung dargestellt wurde.

<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 Verstärkungskarte

Das Bild der Verstärkungskarte muss als zusätzliches Bild gespeichert werden, wie im Abschnitt Abhängigkeiten unter CIPA DC-x 007-2009 Multi-Picture Format beschrieben.

Decodieren

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

Signal des Formats

Eine JPEG-Datei, die diesem Format entspricht, kann anhand der Anwesenheit von hdrgm:Version="1.0" im XMP-Paket des primären Bildes identifiziert werden. Dabei ist hdrgm der URI des Namespace http://ns.adobe.com/hdr-gain-map/1.0/.

Bild der Gewinnkarte aufrufen

Weitere Informationen zum Parsen und Decodieren des Bildes finden Sie im folgenden Abschnitt GContainer-Details. Mit dem semantischen Element „GainMap“ in der XMP-rdf:Directory wird der Speicherort eines Gainmap-Bilds angegeben. Alternativ können Sie den IFD des MPF-Indexes und die XMP-Datei der gescannten Bilder verwenden, um den Speicherort einer Verstärkungskarte zu ermitteln.

Umgang mit ungültigen Metadaten

Metadaten gelten als ungültig, wenn ein Pflichtfeld fehlt oder ein Feld mit einem ungültigen Wert vorhanden ist. Ein Wert kann ungültig sein, weil er nicht in den angegebenen Typ umgewandelt werden kann oder weil er außerhalb des erwarteten Bereichs liegt.

Wenn ungültige Metadaten festgestellt werden, sollte die Verstärkungskarte ignoriert und das SDR-Bild angezeigt werden.

Anzeige

Dateien, die im HDR-Gain-Map-Format codiert sind, können entweder auf herkömmlichen SDR-Displays oder auf HDR-Displays mit höherer Leuchtkraft gerendert werden.

Mit der Gewinnkarte die angepasste HDR-Darstellung erstellen 

Bei den folgenden Berechnungen in diesem Abschnitt wird eine Gleitkommaarithmetik vorausgesetzt.

encoded_recovery(x, y) ist der einkanalige, 8‑Bit-Wert der vorzeichenlosen Ganzzahl aus dem Bild der Verstärkungskarte.

Wenn die Verstärkungskarte eine andere Auflösung als das Hauptbild hat, wird encoded_recovery(x, y) stattdessen durch eine gefilterte Stichprobenerhebung des Verstärkungskartenbilds für x und y im Bereich der Breite und Höhe des Hauptbilds bestimmt. Die Filtermethode muss bilinear oder besser sein und wird von der 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)

„Max. Display-Boost“ ist ein skalarer Gleitkommawert, der als Verhältnis zwischen dem aktuellen HDR-Weißpunkt geteilt durch den aktuellen SDR-Weißpunkt definiert 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.

Wenn hdrgm:BaseRenditionIsHDR „False“ ist, wird weight_factor so ermittelt:

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 „True“ ist, lautet die zweite Gleichung stattdessen:

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 an der für das Display erwarteten Stelle zu platzieren. Alle diese Transformationen müssen kolorimetrisch korrekt sein.

Hinweis: Die Gain-Map muss wie oben gezeigt (mit Exponentiation) angewendet werden, um die erforderlichen relativen Tonbeziehungen (zwischen Bereichen mit unterschiedlicher Helligkeit im Bild) bei jeder gewünschten Displayverstärkung korrekt zu erzeugen.Wenn die Verstärkungszuordnung auf andere Weise angewendet wird, z. B. über eine einfache lineare Interpolation, sind die relativen tonalen Beziehungen im Bild nur bei der maximalen Inhaltsoptimierung korrekt und werden bei anderen Boost-Faktoren beeinträchtigt.

Die beschriebene Methode zum Wiederherstellen der angepassten HDR-Darstellung sorgt dafür, dass die Anzeigeergebnisse nahtlos übergehen, wenn sich die maximale Display-Optimierung ändert. Mit dieser Methode wird immer ein Anzeigeergebnis erzielt, das der Absicht des Erstellers von Inhalten so genau wie möglich entspricht und alle Anforderungen an die Bildqualität erfüllt, die im Abschnitt Motivation aufgeführt sind.

Der Grad der Dämpfung in Fällen, in denen die Mindestwerterhöhung weniger als 1,0 beträgt, wird auch anhand der Beziehung zwischen maximaler Display-Optimierung und maximaler Inhaltsoptimierung skaliert. Wenn beispielsweise die maximale Inhaltsverstärkung 4,0, die minimale Inhaltsverstärkung 0,5 und die maximale Displayverstärkung 2,0 ist, beträgt die maximale Dämpfung des angezeigten Bilds 0,7071 statt 0,5, wenn die maximale Displayverstärkung 4,0 oder höher ist.

GContainer-Details

In diesem Abschnitt werden zusätzliche Anforderungen festgelegt, damit dieses Format den GContainer-XML-Metadaten entspricht. Die Metadaten werden gemäß der ISO 166841:2011(E) XMP-Spezifikation Teil 1 serialisiert und wie in der Adobe XMP-Spezifikation Teil 3: Speichern in Dateien beschrieben in die primäre Bilddatei eingebettet. Die primäre Bilddatei enthält die folgenden Elemente, die als RDF/XML formatiert sind.

Anforderungen an XMP-Pakete

Das XMP-Paket muss die XMP-Erweiterung für die Metadaten der Gain Map über den Namespace-URI http://ns.adobe.com/hdr-gain-map/1.0/ enthalten. Das Standardpräfix für Namespaces ist hdrgm.

Das XMP-Paket muss hdrgm:Version="1.0" definieren.

Container element

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

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

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

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

Elementname	Eingeben	Beschreibung
Container:Verzeichnis	Geordnetes Array von Strukturen	Geordnetes Array von Strukturen, die jeweils eine Container:Item-Struktur enthalten, die das Layout und den Inhalt des Containers definiert.

Elementelement

Mit Element-Elementen wird beschrieben, wie die einzelnen Medienelemente von der Anwendung verwendet werden.

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

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

Die Länge des primären Bildelements wird bestimmt, indem das primäre Bild anhand seines MIME-Typs am Anfang des Dateicontainers geparst wird.

Medienelemente können das Attribut Item:Padding enthalten, mit dem zusätzliches Padding zwischen dem Ende des Medienelements und dem Beginn des nächsten Medienelements angegeben wird. Wenn Item:Padding im letzten Medienelement in Container:Directory vorhanden ist, gibt es ein Padding zwischen dem Ende des Elements und dem Ende der Datei.

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

Sequenzielle Medienelemente können Ressourcendaten innerhalb des Dateicontainers gemeinsam nutzen. Das erste Medienelement bestimmt den Speicherort der Ressource im Dateicontainer. Für nachfolgende freigegebene Medienelemente ist Item:Length auf 0 gesetzt. Wenn die Ressourcendaten selbst ein Container sind, kann Item:URI verwendet werden, um den Speicherort der Daten des Medienelements innerhalb der Ressource zu ermitteln.

Die Position der Medienelementressourcen im Container wird durch Addition der Länge der primären Bildcodierung, der Item:Length-Werte der vorausgehenden sekundären Medienelementressourcen und aller vorausgehenden Item:Padding-Werte bestimmt. Bei Ressourcen für Medienelemente, für die kein Wert angegeben ist, wird Item:Padding als „0“ betrachtet.

Attributname	Eingeben	Beschreibung
Item:Mime	Text	Einfacher String, der den MIME-Typ des Medienelements im Container angibt. Eine Definition finden Sie im Abschnitt mit den MIME-Typ-Werten für Elemente. Required.
Artikel:Semantisch	Text	Einfacher String, der die anwendungsspezifische Bedeutung des Medienelements angibt. Eine Definition finden Sie im Abschnitt zu semantischen Artikelwerten. Required.
Artikellänge	Ganzzahl	Einfacher String mit einer positiven Ganzzahl, die die Länge des Artikels in Byte angibt. „0“ gibt an, dass die Ressource des Medienelements mit dem vorherigen Medienelement geteilt wird. Erforderlich für sekundäre Medienelemente. Optional für das Medienelement des primären Bilds.
Element:Label	Text	Ein von der Implementierung definierter String, mit dem mehrere Elementelemente mit derselben Item:Semantic unterschieden werden. Optional.
Element:Abstand	Ganzzahl	Ein String mit einer positiven Ganzzahl für zusätzlichen Abstand in Byte zwischen dem Ende des Medienelements und dem Anfang des nächsten Medienelements oder dem Ende der Datei, wenn es beim letzten Medienelement im Container:Directory verwendet wird. Wenn kein Wert vorhanden ist, wird ein Wert von 0 angenommen. Optional.
Element:URI	Text	Ein URI-String gemäß Abschnitt 8.11.9 der ISO/IEC 14496-12, der den relativen URI der Mediendaten innerhalb der Medienelementressource enthält. Standardmäßig ist dies die primäre Bildressource. Optional für MIME-Typen des ISO-Basismediadateiformats ISO/IEC 14496-12. Kann nicht anderweitig verwendet werden.

Werte für den MIME-Typ des Artikels

Das Attribut Item:Mime definiert den MIME-Typ der Daten jedes Medienelements.

Wert	Beschreibung
image/jpeg	JPEG-Bild.

Beispiel für GContainer-XMP

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

<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>

Kompatibilität mit ISO 21496-1

ISO 21496-1 bietet einen alternativen Kapselungsmechanismus für die Codierung von Kartenmetadaten in einer Bilddatei. Du kannst sowohl Ultra-HDR-Metadaten als auch ISO 21496-1-Metadaten in einer JPEG-Datei mit einem einzigen Gainmap-Bild codieren.

Abbildung 2. Beispiel für ein Dateilayout mit Ultra-HDR- und ISO 21496-1-Metadaten

Für maximale plattformübergreifende Kompatibilität sollten Android-Implementierungen und -Apps, die eine eigene Codierung oder Dekodierung von JPEG-Dateien mit Gain-Maps implementieren, sowohl die Codierung als auch die Dekodierung für Ultra-HDR v1- und ISO 21496-1-Metadaten unterstützen. Während der Codierung sollten die Implementierung oder App beide Metadatenformate codieren. Wenn bei der Dekodierung beide Arten von Metadaten vorhanden sind, sollten die Metadaten nach ISO 21496-1 verwendet werden.

Hinweis :Android unterstützt ab Android 15 (API-Level 35) die ISO 21496-1-Codierung und die Decodierung in Bitmap für JPEG. Android 15 codiert beim Codieren von Ultra-HDR-JPEG-Dateien aus Bitmap-Objekten sowohl Ultra-HDR-v1-Metadaten als auch ISO 21496-1-Metadaten. Außerdem unterstützt die Bibliothek libultrahdr in AOSP die ISO 21496-1-Codierung, wenn das entsprechende Flag aktiviert ist.

Änderungsprotokoll

Dieser Abschnitt enthält Informationen zu den Änderungen zwischen den Versionen dieser Spezifikation.

Version 1.1

Alle Änderungen in dieser Version der Ultra-HDR-Spezifikation sind rein informativ und beziehen sich auf die Kompatibilität mit ISO 21496-1. Am Dateiformat selbst gibt es keine Änderungen.

• Fügen Sie den Abschnitt ISO 21496-1-Kompatibilität hinzu.

Version 1.0

Die erste Veröffentlichung der Ultra HDR-Spezifikation.