Formato de imagen Ultra HDR v1.1

Introducción

En este documento, se define el comportamiento de un nuevo formato de archivo que codifica una imagen de mapa de ganancia de rango logarítmico en un archivo de imagen JPEG. Los lectores heredados que no admiten el nuevo formato leen y muestran la imagen convencional de rango dinámico bajo del archivo de imagen. Los lectores que admiten el formato combinan la imagen principal con el mapa de ganancia y renderizan 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 usar este formato. En términos generales, el ciclo de vida de una imagen que se ajusta a este formato es el siguiente:

1. Codificación

   1. Generación de mapas de ganancias
   2. Obtén 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 archivos de imagen SDR que se pueden usar en combinación con la técnica de visualización para producir sus mejores representaciones HDR, 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 se muestre la imagen SDR convencional para usuarios básicos.
• No ocupe demasiado espacio extra.

Además, la técnica de visualización debe cumplir con los siguientes requisitos:

• No requieren un procesamiento intensivo para decodificarse.
• Ser capaz de adaptarse a cualquier relación entre los puntos blancos de HDR y SDR de una pantalla, que pueden variar de forma significativa entre dispositivos o incluso temporalmente en un solo dispositivo

Por último, la técnica debe ser capaz de realizar todas las acciones anteriores sin siquiera hacer lo siguiente:

• Recorte de los momentos destacados
• Sombras aplastadas
• 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 XMP ISO 16684-1:2019, parte 1
• ISO/IEC 14496-12 ISO base media file format
• T.81 (09/92) Codificación y compresión digital de imágenes estáticas de tono continuo
• Informe de CIPA DC-x 007-2009 sobre el formato multifoto

Definiciones

• Pantalla SDR

  • Es una pantalla convencional que no está diseñada para mostrar contenido HDR. Por lo general, estas pantallas producen un brillo máximo nominal de alrededor de 400 cd/m² o menos.

• Pantalla HDR

  • Una pantalla diseñada para contenido HDR Por lo general, estas pantallas producen un brillo máximo nominal superior al de una pantalla SDR, por lo general, de 800 cd/m² o más, y también suelen tener mejores relaciones de contraste que las pantallas SDR.

• Imagen principal

  • Es la primera instancia de una imagen en un archivo GContainer con archivos multimedia secundarios adjuntos. La imagen principal contiene metadatos XMP de GContainer que definen el orden y las propiedades de los archivos de elementos multimedia secundarios posteriores en el contenedor de archivos.

• Imagen secundaria

  • Son los archivos de elementos multimedia posteriores que se agregan a la imagen principal en un archivo GContainer.

• Compresión de rango

  • En la fotografía, las escenas del mundo real suelen tener un rango dinámico más amplio que el que puede representar una pantalla SDR. Las operaciones como la compresión de rango, también llamada asignación de tono local, se necesitan para reducir el rango dinámico de una imagen. Esta reducción debe evitar recortar los reflejos o aplastar las sombras, al tiempo que preserva el contraste local tanto como sea posible. Intentas reducir el tamaño de los bordes de luminancia grandes en la imagen, que contribuyen más a su contraste global, mientras intentas preservar el tamaño de los bordes de luminancia pequeños, que son los detalles. Aunque hay muchas implementaciones diferentes, esta operación es estándar en la mayoría de las cámaras digitales modernas.

• Punto blanco SDR

  • Es la luminancia lineal máxima del contenido de SDR en una pantalla en un momento determinado.

• Punto blanco HDR

  • Es la luminancia lineal máxima del contenido HDR en una pantalla en un momento determinado. Por lo general, este valor es superior al punto blanco de SDR.

• Amplificación

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

• Aumento máximo del contenido (max_content_boost en las ecuaciones)

  • Este valor permite que el creador de contenido limite la cantidad de brillo que puede tener una imagen cuando se muestra en una pantalla HDR en relación con la renderización SDR.
  • Este valor es una constante para una imagen en particular. Por ejemplo, si el valor es cuatro, para cualquier píxel determinado, la luminancia lineal de la renderización HDR que se muestra debe ser, como máximo, 4 veces la luminancia lineal de la renderización SDR. En la práctica, esto significa que las partes más brillantes de la escena se pueden mostrar hasta 4 veces más brillantes.
  • En la práctica, este valor suele ser mayor que 1.0.
  • Siempre debe ser mayor o igual que Aumento mínimo del contenido.

• Aumento mínimo del contenido (min_content_boost en las ecuaciones)

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

• Aumento máximo de la pantalla (max_display_boost en las ecuaciones)

  • Es la mejora máxima disponible que admite una pantalla en un momento determinado. Este valor puede cambiar con el tiempo según la configuración del dispositivo y otros factores, como las condiciones de luz ambiental o la cantidad de píxeles brillantes en la pantalla.
  • Por ejemplo, si este valor es 4.0, la pantalla puede mostrar un píxel que es, como máximo, cuatro veces más brillante que el punto blanco de SDR. Este valor siempre es superior o igual a 1.0, ya que la pantalla siempre puede mostrar el blanco HDR al menos tan brillante como el blanco SDR.

• Mejora de Display

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

• Renderización HDR objetivo

  • La renderización HDR ideal, según el creador de contenido

• Renderización HDR adaptada

  • La renderización HDR final que se muestra en la pantalla, después de adaptar la renderización HDR objetivo para el aumento de la pantalla actual.

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

  • Un mapa que indica cuánto se debe aclarar cada píxel, en la renderización SDR, para producir la renderización HDR objetivo. Este mapa puede ser de un solo canal o de varios. Un mapa multicanal indica una ganancia independiente para cada canal de color, como rojo, verde y azul. En este documento, se ilustra 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 en base 2; 2^x.

• floor(x)

  • Devuelve 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 imágenes, definido por la especificación XMP parte 1 de la norma ISO 16684-1:2011(E).

• Formato de varias imágenes

  • El formato de varias imágenes es una técnica desarrollada por la Camera and Imaging Products Association (CIPA) para almacenar varias imágenes codificadas en JPEG en un solo archivo JPEG.
  • Para obtener más información, consulta la dependencia relacionada, el informe de CIPA DC-x 007-2009 sobre el formato multifoto.

• GContainer

  • GContainer es un método para almacenar varias imágenes en un contenedor de imágenes, en el que una imagen se considera como la principal. Cualquier imagen adicional se considera versión alternativa o auxiliar. Los metadatos XMP se usan para comunicar la presencia y el significado de cualquier imagen adicional. Para obtener más información, consulta la sección Detalles de GContainer.

Codifica

En esta sección, se describe cómo codificar un archivo JPEG conforme. Consulta T.81 (09/92) Digital compression and coding of continuous-tone still images, en la sección Dependencias, para obtener más información sobre el formato JPEG.

Generación de mapas de ganancias

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

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

En las siguientes funciones, se describe la imagen SDR:

• SDR'(x, y) es la imagen principal no lineal de tres canales (por lo general, codificada en gamma).
• SDR(x, y) es la versión lineal de la imagen principal de tres canales, que se obtiene mediante la transformación a una versión lineal del espacio de color de la imagen principal. Por ejemplo, de un espacio de color con una función de transferencia sRGB a un espacio de color lineal que conserva 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 del 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 no lineal de tres canales, es decir, una imagen codificada en PQ o HLG.
• 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 de la imagen SDR define el espacio de color de la imagen HDR.

Por ejemplo, si la imagen principal SDR tiene un perfil de color Display-P3, la imagen HDR se define en relación con los colores primarios de ese perfil. Esto 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 luminancia de la imagen HDR deseada, Yhdr(x, y), y la imagen de luminancia del rango estándar, Ysdr(x, y).

La función pixel_gain(x, y) se define como la proporción entre la función 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 cero se define en la implementación.

Por ejemplo, las implementaciones pueden controlar el caso en el que Ysdr(x, y) y offset_sdr son cero definiendo pixel_gain(x, y) como 1.0. Como alternativa, las implementaciones también evitan esta situación con el uso de un offset_sdr distinto de cero.

La implementación podría 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 un 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 está definido por la implementación, ya que log2(0) no está definido.

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

Los valores de aumento máximo de contenido y aumento mínimo de contenido se definen en la implementación y el creador de contenido puede decidirlos de forma arbitraria. El aumento máximo del contenido debe ser mayor o igual que 1.0. El aumento mínimo del contenido debe estar en el 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 un JPEG de imagen secundaria y, por lo tanto, se debe codificar con valores de números enteros de 8 bits sin firmar, por lo que está en el rango [0, 255]. Cada valor representa un valor recovery(x, y) y se almacena en un píxel de la imagen secundaria.

Para el almacenamiento de números enteros sin signo de 8 bits, el valor codificado se define de la siguiente manera:

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 al final en el resultado de número entero sin signo de 8 bits redondeando como se indica.

Esta codificación genera una representación de número entero sin firma de 8 bits de los valores de recovery(x, y), de 0.0 a 1.0. El mapa de ganancias codificado se debe almacenar en un elemento de imagen secundario como un archivo JPEG. La implementación elige la cantidad de compresión que se usará durante la codificación JPEG.

Después de que el mapa de ganancias se almacena en una imagen secundaria, se agrega a una imagen principal con metadatos XMP de MPF y GContainer. El directorio principal de GContainer de la imagen debe contener un elemento para la imagen del mapa de ganancia.

La resolución del mapa de ganancia almacenado se define en la implementación y puede ser diferente de la resolución de la imagen principal. En el caso de que el mapa de ganancia se ajuste a una resolución diferente de la imagen principal para el almacenamiento, el método de muestreo debe ser bilinear o mejor, y se define en la implementación.

La orientación del mapa de ganancia debe coincidir con la de la imagen principal. Si están presentes, no se usan los metadatos de orientación en la imagen del mapa de ganancias almacenada, como en EXIF.

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

Obtén el contenedor del mapa

Perfil de color

El perfil de color de la imagen se debe indicar a través de un perfil ICC para la imagen principal.

Atributos XMP

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

En las siguientes sub secciones, se incluyen detalles específicos de este formato. En la sección Detalles de GContainer, se especifica información adicional sobre el cumplimiento general de GContainer.

Los valores de atributo que se describen en las siguientes tablas se almacenan como valores simples de XMP de los tipos de valores básicos de XMP especificados.

Valores semánticos del artículo

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

Metadatos del mapa de ganancia HDR

Los metadatos del mapa de ganancia codifican información sobre cómo interpretar y aplicar el mapa de ganancia para producir 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 las siguientes 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 el formato de varias imágenes CIPA-x 007-2009, como se hace referencia en la sección Dependencias.

Decodificación

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

Señal del formato

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

Ubica la imagen del mapa de ganancias

Para obtener detalles sobre el análisis y la decodificación de la imagen, consulta la siguiente sección Detalles de GContainer. Se usa un elemento semántico "GainMap" dentro de rdf:Directory de XMP para indicar la ubicación de una imagen de mapa de ganancia. Como alternativa, se usa el IFD del índice de MPF y el XMP de las imágenes de escaneo 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 algún campo está presente con un valor no válido. Un valor puede no ser válido porque no se puede analizar al tipo especificado o porque está fuera de su rango esperado.

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

Pantalla

Es posible que los archivos codificados en el formato de mapa de ganancia de HDR se rendericen en pantallas SDR convencionales o en pantallas HDR capaces de generar una salida con mayor luminosidad.

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

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

encoded_recovery(x, y) es el valor entero de un solo canal, 8 bits y sin firma de la imagen del mapa de ganancias.

Si la resolución del mapa de ganancia es diferente a la de la imagen principal, encoded_recovery(x, y) se determina mediante un muestreo filtrado de la imagen del mapa de ganancia correspondiente a x e y en el rango del ancho y la altura de la imagen principal, respectivamente. El método de filtrado debe ser bilinear o mejor, y se define en la implementación.

map_gamma se determina mediante 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)

El aumento máximo de la pantalla es un valor de punto flotante escalar definido como la proporción entre el punto blanco HDR actual y el punto blanco SDR actual. El sistema de visualización proporciona este valor, que puede cambiar con el tiempo.

hdr_capacity_max se determina mediante el campo de metadatos hdrgm:HDRCapacityMax. hdr_capacity_min se determina mediante el campo de metadatos hdrgm:HDRCapacityMin.

weight_factor se determina de la siguiente manera cuando hdrgm:BaseRenditionIsHDR es “False”:

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 se determina mediante el campo de metadatos hdrgm:GainMapMax. gain_map_min se determina mediante el campo de metadatos hdrgm:GainMapMin. offset_sdr se determina mediante el campo de metadatos hdrgm:OffsetSDR. offset_hdr se determina mediante 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 los datos en el espacio que espera la pantalla. Cualquier transformación de este tipo debe ser colorimétricamente correcta.

Detalles de GContainer

En esta sección, se especifican requisitos adicionales para que este formato cumpla con los metadatos XML de GContainer. Los metadatos se serializan de acuerdo con la Especificación XMP Parte 1 de la norma ISO 166841:2011(E) y se incorporan en el archivo de imagen principal, como se describe en la Especificación XMP Parte 3 de Adobe: Almacenamiento en archivos. El archivo de imagen principal contiene los siguientes elementos con formato RDF/XML.

Requisitos de los 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 prefijo de espacio de nombres predeterminado es hdrgm.

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

Elemento del 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 que define el orden y las propiedades del archivo multimedia posterior en el contenedor de archivos. Cada archivo del contenedor tiene un elemento multimedia correspondiente en el Container:Directory. El elemento multimedia describe la ubicación en el contenedor de archivos y las propiedades básicas de cada archivo concatenado.

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

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

Elemento de artículo

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

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

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

La longitud del elemento de imagen principal se determina a través del análisis de la imagen principal según su tipo MIME, que comienza al principio del contenedor de archivos.

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

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

Los elementos multimedia secuenciales pueden compartir datos de recursos dentro del contenedor de archivos. 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 caso de que los datos del recurso sean un contenedor, se podría usar Item:URI para determinar la ubicación de los datos del elemento multimedia dentro del recurso.

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

Valores de tipo MIME del artículo

El atributo Item:Mime define el tipo de MIME de cada dato de elemento multimedia.

Ejemplo de XMP de GContainer

En el siguiente ejemplo de un paquete XMP de GContainer válido, se tomaron metadatos del archivo de ejemplo que se muestra 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>

Compatibilidad con ISO 21496-1

El ISO 21496-1 proporciona un mecanismo de encapsulamiento alternativo para codificar los metadatos del mapa de ganancia en un archivo de imagen. Puedes codificar los metadatos de Ultra HDR y los metadatos ISO 21496-1 en un archivo JPEG con una sola imagen de mapa de ganancia en el archivo.

Figura 2: Ejemplo de diseño de archivo con Ultra HDR y metadatos ISO 21496-1.

Para obtener la máxima compatibilidad multiplataforma, las implementaciones y apps de Android que implementen su propia codificación o decodificación de archivos JPEG con mapas de ganancia deben admitir la codificación y decodificación de metadatos Ultra HDR v1 y ISO 21496-1. Durante una operación de codificación, la implementación o la app deben codificar ambos formatos de metadatos. Si ambos tipos de metadatos están presentes durante una operación de decodificación, la implementación o la app deben preferir usar los metadatos ISO 21496-1.

Registro de cambios

En esta sección, se incluye información sobre los cambios entre las versiones de esta especificación.

Versión 1.1

Todos los cambios en esta versión de la especificación de Ultra HDR son informativos y se relacionan con la compatibilidad con ISO 21496-1. No hay cambios en el formato de archivo real.

• Se agregó la sección Compatibilidad con ISO 21496-1.

Versión 1.0

La publicación inicial de la especificación de Ultra HDR.