Vidéo iPhone délavée dans DaVinci Resolve : les 2 vraies causes et la correction

Tu as filmé une belle scène avec ton iPhone. Sur l'écran du téléphone, l'image était éclatante : le ciel avait du bleu, les visages avaient de la vie, le contraste claquait. Tu importes le fichier dans DaVinci Resolve, tu le poses sur la timeline… et là, c'est une autre vidéo. Grise. Plate. Comme lavée à l'eau de Javel. Les noirs sont laiteux, les couleurs sont éteintes, et l'image ressemble davantage à un vieux fichier compressé qu'à un plan tourné avec un capteur moderne.

La réaction naturelle, c'est de se dire « je vais remonter le contraste et la saturation, ça va revenir ». C'est exactement ce que j'ai fait la première fois, et c'est exactement l'erreur. Parce que ce que tu vois à l'écran n'est pas une image abîmée : c'est une image mal interprétée. Ton fichier contient plus d'information que ce que Resolve t'affiche — et tant que tu n'as pas corrigé l'interprétation, tout ce que tu ajoutes par-dessus se construit sur du sable.

Et il y a un détail que la plupart des tutoriels ratent : il n'y a pas une cause, il y en a deux, complètement distinctes, qui se cumulent. La première concerne l'espace colorimétrique (ton iPhone filme en HDR par défaut). La seconde concerne la plage de données (l'échelle de valeurs dans laquelle le signal est encodé). Corriger l'une sans l'autre, c'est obtenir une image « presque bonne » sans jamais comprendre pourquoi ça coince encore.

Dans cet article, je t'explique ce que ton iPhone enregistre réellement, pourquoi Resolve l'affiche comme ça, et les trois chemins de correction possibles — au niveau du projet, au niveau du plan, ou directement au tournage. Le tout 100 % avec les outils natifs de DaVinci Resolve : pas un plugin, pas un LUT à acheter, pas un « pack magique » à télécharger.

Allez, c'est parti 😄

L'iPhone filme HDR

Commençons par le fait qui explique presque tout, et que beaucoup de vidéastes découvrent après des mois de galère : sur les modèles compatibles, ton iPhone enregistre en HDR par défaut. Ce n'est pas une option que tu as activée par mégarde dans un sous-menu. C'est le réglage d'usine.

Apple le documente noir sur blanc dans son support : certains modèles d'iPhone et d'iPad enregistrent la vidéo en Dolby Vision HDR, et pour vérifier que ton appareil est bien réglé ainsi, il faut aller dans Réglages → Appareil photo → Enregistrement vidéo et regarder l'état de l'option HDR vidéo. Le format exact décrit par Apple est du Dolby Vision Profile 8.4 avec un identifiant de rétro-compatibilité correspondant au HLG, encodé avec un codec HEVC 10 bits. Apple recommande d'ailleurs, pour la meilleure qualité, d'exporter un master HLG ou de partager vers des appareils Apple avec le codec vidéo réglé sur HEVC 10 bits.

Traduisons ça en français courant. Ton iPhone ne produit pas un fichier vidéo « normal » en Rec.709 comme une caméra grand public d'il y a dix ans. Il produit un fichier dont la couche de base est du HLG — un standard HDR — avec une couche Dolby Vision par-dessus. Et c'est cette couche de base HLG que lisent les logiciels de montage et les sondes d'analyse de fichiers.

J'ai voulu vérifier ça sur mes propres rushes plutôt que de te répéter une info trouvée sur un forum. J'ai passé une sonde d'analyse sur l'intégralité des fichiers vidéo d'un iPhone 16 Pro que j'avais sous la main : 96 fichiers sur 96 ressortaient en HLG / Rec.2020, avec la couche Dolby Vision. Pas un seul fichier en Rec.709 classique. Autrement dit : si tu filmes à l'iPhone sans avoir touché aux réglages, la question n'est pas « est-ce que mes rushes sont en HDR ? », mais « qu'est-ce que je fais de ce HDR ».

Et c'est là que le malentendu naît. Ton téléphone, lui, sait qu'il a filmé en HDR : il affiche ses propres vidéos avec l'interprétation qui va bien, sur un écran conçu pour. DaVinci Resolve, en revanche, travaille par défaut dans une timeline pensée pour le standard de diffusion classique, le Rec.709. Poser un fichier HLG/Rec.2020 dans un environnement Rec.709 sans conversion, c'est comme lire un texte en admettant qu'il est écrit dans une langue qu'il ne parle pas : les lettres sont bien là, mais le sens se perd.

Les 2 causes

Maintenant que tu sais ce que contient ton fichier, on peut nommer précisément les deux mécanismes qui te donnent cette image délavée. Ils sont indépendants l'un de l'autre, ils n'ont pas les mêmes symptômes, et ils ne se corrigent pas au même endroit. C'est le point que la majorité des contenus sur le sujet ratent : ils en traitent un, obtiennent une amélioration partielle, et concluent que « ça marche à peu près ».

Cause n°1 — l'espace colorimétrique. Ton fichier est encodé en HLG dans un gamut Rec.2020, c'est-à-dire une courbe de transfert HDR et une palette de couleurs très large. Affiché tel quel dans une timeline Rec.709 sans conversion, ça donne une image plate et désaturée : le contraste semble aplati sur toute la hauteur, les couleurs paraissent tièdes, et l'ensemble a un air « brumeux ». C'est le symptôme dominant, celui que tu remarques en premier.

Cause n°2 — la plage de données. Indépendamment de l'espace colorimétrique, chaque fichier vidéo encode ses valeurs dans une échelle numérique donnée. Il en existe deux grandes familles, et si Resolve interprète ton fichier dans la mauvaise, le résultat est un contraste écrasé avec des noirs laiteux et des blancs qui n'atteignent jamais le blanc (ou, dans l'autre sens, des noirs bouchés et des hautes lumières cramées). C'est un symptôme plus discret, souvent confondu avec un problème d'exposition — et c'est précisément celui qu'on corrige à tort « à la main » en tirant sur les curseurs.

La confusion entre les deux est le vrai piège. Si tu ne corriges que l'espace colorimétrique, tes couleurs reviennent mais tes noirs restent gris. Si tu ne corriges que la plage de données, ton contraste revient mais l'image garde une saturation étrange et des hautes lumières qui se comportent bizarrement. Dans les deux cas, tu attribues le reste du problème à « l'iPhone qui filme mal », et tu passes à autre chose avec une image en dessous de ce qu'elle pouvait être.

Le réflexe à prendre, c'est donc de diagnostiquer avant de corriger : est-ce que mon image est fade (couleurs éteintes, tout est mou) ou est-ce qu'elle est écrasée (noirs gris, blancs qui plafonnent) ? Souvent, la réponse est « les deux » — et ça tombe bien, parce que les deux se corrigent en natif dans DaVinci Resolve.

L'espace colorimétrique

Entrons dans le détail de la première cause, parce que c'est celle qui produit l'effet « délavé » le plus visible, et parce que la comprendre change complètement la façon dont tu abordes la correction.

Un espace colorimétrique, c'est la combinaison de deux choses : un gamut (l'étendue des couleurs représentables) et une courbe de transfert (la façon dont les valeurs numériques se traduisent en luminosité à l'écran). Le Rec.709, standard historique de la télévision haute définition et de la vidéo web, a un gamut relativement restreint et une courbe conçue pour des écrans SDR. Le HLG en Rec.2020, lui, a un gamut beaucoup plus large et une courbe HDR.

Ce qui rend le HLG particulier — et ce qui explique la forme précise du problème que tu observes —, c'est sa construction. Le manuel de référence de Blackmagic Design le décrit clairement : la courbe HLG se comporte de façon très proche de la courbe SDR classique (BT.1886) sur la partie basse du signal, environ de 0 à 0,6 de l'amplitude, puis bascule progressivement en encodage logarithmique pour les hautes lumières. L'objectif affiché par ses concepteurs était d'offrir « un certain degré de compatibilité avec les écrans existants », en collant au plus près des courbes de transfert historiques de la télévision.

Conséquence directe pour toi : quand tu envoies un signal HLG sur un écran SDR sans conversion, la partie basse de l'image (ombres et tons moyens) reste à peu près lisible — elle ne part pas complètement en vrille —, mais les hautes lumières sont compressées de façon logarithmique et n'ont plus rien à voir avec ce qu'elles devraient être. Voilà pourquoi ton plan n'est pas illisible : il est simplement fade. Les ombres tiennent debout, les hautes lumières sont tassées, la saturation semble avoir disparu. C'est un symptôme extrêmement caractéristique, et une fois que tu l'as identifié une fois, tu le reconnais au premier coup d'œil.

À ça s'ajoute la question du gamut. Le Rec.2020 est nettement plus large que le Rec.709. Quand une image encodée dans un gamut large est affichée sans conversion dans un environnement au gamut plus étroit, les couleurs ne « débordent » pas comme on pourrait l'imaginer : elles se retrouvent au contraire ramenées vers l'intérieur, ce qui se traduit visuellement par une saturation qui semble avoir fondu. Ton bleu de ciel devient bleu-gris, ton vert de feuillage devient kaki.

La correction ne consiste donc jamais à « remonter la saturation ». Elle consiste à effectuer une conversion : dire à DaVinci Resolve que la source est en HLG / Rec.2020 et que la destination est en Rec.709, puis laisser le logiciel appliquer le remappage mathématique adéquat — le mappage de luminance pour la courbe, le mappage de la saturation pour le gamut. Ce sont deux opérations distinctes, et Resolve sait faire les deux, nativement.

La fiche mémo Le HDR

Garde sous la main les repères essentiels du HDR (gamut, courbe, compatibilité) pour comprendre ce que ta caméra ou ton téléphone enregistre vraiment.

Télécharger la fiche →

Plages 10 bits

Passons à la seconde cause, la plus technique — et celle qui contient le vrai moat de cet article, parce que la quasi-totalité des contenus qui l'abordent le font avec des chiffres qui ne correspondent pas à ton fichier.

Une image numérique encode chaque composante dans une plage de valeurs. En 10 bits, l'étendue théorique va de 0 à 1023. Mais tous les fichiers n'utilisent pas cette étendue de la même façon. Le manuel de référence de DaVinci Resolve décrit précisément les deux conventions en usage :

• Plage vidéo — typique des données vidéo Y'CbCr. Toute l'information d'image de 0 à 100 % doit tenir dans l'intervalle 64–940 pour la composante Y', et 64–960 pour les composantes CB et CR. L'intervalle bas 4–63 est réservé au « plus noir que le noir », et les intervalles hauts 941/961–1019 au « super-blanc ». Ces valeurs hors limites existent bel et bien dans les fichiers sources, sous forme de dépassements haut et bas, mais elles ne sont pas acceptables pour une diffusion broadcast.
• Plage pleine — typique des données RVB 4:4:4 issues de caméras de cinéma numérique ou de scans film. Toute l'information de 0 à 100 % occupe simplement l'intervalle complet 4 à 1023.

Quand un média encodé dans une plage est converti vers l'autre, chaque composante est remappée linéairement : le minimum de l'ancienne plage est mis à l'échelle du minimum de la nouvelle, et le maximum de l'ancienne à l'échelle du maximum de la nouvelle. Le manuel écrit l'équivalence noir sur blanc : 64 (minimum plage vidéo) = 4 (minimum plage pleine) et 940 ou 960 (maximum plage vidéo) = 1023 (maximum plage pleine).

Maintenant, imagine ce qui se passe si l'interprétation est fausse. Si un fichier encodé en plage pleine est lu comme s'il était en plage vidéo, tout ce qui vivait entre 4 et 63 se retrouve traité comme du « plus noir que le noir » — donc affiché à un niveau supérieur au vrai noir — et tout ce qui vivait entre 941 et 1023 se retrouve traité comme du « super-blanc ». Résultat visuel : des noirs laiteux qui ne descendent jamais, des blancs qui plafonnent avant l'heure, un contraste écrasé. Exactement le second symptôme décrit plus haut.

Et voilà le point que je tiens à corriger, parce qu'il circule partout de travers : la plupart des explications que tu trouveras en ligne parlent de « plage pleine 0-255 contre plage vidéo 16-235 ». Ces chiffres-là sont ceux du 8 bits. Or ton iPhone encode en HEVC 10 bits. Les chiffres qui te concernent réellement sont ceux du tableau ci-dessus : 64–940, 64–960, 4–63, 941/961–1019, 4–1023. Le raisonnement est le même, mais si tu cherches à comprendre ce que tu lis sur tes scopes, ce sont ces valeurs-là qu'il faut avoir en tête.

Une nuance importante, et rassurante : quand Resolve écrête ces valeurs hors limites, il ne les détruit pas. Le manuel est explicite — DaVinci Resolve conserve ces données en interne, et les pixels de détail écrêtés dans les dépassements haut et bas restent récupérables en effectuant les ajustements appropriés depuis la page Étalonnage, pour les ramener dans la plage « légale ». L'écrêtage définitif n'intervient qu'à la sortie vidéo ou au rendu — et le manuel décrit deux cases à cocher (une côté monitoring, une côté rendu) qui permettent justement de conserver ces sous-noirs et ces sur-blancs à l'export.

La chaîne couleur

Pour choisir le bon chemin de correction, il faut avoir en tête où chacun de ces deux problèmes se situe dans la chaîne de traitement de DaVinci Resolve. C'est la section un peu « coulisses » de cet article, mais c'est elle qui fait que tu ne te tromperas plus d'outil.

Concrètement, ton image traverse trois étages successifs.

Étage 1 — l'entrée. Au moment où un fichier arrive dans la Bibliothèque de médias, Resolve lui attribue une interprétation. Il décide comment lire ses valeurs numériques (la plage de données) et, si la gestion de la couleur est activée, dans quel espace colorimétrique il considère qu'il a été tourné. Le manuel précise que le réglage de niveaux attribué par défaut est le mode automatique, et que dans ce mode l'interprétation retenue est déterminée d'après le codec du média source. Il ajoute que Resolve fait généralement du bon travail tout seul, mais que dans certaines circonstances — typiquement des médias créés dans un format puis transcodés dans un autre — il peut être nécessaire de choisir manuellement le réglage adéquat.

Étage 2 — l'espace de travail. C'est la timeline, l'endroit où tu montes et où tu étalonnes. Toute la question est de savoir si ce que tu vois dans le viewer correspond à une interprétation juste de la source. Si l'étage 1 s'est trompé, tout ce que tu construis à l'étage 2 compense une erreur au lieu de créer une intention.

Étage 3 — la sortie. C'est la page Exportation. Là, Resolve reconvertit vers ce que tu as demandé : un espace colorimétrique de sortie, une plage de données de sortie. Et c'est ici, et seulement ici, que les valeurs hors limites conservées en interne sont réellement écrêtées.

Le principe qui doit guider ta décision est simple : on corrige un problème d'interprétation à l'étage où il naît, jamais à l'étage d'après. Un fichier mal interprété à l'entrée ne se répare pas par un coup de contraste dans la timeline — ça peut ressembler à une réparation, mais tu as juste maquillé une erreur, et tu la paieras au raccord entre deux plans ou à l'export.

C'est aussi pour cette raison que je te déconseille de commencer par étaler des corrections créatives sur un plan iPhone. Tant que l'interprétation n'est pas juste, tu n'étalonnes pas : tu bricoles. Si tu veux la logique complète de l'ordre des opérations, je l'ai détaillée dans mon guide de l'étalonnage dans DaVinci Resolve pour débuter.

Corriger au projet

Premier chemin, et celui que je recommande par défaut si tu as plusieurs plans iPhone dans ton montage : régler la question au niveau du projet, via la gestion de la couleur de DaVinci Resolve.

Le réglage qui commande tout ça s'appelle Gestion de la couleur, en haut du panneau de gestion de la couleur des paramètres du projet. Il propose plusieurs modes, dont le mode historique de Resolve et le mode DaVinci YRGB Color Managed. Le premier fonctionne en « display referred » : Resolve n'a aucune information sur l'apparence attendue de tes médias, et c'est toi, avec ton écran, qui fait office de gestion de la couleur. Le second, introduit avec Resolve 12, fonctionne en « scene referred » : tu associes à chaque type de média un profil colorimétrique qui indique à Resolve comment représenter ses couleurs dans l'espace de travail commun de la timeline.

C'est exactement ce qu'il te faut pour du HLG. Tu dis à Resolve « ce plan vient d'un appareil qui filme en HLG », et il s'occupe du remappage vers ta timeline.

Le manuel décrit une voie simplifiée particulièrement adaptée à ton cas : la Gestion de la couleur automatique. Quand cette case est cochée, Resolve présente un jeu d'options réduit pour les usages les plus courants. Tu choisis simplement, pour le Mode de traitement de la couleur, entre SDR et HDR, et — je cite la logique du manuel — en fonction des types de fichiers et des codecs présents dans la Bibliothèque de médias, DaVinci Resolve choisit automatiquement l'espace colorimétrique source approprié. Il ne te reste plus qu'à sélectionner l'espace colorimétrique de sortie correspondant à ta livraison.

Pour une vidéo destinée à YouTube ou à un site web, tu vises une sortie SDR Rec.709 — c'est d'ailleurs le préréglage par défaut de la gestion de la couleur de Resolve, décrit dans le manuel comme mettant en place un environnement d'étalonnage Rec.709 SDR, adapté à la diffusion et au streaming conventionnels. Si tu veux garder la main, tu décoches la gestion automatique et tu vas chercher toi-même l'espace colorimétrique source de tes plans.

Ce que fait Resolve quand il convertit du HDR vers du SDR n'a rien de magique, et le manuel donne même les règles chiffrées. En passant du HDR au SDR : la zone de 0 à 50 nits (qui contient le gris moyen à 18 %) est reportée telle quelle de 0 à 50 nits, sans changement ; tout ce qui se situe entre 51 et 100 nits est remappé sur la plage 51-90 nits, donc légèrement comprimé ; et tout ce qui se situe entre 101 et 1000 nits est remappé sur la plage 91-100 nits, donc fortement comprimé. Voilà, en chiffres, ce que « mappage de luminance » veut dire : tes hautes lumières HDR sont repliées dans le peu de place que leur laisse le SDR.

Le manuel ajoute un avertissement que je reprends volontiers à mon compte : ces méthodes de conversion constituent un excellent point de départ, mais elles ne sont pas censées être une solution automatique — il est essentiel de faire une passe de vérification plan par plan quand on sort dans un nouvel espace colorimétrique.

Une variante existe, et c'est celle que j'utilise personnellement sur mes projets : faire la conversion nœud par nœud plutôt qu'au niveau du projet, avec un effet de conversion d'espace colorimétrique posé en tête de l'Arbre des nœuds — c'est celui qui porte les réglages Mappage de luminance et Mappage de la saturation. L'idée reçue voudrait que ce soit « moins bien » que la gestion de la couleur du projet. C'est faux : la gestion de la couleur de Resolve s'appuie en interne sur ces mêmes conversions. Ce n'est donc pas un choix de qualité, c'est un choix de contexte — global et automatique d'un côté, transparent et modifiable plan par plan de l'autre.

Si tu veux le détail complet de ce panneau et des préréglages, j'ai écrit un article dédié : la gestion des couleurs dans DaVinci Resolve, guide pratique.

Corriger au plan

Deuxième chemin : intervenir au niveau d'un plan précis, pour corriger l'interprétation de sa plage de données. C'est le geste qui règle les noirs laiteux et le contraste écrasé quand la gestion de la couleur du projet n'a pas suffi.

Avant de te décrire la manipulation, une mise au point honnête sur le vocabulaire, parce que c'est important pour moi et parce que ça t'évitera de chercher un menu qui n'existe pas. Mon manuel de référence Blackmagic est en anglais. Certains libellés de l'interface française de DaVinci Resolve, je les ai vérifiés à l'écran — et je te les donne alors tels quels. D'autres, non — et dans ce cas je te décris la manipulation par sa fonction, sans inventer une traduction. C'est le cas ici : je ne te donnerai pas le nom français exact de la fenêtre ni des trois options concernées, parce que je ne les ai pas vérifiés dans une interface française. Tu les reconnaîtras sans peine, et tu ne chercheras pas un libellé fantôme dans ton logiciel.

Voici donc la logique, telle que la décrit le manuel. Chaque plan de la Bibliothèque de médias possède un réglage de niveaux qui détermine la façon dont ses valeurs sont mises à l'échelle. Ce réglage vit dans la fenêtre d'attributs du plan, accessible par le menu contextuel (clic droit) de la Bibliothèque de médias, depuis la page Média ou la page Montage. Trois choix y sont proposés : une interprétation automatique, une interprétation en plage vidéo, une interprétation en plage pleine. La procédure décrite par le manuel tient en trois gestes : sélectionner un ou plusieurs plans, faire un clic droit et ouvrir les attributs du plan, puis cliquer sur le bouton correspondant au réglage de niveaux voulu et valider.

Quand tu changes ce réglage, le manuel précise que le plan est automatiquement reconverti selon la nouvelle attribution. Autrement dit, tu vois le résultat immédiatement dans le viewer. Et le manuel donne le critère de décision le plus honnête qui soit : si le résultat te paraît correct, tu peux travailler ; s'il ne l'est pas, tu reconsidères ton attribution, et le cas échéant tu te renseignes sur la façon dont le média a été généré, capturé et exporté.

Il y a une astuce du manuel que je trouve précieuse et que peu de gens connaissent : si tu dois modifier ce réglage sur une série de plans qui partagent une propriété commune — nom de bobine, résolution, cadence, chemin de fichier —, tu peux afficher la Bibliothèque de médias en mode colonnes et trier par la colonne qui isole le mieux la série concernée. Sur un tournage iPhone avec 80 rushes, ça change une corvée en manipulation de dix secondes.

Une remarque de méthode pour finir. Ce réglage-là est un réglage d'interprétation, pas un réglage créatif. Il n'y a pas de « bonne valeur » universelle : la bonne valeur est celle qui correspond à la façon dont le fichier a réellement été encodé. C'est pour ça que le test visuel immédiat est légitime ici, alors qu'il ne le serait pas pour une correction esthétique : tu ne cherches pas ce qui est joli, tu cherches ce qui est juste.

Corriger au tournage

Troisième chemin, et le plus radical : ne pas créer le problème. Si tu sais que tes rushes iPhone finiront dans un montage destiné au web, tu peux demander à ton téléphone de ne pas filmer en HDR.

Apple documente ce réglage dans son support : il se trouve dans Réglages → Appareil photo → Enregistrement vidéo, sous l'intitulé HDR vidéo. Apple présente ce chemin comme la façon de vérifier que ton appareil est bien réglé pour enregistrer en HDR — c'est donc aussi le même endroit pour le désactiver.

Ce que tu y gagnes est immédiat : des fichiers qui arrivent dans DaVinci Resolve sans réclamer de conversion d'espace colorimétrique, un workflow plus simple, et zéro surprise au moment de l'export. Pour un vidéaste qui filme des interviews, du tutoriel, de la vidéo de famille ou du contenu YouTube en SDR, c'est un choix parfaitement défendable — et c'est celui que je conseille à beaucoup de gens qui me disent perdre plus de temps à corriger qu'à monter.

Mais je dois être honnête sur ce que ça coûte, parce que ce n'est pas un choix neutre. En désactivant le HDR, tu renonces à la latitude que la capture HDR t'offrait. Les scènes très contrastées — un sujet en intérieur devant une fenêtre lumineuse, un coucher de soleil, une rue à l'ombre avec un ciel éclatant — sont précisément celles où la capture HDR conserve du détail que le SDR jette. Une fois l'information absente du fichier, aucune correction ne la fera revenir.

Le compromis se pose donc ainsi. Si tu tournes surtout en lumière maîtrisée et que tu livres en SDR, désactiver le HDR te simplifie la vie sans rien te coûter de réel. Si tu tournes en extérieur, en lumière difficile, ou que tu veux garder la porte ouverte à une livraison HDR un jour, garde le HDR et corrige au montage — c'est un peu plus de travail, et tu conserves le maximum d'information.

Une chose que je précise toujours, parce que la confusion est fréquente : filmer en HDR ne rend pas ton image « meilleure » en soi. Ça change ce que le fichier contient. Un plan HDR mal converti sera toujours moins bon qu'un plan SDR bien exposé. Le HDR est une réserve, pas un label de qualité.

Et si tu veux travailler tes fondamentaux de tournage au téléphone, j'ai un article complet sur le sujet : comment filmer avec son téléphone.

Quel chemin choisir

Tu as maintenant trois leviers à trois niveaux différents : le projet, le plan, le tournage. Voici comment je choisis, selon la situation.

La règle de bon sens, si tu ne devais retenir qu'une ligne : quand le problème concerne tous tes plans, corrige au projet ; quand il concerne un plan, corrige sur le plan ; quand il va concerner tous tes tournages à venir, corrige à la caméra.

Vérifier aux scopes

Il te manque encore une chose pour être vraiment autonome sur ce problème : un moyen de vérifier que ta correction est juste, autrement qu'en te disant « ouais, ça me paraît mieux ». Parce que le piège de ce sujet précis, c'est qu'une image « moins délavée » n'est pas forcément une image juste.

Les scopes sont là pour ça. Ils analysent les valeurs numériques réelles de ton image, indépendamment de ce que ton écran affiche et de ce que ton œil croit voir. Sur ce problème-là, deux lectures t'intéressent en priorité.

La forme d'onde, d'abord, pour la question de la plage de données. Tu regardes où se pose le bas de la courbe et où se pose le haut. Sur une image délavée par une mauvaise interprétation de plage, tu verras typiquement une masse qui ne descend jamais jusqu'en bas du graphique et qui ne monte jamais jusqu'en haut : le signal « flotte » au milieu. Après correction, l'amplitude s'étale de nouveau. C'est un contrôle objectif, immédiat, qui ne dépend d'aucun jugement esthétique.

La parade RVB, ensuite, pour la question de l'espace colorimétrique. Tu compares la hauteur relative des trois canaux au même niveau de luminosité. Une conversion HLG mal faite laisse souvent une signature reconnaissable : des canaux qui divergent dans les hautes lumières alors qu'ils étaient alignés dans les ombres.

Une précision utile pour lire correctement ces graphiques dans le contexte de cet article : par défaut, l'échelle numérique de la forme d'onde et de la parade RVB reflète les données 10 bits en pleine plage, de 0 à 1023. C'est précisément l'échelle dans laquelle sont exprimés les chiffres que je t'ai donnés plus haut — 64, 940, 960, 1023. Tu peux donc les vérifier directement à l'œil sur le scope.

Si les scopes sont encore un terrain flou pour toi, je leur ai consacré un guide complet : lire les scopes dans DaVinci Resolve. C'est, à mon avis, la compétence qui change le plus de choses quand on débute en étalonnage — bien avant n'importe quel réglage exotique.

En tant que Partenaire Miss Numérique, je perçois une commission sur les achats effectués via ce lien, sans surcoût pour toi.

La fiche mémo Le Signal Vidéo

Les repères essentiels du signal vidéo — niveaux, plages, lecture — à garder à portée de main quand tu contrôles une image.

Télécharger la fiche →

Sans plugin payant

Je veux m'arrêter une minute sur un point qui n'est pas technique mais qui compte, parce que c'est ce que tu vas trouver en premier si tu cherches ce problème en anglais.

La réponse la plus visible en ligne à « vidéo iPhone délavée » consiste à te vendre — ou à t'offrir contre un pourboire — un fichier de conversion tout fait à appliquer sur tes plans. Ça « marche », au sens où l'image change et paraît meilleure. Mais ça te laisse dans une position que je trouve mauvaise pour toi : tu ne sais toujours pas ce qui s'est passé, tu dépends d'un fichier que tu n'as pas produit, et le jour où ton téléphone change, ou où tu montes une source différente, tu es de nouveau bloqué.

Or absolument tout ce que je viens de décrire est déjà dans DaVinci Resolve. La gestion de la couleur est un panneau des paramètres du projet. Le réglage de niveaux d'un plan est dans le menu contextuel de la Bibliothèque de médias. La conversion d'espace colorimétrique nœud par nœud est un effet fourni. Tu n'as rien à acheter, rien à installer, rien à télécharger. Et c'est mathématiquement identique, voire plus précis, puisque tu appliques la conversion qui correspond réellement à ta source plutôt qu'un réglage moyen conçu pour un autre modèle de téléphone.

Il y a un usage technique parfaitement légitime des fichiers de conversion — convertir un profil logarithmique de caméra, calibrer un retour moniteur sur un tournage. Ça n'a rien à voir avec le fait d'acheter un « look » pour masquer un problème d'interprétation. La différence est simple : dans un cas tu convertis en connaissance de cause, dans l'autre tu maquilles sans savoir.

Mon parti pris, sur ce site comme sur ma chaîne, c'est celui-là : je préfère t'expliquer pourquoi ton image se comporte comme ça, quitte à ce que ce soit un peu plus long à lire, plutôt que de te donner un raccourci qui te laisse dépendant.

5 mythes

Voici les cinq explications que je vois circuler le plus souvent sur ce problème, et pourquoi aucune ne tient.

Mythe 1 — « C'est le codec HEVC qui abîme l'image. » Non. Le codec, c'est le contenant : la façon dont les données sont compressées et rangées dans le fichier. Il ne décide ni de l'espace colorimétrique, ni de l'interprétation de la plage. Ton problème est un problème d'interprétation, pas de compression. La preuve : la même correction fonctionne quel que soit le débit du fichier.

Mythe 2 — « Il faut acheter un fichier de conversion pour régler ça. » Non, et c'est même contre-productif. La conversion HLG vers Rec.709 est une opération native de DaVinci Resolve, exposée à deux endroits (les paramètres du projet, l'arbre des nœuds). Un fichier tiers appliquera une conversion générique là où le logiciel peut appliquer la conversion exacte.

Mythe 3 — « Mon téléphone filme mal. » C'est l'inverse. Ton iPhone a enregistré plus d'information que ce que ta timeline en affiche par défaut : un gamut plus large, une courbe HDR, du 10 bits. L'image plate n'est pas un manque de données, c'est un excès de données mal restituées. Et rappelle-toi que le manuel de Resolve le dit lui-même : le logiciel préserve en interne les valeurs hors limites, elles restent récupérables depuis la page Étalonnage.

Mythe 4 — « Il suffit de monter le contraste et la saturation. » C'est le mythe le plus coûteux, parce qu'il donne l'illusion de fonctionner. En poussant ces curseurs, tu ne rétablis pas la conversion : tu en fabriques une, à l'aveugle, non linéaire, différente sur chaque plan. Le jour où tu mets deux plans côte à côte, ils ne raccordent pas — et tu ne sais pas pourquoi. Une conversion, c'est une opération déterministe ; un coup de saturation, c'est une opinion.

Mythe 5 — « C'est un bug de DaVinci Resolve. » Non. Resolve applique une interprétation par défaut, documentée, prévisible : en mode automatique, le réglage de niveaux est déterminé d'après le codec du média source. Le manuel indique explicitement que ça fonctionne bien dans la majorité des cas, mais qu'il peut être nécessaire de choisir manuellement le réglage adéquat pour certains médias. Ce n'est pas une défaillance, c'est un réglage qui t'attend.

Un bonus, parce qu'il revient souvent : « ça vient de mon écran ». Ton écran peut effectivement fausser ton jugement, et c'est une vraie question. Mais il ne fabrique pas le symptôme précis dont on parle ici. Le test est immédiat : si la forme d'onde montre un signal qui ne descend pas au noir et ne monte pas au blanc, le problème est dans le fichier ou son interprétation, pas dans la dalle.

Exporter sans surprise

Dernière étape, et pas la moins traître : il serait dommage d'avoir tout corrigé pour perdre le bénéfice à l'export.

Sur la page Exportation, les paramètres de rendu contiennent un réglage de plage de données de sortie. Le manuel décrit trois options : un mode automatique, dans lequel la plage de sortie de tous les plans est déterminée d'après le codec choisi pour le rendu ; un mode plage vidéo, où tous les plans sont rendus à l'échelle normale pour la vidéo (10 bits, 64–940) ; et un mode pleine plage. Et le manuel donne sa recommandation sans détour : pour la plupart des projets, laisser ce réglage sur automatique donnera le résultat approprié.

Autrement dit : dans la très grande majorité des cas, tu n'as rien à faire ici. Le mode plage pleine est utile quand tu prépares un fichier destiné à une autre application de traitement d'image — un logiciel de compositing, par exemple — capable de lire correctement de la pleine plage. Le manuel insiste d'ailleurs sur le point critique : il est essentiel que l'application qui recevra ce média soit réglée pour le lire en pleine plage, sinon les images ne s'afficheront pas correctement. Pour une livraison YouTube, tu n'as aucune raison d'y toucher.

Deux réflexes de contrôle avant de lancer ton rendu. Premièrement, vérifie ta forme d'onde sur deux ou trois plans représentatifs : le signal doit occuper l'amplitude sans être écrasé ni écrêté. Deuxièmement, souviens-toi que c'est au moment du rendu que les valeurs hors limites conservées en interne par Resolve sont réellement écrêtées — si tu tenais à des détails qui vivaient dans les sur-blancs, c'est avant l'export qu'il fallait les ramener dans la plage légale, depuis la page Étalonnage.

Si tu veux le détail complet des réglages d'export, je l'ai traité à part dans mon article sur l'export d'une vidéo en 4K dans DaVinci Resolve.

Conclusion

Ta vidéo d'iPhone n'est pas délavée parce que ton téléphone filme mal, ni parce que DaVinci Resolve est capricieux. Elle est délavée parce que deux interprétations se sont mises de travers, et parce qu'elles se cumulent.

Pour récapituler : ton iPhone enregistre en HDR par défaut, avec une couche de base HLG en HEVC 10 bits. Première cause, l'espace colorimétrique — du HLG en Rec.2020 affiché dans une timeline Rec.709 sans conversion donne une image fade, aux hautes lumières tassées. Seconde cause, la plage de données — une interprétation qui ne correspond pas à l'encodage réel du fichier donne des noirs laiteux et un contraste écrasé, avec les repères 10 bits 64–940, 64–960 et 4–1023 comme grille de lecture. Et trois leviers pour corriger : la gestion de la couleur du projet, le réglage de niveaux d'un plan, ou la désactivation du HDR au tournage si tu acceptes d'en perdre la latitude.

Le fil rouge, s'il n'en reste qu'un : on corrige une erreur d'interprétation là où elle naît, pas en la maquillant deux étages plus loin. Le jour où tu tiens ce réflexe, tu ne le tiens pas seulement pour l'iPhone — tu le tiens pour n'importe quelle source qui te tombera entre les mains.

Si tu veux transformer ces repères en une méthode d'étalonnage complète et reproductible, j'ai construit un Kit Étalonnage gratuit qui te donne le cadre de travail pas à pas. Et si tu préfères voir tout ça appliqué en vidéo, sur un vrai plan, du début à la fin, j'ai publié une masterclass complète sur ma chaîne : la formation gratuite pour apprendre l'étalonnage dans DaVinci Resolve.

Récupère ton Kit Étalonnage gratuitement

FAQ

Pourquoi ma vidéo iPhone est-elle grise et délavée dans DaVinci Resolve ?

Parce que ton iPhone enregistre en HDR par défaut sur les modèles compatibles : Apple documente un format Dolby Vision Profile 8.4 rétro-compatible HLG, en HEVC 10 bits. Affiché sans conversion dans une timeline pensée pour le Rec.709, ce signal HLG paraît plat et désaturé. À cela peut s'ajouter une interprétation de plage de données qui ne correspond pas à l'encodage réel du fichier, ce qui écrase le contraste et laisse les noirs gris.

Faut-il désactiver le HDR sur l'iPhone pour monter dans DaVinci Resolve ?

Ce n'est pas obligatoire, c'est un arbitrage. Le réglage se trouve dans Réglages → Appareil photo → Enregistrement vidéo → HDR vidéo. En le désactivant, tes fichiers arrivent directement exploitables et ton workflow se simplifie, mais tu perds définitivement la latitude que la capture HDR offrait dans les scènes très contrastées. Si tu filmes surtout en lumière maîtrisée et que tu livres en SDR, c'est un choix parfaitement défendable.

Un LUT gratuit ou payant règle-t-il le problème ?

Il le masque plus qu'il ne le règle. La conversion d'un signal HLG vers du Rec.709 est une opération native de DaVinci Resolve, disponible à la fois dans la gestion de la couleur des paramètres du projet et sous forme d'effet de conversion à poser dans l'arbre des nœuds. Un fichier tiers applique une conversion générique, conçue pour une autre source que la tienne, et te laisse dépendant d'un réglage que tu ne maîtrises pas. Tu n'as rien à acheter.

Quelle est la différence entre plage vidéo et plage pleine ?

Ce sont deux conventions d'encodage des valeurs. En 10 bits, la plage vidéo fait tenir toute l'information de 0 à 100 % dans l'intervalle 64–940 pour la luminance (64–960 pour les composantes de chrominance), en réservant 4–63 aux valeurs « plus noires que le noir » et 941/961–1019 au super-blanc. La plage pleine, elle, occupe simplement l'intervalle 4 à 1023. Lors d'une conversion, le remappage est linéaire : 64 devient 4, et 940 ou 960 devient 1023.

Mes couleurs sont revenues mais mes noirs restent laiteux, pourquoi ?

Parce que tu as corrigé la première cause (l'espace colorimétrique) sans corriger la seconde (la plage de données). C'est le scénario le plus fréquent, et c'est précisément pour ça qu'il faut traiter les deux séparément. Vérifie l'interprétation de niveaux du plan concerné depuis le menu contextuel de la Bibliothèque de médias : le plan est reconverti immédiatement, tu vois le résultat tout de suite dans le viewer.

Est-ce que je perds de la qualité en convertissant du HLG vers du Rec.709 ?

Tu perds nécessairement de la dynamique, puisque le Rec.709 ne peut pas contenir tout ce que le HDR contenait — le manuel de Resolve chiffre ce repliement : la zone 0-50 nits est reportée sans changement, la zone 51-100 nits est légèrement comprimée sur 51-90, et la zone 101-1000 nits est fortement comprimée sur 91-100. Mais ce n'est pas une dégradation subie : c'est une conversion maîtrisée, très supérieure à un rattrapage manuel au contraste et à la saturation. Fais simplement une passe de vérification plan par plan, comme le recommande le manuel.