AE et le time-code

Cher Réglisse22,


je viens de tomber un peu tardivement sur ce post, mais je tenais à dire que la démarche de fb2k n'est pas du tout illogique. La gestion des time-codes et notamment l'export de ceux-ci au format EDL peut-être extrêmement pratique.

Imaginons que tu as tourné un clip très graphique en HD ou BetaNum et que tu as de nombreuses heures de rushes. Comme celles-ci prennent trop de place en non-compressé, tu décides de faire un prémontage en basse def (DV par exemple), pour remplacer ensuite les fichiers dont tu as besoin dans ta composition finale.

On peut bien entendu faire un prémontage sous Premiere et imaginer à l'avance toutes les transitions que l'on va appliquer sur les images mais à l'utilisation c'est contraignant.

L'idéal pour moi serait de faire son 1er montage sous Premiere en basse-def, l'importer sous After pour styliser celui-ci et au final, récupérer tous les time-codes des rushes utilisées, les digitaliser et les ré-importer sous After pour le rendu final.

Malheureusement, aujourd'hui ce n'est pas possible et je peux t'assurer que dans certains cas c'est galère.

D'autant plus que comme le dit fb2k, ça ne doit pas être bien compliqué à intégrer comme fonction.

Cordialement,


Stéphane

 

Sais-tu utiliser les Pseudo-élément et les doublures?

Ca peux servir dans ce cas pour travailler sur des éléments basse-def. Mais il faudras remplacer chaque fichier intégralement, à cause de cette lacune sur les tc. Mais ça peux permettre de faire une selection des plans et de n'importer ensuite que ceux là.

 

C'est une excellente solution, qui peut faire gagner beaucoup de temps.

Malheureusement, tu es quand même obligé de digitaliser en haute def des sources inutiles et je viens de faire l'essai sur un projet de 3 minutes, en sélectionnant uniquement mes sources DV afin d'estimer le poids final. J'obtiens 70 fichiers pour un poids en DV de 11Go, ce qui devrait me donner 60Go à digitaliser. C'est mieux, mais c'est beaucoup. L'idéal serait quand même de pouvoir exporter les time-codes et les noms de K7 directement sous After.

Mais ta solution reste une bonne alternative,


Stéphane

 

C'est vrai... Cependant il ne faut pas oublier qu'After Effects est rarement utilisé dans ce genre de situation.

Les plus grosses boîtes de post-production l'utilisent, mais rarement pour ce que l'on pourrait considérer comme le traitement final.

ILM par exemple l'utilise énormément pour ses animatics, d'autres boîtes l'utilisent pour générer divers éléments, etc.
Mais After Effects est rarement utilisé pour le rendu final.
Principalement car il n'est pas conçu pour travailler avec du 2k ou du 4k. Biensûr, il peut gérer ça. Mais pas de manière optimale, comme le ferait des stations flame, inferno, ou encore Digital Fusion et Shake.
Et également car il ne peut pas travailler en floating point. Le 16bits, c'est vraiment juste pour travailler avec des images cineon. eLin permet bien de simuler ce traitement, mais le calcul continue à se faire en 16bits.

Ce que je veux dire (et tu l'as dit toi-même), c'est qu'After Effects n'est pas réellement conçu pour gérer ce genre de données.
Et ton problème avec le Time Code se pose surtout dans ce genre de cas.


PS: J'ai vu certains de tes films sur ton site. Il y a vraiment de très belles choses, félicitation.
PPS: J'ai bien aimé les voix françaises d'Harrison Ford, Whoopy Goldberg, Bruce Willis,...

EDIT: Après avoir relu mon message... j'ai l'impression que j'y dis absolument rien d'intéressant

 

Sans aller jusque là, on peut plus facilement se retrouver avec des rushes issues d'une Betanum pour faire de l'incruste sur fond vert par exemple.

Personnellement je n'ai jamais été confronté à du 2K ou plus, et je ne me suis jamais posé ce genre de questions. Je ne savais pas que After était limité à ce niveau, et Combustion il est en 16bit également ?

Je pense à un truc, After bosse en 3*8bits non ?

Merci pour ton message,


Stéphane

 

After Effects peut travailler soit en 8bits, soit en 16bits (seulement dans la version professionnelle). C'est en effet le nombre de bits par couche (3x8bits en RGB ou 4x8bits en RGBa).

After Effects n'est pas fait pour bosser avec des fichiers cineon. Pour pleins de raisons qu'il me serait trop long de détailler (pour ceux qui se sont intéressés à la question des espaces colorimétriques linéaires, c'est un peu la même chose, sauf que pleins d'autres facteurs entrent en jeu: gamma natif du film, gamma du format cineon (espace colorimétrique logarythmique), tranformation en espace colorimétrique "vidéo" (appellé généralement à tord log->lin, alors qu'en fait c'est tout sauf linéaire, contenu du gamma 2.2 ou 2.5 de la vidéo), éventuellement transformation en linéaire, modification du gamma due au projecteur, ...).

Et le fait est que la plupart des algorythmes s'occupant du format cineon sont fait pour travailler avec des moniteurs SGI (qui comprennent une correction gamma).

De plus, comme je l'ai déjà dit, le 8bits ou le 16bits sont nettement trop destrutifs pour ces nombreuses corrections gamma.

Si le sujet t'intéresse tu peux jetter un coup d'oeil ici: http://boards.theforce.net/Fan_Films/b10015/16680747/p3/?76

 

C'est intéressant, je ne me suis jamais posé la question. J'ai toujours bossé en vidéo, j'imagine que sur ce support il n'y a aucune différence ?

J'espère, sinon je vais rapidement devoir changer certaines de mes techniques de travail en postprod.

Stéphane

 

En fait, si
C'est le problème des images linéaires.

Une image "vidéo" a un gamma de 2.2 (ou 2.5) intégré. Le gamma est une fonction exponentielle. Quand on dit qu'une image a un gamma de 2.2, cela signifie que toutes ses valeurs sont élevées à la puissance 2.2.

Une image avec un gamma de 1 est une image dite linéaire. Si l'on représente l'image avec un graphique, nous avons une droite.
Une image avec un gamma de 2.2 ne sera pas une droite, mais un courbe.

Il y a pleins de conséquances, mais la plus importante, est la suivante: lors d'une opération mathématique, le résultat ne sera pas le même.

Imaginons par exemple que l'on ajoute 2 à une image linéaire. La droite sera seulement élevée vers le haut (toute l'image deviendra plus lumineuse); les zones claires et les zones sombres seront élevées de la même façon.
Maintenant dans le cas d'une image non-linéaire. Si l'on ajoute deux, proportionnellement à une image linéaire, certaines zones seront plus touchées que d'autres. On peut très vite le vérifier: as-tu déjà essayé d'utiliser le mode de transftert "Ajouter"? Si oui, je pense que tu sais parfaitement, que contrairement au mode de transfert "Ecran", ce mode "brule" très rapidement les blancs. Pourquoi? Car du à la forme de la courbe gamma, les blancs seront, proportionnellement, plus touchés.
Maintenant, si l'on converti l'image en linéaire, le mode de transftert "Ajouter" se comportera pratiquement comme le mode de transftert "Ecran". Certaines zones blanches seront également "brulées", mais nettement moins qu'avant!
Quel est l'intérêt? Dans la réalité, l'intensité des photons est toujours ajoutée. Si on a deux sources lumineuses, on a l'intensité des photons de la source 1 + l'intensité des photons de la source 2. C'est tout simplement du à la rétine... Si il y a un photon qui y arrive, puis un autre, l'intensité totale perçue sera celle du premier plus celle du deuxième. Logique, non?
Donc la lumière doit toujours être AJOUTEE. Par conséquant, utiliser le mode "Ecran" n'est pas réaliste. Et en non-linéaire, le mode "Ajouter" est faussé, et n'est donc pas non plus réaliste.
La seule façon REALISTE est d'utiliser "Ajouter" en linéaire.

After Effects ne supporte pas la possibilité de travailler en linéaire. On PEUT appliquer une correction gamma de 1/2.2 au début (qui transformera la courbe en une droite), faire les opérations, et appliquer une correction gamma de 2.2 à la fin. Nous travaillerons ainsi en linéaire.
Cependant, en pratique, travailler en linéaire demande d'autres choses: premièrement de travailler en floating point (donc avec des valeurs de 0 à 1, pratiquement une infinitée, donc), car le 8bits et le 16bits sont trop destructifs pour pouvoir se permettre ces changements de gamma (mathématiquement, on peut très bien appliquer une infinité de corrections gamma sans dégrader l'image; mais en 8bits, il y a de nombreux arrondissements, qui vont dégrader l'image). Deuxièmement il y a également une gestion HDR. En gros, on essaie de conserver les valeurs qui sont plus grandes que 1 (donc plus blanches que blanches), pour ne pas perdre d'informations (un exemple typique serait d'augmenter la luminosité d'une image puis de la diminuer; si les valeurs supérieures à 1 ne sont pas conservées, en diminuant la luminosité on perd les zones blanches). Et troisièmement il y a aussi l'hypercompression. Au final, on est obligé de couper les valeurs supérieures à 1. L'hypercompression permet, en gros, d'adoucir cet effet, en plaçant, par exemple, les valeurs de 0 à 1 entre 0 et 0.95, et en plaçant les valeurs de 1 à la valeur maximale de 0.95 à 1.
Un programme pouvant travailler en vrai linéaire inclu généralement tout ceci.

Si le sujet t'intéresse, je peux te passer pas mal de documentation.

 

Merci beaucoup pour ta proposition !

Le seul truc, c'est que je suis assez matérialiste ... concrètement, est-ce que ça va améliorer mon étalonnage ou mes incrustes pour de la vidéo ?

Dans le cas contraire, d'ici à ce que je réalise un long nécessitant des SFX en 4K, à mon avis, ce n'est pas moi qui vais me taper le compositing.


Stéphane