The Colour Science Behind Transduce¶

Overview¶

Every clip that passes through the Transduce engine — regardless of what generated it, what camera shot it, or what colour space it arrived in — is converted into a single, industry-standard working space before any grading, effects, or AI processing happens, and converted back out into whatever colour space a given delivery requires. That working space is ACEScg, part of the Academy Color Encoding System (ACES) published and maintained by the Academy of Motion Picture Arts and Sciences.

ACEScg is not a proprietary format — it's a published, industry-standard working space, which means footage processed through Transduce round-trips cleanly with colour-managed tools already in use on a professional show.

Why this matters in practice¶

Modern footage arrives from wildly different sources — camera-original log formats, AI-generated video platforms exporting display-referred sRGB, VFX plates already delivered in a full ACES interchange container. Grading, defocus, resizing, and AI upscaling are all mathematically well-behaved only when performed in linear light — a curve like log or gamma baked into the math produces visible artifacts (muddy blurs, wrong-looking blends, banding). Converting everything into one linear, wide-gamut space up front ensures every processing stage — human-driven or AI-driven — operates on physically correct values, and that nothing gets clipped or discarded along the way that a later delivery format might have needed.

Technical Specification¶

1. Working (intermediate) colour space¶

Property	Value
Name	ACEScg
Primaries	AP1
White point	D60 (CIE x=0.32168, y=0.33767)
Encoding	Scene-linear — no gamma or log curve
Storage precision	16-bit half-float (IEEE 754), in EXR containers
Compute precision	float32, in-flight during CC/effects/upscale (GPU-resident tensors)
Reference	SMPTE ST 2065-1:2012, Annex B, Table B.2

AP1 (ACEScg) chromaticities:

	x	y
Red	0.71300	0.29300
Green	0.16500	0.83000
Blue	0.12800	0.04400
White (D60)	0.32168	0.33767

Small negative values in ACEScg are valid and are never clamped. This is an intentional, expected consequence of AP1 being a narrower gamut triangle than several source spaces converted into it (notably AP0 — see below); clamping would silently discard real, out-of-AP1-but-legitimate colour information rather than preserving it for later stages or a wider-gamut delivery.

2. Processing pipeline¶

Every clip passes through the same fixed-order pipeline:

Ingest — source decoded to raw frame data; container/codec/resolution/frame rate/bit depth recorded.
Source detection — mechanism depends on container. For EXR: the chromaticities header attribute and acesImageContainerFlag are read directly (a distinctive red-primary x-coordinate identifies ACEScg, ACES2065-1, or Rec.709/sRGB; camera-provenance fields such as ARRI's tech_details_gamma_space/tech_details_color_space are captured as provenance metadata alongside, not used to override an explicit chromaticities/ACES-flag match). For video containers: VUI colour primaries/transfer characteristics reported by the container. Where no explicit metadata is present, detection falls back to a per-platform profile (known AI generation platforms' typical output encoding), then to an sRGB 8-bit default flagged for manual review.
Linearise — the source's own encoding curve is inverted (e.g. inverse sRGB EOTF for display-referred sources; the appropriate camera log curve for camera-native footage).
Convert to ACEScg — a validated matrix chain moves the linearised data into the AP1/D60 working space.
Colour correction — primary and secondary grading, applied entirely in linear ACEScg. 5b. Effects — post-CC image operations (GPU-native), also in linear ACEScg.
Upscale — deterministic resize or AI-model upscaling; receives and returns linear ACEScg. (The AI upscale path round-trips internally through display-referred sRGB purely for model inference, then converts back to ACEScg linear before returning — nothing downstream of this step ever sees anything but linear ACEScg.)
Encode — ACEScg is converted to the target delivery colour space and written to the target container/codec.
Write output — files written with a manifest recording source, parameters, and output path.

Colour correction, effects, and upscale all happen before final colour conversion — never on already-converted display-referred or log data.

3. Source-side conversion matrices¶

sRGB (linear) → ACES 2065-1 (AP0):

0.4397  0.3829  0.1774
0.0897  0.8134  0.0969
0.0175  0.1115  0.8710

ACES 2065-1 (AP0) → ACEScg (AP1):

 1.6410  -0.3248  -0.2362
-0.6636   1.6154   0.0167
 0.0117  -0.0082   0.9883

Camera-native log formats (ARRI LogC3/LogC4, and others) are linearised via their own manufacturer-published IDT (Input Device Transform — e.g. ARRI White Paper WP-2022-001 for LogC4 / ALEXA 35 / Wide Gamut 4), which converts camera-native encoding directly to ACES2065-1 (AP0). The AP0→AP1 step above is then the standard ACES-to-ACEScg working-space remap applied uniformly regardless of source — it is not itself an IDT.

4. Delivery-side conversion matrices¶

ACEScg (AP1) → ACES 2065-1 (AP0):

 0.69545220  0.14067870  0.16386910
 0.04479456  0.85967110  0.09553432
-0.00552588  0.00402521  1.00150060

This is the exact algebraic inverse of the AP0→AP1 matrix above (round-trip error against identity: < 6×10⁻⁸) — encoding to AP0 and re-decoding recovers the original values to within floating-point precision, not an approximation.

ACEScg (AP1) → Linear Rec.709:

 1.7050513  -0.6217930  -0.0832585
-0.1302048   1.1408036  -0.0105987
-0.0240033  -0.1289689   1.1529788

AP0 (ACES 2065-1) chromaticities (for reference/interchange tagging):

	x	y
Red	0.73470	0.26530
Green	0.00000	1.00000
Blue	0.00010	-0.07700
White (D60)	0.32168	0.33767

5. Delivery colour space options¶

Each output format either declares a single fixed delivery colour space, or exposes a user-selectable one:

Delivery format	Colour space
H.264 / H.265 / AV1	Rec.709 (fixed)
PNG / JPEG / WebM	sRGB (fixed)
DPX	User-selectable: Display Rec.709, Display sRGB, Scene Linear, Log
CineForm	User-selectable: Display Rec.709, Display sRGB, Scene Linear
OpenEXR	User-selectable: ACEScg (AP1), Linear Rec.709, ACES 2065-1 (AP0)

ACES 2065-1 (AP0) EXR delivery writes the acesImageContainerFlag (per SMPTE ST 2065-4) in addition to correct AP0 chromaticities, so ACES-aware tools identify the file as a proper ACES delivery container automatically, not merely a wide-gamut linear EXR.

6. Validated round-trip fidelity¶

Using a real, camera-original ACES 2065-1 (AP0) production EXR (ARRI ALEXA 35, native acesImageContainerFlag and AP0 chromaticities present in the source file), a full decode → ACEScg → re-encode → re-decode round trip was measured directly against the original delivered pixel data:

Maximum absolute deviation: 0.000244 — the resolution limit of 16-bit half-float storage itself, not accumulated error.
Mean absolute deviation: 7.4 × 10⁻⁷.
0% of pixels deviated by more than 0.001.
Relative error where signal was meaningfully non-zero (|value| > 0.01): mean 0.001%, 99th percentile 0.05%.

The round-tripped file was independently re-detected as ACES 2065-1 on read, confirming both the write-side tagging and read-side detection close the loop correctly.

7. Scope¶

Transduce implements ACEScg as a linear working and interchange space, with matrix-based IDT-style conversion on ingest and ODT-style conversion on delivery, as described above. It does not currently apply the ACES Reference Rendering Transform (RRT) or an Academy-defined Output Device Transform chain — there is no filmic tone-mapping or view-transform curve applied as part of colour management; delivery conversions are direct, invertible primaries/matrix transforms only.

Current release scope targets SDR delivery from AI-generated and camera-original footage without a creative rendering transform in the loop. A full RRT+ODT viewing/grading pipeline for VFX and scene-linear workflows is planned as a subsequent addition, tagged per-project rather than assumed globally.

Licensing¶

ACES, and ACEScg as part of it, is licensed under Apache 2.0. As of August 2025, the ACES project moved under the Academy Software Foundation's open governance model, which extends (rather than restricts) its open-source footing. Apache 2.0 explicitly permits commercial use, redistribution, and modification.

Separately from the technical license: "ACES," "Academy Color Encoding System," and any certification-style claims (e.g. "ACES certified") are Academy of Motion Picture Arts and Sciences trademarks / certification marks. Describing Transduce's pipeline as ACEScg-based is a factual technical statement and is not restricted; any claim of formal ACES certification would require going through the Academy's own certification process separately.

Sources: