Managed system
Input, working and output states as one system: Resolve Colour Management, CST and ACES without double transforms, random LUTs or confusion between camera and display.
Colour management does not 'make the picture pretty'. It tells the system what the incoming numbers mean, which state the grade should operate in, and how that result must be rendered for a particular display or file.
Quick reference
Camera gamut/gamma, decoded RAW, Rec.709, sRGB, etc.
The working gamut + transfer must be known.
May include tone/gamut mapping, not only matrix/gamma.
RCM + CST/LUT can apply the same technical stage twice.
Managed colour
For every image you need to know: what the source encoding is; which coordinate/tonal state the tools will operate in; and which display/delivery state is required at the output. In Resolve these ideas correspond to Input Colour Space, Timeline/working Colour Space and Output Colour Space. Whether RCM, ACES or explicit CST nodes perform the transforms, the logic is the same.
In ordinary DaVinci YRGB, Resolve is not required to automatically convert camera states into one working space: you can build the pipeline yourself using CST nodes, LUTs or DCTL. In DaVinci YRGB Color Managed, the project-level system performs coordinated input/timeline/output conversions. Managed mode reduces manual technical nodes but does not remove the need to identify the source correctly.
Input Colour Space describes what is already in the file after decoding: ARRI Wide Gamut 4 / LogC4, S-Gamut3.Cine / S-Log3, Blackmagic Wide Gamut / Film Gen 5, Rec.709 or sRGB, for example. If the source tag is wrong, RCM will faithfully transform incorrectly described numbers. Automatic metadata detection helps, but a production pipeline must be able to verify it manually.
The working space affects more than 'how many colours fit'. It defines the coordinate system and transfer representation in which many grading operations and effects work. A wide scene-referred pair such as DaVinci Wide Gamut / Intermediate can retain camera latitude and saturated colours until final rendering, while colour-space-aware tools can adapt their behaviour to that state.
Moving from a scene-referred working state to Rec.709, P3, PQ or HLG usually involves more than a matrix/gamma conversion. Scene dynamic range and gamut must be fit to the target display through tone mapping, saturation/gamut mapping, display encoding and viewing assumptions. The Output Transform therefore affects appearance and should exist exactly once in each viewing/delivery path.
Automatic Colour Management in Resolve hides some settings and offers ready-made SDR/HDR processing environments. This is useful for predictable projects, but it does not remove source tagging or output verification. When an explicit Timeline Colour Space, separate gamut/tone-mapping decisions or complex multi-delivery are needed, Custom mode provides precise control over the pipeline.
In a Custom setup, the important controls include the Input Colour Space policy, Timeline Colour Space, Output Colour Space, DRT/tone-mapping options, gamut limiting/mapping and reference/graphics white for HDR workflows. Do not change several variables at once: lock the source and working state first, then the output target, and only then compare rendering options.
Colour Space Transform is useful when a transform must exist at a specific point in the node tree: a manual Input CST, a move into a special working space for an effect, or an explicit Output CST in an unmanaged pipeline. But a CST inside an already managed path can easily create a double transform. Before every CST node, write two lines: INPUT STATE = …; OUTPUT STATE = … . If you cannot name them, it is too early to place the transform.
Camera log, Rec.709 video, sRGB PNG and Display P3 graphics are not equivalent inputs. Automatically treating UI/PNG assets as scene-referred camera material is especially dangerous: display-referred graphics can receive unnecessary contrast/gamut rendering. On mixed-media timelines, source classification should be part of ingest rather than an improvised guess on the Colour page.
A major strength of a managed pipeline is separating creative grading from display rendering. One grade in a wide working context can feed Rec.709 SDR, P3 cinema and HDR targets through different output paths. That does not mean every output will be artistically identical without review: highlight placement, saturation, graphics white and display surround may require a trim pass or output-specific adjustment.
A baseline workflow is: DaVinci YRGB Colour Managed → Custom → assign the correct Input Colour Space to each camera family → Timeline = DaVinci Wide Gamut / DaVinci Intermediate → Output = the actual monitoring/delivery target. Technical Input/Output transforms then do not need to be repeated as LUTs on every clip. If a LUT is a creative look, place it where its expected input state is known and label that explicitly.
Choose one clip of each type and trace the signal state from left to right: decode → input tag/transform → timeline state → node tree → output transform → monitor. Disable technical stages one at a time and look for the expected change. If disabling one node barely changes anything, a duplicate transform may exist; if the image breaks dramatically around an unexplained node, its colour-state contract is not documented.
Colour management should let you answer 'what do these RGB numbers mean right now?' at any point. If the answer is unknown, a pleasing Viewer still does not prove the system is correct.
Technical definitions are anchored to standards bodies and primary specifications wherever that distinction matters.
Current practical guidance for DaVinci YRGB Colour Managed, Custom processing and Timeline Colour Space.
Official definition of the working gamut and transfer pair.
Input, scene-referred working context, looks and Output Transforms as an architectural model.
Why display rendering is a distinct system stage.
