Formato de imagen Ultra HDR v1.0

Introducción

Este documento define el comportamiento de un nuevo formato de archivo que codifica imagen de mapa de ganancia de rango logarítmico en un archivo de imagen JPEG. Los lectores heredados que no admitir el nuevo formato, leer y mostrar el estándar dinámico bajo de rango de imagen a partir del archivo de imagen.Los lectores que admiten el formato se combinan la imagen principal con el mapa de ganancia y renderizar una imagen de alto rango dinámico en pantallas compatibles.

En el resto de este documento, se describen los métodos de los procesos necesarios para usen este formato. En un nivel alto, el ciclo de vida de una imagen que se ajusta a este formato es:

1. Codificación

   1. Genera mapas
   2. Cómo obtener compresión de mapas
   3. Genera contenedores de mapas

2. Decodificación

Figura 1: Ejemplo de diseño de archivo y metadatos relevantes.

Motivación

El objetivo de este formato de archivo es codificar información adicional en una imagen SDR. que se pueden usar junto con la técnica de visualización para generar sus formatos HDR óptimos en un solo archivo.

Para que esto sea práctico, el formato de archivo debe cumplir con los siguientes requisitos:

• Debe ser retrocompatible, de modo que, para usuarios básicos, la imagen SDR convencional el código fuente.
• No ocupe demasiado espacio extra.

Además, la técnica de visualización debe cumplir con lo siguiente:

• No requieren procesamiento intensivo para decodificarse.
• Adaptarse a cualquier relación entre los puntos blancos del SDR y el HDR de una pantalla que puede variar significativamente entre dispositivos o, incluso, temporalmente en un solo dispositivo.

Por último, la técnica debe ser capaz de realizar todas las acciones anteriores sin nunca:

• Recorte de elementos destacados.
• Sombras que rompen.
• Cambiar o comprimir el contraste local.
• Cambiar las relaciones tonales relativas (entre los objetos de la escena).

Dependencias

Las siguientes son referencias normativas para esta especificación:

• Especificación de Adobe XMP, parte 3: Almacenamiento en archivos
• Especificación de XMP ISO 16684-1:2019 (parte 1)
• Formato de archivo de medios base ISO/IEC 14496-12
• T.81 (09/92) Compresión y codificación digital de imágenes fijas de tono continuos imágenes
• Informe de la CIPA DC-x 007-2009, formato Multi-Picture

Definiciones

• Pantalla SDR

  • Una pantalla convencional, que no está diseñada para mostrar contenido HDR Estos las pantallas suelen producir un brillo máximo nominal de aproximadamente 400 cd/m² o menos.

• Pantalla HDR

  • Una pantalla diseñada para contenido HDR. Estas pantallas suelen producir un brillo máximo nominal mayor que el de una pantalla SDR, por lo general, 800 cd/m² o superior; también suelen tener un mejor contraste que las pantallas SDR.

• Imagen principal

  • La primera instancia de una imagen en un archivo GContainer con medios secundarios archivos adjuntos. La imagen principal contiene metadatos XMP de GContainer Definir el orden y las propiedades del elemento multimedia secundario subsiguiente en el contenedor de archivos.

• Imagen secundaria

  • Archivos de elementos multimedia posteriores que se agregan a la imagen principal en una .GContainer.

• Compresión de rango

  • En fotografía, las escenas del mundo real suelen tener un rango más dinámico que un la pantalla SDR puede representar. Operaciones como la compresión de rangos, también llamada asignación de tono local, son necesarias para reducir el rango dinámico de un imagen. Esta reducción debe evitar recortar los momentos destacados o romperlos. a la vez que preservan el contraste local tanto como sea posible.Intentas reducir el tamaño de los grandes bordes de luminancia de la imagen, lo que contribuye más a su contraste global, al tiempo que intentamos preservar el tamaño de pequeños bordes de luminancia, que son los detalles.Aunque hay muchas en implementaciones diferentes, tal operación es estándar en la mayoría cámaras digitales.

• punto blanco de SDR

  • La luminancia lineal máxima del contenido SDR en una pantalla en un rango en un momento determinado.

• Punto blanco HDR

  • La luminancia lineal máxima del contenido HDR en una pantalla en un valor determinado en un momento determinado. Por lo general, este valor es más alto que el punto blanco del SDR.

• Amplificación

  • Es el punto blanco HDR dividido por el punto blanco SDR.

• Potenciación máxima del contenido (max_content_boost en ecuaciones)

  • Este valor permite al creador del contenido limitar el brillo de una imagen. cuando se muestre en una pantalla HDR, en relación con la representación de SDR.
  • Este valor es una constante para una imagen en particular. Por ejemplo, si el valor es cuatro, por lo tanto, para cualquier píxel, la luminancia lineal del la representación de HDR que se muestra debe ser, como máximo, 4 veces la luminancia lineal de la la interpretación de SDR. En la práctica, esto significa que las partes más brillantes de la escena se puede mostrar hasta 4 veces más brillante.
  • En la práctica, este valor suele ser mayor que 1.0.
  • Siempre mayor o igual que la Mejora mínima del contenido.

• Refuerzo mínimo de contenido (min_content_boost en ecuaciones)

  • Este valor permite al creador del contenido limitar puede obtener una imagen, cuando se muestra en una pantalla HDR, en relación con el SDR. la interpretación.Este valor es una constante para una imagen en particular.
  • Si, por ejemplo, el valor es 0.5, entonces, para cualquier píxel, la de la representación HDR en pantalla debe ser (al menos) 0.5 veces el valor y lineal de la representación de SDR.
  • En la práctica, este valor suele ser igual o menor que 1.0.
  • Siempre menor o igual que la Mejora del contenido máxima

• Mejora máx. de pantalla (max_display_boost en ecuaciones)

  • Es la mejora máxima disponible que admite una pantalla en un punto determinado de tiempo. Este valor puede cambiar con el tiempo según la configuración del dispositivo y otras factores como las condiciones de luz ambiente o cuántos píxeles brillantes hay en la pantalla.
  • Por ejemplo, si este valor es 4.0, entonces la pantalla puede mostrar Mostrar un píxel que sea, como máximo, cuatro veces más brillante que el SDR. punto blanco. Este valor es siempre >= 1.0, ya que la pantalla siempre puede pantalla HDR con blanco al menos tan brillante como SDR blanco.

• Mejora de Display

  • Equivale a la mejora mínima de la mejora de contenido y la de visualización máxima. Esta siempre es >= 1.0.
  • Por ejemplo, si la mejora máxima del contenido es 4.0 y la mejora de la pantalla máxima es 3.0, entonces la mejora de Display es de 3.0. Los píxeles se muestran hasta 3 veces más brillantes. que el SDR, ya que las capacidades de visualización son el factor limitante.
  • Por ejemplo, si la mejora máxima del contenido es 4.0 y la mejora de la pantalla máxima es de 5.0, y la mejora de visualización es de 4.0. Los píxeles se muestran hasta 4 veces. más brillante que el SDR, ya que la intención del contenido es el factor limitante.

• Reproducción de HDR objetivo

  • La interpretación ideal de HDR, según el creador del contenido.

• Reproducción de HDR adaptada

  • La versión final de HDR que se muestra en la pantalla, después de adaptar la representación de HDR objetivo para la mejora de pantalla actual.

• Mapa de ganancias (recovery(x, y) en ecuaciones)

  • Un mapa que indica cuánto brillo cada píxel, en la interpretación de SDR para producir la representación HDR objetivo. Este mapa puede ser de un solo canal multicanal. Un mapa multicanal indica una ganancia independiente para cada uno canal de color, como rojo, verde y azul. En este documento, se ilustra en el caso de un mapa de un solo canal.

• clamp(x, a, b)

  • Fija el valor x al rango [a, b].

• exp2(x)

  • Exponenciación de base 2; 2^x.

• floor(x)

  • Muestra el número entero más cercano que sea igual o menor que x.

• log2(x)

  • Logaritmo en base 2; log₂(x)

• pow(b, x)

  • Exponenciación; b^x.

• XMP

  • Plataforma de metadatos extensible. Un estándar que define un método para codificar metadatos en un contenedor de imagen definido por las ISO 16684-1:2011(E) Especificación XMP Parte 1.

• Formato multiimagen

  • El formato de imágenes múltiples es una técnica desarrollada por el equipo de Cámara e Imágenes Asociación de productos (CIPA) para almacenar varias imágenes JPEG codificadas en un solo archivo JPEG.
  • Para obtener más información, consulta la dependencia relacionada, el Informe de la CIPA DC-x 007-2009, formato de varias imágenes.

• GContainer

  • GContainer es un método para almacenar varias imágenes en una sola imagen de contenedor, donde una imagen se considera como la imagen principal. Cualquiera las imágenes adicionales se consideran versiones alternativas o auxiliares. Los metadatos XMP se utilizan para comunicar la presencia y el significado de cualquier imágenes adicionales. Para obtener más información, consulta la documentación de GContainer sección de detalles.

Codifica

En esta sección, se describe cómo codificar un archivo JPEG conforme. Consulta T.81 (09/92) Compresión digital y programación de imágenes fijas de tono continuo imágenes en la sección Dependencias para obtener más información. sobre el formato JPEG.

Genera mapas

Las canalizaciones de imágenes de cámaras suelen realizar una operación de compresión de rango para comprime los datos de luminancia de rango dinámico más altos en el rango más bajo de la cámara pantallas SDR. El mapa de ganancia proporciona un mecanismo para almacenar datos suficientes recupera los datos originales de luminancia de rango dinámico más alto.

En los siguientes cálculos de esta sección, se supone la aritmética de punto flotante.

En las siguientes funciones, se describe la imagen SDR:

• SDR'(x, y) es el formato de tres canales, no lineal (generalmente con codificación gamma). imagen principal.
• SDR(x, y) es la versión lineal de la imagen principal de tres canales. se obtiene transformando a una versión lineal del color de imagen principal espacio. Por ejemplo, desde un espacio de color con una función de transferencia sRGB hasta una un espacio de color lineal que preserva los colores primarios sRGB.

La función Ysdr(x, y) se define en el rango de 0.0 a 1.0 y es la luminancia lineal de la imagen principal de rango dinámico estándar:

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

Existen definiciones similares para la imagen HDR.

• HDR'(x, y) es el formato no lineal de tres canales, es decir, con codificación PQ o HLG. imagen.
• HDR(x, y) es la imagen HDR lineal de tres canales.

Yhdr(x, y) es la luminancia en un punto determinado de la imagen HDR:

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

Yhdr(x, y) se define en el rango de 0.0 a la mejora máxima del contenido.

Las imágenes SDR y HDR deben tener la misma resolución. El perfil de color del SDR define el espacio de color de la imagen HDR.

Por ejemplo, si la imagen principal SDR tiene un perfil de color Display-P3, entonces la imagen HDR se define en relación con los colores primarios de ese perfil. Esta significa que la imagen HDR también tiene colores primarios Display-P3.

El mapa de ganancia se calcula a partir de dos imágenes lineales que contienen la imagen HDR deseada luminancia, Yhdr(x, y), y la imagen de luminancia de rango estándar, Ysdr(x, y).

La función pixel_gain(x, y) se define como la proporción entre Yhdr(x, y). y la función Ysdr(x, y):

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

El comportamiento de la función pixel_gain(x, y), en el que Ysdr(x, y) y offset_sdr son tanto cero está definido por la implementación.

Por ejemplo, las implementaciones pueden controlar el caso en el que Ysdr(x, y) y offset_sdr son cero cuando se define pixel_gain(x, y) como 1.0. Por otro lado, las implementaciones también evitan esta situación utilizando un offset_sdr distinto de cero.

La implementación puede elegir los valores de offset_sdr y offset_hdr.

El mapa de ganancia es una función escalar que codifica pixel_gain(x, y) en una espacio logarítmico, en relación con la mejora máxima y mínima del contenido:

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)

El comportamiento de la función recovery(x, y), en el que pixel_gain(x, y) es cero es se define la implementación porque log2(0) no está definido.

map_gamma es un número de punto flotante que debe ser mayor que 0.0 y es elegidas por la implementación.

Los valores de la mejora máxima del contenido y la mejora mínima del contenido son las siguientes: definidas por la implementación, y el creador del contenido puede decidir de forma arbitraria. La mejora máxima del contenido debe ser mayor o igual que 1.0. La mejora mínima del contenido debe estar dentro del rango (0.0, 1.0).

Los valores en recovery(x, y) se limitan al rango [0.0, 1.0].

El mapa de ganancia se almacena en una imagen secundaria JPEG, por lo que debe codificarse con valores enteros de 8 bits sin firma, que se encuentran en el rango [0, 255]. Cada valor representa un valor de recovery(x, y) y se almacena en un píxel de la interfaz imagen.

Para el almacenamiento de número entero de 8 bits sin firma, el valor codificado se define como el lo siguiente:

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

El cálculo de la función de codificación se realiza en punto flotante y se convierte a el final al resultado de número entero de 8 bits sin firma redondeando como se indica.

Esta codificación da como resultado una representación de número entero de 8 bits sin firma de Valores recovery(x, y), de 0.0 a 1.0 El mapa de ganancia codificado se debe almacenar en un elemento de imagen secundario como JPEG. La implementación elige la cantidad de compresión para usar durante la codificación JPEG.

Una vez que el mapa de ganancia se almacena en una imagen secundaria, se agrega a una con metadatos de MPF y GContainer XMP. La imagen principal de GContainer debe contener un elemento para la imagen del mapa de ganancia.

La resolución del mapa de ganancia almacenado está definida por la implementación y puede distinta de la resolución de la imagen principal. En caso de que la ganancia El mapa se ajusta a una resolución diferente a la de la imagen principal para su almacenamiento, la método de muestreo debe ser bilineal o ser mejor, y su implementación está definida.

La orientación del mapa de ganancia debe coincidir con la de la imagen principal. Si cualquier metadato de orientación en la imagen del mapa de ganancia almacenada, como en EXIF no se usa.

Si está presente, no se usa el perfil de color del mapa de ganancias.

Contenedor del mapa de ganancia

Perfil de color

El perfil de color de la imagen debe indicarse a través de un perfil ICC de la imagen principal.

Atributos XMP

La imagen principal contiene metadatos XMP para definir al menos dos imágenes con información semántica para el formato de mapa de ganancia HDR.

Las siguientes subsecciones contienen detalles específicos de este formato. Adicional información relacionada con el cumplimiento general de GContainer se especifica en el Sección GContainer details.

Los valores de atributos descritos en las siguientes tablas se almacenan como archivos simples de XMP. valores de los tipos de valores básicos XMP especificados.

Valores semánticos del elemento

La propiedad Item:Semantic define el significado específico de la aplicación de cada elemento multimedia en el directorio del contenedor.

Metadatos de mapas con aumento de HDR

Los metadatos del mapa de ganancia codifican la información sobre cómo interpretar y aplicar la ganancia. para generar la representación HDR de la imagen principal.

El URI del espacio de nombres XMP para la extensión XMP de metadatos del mapa de ganancia es http://ns.adobe.com/hdr-gain-map/1.0/ El prefijo del espacio de nombres predeterminado es hdrgm

Estos metadatos se almacenan en el paquete XMP de la imagen del mapa de ganancia y los siguientes elementos: Las propiedades deben aparecer en rdf:Description de XMP de la imagen del mapa de ganancia:

Ejemplo de XMP para mapas de ganancia

El siguiente ejemplo de un paquete XMP de mapa de ganancia válido contiene metadatos tomados del archivo de ejemplo ilustrado en la sección Introducción.

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

Almacenamiento de MPF del mapa de ganancia

La imagen del mapa de ganancia debe almacenarse como una imagen adicional, tal como se define en CIPA DC-x 007-2009 en formato de varias imágenes, como se indica en las Sección Dependencies.

Decodificación

En esta sección, se describe cómo decodificar el mapa de ganancia a partir de un archivo JPEG conforme.

Indicador del formato

Un archivo JPEG que cumpla con este formato puede identificarse por la presencia de hdrgm:Version="1.0" en el paquete XMP de la imagen principal, donde hdrgm es el URI del espacio de nombres http://ns.adobe.com/hdr-gain-map/1.0/.

Ubica la imagen del mapa de ganancia

Para obtener información detallada sobre el análisis y la decodificación de la imagen, consulta la documentación de GContainer sección de detalles. Un “GainMap” elemento semántico dentro de XMP rdf:Directory se usa para indicar la ubicación de una imagen del mapa de ganancia. Por otro lado, el IFD del índice MPF y la búsqueda de imágenes XMP se usa para determinar la ubicación de un mapa de ganancia.

Controla los metadatos no válidos

Los metadatos se consideran no válidos si no hay un campo obligatorio presente o si está presente con un valor no válido. Un valor puede no ser válido porque no se puede analizar con el tipo especificado o porque está fuera del rango esperado.

Si se encuentran metadatos no válidos, se debe ignorar el mapa de ganancia y se debe ignorar el SDR. se debe mostrar la imagen.

Pantalla

Los archivos codificados en el formato de mapa de ganancia HDR se pueden renderizar en pantallas SDR convencionales o en pantallas HDR compatibles con una mayor luminosidad salida.

Usa el mapa de ganancias para crear la representación HDR adaptada

En los siguientes cálculos de esta sección, se supone que la aritmética es de punto flotante.

encoded_recovery(x, y) es el valor de número entero sin firma de un solo canal de 8 bits a partir de la imagen del mapa de ganancia.

Si la resolución del mapa de ganancia es diferente a la de la imagen principal, En cambio, encoded_recovery(x, y) se determina mediante un muestreo filtrado de lo siguiente: obtener una imagen de mapa para x e y en el rango de ancho y alto de la imagen principal, respectivamente. El método de filtrado debe ser bilineal o mejor y es implementación definida.

map_gamma está determinado por el campo de metadatos hdrgm:Gamma.

log_recovery(x, y) es la ganancia de píxeles de punto flotante normalizada en un espacio logarítmico:

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

La mejora máxima de la pantalla es un valor escalar de punto flotante definido como la proporción entre el punto blanco de HDR actual dividido por el punto blanco del SDR actual. Esta el valor proporcionado por el sistema de visualización y puede cambiar con el tiempo.

hdr_capacity_max está determinado por el campo de metadatos hdrgm:HDRCapacityMax. hdr_capacity_min está determinado por el campo de metadatos hdrgm:HDRCapacityMin.

weight_factor se determina de la siguiente manera cuando hdrgm:BaseRenditionIsHDR es "Falso":

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)

Cuando hdrgm:BaseRenditionIsHDR es "True", la segunda ecuación es la siguiente:

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

gain_map_max está determinado por el campo de metadatos hdrgm:GainMapMax. gain_map_min está determinado por el campo de metadatos hdrgm:GainMapMin. offset_sdr está determinado por el campo de metadatos hdrgm:OffsetSDR. offset_hdr está determinada por el campo de metadatos hdrgm:OffsetHDR.

La representación de HDR adaptada lineal se puede calcular de la siguiente manera:

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

Si es necesario, la implementación podría aplicar una transformación a HDR(x, y) para colocar la en el espacio que espera la pantalla. Todas esas transformaciones deben ser colorimétricamente correcto.

Detalles de GContainer

Esta sección especifica los requisitos adicionales de modo que el formato cumpla con con metadatos XML de GContainer. Los metadatos se serializan según la ISO 166841:2011(E) XMP Specification Part 1 and incorporado dentro del archivo de imagen principal, como se describe en Especificación de Adobe XMP Parte 3 Almacenamiento en Archivos. El archivo de imagen principal contiene la los siguientes elementos, con el formato RDF/XML.

Requisitos de paquetes XMP

El paquete XMP debe incluir la extensión XMP de metadatos del mapa de ganancia a través del URI del espacio de nombres http://ns.adobe.com/hdr-gain-map/1.0/. El espacio de nombres predeterminado es hdrgm.

El paquete XMP debe definir hdrgm:Version="1.0".

Elemento de contenedor

El espacio de nombres XMP para la extensión XMP de GContainer es http://ns.google.com/photos/1.0/container/ El prefijo del espacio de nombres predeterminado es Container

La imagen principal contiene un elemento Container:Directory en los metadatos XMP. Definir el orden y las propiedades del archivo multimedia posterior en el archivo contenedor. Cada archivo del contenedor tiene un elemento multimedia correspondiente en la Container:Directory El elemento multimedia describe la ubicación en el archivo. y las propiedades básicas de cada archivo concatenado.

El elemento contenedor está codificado en los metadatos XMP de la imagen principal y define un directorio de elementos multimedia en el contenedor. Los elementos multimedia deben estar ubicados del archivo contenedor en el mismo orden que los elementos multimedia de la y deben estar bien empaquetados.

El directorio solo puede contener un elemento "Primary" elemento de imagen y debe ser el primero del directorio.

Elemento:

Los elementos de elementos describen cómo la app usa cada elemento multimedia.

El URI del espacio de nombres XMP para la extensión XMP del elemento de GContainer es http://ns.google.com/photos/1.0/container/item/ El prefijo del espacio de nombres predeterminado es Item.

El primer elemento multimedia debe ser la imagen principal.Debe especificar Item:Semantic = "Primary" y un Item:Mime enumerado en Valores de tipo MIME del elemento.

La longitud del elemento de imagen principal se determina mediante el análisis del principal según su tipo de MIME, comenzando por el principio del contenedor de archivos.

Los elementos multimedia pueden contener un atributo Item:Padding que especifique relleno entre el final del elemento multimedia y el comienzo del siguiente elemento. Cuando está presente en el último elemento multimedia de Container:Directory, Item:Padding indica un relleno entre el final del elemento y el final de la .

Cada elemento multimedia debe contener el tipo Item:Mime y atributos Item:Semantic. Los elementos multimedia de la imagen secundaria deben contener atributos Item:Length.

Los elementos multimedia secuenciales pueden compartir datos de recursos dentro del contenedor de archivos. El El primer elemento multimedia determina la ubicación del recurso en el contenedor de archivos. y los elementos multimedia compartidos posteriores tienen Item:Length establecido en 0. En el caso de que los datos del recurso son en sí mismos un contenedor, Item:URI podría usarse para determinar la ubicación de los datos del elemento de medios dentro del recurso.

La ubicación de los recursos de los elementos multimedia en el contenedor se determina mediante la suma la longitud de la codificación de la imagen principal, los valores Item:Length de la recursos anteriores de elementos multimedia secundarios y todos los Item:Padding anteriores de salida. Item:Padding se considera como 0 en los recursos de elementos multimedia que no especificar su valor.

Valores de tipo MIME del elemento

El atributo Item:Mime define el tipo de MIME de cada elemento multimedia de datos no estructurados.

Ejemplo de XMP de GContainer

El siguiente ejemplo de un paquete XMP de GContainer válido tiene metadatos tomados de el archivo de ejemplo ilustrado en la sección Introducción.

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