What the transfer characteristic field is
DPX (SMPTE 268M) stores a set of image-information fields ahead of the pixels, and two of them describe colour intent: the transfer characteristic and the colorimetric specification. The transfer characteristic is a single coded byte that names the function relating stored code values to light or density - for example logarithmic (printing-density / Cineon-style) or linear. It does not transform the pixels; it is a label that tells the reader how to interpret them. Get the label wrong and every downstream tool applies the wrong inverse curve.
Cineon/log vs linear
| Encoding | What the code values mean | Typical use |
|---|---|---|
| Log (Cineon) | Code values track printing density on a logarithmic curve - the way film responds and prints. 0-1023 in 10-bit maps to the negative's range, black around 95, white around 685. | Film scans, plate pulls, DI interchange |
| Linear | Code values are proportional to scene light, no curve applied. Simple maths, but spends bits inefficiently on the range the eye cares about. | Some rendered or converted plates, when a spec explicitly asks for it |
The two contain the same picture in principle, but the numbers are distributed completely differently. Feed a log file into a pipeline expecting linear and the midtones crush and the highlights clamp; do the reverse and everything washes out flat and milky. The pixels are "fine" - the interpretation is broken.
Why 10-bit log is the film/DI standard
The Cineon log encoding was designed to pack the full latitude of a film negative into 10 bits per channel without visible banding, by allocating code values along a curve that matches how film - and human perception - handles light. It became the lingua franca of the digital-intermediate era, and it stuck: even now, plate pulls, film scans and many finishing deliverables are specified as 10-bit log DPX. When a spec says "DPX 10-bit log", it is asking for exactly this - Cineon-style logarithmic transfer, 10-bit, and it will check the header field, not just the file extension.
How a wrong transfer flag breaks a pull
- Silent contrast damage. The plate ingests, the pipeline applies its standard log-to-working transform, and because the file was actually linear the result is wrong - but nobody sees it until a comp looks off two steps later.
- Round-trip rejection. A finishing house that automates ingest simply bounces anything whose transfer field does not match the spec, before a human ever opens it.
- Bit-depth mismatch alongside it. A 16-bit DPX where the spec said 10-bit, or 8-bit where it said 10, fails for the same "reads the header" reason - the two errors travel together.
None of this is visible in a thumbnail. The only reliable way to catch it before upload is to read the header field and compare it to the spec.