DCP-o-matic 2.18.34+: anyone validated the P3-D65 / gamma 2.6 preset for theatrical delivery?

[neothilic]

Hi everyone,

I’m handling DCP creation for a film. The intended handoff from grading is a DSM image sequence specified as P3 primaries, D65 white point and gamma 2.6.

Has anyone used the dedicated “P3 D65 (~6500K)” source colourspace preset in DCP-o-matic 2.18.34 or later, and checked the resulting DCP for colour accuracy?

The workflow I’m looking into is:

P3-D65 / gamma 2.6 master → DCP-o-matic with “P3 D65 (~6500K)” selected manually → XYZ DCP → theatrical QC.

I’ve read the older discussion about the P3 preset and white-point interpretation:
https://dcpomatic.com/forum/viewtopic.php?t=2193

I also saw that version 2.18.34 renamed the old preset to P3 DCI and added separate P3-D60 and P3-D65 options:
https://dcpomatic.com/bugs/view.php?id=3124

I’d appreciate first-hand experience with the newer P3-D65 preset. If you’ve used it, could you share whatever details you have?

- DCP-o-matic version and operating system.
- Source format and bit depth, confirmed gamma, and full/video range settings.
- Whether you used the preset unchanged or needed any custom settings.
- How you checked colour: projection on a calibrated cinema system, comparison against a trusted XYZ conversion, or a colour-managed round-trip.
- Whether it matched the approved grade, particularly neutral greys, skin tones and shadow detail.

Successful cinema ingest and playback would be useful to hear about too; please mention whether a separate colour check was performed.

A brief account of a completed delivery would help. Experiences where this workflow needed a correction are equally welcome.

Thanks!

[neothilic]

Following up with some measurements in case they help others investigating this.

Short version: I did not reproduce a general P3-D65 transform failure with lossless RGB TIFF input. I did find a small, repeatable luminance difference between direct ProRes input and a Resolve-decoded TIFF intermediate. These are digital-file tests, not calibrated cinema validation.

My original question mentioned DSM image sequences, but the actual master available for testing was ProRes 4444 XQ, so I tested both image and video input paths.

Setup: DCP-o-matic 2.18.48 on macOS, Resolve 21.0.4.5, and FFmpeg 9.0.1 for analysis. Comparisons used 2K Flat, 24 fps, SMPTE, 200 Mbps.

1. Controlled RGB and ProRes tests

I compared known P3-D65 / gamma 2.6 RGB16 TIFF input using the P3-D65 preset against independently calculated XYZ TIFF input with no further colour conversion.

Across 4,912 non-black RGB-lattice patches, mean CIEDE2000 error against the calculated target was:

- P3 RGB TIFF → P3-D65 preset: 0.0280
- Precomputed XYZ TIFF → no colour conversion: 0.0214
- Controlled ProRes 4444 XQ → P3-D65 preset: 0.2074

Calculated white Y was 47.9987 for both TIFF routes and 47.5588 for the ProRes route, on a nominal 48 cd/m² scale. These are values derived from decoded XYZ, not projector measurements. Fitted grayscale gamma was approximately 2.601 for all three.

The ProRes control used explicitly generated 10-bit nominal-range YUV values, with decoded black/white checked at 64/940. It is therefore not a test of all native 12-bit ProRes precision. An earlier fixture producing white at 943 was excluded from these results.

2. Fifteen-minute test with all Resolve grading nodes disabled

Using the same section of the actual ProRes master:

- A: ProRes → unmanaged DaVinci YRGB, all grading nodes disabled → full-range P3 RGB16 TIFF → DCP-o-matic P3-D65 → DCP.
- B: Original ProRes → DCP-o-matic P3-D65 → DCP.

Both used the same DCP-o-matic colour conversion settings. No LUT, CST, exposure adjustment or XYZ-normalization node was used. An earlier comparison included normalization; that is not the basis for these results.

I sampled 182 positions across 21,600 frames; 181 were non-black. The mathematical reference used native 12-bit YUV decoding, explicit Video-range/BT.709 matrix conversion, and P3-D65/gamma 2.6 RGB-to-XYZ calculation. BT.709 here describes the YUV matrix, not the RGB gamut.

Median per-frame Y bias against that model:

- A: −0.260%
- B: −1.015%
- B relative to A: −0.757%

Mean block-averaged ΔE00 was 0.105 for A and 0.149 for B. These use 16×16 linear-XYZ averages, not individual pixels. A separate full-resolution check at 16 anchors gave mean pixel ΔE00 of 0.842 and 0.858 respectively.

Neither route is ground truth: the Resolve TIFF already had a small model-relative luminance offset before DCP encoding.

3. Full-feature direct encode

A subsequent 150 Mbps direct encode passed package/hash verification and full-length picture decoding: 129,661 frames, approximately 90 minutes. All six audio channels were sample-identical to the source.

This has not yet been validated through destination-cinema ingest or calibrated projection.

My current interpretation

The lossless RGB results support the P3-D65 conversion working as expected in this setup. The ProRes difference persists without grading nodes, but these tests do not establish whether decoding, range handling, rounding or another processing stage is responsible. They do not justify declaring direct ProRes unusable or applying a blanket gain correction.

I’m attaching two plots; the supporting notes distinguish patch, block and full-resolution metrics.

Has anyone replicated this with a controlled ProRes source, or compared the current preset against an approved reference on a calibrated cinema system? Suggestions for isolating the remaining input-path difference would be very welcome.

[Wolfgang Woehl]

One isolating test would be to compare

- ProRes > DCP-o-matic (implicitly using its FFmpeg version)
vs
- native (not Resolve's) FFmpeg conversion of ProRes to RGB16 TIFF > DCP-o-matic

[neothilic]

Thanks, Wolfgang — I tried your suggested isolation test, replacing Resolve with standalone FFmpeg.

The key result: 21,600/21,600 compared JPEG2000 frame payloads are byte-identical between the FFmpeg → RGB16 TIFF → DCP route and the preserved direct ProRes DCP. I compared the actual frame payloads read from both MXFs, not just mean colour metrics or stored hash strings. Native XYZ12 checks at 16 anchors also showed zero pixel differences.

This was a continuous 15-minute / 21,600-frame test at 2K Flat, 24 fps, SMPTE, 200 Mbps. Both routes used the same P3-D65/gamma 2.6 conversion in DCP-o-matic 2.18.48. Standalone FFmpeg was 9.0.1; the bundled libraries report n7.0.1-18-g6a0411c388.

So the earlier Resolve-vs-direct difference disappeared when I substituted this FFmpeg TIFF path. However, the approximately 1% offset against my declared mathematical reference did not disappear: it was already present in the FFmpeg TIFF before DCP encoding (median Y bias -0.9982%, versus -1.0153% after DCP encoding).

I then removed ProRes, TIFF and DCP entirely and tested exact synthetic neutral YUV values. With 12-bit Video-range white Y=3760 and Cb=Cr=2048, FFmpeg returned R=G=B=65283 in RGB16, versus a full-range mathematical target of 65535. That corresponds to approximately -0.9967% in calculated luminance at gamma 2.6. Both bundled and standalone libraries returned the same values; the corresponding 10-bit test did too.

This seems to narrow the remaining numerical question to YUV-to-RGB normalization in the tested FFmpeg path, rather than the P3-D65 preset. I’ve included a small synthetic-only reproducer and plots, with no film material.

Is that RGB16 endpoint expected for this swscale conversion, or is there another range/normalization setting I should be checking?

These remain file-based measurements, not calibrated cinema validation. No gain correction was applied, and agreement between two FFmpeg-based paths is not an independent guarantee of absolute colour accuracy.