PicaJet

Reference Formats

DPX

DPX is the SMPTE standard for storing one motion-picture frame as uncompressed, 10-bit log-encoded pixel data, used across film scanning, digital-intermediate, and VFX pipelines.

Extension

.dpx

Full name

Digital Picture Exchange

Introduced

1994 (ANSI/SMPTE 268M-1994, published February 18, 1994); revised as SMPTE ST 268-1:2014 and ST 268-2:2018 for HDR extensions

Vendor

SMPTE (Society of Motion Picture and Television Engineers)

What is inside the container

A DPX file holds exactly one image frame, never a clip: a moving shot is stored as a padded, sequentially numbered stack of files (shot_0001.dpx, shot_0002.dpx …), not a single video container. The header carries a large block of production metadata — image orientation, source device, timecode, film-key numbers, color and gamma information — ahead of pixel data that is typically 10-bit logarithmic RGB packed three channels per 32-bit word, though the spec also allows 8, 12, or 16-bit linear encodings. The log encoding exists to preserve the extended dynamic range of a film negative before any color grading is applied, which is why DPX sequences are treated as an unprocessed digital negative in post-production, not a finished picture.

How to open it

Post-production / color DaVinci Resolve and Nuke/Nuke Studio read and write DPX sequences natively as their standard VFX and grading interchange format.
Review / playback RV (Autodesk/Tweak Software) and djv Imaging play DPX frame sequences at speed with color-managed preview, the way editorial reviews footage before conform.
Command line FFmpeg can decode individual DPX frames or an image-sequence glob (ffmpeg -i frame_d.dpx) for transcoding to a proxy; OpenImageIO's oiiotool reads/writes DPX headers and pixels directly.
Still image tools Photoshop and ImageMagick can open a single DPX frame for inspection, but neither is built for sequence-aware playback or bulk header editing.

For archives

Archive the full numbered frame sequence together with its DPX headers intact — cropping to a video file discards the per-frame metadata and the log-to-linear mapping a colorist needs later. Store a lightweight ProRes or H.264 proxy alongside the sequence purely for browsing, since no generic DAM viewer decodes raw DPX previews at scale. Checksum every frame individually (not just the folder) because a single corrupt frame in a 5,000-frame shot is easy to miss otherwise, and never re-encode the master frames to a lossy format.

DPX grew directly out of Kodak’s Cineon film-scanning system: when Cineon’s proprietary .cin format needed an industry-wide standard, SMPTE added a formal header and published it as ANSI/SMPTE 268M-1994 on February 18, 1994. The format was built for one job — carrying a scanned or rendered motion-picture frame between different vendors’ hardware and software without loss — and that single-purpose design is still exactly what it does thirty years later in digital-intermediate and visual-effects pipelines.

Cineon (.cin)DPX (.dpx)
Standardized byKodak proprietary, never formally standardizedSMPTE (ANSI/SMPTE 268M-1994)
First releasedSeptember 1992February 18, 1994
Pixel encoding10-bit log RGB, 3 channels per 32-bit wordSame log encoding, plus 8/12/16-bit linear options
HeaderMinimal, fixedExtensible metadata block (timecode, film-key numbers, device info)
Current statusLegacy, effectively replacedActive industry standard, extended for HDR in ST 268-2:2018

Because a DPX file is one frame, a two-minute shot at 24 fps is 2,880 separate files sharing a naming convention and a frame-padding scheme. This is the part that trips up asset systems built for photos or finished video: a DAM has to recognize the sequence as a single logical asset, generate a representative thumbnail from one frame (usually without a real DPX decoder on the server), and keep the sequence’s file count and total size intact rather than treating each frame as an orphaned image. Losing frames, renumbering, or letting a sequence get split across folders breaks conform in the editing suite downstream.

The 10-bit logarithmic encoding is the other reason DPX needs specialized handling: pixel values map to film density, not to display brightness, so opening a raw frame in an ordinary viewer without the right color transform produces a flat, washed-out image that looks broken even when the data is perfectly fine. A production DAM that ingests DPX has to either apply a known LUT for preview generation or clearly label the preview as unconverted, rather than silently misrepresenting the footage.

Frequently asked

Why does a DPX file only ever contain one frame instead of a whole clip?

DPX was designed as a frame-interchange format for film scanning and digital-intermediate work, where every frame historically corresponded to one physical film frame passed between scanner, recorder, and grading systems. Keeping one frame per file lets any single frame be re-scanned, replaced, or graded without touching the rest of the shot.

Why does a DPX frame look washed out or flat when I open it in a normal image viewer?

Most DPX frames store 10-bit logarithmic pixel values that map to film density rather than to screen brightness. Without applying the correct log-to-linear conversion or a color transform (LUT), the raw values render as a low-contrast, desaturated image even though no data is missing.

Can a DAM generate a usable thumbnail from a DPX sequence automatically?

Only if it has an actual DPX decoder and applies a reasonable default color transform, since generic image libraries and browsers do not read DPX. Tools built on OpenImageIO or FFmpeg's DPX decoder can extract and convert one representative frame; without that, a DAM will fail to preview the format at all.

Is DPX compressed?

Almost never in production use. DPX supports several bit depths but is conventionally stored uncompressed to guarantee lossless round-tripping through scanning, grading, and recording, which is also why sequences are large and storage-heavy in an archive.

How should a DAM track a DPX sequence as a single asset instead of thousands of files?

The system needs to recognize the shared filename stem and zero-padded frame counter, group the files into one logical asset with a frame range and total count, and prevent partial deletion or renaming of individual frames, since editorial and VFX tools expect the sequence to remain contiguous and complete.

What's the difference between DPX and Cineon in a DAM context?

Cineon (.cin) is Kodak's original proprietary format and DPX is its SMPTE-standardized, more extensible successor with a richer metadata header; DPX has effectively replaced Cineon in modern pipelines, so a DAM handling legacy Cineon assets is usually dealing with archival material rather than active production.

Can DPX carry alpha or extra channels for VFX compositing?

Yes — the SMPTE 268M specification allows additional image elements per file, including alpha and other auxiliary channels, though in practice most production pipelines keep DPX to RGB and handle mattes as separate elements or in EXR instead.

Should a DAM convert DPX sequences to another format for long-term storage?

No — DPX is the standard interchange format film and VFX vendors expect, and converting the archival master away from it risks losing the exact log encoding and metadata a future re-grade needs. Keep DPX as the preservation master and generate a compressed proxy (e.g. ProRes) purely for browsing and review.

Sources