Signal source

Cameras, RAW, log and camera gamuts

The complete chain from photons and a CFA sensor to camera-native RGB, RAW decode, a log/gamut pair and technical normalisation in DaVinci Resolve.

Sensor responseCFA / DebayerRAW decodeCamera RGBLog + gamut

In plain language

A camera does not record finished Rec.709 colour. The sensor measures light through spectral filters, then debayering and camera colour science build an RGB representation. RAW preserves an earlier state of that chain, while log is already a defined encoding of a formed image signal.

12 sections4 primary references

Quick reference

Definitions and numbers worth keeping in view

First RGB state

After debayer

A CFA photosite usually measures one filtered component; full RGB is reconstructed.

RAW

Earlier sensor-domain state

Not equivalent to log and does not mean all processing is absent.

Log

Defined image encoding

Always interpreted together with camera gamut/generation.

Production rule

Source → decode → gamut/gamma

Only then come normalisation and matching.

Camera pipeline

Colour appears through an interpretation chain, not inside the sensor

Photons + CFA

Filtered photosites measure spectral response

RAW / sensor data

Earlier device-dependent state

Debayer

Mosaic → camera-native RGB

Colour engine

Calibration · WB · matrix / rendering

Log + gamut

Defined source pair for post

RAW ≠ Log

Gamma without gamut is half a description

Match only after normalisation

A sensor measures energy, not finished colours

A photosite fundamentally measures incoming photon energy. To obtain spectral discrimination, a colour filter array is placed over the photosites — most commonly a Bayer-like mosaic, although other designs exist. The red, green and blue filtered photosites do not behave like ideal narrow R/G/B bands; they have broad, overlapping spectral sensitivity curves. Camera RGB is therefore initially a device-dependent measurement of a specific sensor, not universal Rec.709 RGB values.

CFA: why one photosite usually does not know full RGB

In a Bayer CFA, each photosite measures only one filtered component. Full RGB at every output pixel is reconstructed computationally from neighbouring samples. The simple statement 'sensor equals three RGB channels' hides an important intermediate stage: spatial sampling, CFA pattern, optical low-pass/aliasing behaviour and the subsequent demosaic all affect detail, moiré, coloured edges and noise.

What RAW actually preserves

RAW usually stores sensor-domain data, or a representation close to it, before some irreversible image-processing decisions. That allows a decoder to choose white balance, demosaic quality, highlight recovery, noise-processing strategy and output gamut/gamma later — but the controls available depend on the format and vendor. RAW does not mean 'no processing at all': black-level correction, compression, calibration data and metadata may already be part of the system before the file is written.

Debayer turns the mosaic into camera-native RGB

Demosaic/debayer interpolates the missing colour components and forms three channels. A good algorithm tries to preserve edge detail, avoid false chroma and remain stable in noise at the same time. After debayering, the result still belongs to the camera-native spectral response. Moving into a standard working space requires further colourimetric interpretation — a matrix/transform, white-balance state and often a vendor-specific colour engine.

White balance is part of interpreting sensor response

In a RAW workflow, white balance is often applied as channel gains or related transforms during decode, while camera metadata carries the initial intent that can be changed without the same degree of loss as with an already baked video signal. But white balance does not replace camera characterisation: neutralising a grey card and accurately transforming saturated colours are different tasks.

Camera colour science: from native response to a defined RGB space

After sensor measurement, the manufacturer applies calibration, matrices and nonlinear/colour-rendering operations to map device-dependent response into a defined system. ARRI REVEAL, for example, describes separate debayer and colour-engine stages before AWG4/LogC4 encoding. This is where spectral sensitivities, calibration under illuminants and vendor design choices matter: two cameras can share the same target gamut yet differ in how they got there from sensor-native space.

Camera gamut and log curve form one source pair

The gamut/primaries describe the chromatic coordinate system while the log curve describes tonal encoding. ARRI LogC4 must therefore be read together with ARRI Wide Gamut 4, Sony S-Log3 with the specific S-Gamut variant, and Blackmagic Film Gen 5 with the corresponding Blackmagic Wide Gamut. Choosing the correct Gamma in CST but the wrong Colour Space only describes half of the source.

RAW and log live at different layers of the pipeline

RAW is a container for an earlier camera state; log is a defined nonlinear encoding of an already formed image signal. BRAW or ARRIRAW can be decoded into different supported output states. A ProRes/DNx log file or another already recorded log signal already carries a specific gamut/gamma interpretation. Bit depth, RAW/codec and log/gamut therefore cannot be collapsed into one generic 'colour quality' property.

Three real camera families

Vendors use different names and generations, but the principle is the same: identify the recording state precisely rather than guessing from a flat-looking picture.

ARRI: LogC4 + ARRI Wide Gamut 4; AWG4 uses D65 and LogC4 is a scene-referred logarithmic encoding.

Sony: S-Log3 can be paired with S-Gamut3 or S-Gamut3.Cine; those gamuts are not interchangeable merely because the gamma is the same.

Blackmagic: camera RAW decode and Film/Wide Gamut generation must match the metadata and colour-science generation.

DaVinci Resolve practice: identify the source state first

For a RAW clip, start with Camera RAW decoding and check which Colour Space/Gamma the decoder produces. For already recorded log, assign the Input Colour Space through RCM or use an explicit Input CST. In unmanaged YRGB, label the technical nodes: SOURCE → INPUT CST → WORKING. Normalisation should be deterministic: the same recording state should receive the same transform regardless of which timeline contains the clip.

Multi-camera matching starts before the creative grade

Each camera should first be converted from its correctly identified source state into a common working context. Only then should exposure placement, white balance, lens/sensor rendering and creative response be compared. If cameras are matched before technical normalisation, the primary controls must compensate for both real camera differences and transform errors, producing a grade that does not travel well across scenes.

What post cannot recover

RAW and log provide latitude, but they do not remove the physical limits of capture. Clipped photosites, motion blur, severe underexposure below the useful noise floor, spectral mismatch under difficult LEDs and aliasing do not become correct data by changing a Colour Space dropdown. A good colour pipeline preserves what the camera actually measured; it does not invent missing information.

What this changes in post

In Resolve, keep an explicit line for each camera type: format → decode state → Input Colour Space/Gamma → working space. That table is more useful than a collection of random conversion LUTs.

Common mistakes

Identifying camera log by how the Viewer looks.

Treating RAW as merely '12-bit log'.

Choosing Gamma without the matching camera gamut.

Using one technical LUT for different camera families.

Matching cameras before source-state normalisation.

Expecting RAW to recover physically clipped or unmeasured information.

Standards and primary references

Technical definitions are anchored to standards bodies and primary specifications wherever that distinction matters.

ARRI — REVEAL Color Science

Official debayer → colour engine → AWG4 → LogC4 pipeline.

ARRI LogC4 Specification