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 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, afin que l'image SDR conventionnelle s'affiche pour les spectateurs simples.
• Ne pas prendre trop d'espace supplémentaire.

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 ratio entre les points blancs HDR et SDR d'un écran, qui peut varier considérablement d'un appareil à l'autre, voire de manière temporelle sur un seul appareil.

Enfin, la technique doit pouvoir effectuer toutes les actions précédentes sans jamais :

• Rognage des temps forts.
• Ombres écrasées.
• Modifier ou compresser le contraste local
• Modifier les relations tonales relatives (entre les objets de la scène)

Dépendances

Voici les 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 multimédia ISO/IEC 14496-12 de base ISO
• 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 le contenu 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 ont généralement également 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 multimédias secondaires suivants dans le conteneur de fichiers.

• Image secondaire

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

• Compression de plages

  • En photographie, les scènes réelles présentent souvent une plage dynamique supérieure à ce qu'un écran SDR peut représenter. 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 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 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.

• 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, 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 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érieur ou égal à la valeur Amplification du contenu min.

• Amélioration minimale du contenu (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 particulière.
  • Si, par exemple, la valeur est de 0,5, pour un pixel donné, la luminance linéaire de la représentation HDR affichée doit être (au moins) 0,5 fois la luminance linéaire de la représentation SDR.
  • En pratique, cette valeur est généralement égale à 1,0 ou légèrement inférieure.
  • Toujours inférieur ou égal à la valeur Optimisation du contenu maximale.

• Boost d'affichage maximal (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 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 plus 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.

• Amplification de l'affichage

  • Égal à la valeur la plus faible entre l'optimisation maximale du contenu et l'optimisation 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 de l'affichage maximale est de 3,0, 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.
  • Autre exemple : si l'optimisation du contenu maximale est de 4,0 et l'optimisation display maximale de 5, l'optimisation de l'affichage est de 4,0. Les pixels sont affichés jusqu'à quatre fois plus lumineux 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 avoir adapté le rendu HDR cible à l'amélioration d'affichage actuelle.

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

  • Carte indiquant l'intensité à laquelle éclaircir chaque pixel, dans la représentation SDR, pour produire la représentation HDR cible. Cette carte peut être multicanale ou monocanal. Une carte multicanal indique un gain distinct pour chaque canal de couleur, comme le rouge, le vert et le bleu. 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, définie par la spécification XMP partie 1 de la norme ISO 16684-1:2011(E).

• 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 sont utilisées pour 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 section T.81 (09/92) Compression et codage numériques d'images fixes aux tons continus, dans la section "Dépendances".

Génération de la carte de gain

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.

Remarque :Pour illustrer les formules suivantes, ce document part du principe que vous utilisez une carte de gain à canal unique.Si ce n'est pas le cas, les formules associées à ces propriétés peuvent être extrapolées à chaque canal de couleur. Vous évitez de convertir SDR(x, y) et HDR(x, y) en Ysdr(x, y) et Yhdr(x, y), respectivement, et définissez plutôt pixel_gain(x, y) en tant que fonction vectorielle par rapport à SDR(x, y) et HDR(x, y). Vous pouvez également utiliser les valeurs de métadonnées par chaîne, si nécessaire. Utilisez autant que possible une carte de gain à un seul canal.

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 primaire à trois canaux, obtenue en transformant l'espace colorimétrique de l'image primaire en version linéaire. (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 une valeur non linéaire à trois canaux, c'est-à-dire une image encodée au format PQ ou HLG.
• 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 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 possède 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) correspond au 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) 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.

Conseil : Utilisez une valeur de 0,015625 (1/64) pour offset_sdr et offset_hdr. L'objectif de ces valeurs est de trouver un juste milieu entre la capacité à augmenter le niveau de noir et la capacité à encoder avec précision des valeurs de gain plus faibles. Augmenter ces valeurs de décalage augmente la capacité de récupération des noirs proches, tout en maintenant une valeur raisonnable pour map_max_log2. Augmenter les valeurs trop élevées peut réduire la précision de la carte.

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.

Conseil :Définissez recovery(x, y) sur 0.0, où pixel_gain(x, y) est zéro. En effet, une valeur recovery(x, y) de 0,0 représente la plus grande atténuation possible qui peut être stockée dans la carte de gain.

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

Conseil :Utilisez un map_gamma de 1.0. Vous pouvez utiliser une valeur différente si votre carte de gain présente une distribution très inégale des valeurs log_recovery(x, y). Par exemple, cela peut s'appliquer si une carte de gain comporte de nombreux détails juste au-dessus de la plage SDR (représentée par de petites valeurs log_recovery(x, y)) et un map_max_log2 très élevé pour la partie supérieure de la luminosité souhaitée de la restitution HDR (représentée par de grandes valeurs log_recovery(x, y)). Dans ce cas, vous pouvez utiliser un map_gamma supérieur à 1,0 afin que recovery(x, y) puisse encoder précisément les détails dans le bas de gamme et dans le haut de gamme de log_recovery(x, y).

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. L'optimisation maximale du contenu doit être supérieure ou égale à 1. Le coup de pouce minimal au contenu doit être compris dans la plage (0,0, 1,0].

Remarque : Par exemple, imaginons que l'image provient d'un appareil photo et que le pipeline de traitement d'images de l'appareil photo génère l'image SDR en effectuant une compression de plage sur une entrée à plage dynamique plus élevée. Ensuite, l'amélioration maximale du contenu et l'amélioration minimale du contenu peuvent dépendre de la quantité de compression de plage effectuée et des régions de luminance qu'elle a affectées.

Ces pipelines peuvent choisir une optimisation de contenu minimale de 1,0 s'ils ne souhaitent pas encoder une atténuation de l'image HDR par rapport à l'image SDR. Si vous générez la carte de gain en fonction des rendus SDR et HDR eux-mêmes, vous pouvez déterminer la valeur maximale et minimale de l'amélioration du contenu en fonction du gain maximal et minimal nécessaire pour convertir les deux rendus.

Les créateurs ou éditeurs de contenu peuvent également ajuster l'amplification maximale du contenu pour contrôler la différence maximale autorisée entre la luminance SDR et HDR lorsque l'image est affichée.

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

Remarque :Les zones les plus lumineuses de l'image ont généralement des valeurs recovery(x, y) proches de 1,0, tandis que les zones plus sombres de l'image ont des valeurs autour de 0,0.

La carte de gain est stockée dans une image secondaire JPEG. Elle doit donc être encodée à l'aide de 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é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.

Conseil : Pour la plupart des implémentations d'encodage JPEG, commencez avec un paramètre de qualité de l'algorithme JPEG défini par l'implémentation de 85 à 90 sur 100, ou similaire.

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 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 des gains 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 elle est définie par l'implémentation.

Conseil :Avant de stocker la carte de gain, faites en sorte que la carte de gain soit sous-échantillonnée à 1⁄16 de la taille (1⁄4 sur chaque dimension) de l'image principale, par exemple une carte de gain de 480 x 270 pour une image principale de 1 920 x 1 080 pixels. La carte de gain doit présenter un format semblable à celui de l'image principale.

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.

Conseil :Utilisez un profil de couleur Display-P3.

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 concernant la conformité générale avec GContainer sont spécifiées dans la section Informations sur 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.

Valeur	Description
Principale	Indique que l'élément multimédia est l'image principale, prête à être affichée, dans le conteneur. Le répertoire doit contenir un élément "Principal".
GainMap	Indique que l'élément multimédia est une carte de gain. Le répertoire peut contenir au maximum un élément "GainMap".

Métadonnées de carte du 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 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 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 :

Nom	Type	Description
hdrgm:Version	Texte	Version du format de carte de gain utilisé. Il s'agit de la version "1.0". Obligatoire :
hdrgm:BaseRenditionIsHDR	Booléen	Indique la plage dynamique de l'image principale. "False" indique que l'image principale est au format SDR et que la carte de gain peut être combinée avec elle pour produire une représentation HDR. "True" indique que l'image principale est au format HDR et que la carte de gain peut être combinée avec elle pour produire la représentation SDR. Doit être "False". Facultatif. La valeur par défaut est "False".
hdrgm:GainMapMin	Tableau réel ou ordonné de réels	Stocke la ou les valeurs de map_min_log2. Il s'agit de log2 de l'amélioration minimale du contenu, qui correspond au ratio minimal autorisé de la luminance linéaire pour la restitution HDR cible par rapport à (divisé par) celle de l'image SDR, à un pixel donné. Il peut s'agir d'un seul Real ou d'un tableau ordonné de Real. Lorsqu'il s'agit d'un tableau ordonné de réels, il peut contenir un élément qui s'applique à tous les canaux ou trois éléments pour les canaux rouge, vert et bleu, respectivement. La valeur doit être inférieure ou égale à hdrgm:GainMapMax. Facultatif. La valeur par défaut est 0,0.
hdrgm:GainMapMax	Tableau réel ou ordonné de réels	Stocke la ou les valeurs de map_max_log2. Il s'agit de log2 de l'amélioration maximale du contenu, qui correspond au ratio maximal autorisé de la luminance linéaire pour la restitution HDR cible par rapport à (divisé par) celle de l'image SDR, à un pixel donné. Il peut s'agir d'un seul Real ou d'un tableau ordonné de Real. Lorsqu'un tableau ordonné de Reals, il peut contenir un élément qui s'applique à tous les canaux ou trois éléments pour les canaux rouge, vert et bleu, respectivement. Doit être supérieur ou égal à hdrgm:GainMapMin. Obligatoire.
hdrgm:Gamma	Tableau réel ou ordonné de réels	Stocke la ou les valeurs de map_gamma. Il s'agit du gamma à appliquer aux valeurs de carte stockées. Il peut s'agir d'un seul Real ou d'un tableau ordonné de Real. Lorsqu'un tableau ordonné de Reals, il peut contenir un élément qui s'applique à tous les canaux ou trois éléments pour les canaux rouge, vert et bleu, respectivement. Doit être supérieur à 0,0. Facultatif. La valeur par défaut est 1.0.
hdrgm:OffsetSDR	Tableau réel ou ordonné de Real	Stocke la ou les valeurs de offset_sdr. Il s'agit du décalage à appliquer aux valeurs de pixel SDR lors de la génération et de l'application de la carte de gain. Il peut s'agir d'un seul nombre réel ou d'un tableau ordonné de nombres réels. Lorsqu'un tableau ordonné de Reals, il peut contenir un élément qui s'applique à tous les canaux ou trois éléments pour les canaux rouge, vert et bleu, respectivement. Doit être supérieure ou égale à 0,0. Facultatif ; la valeur par défaut est 0,015625 (1/64).
hdrgm:OffsetHDR	Tableau réel ou ordonné de Real	Stocke la ou les valeurs de offset_hdr. Il s'agit du décalage à appliquer aux valeurs de pixel HDR lors de la génération et de l'application de la carte de gain. Peut être un seul Real ou un tableau ordonné de Real. Lorsqu'un tableau ordonné de Reals, il peut contenir un élément qui s'applique à tous les canaux ou trois éléments pour les canaux rouge, vert et bleu, respectivement. Doit être supérieure ou égale à 0,0. Facultatif ; la valeur par défaut est 0,015625 (1/64).
hdrgm:HDRCapacityMin	Réelle	Stocke la valeur de hdr_capacity_min. Il s'agit de log2 de la valeur minimale d'amélioration de l'affichage pour laquelle la carte est appliquée. Cette valeur affecte également l'intensité de l'application de la carte de gain en fonction de l'amélioration de l'affichage. Doit être supérieure ou égale à 0,0. Facultatif. La valeur par défaut est 0,0.
hdrgm:HDRCapacityMax	Réelle	Stocke la valeur de hdr_capacity_max. Cela correspond à log2 de la valeur d'optimisation d'affichage maximale à laquelle la carte est entièrement appliquée. Cette valeur affecte également l'intensité de l'application de la carte de gain en fonction de l'amélioration de l'affichage. Doit être supérieur à hdrgm:HDRCapacityMin. Obligatoire.

Conseil : Dans la mesure du possible, n'utilisez qu'une seule valeur réelle pour chaque propriété précédente qui autorise une valeur ou un tableau de valeurs, une pour chaque canal de couleur. Définissez HDRCapacityMax sur GainMapMax et HDRCapacityMin sur la valeur la plus élevée entre GainMapMin et 0,0. Le reste de ce document suppose que vous utilisez une seule valeur réelle pour toutes les propriétés pouvant avoir un tableau de valeurs réelles. Les formules associées à ces propriétés peuvent être extrapolées à chaque canal de couleur, si ce n'est pas le cas en pratique.

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 la carte de gain doit être stockée en tant qu'image supplémentaire, comme 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 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 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 Informations sur GContainer ci-dessous. 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, car elle n'est pas analysable au format 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 ê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'une sortie de luminosité plus élevée.

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 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 celle de l'image principale, encoded_recovery(x, y) est plutôt 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 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.

Remarque :La carte de gain doit être appliquée comme indiqué précédemment (à l'aide d'une exponentielle) pour produire correctement les relations tonales relatives nécessaires (entre les zones de luminosité différente dans l'image) à chaque amélioration de l'affichage souhaitée. Si la carte de gain est appliquée d'une autre manière, par exemple via une interpolation linéaire simple, les relations tonales relatives dans l'image ne sont correctes qu'à la valeur maximale de l'accentuation du contenu et sont compromises pour d'autres facteurs d'accentuation.

La méthode décrite pour récupérer la restitution HDR adaptée signifie que les résultats d'affichage passent de manière transparente à mesure que le boost d'affichage maximal change. Cette méthode produit toujours un résultat d'affichage qui correspond le plus possible à l'intention du créateur de contenu et qui répond à toutes les exigences de qualité d'image énumérées dans la section Motivation.

La quantité d'atténuation appliquée lorsque l'amélioration du contenu minimale est inférieure à 1,0 est également ajustée en fonction de la relation entre l'amélioration de l'affichage maximale et l'amélioration du contenu maximale. Par exemple, si l'optimisation maximale du contenu est de 4,0, l'optimisation minimale du contenu de 0,5 et l'amélioration maximale de l'écran de 2,0, l'atténuation maximale de l'image affichée est de 0,7071, et non de 0,5 si elle est égale ou supérieure à 4.

Détails de GContainer

Cette section spécifie des exigences supplémentaires pour que ce format soit conforme aux métadonnées XML de 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 dans le fichier image principal, comme décrit dans la section Stockage dans les fichiers de la spécification XMP d'Adobe (partie 3). 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 mappage 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 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 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 d'élément multimédia dans le répertoire et doivent être très compacts.

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

Nom de l'élément	Type	Description
Conteneur:répertoire	Tableau ordonné de structures	Tableau ordonné de structures contenant chacune une structure Container:Item définissant la mise en page et le contenu du conteneur.

É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 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 dans 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 d'image 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 est définie sur 0 pour les éléments multimédias partagés suivants. 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é 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.

Nom de l'attribut	Type	Description
Item:Mime	Texte	Chaîne simple indiquant le type MIME de l'élément multimédia dans le conteneur. Pour en savoir plus, consultez la section "Valeurs du type MIME de l'élément". Obligatoire :
Item:Sémantique	Texte	Chaîne simple indiquant la signification spécifique à l'application de l'élément multimédia. Pour en savoir plus, consultez la section "Valeurs sémantiques des articles". Obligatoire :
Item:Longueur	Nombre entier	Chaîne simple contenant un entier positif en octets de l'élément. Une longueur de 0 indique que la ressource d'élément multimédia est partagée avec l'élément multimédia précédent. Obligatoire pour les éléments multimédias secondaires. Facultatif pour l'élément multimédia de l'image principale.
Item:Label	Texte	Chaîne définie par l'implémentation utilisée pour distinguer plusieurs éléments d'élément avec le même Item:Semantic. Facultatif
Élément:Rembourrage	Nombre entier	Chaîne contenant une longueur entière positive en octets de 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, ou la fin du fichier lorsqu'elle est utilisée pour le dernier élément multimédia de l'Container:Directory. Si cet attribut n'est pas renseigné, la valeur 0 est supposée. Facultatif.
Item:URI	Texte	Chaîne d'URI conforme à la section 8.11.9 de la norme ISO/IEC 14496-12, contenant l'URI relatif des données multimédias dans la ressource d'élément multimédia. La valeur par défaut est la ressource d'image principale. Facultatif pour les types MIME du format de fichier multimédia de base ISO/CEI 14496-12. Ne peut être utilisé dans aucun autre cas.

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.

Valeur	Description
image/jpeg	Image JPEG.

Exemple de 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é ISO 21496-1

ISO 21496-1 fournit un autre mécanisme d'encapsulation pour encoder les métadonnées de carte de gain dans un fichier image. Vous pouvez encoder les métadonnées Ultra HDR et ISO 21496-1 dans un même fichier JPEG à l'aide d'une seule image gainmap 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 et les applications Android 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 des 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.

Remarque :Android prend en charge l'encodage ISO 21496-1 et le décodage vers Bitmap pour JPEG à partir d'Android 15 (niveau d'API 35). Android 15 encode à la fois les métadonnées Ultra HDR v1 et les métadonnées ISO 21496-1 lors de l'encodage de fichiers JPEG Ultra HDR à partir d'objets Bitmap. De plus, la bibliothèque libultrahdr d'AOSP est compatible avec l'encodage ISO 21496-1 lorsque l'indicateur approprié est activé.

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 à cette version de la spécification Ultra HDR sont à des fins d'information et concernent la compatibilité avec la norme ISO 21496-1. Aucune modification n'est apportée au format de fichier.

• Ajoutez la section Compatibilité ISO 21496-1.

v1.0

Publication initiale des spécifications Ultra HDR.