Gestão de cor ACES explicada: manter a cor consistente da estação de trabalho à render farm

Introdução

Quem pesquisou por «cor ACES» ou «Academy Color Encoding System» encontra aqui a resposta curta: o ACES é um framework livre e aberto que dá a todas as imagens de uma produção, quer venham de uma câmara, de um renderizador 3D ou de um programa de composição, uma referência partilhada sobre o que as suas cores significam. A Academy of Motion Picture Arts and Sciences desenvolveu-o e manteve-o durante mais de uma década e, em agosto de 2025, passou para a Academy Software Foundation (ASWF), sob um comité de direção técnica aberto (comunicado de imprensa da Academy, consultado a 13 de outubro de 2026).

Este guia explica o ACES em linguagem simples, sem simplificações erradas: os principais espaços de cor, as transformações de entrada e de saída, o que mudou no ACES 2.0 e como o OpenColorIO (OCIO) o disponibiliza dentro do software 3D. Depois aborda a parte que a maioria das explicações ignora: o que acontece à cor quando uma cena sai da estação de trabalho e é renderizada noutras máquinas, com uma lista de verificação para percorrer antes de submeter um trabalho. Para saber o que é o rendering em si, consulte o nosso guia de fundamentos do rendering.

O que é o ACES e o problema que resolve

A Academy descreve o ACES como um framework open source para gestão de cor e intercâmbio de imagens ao longo de todo o ciclo de vida da produção cinematográfica. Tem três tipos de componentes: codificações (os espaços de cor), transformações (a matemática que leva uma imagem para o ACES e do ACES para um ecrã) e especificações, como o ACES Metadata File (AMF) e os Transform IDs. O ACES2065-1 está normalizado como SMPTE ST 2065-1:2021, e a documentação do ACES refere que dezenas de empresas integraram componentes ACES nas suas ferramentas (documentação do ACES, consultada a 13 de outubro de 2026).

O problema é simples. Cada dispositivo tem a sua própria ideia do que significa um valor de pixel: uma câmara grava na codificação do fabricante, uma textura chega em sRGB, um renderizador calcula no seu espaço de trabalho e cada monitor tem uma gama de cores (gamut) ligeiramente diferente. Sem uma referência partilhada, os mesmos números significam cores diferentes em sítios diferentes. O ACES funciona como um contrato: cada fonte é convertida uma única vez, através de uma transformação conhecida, para uma referência comum; o trabalho faz-se aí; e uma transformação conhecida leva o resultado a cada ecrã. Não é um filtro que faz os renders parecerem melhores. O seu valor é a consistência, que é exatamente o que está em jogo quando uma cena passa de uma máquina para outra.

Os espaços de cor principais: ACES2065-1, ACEScg e ACEScct

Fontes: as páginas ACES2065-1, ACEScg e ACEScct, consultadas a 13 de outubro de 2026.

• O ACEScg é linear e referido à cena (scene-referred). Os seus valores codificam diretamente a exposição relativa. Os valores negativos são válidos e, idealmente, devem ser mantidos, e os valores bem acima de 1,0 são esperados e não devem ser cortados (clamp), exceto durante uma correção de cor deliberada.
• O ACEScg existe por causa da matemática do CG. A documentação explica que os cálculos de CGI tratam frequentemente o RGB como refletância, o que se comporta mal com as primárias AP0, muito largas. O ACEScg usa as primárias AP1, mais pequenas (vermelho 0,713 e 0,293; verde 0,165 e 0,830; azul 0,128 e 0,044) e o mesmo ponto branco (CIE xy 0,32168 e 0,33767). A conversão entre os dois é uma matriz fixa.
• O ACEScct não é um espaço de renderização. A documentação classifica-o como transitório e interno ao software ou ao hardware. Um renderizador trabalha em ACEScg; uma ferramenta de grading pode mudar para ACEScct.

A regra prática: renderizar e compor em ACEScg e tratar o ACES2065-1 como forma de intercâmbio, caso um estúdio o peça.

Transformações de entrada e de saída: as duas pontas do pipeline

Entre o mundo exterior e o espaço de trabalho ACEScg existem dois tipos de transformação.

• As transformações de entrada convertem uma fonte para o espaço de trabalho. Uma textura precisa de uma que corresponda à forma como foi guardada, normalmente sRGB para imagens de cor. No software 3D, este é o campo input color space em cada nó de imagem.
• As transformações de saída pegam em dados ACES scene-linear e preparam-nos para um ecrã, aplicando tone mapping e gamut mapping pelo caminho (About rendering, consultado a 13 de outubro de 2026). No software 3D, corresponde à definição view transform ou display na viewport e na janela de render.

O ponto que mais importa na renderização em render farm: a view transform serve para observar a imagem. A própria imagem deve permanecer scene-linear.

Pipeline ACES: as texturas e o material de câmara passam por transformações de entrada para o ACEScg para renderização, o EXR linear é guardado e uma transformação de saída leva a imagem ao ecrã

O que mudou no ACES 2.0

O registo de alterações do projeto data o ACES 2.0 de 4 de abril de 2025 (CHANGELOG do aces-core, consultado a 13 de outubro de 2026). A documentação do ACES coloca no centro da versão um conjunto redesenhado de transformações de renderização (About ACES 2, consultado a 13 de outubro de 2026):

• Novas Output Transforms com uma escala tonal menos agressiva, menor contraste nos meios-tons e uma atenuação mais suave das altas-luzes do que no ACES 1.x.
• Gamut mapping mais robusto, com menos artefactos de clipping.
• Parâmetros mais intuitivos para ecrãs fora do comum, presets de ecrã e transformações inversas otimizadas.

O que muda isto para o CG? As páginas que consultámos situam a mudança na extremidade do ecrã do pipeline, e não encontrámos qualquer afirmação de que a própria codificação ACEScg tenha mudado. Na prática, o mesmo EXR scene-linear pode ter aspeto diferente no ecrã consoante seja visualizado através de uma output transform do ACES 1.x ou do ACES 2.0. Se a estação de trabalho pré-visualiza com uma e um nó da render farm com a outra, comparam-se dois aspetos dos mesmos dados.

Uma nota sobre as etiquetas de versão. A documentação do OpenColorIO lista agora configs incorporadas com a etiqueta aces-v2.1 para o OCIO 2.6 e posteriores, e o OCIO 2.6.0 foi publicado a 1 de outubro de 2026 (config OCIO Studio e versões do OCIO, consultadas a 13 de outubro de 2026). As fontes do ACES que consultámos não listam uma entrada 2.1, pelo que tratamos o 2.0 como a última versão que conseguimos verificar na fonte primária do ACES. Convém ler a versão no nome da própria config, em vez de a presumir.

Como o OpenColorIO disponibiliza o ACES dentro do software

O ACES define a matemática da cor; o OpenColorIO é a forma como a aplicação a utiliza. O OCIO é um projeto da Academy Software Foundation, descrito como uma solução completa de gestão de cor orientada para a produção cinematográfica (documentação do OpenColorIO, consultada a 13 de outubro de 2026). Um ficheiro de configuração define os espaços de cor disponíveis, os papéis (roles) de que uma aplicação depende (como o espaço de renderização) e os ecrãs e as vistas. A maioria das aplicações permite escolhê-lo nas preferências, e uma variável de ambiente OCIO indica o caminho do ficheiro da config a usar (Using OCIO, consultado a 13 de outubro de 2026).

O OCIO inclui também configs incorporadas (built-in), referenciadas por nome em vez de caminho. A config CG é um conjunto leve para aplicações DCC típicas, por exemplo ocio://cg-config-v4.0.0_aces-v2.0_ocio-v2.5. A config Studio traz o conjunto completo de espaços de cor, ecrãs e vistas do ACES, por exemplo ocio://studio-config-v4.0.0_aces-v2.0_ocio-v2.5. O nome lê-se como tipo de config, versão da config, versão do ACES e versão mínima do OCIO. Por estarem incorporadas, não são precisos ficheiros LUT externos (config CG e páginas da config Studio, consultadas a 13 de outubro de 2026).

Cada aplicação liga isto de forma diferente. O que diz a documentação dos próprios fabricantes (todas as páginas consultadas a 13 de outubro de 2026):

Os valores por defeito variam consoante a aplicação e a versão, e algumas das definições que determinam a cor vivem fora do ficheiro de cena, numa variável de ambiente ou num caminho no próprio disco. É aí que os problemas começam. Para o ciclo 2026 do Cinema 4D, consulte o nosso resumo das novidades.

Onde a cor corre mal quando uma cena sai da estação de trabalho

Na própria máquina, a gestão de cor é sustentada por coisas que nunca se veem: uma variável de ambiente, um ficheiro de preferências, uma config numa pasta criada há um ano. Um nó de renderização não tem nada disso, a menos que a cena ou a render farm o forneça. Numa render farm gerida, envia-se um projeto e recebem-se frames sem iniciar sessão nas máquinas, pelo que não é possível definir discretamente uma variável no nó como se faz no desktop. Quatro falhas merecem ser verificadas primeiro.

1. Uma config OCIO diferente ou em falta. A variável OCIO vive no ambiente da máquina que a define, não no ficheiro de cena, e os documentos do Cinema 4D guardam um caminho para a config. Um caminho para uma unidade do disco da estação de trabalho só serve se a máquina que abre a cena conseguir ler o mesmo ficheiro. Quando não consegue, a aplicação pode indicar espaços de cor desconhecidos ou recorrer a outra config, e o resultado deixa de corresponder ao que foi aprovado. Configs com versões diferentes do ACES causam uma versão mais subtil do mesmo problema.

2. Espaços de cor de entrada das texturas mal etiquetados. As texturas de cor, como JPEG e PNG, devem ser lidas como sRGB, as imagens HDR lineares como scene-linear, e os mapas de dados (normais, rugosidade, máscaras) como raw ou non-color. A página Arnold for Maya da Autodesk recomenda exatamente esta divisão, e a documentação do Redshift avisa que a sua conversão automática pode falhar, pelo que cada asset deve ser verificado. Uma etiqueta errada não se anuncia: as cores ficam desbotadas ou demasiado escuras, ou um mapa de rugosidade altera discretamente o material. Uma render farm renderiza o que a cena diz, frame após frame.

3. Uma view transform incorporada na saída. A documentação do Maya diz que a vista OCIO não é aplicada aos ficheiros de imagem renderizados, a menos que Apply Output Transform to Renderer esteja ativada. Se uma transformação de ecrã ficar incorporada (baked) nos frames e o compositor aplicar outra, a imagem é transformada duas vezes: o contraste fica esmagado, as altas-luzes sofrem clipping e é difícil desfazer.

4. Saída de 8 bits referida ao ecrã (display-referred) em vez de EXR linear. O OpenEXR foi concebido para representar dados de imagem scene-linear de alta gama dinâmica (OpenEXR, consultado a 13 de outubro de 2026). Um PNG ou JPEG de 8 bits contém valores prontos para ecrã e não consegue transportar os valores acima de 1,0 que o ACEScg espera, pelo que renderizar o trabalho real para 8 bits deita fora o pormenor das altas-luzes e a possibilidade de voltar a fazer o grading. O nosso guia de EXR e Cryptomatte explica como se estruturam os ficheiros EXR multicamada.

Quatro formas de a cor se desviar entre uma estação de trabalho e uma render farm: incompatibilidade de config, espaço de entrada errado, view transform incorporada e saída de 8 bits

Lista de verificação pré-envio para uma cor consistente

Sete pontos demoram poucos minutos e custam muito menos do que descobrir uma discrepância no frame 800.

1. Registar a config. Anotar se a cena usa um nome ocio:// incorporado ou um caminho de ficheiro, ler a versão do ACES no nome e anotar se uma variável OCIO da estação de trabalho a fornece. Essa variável não acompanha a cena.
2. Definir o espaço de trabalho dentro do projeto. Escolher o espaço de renderização de forma explícita (ACEScg na maioria dos pipelines de CG) em vez de depender de um valor por defeito. No Cinema 4D, lembrar que um documento pode estar em modo legacy.
3. Verificar a etiqueta de todas as texturas. Imagens de cor como sRGB, HDR linear como scene-linear, mapas de dados como raw. Fazer uma verificação por amostragem de alguns materiais.
4. Reservar a view transform para a visualização. Confirmar que nenhuma transformação de ecrã fica incorporada na saída, a menos que o pipeline o exija.
5. Produzir EXR scene-linear no trabalho real. Usar formatos de 8 bits apenas para pré-visualizações e registar o espaço de cor do EXR para o compositor.
6. Empacotar o projeto por completo. Enviar a pasta do projeto descompactada, com o ficheiro de cena e todos os assets referenciados no lugar. Se se usar uma config personalizada ou de estúdio, informar previamente a render farm.
7. Renderizar um frame de teste. Abrir o render da estação de trabalho e o da render farm no mesmo visualizador, com a mesma view transform, e comparar alguns valores de pixel com um conta-gotas de cor, além de os comparar a olho. Pequenas diferenças de amostragem ou de denoising são normais; um desvio visível de matiz não é.

Lista de verificação de cor pré-envio em sete passos: config, espaço de trabalho, etiquetas das texturas, view transform, saída EXR, projeto empacotado, frame de teste

Testar um frame numa render farm gerida

A Super Renders Farm é uma render farm na nuvem totalmente gerida, pelo que não é necessário iniciar sessão nas máquinas, instalar software nelas nem gerir licenças. Isso é conveniente e é também a razão pela qual a lista de verificação importa: tudo o que a estação de trabalho obtém do seu próprio ambiente tem de ser transportado pela cena e pelos ficheiros enviados.

Não existe uma lista publicada de compatibilidade por config para configurações OCIO personalizadas. Se o pipeline depender de uma config específica do estúdio, contacte o suporte antes do envio, através do chat ao vivo 24/7 ou por supportcenter@superrendersfarm.com, e envie a config com um teste de um frame. Uma regra de envio é importante aqui: a render farm não extrai ficheiros compactados (.zip, .rar, .7z, .tar, .tar.gz), pelo que nada dentro de um ficheiro compactado é renderizado.

Um frame de teste é um trabalho pequeno. As novas contas recebem $25 em render credits gratuitos, e o modo como a utilização é faturada está explicado na página de preços. Para cenas de Cinema 4D e Redshift, a submissão de trabalhos está descrita na nossa página da render farm na nuvem para Cinema 4D; as páginas de Redshift, Maya e Blender cobrem essas aplicações.

FAQ

Q: O que significa ACES? A: ACES significa Academy Color Encoding System, um framework aberto de gestão de cor e intercâmbio de imagens criado pela Academy of Motion Picture Arts and Sciences e mantido pela Academy Software Foundation desde agosto de 2025.

Q: Qual é a diferença entre ACES2065-1 e ACEScg? A: Ambos são lineares e partilham o ponto branco. O ACES2065-1 usa as primárias AP0, muito largas, e é a codificação base definida pela SMPTE ST 2065-1. O ACEScg usa as primárias AP1, mais pequenas, e é o espaço de trabalho pensado para a renderização e a composição de CG.

Q: É preciso o ACES para usar uma render farm? A: Não. Qualquer pipeline de cor consistente funciona, incluindo um simples pipeline sRGB linear. O que importa é que a cena, as texturas e as definições de saída sejam explícitas e idênticas em todas as máquinas que tocam no trabalho. O ACES é popular por ser um padrão documentado e partilhado.

Q: O que mudou no ACES 2.0? A: A principal mudança é um conjunto redesenhado de transformações de renderização e de saída, com uma escala tonal mais suave e um gamut mapping mais robusto. A versão está datada de 4 de abril de 2025 no registo de alterações do projeto. A documentação que consultámos descreve alterações na extremidade do ecrã do pipeline, e não uma nova codificação ACEScg.

Q: Porque é que o meu render fica diferente na render farm e na estação de trabalho? A: As causas habituais são uma config OCIO diferente ou em falta, texturas etiquetadas com o espaço de cor de entrada errado, uma view transform incorporada na saída ou um formato de saída de 8 bits. Convém verificá-las por esta ordem e, depois, renderizar um frame de teste e compará-lo com o render da estação de trabalho no mesmo visualizador.

Q: Convém renderizar para EXR ou para PNG? A: Renderizar o trabalho de produção para EXR scene-linear e reservar a transformação de ecrã para a visualização e para a entrega final. PNG ou JPEG servem para pré-visualizações, porque os ficheiros de 8 bits contêm valores prontos para ecrã e não conseguem transportar valores acima de 1,0.

Q: A Super Renders Farm suporta configs OCIO personalizadas? A: Não existe uma lista de compatibilidade publicada para configs personalizadas. Se o pipeline usar uma, contacte o suporte através do chat ao vivo 24/7 ou por e-mail antes do envio e inclua um teste de um frame para comparar com o render da estação de trabalho.