Common Working Formats
Movie-Based Formats
Use frame-based sequences for VFX plates, intermediate renders, and film scans. ProRes 4444 QuickTimes are common on smaller productions and may be acceptable for final VFX delivery, but avoid movie files for intermediate CGI and compositing renders.
Test a full round trip between production, VFX, and the DI before turnover. Check for unintended color or transfer-function changes during transcode.
Aside from visual effects, various flavors of ProRes, DNxHD, and DNxHR are suitable for offline editorial and mastering.
Apple ProRes
Apple ProRes codecs are resolution-independent, professional video codecs most often seen in
QuickTime (.mov) wrappers. The bitstream itself is published as SMPTE RDD 36, with carriage in
MXF standardized as RDD 44 and the IMF application as RDD 45. Avid Media Composer manages
ProRes as MXF OP-Atom, and Final Cut Pro has exported ProRes-in-MXF since version 10.3, so ProRes
inside an IMF is a realistic delivery route, not an exotic one.
| Variant | Encoding | Typical use |
|---|---|---|
| ProRes 4444 XQ | 12-bit 4:4:4 (RGBA / Y′CbCrA), with alpha | Highest quality: camera acquisition, intermediate grading, VFX plates and delivery |
| ProRes 4444 | 12-bit 4:4:4, with alpha | Camera acquisition, intermediate grading, VFX plates and delivery |
| ProRes 422 HQ | 10-bit 4:2:2 | High-quality mastering and delivery |
| ProRes 422 | 10-bit 4:2:2 | Mastering and delivery |
| ProRes 422 LT | 10-bit 4:2:2 | Lighter editorial |
| ProRes 422 Proxy | 10-bit 4:2:2 | Offline dailies and editorial proxies |
The 4444 variants sustain multiple generations of encoding without meaningful image degradation and are visually indistinguishable from equivalent uncompressed alternatives, which is why they serve as camera acquisition,1 intermediate grading, and VFX plate and delivery formats. See the Apple ProRes white paper for details.
ProRes also has a RAW variant (ProRes RAW, 2018), but it is a camera-acquisition format only, like ARRIRAW or R3D, and is not applicable to transcoded VFX plate pulls.
Don't encode delivery ProRes with FFmpeg
FFmpeg's ProRes encoders are reverse-engineered and unlicensed. A file may look correct but fail delivery QC on metadata or encoder identification. Encode deliverables with an Apple-approved implementation in Resolve, Premiere, or another professional application.
FFmpeg remains suitable for disposable dailies, references, and internal proxies.
Avid DNx
At IBC 2025 Avid rebranded the DNxHD and DNxHR families to a single name, Avid DNx. It dropped the
HD, HR, and GX acronyms, which were misleading once the codec became resolution-independent,
in favor of five quality levels. The rebrand also made 8- to 16-bit encoding and an optional alpha
channel available at every Avid DNx level. The level indicates the chroma sampling and
bandwidth (compression), not a fixed bit depth:2
| Level | Chroma | Typical use |
|---|---|---|
| 444 | 4:4:4 / RGB | Finishing, VFX delivery, cinema masters |
| HQX | 4:2:2 | Color and mastering. Multi-generation work |
| HQ | 4:4:4 / 4:2:2 / 4:2:0 / RGB | High-quality editorial and production |
| SQ | 4:4:4 / 4:2:2 / 4:2:0 / RGB | Editorial and broadcast delivery |
| LB | 4:2:2 / 4:2:0, low bandwidth | Offline editorial and proxies |
Data rates scale with resolution and frame rate. From Avid's published figures, at UHD (3840×2160) / 23.976 fps they run roughly 167 MB/s (444), 83 MB/s (HQX and HQ), 55 MB/s (SQ), and 17 MB/s (LB): about 1.3 Gb/s down to 137 Mb/s. At HD they are roughly a quarter of that (444 ≈ 42 MB/s, LB ≈ 4 MB/s). Avid Media Composer manages DNx media natively in MXF OP-Atom, and Avid also ships DNx QuickTime codecs. The codec is standardized as SMPTE ST 2019-1 (VC-3).2
H.264 / H.265 (HEVC)
Treat H.264 and H.265 as distribution formats, not VFX or DI working formats. Their long-GOP compression stores many frames as differences from neighboring reference frames, making frame-accurate access slower and less reliable for post.
They are, however, perfectly good creative-review proxies. Much VFX review happens in a browser on platforms like Frame.io or cineSync. Whatever the quality of the file that was uploaded, the player streams an H.264 or H.265 transcode anyway. For a director or supervisor giving creative direction, that is plenty. They can judge staging, timing, and the look. It is not a substitute for final QC sign-off, which belongs on the graded shot in the DI, but for broad creative approval an H.264 / H.265 proxy is entirely sufficient.
In practice, consumer H.264 and H.265 deliverables are 8-bit and 10-bit 4:2:0, respectively, because that is what hardware decoders and streaming platforms support, but both standards define higher-bit-depth, higher-chroma professional profiles (H.264 High 10 / Hi444PP up to 14-bit, and HEVC Main 12 / Main 4:4:4 12) used in mezzanine and archival contexts. Neither commonly supports an embedded alpha channel.
These codecs are commonly found in .mov, .mp4, .m4v, and .mkv file wrappers.
AV1 and H.266/VVC
AV1 and H.266/VVC are downstream distribution codecs, not post-production working formats.
AV1 (AOMedia, royalty-free) is the significant one for streaming. It has broad browser and hardware support, though Safari depends on AV1 support in the underlying device. By late 2025, a large share of Netflix's streaming hours were served in AV1. For an independent production it matters as a destination your master gets encoded into by the platform, not something you deliver, edit, or master in.
H.266/VVC is far more niche, with little consumer hardware decoding and no browser support. Its real traction is in broadcast. Brazil's TV 3.0 / DTV+ mandates VVC and began 4K HDR over-the-air in 2025). An independent film will not deliver in it.
Do not acquire, work, or master in either format.
Frame-Based Formats
OpenEXR (.exr)
OpenEXR (more commonly referred to as EXR) is an open-source format developed by Industrial Light and Magic (ILM) as a replacement for legacy image formats commonly used in visual effects. EXR is designed for multichannel 16-bit and 32-bit floating point: almost always in scene-linear encoding.
EXR supports alpha, multiple layers, and arbitrary channels in one file. It offers uncompressed, lossless, and lossy compression schemes.
The choice of compression scheme matters in a digital intermediate: some are cheap to decode and play back in real time, others are not, and the ACES2065-1 archival container (SMPTE ST 2065-4) permits only uncompressed data regardless. For final EXR renders delivered to the DI, uncompressed or a fast lossless scheme (ZIP / ZIP1) is the safe choice. Confirm with your DI facility or colorist before using anything heavier.
| Compression | Lossless | Real-time DI playback | Notes / when to use |
|---|---|---|---|
| None (uncompressed) | ✓ | ✓ | Largest files, no decode cost. The only option permitted in the ACES2065-1 archival container (ST 2065-4). |
| ZIP / ZIP1 (ZIPS) | ✓ | ✓ | zlib. Very efficient to decode and no real problem in modern DI systems: a safe default for VFX renders to the DI. |
| RLE | ✓ | ✓ | Run-length. Light, fast, modest savings. |
| PIZ | ✓ | ✗ | Wavelet + Huffman. Excellent on grainy / noisy plates, but slower to decode and can impact realtime playback on some systems. |
| PXR24 | ✓ half / ✗ 32-bit | ✓ | Good ratio. Lossless for half-float and integer, lossy for 32-bit float. |
| B44 / B44A | ✗ (lossy) | ✓ | Fixed-rate, designed for fast real-time playback. |
| DWAA / DWAB | ✗ (lossy) | ✓ | DCT, JPEG-like. The smallest files and fast to decode. DWAA uses 32-scanline blocks (better for partial reads, as Nuke does). DWAB uses 256-scanline blocks and decodes full frames faster. Lossy: avoid for final DI renders. |
| HTJ2K | ✓ | ✓ | High-Throughput JPEG 2000 (ITU-T T.814 / ISO/IEC 15444-15), added in OpenEXR 3.4. Two variants: htj2k256 (smallest files) and htj2k32 (much faster encode/decode). Among the fastest schemes in OpenEXR, but new, so confirm your facility's OpenEXR version supports it before delivering. |
When in doubt for a DI delivery: uncompressed, or ZIP / ZIP1.
EXRs with multi-channel render passes (AOVs: arbitrary output variables) such as normal maps and z-depth are especially advantageous in visual effects workflows. However, they are rarely included in final renders delivered to the DI, as those additional render passes are intended for lighting and compositing and may serve little benefit to the colorist and will only increase the size of the files.
EXRs, unlike most image formats, may contain image data (the "data window") outside the visible frame area ("display window"). Conversely, a data window smaller than the display window is also supported. This feature is designed for CGI compositing, particularly when producing large-kernel blurs or 2D camera shake effects during compositing. Most DI systems are incompatible with EXRs containing mismatched data and display window sizes. VFX vendors must be informed that their final renders delivered to the DI must have matching data and display window sizes. In some DI systems, mismatched window sizes can lead to image artifacts and in some cases prevent the software from reading the files at all.
DPX (.dpx)
DPX has been the standard file format for digital intermediate scanning, color grading, and
finishing for over thirty years. SMPTE 268M dates to 1994, and DPX remains a common working format for
digital intermediates as well as an intermediate format for transcoded Camera RAW media. Note that
SMPTE has since designated ST 268-1 a Stable document: still in force, but formally flagged as no
longer representing current technology and not subject to further review. In practice DPX still owns
film-scan delivery and log-encoded conform, while ACES/OpenEXR (ST 2065-4) has taken over
scene-referred interchange and archival mastering. It is the successor
to the legacy Cineon format (.cin) which preceded it as the standard film scanning format.
DPX file headers can store embedded timecode and tape name for assisting in conform.
Image data is routinely stored as fully uncompressed RGB 10-bit or 16-bit integer. Although the DPX specification defines support for floating point data types, many software and digital intermediate systems do not support floating point DPX. Alpha channel support is defined in the specification, but many systems do not support DPX with embedded alpha.
DPX files are advantageous because in practice they are written uncompressed and, unlike lossy compressed media, retain image fidelity across successive passes. (SMPTE ST 268-1 does define an optional run-length encoding, but essentially nothing in a post chain writes it, so treat DPX as uncompressed in planning.) File sizes are easily predicted, as all files of a given raster dimension, bit depth, and header length will be the same size, regardless of the image content.
TIFF (.tif, .tiff)
TIFF is an older image format that, within the context of visual effects, is largely a legacy format. DPX and EXR displaced it for plates and comps. It is emphatically not obsolete in mastering, though: 16-bit TIFF is the standard carrier for X'Y'Z' DCDMs (Digital Cinema Distribution Masters), which is about as current a use as a format can have. Aside from DCDMs, some studios prefer 16-bit DCI-P3 RGB TIFFs over DPX as an archival master, but this is quickly being replaced by EXR.
TIFFs and other legacy graphics formats3 are often used for simple title graphics that are comped over picture during the DI. In these cases, TIFF is chosen for its simplicity, as it supports an alpha channel and is readily compatible with Photoshop, where most of those graphics are generated.
TIFFs should not be used as an intermediate working format for either visual effects or digital intermediates, as DPX and EXR both provide advantages over TIFF.
TIFFs are commonly either RGB 8-bit or 16-bit integer, while 24-bit and 32-bit floating point variants exist, with support for embedded alpha channel, but without support for tape name or timecode metadata.
TIFFs can be uncompressed, losslessly compressed, or lossy compressed in a variety of ways, and support multiple layers of image data.
-
ARRI ALEXA ProRes, RED V-RAPTOR, Blackmagic URSA Cine, a variety of external third-party recorders, and more… ↩
-
Avid, Avid DNx naming scheme and data rates and DNxHR Codec Bandwidth Specifications. Rebrand announced at IBC 2025. ↩↩
-
JPEG, PNG, Targa for example. ↩