Format d'image Ultra HDR v1.1

Introduction

Ce document définit le comportement d'un nouveau format de fichier qui encode une image de carte de gain de plage logarithmique dans un fichier image JPEG. Les anciens lecteurs qui n'acceptent pas le nouveau format lisent et affichent l'image conventionnelle à faible plage dynamique à partir du fichier image. Les lecteurs compatibles avec ce format combinent l'image principale avec la carte de gain et affichent une image à plage dynamique élevée sur les écrans compatibles.

Le reste de ce document décrit les méthodes des processus nécessaires pour utiliser ce format. De manière générale, le cycle de vie d'une image conforme à ce format est le suivant:

1. Encodage

   1. Génération de la carte de gain
   2. Compression des cartes
   3. Génération de conteneurs de carte de gain

2. Décodage

Figure 1 : Exemple de mise en page de fichier et de métadonnées pertinentes.

Motivation

L'objectif de ce format de fichier est d'encoder des informations supplémentaires dans des fichiers image SDR que vous pouvez utiliser avec la technique d'affichage pour produire des rendus HDR optimaux, dans un seul fichier.

Pour que cela soit pratique, le format de fichier doit:

• être rétrocompatible, de sorte que les spectateurs n'ayant pas connaissance de la technologie HDR voient l'image SDR classique ;
• Ne pas prendre trop d'espace supplémentaire.

En outre, la technique d'affichage doit:

• Ne nécessite pas de traitement lourd pour le décodage.
• Être capable de s'adapter à n'importe quel format entre les points blancs HDR et SDR d'un écran, qui peut varier considérablement d'un appareil à l'autre, ou même dans le temps sur un seul appareil.

Enfin, la technique doit être capable d'effectuer toutes les actions précédentes sans jamais:

• Découpage des temps forts
• Ombres écrasées.
• Modification ou compression du contraste local
• Modifier les relations tonales relatives (entre les objets de la scène)

Dépendances

Voici les références normatives de cette spécification:

• Spécification XMP Adobe Partie 3: Stockage dans les fichiers
• Spécification XMP ISO 16684-1:2019 Partie 1
• Format de fichier multimédia de base ISO/IEC 14496-12
• T.81 (09/92) Compression et codage numériques des images fixes en tons continus
• Livre blanc sur le format multi-image CIPA DC-x 007-2009

Définitions

• Écran SDR

  • Écran classique, non conçu pour afficher du contenu HDR. Ces écrans produisent généralement une luminosité maximale nominale d'environ 400 cd/m² ou moins.

• Écran HDR

  • Écran conçu pour les contenus HDR Ces écrans produisent généralement une luminosité maximale nominale supérieure à celle d'un écran SDR, généralement de 800 cd/m² ou plus, et présentent généralement de meilleurs rapports de contraste que les écrans SDR.

• Image principale

  • Première instance d'une image dans un fichier GContainer à laquelle sont ajoutés des fichiers multimédias secondaires. L'image principale contient des métadonnées XMP GContainer qui définissent l'ordre et les propriétés des fichiers d'éléments multimédias secondaires ultérieurs dans le conteneur de fichiers.

• Image secondaire

  • Fichiers d'éléments multimédias ultérieurs ajoutés à l'image principale dans un fichier GContainer.

• Compression de plage

  • En photographie, les scènes du monde réel ont souvent une plage dynamique plus importante que celle d'un écran SDR. Des opérations telles que la compression de plage, également appelée mappage de tons local, sont nécessaires pour réduire la plage dynamique d'une image. Cette réduction doit éviter de couper les hautes lumières ou d'écraser les ombres, tout en préservant le contraste local autant que possible. Vous essayez de réduire la taille des bords de luminance importants de l'image, qui contribuent davantage à son contraste global, tout en essayant de préserver la taille des bords de luminance plus petits, qui correspondent aux détails. Bien qu'il existe de nombreuses implémentations différentes, une telle opération est standard sur la plupart des appareils photo numériques modernes.

• Point blanc SDR

  • Luminance linéaire maximale du contenu SDR sur un écran à un moment donné.

• Point blanc HDR

  • Luminosité linéaire maximale du contenu HDR sur un écran à un moment donné. Cette valeur est généralement supérieure au point blanc SDR.

• Amplifier

  • Point blanc HDR divisé par le point blanc SDR.

• Boost maximal du contenu (max_content_boost dans les équations)

  • Cette valeur permet au créateur de contenu de limiter la luminosité d'une image lorsqu'elle est affichée sur un écran HDR par rapport à la restitution SDR.
  • Cette valeur est une constante pour une image spécifique. Par exemple, si la valeur est quatre, pour un pixel donné, la luminance linéaire du rendu HDR affiché doit être au maximum quatre fois supérieure à la luminance linéaire du rendu SDR. En pratique, cela signifie que les parties les plus lumineuses de la scène peuvent être affichées jusqu'à quatre fois plus lumineuses.
  • En pratique, cette valeur est généralement supérieure à 1,0.
  • Toujours supérieure ou égale à l'augmentation de contenu minimale.

• Boost de contenu minimal (min_content_boost dans les équations)

  • Cette valeur permet au créateur de contenu de limiter la luminosité d'une image lorsqu'elle est affichée sur un écran HDR par rapport à la restitution SDR. Cette valeur est une constante pour une image donnée.
  • Par exemple, si la valeur est de 0,5, pour tout pixel donné, la luminance linéaire du rendu HDR affiché doit être (au moins) 0,5 fois la luminance linéaire du rendu SDR.
  • En pratique, cette valeur est généralement égale à 1,0 ou légèrement inférieure.
  • Toujours inférieure ou égale à la Boost de contenu maximal.

• Boost d'affichage maximal (max_display_boost dans les équations)

  • Boost maximal disponible compatible avec un écran, à un moment donné. Cette valeur peut changer au fil du temps en fonction des paramètres de l'appareil et d'autres facteurs, tels que les conditions d'éclairage ambiant ou le nombre de pixels lumineux à l'écran.
  • Par exemple, si cette valeur est de 4,0, l'écran peut afficher un pixel au maximum quatre fois plus lumineux que le point blanc SDR. Cette valeur est toujours supérieure ou égale à 1,0, car l'écran peut toujours afficher le blanc HDR au moins aussi lumineux que le blanc SDR.

• Boost sur le Réseau Display

  • Égal à la valeur la plus faible entre l'amélioration maximale du contenu et l'amélioration maximale de l'affichage. Cette valeur est toujours supérieure ou égale à 1,0.
  • Par exemple, si l'optimisation du contenu maximale est de 4,0 et l'optimisation display maximale de 3, l'optimisation de l'affichage est de 3,0. Les pixels sont affichés jusqu'à trois fois plus lumineux que le SDR, car les fonctionnalités d'affichage sont le facteur limitant.
  • Par exemple, si l'optimisation du contenu maximale est de 4,0 et l'optimisation display maximale est de 5,0, l'optimisation display est de 4,0. Les pixels s'affichent jusqu'à quatre fois plus lumineux que la SDR, car l'intention du contenu est le facteur limitant.

• Rendu HDR cible

  • Rendu HDR idéal, selon le créateur du contenu.

• Rendu HDR adapté

  • Rendu HDR final affiché à l'écran, après avoir adapté le rendu HDR cible à l'amélioration d'affichage actuelle.

• Carte de gain (recovery(x, y) dans les équations)

  • Carte indiquant la quantité d'éclaircissement à appliquer à chaque pixel dans le rendu SDR pour produire le rendu HDR cible. Cette carte peut être multicanale ou monocanal. Une carte multicanal indique un gain distinct pour chaque canal de couleur (rouge, vert et bleu, par exemple). Ce document illustre le cas d'une carte à canal unique.

• clamp(x, a, b)

  • Limite la valeur x à la plage [a, b].

• exp2(x)

  • Exposant de base 2 : 2^x.

• floor(x)

  • Renvoie le nombre entier le plus proche inférieur ou égal à x.

• log2(x)

  • Logarithme en base 2 : log₂(x)

• pow(b, x)

  • Exponentiation : b^x.

• XMP

  • Plate-forme de métadonnées extensible. Norme qui définit une méthode d'encodage des métadonnées dans un conteneur d'images. Elle est définie par la spécification XMP de la norme ISO 16684-1:2011(E), partie 1.

• Format multi-image

  • Le format Multi-Picture est une technique développée par la Camera and Imaging Products Association (CIPA) pour stocker plusieurs images encodées au format JPEG dans un seul fichier JPEG.
  • Pour en savoir plus, consultez la dépendance associée dans le livre blanc sur le format multi-image CIPA DC-x 007-2009.

• Conteneur Google

  • GContainer est une méthode permettant de stocker plusieurs images dans un conteneur d'images, où une image est considérée comme l'image principale. Toutes les images supplémentaires sont considérées comme des versions alternatives ou auxiliaires. Les métadonnées XMP permettent de communiquer la présence et la signification de toute image supplémentaire. Pour en savoir plus, consultez la section Informations sur GContainer.

Encode

Cette section explique comment encoder un fichier JPEG conforme. Pour en savoir plus sur le format JPEG, consultez la norme T.81 (09/92) Compression et codage numériques des images fixes en tons continus, dans la section "Dépendances".

Génération de cartes plus rapide

Les pipelines d'imagerie de l'appareil photo effectuent généralement une opération de compression de plage pour compresser les données de luminance à plage dynamique élevée dans la plage inférieure des écrans SDR conventionnels. La carte de gain fournit un mécanisme permettant de stocker des données suffisantes pour récupérer les données de luminance d'origine à plage dynamique plus élevée.

Les calculs suivants de cette section partent du principe que l'arithmétique à virgule flottante est utilisée.

Les fonctions suivantes décrivent l'image SDR:

• SDR'(x, y) est l'image principale à trois canaux, non linéaire (généralement encodée en gamma).
• SDR(x, y) est la version linéaire de l'image principale à trois canaux, obtenue par transformation en une version linéaire de l'espace colorimétrique de l'image principale. (par exemple, d'un espace de couleurs avec une fonction de transfert sRVB à un espace de couleurs linéaire qui préserve les primaires de couleur sRVB).

La fonction Ysdr(x, y) est définie sur la plage de 0,0 à 1,0 et correspond à la luminance linéaire de l'image primaire de la plage dynamique standard :

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

Des définitions similaires existent pour l'image HDR.

• HDR'(x, y) est la non-linéaire à trois canaux, c'est-à-dire une image encodée en PQ ou HLG.
• HDR(x, y) correspond à l'image HDR linéaire sur trois canaux.

Yhdr(x, y) correspond à la luminance à un point donné de l'image HDR:

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

Yhdr(x, y) est défini dans la plage de 0,0 à la promotion de contenu maximale.

Les images SDR et HDR doivent avoir la même résolution. Le profil de couleur de l'image SDR définit l'espace colorimétrique de l'image HDR.

Par exemple, si l'image principale SDR présente un profil de couleur Display-P3, l'image HDR est définie par rapport aux couleurs primaires de ce profil. Cela signifie que l'image HDR comporte également des couleurs primaires Display-P3.

La carte de gain est calculée à partir de deux images linéaires contenant la luminance de l'image HDR souhaitée, Yhdr(x, y), et l'image de luminance de la plage standard, Ysdr(x, y).

La fonction pixel_gain(x, y) est définie comme le rapport entre la fonction Yhdr(x, y) et la fonction Ysdr(x, y):

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

Le comportement de la fonction pixel_gain(x, y) lorsque Ysdr(x, y) et offset_sdr sont tous deux nuls est défini par l'implémentation.

Par exemple, les implémentations peuvent gérer le cas où Ysdr(x, y) et offset_sdr sont tous deux nuls en définissant pixel_gain(x, y) sur 1,0. Les implémentations évitent également ce scénario en utilisant un offset_sdr non nul.

L'implémentation peut choisir les valeurs de offset_sdr et offset_hdr.

La carte de gain est une fonction scalaire qui encode pixel_gain(x, y) dans un espace logarithmique, par rapport à l'amplification maximale du contenu et à l'optimisation de contenu minimale:

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)

Le comportement de la fonction recovery(x, y) lorsque pixel_gain(x, y) est nul est défini par l'implémentation, car log2(0) n'est pas défini.

map_gamma est un nombre à virgule flottante qui doit être supérieur à 0,0 et qui est choisi par l'implémentation.

Les valeurs de boost de contenu maximal et de boost de contenu minimal sont définies par l'implémentation et peuvent être décidées arbitrairement par le créateur de contenu. Le boost maximal du contenu doit être supérieur ou égal à 1,0. L'optimisation de contenu minimale doit être comprise dans la plage (0,0, 1,0].

Les valeurs de recovery(x, y) sont limitées à la plage [0,0, 1,0].

La carte de gain est stockée dans une image JPEG secondaire et doit donc être encodée à l'aide de valeurs d'entiers non signés de 8 bits, c'est-à-dire dans la plage [0, 255]. Chaque valeur représente une valeur recovery(x, y) et est stockée dans un pixel de l'image secondaire.

Pour le stockage d'entiers non signés 8 bits, la valeur encodée est définie comme suit :

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

Le calcul de la fonction d'encodage est effectué en virgule flottante et converti à la fin en résultat entier non signé de 8 bits par arrondi, comme indiqué.

Cet encodage génère une représentation d'entier non signé de 8 bits des valeurs recovery(x, y), de 0,0 à 1,0. La carte de gain encodée doit être stockée dans un élément d'image secondaire au format JPEG. L'implémentation choisit la quantité de compression à utiliser lors de l'encodage JPEG.

Une fois la carte de gain stockée dans une image secondaire, elle est ajoutée à une image principale avec des métadonnées MPF et GContainer XMP. Le répertoire GContainer de l'image principale doit contenir un élément pour l'image de la carte de gain.

La résolution de la carte de gain stockée est définie par l'implémentation et peut être différente de celle de l'image principale. Si la carte de gain est mise à l'échelle à une résolution différente de l'image principale pour le stockage, la méthode d'échantillonnage doit être bilinéaire ou meilleure, et est définie par l'implémentation.

L'orientation de la carte de gain doit correspondre à celle de l'image principale. Le cas échéant, les métadonnées d'orientation dans l'image de carte de gain stockée (comme dans EXIF) ne sont pas utilisées.

Si elle est présente, la carte de gain n'utilise pas le profil de couleur.

Conteneur de carte de gain

Profil de couleur

Le profil de couleur de l'image doit être indiqué via un profil ICC pour l'image principale.

Attributs XMP

L'image principale contient des métadonnées XMP pour définir au moins deux images avec des informations sémantiques supplémentaires pour le format de carte de gain HDR.

Les sous-sections suivantes contiennent des informations spécifiques à ce format. Des informations supplémentaires sur la conformité générale à GContainer sont spécifiées dans la section Détails de GContainer.

Les valeurs d'attribut décrites dans les tableaux suivants sont stockées en tant que valeurs simples XMP des types de valeurs de base XMP spécifiés.

Valeurs sémantiques des éléments

La propriété Item:Semantic définit la signification spécifique à l'application de chaque élément multimédia dans le répertoire du conteneur.

Métadonnées de la carte de gain HDR

Les métadonnées de la carte de gain encodent des informations sur la façon d'interpréter et d'appliquer la carte de gain pour produire la représentation HDR de l'image principale.

L'URI de l'espace de noms XMP pour l'extension XMP des métadonnées de la carte de gain est http://ns.adobe.com/hdr-gain-map/1.0/. Le préfixe d'espace de noms par défaut est hdrgm.

Ces métadonnées sont stockées dans le paquet XMP de l'image de la carte de gain, et les propriétés suivantes doivent apparaître dans le rdf:Description de l'image XMP de la carte de gain :

Exemple de fichier XMP de carte de gain

L'exemple suivant de paquet XMP de carte de gain valide contient des métadonnées extraites de l'exemple de fichier illustré dans la section Introduction.

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

Stockage MPF de la carte de gains

L'image de carte de gain doit être stockée en tant qu'image supplémentaire, comme défini dans le format CIPA DC-x 007-2009 Multi-Picture, comme indiqué dans la section Dépendances.

Décoder

Cette section explique comment décoder la carte de gain à partir d'un fichier JPEG conforme.

Signal du format

Un fichier JPEG conforme à ce format peut être identifié par la présence de hdrgm:Version="1.0" dans le paquet XMP de l'image principale, où hdrgm est l'URI de l'espace de noms http://ns.adobe.com/hdr-gain-map/1.0/.

Localiser l'image de la carte de gain

Pour en savoir plus sur l'analyse et le décodage de l'image, consultez la section Détails sur GContainer suivante. Un élément sémantique "GainMap" dans le rdf:Directory XMP permet d'indiquer l'emplacement d'une image de carte de gain. Vous pouvez également utiliser l'IDF de l'indice MPF et le XMP des images de numérisation pour déterminer l'emplacement d'une carte de gain.

Gérer les métadonnées non valides

Les métadonnées sont considérées comme non valides si un champ obligatoire n'est pas présent ou si un champ est présent avec une valeur non valide. Une valeur peut être non valide parce qu'elle ne peut pas être analysée avec le type spécifié ou parce qu'elle se situe en dehors de la plage attendue.

Si des métadonnées non valides sont détectées, la carte de gain doit être ignorée et l'image SDR doit s'afficher.

Écran

Les fichiers encodés au format de carte de gain HDR peuvent être affichés sur des écrans SDR classiques ou sur des écrans HDR capables d'une sortie de luminosité plus élevée.

Utilisez la carte de gain pour créer la version HDR adaptée.

Les calculs suivants de cette section supposent une arithmétique à virgule flottante.

encoded_recovery(x, y) est la valeur d'entier non signé à 8 bits à canal unique de l'image de la carte de gain.

Si la carte de gain a une résolution différente de l'image principale, encoded_recovery(x, y) est déterminée par un échantillonnage filtré de l'image de la carte de gain pour x et y sur la plage de largeur et de hauteur de l'image principale, respectivement. La méthode de filtrage doit être bilinéaire ou meilleure, et est définie par l'implémentation.

map_gamma est déterminé par le champ de métadonnées hdrgm:Gamma.

log_recovery(x, y) correspond au gain de pixel à virgule flottante normalisé dans un espace logarithmique :

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

L'amélioration d'affichage maximale est une valeur scalaire à virgule flottante définie comme le rapport entre le point blanc HDR actuel et le point blanc SDR actuel. Cette valeur est fournie par le système d'affichage et peut changer au fil du temps.

hdr_capacity_max est déterminé par le champ de métadonnées hdrgm:HDRCapacityMax. hdr_capacity_min est déterminé par le champ de métadonnées hdrgm:HDRCapacityMin.

weight_factor est déterminé comme suit lorsque hdrgm:BaseRenditionIsHDR est "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)

Lorsque hdrgm:BaseRenditionIsHDR est défini sur "True", la deuxième équation est plutôt la suivante :

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

gain_map_max est déterminé par le champ de métadonnées hdrgm:GainMapMax. gain_map_min est déterminé par le champ de métadonnées hdrgm:GainMapMin. offset_sdr est déterminé par le champ de métadonnées hdrgm:OffsetSDR. offset_hdr est déterminé par le champ de métadonnées hdrgm:OffsetHDR.

La restitution HDR adaptée linéairement peut être calculée comme suit :

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 nécessaire, l'implémentation peut appliquer une transformation à HDR(x, y) pour placer les données dans l'espace attendu par l'écran. Toutes ces transformations doivent être colorimétriquement correctes.

Détails du GContainer

Cette section spécifie des exigences supplémentaires afin que ce format soit conforme aux métadonnées XML GContainer. Les métadonnées sont sérialisées conformément à la partie 1 de la spécification XMP ISO 166841:2011(E) et intégrées au fichier d'image principal, comme décrit dans la partie 3 de la spécification Adobe XMP (stockage dans les fichiers). Le fichier d'image principal contient les éléments suivants, au format RDF/XML.

Exigences concernant les paquets XMP

Le paquet XMP doit inclure l'extension XMP des métadonnées de la carte de gain via l'URI d'espace de noms http://ns.adobe.com/hdr-gain-map/1.0/. Le préfixe d'espace de noms par défaut est hdrgm.

Le paquet XMP doit définir hdrgm:Version="1.0".

Élément de conteneur

L'espace de noms XMP de l'extension XMP GContainer est http://ns.google.com/photos/1.0/container/. Le préfixe d'espace de noms par défaut est Container.

L'image principale contient un élément Container:Directory dans les métadonnées XMP qui définit l'ordre et les propriétés du fichier multimédia suivant dans le conteneur de fichiers. Chaque fichier du conteneur est associé à un élément multimédia dans Container:Directory. L'élément multimédia décrit l'emplacement dans le conteneur de fichiers et les propriétés de base de chaque fichier concaténé.

L'élément de conteneur est encodé dans les métadonnées XMP de l'image principale et définit un répertoire d'éléments multimédias dans le conteneur. Les éléments multimédias doivent se trouver dans le fichier de conteneur dans le même ordre que les éléments multimédias du répertoire, et doivent être empaquetés étroitement.

Le répertoire ne peut contenir qu'un seul élément d'image "Principal", qui doit être le premier élément du répertoire.

Élément "Item"

Les éléments d'élément décrivent la manière dont chaque élément multimédia est utilisé par l'application.

L'URI de l'espace de noms XMP pour l'extension XMP de l'élément GContainer est http://ns.google.com/photos/1.0/container/item/. Le préfixe d'espace de noms par défaut est Item.

Le premier élément multimédia doit être l'image principale.  Il doit spécifier Item:Semantic = "Primary" et un Item:Mime listé dans la section Valeurs du type MIME de l'élément.

La longueur de l'élément de l'image principale est déterminée par l'analyse de l'image principale en fonction de son type MIME, à partir du début du conteneur de fichiers.

Les éléments multimédias peuvent contenir un attribut Item:Padding spécifiant une marge intérieure supplémentaire entre la fin de l'élément multimédia et le début de l'élément multimédia suivant. Lorsqu'il est présent sur le dernier élément multimédia de Container:Directory, Item:Padding indique la marge intérieure entre la fin de l'élément et la fin du fichier.

Chaque élément multimédia doit contenir un type Item:Mime et des attributs Item:Semantic. Les éléments multimédias de l'image secondaire doivent contenir des attributs Item:Length.

Les éléments multimédias séquentiels peuvent partager des données de ressources dans le conteneur de fichiers. Le premier élément multimédia détermine l'emplacement de la ressource dans le conteneur de fichiers, et la valeur Item:Length est définie sur 0 pour les éléments multimédias partagés suivants. Si les données de la ressource sont elles-mêmes un conteneur, Item:URI peut être utilisé pour déterminer l'emplacement des données de l'élément multimédia dans la ressource.

L'emplacement des ressources d'éléments multimédias dans le conteneur est déterminé en additionnant la longueur de l'encodage d'image principal, les valeurs Item:Length des ressources d'éléments multimédias secondaires précédentes et toutes les valeurs Item:Padding précédentes. Item:Padding est considéré comme 0 pour les ressources d'éléments multimédias qui ne spécifient pas sa valeur.

Valeurs du type MIME de l'élément

L'attribut Item:Mime définit le type MIME des données de chaque élément multimédia.

Exemple de fichier XMP GContainer

L'exemple suivant de paquet XMP GContainer valide contient des métadonnées extraites du fichier d'exemple illustré dans la section Introduction.

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

Compatibilité avec la norme ISO 21496-1

La norme ISO 21496-1 fournit un autre mécanisme d'encapsulation pour l'encodage des métadonnées de la carte de gain dans un fichier image. Vous pouvez encoder à la fois les métadonnées Ultra HDR et les métadonnées ISO 21496-1 dans un seul fichier JPEG à l'aide d'une seule image de carte de gain dans le fichier.

Figure 2. Exemple de mise en page de fichier avec des métadonnées Ultra HDR et ISO 21496-1.

Pour une compatibilité multiplate-forme maximale, les implémentations Android et les applications qui implémentent leur propre encodage ou décodage de fichiers JPEG avec des cartes de gain doivent prendre en charge l'encodage et le décodage à la fois pour les métadonnées Ultra HDR v1 et ISO 21496-1. Lors d'une opération d'encodage, l'implémentation ou l'application doit encoder les deux formats de métadonnées. Si les deux types de métadonnées sont présents lors d'une opération de décodage, l'implémentation ou l'application doit préférer utiliser les métadonnées ISO 21496-1.

Journal des modifications

Cette section contient des informations sur les modifications entre les versions de cette spécification.

v1.1

Toutes les modifications apportées dans cette version de la spécification Ultra HDR sont fournies à titre d'information et concernent la compatibilité ISO 21496-1. Aucune modification n'est apportée au format de fichier.

• Ajoutez la section Compatibilité avec la norme ISO 21496-1.

v1.0

Publication initiale des spécifications Ultra HDR.