Format d'image Ultra HDR v1.0

Introduction

Ce document définit le comportement d'un nouveau format de fichier qui encode un image de carte de gain en plage logarithmique dans un fichier image JPEG. Les anciens lecteurs qui ne sont compatibles avec le nouveau format, lisent et affichent les images du fichier image.Les lecteurs qui prennent en charge le format combinent l'image principale avec la carte de gain et afficher une image HDR compatibles.

Le reste de ce document décrit les méthodes des processus nécessaires pour utilisez ce format. Globalement, le cycle de vie d'une image conforme à ce format est:

1. Encodage

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

2. Décodage

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

Motivation

L'objectif de ce format de fichier est d'encoder des informations supplémentaires dans une image SDR qui peuvent être utilisés avec la technique d'affichage pour produire leurs rendus HDR optimaux, dans un seul fichier.

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

• être rétrocompatibles afin que, pour les spectateurs simplistes, l'image SDR conventionnelle s'affiche.
• Elles ne prennent pas trop de place.

De plus, la technique d'affichage doit:

• Le décodage ne nécessite pas de traitement lourd.
• Ê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, voire dans le temps appareil.

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

• Découpage des temps forts
• Des ombres écrasantes.
• Modifier ou compresser le contraste local
• Modification des relations tonales relatives (entre les objets de la scène)

Dépendances

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

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

Définitions

• Écran SDR

  • Écran traditionnel, non conçu pour afficher des contenus HDR. Ces les é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, et offrent généralement un meilleur contraste que les écrans SDR.

• Image principale

  • Première instance d'une image dans un fichier GContainer avec un média secondaire fichiers qui lui sont ajoutés. L'image principale contient les métadonnées XMP GContainer définir l'ordre et les propriétés de l'élément multimédia secondaire suivant ; dans le conteneur de fichiers.

• Image secondaire

  • Les fichiers d'éléments multimédias suivants sont ajoutés à l'image principale dans une .gContainer

• Compression de plages

  • En photographie, les scènes du monde réel ont souvent une gamme dynamique plus large qu'une que peut représenter l'affichage SDR. Les opérations telles que la compression de plages, (appelées "mappages des tons locaux") sont nécessaires pour réduire la plage dynamique l'image. Cette réduction doit éviter de rogner les tons clairs ou d'écraser des ombres, tout en préservant autant que possible le contraste local.Vous essayez de de réduire la taille des bords de luminance importants dans l'image, à son contraste global, tout en essayant de préserver la taille les bords de la luminance, qui sont les détails.Bien qu'il existe de nombreuses différentes implémentations, ce type d'opération est la norme sur la plupart des appareils photo numériques aujourd'hui.

• Point blanc SDR

  • Luminance linéaire maximale du contenu SDR sur un écran à une certaine valeur à un moment précis.

• Point blanc HDR

  • Luminance linéaire maximale du contenu HDR sur un écran à une certaine valeur à un moment précis. Cette valeur est généralement supérieure au point blanc 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 la luminosité d'une image peuvent obtenir, lorsqu'ils sont affichés sur un écran HDR, par rapport au rendu SDR.
  • Cette valeur est une constante pour une image particulière. Par exemple, si le est égale à quatre, puis pour tout pixel donné, la luminance linéaire du le rendu HDR affiché doit être au maximum quatre fois la luminance linéaire de le rendu SDR. En pratique, cela signifie que les parties les plus brillantes la scène peut être jusqu'à quatre fois plus lumineuse.
  • En pratique, cette valeur est généralement supérieure à 1,0.
  • Toujours supérieur ou égal à la valeur Amplification du contenu min.

• Optimisation minimale du contenu (min_content_boost dans les équations)

  • Cette valeur permet au créateur de contenu de limiter que l'image peut obtenir, lorsqu'elle est diffusée sur un écran HDR, par rapport à la SDR. le rendu final.Cette valeur est une constante pour une image particulière.
  • Si, par exemple, la valeur est 0,5, alors pour un pixel donné, la courbe la luminance du rendu HDR affiché doit être (au moins) 0,5 fois supérieure à la luminance linéaire du rendu SDR.
  • En pratique, cette valeur est généralement égale ou juste inférieure à 1,0.
  • Toujours inférieur ou égal à la valeur Optimisation du contenu maximale.

• Amplification maximale de l'écran (max_display_boost dans les équations)

  • Boost disponible maximal pris en charge par un écran, à un moment donné en temps réel. Cette valeur peut changer au fil du temps en fonction des paramètres de l'appareil et d'autres facteurs tels que la luminosité ambiante ou le nombre de pixels à l'écran.
  • Par exemple, si cette valeur est 4,0, l'écran peut qui affiche un pixel au maximum quatre fois plus lumineux que le SDR. un point blanc. Cette valeur est toujours supérieure ou égale à 1.0, car l'affichage peut toujours avec un 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 maximale du contenu et l'optimisation maximale de l'affichage. Ce la valeur est toujours >= 1.0.
  • Par exemple, si l'optimisation maximale du contenu est de 4,0 et celle de l'optimisation display maximale est de 3, l'amélioration de l'affichage est de 3. Les pixels s'affichent jusqu'à trois fois plus lumineux que SDR, car les capacités d'affichage sont le facteur limitant.
  • Autre exemple : si l'optimisation maximale du contenu est de 4, et l'optimisation display maximale est de 5,0, l'optimisation de l'affichage est de 4,0. Les pixels s'affichent jusqu'à quatre fois plus brillant que le 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 en adaptant le rendu HDR cible pour l'amélioration actuelle de l'affichage.

• Carte de 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 concerner un seul canal ou multicanal. Une carte multicanal indique un gain distinct pour chacun canal de couleur, tel que rouge, vert et bleu. Ce document illustre dans le cas d'une carte à canal unique.

• clamp(x, a, b)

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

• exp2(x)

  • exponentiel base 2 ; x 2^x.

• floor(x)

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

• log2(x)

  • Logarithme en base 2 ; log₂(x)

• pow(b, x)

  • Exponentiation b^x.

• XMP

  • Extensible Metadata Platform. une norme qui définit une méthode encoder des métadonnées dans un conteneur d'images ; défini par ISO 16684-1:2011(E) Spécification XMP Partie 1.

• Format multi-image

  • Le format multi-image est une technique développée par le laboratoire d'images Association de produits (CIPA) pour le stockage de plusieurs images encodées au format JPEG dans un seul fichier JPEG.
  • Pour en savoir plus, consultez la dépendance associée, Livre blanc de la CIPA DC-x 007-2009 Multi-Picture Format.

• Conteneur Google

  • gContainer est une méthode permettant de stocker plusieurs images dans une même image. où une image est considérée comme l'image principale. N'importe quelle valeur les images supplémentaires sont considérées comme des versions alternatives ou auxiliaires. Les métadonnées XMP sont utilisées pour communiquer la présence et la signification des images supplémentaires. Pour plus d'informations, consultez la documentation GContainer détails.

Encoder

Cette section explique comment encoder un fichier JPEG conforme. Reportez-vous à la section T.81 (09/92) Compression numérique et codage d'image statique continue images, dans la section "Dépendances", pour en savoir plus sur le format JPEG.

Génération de la carte de gain

Les pipelines d'imagerie des caméras effectuent généralement une compression de plages compresser les données de luminance à plage dynamique supérieure à la plage inférieure des valeurs les écrans SDR. La carte de gain fournit un mécanisme pour stocker des données suffisantes pour récupérer les données de luminance d'origine à plage dynamique supérieure.

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

Les fonctions suivantes décrivent l'image SDR:

• SDR'(x, y) est le canal non linéaire à trois canaux (généralement encodé en gamma) ; l'image principale.
• SDR(x, y) correspond à la version linéaire de l'image principale à trois canaux. obtenu en convertissant une version linéaire de la couleur principale de l'image l'espace de stockage. Par exemple, d'un espace colorimétrique avec une fonction de transfert sRVB à qui préserve les couleurs primaires sRVB.

La fonction Ysdr(x, y) est définie sur une plage de 0,0 à 1,0. luminance linéaire de l'image principale dans 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 une valeur non linéaire à trois canaux, c'est-à-dire encodée au format PQ ou HLG. l'image.
• HDR(x, y) correspond à l'image HDR linéaire sur trois canaux.

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

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

Yhdr(x, y) est compris dans la plage 0,0 de l'optimisation du contenu maximale.

Les images SDR et HDR doivent avoir la même résolution. Profil de couleur du 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, alors l'image HDR est définie par rapport aux couleurs primaires de ce profil. Ce signifie que l'image HDR comporte également des images principales Display-P3.

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

La fonction pixel_gain(x, y) correspond au ratio entre les Yhdr(x, y) et la fonction Ysdr(x, y):

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

Comportement de la fonction pixel_gain(x, y) où Ysdr(x, y) et offset_sdr sont le zéro 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 lorsque pixel_gain(x, y) est défini sur 1.0. Par ailleurs, 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'optimisation de contenu maximale 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), où pixel_gain(x, y) est égal à zéro l'implémentation définie, 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 d'optimisation de contenu maximale et d'optimisation de contenu minimale sont définies par la mise en œuvre et peuvent être déterminées de manière arbitraire par le créateur du contenu. L'optimisation maximale du contenu doit être supérieure ou égale à 1. L'optimisation de contenu minimale doit 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].

La carte de gain est stockée dans une image secondaire JPEG, et doit donc être encodée en utilisant des valeurs entières non signées de 8 bits, donc comprises dans la plage [0, 255]. Chaque valeur Représente une valeur recovery(x, y) et est stocké dans un pixel de l'instance l'image.

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

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 du résultat entier non signé de 8 bits en arrondissant comme indiqué.

Ce codage donne une représentation entière non signée de 8 bits de Valeurs recovery(x, y), comprises entre 0,0 et 1,0. La carte de gain encodée doit être stockée comme image secondaire au format JPEG. L'implémentation choisit la quantité à 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 les métadonnées MPF et GContainer XMP. Le 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ù le Gain La carte est mise à l'échelle avec une résolution différente de celle de l'image principale pour le stockage, la méthode d'échantillonnage doit être bilinéaire ou supérieure, et est définie pour l'implémentation.

L'orientation de la carte de gain doit correspondre à celle de l'image principale. Si toute métadonnée d'orientation dans l'image de carte de gain stockée, comme dans EXIF, n'est pas utilisée.

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

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 permettant de définir au moins deux images avec des données des informations sémantiques pour le format de carte de gain HDR.

Les sous-sections suivantes contiennent des informations spécifiques à ce format. Autres les informations relatives à la conformité générale avec GContainer sont spécifiées dans le Détails de GContainer

Les valeurs d'attribut décrites dans les tableaux suivants sont stockées sous forme de code XMP simple 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 carte du gain HDR

Les métadonnées de carte de gain encodent des informations sur la manière d'interpréter et d'appliquer le gain pour générer la représentation HDR de l'image principale.

L'URI d'espace de noms XMP pour l'extension XMP des 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 gain et dans les doivent apparaître dans le fichier XMP de l'image de gain de l'image (rdf:Description) :

Exemple de XMP de carte de gain

L'exemple suivant de paquet XMP de mappage de gain valide contient des métadonnées prises du fichier d'exemple 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 la carte de gain doit être stockée sous la forme d'une image supplémentaire, conformément aux dispositions de la norme CIPA DC-x 007-2009 Multi-Picture Format, comme indiqué dans le Dépendances.

Décodage

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

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

Localiser l'image de la carte de gain

Pour plus de détails sur l'analyse et le décodage de l'image, consultez la documentation GContainer détails. Une « GainMap » élément sémantique du XMP rdf:Directory permet de signaler l'emplacement d'une image de carte de gain. Le format MPF Index IFD et l'analyse des images XMP est utilisé 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 contient une valeur non valide. Une valeur peut être incorrecte si elle n'est pas analysable au type spécifié ou parce qu'il se trouve 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 le SDR doit s'afficher.

Écran

Les fichiers encodés au format de carte de gain HDR peuvent être affichés sur les écrans SDR classiques ou les écrans HDR offrant une luminance plus élevée. de sortie.

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 de 8 bits à canal unique à partir 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 plutôt déterminé par un échantillonnage filtré des obtenir l'image de carte 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 doit être est définie.

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

log_recovery(x, y) est le gain normalisé en pixels à virgule flottante 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'optimisation maximale de l'affichage est une valeur scalaire à virgule flottante définie comme le ratio entre point blanc HDR actuel, divisé par le point blanc SDR actuel. Ce 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 "Faux" :

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 "True", la deuxième équation est à la place:

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 le dans l'espace attendu par l'écran. Ces transformations doivent être colorimétriquement correct.

Détails de GContainer

Cette section spécifie des exigences supplémentaires pour que ce format soit conforme avec des métadonnées XML GContainer. Les métadonnées sont sérialisées selon les normes ISO 166841:2011(E) Spécification XMP Partie 1 et version intégrée dans le fichier image principal, comme indiqué dans la spécification Adobe XMP (partie 3) Stockage dans Fichiers Le fichier 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 carte de gain via le URI d'espace de noms http://ns.adobe.com/hdr-gain-map/1.0/. Espace de noms par défaut est hdrgm.

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

Élément du conteneur

L'espace de noms XMP de l'extension GContainer XMP 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 définir l'ordre et les propriétés du fichier multimédia suivant dans le fichier ; conteneur. Chaque fichier du conteneur possède un élément multimédia correspondant Container:Directory L'élément multimédia décrit l'emplacement dans le fichier. et les propriétés de base de chaque fichier concaténé.

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

Le répertoire ne peut contenir qu'un seul champ "Principal" et il doit s'agir du premier élément image dans le 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 d'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 Valeurs du type MIME de l'élément.

La longueur 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 des une marge intérieure entre la fin de l'élément multimédia et le début du suivant élément. S'il est présent sur le dernier élément multimédia dans Container:Directory, Item:Padding indique la marge intérieure entre la fin de l'élément et la fin de l'élément .

Chaque élément multimédia doit contenir un type Item:Mime et des 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. La le premier élément multimédia détermine l'emplacement de la ressource dans le conteneur de fichiers, et les éléments multimédias partagés suivants ont la valeur Item:Length définie sur 0. Dans le cas où si les données de la ressource constituent elles-mêmes un conteneur, Item:URI peut servir à 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é par la somme la longueur de l'encodage de l'image principale, les valeurs Item:Length des les ressources d'élément multimédia secondaires précédentes et toutes les Item:Padding précédentes valeurs. Item:Padding est considéré comme nul pour les ressources d'éléments multimédias qui ne spécifier sa valeur.

Valeurs du type MIME de l'élément

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

Exemple de XMP GContainer

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