Image sequences & VFX
OpenEXR and camera-raw sequences take a different path through the system than video files do. This page explains where they diverge and why.
If you work in frames rather than files — EXR comps, DPX scans, CinemaDNG rolls — the concepts from the rest of these docs still apply, but three things change: how work is divided, how the source is addressed, and how colour is handled.
Sequences are not video#
A video file is chunked by time. The planner finds keyframes and cuts on scene boundaries, because you cannot split a compressed stream anywhere else without producing seams.
An image sequence has no such constraint. Every frame is already independent — that is what makes it a sequence. So sequences are planned by frame range instead: each worker is given a slice of frame numbers and renders exactly those.
This is simpler and it is better. There is no keyframe alignment to respect, no group-of-pictures to keep intact, and no boundary quality question, because nothing is being cut mid-stream. A sequence distributes about as cleanly as work can.
For video, chunk length trades bitrate efficiency against fleet utilisation. For sequences that tension does not exist — the only consideration is scheduling overhead against how evenly work spreads.
Addressing a sequence#
A sequence is many files that mean one thing, so it needs an address that captures that. Sequences are referred to with their own URI scheme naming the directory, the filename pattern and the frame range:
exrseq://<base>/<pattern>@<first>-<last>The range is explicit rather than inferred, which matters for the case that quietly ruins renders: a sequence with a gap in it. Naming the range means a missing frame is a mismatch that gets reported, not a shorter output that looks fine.
CinemaDNG rolls are addressed the same way through their own scheme, and are rendered to an intermediate before the normal pipeline picks them up.
OpenEXR#
Six presets write EXR, one per compression scheme — DWAA, DWAB, PIZ, RLE, ZIP and ZIPS. Choosing between them is a storage-against-fidelity decision:
| Scheme | Lossless | Suits |
|---|---|---|
DWAA / DWAB | No | Work in progress and review, where size matters more than archival fidelity. |
PIZ | Yes | Grainy or noisy plates — it handles high-frequency detail well. |
ZIP / ZIPS | Yes | The conventional default for delivery and archive. ZIPS is single-scanline, ZIP works in blocks. |
RLE | Yes | Flat or synthetic imagery — mattes, CG passes with large uniform areas. |
DWAA and DWAB are dramatically smaller and genuinely useful mid-comp. They are not an archival format. If a sequence is a deliverable or a master, use a lossless scheme.
Colour management#
The EXR paths are colour-managed through OCIO, and an ACES studio configuration ships inside the master bundle. You do not install or point at a config for the standard case.
Look-up tables are baked as part of the pipeline rather than applied by hand afterwards, so the transform that was intended is the transform that was applied, on every frame, on every worker.
If workers disagreed about colour interpretation, the result would be a sequence whose appearance shifts partway through — technically valid frames, and unusable. This is why the colour-consistency verifier exists and why assembly refuses chunks whose colour signatures do not match. See Correctness & QC.
Camera raw and debayer#
CinemaDNG is detected by inspecting the file header rather than trusting the extension, because DNG is a TIFF subset and variants differ in ways the filename does not reveal.
Debayering is exposed as a small set of named profiles rather than as raw decoder flags. The choice is a creative one — how much the decode should interpret versus preserve — and naming the intent is more useful than surfacing switches most people would have to look up.
The shot model#
Beyond individual jobs, there is a domain model for studio ingest: shots, versions of those shots, and ingest profiles describing how a given kind of material should be handled.
This is what makes repeatable ingest possible. Rather than an operator choosing settings per delivery, a profile encodes the decision once and each arriving shot is processed the same way — with the version history recorded rather than implied by filenames.
Duplicate submissions are collapsed by content hash: the same bytes arriving twice produce one job, not two. On a studio ingest where the same plate is delivered through two routes, that is the difference between one render and a duplicate that has to be spotted.
Preflight#
The sequence paths need image and colour tooling that ships with the master. Before committing a show to this pipeline, confirm it resolves on the machine that will run it:
$ master probe-v-depsIt prints what it found and exits non-zero if anything is missing, which makes it usable as a deployment check rather than something to read by eye. Run it after any move or upgrade of the master.