ACES colour management for archviz: textures, ACEScg and EXR delivery

What ACES solves, and what it does not

ACES colour management is useful in architectural visualization when several applications must interpret the same image data consistently. A renderer, compositor and editor can each show a plausible picture while disagreeing about what the pixels mean. The result is familiar: a plaster wall changes colour after export, a saturated fabric loses its character, or a bright window acquires a second contrast curve. ACES provides a framework for managing those transformations. It does not design the lighting, guarantee material accuracy or make an uncalibrated laptop match a reference display.

The practical question is not whether ACES produces a more impressive image by default. It is whether the studio can explain the path from an incoming texture to the final client file. If one artist renders in one space, another grades in a different space and the delivery application guesses the file interpretation, consistency is accidental. A documented pipeline makes that process repeatable. For a solo artist delivering a few stills in a single application, a simpler managed workflow may already be sufficient. Adopt ACES because the handoff needs it, not because the acronym suggests cinematic quality.

Separate working space from the displayed image

Separate three ideas: the source colour space of an asset, the working space used for rendering or compositing, and the transform used to display the result. ACEScg is a scene-linear RGB working space commonly used in computer graphics. ACES2065-1 is a different ACES encoding used for interchange and archival purposes. They are not interchangeable labels for an EXR. The viewing transform then maps scene-referred values into a picture suitable for a particular display. Confusing that final presentation with the underlying render data is the source of many export mistakes.

A wider working gamut is not a substitute for sensible material values. A vivid red chair can still have an implausible shader, and a white wall can still return too much light. Highlight appearance also depends on the viewing transform, exposure and the scene, not merely on the name of the working space. Judge a material against references under controlled lighting before grading the entire shot. Otherwise a colour-management change may be blamed for a problem that originated in texture authoring, an incorrect light spectrum assumption or an over-bright diffuse colour.

Assign texture colour spaces deliberately

For incoming colour textures, identify how they were authored. A base-colour image prepared for an sRGB workflow normally needs interpretation as sRGB and conversion into the chosen rendering space. Simply labelling those pixel values ACEScg is not a conversion. The renderer would then assign the wrong meaning to them. Check the application and version documentation for the actual texture controls, particularly where automatic detection is involved. A file name suffix can help the team, but it should not be the only evidence of the file's colour space.

Roughness, normal, displacement and mask maps usually carry data rather than display colour. Treating them with a colour-texture transform can change the values that drive the shader. The exact label may be Raw, Non-Color or an equivalent data setting depending on the software. A roughness map interpreted incorrectly can make a finish look glossier or flatter, which then tempts the artist to compensate with lights or grading. Audit these maps before changing the material. Also verify normal-map conventions and displacement units separately: colour management will not repair a flipped normal channel or a wrong height scale.

Build a small scene to test the handoff

Build a small pipeline test before converting a whole project. Include a neutral wall, a saturated colour sample, a metal object and a bright window or light source. Use assets with known interpretations and keep exposure fixed. Render a reference view, export the working image and open it in the next application. Compare under the same intended display transform. This is not a scientific material measurement, but it makes handoff errors obvious. Neutral surfaces reveal colour shifts, saturated samples expose wrong conversions, and bright highlights show whether a viewing curve has been applied twice.

For a hypothetical gallery project, the test might include pale plaster, oak joinery and a red artwork. If the red changes substantially between renderer and compositor while the geometry and lighting remain untouched, investigate the input space and view settings before editing the artwork texture. If the entire image becomes more contrasty, inspect the export and import path for a baked display transform. Keep the test scene separate from the hero camera so creative adjustments cannot conceal a technical mismatch. Once it works, record its settings as the baseline for the production shots.

Export linear EXRs without baking the view

OpenEXR is useful for preserving high-dynamic-range render data, but the extension alone does not establish a colour space. Decide what the file contains and tell the recipient. A scene-linear ACEScg beauty pass should be read as that space, while data passes should retain the interpretation appropriate to their contents. Do not assume every renderer writes the same metadata or that every compositor reads it automatically. Verify a round trip with the actual applications. A thumbnail that looks dark or washed out outside the managed viewer may simply lack the intended viewing transform.

Apply the presentation transform deliberately and only once in the intended image path. If a renderer saves a display-referred picture with the view already baked in, the compositor should not treat it as an untouched scene-linear master and apply the same view again. Conversely, a linear EXR needs the appropriate managed view to look like the approved render. Keep the high-dynamic-range master and the client-facing image separate. That distinction allows later exposure or grading changes without repeatedly manipulating a compressed, already transformed JPEG.

Match applications before matching shots

Matching two applications requires more than choosing a menu item called ACES in both. Record the OpenColorIO configuration, its version, the working space, the view and the target display. Different configurations or output-transform generations can produce different pictures from the same data. OpenColorIO manages colour transformations; it is not itself synonymous with ACES, and an OCIO-enabled application can use other configurations. Freeze the agreed configuration for a project unless a deliberate upgrade is being tested. Software updates should not quietly change the look of an already approved set.

Blender's AgX is another important distinction. AgX is a viewing transform available in Blender, not another name for an ACEScg render pipeline. A scene can look attractive under AgX without matching an ACES-managed view elsewhere. If Blender is part of the project, document its texture interpretation, working configuration, exported image space and viewing transform separately. Avoid compensating for a mismatch by adding a contrast curve until it resembles the reference. That workaround may hold for one image and fail on the next, particularly where bright windows and saturated materials occupy a larger part of the frame.

Deliver the right file for the destination

Delivery should follow the destination rather than the render master's format. A web still commonly needs an sRGB-targeted display image with suitable compression. A film needs the transfer, colour interpretation and encoding agreed with the editor or distributor. An EXR intended for further compositing is a different deliverable from an approved JPEG intended for immediate publication. Specify both when necessary. Check the actual exported file, not only the viewer inside the renderer. The display image should preserve the approved composition and tonal hierarchy after resizing and compression.

Material approval has limits that should be stated honestly. A supplier's photographed swatch is affected by its lighting, camera and processing; a screenshot of that photograph adds another uncertain display path. ACES cannot recover an exact physical colour from that chain. Where a finish is commercially sensitive, agree on the reference and approval conditions with the client, and use measured or properly documented material information when available. For ordinary visualization work, maintain consistent references and disclose uncertainty instead of promising that every screen will show the architect's paint specification identically.

Document the pipeline before scaling it

A useful handoff note is short enough to be read: software versions, OCIO configuration, working space, texture assumptions, EXR interpretation, viewing transform and final output target. Add the test frame and an approved display reference. Keep the original textures rather than repeatedly converting and overwriting them. If the team later changes the working space, those originals allow a clean conversion instead of an uncertain chain of previous edits. The note belongs with the deliverables so the next artist does not have to infer the pipeline from a picture.

Start with one render and one compositor, then prove that the same neutral wall, saturated sample and window highlight survive the round trip. Only then roll the settings into the full project. ACES is most valuable when it removes ambiguity between people and applications, not when it becomes an extra layer of unexplained controls. Correctly interpreted inputs, clearly labelled scene-linear masters and a deliberate output transform are the core of dependable archviz colour. Once those are stable, artistic grading becomes a choice instead of a repair for a broken handoff.