DCTL

The most important DCTL model is host versus script. The Fusion node provides image plumbing, script selection and execution while the external file supplies the actual algorithm. Two identical DCTL nodes can therefore perform completely different jobs when they load different scripts.

DCTL is not the same thing as a LUT. A conventional 1D/3D LUT stores precomputed values and interpolates between them, while DCTL contains executable code that directly computes an image transformation on the GPU.

Blackmagic describes DCTL as a C-like language. A simple transform signature can receive RGB for one pixel and return float3, while spatial variants can work with frame size, pixel coordinates and texture access. Reducing DCTL to a color matrix is therefore incorrect.

A DCTL is an external runtime dependency. The project does not magically embed the selected implementation: if another workstation lacks the file, has a different revision, or Resolve cannot discover the active LUT/DCTL location, reproducibility is lost.

The Resolve 21 Reference Manual labels the DCTL Resolve FX workflow as Studio Version Only. A composition that must also run in the Free edition needs a separate fallback or a pre-rendered result.

The DCTL host UI should be checked against the target Resolve build: the selected script can change Controls dynamically, and Color-page and Fusion host surfaces do not have to match. Visual examples should therefore be tied to a specific version and exact script.

DCTL = NONE means no user transform is selected. It is a useful host baseline, but it is not a reason to promise byte-identical passthrough of every channel on every build; critical channel behavior still requires a live test.

After a script is selected, the Inspector may gain additional controls published by that DCTL. The set is dynamic: one file may expose nothing while another publishes sliders, toggles, integer/float controls or menu-like selectors.

Script-defined controls must not be promoted into the generic host documentation as permanent DCTL parameters. Even scripts with similar goals can use different ranges, defaults and math behind similarly named controls.

Settings is the common Fusion-node tab. It is not the universal home of DCTL-script parameters. Dynamic script controls belong to the selected script's host UI on Controls and should be documented together with the exact file revision.

The correct place for DCTL in a Flow is defined by the selected script's signal contract rather than the node name. One transform may expect camera log, another scene-linear, DaVinci Wide Gamut/Intermediate, display-referred imagery, or a different technical representation.

An incorrect input state often looks like excessive contrast, wrong gamma, clipping or odd saturation. Correcting that with another ColorCorrector is risky; first check for duplicate transforms and verify that upstream matches the DCTL's documented input state.

DCTL Output remains a normal 2D image stream. It can feed ColorCorrector, Merge, Viewer, MediaOut and other 2D tools, while the meaning of RGB and Alpha after processing remains part of the selected script contract.

The simple DCTL examples in documentation demonstrate RGB processing but do not prove that every third-party DCTL preserves Alpha, auxiliary channels or values outside the nominal 0–1 range. Compositing-critical pipelines must test these behaviors explicitly.

A spatial DCTL may read neighboring pixels through texture sampling. In that case edge behavior, filtering and coordinate assumptions become part of the algorithm and cannot be described as a simple per-pixel LUT-style transform.

DCTL can use floating-point math and wide values, but that does not automatically make every script safe for HDR or scene-linear data. The code itself may clamp, normalize or assume a 0–1 range.

GPU execution does not guarantee identical performance across DCTLs. Code complexity, texture reads, conditional branches, image resolution and the GPU all affect playback and render time.

A technical-transform A/B should compare original and processed branches without changing upstream or downstream state. Otherwise it becomes impossible to isolate which stage caused the difference.

Mixing a technical transform with Merge Blend 0.5 is generally not a valid way to reduce its strength. A creative DCTL may intentionally support mix behavior, but technical transforms should only be weakened through a method documented by that script.

For production, record the exact filename, version and checksum. The same filename on two workstations is not evidence of identical code, especially when files have been manually replaced or updated.

Encrypted .dctle files remain external DCTL dependencies. Lack of readable source code does not remove the need to pin the exact installer/package version and installation conditions.

After adding a new DCTL, Resolve must discover it in the active LUT/DCTL location. The exact refresh/restart workflow depends on host and version; do not copy Color-page buttons into the Fusion UI unless they have been verified there.

DCTL Resolve FX can be used on the Fusion page as an effect host, but the Color page and Fusion Inspector do not have to expose identical UI. Generic documentation should describe only the verified common contract and mark host-specific UI separately.

A diagnostic false-color, gamut/clipping or exposure DCTL usually should not be rendered as final beauty. Label these tools as diagnostic and bypass or remove them before delivery.

When DCTL is a mandatory color-pipeline stage, put the documented IN → OUT state in the node label or comments. This reduces the chance that someone moves the transform after a Merge, CST or display-referred stage by accident.

When multiple DCTLs are chained, each script receives the previous script's output. Treat the graph as a sequence of signal contracts rather than a bag of independent looks.

For migration between Resolve builds, keep a reference frame with scopes and the script checksum. If the result changes after an update, this helps distinguish a host/GPU change from a script change.

Automation must use serialized input IDs verified from the target Resolve build. Display labels such as DCTL and dynamic control names are not sufficient for reliable scripting or macros without a captured .setting/.comp.

A production DCTL check has four separate questions: is the exact script loaded, is the IN→OUT signal contract correct, are channel/edge behaviors correct, and is the result reproducible on the target Resolve/GPU. Only then should the node be treated as pipeline-certified.