Format d'image Ultra HDR v1.1

Introduction

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

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

1. Encodage

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

2. Décodage

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

Motivation

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

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

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

En outre, la technique d'affichage doit:

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

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

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

Dépendances

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

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

Définitions

• Écran SDR

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

• Écran HDR

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

• Image principale

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

• Image secondaire

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

• Compression de plage

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

• Point blanc SDR

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

• Point blanc HDR

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

• Amplifier

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

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

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

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

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

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

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

• Boost sur le Réseau Display

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

• Rendu HDR cible

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

• Rendu HDR adapté

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

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

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

• clamp(x, a, b)

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

• exp2(x)

  • Exposant de base 2 : 2^x.

• floor(x)

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

• log2(x)

  • Logarithme en base 2 : log₂(x)

• pow(b, x)

  • Exponentiation : b^x.

• XMP

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

• Format multi-image

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

• Conteneur Google

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

Encode

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

Génération de cartes plus rapide

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

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

Remarque :Pour illustrer les formules suivantes, ce document suppose que vous utilisez une carte de gain à un seul canal. Si ce n'est pas le cas, les formules lié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 utilisez également des valeurs de métadonnées par canal, 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 principale à trois canaux, obtenue par transformation en une version linéaire de l'espace colorimétrique de l'image principale. (par exemple, d'un espace de couleurs avec une fonction de transfert sRVB à un espace de couleurs linéaire qui préserve les primaires de couleur sRVB).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Conseil : Utilisez une valeur de 0,015625 (1/64) pour offset_sdr et offset_hdr. L'objectif de ces valeurs est d'équilibrer la capacité à augmenter les valeurs proches du noir avec la capacité à encoder précisément 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. Si vous augmentez trop les valeurs, la précision de la carte peut être réduite.

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 lorsque pixel_gain(x, y) est nul. 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 autre valeur 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 présente 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 luminosité souhaitée du rendu HDR (représentée par de grandes valeurs log_recovery(x, y)). Dans ce cas, vous pouvez utiliser une valeur map_gamma supérieure à 1,0 afin que recovery(x, y) puisse encoder précisément les détails à la fois dans la plage basse et dans la plage haute 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. Le boost maximal du contenu doit être supérieur ou égal à 1,0. L'optimisation de contenu minimale doit être comprise dans la plage (0,0, 1,0].

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.

De tels pipelines peuvent choisir une amplification de contenu minimale de 1,0 s'ils ne souhaitent pas encoder d'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 JPEG secondaire et doit donc être encodée à l'aide de valeurs d'entiers non signés de 8 bits, c'est-à-dire dans la plage [0, 255]. Chaque valeur représente une valeur recovery(x, y) et est stockée dans un pixel de l'image secondaire.

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

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

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

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

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 la carte de gain.

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

Conseil :Réduisez la carte de gain à ¹⁄₁₆ de la taille (¼ sur chaque dimension) de l'image principale avant le stockage, par exemple une carte de gain de 480 x 270 pixels pour une image principale de 1 920 x 1 080 pixels. La carte de gain doit avoir un format similaire à 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 sur la conformité générale à GContainer sont spécifiées dans la section Détails de GContainer.

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

Valeurs sémantiques des éléments

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

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 la carte de gain HDR

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

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

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

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. La valeur doit être "False". Facultatif. La valeur par défaut est "False".
hdrgm:GainMapMin	Tableau réel ou ordonné de Real	Stocke la ou les valeurs de map_min_log2. Cela correspond au ratio minimal autorisé de luminance linéaire pour le rendu HDR cible par rapport à (divisé par) celui de l'image SDR, à un pixel donné. Cela correspond à log2 d'optimisation minimale du contenu. 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. 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é. Peut être un seul nombre réel ou un tableau ordonné de nombres réels. 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. 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 de la valeur gamma à appliquer aux valeurs de la carte stockées. Peut être un seul nombre réel ou un tableau ordonné de nombres réels. 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. Doit être supérieur à 0,0. Facultatif ; la valeur par défaut est 1,0.
hdrgm:OffsetSDR	Tableau réel ou ordonné de réels	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'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. Doit être égal ou supérieur à 0,0. Facultatif.La valeur par défaut est 0,015625 (1/64).
hdrgm:OffsetHDR	Tableau réel ou ordonné de réels	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. Il peut s'agir d'un seul nombre réel ou d'un tableau ordonné de nombres réels. 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. Doit être égal ou supérieur à 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 le degré d'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. Il s'agit de log2 de la valeur d'amélioration d'affichage maximale pour laquelle la carte est appliquée complètement. 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 carte de gain doit être stockée en tant qu'image supplémentaire, comme défini dans le format CIPA DC-x 007-2009 Multi-Picture, comme indiqué dans la section Dépendances.

Décoder

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

Signal du format

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

Localiser l'image de la carte de gain

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

Gérer les métadonnées non valides

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

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

Écran

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

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

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

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

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

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

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

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

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

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

weight_factor est déterminé comme suit lorsque hdrgm:BaseRenditionIsHDR est "False" :

unclamped_weight_factor = (log2(max_display_boost) - hdr_capacity_min)
                        / (hdr_capacity_max - hdr_capacity_min)
weight_factor = clamp(unclamped_weight_factor, 0.0, 1.0)

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

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

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

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

log_boost(x, y) = gain_map_min * (1.0f - log_recovery(x, y))
                + gain_map_max * log_recovery(x, y)
HDR(x, y) = (SDR(x, y) + offset_sdr) * exp2(log_boost(x, y) * weight_factor)
          - offset_hdr

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

Remarque :La carte de gain doit être appliquée comme indiqué précédemment (à l'aide de l'exponentiation) pour produire correctement les relations tonales relatives requises (entre les zones de luminosité différente de l'image) à tout renforcement d'affichage souhaité.Si la carte du gain est appliquée d'une autre manière, par exemple via une simple interpolation linéaire, les relations tonales relatives dans l'image ne sont correctes qu'au maximum du contenu et ne sont compromises qu'avec d'autres facteurs d'optimisation.

La méthode décrite pour récupérer le rendu HDR adapté signifie que les résultats d'affichage changent de manière fluide à mesure que l'optimisation maximale de l'affichage change. Cette méthode produit toujours un résultat d'affichage qui correspond le plus précisément possible à l'intention du créateur du 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 du GContainer

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

Exigences concernant les paquets XMP

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

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

Élément de conteneur

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

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

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

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

Nom de l'élément	Type	Description
Container:Directory	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 "Item"

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

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

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

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

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

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

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

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

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 :
Élément: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 :
Élément: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 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:marge intérieure	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. Lorsqu'il n'est pas présent, 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 ressource d'image principale est utilisée par défaut. 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 fichier XMP GContainer

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

<x:xmpmeta xmlns:x="adobe:ns:meta/" x:xmptk="Adobe XMP Core 5.1.2">
  <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
    <rdf:Description
     xmlns:Container="http://ns.google.com/photos/1.0/container/"
     xmlns:Item="http://ns.google.com/photos/1.0/container/item/"
     xmlns:hdrgm="http://ns.adobe.com/hdr-gain-map/1.0/"
     hdrgm:Version="1.0">
      <Container:Directory>
        <rdf:Seq>
          <rdf:li rdf:parseType="Resource">
            <Container:Item
             Item:Semantic="Primary"
             Item:Mime="image/jpeg"/>
          </rdf:li>
          <rdf:li rdf:parseType="Resource">
            <Container:Item
             Item:Semantic="GainMap"
             Item:Mime="image/jpeg"
             Item:Length="66171"/>
          </rdf:li>
        </rdf:Seq>
      </Container:Directory>
    </rdf:Description>
  </rdf:RDF>
</x:xmpmeta>

Compatibilité avec la norme ISO 21496-1

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

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

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

Remarque :Android est compatible avec l'encodage ISO 21496-1 à partir de Bitmap et du 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 dans cette version de la spécification Ultra HDR sont fournies à titre d'information et concernent la compatibilité ISO 21496-1. Aucune modification n'est apportée au format de fichier.

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

v1.0

Publication initiale des spécifications Ultra HDR.