DisplayCAL 3D LUT Settings for DaVinci Resolve

Generating a 3D LUT for DaVinci Resolve with DisplayCAL should be straightforward, but the settings that worked in the Python 2 era do not all behave the same in DisplayCAL-py3 3.9.x. Users in GitHub issue #411 spent hours finding a working combination. This page collects what actually worked, with honest attribution.

The Settings That Worked

Attribution: these settings were reported by community member Adam-Color in issue #411 after extensive trial and error. They are user-reported, not official presets, but they produced a solid calibration with correct white point where the defaults did not.
  1. DaVinci Resolve: use video levels (not full or data levels).
  2. DisplayCAL: use full levels all the way through the workflow.
  3. Drift compensation: off.
  4. Black level: as measured.
  5. Tone curve: as measured. (The reporter noted tone curve calibration appears broken in this workflow.)
  6. Black output offset: 100%.
  7. Gamma: absolute gamma.
  8. Rendering intent: preserve saturation.
  9. Apply calibration (vcgt): on.

Why These Matter

Levels: the number one gotcha

Video (limited) vs full (data) levels mismatch is the classic cause of washed-out blacks or crushed shadows in a Resolve pipeline. Resolve and DisplayCAL must agree on what the signal means at each stage, hence video levels in Resolve paired with full levels in DisplayCAL’s processing.

Drift compensation

Normally useful for long runs, but in this workflow users found the mid-run re-measurements interacted badly with the video-level signal chain. Off is the reported-good setting.

Tone curve: as measured

Rather than forcing a theoretical curve, measuring the display’s actual response and building the LUT around it gave better results in the reported case.

Patch Count Guidance

A 3D LUT is only as good as the data behind it. A few hundred patches is a practical starting point for most displays; 1000+ patch sets suit reference monitors where you can let the meter run for hours.

Verifying the Result

After generating the LUT, load it in Resolve and check with familiar reference material. Skin tones and neutral grays reveal problems fastest. Then run DisplayCAL’s verification to get numbers: the report tells you whether the white point and gamma actually landed on target (see also our white point troubleshooting if they did not).

Known Friction in 3.9.x

The maintainer acknowledged in issue #411 that 3D LUT workflows deserve more attention in the Python 3 branch and that a bug is possible. If the settings above do not work for you, please report your display model, signal chain, and versions on the issue. That is how it gets fixed.

Related: DisplayCAL troubleshooting hub | 3D LUT video guide | 3D LUT for madVR

Frequently Asked Questions

Should I use video levels or full levels in DisplayCAL for Resolve?
The community-reported working setup (GitHub issue #411) is: video levels in DaVinci Resolve, full levels all the way through in DisplayCAL. Mismatched levels are a common cause of washed-out or crushed results.
What is drift compensation and why turn it off for Resolve?
Drift compensation re-measures reference patches during long profiling runs to correct for display drift. In the Resolve 3D LUT workflow, users reported better results with it off. The re-measurements interacted badly with the video-level signal chain.
How many patches should I use for a Resolve 3D LUT?
More patches means a smoother LUT but a longer measurement. A few hundred patches is a practical starting point; large (1000+) sets are for reference displays where you can leave the meter running. Users in issue #411 mentioned a Resolve-oriented patch set as worth trying.
Does the 3D LUT workflow work in the Python 3 branch?
Mostly yes, but issue #411 documents real friction: settings that worked in the Python 2 era do not all behave the same in 3.9.x. The maintainer acknowledged this may be a bug worth investigating. Use the settings on this page as your starting point.