Format d'image Ultra HDR v1.0

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 JPEG. Les anciens lecteurs qui ne sont pas compatibles avec le nouveau format lisent et affichent l'image conventionnelle à faible plage dynamique 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 de 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. Gagner des cartes
   2. Gain de compression de carte
   3. Obtenir la génération de conteneurs de carte

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 obtenir leurs meilleurs rendus HDR dans un seul fichier.

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

• Être rétrocompatible afin que l'image SDR classique s'affiche pour les spectateurs naïfs.
• Elles n'occupent pas trop d'espace.

De plus, la technique d'affichage doit:

• Ne nécessite pas de traitement lourd pour le décodage.
• Pouvoir s'adapter à n'importe quel rapport entre les points blancs HDR et SDR d'un écran, qui peut varier considérablement d'un appareil à l'autre, voire temporairement sur un seul appareil.

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

• Coupures des temps forts
• Des ombres brisées.
• Modification ou compression du contraste local.
• Modification des relations tonales relatives (entre les objets de la scène).

Dépendances

Voici des références normatives pour cette spécification:

• Spécification Adobe XMP Partie 3: Stockage dans les fichiers
• Spécification XMP ISO 16684-1:2019 (partie 1)
• Format de fichier média de base ISO/IEC 14496-12
• T.81 (09/92) Compression numérique et codage d'images fixes à tons continus
• Livre blanc de la CIPA DC-x 007-2009 Multi-Picture Format

Définitions

• Écran SDR

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

• Écran HDR

  • Un é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 800 cd/m² ou plus. Ils présentent également généralement de meilleurs rapports de contraste que les écrans SDR.

• Image principale

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

• Image secondaire

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

• Compression de plage

  • En photographie, les scènes réelles ont souvent une plage dynamique plus importante que ce qu'un écran SDR ne peut représenter. Des opérations telles que la compression de plage, également appelée mappage des tons locaux, sont nécessaires pour réduire la plage dynamique d'une image. Cette réduction doit éviter de rogner les tons clairs ou d'écraser les ombres, tout en préservant autant que possible le contraste local.Vous essayez de réduire la taille des grands bords de luminance de l'image, qui contribuent davantage à son contraste global, tout en essayant de préserver la taille des petits bords de luminance, qui sont les détails.Bien qu'il existe de nombreuses implémentations différentes, une telle opération est la norme 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

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

• Amplifier

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

• Optimisation maximale du contenu (max_content_boost dans les équations)

  • Cette valeur permet au créateur de contenu de limiter l'augmentation de luminosité d'une image lorsqu'elle est affichée sur un écran HDR par rapport au rendu SDR.
  • Cette valeur est une constante pour une image particulière. Par exemple, si la valeur est de quatre, pour un pixel donné, la luminance linéaire du rendu HDR affiché doit au maximum correspondre à quatre fois 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.
  • En pratique, cette valeur est généralement supérieure à 1,0.
  • Toujours supérieure ou égale à la valeur Optimisation du contenu minimal.

• Amélioration de contenu minimal (min_content_boost dans les équations)

  • Cette valeur permet au créateur de contenu de limiter l'assombrissement qu'elle peut devenir sur un écran HDR par rapport au rendu SDR.Cette valeur est une constante pour une image particulière.
  • Par exemple, si la valeur est de 0, 5, la luminance linéaire du rendu HDR affiché doit (au moins) correspondre à 0, 5 fois la luminance linéaire du rendu SDR.
  • En pratique, cette valeur est généralement inférieure ou égale à 1,0.
  • Elle est toujours inférieure ou égale à la valeur Max Content Boost.

• Boost maximal sur le Réseau Display (max_display_boost dans les équations)

  • Boost disponible maximal accepté par 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 de luminosité ambiante 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'optimisation de contenu maximale et l'optimisation maximale des annonces display. Cette valeur est toujours supérieure ou égale à 1,0.
  • Par exemple, si l'optimisation du contenu maximale est de 4,0 et que l'optimisation maximale des annonces display est de 3,0. Les pixels s'affichent jusqu'à trois fois plus lumineux que le SDR, car les capacités d'affichage sont le facteur limitant.
  • Prenons un autre exemple. Si l'optimisation du contenu maximale est de 4,0 et que l'optimisation maximale des annonces display est de 5,0, l'optimisation display est de 4,0. Les pixels sont affichés jusqu'à quatre fois plus lumineux que les SDR, car l'intent du contenu est le facteur limitant.

• Rendu HDR cible

  • Le 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 de l'écran actuel.

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

  • Carte indiquant la luminosité de chaque pixel dans le rendu SDR pour produire le rendu HDR cible. Cette carte peut être monocanal ou multicanal. 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)

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

• exp2(x)

  • exponentielle en base 2 ; 2^x.

• floor(x)

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

• log2(x)

  • Log₂(x) de base 2

• pow(b, x)

  • Exposantiation ; b^x.

• XMP

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

• Format multi-image

  • Le format multi-image 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 sur la dépendance associée, consultez le livre blanc sur le format multi-image de la 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. Toute image supplémentaire est considérée comme une version alternative ou auxiliaire. Les métadonnées XMP sont utilisées pour communiquer la présence et la signification de toute image supplémentaire. Pour en savoir plus, consultez la section Détails de GContainer.

Encoder

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

Gagner des cartes

Les pipelines d'imagerie des caméras effectuent généralement une opération de compression de plage pour compresser les données de luminance en plage dynamique supérieure vers la plage inférieure des écrans SDR classiques. Le mappage de gain fournit un mécanisme permettant de stocker suffisamment de données pour récupérer les données de luminance de la plage dynamique d'origine, plus élevées.

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

Les fonctions suivantes décrivent l'image SDR:

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

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

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

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

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

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

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

La valeur Yhdr(x, y) est comprise entre 0.0 et Content Boost maximal.

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 a 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 primaires Display P3.

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

La fonction pixel_gain(x, y) est définie comme le ratio 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) où 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 les 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 une valeur offset_sdr non nulle.

L'implémentation peut choisir les valeurs 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 de contenu maximale et à l'amplification 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) où pixel_gain(x, y) est égal à zéro est défini pour 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 "Max Content Boost" et "Min Content Boost" sont définies par l'implémentation et peuvent être décidées de manière arbitraire par le créateur de contenu. L'optimisation de contenu maximale doit être supérieure ou égale à 1. L'amplification de contenu minimale doit être comprise dans la plage (0,0, 1,0).

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

Le mappage de gain est stocké dans une image secondaire JPEG et doit donc être encodé à l'aide de valeurs entières non signées de 8 bits, qui se situent donc 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 de 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 un entier non signé de 8 bits par arrondi, comme indiqué.

Cet encodage produit une représentation sous forme d'entier non signé de 8 bits des valeurs recovery(x, y) comprises entre 0.0 et 1.0. Le mappage de gain encodé doit être stocké 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 que le mappage de gain est stocké dans une image secondaire, il est ajouté à une image principale avec les métadonnées MPF et XMP de GContainer. Le répertoire GContainer de l'image principale doit contenir un élément pour l'image de 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. Dans le cas où la carte du gain est mise à l'échelle avec une résolution différente de celle de l'image principale à des fins de stockage, la méthode d'échantillonnage doit être bilinéaire ou supérieure. De plus, elle doit être implémentée.

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.

S'il est présent, le profil de couleurs de la carte de gain n'est pas utilisé.

Récupérer un conteneur de carte

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 permettant de 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 Informations sur GContainer.

Les valeurs d'attribut décrites dans les tableaux suivants sont stockées sous forme de valeurs simples XMP correspondant aux types de valeurs de base XMP spécifiés.

Valeurs sémantiques de l'élément

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.

Récupérer des métadonnées de carte HDR

Les métadonnées de carte de gain encodent les 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 de métadonnées de 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 carte de gain, et les propriétés suivantes doivent apparaître dans le rdf:Description du XMP de l'image de carte de gain:

Exemple 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 des gains

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

Décodage

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 correspond à l'URI d'espace de noms http://ns.adobe.com/hdr-gain-map/1.0/.

Localiser l'image de carte de gain

Pour en savoir plus sur l'analyse et le décodage de l'image, consultez la section Informations détaillées sur GContainer. Un élément sémantique "GainMap" dans le rdf:Directory XMP est utilisé pour signaler l'emplacement d'une image de carte de gain. L'IFD de l'indice MPF et le XMP des images sont également utilisés 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, car elle ne peut pas être analysée avec le type spécifié ou parce qu'elle se trouve en dehors de la plage attendue.

Si des métadonnées non valides sont rencontrées, la carte des gains doit être ignorée et l'image SDR doit être affichée.

É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'obtenir une sortie de luminance supérieure.

Utiliser la carte de gain pour créer le rendu HDR adapté

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

encoded_recovery(x, y) est la valeur entière non signée, 8 bits à un seul canal de l'image de carte de gain.

Si la résolution de la carte de gain est différente de celle de l'image principale, encoded_recovery(x, y) est alors déterminé par un échantillonnage filtré de l'image de 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 supérieure, et son implémentation est définie.

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

log_recovery(x, y) est le gain de pixels à 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 maximale de l'écran est une valeur scalaire à virgule flottante définie comme le ratio entre le point blanc HDR actuel et divisé par 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 a la valeur "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 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.

Le rendu HDR adapté linéaire peut être calculé 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. Ces transformations doivent être correctes d'un point de vue colorimétrique.

Détails de GContainer

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

Exigences relatives aux paquets XMP

Le paquet XMP doit inclure l'extension XMP de métadonnées de 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 conteneur

L'espace de noms XMP de l'extension XMP de 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 possède un élément multimédia correspondant 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 ils doivent être très empaquetés.

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

Élément d'élément

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 les valeurs du type MIME de l'article.

La longueur de l'élément de l'image principale est déterminée en analysant 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'elle est présente sur le dernier élément multimédia du 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 le type Item:Mime et les attributs Item:Semantic. Les éléments multimédias des images secondaires 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 des éléments multimédias partagés suivante est définie sur 0. Si les données de ressource sont elles-mêmes un conteneur, Item:URI peut être utilisé pour déterminer l'emplacement des données d'élément multimédia dans la ressource.

L'emplacement des ressources d'éléments multimédias dans le conteneur est déterminé par la somme de la longueur de l'encodage de l'image principale, des valeurs Item:Length des ressources d'éléments multimédias secondaires précédentes et de toutes les valeurs Item:Padding précédentes. Item:Padding est considéré comme ayant la valeur 0 sur les ressources d'élément multimédia 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 XMP de GContainer

L'exemple suivant de paquet XMP GContainer valide contient des métadonnées extraites du fichier 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>