Houdini-tuned ACES 2.0 CG OCIO config based on the official ACEScg config, with practical defaults, file rules, and curated cinematic looks for real CG work.
Use ACEScg-personal-v2.0_ocio-v2.4-.ocio (recommended for all artists).
It includes the full ACES 2.0 base output plus 4 curated cinematic looks (Film Dense, Chemical Drift, Carbon Black, Cold Steel Neutral), ready to use in Houdini with no setup beyond pointing OCIO at the file. If you want clean, cinematic output without wrestling with OCIO from scratch, this is the one to use.
ACEScg-v2.0_ocio-v2.4.ocio is the base config with no looks. It follows the minimal tweaks for a smooth CG transfer pipeline, with practical defaults and file rules that make it behave correctly in Houdini out of the box. Use it if you want a clean ACES 2.0 foundation to build your own look stack on top of.
All looks are applied in ACEScct log space as view-only transforms. They do not affect rendered output, texture interpretation, or scene-linear values. Purely a display choice.
| Look | Character |
|---|---|
| Film Dense | Heavy contrast, rich blacks, compressed highlights. Photochemical print density. |
| Carbon Black | Extreme shadow crush, near-black fabric rendering, zero lift |
| Cold Steel Neutral | Desaturated cool midtones, industrial neutrality, minimal chroma contamination |
| Chemical Drift | Photographic colour drift; pushed hues, dirty lows, organic midtone shift |
Fusion / DaVinci Resolve: Looks will not work in Fusion or Resolve. Neither application has official OCIO 2.4 support. The base ACES 2.0 output transforms are available in Resolve 20 via native colour management only, but the OCIO look transforms are not applicable there.
Note on Adobe colorspaces: The personal config does not include Adobe RGB or any Adobe-specific colorspaces. They have been removed intentionally. You simply don't need them in a CG pipeline. ACES covers every working, interchange, and delivery space a Houdini/Arnold workflow requires.
Note on displays: The personal config ships with only three displays: sRGB, Display P3, and Rec.1886 Rec.709. That covers every monitor a solo artist will realistically work on. Broadcast, HDR, and cinema projection displays were intentionally removed to keep the personal config focused and lightweight.
Stable and ready to use. Built to avoid the usual Houdini OCIO friction so you don't have to. Works with external renderers, tested Arnold in Solaris (Houdini 21). Loaded this config in Nuke 17 and it transferred properly.
This config is ocio_profile_version: 2.4, so treat it as OCIO 2.4+ only: OCIO 2.4 shipped in September 2024 and is part of the VFX Reference Platform CY2025, and Houdini 21 ships with OpenColorIO 2.4.1 (SideFX also lists 2.4.1 in its third-party libraries), so Houdini 21 is the intended host. Nuke 17 ships with OCIO 2.4.2 and is also a confirmed target.
Resolve/Fusion 19 only documents OpenColorIO 2.3 support, while Resolve 20 separately adds ACES 2.0 support in its own color-management operations. Neither Resolve nor Fusion has official OCIO 2.4 support, so these configs should be treated as unsupported there. This also means the custom looks in the personal config will not load or apply in Fusion or Resolve, as they require OCIO 2.4. Base ACES 2.0 output is accessible in Resolve 20 only via its native colour management path, not via this OCIO config.
Do not assume a host-specific ACES/DRCM path is a clean workaround for standard OCIO interchange: it can diverge, so validate end-to-end instead of trusting the label, as noted on ACESCentral.
After Effects 26 is not a supported host. Adobe doesn't release documentation about their OCIO version, but I quickly tested it myself. Its current OCIO implementation does not load ocio_profile_version: 2.4.
Create or edit ocio.json in your Houdini packages folder and replace the path with your local path of the config.
For the personal config (recommended):
{
"enable": true,
"show": true,
"load_package_once": true,
"env": [
{ "OCIO": "${OCIO-/path/to/ACEScg-v2.0-Houdini/ACEScg-personal-v2.0_ocio-v2.4-.ocio}" }
]
}For the base config (no looks):
{
"enable": true,
"show": true,
"load_package_once": true,
"env": [
{ "OCIO": "${OCIO-/path/to/ACEScg-v2.0-Houdini/ACEScg-v2.0_ocio-v2.4.ocio}" }
]
}Restart Houdini after adding or changing the package file, since OCIO is read at startup.
With this config active, ACEScg is the intended default working space for CG content.
Houdini’s OCIO editor is unreliable in practice for config authoring/persistence (this isn’t specific to this config). If you want changes, edit the .ocio file directly and restart Houdini.
Solaris Render Gallery has its own caching/consistency quirks; don’t use it as your only ground truth when validating color.
The stock ACES CG config is already the right kind of base for Houdini. The real problem was not the working space, it was default file assignment. By default, unmatched files fell back to ACES2065-1, which is a poor day-to-day assumption for CG work in Houdini.
./ACEScg-v2.0_ocio-v2.4.ocio keeps the ACES 2 structure intact, but makes the defaults practical so standard textures, EXRs, and loosely tagged files behave like a sane Houdini pipeline instead of an interchange/archive config.
| Setting | Stock ACES CG config | Houdini-tuned config |
|---|---|---|
default |
not set | ACEScg |
reference |
not set | ACEScg |
scene_linear |
ACEScg |
ACEScg |
color_timing |
ACEScct |
ACEScct |
compositing_log |
ACEScct |
ACEScct |
matte_paint |
ACEScct |
ACEScct |
color_picking |
sRGB Encoded Rec.709 (sRGB) |
sRGB Encoded Rec.709 (sRGB) |
texture_paint |
sRGB Encoded Rec.709 (sRGB) |
sRGB Encoded Rec.709 (sRGB) |
Default file rule |
ACES2065-1 |
ACEScg |
File rules added in this config:
*srgb_tx*->sRGB Encoded Rec.709 (sRGB)*srgb_texture*->sRGB Encoded Rec.709 (sRGB)*ACEScg*->ACEScg*lin_rec709*->Linear Rec.709 (sRGB)*lin_srgb*->Linear Rec.709 (sRGB)__usdz_jpg->sRGB Encoded Rec.709 (sRGB)__usdz_jpeg->sRGB Encoded Rec.709 (sRGB)__usdz_png->sRGB Encoded Rec.709 (sRGB)__usdz_tif->sRGB Encoded Rec.709 (sRGB)__usdz_tiff->sRGB Encoded Rec.709 (sRGB)__usdz_exr->ACEScg.jpg->sRGB Encoded Rec.709 (sRGB).jpeg->sRGB Encoded Rec.709 (sRGB).png->sRGB Encoded Rec.709 (sRGB).tif->sRGB Encoded Rec.709 (sRGB).tiff->sRGB Encoded Rec.709 (sRGB).exr->ACEScg- fallback
Default->ACEScg
Tag rules take precedence over extension rules. USDZ archive-internal file paths are matched by explicit regex rules before the normal extension rules.
The file rules in this config are a pipeline fallback for loosely named assets. OCIO file rules are evaluated top-down, and the first match wins.
See OCIO file rules documentation
Houdini/USD can expose files inside .usdz archives as .usdz[texture.ext] paths. That is why this config adds explicit regex rules for USDZ payloads, because normal extension rules are not enough on their own for those archive-internal references. See the SideFX USD Zip render node.
Do not treat extension rules (e.g. .png/.tif → sRGB) as a license to stop assigning the correct interpretation on MaterialX nodes:
- Color textures (albedo/baseColor/emission) are typically sRGB.
- Data textures (normal, roughness, metallic, AO, displacement, masks/IDs) must be Raw/Data (no color transform).
SideFX explicitly notes that when reading normal maps with MaterialX, you should set the Signature to Vector3 to make sure a color space is not applied:
SideFX MaterialX documentation
If a texture looks washed out, oversaturated, or double-transformed, check whether it is already display-referred, whether the filename includes srgb_tx, srgb_texture, ACEScg, lin_rec709, or lin_srgb, and whether the extension matches the intended automatic rule.
albedo.png->sRGB Encoded Rec.709 (sRGB)(extension rule)albedo_srgb_tx.png->sRGB Encoded Rec.709 (sRGB)(tag rule, takes precedence)backplate_lin_srgb.exr->Linear Rec.709 (sRGB)(tag rule, takes precedence)lighting.exr->ACEScg(extension rule)lighting_ACEScg.exr->ACEScg(tag rule)
# Personal config (recommended)
ociocheck --iconfig ACEScg-personal-v2.0_ocio-v2.4-.ocio
# Base config
ociocheck --iconfig ACEScg-v2.0_ocio-v2.4.ocioIf you need to inspect image files directly, OpenImageIO documentation is a good reference, and tools like iinfo and oiiotool are useful for checking metadata, channels, and file properties.
ociocheck passes for this config. Unlike the stock Default -> ACES2065-1 behavior, this tuned version now falls back to ACEScg, which is the practical working assumption for Houdini CG use.
For the spec, the host app, and current software support, start here:
For deeper reading on color science and pipeline decisions:
- Liam Collod's Picture Lab
- Chris Brejon's articles
- Chris Brejon: OCIO display transforms and misconceptions (mea culpa)
- Chris Brejon: What makes a good picture formation?
- ACESCentral: Per-channel display transform with wider rendering gamut
- Apple: Use reference modes with your Apple display
- chrisbrejon/ARRI-REVEAL-OCIO-Config is a rather universal ARRI Reveal community reference.
- ARRI-Houdini if you want the ARRI Reveal config on ACES 1.3 variant. Tweaked for Houdini by me.
This repo focuses on Houdini-friendly defaults, file rules, and predictable CG working space behavior instead. ACEScg as working space is a pipeline sanity choice. Open to feedback and solutions.
A quick visual comparison of a few default output transform directions applied to the same scene, included as a practical reference only. Different transforms can produce materially different picture formation, contrast distribution, highlight behavior, and chroma character even before any custom look is applied. This is worth understanding before committing to a config.
Treat this as a sanity-check illustration, not a universal ranking. The exact result will vary depending on your host application, render delegate, display calibration, and viewing conditions. Validate the full chain inside your own setup before drawing conclusions.
The ACES 2.0 base is cleaner than the ARRI config which runs on ACES 1.3, but the same rule still applies: don't trust a pipeline until you validate the whole chain.
Test transfers between input texture encoding to scene-linear (Solaris/MaterialX), scene-linear to Hydra delegate/viewport, Arnold maketx/.tx generation to MaterialX reads (.tx + colorspace), husk/kick EXR to comp/viewers, scene-linear to display transform, and display transform to final deliverables, then lock it in your comp/grading software of choice.
The exact edge cases can still differ by render engine, delegate, and host app build. If anything looks suspicious, validate the chain end-to-end instead of assuming the label is right. Terminal with iinfo, oiiotool, and ociocheck becomes your best friend.