Gestion des couleurs ACES : garder des couleurs cohérentes de la station de travail à la render farm

Introduction

Si vous avez cherché « couleur ACES » ou « Academy Color Encoding System », voici la réponse courte : l'ACES est un cadre ouvert et gratuit qui donne à chaque image d'une production, qu'elle provienne d'une caméra, d'un moteur de rendu 3D ou d'un logiciel de compositing, une même référence quant à la signification de ses couleurs. L'Academy of Motion Picture Arts and Sciences l'a développé et maintenu pendant plus de dix ans, et en août 2025 il est passé sous l'égide de l'Academy Software Foundation (ASWF), avec un comité de pilotage technique ouvert (communiqué de presse de l'Academy, consulté le 13 octobre 2026).

Ce guide explique l'ACES en langage clair, sans approximation : les principaux espaces colorimétriques, les transformations d'entrée et de sortie, ce qui a changé dans l'ACES 2.0, et la manière dont OpenColorIO (OCIO) l'apporte dans votre logiciel 3D. Il aborde ensuite ce que la plupart des explications passent sous silence : ce qu'il advient de la couleur lorsqu'une scène quitte votre station de travail et est rendue sur d'autres machines, avec une checklist à parcourir avant d'envoyer un job. Pour savoir ce qu'est le rendu lui-même, consultez notre guide des fondamentaux du rendu.

Ce qu'est l'ACES, et le problème qu'il résout

L'Academy décrit l'ACES comme un cadre open source de gestion des couleurs et d'échange d'images couvrant tout le cycle de vie d'une production cinématographique. Il comprend trois types d'éléments : des encodages (les espaces colorimétriques), des transformations (les calculs qui amènent une image vers l'ACES, puis de l'ACES vers un écran) et des spécifications, comme l'ACES Metadata File (AMF) et les Transform IDs. L'ACES2065-1 est normalisé sous la référence SMPTE ST 2065-1:2021, et la documentation de l'ACES précise que des dizaines d'entreprises ont intégré des composants ACES à leurs outils (documentation ACES, consultée le 13 octobre 2026).

Le problème est simple. Chaque appareil a sa propre idée de ce que signifie une valeur de pixel : une caméra enregistre dans l'encodage de son fabricant, une texture arrive en sRGB, un moteur de rendu calcule dans son espace de travail, et chaque moniteur a un gamut légèrement différent. Sans référence commune, les mêmes nombres désignent des couleurs différentes selon l'endroit. L'ACES joue le rôle de contrat : chaque source est convertie une seule fois, par une transformation connue, vers une référence commune ; le travail s'effectue dans cet espace ; une transformation connue fait ensuite correspondre le résultat à chaque écran. Ce n'est pas un filtre qui embellit les rendus. Sa valeur est la cohérence, ce qui est exactement l'enjeu lorsqu'une scène passe d'une machine à l'autre.

Les espaces colorimétriques de base : ACES2065-1, ACEScg et ACEScct

Sources : pages ACES2065-1, ACEScg et ACEScct, consultées le 13 octobre 2026.

• L'ACEScg est linéaire et référencé à la scène. Ses valeurs encodent directement l'exposition relative. Les valeurs négatives sont valides et il est préférable de les conserver ; les valeurs bien supérieures à 1,0 sont normales et ne doivent pas être écrêtées, sauf lors d'une correction colorimétrique volontaire.
• L'ACEScg existe à cause des mathématiques de la CG. La documentation explique que les calculs de CGI traitent souvent le RVB comme une réflectance, ce qui se comporte mal avec les primaires AP0, très larges. L'ACEScg utilise les primaires AP1, plus petites (rouge 0,713 / 0,293 ; vert 0,165 / 0,830 ; bleu 0,128 / 0,044) et le même point blanc (CIE xy 0,32168 / 0,33767). Le passage de l'un à l'autre se fait par une matrice fixe.
• L'ACEScct n'est pas un espace de rendu. La documentation le qualifie de transitoire et interne au logiciel ou au matériel. Un moteur de rendu travaille en ACEScg ; un outil d'étalonnage peut passer en ACEScct.

La règle pratique : effectuez le rendu et le compositing en ACEScg, et considérez l'ACES2065-1 comme la forme d'échange lorsqu'un studio la demande.

Transformations d'entrée et de sortie : les deux extrémités du pipeline

Entre le monde extérieur et votre espace de travail ACEScg se trouvent deux types de transformations.

• Les transformations d'entrée convertissent une source vers l'espace de travail. Une texture en nécessite une qui correspond à la manière dont elle a été enregistrée, généralement sRGB pour les images couleur. Dans un logiciel 3D, il s'agit du champ espace colorimétrique d'entrée (input color space) de chaque nœud d'image.
• Les transformations de sortie prennent des données ACES linéaires de scène (scene-linear) et les préparent pour un écran, en appliquant au passage un mappage tonal et un mappage de gamut (À propos du rendu, consulté le 13 octobre 2026). Dans un logiciel 3D, il s'agit du réglage transformation de vue (view transform) ou affichage (display) dans la vue 3D et la fenêtre de rendu.

Le point qui compte le plus pour le rendu sur une render farm : la transformation de vue sert à regarder l'image. L'image elle-même doit rester linéaire de scène.

Pipeline ACES : les textures et les images de caméra passent par des transformations d'entrée vers l'ACEScg pour le rendu, un EXR linéaire est enregistré, et une transformation de sortie adapte l'image à l'écran

Ce qui a changé dans l'ACES 2.0

Le journal des modifications du projet date l'ACES 2.0 du 4 avril 2025 (CHANGELOG d'aces-core, consulté le 13 octobre 2026). La documentation de l'ACES place au cœur de cette version une suite repensée de transformations de rendu (À propos de l'ACES 2, consultée le 13 octobre 2026) :

• De nouvelles transformations de sortie, avec une courbe tonale moins agressive, un contraste des tons moyens réduit et une atténuation des hautes lumières plus douce que dans l'ACES 1.x.
• Un mappage de gamut plus robuste, avec moins d'artefacts d'écrêtage.
• Des paramètres plus intuitifs pour les écrans atypiques, des préréglages d'affichage et des transformations inverses optimisées.

Qu'est-ce que cela change pour la CG ? Les pages que nous avons lues situent le changement à l'extrémité affichage du pipeline, et nous n'avons trouvé aucune mention d'une modification de l'encodage ACEScg lui-même. En pratique, un même EXR linéaire de scène peut avoir un aspect différent à l'écran selon qu'il est visualisé via une transformation de sortie ACES 1.x ou ACES 2.0. Si votre station de travail prévisualise avec l'une et un nœud de la render farm avec l'autre, vous comparez deux aspects différents des mêmes données.

Une remarque sur les numéros de version. La documentation d'OpenColorIO répertorie désormais des configurations intégrées nommées aces-v2.1 pour OCIO 2.6 et les versions ultérieures, et OCIO 2.6.0 a été publié le 1er octobre 2026 (configuration OCIO Studio et versions d'OCIO, consultées le 13 octobre 2026). Les sources ACES que nous avons lues ne mentionnent aucune entrée 2.1 ; nous considérons donc la 2.0 comme la dernière version que nous avons pu vérifier auprès de la source ACES primaire. Lisez plutôt le numéro de version dans le nom de votre propre configuration au lieu de le supposer.

Comment OpenColorIO apporte l'ACES dans votre logiciel

L'ACES définit les calculs de couleur ; OpenColorIO est la manière dont votre application les utilise. OCIO est un projet de l'Academy Software Foundation, décrit comme une solution complète de gestion des couleurs conçue pour la production cinématographique (documentation OpenColorIO, consultée le 13 octobre 2026). Un fichier de configuration définit les espaces colorimétriques disponibles, les rôles sur lesquels une application s'appuie (comme l'espace de rendu), ainsi que les affichages et les vues. La plupart des applications permettent de le choisir dans les préférences, et une variable d'environnement OCIO indique le chemin du fichier de configuration à utiliser (Utiliser OCIO, consulté le 13 octobre 2026).

OCIO fournit aussi des configurations intégrées, référencées par leur nom plutôt que par un chemin. La configuration CG est un jeu allégé destiné aux applications DCC courantes, par exemple ocio://cg-config-v4.0.0_aces-v2.0_ocio-v2.5. La configuration Studio contient l'ensemble complet des espaces colorimétriques, affichages et vues ACES, par exemple ocio://studio-config-v4.0.0_aces-v2.0_ocio-v2.5. Le nom se lit ainsi : type de configuration, version de la configuration, version de l'ACES et version minimale d'OCIO. Comme elles sont intégrées, aucun fichier LUT externe n'est nécessaire (configuration CG et page de la configuration Studio, consultées le 13 octobre 2026).

Chaque application met cela en place à sa façon. Voici ce que dit la documentation des éditeurs (toutes les pages consultées le 13 octobre 2026) :

Les valeurs par défaut diffèrent selon l'application et la version, et certains des réglages qui déterminent votre couleur se trouvent hors du fichier de scène, dans une variable d'environnement ou un chemin sur votre propre disque. C'est là que les ennuis commencent. Pour le cycle Cinema 4D 2026, consultez notre récapitulatif des nouveautés.

Où la couleur déraille lorsqu'une scène quitte votre station de travail

Sur votre propre machine, la gestion des couleurs tient grâce à des éléments que vous ne voyez jamais : une variable d'environnement, un fichier de préférences, une configuration dans un dossier créé il y a un an. Un nœud de rendu n'a rien de tout cela, sauf si la scène ou la render farm le fournit. Sur une render farm gérée, vous envoyez un projet et vous recevez des images sans vous connecter aux machines ; vous ne pouvez donc pas définir discrètement une variable sur le nœud comme vous le faites sur votre poste. Quatre défaillances méritent d'être vérifiées en premier.

1. Une configuration OCIO différente ou absente. La variable OCIO vit dans l'environnement de la machine qui la définit, pas dans le fichier de scène, et les documents Cinema 4D enregistrent un chemin vers la configuration. Un chemin vers un disque de votre station de travail n'aide que si la machine qui ouvre la scène peut lire le même fichier. Dans le cas contraire, l'application peut signaler des espaces colorimétriques inconnus ou se rabattre sur une autre configuration, et le résultat ne correspond plus à ce que vous aviez validé. Des configurations embarquant des versions d'ACES différentes provoquent une version plus discrète du même problème.

2. Espaces colorimétriques d'entrée des textures mal étiquetés. Les textures couleur comme les JPEG et PNG doivent être lues en sRGB, les images HDR linéaires en linéaire de scène, et les cartes de données (normales, rugosité, masques) en brut (raw) ou non-couleur (non-color). La page Arnold pour Maya d'Autodesk recommande exactement cette répartition, et la documentation de Redshift avertit que sa conversion automatique peut se tromper ; il faut donc vérifier chaque asset. Une mauvaise étiquette ne s'annonce pas : les couleurs paraissent délavées ou trop sombres, ou une carte de rugosité modifie discrètement le matériau. Une render farm rend ce que dit la scène, image après image.

3. Une transformation de vue intégrée définitivement à la sortie. La documentation de Maya indique que la vue OCIO n'est pas appliquée aux fichiers d'image rendus, sauf si l'option Apply Output Transform to Renderer est activée. Si une transformation d'affichage est intégrée définitivement à vos images et que votre logiciel de compositing en applique une autre, l'image est transformée deux fois : le contraste s'écrase, les hautes lumières s'écrêtent, et il est difficile de revenir en arrière.

4. Une sortie 8 bits référencée à l'affichage au lieu d'un EXR linéaire. OpenEXR est conçu pour représenter des données d'image HDR linéaires de scène (OpenEXR, consulté le 13 octobre 2026). Un PNG ou un JPEG 8 bits contient des valeurs prêtes pour l'affichage et ne peut pas porter les valeurs supérieures à 1,0 qu'attend l'ACEScg ; effectuer le vrai job en 8 bits fait donc perdre le détail des hautes lumières et la possibilité de réétalonner. Notre guide EXR et Cryptomatte explique comment sont structurés les fichiers EXR multicouches.

Quatre façons dont la couleur dérive entre une station de travail et une render farm : configuration incohérente, mauvais espace d'entrée, transformation de vue intégrée définitivement et sortie 8 bits

Une checklist avant envoi pour des couleurs cohérentes

Sept points prennent quelques minutes et coûtent bien moins cher que de découvrir un écart à l'image 800.

1. Notez votre configuration. Relevez si la scène utilise un nom intégré ocio:// ou un chemin de fichier, lisez la version d'ACES dans le nom, et notez si une variable OCIO de votre station de travail la fournit. Cette variable ne voyagera pas avec la scène.
2. Définissez l'espace de travail dans le projet. Choisissez explicitement l'espace de rendu (ACEScg pour la plupart des pipelines CG) au lieu de vous fier à une valeur par défaut. Dans Cinema 4D, n'oubliez pas qu'un document peut être en mode hérité (legacy).
3. Vérifiez l'étiquette de chaque texture. Images couleur en sRGB, HDR linéaires en linéaire de scène, cartes de données en brut (raw). Contrôlez par échantillonnage quelques matériaux.
4. Réservez la transformation de vue à la visualisation. Vérifiez qu'aucune transformation d'affichage n'est intégrée définitivement à la sortie, sauf si votre pipeline l'exige.
5. Produisez un EXR linéaire de scène pour le job réel. Réservez les formats 8 bits aux aperçus, et notez l'espace colorimétrique de l'EXR pour votre logiciel de compositing.
6. Empaquetez le projet intégralement. Envoyez le dossier du projet non compressé, avec le fichier de scène et tous les assets référencés en place. Si vous utilisez une configuration personnalisée ou propre à un studio, informez-en la render farm à l'avance.
7. Rendez une image en test. Ouvrez le rendu de la station de travail et celui de la render farm dans la même visionneuse, avec la même transformation de vue, et comparez quelques valeurs de pixels avec une pipette de couleur en plus de l'œil. De petites différences dues à l'échantillonnage ou au débruitage sont normales ; un décalage visible de teinte ne l'est pas.

Checklist couleur avant envoi en sept étapes : configuration, espace de travail, étiquettes de texture, transformation de vue, sortie EXR, projet empaqueté, image de test

Tester une image sur une render farm gérée

Super Renders Farm est une render farm cloud entièrement gérée : vous ne vous connectez pas aux machines, vous n'y installez aucun logiciel et vous ne gérez pas vous-même les licences. C'est pratique, et c'est aussi la raison pour laquelle la checklist compte : tout ce que votre station de travail tire de son propre environnement doit être transporté par la scène et par les fichiers que vous envoyez.

Il n'existe pas de liste de compatibilité publiée par configuration pour les setups OCIO personnalisés. Si votre pipeline dépend d'une configuration propre à un studio, contactez le support avant l'envoi, via le chat en direct 24h/24 et 7j/7 ou à l'adresse supportcenter@superrendersfarm.com, et joignez la configuration avec un test sur une seule image. Une règle d'envoi compte ici : la render farm n'extrait pas les archives (.zip, .rar, .7z, .tar, .tar.gz), donc rien de ce qui se trouve dans une archive n'est rendu.

Une image de test est un petit job. Les nouveaux comptes reçoivent 25 $ de crédits de rendu gratuits, et la manière dont l'utilisation est facturée est expliquée sur la page des tarifs. Pour les scènes Cinema 4D et Redshift, la soumission des jobs est décrite sur notre page de render farm cloud pour Cinema 4D ; les pages Redshift, Maya et Blender couvrent ces applications.

FAQ

Q: Que signifie ACES ? A: ACES signifie Academy Color Encoding System, un cadre ouvert de gestion des couleurs et d'échange d'images créé par l'Academy of Motion Picture Arts and Sciences et maintenu par l'Academy Software Foundation depuis août 2025.

Q: Quelle est la différence entre l'ACES2065-1 et l'ACEScg ? A: Les deux sont linéaires et partagent le même point blanc. L'ACES2065-1 utilise les primaires AP0, très larges, et constitue l'encodage de base défini par la norme SMPTE ST 2065-1. L'ACEScg utilise les primaires AP1, plus petites, et c'est l'espace de travail destiné au rendu et au compositing de CG.

Q: Ai-je besoin de l'ACES pour utiliser une render farm ? A: Non. Tout pipeline colorimétrique cohérent convient, y compris un simple pipeline sRGB linéaire. Ce qui compte, c'est que la scène, les textures et les réglages de sortie soient explicites et identiques sur chaque machine qui touche au job. L'ACES est populaire parce que c'est une norme documentée et partagée.

Q: Qu'est-ce qui a changé dans l'ACES 2.0 ? A: Le principal changement est un ensemble repensé de transformations de rendu et de sortie, avec une courbe tonale plus douce et un mappage de gamut plus robuste. La version est datée du 4 avril 2025 dans le journal des modifications du projet. La documentation que nous avons lue décrit des changements à l'extrémité affichage du pipeline, et non un nouvel encodage ACEScg.

Q: Pourquoi mon rendu est-il différent sur la render farm et sur ma station de travail ? A: Les causes habituelles sont une configuration OCIO différente ou absente, des textures étiquetées avec un mauvais espace colorimétrique d'entrée, une transformation de vue intégrée définitivement à la sortie, ou un format de sortie 8 bits. Vérifiez-les dans cet ordre, puis rendez une image de test et comparez-la au rendu de votre station de travail dans la même visionneuse.

Q: Dois-je rendre en EXR ou en PNG ? A: Rendez le job de production en EXR linéaire de scène et réservez la transformation d'affichage à la visualisation et à la livraison finale. Utilisez PNG ou JPEG pour les aperçus, car les fichiers 8 bits contiennent des valeurs prêtes pour l'affichage et ne peuvent pas porter de valeurs supérieures à 1,0.

Q: Est-ce que Super Renders Farm prend en charge les configurations OCIO personnalisées ? A: Il n'existe pas de liste de compatibilité publiée pour les configurations personnalisées. Si votre pipeline en utilise une, contactez le support via le chat en direct 24h/24 et 7j/7 ou par e-mail avant l'envoi, et joignez un test sur une seule image à comparer avec le rendu de votre station de travail.