Rec 709 et DCI P3, je ne comprends plus rien :)

Bonsoir à tous,

je ne sais plus quoi penser. J'ai des rushs en Rec709 (GH5). J'ai étalonné dans Da Vinci avec le color management suivant, Aces avec Rec709 en IDT et DciP3 en ODT, et j'ai réglé mon écran de monitoring sur DCI P3 (Il est DCI P3 97%). Je me suis dis, pour des exports web ou DCP c'est ce qu'il faut puisque ce sont des surface de diffusion en DCI P3.

Mais je ne sais pas si j'ai bien fait, alors par acquis de conscience, j'ai passé mon écran en Rec709, et la patatra mon étalonnage est dégueulasse dans ce profil, plus rien de correspond.

Et là c'est le début de mes noeuds de cerveau. Je retourne dans color management, je fais des essais en etalonnant de nouveau, en essayant de passer en ACES IDT et ODT REC709, en essayant le YRGB avec timeline en rec 709 gamma 2.4 et en regardant les exports sur différent écran. Plus je fais des essais et moins je comprends Une âme charitable pourrait elle m'expliquer ?

 

Si je fais color management, Yrgb, timeline Rec709 gamma 2.4 (les rush sont en rec709) et je mets mon moniteur en mode DCI P3 car je me dis c'est l'espace colorimétrique du DCP, pour voir ce que je fais, j'ai bon ?

Comment gérer un workflow rush rec 709 pour du DCI P3 65 en diff via Aces ?

 

Je ne suis pas vraiment calé et je n'ai jamais utilisé l'ACES ni sorti du DCP. Ce qui suit ne doit pas être pris pour argent comptant, c'est plus histoire de faire avancer le schmilblick.

Une remarque: le web n'est pas en DCI P3, mais en sRGB, qui est quasi identique au Rec709 (même point blanc, même gamut, gamma légèrement différent). Enfin... en vrai le web c'est tout et n'importe quoi, puisque ce sont des appareils grand public et que rien n'est obligatoire. Mais le sRGB est prétendument ce qui se rapproche le plus d'un espace colorimétrique "moyen".

Ma compréhension du truc:
- L'IDT sert à transformer correctement tes rushes vers l'espace de travail ACES. Dans ton cas, Rec709 me semble donc correct
- L'ODT sert à transformer l'espace ACEs vers l'espace de diffusion de ta production. DCI-P3 me semble correct pour un DCP, pas pour un export web. Il faut faire deux exports distincts, l'un en DCI-P3, l'autre en Rec709. A noter que si Rec709 et sRGB diffèrent un peu, certains logiciels de lecture vidéo corrigent la légère différence de gamma, mais d'autres non. Impossible de décider s'il faut corriger cet écart dans le flux vidéo. De toute façon, vue la disparité des écrans, ces histoires de gamma reviennent à faire du mal aux drosophiles.

Mais il y a encore un truc à faire gaffe: l'espace de couleur dans lequel travaille ton moniteur. Dans ce que tu racontes, c'est normal d'avoir un affichage différent si tu changes le gamut de ton moniteur. Resolve ne peut pas deviner quel est ce gamut. Il faut qu'il corresponde à l'espace de travail de ta production. Donc DCI-P3 si tu travailles avec un ODT DCI-P3, Rec709 si tu travailles avec un ODT Rec709.

Là, il y a en gros deux manières de faire:

Soit ton moniteur dispose des deux modes. Dans ce cas, tu changes de mode en fonction de ton ODT.

Soit ton moniteur ne permet pas cela, ou plus raisonnablement, il le permet mais tu ne fais pas vraiment confiance (d'autant plus que ça peut dériver avec le temps). Dans ce cas, le mieux est d'acheter une sonde de calibration genre I1Display pro, d'installer Displaycal (gratuit) et de générer des LUT d'affichage, que tu places dans project settings / color management / Video monitor LUT. Il te faudra deux LUT:
- l'une qui "découpe" un gamut Rec709/sRGB réduit dans l'espace réel et large de ton moniteur
- l'autre qui transforme l'espace DCI-P3 plus ou moins hasardeux en vrai bon DCI-P3 bien conforme aux specs.

Si ton moniteur est déjà très bien conforme au DCI-P3, la seconde LUT ne sert à peu près à rien et tu pourrais t'en passer. Tu pourrais donc étalonner en DCI-P3 avec ton moniteur sans LUT d'affichage. Bon, les vrais pros vont t'expliquer qu'étalonner pour du ciné, ça ne se fait pas sur un moniteur mais sur un écran de projection, en plus en 10 bit, etc.
Par contre, pour étalonner vers du sRGB ou Rec709, pas le choix, il faut réduire le gamut d'affichage.

A noter que si tu veux vérifier ensuite le résultat dans VLC ou dans un navigateur web, aucun de ces logiciels ne gère la réduction de gamut. Sur un écran DCI-P3, ils vont étendre une vidéo Rec709 sur un gamut DCI-P3, avec des couleurs bien trop saturées (trop vives). Il n'y a pas d'autre solution que d'utiliser le mode sRGB de ton moniteur (s'il en a un), ou de trouver un autre moniteur avec un gamut natif sRGB.

Si j'ai dit des conneries, que ceux qui maîtrisent n'hésitent pas à corriger.

 

Très intéressant résumé de la complexité des différents formats de diffusion.
C'est pour cela, qu'en fonction de ce que l'on fait (et fera) il est important de réfléchir à sa chaine de travail.
Il est donc important de définir pour ses montages un format de fichier dit "pivot" qui permettra de décliner les fichier (par transcodage) pour les différentes utilisations.
Les moniteurs dit compatible DCI-P3 permettent de visionner un DCP presque correctement, mais il est préférable ensuite, avant exploitation, de faire une vérification avec une véritable installation DCI.
Ne pas oublier que le nommage des fichiers DCP est normé.

 

Merci beaucoup pour vos réponses

Nicolas, oui j'avais bien fait cela au départ mais il y une chose qui m’échappe.
Da Vinci propose un color management en Aces, ce que j'ai fait, et un color management en yrgb avec un espace de couleur de la timeline à définir. J'ai lu ici ou là que pour un DCP à partir de rush 709, il fallait se mettre en yrgb timeline rec 709 gamma 2.4
Quand je fais cela, tout l’étalonnage change et surtout il offre bien moins de possibilités, les couleurs saturent beaucoup rapidement, les noirs sont laiteux...
Donc en yrgb timeline res709 gamma 2.4 ou Ace ODT IDT, tel est la question Quelle est leur différence ?

Pour le web, beaucoup d’écrans affichent en DCI p3 60 non ? Comment faire alors un bon export web ? Chez moi les affichages en REC 709 (srgb) et DCI P3 n'ont rien à voir, et je ne sais pas sur quel type d'ecran cela sera regardé...

Tu sais où je peux trouver des luts de moniteur en DCI p3 ? Car j'ai une sonde, j'ai calibré mon écran, mais je me posais la question d’être sûr de faire le processus de la sonde en DCI P3 puisque mon écran me propose plusieurs modes d'affichages. Comment fait on cela ?

Beaucoup de questions Les infos sont pas facile à trouver dans ce domaine

 

Le DCP c'est uniquement pour le cinéma numérique, donc pour passer dans un système DCI qui est normé.
Pour le reste le REC 709 ou 2020 suffit.

 

Si toute ta chaîne image est entièrement configurée en Rec709 (rushes nativement en Rec709 et définis comme tel dans Resolve, timeline en Rec709, sortie en Rec709) et qu'à la fin tu observes ça sur un moniteur en DCI-P3 sans LUT d'affichage, c'est normal que ça donne des trucs bizarres.

Par ailleurs, si tu fais varier les espaces de couleurs de sortie sans adapter ton moniteur en conséquence (soit dans le moniteur lui-même, soit en utilisant des LUT d'affichage), c'est encore normal d'avoir des trucs bizarres.

Je n'ai pas vérifié, mais si ma compréhension est bonne, avec la "science de couleurs" Davinci YRGB Color managed, les chaînes suivantes devraient donner des résultats visuellement corrects (pas identiques, mais sans rien qui choque niveau gamut) :
1) rushes définis comme Rec709, timeline en Rec709, output color space en Rec709, moniteur réglé sur le mode sRGB
2) rushes définis comme Rec709, timeline en Rec709, output color space en Rec709, moniteur réglé sur le mode DCI-P3 et LUT d'affichage réduisant le DCI-P3 au Rec709
3) rushes définis comme Rec709, timeline en Rec709, output color space en DCI-P3, moniteur réglé sur le mode DCI-P3
4) rushes définis comme Rec709, timeline en DCI-P3, output color space en DCI-P3, moniteur réglé sur le mode DCI-P3

Par contre, les chaînes 1 et 2 ne permettent pas de générer un DCP conforme, puisque la sortie est limitée au gamut sRGB/Rec709.

De même, en utilisant l'ACES, les chaînes suivantes devraient être correctes (pas identiques, mais correctes):
1) rushes Rec709, timeline ACES, ODT Rec709, moniteur Rec709
2) rushes Rec709, timeline ACES, ODT Rec709, moniteur DCI-P3, LUT réduisant du DCI-P3 au Rec709
3) rushes Rec709, timeline ACES, ODT DCI-P3, Moniteur DCI-P3

De nouveau, les chaînes 1 et 2 ne permettront pas de générer des DCP conformes.

Remarque bien qu'il n'y a pas 4 mais 3 chaînes ici, puisque l'ACES est de toute façon plus large que le Rec709 et que le DCI-P3. Il n'y a donc plus de timeline dans un mode ou dans un autre, juste dans l’espace ACES qui est le plus large possible et englobe tout le domaine visible.

Tu peux avoir des résultats corrects avec les deux espaces de travail, à condition qu'ils soient configurés correctement et que le moniteur soit dans un gamut correct. De toute façon, les deux chaînes sont fonctionnellement similaires. Dans le mode "Davinci YRGB Color managed" - un algorithme propre à DVR - il y a aussi des équivalents d'IDT et d'ODT, même si ça ne s'appelle pas comme ça. "Output color space", c'est un ODT.

"ce que tu as pu lire ici ou là" a peut-être été écrit avant que l'ACES ne devienne vraiment officiel, ou par des gens qui ont gardé les habitudes (ça ne change pas du jour au lendemain). L'ACES est assez récent. C'est censé remplacer tous les anciens espaces de couleurs des timelines. Vu que l'ACES est à priori un truc plutôt intelligent et qui va dans le bon sens, j'aurais tendance à te conseiller cet espace de travail.

Quelques utilisateurs auront des écrans DCI-P3, mais c'est très loin d'être courant. D'autres auront du "wide gamut", qui veut simplement dire "plus large que le sRGB", mais sans aller jusqu'au DCI-P3. D'autres auront des écrans sRGB. D'autres encore auront des écrans bien plus réduits que le sRGB. L'écran de mon ordinateur portable, par exemple, ne couvre que 54% de l'espace sRGB. Ca va être fréquent sur les ordinateurs portables, eux-même fréquents chez les particuliers (qui achète une tour aujourd'hui ?).
Sur les téléphones portables, difficile à dire mais il me semble que les gamuts sont plutôt larges et couvrent généralement le sRGB, voir plus.
Espérer du DCI-P3 sur Internet, ça me semble extrêmement optimiste à l'heure actuelle.

Je n'ai rien à te proposer clé en main car mes LUT ne sont adaptées qu'à mon moniteur. Vu que tu as une sonde, tu peux créer tes propres LUT gratuitement avec Displaycal:
3D LUT creation workflow for Resolve | DisplayCAL

 

Dans mon expérience, faire un étalonnage sur un écran avec une simulation de P3 DCI y2.6 à 48 nits ne fournit pas de bons résultats pour un DCP cinéma.
Si on n'a pas accès à un bon auditorium d'étalonnage, il vaut mieux en fait rester en 709 y2.4 à 100 nits sur le moniteur de référence et confier la conversion au color management. Le contraire est d'ailleurs vrai aussi, si l'étalonnage a été fait en projection DCI y2.6, la conversion vers le 709 y2.4 est généralement satisfaisante.
Les moniteurs qui simulent la projection cinéma échouent géométriquement à vous proposer la bonne image, elle est juste trop petite...

Le cas de figure Netflix/VOD est peut être le seul à bénéficier d'un workflow en P3 mais uniquement dans le cas d'un mastering HDR à 1000 nits

 

Bonjour, merci beaucoup pour toutes vos réponses enrichissantes

Merci pour ton lien Il y a une chose que je ne comprend pas. Les luts d'affichage. Pour moi un espace de couleur est un invariable. Si je place une lut d'affichage personnalisée sur mon écran, je vais donc étalonner selon un monitoring qui m'est propre, alors que j'ai besoin d’étalonner sur un monitoring qui est juste partout. Bien sûr les écrans de tout à chacun divergent, mais je n'accentue pas les potentiels écart étalonnage / diffusion en rajoutant en plus une lut d'affichage personnalisée sur mon monitoring ?

Merci beaucoup Nicolas d'avoir pris le temps de faire cette super réponse détaillée.
Tu me conseillerais donc de travailler avec un écran de monitoring en REC 709, Aces Idt Rec 709, ODT Rec 709 pour du web ?

Mais là je ne comprends pas. Si j’étalonne avec mon moniteur et mes idt odt en rec709, quand je bascule pour vérification mon moniteur en dcip3, le résultat est horrible. En quoi du coup dois je faire le monitoring pour avoir un résultat qui soit un minimum cohérent sur des écrans REc709 et Dcip3, puisque cela sera lu sur les deux ? C'est bien là le coeur de mon problème


J'en reviens au DCP Car le client voudrait peut être une diffusion salle avant le film. Quel workflow me conseillerai tu en ACES pour un export DCP à partir de rushs Rec 709 ?

Désolé de te poser autant de question mais tu as l'air grave calé

Merci beaucoup pour ta réponse. Tu parle de conversions via un node de conversion ? Tu crois tu pourrais me dire comment faire cela concrètement ? Car je fais des test, je mate des tutos, mais je ne suis vraiment pas sur de moi dans ce process

Merci beaucoup beaucoup pour votre temps

En cherchant j'ai trouvé ce lien et cette chaine youtube super instructive



En espérant que mes interrogations servent à d'autres

 

très bien ce tuto

 

Je crois que ce que tu vis c'est surtout la qualité de l'ODT, à mon avis tu auras la même expérience en ACES avec l'ODT 709. La différence fondamentale c'est qu'en ACES tu travailles sur des valeurs widegammut intermédiaires alors qu'en YRGB tu travailles directement sur les valeurs affichées.

 

Je pense que c'est une bonne piste.

Si ton export Rec709 est affiché par un Internaute sur un écran DCI-P3 sans correction de gamut, les couleurs seront trop saturées. Inversement, si tu produis un export web DCI-P3 et qu'il est affiché par un internaute sur un écran sRGB sans correction de gamut, les couleurs seront trop pastel.

Il y a deux problèmes fondamentaux:
1- la très grande majorité des écrans des utilisateurs ne sont pas calibrés.
2- même pour les utilisateurs avec des écrans calibrés, la correction de gamut est très mal gérée à l'heure actuelle sous Windows.

Si (et je dis bien si) l'adaptation de gamut était bien gérée ET si les écrans étaient massivement calibrés, alors il y aurait intérêt à diffuser dans un gamut large: ceux qui auraient un écran à large gamut bénéficieraient de toutes les nuances correctes, et ceux qui auraient un écran à gamut réduit auraient des couleurs correctes au sein de la plage réduite de leur écran. Il resterait bien sûr un problème avec les couleurs hors de leur gamut qui ne pourraient pas être affichées correctement.

Sauf que le monde réel n'est pas aussi beau. On se retrouve choisir entre deux solutions bancales:
- créer du contenu à large gamut, qui sera affiché correctement par les quelques privilégiés ayant un écran de même gamut, mais incorrect pour une écrasante majorité des internautes;
- créer du contenu à gamut réduit, qui sera plus ou moins correctement affiché chez la plupart des utilisateurs. Ce contenu sera trop saturé sur les écrans à large gamut, même s'ils sont calibrés. Les boules.

Le consensus professionnel aujourd'hui, c'est de travailler pour la masse, et de se restreindre au sRGB/Rec709.

Que ce soit plus grand n'empêche pas les erreurs: il faut qu'il y ait une adaptation de gamut. Si le gamut Rec709 est purement plaqué sur le DCI-P3 d'un projecteur, les couleurs seront trop saturées.

Mais si je comprends bien le message de Forest, les projecteurs de ciné font cette correction de gamut. On peut sans problème leur envoyer des fichiers en Rec709 qui seront affichés correctement. Et même, cette correction automatique sera meilleure que de tenter chez soi un étalonnage DCI-P3 hasardeux. Il vaut donc mieux travailler en Rec709 en ODT sur un écran réglé en Rec709 d'une manière ou d'une autre, même si la palette de couleurs sera moindre. Moins de couleurs, mais une meilleure confiance que celles projetées soient similaires à ce que tu avais sur ton écran.


******************************

Voici quelques grandes lignes approximatives sur le principe d'une calibration. Pour calibrer un écran, on conforme plusieurs paramètres selon une cible (DCI-P3, sRGB, Rec709, etc). Si chaque producteur de contenu et chaque utilisateur aligne son écran sur la même cible, les affichages seront aussi proches que possible, indépendamment des caractéristiques disparates des écrans.

Il y a en gros deux manières de conformer ces paramètres:
- le menu de l'écran
- par logiciel dans le système d'exploitation

Les deux méthodes nécessitent une sonde de calibration. C'est généralement mieux d'utiliser d'abord le menu de l'écran, et de compléter ensuite par correction logicielle si besoin.

La méthode utilisant le menu est dite "itérative": tu mesures les caractéristiques avec la sonde, tu vas dans le menu pour corriger un peu au pif, tu re-mesures: c'est mieux mais c'est pas encore ça. Tu retournes dans le menu, tu modifies plus finement, et ainsi de suite jusqu'à être au plus près. A proprement parler, la sonde ne calibre rien du tout, elle mesure. C'est toi qui calibre avec tes petits doigts sur les petits boutons du menu.

Le colorimètre HCFR est un logiciel gratuit dédié à la calibration itérative. C'est développé par des mordus de home-cinéma, qui ont pour source des lecteurs DVD ou Blu-ray, qui ne permettent pas de calibration logicielle. C'est une bonne idée de commencer par calibrer le plus possible avec HCFR, et de compléter ensuite avec un outil comme DisplayCal dédié à la calibration logicielle.


Les paramètres à conformer sont en gros:
1- la luminosité globale de l'écran (en Cd/m2, candelas par mètre carré)
2- la température de couleur ou point blanc (en Kelvin, K)
3- le gamma (le profil de l'échelle de gris)
4- le gamut (l'étendue des couleurs reproductibles)


Sous Windows, les trois premiers sont pas trop mal gérés. Le quatrième, c'est la fête du slip.

La luminosité idéale dépend de l'environnement. Un studio d’étalonnage va aussi respecter des contraintes d'environnement (pas de sources de lumières directes, ambiance lumineuse tamisée, murs gris neutre, éclairage à 6500K - ou 5600K je ne me souviens plus). Si tu étalonnes dans ton salon avec des murs de toutes les couleurs et un éclairage à base d'ampoules vintage "Edison" à 2000K, tu n'es pas du tout dans des conditions optimales. Ca n'a rien de mal (c'est mon cas), mais c'est pas pro. Les histoires de DCI-P3 plutôt que Rec709 sont vite superflues, parce qu'il y a à coté des lacunes plus fondamentales.
La luminosité se règle directement dans le menu de l'écran. Dans le monde réel, beaucoup d'écrans actuels sont beaucoup trop lumineux au regard des conditions de visionnages. Ils délivrent 300Cd/m2 ou plus, alors qu'un visionnage en intérieur "normal" ne requiert que 100 à 150Cd/m2. Dans bien des cas, la luminosité des écrans devrait être réglée à seulement 30 ou 40%.

Le point blanc, c'est simple et universel: c'est 6500K sur la courbe "Daylight" (ou D65). Cette courbe est proche d'un corps noir avec un léger déficit de bleu, et s'approche de la lumière du soleil une fois qu'elle a traversé l'atmosphère.
Dans la vraie vie, beaucoup d'écrans lambda sont trop bleus (entre 7000 et 8000K).
Ca se règle idéalement en ajustant les gains R/V/B dans le menu de l'écran, ou à défaut par logiciel. La compensation logicielle est alors placée dans Windows au niveau de la carte graphique et toutes les applications bénéficient de cette correction. Donc, coté "point blanc", qu'on le règle grâce au menu ou par logiciel, cela affecte tout.

Le gamma: là aussi, c'est théoriquement mieux de le gérer dans le menu de l'écran. Mais tous les moniteurs ne permettent pas cela. A défaut, ça se règle par logiciel, et là encore c'est placé au niveau de la carte graphique et ça concerne toutes les applications. On appelle ça "Video Card Gamma Table" (VCGT), et ce sont des sortes de LUT 1D. Si le moniteur le permet, on peut très bien utiliser le gamma le plus proche de ce qu'on désire, et affiner par logiciel en plus. Attention, les valeurs dans les menus ne sont pas très précises. Un écran que j'utilise doit être réglé sur Gamma 2.4 pour avoir un gamma proche de 2.2.
Le gamma à cibler dépend des conditions de visionnage, comme la luminosité maximale de l'écran. Les moniteurs informatiques sont en sRGB à gamma 2.2 (utilisation de jour), alors qu'en vidéo Rec709 on est à 2.4 (utilisation en soirée) et qu'en cinéma on est à 2.6 (noir total).
Dans la vraie vie sur un moniteur lambda, le gamma c'est tout et n'importe quoi, avec une tendance des moniteurs informatiques à écraser les noirs pour rendre l'image plus pêchue.

Et enfin, il y a ce fameux gamut. Certains écrans peuvent adapter le gamut dans leur menu. Sur les deux écrans que j'ai, cette fonction existe mais bloque d'autres réglages (je ne sais pas pourquoi). Du coup elle est inutilisable et je dois passer par logiciel, même si théoriquement c'est là encore mieux d'utiliser les menus de l'écran. La correction de gamut se fait avec des LUT3D.
Le hic, c'est que ce gamut n'est pas placé au niveau de la carte graphique, il est simplement stocké dans un répertoire sous la forme de profils ICC et mis à disposition de qui n'en veut. Chaque logiciel l'utilise ou pas selon les envies du développeur. Et pour le moment, c'est pas glorieux. Les applications graphiques type Photoshop ou Gimp utilisent ces profils ICC. Resolve ne l'utilise pas mais la fonction "LUT d'affichage" fait la même chose (je pense que les mecs de Resolve ont dû regarder ce qui se faisait sous Windows et ont décidé dans la seconde qui suit de gérer tout ça eux même). Les lecteur vidéo grand public type VLC ne gèrent pas la réduction de gamut. Les navigateurs web récents la gèrent pour les images fixes (et encore, selon des critères variables d'un navigateur à l'autre), mais pas pour les vidéos. Last but not least, Windows n'utilise pas les profils ICC pour sa propre interface: les icônes sont hyper flashy sur un écran à large gamut.

Les moniteurs dits "graphiques" permettent d'intégrer ces LUT directement dans le moniteur. On a alors le meilleur des deux méthodes de calibration: la souplesse et la précision d'une calibration logicielle, mais qui suit le moniteur (si on le branche sur un autre PC, ça continue de fonctionner) et qui s'applique à la totalité du contenu, y compris aux applications incapables de gérer les gamut.

Enfin, quand on est pauvre, choisir un écran qui a intrinsèquement un gamut sRGB est une bonne idée: il n'y aura pas d'adaptation de gamut à faire pour les contenus usuels, (sRGB ou Rec709) et les autres paramètres sont à peu près correctement gérés et poseront moins de soucis.

 

Heu, vous n'avez jamais utilisé le CST ?



Normalement, à part le gamma qui passe de 2.4 à 2.6, tu ne dois pas voir beaucoup de différence au niveau des couleurs.

Sinon, pour faire un DCP, il faut que tu regardes comment générer un IMF à partir de Resolve.......

 

Merci Kersalg pour ta réponse Tu crois que tu pourrais détailler un peu plus ?