Image sequences & VFX
OpenEXR and camera-raw sequences take a different path through the system than video files. This page describes where the paths diverge and why.
Frame-based sources — EXR composites, DPX scans, CinemaDNG rolls — follow the same concepts as the rest of this documentation, with three differences: how work is divided, how the source is addressed, and how colour is handled.
Differences from video sources#
A video file is chunked by time. The planner finds keyframes and cuts on scene boundaries, because a compressed stream cannot be split anywhere else without producing seams.
An image sequence has no such constraint: every frame is already independent. Sequences are therefore planned by frame range. Each worker is given a slice of frame numbers and renders exactly those frames.
Frame-range planning removes the constraints that apply to video chunking. There is no keyframe alignment to respect, no group of pictures to keep intact, and no boundary-quality concern, because nothing is cut mid-stream.
Chunk size behaves differently for sequences. For video, chunk length trades bitrate efficiency against fleet utilisation. For sequences that trade-off does not exist; the only consideration is scheduling overhead against how evenly work spreads.
Sequence addressing#
A sequence is a set of files that together represent one source, and it is addressed as one source. Sequences are referred to with a dedicated URI scheme naming the directory, the filename pattern and the frame range:
exrseq://<base>/<pattern>@<first>-<last>The range is explicit rather than inferred. This matters when a sequence contains a gap: because the range is declared, a missing frame is reported as a mismatch rather than producing a shorter output that appears complete.
CinemaDNG rolls are addressed the same way through their own scheme, and are rendered to an intermediate before the normal pipeline processes them.
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 produce substantially smaller files and are suitable for work in progress. They are not archival formats. Use a lossless scheme for any sequence that is a deliverable or a master.
Colour management#
The EXR paths are colour-managed through OCIO, and an ACES studio configuration ships inside the master bundle. The standard case requires no configuration to be installed or referenced.
Look-up tables are baked as part of the pipeline rather than applied manually afterwards, so the intended transform is applied identically on every frame and on every worker.
Inconsistent colour interpretation between workers would produce a sequence whose appearance shifts partway through: individually valid frames forming an unusable deliverable. The colour-consistency verifier exists for this reason, and 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 a named profile records that intent without requiring knowledge of the underlying decoder switches.
Shot model#
Beyond individual jobs, the system provides a domain model for studio ingest: shots, versions of those shots, and ingest profiles describing how a given kind of material is handled.
Profiles make ingest repeatable. Rather than an operator choosing settings per delivery, a profile encodes the decision once, and each arriving shot is processed the same way. Version history is recorded rather than implied by filenames.
Duplicate submissions are collapsed by content hash: the same bytes arriving twice produce one job, not two. When the same plate is delivered through two routes, the result is a single render rather than a duplicate that must be identified manually.
Ingest output bundle#
An EXR ingest does not re-encode the plate in isolation. It produces a bundle of related outputs:
- The EXR master — converted into the working colour space, the source for downstream work.
- JPG dailies in Rec.709, for reviewers who do not open EXR files.
- One or more ProRes reference deliverables, optionally with burn-in and a head slate.
A sequence ingest therefore produces video deliverables in addition to the converted sequence, which is why the reference presets belong to the same family as the EXR presets.
Preflight#
The sequence paths require image and colour tooling that ships with the master. Before committing a show to this pipeline, confirm that the tooling resolves on the machine that will run it:
$ master probe-v-depsThe command prints each dependency it resolves and exits non-zero if anything is missing, so it can serve as an automated deployment check. Run it after any move or upgrade of the master.