Amelioration de mon Workflow Montage/post prod

Salut tout le monde,

Je me tourne vers vous parce que je rencontre des problèmes, du moins des ralentissements dans mon Workflow entre Adobe Premiere et Resolve. Je sens que je pourrais nettement améliorer tout ça.

(En rouge, les étapes qui sont causes de problèmes).


Etape 1: Importation, tri et montage des rushs sur Adobe Premiere (ou Vegas)

Etape 2: Sur Premiere, denoise via le plug in "Neat video" puis export XML ou AAF
Le problème c'est que : 1. Le logiciel de montage exporte alors tous les rushs de la timeline... 2. Si je le fais pas, je ne peux pas denoise sur Resolve, et si je ne denoise pas, ça bruite à l'etalonnage.

Etape 3: Etalonnage, puis Export AAF ou XML vers Adobe ou Vegas (mais ça prend du temps à nouveau d'avoir un export de rushs...)

Etape 4: Sur le logiciel de montage, dernières modifications, ajouts des transitions.



Avez vous des conseils pour m'améliorer ?

Citation:

---

Envoyé par thomashauserr

Salut tout le monde,

Je me tourne vers vous parce que je rencontre des problèmes, du moins des ralentissements dans mon Workflow entre Adobe Premiere et Resolve. Je sens que je pourrais nettement améliorer tout ça.

(En rouge, les étapes qui sont causes de problèmes).


Etape 1: Importation, tri et montage des rushs sur Adobe Premiere (ou Vegas)

Etape 2: Sur Premiere, denoise via le plug in "Neat video" puis export XML ou AAF
Le problème c'est que : 1. Le logiciel de montage exporte alors tous les rushs de la timeline... 2. Si je le fais pas, je ne peux pas denoise sur Resolve, et si je ne denoise pas, ça bruite à l'etalonnage.

Etape 3: Etalonnage, puis Export AAF ou XML vers Adobe ou Vegas (mais ça prend du temps à nouveau d'avoir un export de rushs...)

Etape 4: Sur le logiciel de montage, dernières modifications, ajouts des transitions.



Avez vous des conseils pour m'améliorer ?

---

Mais pourquoi appliquer "Neat" au début ?
Ce n'est pas trop logique Thomas.

Neat c'est la toute dernière étape.
Surtout que dans l'export XML cela n'apparait pas.

Si je ne fais pas neat avant d'étalonner, j'ai beaucoup plus d'artefacts. Surtout en S-LOG, c'est pour ça. Tu veux dire qu'il est préférable de denoiser après l'application de la LUT et l'étalonnage ?

Citation:

---

Envoyé par thomashauserr

Si je ne fais pas neat avant d'étalonner, j'ai beaucoup plus d'artefacts. Surtout en S-LOG, c'est pour ça. Tu veux dire qu'il est préférable de denoiser après l'application de la LUT et l'étalonnage ?

---

Il y a plusieurs points que je ne comprends pas bien...

1) S-LOG = bruit.
=> Si l'utilisation du mode "S-LOG" produit du bruit et dégrade l'image, pourquoi Sony le propose t-il ?
Non Le LOG ne doit pas produire de bruit s'il est bien utilisé. Il doit être réservé à des situations complexes=> grande latitude nécessaire : écarts de diaph importants dans le même cadre, et/ou des besoins de post-prod important.

Donc je pense qu'il faut que tu améliores ton exposition dans ce mode, et que tu le réserves à des situations spécifiques.

2) L'étalonnage est une action de finition et le "débruitage" s'effectue en toute fin de workflow car son degré d'application dépendra justement du type d'étalonnage !

3) Si la LUT dégrade l'image, c'est qu'elle n'est pas appropriée. Cela veut dire que le transcodage couleur / luminance qu'elle doit réaliser, s'effectue mal.
=> Il est parfois intéressant de dégrader volontairement l'image, mais je ne pense pas que ce soit l'objet de ta question

Conclusion :

Je te déconseille vivement de "débruiter" en début de workflow car en appliquant une LUT après l’application de "Neat" tu peux dégrader le travail du plugin, le réduire....

Citation:

---

Envoyé par lafamily

Il y a plusieurs points que je ne comprends pas bien...

1) S-LOG = bruit.
=> Si l'utilisation du mode "S-LOG" produit du bruit et dégrade l'image, pourquoi Sony le propose t-il ?
Non Le LOG ne doit pas produire de bruit s'il est bien utilisé. Il doit être réservé à des situations complexes=> grande latitude nécessaire : écarts de diaph importants dans le même cadre, et/ou des besoins de post-prod important.

Donc je pense qu'il faut que tu améliores ton exposition dans ce mode, et que tu le réserves à des situations spécifiques.

2) L'étalonnage est une action de finition et le "débruitage" s'effectue en toute fin de workflow car son degré d'application dépendra justement du type d'étalonnage !

3) Si la LUT dégrade l'image, c'est qu'elle n'est pas appropriée. Cela veut dire que le transcodage couleur / luminance qu'elle doit réaliser, s'effectue mal.
=> Il est parfois intéressant de dégrader volontairement l'image, mais je ne pense pas que ce soit l'objet de ta question

Conclusion :

Je te déconseille vivement de "débruiter" en début de workflow car en appliquant une LUT après l’application de "Neat" tu peux dégrader le travail du plugin, le réduire....

---

Ok, c'est noté. J'étais persuadé que c'était la marche à suivre pourtant. Enfin je n'avais jamais lu d'indication contraire, c'est même l'opposé : Vision Color conseille dans le pdf qui accompagne le pack qui accompagne ses LUTs de denoiser, et je pensais que c'était à faire avant pour éviter que le micro bruit (et en Slog 2 tu en as souvent) devienne visible après l'application de la LUT. C'est étonnant que je n'ai jamais pensé à l'appliquer après... putain


Dis, tu es toujours passé à coté de ma question dans le dernier fil. Mais quelle est la façon la plus simple de séparer les couches RVB sur Resolve ? le Qualifier ?

Citation:

---

Envoyé par thomashauserr

Dis, tu es toujours passé à coté de ma question dans le dernier fil. Mais quelle est la façon la plus simple de séparer les couches RVB sur Resolve ? le Qualifier ?

---

Oh pardon Thomas, j'ai zappé la question.

Je te propose une méthode 100% simple et automatique :

1) tu crées un premier node (ctrl+s)
2) dans le menu "NODE" et tu choisis "Add Splitter/conbiner Node"

Et hop ! C'est fait !

a) Tu obtiens un Node "splitter" qui ne sert qu'à faire le lien entre ton premier node et les trois couches RVB, puis trois nodes (ne jamais lui appliquer d'effets) :
b) En lecture de haut en bas tu obtiens = en Haut le rouge, en dessous le verts, et en ba le bleu !
c) le dernier Node (combiner) compile le résultat des 3.

Je te conseille d’appliquer une LUT en créant un nouveau serial Node à la suite du "Combiner", c'est plus propres...

Tu peux donc travailler sur les couches RVB indépendamment les unes des autres !
C'est une fonction que j'utilise tout le temps !!!


Tu peux également séparer les couches "à la main"
Comme ceci :

Split RGB in Resolve 9 : A "Stupid" Resolve Trick on Vimeo

C'est intéressant pour bien comprendre comment ça marche.

Mais c'ext extra ! Je ne connaissais pas. C'est super utile !

J'ai un peu de mal à travailler avec ces couches RVB, mais bon, ça va sans doute venir.

Citation:

---

Envoyé par thomashauserr

Mais c'ext extra ! Je ne connaissais pas. C'est super utile !
J'ai un peu de mal à travailler avec ces couches RVB, mais bon, ça va sans doute venir.

---

Oui c'est sacrément utile !

Le signal vidéo étant composé des trois couches, il est beaucoup plus efficace de travailler sur une couche avec précision plutôt que de bidouiller sur les les roues sur l'ensemble du cadre...

Tu peux également créer uniquement la couche "luminance" qui te permet de ne bosser que sur la luminance associée à une seule couche !
Tu devrais tenter, c'est magique !

Si avant d'appliquer une LUT, tu décomposes en couches RVB, tu pourras mieux maîtriser les couleurs que la LUT engendre.
Maitriser la luminance sur chaque couche te permettra de régler finement l'impact de ta LUT si celui -ci est trop fort dans l'interprétation du bleu ou du rouge...ou du vert...

Et pour le S-LOG, je te conseille de décomposer un plan en couches RVB indépendantes et regarder dans quelle couche se trouve le bruit numérique.
Ça te permettra de mieux comprendre pourquoi tu obtiens du bruit.

Si le bruit est dans le "layer" rouge, ça veut dire que tu sous-exposes les valeurs chaudes !

Je vais donc bosser tout ça cette semaine !


Mon dieu, j'ai découvert à l'instant que Atomos avait mis fin à la production des Shogun et Assassin, moi qui voulait profiter des 25% étudiants pour avoir l'Assassin à 750€... Je comprends pas. Maintenant ils ont ajouté le HDR 10 stops de dynamic j'ai l'impression... Je sais pas ce que ça donne mais je suis déçu. Le 10bits 4:2:2 m'aurait changé la vie

Help Francis !

J'ai un soucis en passant de Premiere à Resolve, je pose mes fichiers en XAVC S container MP4, les monte etc, exporte le XML, mais il semblerait que le MP4 soit mal supporté en XML puisque Resolve refuse d'ouvrir les fichiers. C'est ce qu'on m'a dit... C'est étonnant, j'avais essayé une fois et parfaitement réussi... Tu as une idée de la cause ?



Autre chose : Quand je passe du XAVC S (MP4) en DNxHD (mov), l'image devient plus contrastée, ça n'est pas préjudiciable à l'application d'une LUT ?

Par ailleurs j'ai de grosses mochetés qui apparaissent en DNxHD... je te laisse observer !


http://nsa37.casimages.com/img/2016/...1629870712.jpg

Du XAVC S





http://nsa38.casimages.com/img/2016/...2162917028.jpg
Et le DNxHD qui est pourtant près de deux fois plus lourd

Citation:

---

mais il semblerait que le MP4 soit mal supporté en XML

---

Non Thomas, Le XML est un fichier texte (.txt) que tu peux ouvrir dans "Word" ou dans "Wordpad".
C'est un fichier descriptif qui décrit le nom d'un rush, sa longueur, l'endroit où tu as coupé...C'est tout, et quel que soit le codec de tes rushes.
Bref c'est un fichier texte qui décrit ton montage, il n'encode rien, il ne traduit rien.

Le problème vient de DaVinci Resolve qui n'arrive pas à lire le XAVC S (qui est une forme propriétaire de compression spécifique à Sony, le "S" c'est pour Sony).
Le logiciel de montage AVID ne lit pas non plus ce Codec Propriétaire XAVC S.

Tu fais donc très bien d'encoder tes rushes en DNxHD.
Tu pourrais aussi les encoder en .MOV (un simple rewrap du MP4 en ".MOV") au moment de transférer tes rushes de la carte SDXC vers ton disque dur d'ordinateur, si tu préfères rester en 8bits.

Citation:

---

Autre chose : Quand je passe du XAVC S (MP4) en DNxHD (mov), l'image devient plus contrastée, ça n'est pas préjudiciable à l'application d'une LUT ?

---

Voilà une bonne illustration d'une mauvaise interprétation de l'espace couleur, dont je parle souvent (lorsque je parle des LUTs) !!!!!!!!!!!!!

Lorsque tu exportes ton DNxHD il faut que tu choisisses le même espace couleur qui va être utilisé par Resove, c'est de là que vient ton problème.
=> En effet, au moment de l'encodage en DNxHD il faut définir le niveau de "noir".

Je t'explique :
Si Première interprète le gris très foncé comme un gris et Resolve le même gris très foncé comme du noir => Tu images que la même image sera interprétée de façon plus contrastée dans Resolve que dans Première !
Et ce décalage va se voir sur toute l'image !
C'est ça "l'espace couleur".

Une caméra transforme une couleur en une information chiffrée et affiche la couleur correspondante suivant sa propre grille = son Espace Couleur
La même image lue par un autre logiciel qui n'interprète pas ces informations chiffrées de la même façon va détruire l'image en la lisant... problème de traduction...

Si tu exportes ton DNxHD depuis Première en RVB (0-255) et que Resolve interprète ton DNxHD dans l'espace de couleurs Rec-709 (16-235) ça donne ce résultat !

Conclusion :
Dans première, au moment de ton export, vérifie bien dans quel espace couleur tu exportes (Rec-709 16-235) ou (RVB 0-255).
Dans Resolve vérifie dans quel espace couleur (dans l'onglet préférences) il interprète le DNxHD.
Pour que que ton image soient toujours correctement affichée dans les 2 logiciels, il faut que les 2 logiciels l'interprètent dans le même espace couleur.

Si Première dit => la valeur 0 c'est du noir (pur) et 255 c'est du blanc (pur)
et que Resolve dit => La valeur 16 c'est du noir (pur) et la valeur 235 c'est du blanc (pur)

Si les 2 logiciels qui lisent la même image ne parlent pas la même langue...Ils ne la lisent pas de la même façon !

Lorsque tu encodes ton XAVC S en DNxHD tu dois choisir dans les options :
C'est le menu que j'ai dans Sony Vegas Pro, tu dois obtenir la même chose dans Première

http://nsa37.casimages.com/img/2016/...5906809864.jpg


Je reviens sur les LUTs :
C'est pour cela que je m'emporte concernant les LUTs et les "espaces couleur" et que je répète encore un fois : une LUT est faite pour un espace couleur et un seul !!!!!

Salut Francis,

Merci de ton aide, ça éclaire pas mal de points noirs. En l'occurence on parle bien de l'espace couleur d'interprétation ? Il faudrait donc que j'encode mon XAVC S en DNxHD RGB Level si le 709 ne correspond pas à mes rushs bruts ?


De toutes façons je n'exporte pas à partir de Premiere au départ, maintenant je passe par Encoder pour passer en DNxHD (709 précédemment, mais ej viens de réaliser que c'est le RGB qui correspond à l'espace couleur natif).

Citation:

---

En l'occurence on parle bien de l'espace couleur d'interprétation ?

---

Non !!
Je parle de la manip que tu fais dans "Encoder" au moment ou tu encodes passes tes rushes de XAVC S à DNxHD.

=> Ce qui est important c'est que si tu choisis DNxHD "Rec-709", et bien lorsque tu ouvres Resolve il faut qu'il soit bien en REC-709.
=> Si tu choisis "RBG" dans "Encoder", alors lorsque tu ouvres Resolve => tu vas dans les préférences pour lui dire d'interpréter la TimeLine en "RGB"

ça n'a rien à voir avec ton fichier natif en XAVC S..

Citation:

---

Il faudrait donc que j'encode mon XAVC S en DNxHD RGB Level si le 709 ne correspond pas à mes rushs bruts ?

---

Non rien à voir, j'ai tenté de t'expliquer au dessus....

Est-ce plus clair Thomas ?

DaVinci Resolve interprète par défaut en REC-709 2.4, c'est à toi de changer ce paramètre si tu as encodé ton DNxHD en RBG.

Car Si tu as des "escaliers" sur ton image, c'est juste un problème d'affichage, car Resolve n’interprète pas dans le bon espace couleur ton fichier.

Est-ce plus clair Thomas ?

D'accord, c'est compris !

Donc finalement, que dans Encoder je choisisse RGB ou 709 importe peu tant que Je maintiens ce réglage dans Resolve. En l'occurence j'avais encodé en 709, mais Resolve n'interprétait pas bien, il faut que je trouve l'option dans les réglages.


C'est plus clair ! L'espace couleur d'une image doit être lu comme tel c'est bien ça ? Comme un livre en français est lu en français etc...


EDIT : Dans Color Science je ne vois que Da vinci YRGB ou Da vinci ACES.

Citation:

---

Envoyé par thomashauserr

EDIT : Dans Color Science je ne vois que Da vinci YRGB ou Da vinci ACES.

---

Dans "Timeline" (de mémoire) il lit en REC-709 2.4 je crois....
vérifie... je ne suis pas devant une machine à l'instant...

Effectivement, mon Resolve lit de façon similaire le XAVC S et le DNxHD exporté en RGB.

Je cherche à lui faire interpreter le 709 correctement, sans succès pour le moment. Je verrai ça plus tard :)

Pourras-tu regarder dans Resolve ou changer l'espace couleur s'il te plait ? Je n'ai pas trouvé, pas même sur Google. Et ma solution d'encoder les rushs en RGB qui avait fonctionné est con : je les ai ensuite envoyé sur Premiere qui ne les lisait plus correctement du coup... Il faut donc que je reste en 709, que Premiere lit parfaitement, mais que je configure Resolve de tel sorte à ce qu'il lise aussi en 709

Citation:

---

Envoyé par thomashauserr

Pourras-tu regarder dans Resolve ou changer l'espace couleur s'il te plait ? Je n'ai pas trouvé, pas même sur Google. Et ma solution d'encoder les rushs en RGB qui avait fonctionné est con : je les ai ensuite envoyé sur Premiere qui ne les lisait plus correctement du coup... Il faut donc que je reste en 709, que Premiere lit parfaitement, mais que je configure Resolve de tel sorte à ce qu'il lise aussi en 709

---

Lorsque tu ouvres Resolve, la petite roue dentée tout en bas à droite.
C'est là que tu ouvres les préférences pour changer les inputs et ouputs que ce soit dans Color ou des Edit !

http://nsa38.casimages.com/img/2016/...1021132294.jpg

"Master reset maintains RGB balance" ? Parce que aucun des boutons ne modifie mon espace couleur ici. Et dans Editing j'ai rien non plus