LUT verification gives wrong results in 3.9.16 (but works in 3.8.9.3 on Intel Ma

[saltarob]

Hi, and thanks for maintaining DisplayCAL!

I’m trying to verify a 3D LUT applied in DaVinci Resolve on the GUI screen (i.e. part of the desktop, not through DeckLink). I followed the instructions from the wiki here:
🔗 https://hub.displaycal.net/wiki/3d-lut-creation-workflow-for-resolve/

The workflow used:

DisplayCAL sends the verification patch sequence to Resolve

Resolve displays the patches on the GUI viewer with the 3D LUT active

I measure the screen using an i1Display Pro colorimeter

Simulation profile set to Rec.709 (tone curve Gamma 2.2 — same as in LUT creation)

No device link used, just checking the LUT application accuracy visually and by measurement

Problem:
In DisplayCAL 3.9.16 (macOS 15.5 on Apple Silicon), the measured results are completely off — despite the visual output looking fine.
But when I do the exact same process with DisplayCAL 3.8.9.3 on an Intel Mac, I get expected values and good accuracy.

Question:
Is there anything that changed in the verification process or handling of LUT-based workflows between versions?
Or is there a known issue with the current 3.9.16 verification when measuring GUI display + active 3D LUT (Resolve)?

Happy to provide logs, settings, and measurements if needed. Thanks again!

Calibrite Display Pro HL on Amazon  
Disclosure: As an Amazon Associate I earn from qualifying purchases.

[Vincent]

Show us where the results are off. Or look af them by yourself. This usually points to the culprit, usually user misconfiguration.
Examples:
-low contrast : signal level mismatch
-20 b* error, likely to be using some ICC prpfile with PCS white (D50) with abs colorimetric lut.
-desaturation (color management twice, did you disable ICC profiles in Resolve?), or oversaturation (no LUT applied)
… et cetera

HTML report show these common issues you just need to look at them.

[saltarob]

Hi Vincent,

Thanks for the helpful tips and for pointing out the common pitfalls.

I’ve figured out that the new version of DisplayCAL isn’t saving settings — and worse, it silently alters some of them during profiling, which is quite strange.

I made sure to configure everything properly before starting the profiling process, and then saved the LUT afterward — exactly as I’ve always done in version 3.8.9.3 without any issues. But after several test runs, it became clear that DisplayCAL 3.9.16 changes certain settings during profiling, possibly reverting them to defaults. So now, at every step, I have to double-check all settings, because DisplayCAL modifies them silently in the background.

Also, it no longer saves profiles as reusable presets, and the “Load settings…” option only restores part of the configuration — leaving the rest to be verified manually.

On top of that, DisplayCAL doesn’t remember that ArgyllCMS is already installed. Every time I restart, it asks to install it again.

Is this a bug that should be reported, or is DisplayCAL 3.9.16 still under development and these are features not yet fully implemented?

Thanks again for your support.

• This reply was modified 10 months ago by saltarob.

[Author]

Posts