FAQ
26 practical questions covering Rec.709, sRGB, log, RAW, CST/RCM/ACES, full/video levels, Y′CbCr, HDR, PQ/HLG, monitoring and common reasons colour goes wrong.
The FAQ is organised as diagnostics: determine what was encoded and how it is interpreted, then check transforms and signal metadata before blaming the grade itself.
Quick reference
Fundamentals, Resolve, HDR and troubleshooting.
Diagnostics follow the real signal flow.
Checked before creative correction.
Without this, colour comparison becomes guesswork.
The answers separate source interpretation, working state, rendering, signal metadata and display behaviour instead of treating every problem as a grading problem.
Because the Rec.709 label does not describe the whole playback chain. Transfer/display assumptions, video/full range, metadata tags, OS colour management, monitor calibration and viewing environment all affect appearance. Compare the signal state and display path, not only the gamut name.
They share RGB primaries and a D65 white point, so their gamut geometry is the same. Transfer/display conventions and typical viewing contexts differ. An sRGB file is not automatically a correct Rec.709 master merely because the primaries match.
Log is a scene-oriented encoding, not finished display rendering. If its code values are shown directly on an SDR monitor, contrast and saturation look low. Use the correct input interpretation and a viewing/output transform rather than an arbitrary contrast boost.
For log, HDR, smooth gradients, keys and heavy transforms, 10-bit greatly reduces the risk of visible quantisation and banding. It cannot fix clipped source, wrong gamut/transfer interpretation or heavy compression. 10-bit is precision, not magic quality.
It depends on the operation. Bit depth usually matters more for tonal gradients, log/HDR and aggressive grading; spatial chroma detail matters more for chroma keying, fine coloured text and compositing. 10-bit 4:2:0 and 8-bit 4:4:4 address different limits.
No. Y′CbCr is a way of representing nonlinear RGB through luma-like and colour-difference components. Primaries, transfer, matrix coefficients and range are still needed to recover colour meaning. A YCbCr label alone does not specify the gamut.
CST is useful when you want explicit local transforms in the node tree. RCM is convenient for Resolve-centric project-level management. ACES is useful as a standardised cross-application architecture. Choose based on the project pipeline rather than assuming one is always 'better'.
They are not direct competitors at the same architectural level. DWG/Intermediate is a Resolve working gamut/transfer pair; ACES is a broader interchange and transform architecture. DWG is often simpler inside Resolve, while ACES is useful when a pipeline must align across multiple applications or departments.
In a manual scene-referred chain, an Input CST usually normalises camera source into the working space before the main grade, while the Output CST/DRT follows scene-referred creative work. Display-specific trims may intentionally occur after the output transform. Know the state of each node rather than memorising a position as dogma.
A common cause is a double transform: project RCM has already performed an input/output conversion and a CST or technical LUT repeats the same stage. Check source tagging, project colour management, timeline/output settings and LUT assumptions before manually correcting the image.
No. RAW is an earlier sensor-domain representation that still requires decode/demosaic and camera interpretation. Log is a defined image encoding. A RAW decode can output log plus a camera gamut, but that is one possible result of decoding, not the definition of RAW.
First interpret each source pair correctly and bring the media into a common working state through managed input transforms or individual CSTs. Perform balance and matching after technical normalisation. Visually matching different camera encodings before normalisation is harder and less robust.
Display-authored assets are often sRGB/Rec.709-referred, while a project may mistakenly treat them as camera scene sources. Assign the correct input space or use a branch/workflow for display-referred graphics instead of forcing them through camera-style rendering.
PQ is an absolute display-luminance encoding commonly used for mastered/on-demand HDR. HLG is a relative broadcast-oriented system with a system gamma and suits some live/broadcast chains. The delivery specification should decide; one cannot be replaced by the other with a simple tag change.
The display/player must perform display mapping/tone mapping to fit the higher master range into the lower display peak. The result depends on the mapping algorithm and metadata. Hard clipping is neither the only nor the desirable option.
No. 10,000 cd/m² is the mathematical design ceiling of ST 2084. A real master may use a 600-, 1000-, 4000-nit or other approved peak. PQ code values retain absolute luminance meaning within the system, but the mastering display need not reach the ceiling.
No. That only re-encodes or reinterprets the signal relationship and does not automatically create a new scene/display rendering. A proper HDR trim/master requires decisions about reference white, highlight allocation, colour volume, tone/gamut mapping and monitoring target.
The first suspect is a full/video range mismatch or incorrect data-level interpretation. Also check transfer assumptions and the player path. A range error changes code-value mapping to black/white and can look like washed or crushed blacks without any creative grade change.
Check whether the wrong Y′CbCr matrix was applied, such as BT.601 instead of BT.709/BT.2020, and whether the primaries are interpreted correctly. A matrix mismatch produces characteristic colour shifts that should not be corrected with manual hue/saturation before source interpretation is fixed.
Different applications can use different colour-management/display paths, interpret tags differently and output through different OS APIs. Compare the master on a controlled reference path, then test consumer playback separately. A screenshot from one browser is not a reference measurement of the master signal.
They answer different questions. Scopes measure the signal representation, while a calibrated monitor shows the perceptual/rendered result. Creative colour cannot be judged from a waveform alone, just as levels/tag mismatches should not be diagnosed only by eye on an unknown display.
No. Colour management maps the signal into a target output state; calibration ensures the physical display actually matches that target. If the monitor does not match the target, a mathematically correct output transform will still be viewed incorrectly.
Not necessarily. In wide-gamut floating-point scene-referred transforms, such values can be a valid intermediate state. The problem occurs when they are sent to a limited display output without appropriate gamut/tone mapping or clipping policy.
When an image looks wrong, check the chain in one order: source state → decode → working state → rendering/output transform → signal representation/tags → display path. Adjusting Lift/Gamma/Gain before this can visually hide a technical error and make the master less predictable.
Establish the camera model/recording mode, RAW decode, camera gamut + log pair or finished display space, bit depth, chroma sampling and expected range. Metadata is useful but not infallible; for problematic files, compare it with codec/container information and the known source workflow.
A managed project, clip input tagging, CST, technical LUT, OFX colour transforms, DRT and display/viewer transforms can overlap. A double transform often looks overly contrasty/saturated; a missing transform often looks like flat log or a wrong gamut. Write the chain down explicitly before correcting the picture.
Primaries/transfer tags, Y′CbCr matrix, video/full range, codec profile, bit depth and chroma sample location are independent fields. Retagging changes interpretation but does not necessarily change pixel values. A levels mismatch or wrong matrix can ruin appearance even when the creative grade is correct.
The Resolve viewer, dedicated video output, QuickTime, a browser and a mobile device can use different OS colour-management paths and interpret metadata differently. Evaluate the reference master on a known calibrated path and test consumer apps separately as compatibility targets. One arbitrary screen cannot be both a measurement instrument and a universal reference.
Minimum evidence: source codec/container; camera gamut/log or RAW decode; project Colour Management; clip input space; timeline/working space; node CST/LUT chain; output space/gamma; Data Levels; export codec/bit depth/tags; and the application/display where the difference appears. With this information the problem can usually be localised quickly; without it, diagnosis becomes guesswork.
Do not fix a technical mismatch with creative controls. If the image still looks wrong after correct source interpretation, transform chain and display path, then it is a grading problem.
Technical definitions are anchored to standards bodies and primary specifications wherever that distinction matters.
CST, RCM, input/output spaces, groups and practical colour-managed workflows.
Independent code points for primaries, transfer, matrix, full range and chroma siting.
HDTV colorimetry, transfer and digital representation context.
PQ/HLG HDR signal systems and wide-colour-gamut television.
Input/common scene-referred/output architecture and terminology.
