XYZ source file to DCP is shifting color

[Nasty]

I have a Prores 4444 XQ I'm using as my source file that has properly been converted to XYZ before rendering. When I add my XYZ Prores into DCP-o-matic and set "Colour" to None, color is changing in the DCP when checked against the source. The DCP's color is shifting to yellow/green. Any suggestions on what I'm doing wrong?

[Carsten]

There could be many possible issues with your XYZ conversion - limited vs. full color range, gamma issues, etc. When disabling color conversion, DCP-o-matic takes no responsibility for your source color space conversion and assumes it to be X'Y'Z' (inverse 2.6 gamma) full range at DCI whitepoint.

You are not following a standard procedure when creating your master file.

[carl]

Hi,

When you compare the DCP against the source, are you looking at the DCP in the DCP-o-matic player, or some other way?

How did you create the XYZ Prores?

Is it possible to prepare a short sample clip that demonstrates the problem, and send it to me? carl@dcpomatic.com

[Nasty]

My original source file is a P3D65 Prores 4444 XQ. I am converting to XYZ in Resolve and can confirm that the conversion is accurately converting from P3D65 to XYZ.

If I render the P3D65 file converted to XYZ from Resolve as a 16bit TIFF sequence DCDM and input that source into DCP-o-matric, set Colour to None and create a DCP, color is correct.

But if I render that same timeline as an XYZ Prores 4444 XQ and set Colour to None, the DCP color is shifted. I don't think its a range issue as there is no shift in brightness.

If DCP-o-matic is taking no responsibility for my source color space conversion when set to None, shouldn't DCP color match the source regardless?

I'm comparing the DCP to the source in Resolve with my timeline/output color space set to Rec.709 Gamma 2.4. Both the DCP and Prores source are converted to Rec.709 Gamma 2.4 under the same conversion.

I will go ahead and send a sample, thanks for your help!

[IoannisSyrogiannis]

My original source file is a P3D65 Prores 4444 XQ. I am converting to XYZ in Resolve[...]

If I render the P3D65 file converted to XYZ from Resolve as a 16bit TIFF sequence DCDM[...], color is correct.
[...]

I will not pretend that I know the answer, but doesn't that seem like the color difference between the two cases is (also) affected by that last four bits of alpha channel on 4:4:4:4 and that would not be present as an extra channel on the 16bit TIFF sequence DCDM?

I will second the the point Carsten made about gamma and DCI white point. If no brightness change appears, it would seem to me more probable that in the first case the white point remains on P3D65. If I am not mistaken, P3-D65 white point is x=0.3127 and y=0.3290, while DCI-P3 is x=0.314 and y=0.351. That means a shift that would have to take place on it (white point) towards the top and the right of the CIE chromaticity diagram, wouldn't that be the case?

Edit:
To give some substance in the difference, here is the two white points. The triangle one is the DCI one, the spade one is the D65.

CIE1931chromaticitydiagram031403510312703290.png

[carl]

This should be fixed in 2.18.19 - let me know if not!

[jamiegau]

Just reading over this now.
Wanted to make a comment.

You render to P3-65 in Pores and TIFF.
Use DOM to make a DCP with DOM set to no conversion on incoming images. Treat as in the correct gamut and gamma/EOTF

The TIFF looks right, the ProRes have a gamma shift.

Could this be a ProRes meta data issue? 1-2-1 , 1-1-1, I cannot remember the exact meaning of the codes.
But internally, if they are not what you expect, this type of issue could result. This is all inside ProRes too, I don’t see how you can fix a bug in DOM as it is a ProRes issue.

[rexbron]

To OP:

I have filed a bug report with sample files that should demonstrate the issue and provide some samples.

https://dcpomatic.com/bugs/view.php?id=3066

Re Jamiegau:

"This is all inside ProRes too, I don’t see how you can fix a bug in DOM as it is a ProRes issue"

In the sample files I created, I tried ProRes444, DPX and H264 and encountered the same behaviour, Colour=None did not have an effect.

I have provided a sample DoM project for others to test with.

[jamiegau]

From my understanding, the issue that we are most likely seeing here..
In Apple's eyes, QuickTime is working as intended, its a matter of interpretation of the standards I believe.
From ChatGPT, if you know the right question:

Yes, this is a well-known issue in workflows involving QuickTime and the use of ProRes or other intermediate codecs, particularly when working with color-managed environments (like DaVinci Resolve, Adobe Premiere Pro, or Final Cut Pro). The problem largely stems from metadata in the QuickTime file header — specifically, the color profile information, including the Color Primaries, Transfer Characteristics, and Matrix Coefficients — commonly referred to using shorthand like 1-1-1.

What is the “1-1-1” in QuickTime metadata?
The 1-1-1 code refers to:

Color Primaries: 1 = BT.709

Transfer Characteristics (Gamma): 1 = BT.709 (log-ish gamma curve)

Matrix Coefficients: 1 = BT.709

This combination is typical for HD video, but here's the catch:

The Problem
1. QuickTime Doesn't Apply or Respect Color Tags Consistently
QuickTime Player (and other Apple ecosystem tools) interprets video gamma and color based on this metadata. If the tags are missing, ambiguous, or simply defaulted to 1-1-1, the system might apply a gamma transformation that doesn't match how the image was rendered. This results in:

Washed-out or overly bright images (gamma lift)

Crushed blacks (gamma compression)

Inconsistent look between platforms (e.g., looks different in Resolve vs. QuickTime Player vs. VLC)

2. Rendering with Wrong or Missing Tags
If your application (e.g., DaVinci Resolve) renders a file without embedding the correct tags, or defaults to 1-1-1 when it should be something else (e.g., 2-2-2 for full Rec.709 with sRGB-like gamma), QuickTime will misinterpret the intent.

3. Gamma Shift
This is the most visible artifact: the rendered output looks different from the source timeline. For example:

Resolve may display the video as linear or gamma 2.4

QuickTime interprets it as BT.709 with an approximate gamma of 1.96

The result: the video looks brighter/lower contrast

Typical Workflow Mistake
You render a ProRes 422 file in DaVinci Resolve with Rec.709 2.4 gamma.

But Resolve either embeds default 1-1-1 tags or omits tags.

QuickTime assumes the content is gamma 1.96 (Apple's Rec.709 interpretation), leading to a noticeable gamma shift.

How to Avoid the Problem
Explicitly set color space and gamma tags when rendering:

In Resolve: use Color Management to define output color space.

In Output settings, ensure Data Levels and tagging are correct.

Resolve 17+ has improved tagging support — use Rec.709 (Scene) or Rec.709 (Gamma 2.4) as needed.

Test your renders across multiple players (VLC, Resolve, QuickTime) to see how they're interpreted.

Use color-managed timelines: DaVinci Resolve’s Color Management (DaVinci YRGB Color Managed) helps standardize this.

Avoid relying on Apple QuickTime Player for color-accurate viewing unless your delivery is Apple-only.

🛠 Tools to Inspect Tags
FFmpeg:

ffprobe -v error -show_entries stream=color_space,color_transfer,color_primaries -of default=nw=1 input.mov
This will show if your file is tagged as bt709, smpte170m, etc.

MediaInfo: GUI tool or CLI to inspect detailed codec and metadata info.

Summary
The 1-1-1 QuickTime metadata codes can cause unexpected gamma shifts during playback, especially in Apple environments, due to how macOS interprets BT.709 gamma. These shifts are caused not by image data itself, but by incorrect or oversimplified metadata tagging. The solution is to use proper color management in your NLE, double-check your export settings, and verify tags with tools like FFmpeg or MediaInfo.

Let me know if you want help with fixing tags using FFmpeg or scripting the workflow.