Vous avez sans doute vu passer le terme « ACES » ces derniers temps. Le fameux « Academy Color Encoding System » mis en place sous l’égide de l’Academy of Motion Picture Arts and Sciences (qui organise également les Oscars) peut intimider, et le site officiel, très documenté, peut faire peur au néophyte.
L’infographiste Mathieu Maurel nous propose du coup une version accessible de cette approche. L’idée : aller droit au but, et vous aider à comprendre comment utiliser ce systèmes en 9 étapes.
En fin de tutoriel, vous trouverez des liens et ressources pour aller plus loin.
Liens et ressources :
- Chris Brejon – CG Cinematography ;
- Toadstorm Nerdblog – « An Idiot’s Guide to ACES » ;
- Saul Spinoza sur Patreon ;
- Johnny Fehr – ACES Workflow in Maya with Redshift and Arnold :
5 commentaires
Ce tuto est une bonne chose s’il peut aider à démocratiser l’aces. Ceci dit tu éludes un bon nombre (sinon toutes) les problématiques pour l’intégrer dans un pipeline de prod.
Photoshop (et adobe plus généralement) ne permet que depuis trèèès récemment l’usage d’aces en natif, avant il fallait littéralement faire des ronds de chapeaux.
De meme qu’il faut quelqu’un au sein de la boite qui sera dédié au color pipeline. T’as pas idée du nombres de personnes qui collent un bump, roughness ou n’importe quelle map scalaire en sRGB (ou en tous cas en gamma 2) en 3d. Pour le compositing c’est encore pire. Je vois encore aujourd’hui des gens se démener pour tenter de faire un comp build sauf que leur composantes sont en gamma 2.
il faut aussi ajouter – et on le voit bien sur ton rendu de fin – que le sRGB aces n’a pas tout a fait la meme curve que le sRGB IEC du coup l’image en ressort plus contrastée, plus sombre aussi et parfois plus saturée ce qui peut déconcerter au début.
Enfin, aces implique que le color pipeline soit tenu de bout en bout, de la video / photo en log ou sRGB, jusqu’à l’output éventuellement en rec2020 en travaillant avec du raw, du linear au milieu voire du aces cc / cct. Et là tu perds pas mal de mondes avec les idt/odt quand il faut passer d’un color space à un autre.
Enfin il y a la problèmatique « informatique », il faut déployer des variables d’environnement pour que les différentes appz (nuke etc) trouvent les configurations, il faut écrire ses propres tables de correspondance si tu veux pas que l’utilisateur mongolise entre les color spaces et que ça se fasse tout seul en fonction du nom du fichier etc.
Pour pas mal de monde c’est encore un peu prématuré.
[USER=13459]@malikarn[/USER] Le but de Mathieu était juste de poser les bases pour les gens qui sont un peu déboussolés ou veulent une intro. Très clairement, pour les pros du pipe, un tuto d’une page ne suffit pas, et se plonger dans les ressources plus touffues (comme celles données en fin d’article) est indispensable. Et ça fait partie de leur métier. 🙂
Il faut vraiment voir ça comme un « ACES pour les nuls », un peu comme un article « comment un film d’animation est fait » n’a pas vocation à enseigner l’animation.
Hello.
Bien sur shadow et de ce point de vue son tuto est une bonne chose. Ce que je critique, c’est davantage l’aces lui-même.
Dans l’agence pour laquelle je travaillais, nous avons tenté de le mettre en place sur un projet « pilote », pour tester. C’est extrêmement difficile de garder un color pipeline correct de bout en bout. En particulier sur les workflow basés sur des assets et donc des bibliothèques. Il faut tout reprendre sans exception, la moindre texture, le moindre élément intégré en comp ou motion graphics.
Il faut aussi former l’utilisateur qui jusqu’ici est très satisfait de son sRGB sous adobe ou de son managed color worklow sous resolve pour n’en citer que deux.
En corolaire et puisque la courbe de réponse sRGB est un peu différente, ce sont aussi toutes les LUT perso de « look » ou finishing à reprendre.
C’est très fastidieux et ça nous a considérablement ralenti sur le projet en question.
Sans parler de l’impact sur les temps de calcul. A titre d’exemple, la doc vray stipule bien que le node OCIO ralenti le traitement des textures… Max étant ce qu’il est, il n’a pas de colorpipeline tel que celui de maya par exemple. Donc il faut surcharger le colorspace pour chaque texture. C’est pas pratique.
[ATTACH]40616[/ATTACH]
Et pour finir, c’est pénible à automatiser pour un directeur technique car cela impacte tous les outils graphiques, et pas juste max, toshop, nuke ou substance painter. Absolument tous. On peut néanmoins se féliciter que depuis la version 2020 les outils adobe proposent l’aces. Ce n’était pas le cas il y a peu.
[USER=13459]@malikarn[/USER] en effet, pas évident de gérer une telle évolution qui touche tous les maillons. Je n’ose imaginer la masse de travail technique.
Au final, est-ce que l’agence a tout de même persévéré sur les projets suivants ?
Non.
Deja parce que l’agence bosse principalement avec max et tant que ce dernier ne propose pas un system « built in » de color pipeline, prenant en charge bien sur OCIO, c’est trop contraignant car il faut attaquer toutes les bibliothèques d’objets à la mano (ou en script…). et surcharger le colospace des exr en sortie ce qui est possible avec vray ou arnold mais pas corona par exemple. Pour ce dernier, si l’on souhaite conserver le gammut exceptionnel 2065-1 d’aces, il faut d’abord sortir en full float et – avec les composantes de rendu – ca fait des fichiers excessivement lourds.
Ou alors tu output un exr 16bit qui viendra avec un sRGB IEC et sera donc « un peu différent » une fois converti en ACES cg car certaines informations seront perdues puisque le gammut sRGB est plus étroit que l’aces cg. Bref selon l’industrie visée, c’est un peu prématuré. En l’occurence en archviz.
Adobe c’est différent car il prend en charge désormais l’aces, tout comme nuke (depuis longtemps par ailleurs). Mais ce n’était pas le cas au moment du « projet test ».
++