Are you a CGI artist who’s tired of chasing accurate colors through every render? Have you ever watched your carefully crafted scenes shift and degrade when viewed on different devices or composited in post?
Whether you’re juggling multiple software tools or wrestling with mismatched color spaces, the lack of a unified workflow can sap hours of your time and leave you frustrated at every turn.
Enter ACES—the Academy Color Encoding System. Built to standardize color management across the entire pipeline, ACES promises consistency from your 3D package to final delivery, no matter the format or display.
In this guide, you’ll gain a clear understanding of ACES fundamentals, from setting up transforms in Houdini to integrating LUTs and handling HDR workflows. You’ll learn to troubleshoot common pitfalls and maintain color fidelity throughout your project.
By the end of this introduction, you’ll know exactly why adopting ACES can transform your pipeline and how the following sections will equip you with actionable steps for seamless color management in your next CGI production.
What is ACES and why adopt a scene-referred color pipeline in CGI production?
ACES is an open standard for high-dynamic-range, scene-referred workflows maintained by the Academy. It uses 16-bit float or 32-bit float EXR files, storing real-world light intensities directly in linear space. This ensures that color data remains physically accurate from lighting through compositing, avoiding gamut clipping and inconsistent grading.
Adopting a color pipeline based on ACES delivers predictable results across software and devices. Artists share a common reference space, reducing mismatches between look-development, lighting, and finishing. ACES also future-proofs archives, as raw scene values preserve full exposure latitude for later color adjustments.
- Input Device Transform (IDT): Converts camera or texture data into the ACES reference space.
- Reference Rendering Transform (RRT): Applies a perceptual tone mapping and viewing condition compensation.
- Output Device Transform (ODT): Maps the scene-referred result to the target display gamut and gamma.
In Houdini’s OpenColorIO configuration, enable ACES in Edit ▸ Color Settings. Assign “ACEScg” as your working space, then use Color Correct and OCIOColorSpace nodes to switch between scene-referred and view spaces. Procedural shaders built in VEX will maintain physical intensity values, while COPs grading retains full dynamic range. This integration ensures each department works from the same mathematical foundation.
How does the ACES architecture work and which transforms (IDT, RRT, ODT, AP0/AP1) change my rendering math?
The ACES architecture is a three-stage pipeline that isolates scene capture, rendering and display into distinct color domains. First, an Input Device Transform (IDT) linearizes and maps camera or texture data into ACES color space. Then the Reference Rendering Transform (RRT) applies perceptual tone mapping. Finally, an Output Device Transform (ODT) adapts the RRT result to your target display gamut and gamma.
IDT maps scene data to ACES2065-1 (AP0 primaries) or ACEScg (AP1 primaries). In Houdini you configure the OpenColorIO (OCIO) color config in the “Color Management” prefs. When you choose an input role like “Utility – Linear – sRGB” or a custom IDT LUT for RED, ARRI or Sony, you’re effectively multiplying your input values by a 3×3 matrix or applying a 3D LUT. This ensures your shading and light transport all happen in a common, device-agnostic linear domain.
- IDT: camera/texture → ACES2065-1 (AP0) or ACEScg (AP1)
- RRT: perceptual tone mapping inside ACES
- ODT: display-targeted transform (Rec.709, P3, HDR)
- AP0 vs AP1: archival code values vs rendering-optimized primaries
ACES2065-1 (AP0) uses extremely wide-gamut primaries designed for lossless interchange and grading, but its zero headroom and extreme whites can introduce precision challenges in shaders. ACEScg (often called AP1) shifts to narrower primaries more suited for modern renderers: you get better numerical stability in light loops, fewer clamped specular peaks, and a more predictable black-point when working procedurally in Houdini’s SHOP or VOP networks.
The Reference Rendering Transform (RRT) lives between your renderer’s raw output and the ODT. It applies a scientifically derived curve that simulates filmic response, compresses highlights and charters a logical path from scene-linear HDR to perceptual mid-tones. In practice the RRT is baked into the ODT LUTs in OCIO, so your driver math remains untouched until final grading. Houdini’s mantra or Karma renderers output linear ACEScg values, and the OCIO viewer applies the combined RRT+ODT when you choose a display with “Output Transform”.
The Output Device Transform (ODT) tailors the RRT result to a chosen display standard—Rec.709, DCI-P3, Rec.2020 or HDR PQ/HLG. It remaps whites to the target white point, applies gamut clipping or compression and imposes the correct electro-optical transfer function (EOTF). In Houdini Solaris with Karma XPU, set your viewport’s “OCIO Display” to match your delivery specification; the renderer itself still writes out ACES2065-1 EXRs, and the ODT is only user-facing. This separation guarantees full dynamic range in the EXR archive while showing you a true preview of your final deliverable.
How do I set up ACES in Houdini for a robust production render pipeline?
Project-level OCIO and Houdini color-management settings: HIP, environment, and .ocio integration
Begin by centralizing your ACES configuration in the project root. Store your config.ocio alongside supporting LUTs and transforms. In Houdini’s Preferences > Color Management, select “OpenColorIO” and point to your OCIO filepath. This ensures all view transforms and working spaces follow a single source of truth.
- Set HOUDINI_OCOCIO to $PROJECT/config.ocio so every .hip references the same schema
- Place config.ocio and LUTs under version control for team-wide consistency
- In your houdini.env, add OCIO = $PROJECT/config.ocio and disable legacy sRGB toggles
When creating a new .hip, confirm your global color space is “ACEScg” under Rendering > Color Management. This drives color-correct lighting, shading, and simulation data throughout the node graph.
Renderer-specific configuration (Mantra, Redshift, Arnold): IDTs, primaries, EXR role and linear EXR workflows
Each renderer interprets textures and outputs differently. Configure Input Device Transforms (IDTs) so maps tagged sRGB or Rec.709 convert into ACEScg before shading calculations.
- Mantra: In the Mantra ROP, under “Extra Image Planes,” set “EXR Output Color Space” to ACEScg and define input color space per texture VOP using “OCIO Color Space” nodes
- Redshift: In RS ROP > Color Management, choose “OCIO” workflow, set “ACEScg” as the internal space, and assign EXR role “scene_linear” for deep compositing
- Arnold: In the Arnold ROP, enable “OCIO Config,” set “Input Space” for each file node and “Output Space” to ACES2065-1 or an ODT like rec709 in your render AOVs
For linear EXR workflows, tag all beauty and AOV outputs with “scene_linear” in the EXR metadata. This preserves scene-referred data for graded passes. Use OCIO File Transform SOP or COP to verify LUT consistency and ensure no hidden gamma shifts occur between DCC, render, and compositing.
How should I author and prepare textures, HDRIs and look assets for ACES (color spaces, encoding, and gamut strategies)?
All color imagery in an ACES pipeline lives in a linear scene-referred space. In Houdini, that means authoring or converting textures into ACEScg (for shading) and using ACES2065-1 for interchange. This preserves the full AP1 gamut and prevents clipping when you push saturation or dynamic range in post.
Classify and encode each map according to its role:
- Albedo/Diffuse: photographic or painted color → import as ACEScg, linear data
- Normal, Roughness, Metalness: machine data → leave untagged, no gamma
- Specular/Reflection: color-driven highlights → convert from sRGB to linear ACEScg
When you inherit 8-bit sRGB bitmaps, use Houdini’s OCIOColorSpace VOP or a COP2 node. Set “Source Color Space” to sRGB and “Destination” to ACEScg. Chain these conversions at import in your material digital asset so every legacy map is normalized automatically.
For HDRI environments, capture or save illuminance maps in EXR floats, then run them through your OCIO config: set the input role to the source camera space (e.g., Rec.709) and output to ACES2065-1. This ensures full dynamic range—deep shadows, specular fireflies—and accurate color when lighting your scene procedurally in Solaris or Mantra.
Look asset strategies: publish materials with embedded roles and color tags. Bake any custom LUTs in ACEScg via the Renderview’s OCIO LUT export. When exporting Alembic or material packages, package textures alongside a .ocio file or color profile. Downstream tools will inherit accurate transform recipes, guaranteeing consistent appearance across VFX, compositing, and game engines.
How do I composite and grade while preserving scene-referred linearity with ACES (OCIO viewing transforms, neutral math, and display pipelines)?
When working with ACES, the goal is to maintain a scene-referred, linear workflow from render through grade. In Houdini, you assign ACEScg as your working color space via the OCIO config, keep all EXR passes in floating-point linear, and defer any display transforms until the final output stage. This avoids unintended gamut clipping or gamma shifts during compositing.
First, configure Houdini’s OCIO. Under Globals > Color Management, point to the official ACES config folder. Set the Working Space Role to ACEScg and the Display to ACES Display – Rec.709. Use the COP2 OCIO Color Space Transform node to convert any non-ACES inputs (plates, textures) into ACEScg. All color-correct and merge operations must occur in this linear, wide-gamut domain.
For truly neutral math, ensure every adjustment node treats data as linear scene values. In COP2, the Color Correct node should remain in linear mode—avoid “gamma” or “log” toggles. Perform exposure shifts with the Exposure slider or a Multiply node on RGBA. Use Add/Subtract SOP VOPs or VEX snippets for precise channel math when balancing AOVs, ensuring you’re never operating in display-referred space.
The final display pipeline must be isolated. In a compositing network, attach an OCIO Color Space Transform set from ACEScg to your chosen Display – usually Rec.709 or DCI-P3. Only at this node do you apply the ACES Output Transform. When rendering dailies or previews via Mantra ROP, enable the “OCIO Output Transform” parameter under Properties > Image Planes, choosing your display View and Look. This secures full dynamic range until the last moment.
- Keep all renders in EXR 16- or 32-bit float
- Use ACEScg for lighting, shading, compositing
- Convert to display space only once, at export or in a viewer
- Avoid any GPU LUTs or sRGB toggles during compositing
By strictly separating scene-referred operations from display transforms, you preserve highlight and shadow detail, maintain accurate color relationships, and ensure that grading decisions are reversible and physically plausible. This disciplined approach unlocks the full power of ACES in Houdini.
What are the common ACES pitfalls in CG pipelines and how do I diagnose and fix them?
Implementing ACES often trips up CG pipelines because of mismatched file transforms or viewer LUTs. A common symptom is washed-out renders or clipped highlights despite correct linear workflows. Diagnosing starts with validating each stage: texture import, lighting, shading and render output all must use consistent OCIO roles.
- Missing inverse file transform: textures tagged as sRGB but used in linear space → ensure OCIOColorSpace nodes invert to ACEScg on import.
- Wrong working color space: default Houdini set to linear sRGB → switch global config to ACES 1.2 and set working space to ACEScg.
- Baked gamma in assets: artists deliver .exr with display gamma → repipeline to scene-referred .exr with no baked LUTs.
- Viewer LUT mismatch: rendering in ACEScg but viewing in Rec.709 → set IFD viewer to ACEScg to Rec.709.DRT.
- Clip or quantization: 8-bit outputs or limited bit depth → render 16- or 32-bit float and use Deep Image where needed.
To diagnose subtle gamut shifts, use Houdini’s Image Viewer histogram and pixel readouts in ACEScg space. Toggle the OCIO viewer LUT off and on to compare raw linear output. In COP2 networks attach OCIOColorSpace nodes before and after a color manipulation to inspect whether the transformation is truly neutral or adding unintended curves.
Ensure your OCIO config is referenced in $OCIO environment and in Houdini’s Color Management preferences. Define ACEScg as your scene working space and assign proper color roles at file nodes. For Karma, verify RenderSettings > Color Management matches the config. For Mantra, set the Pixel Format to 32-bit float and enable OCIO transforms under Image to Output.
Exposure mismatches can arise if lens or physical lights use default EV100 scales. In ACEScg, calibrate lights using candela or lumen values and test against a neutral gray card at 18% reflectance. Render a flat gray plane and adjust exposure control in the post-process ROP or the Karma DRT node until its luminance reads 0.18 in ACEScg.
Clipping in highlights can sneak in via dashboard compositing: if you composite an ACEScg pass in non-scene referred tools, you lose metadata. Always use scene-referred compositors like Nuke with an ACES config. Maintain ID pass integrity in Houdini by rendering cryptomattes in ACEScg and avoid recompressing or linearizing them externally.