Blackmagic Forum

I have an ACES project outputting via 709 transform. I set up a test Deliver to a Kakatu DCP and looked at it in the DCP-o-matic player. The gamma is darker (probably 2.6 vs 2.4) than the 709 output. I would have thought that Resolve might do the gamma shift automatically but apparently not. Does this mean that I should set the OT to p3-DCI before rendering?

Also I downloaded DCP-o-matic because when I import the DCP mxf into Resolve there seems to be no input ACES transform from XYZ. Is there a LUT somewhere?

David, what camera recorded the footage? You need to set the ACES IDT appropriate to the camera that created the image.


Sent from my iPhone using Tapatalk

Thanks, Rick, I know. All the IDTs for the various input formats have been set correctly. That's not the issue at all. It's whether the ODT needs to be changed to P3-DCI (gamma 2.6) before making the DCP. I doubt it because that would likely also affect the gamut but the Kakatu DCP option is new so maybe there's some quirks and necessary workarounds, especially with ACES projects.

I ran some tests and changing the OT to P3 DCI is definitely NOT the solution. It doesn't correct the problem and alters the colour gamut.

To summarize what's happening:

Creating a Kakadu DCP output from and ACES project with a 709 OT with Deliver data levels set on Auto. Looking at the result in the DCP-o-matic player the blacks get severely crushed.

Changing the Deliver data levels to video the blacks are crushed a little and there is a slight yellow shift.

Either way the results do not look good in the DCP-o-matic player

As a workaround, export a dpx sequence at rec709, make a new project with timeline at 709 and do the dcp from there
.

David Cherniack wrote: Looking at the result in the DCP-o-matic player the blacks get severely crushed.

Changing the Deliver data levels to video the blacks are crushed a little and there is a slight yellow shift.

Do you have any way of roundtripping an analytical project (bars, greyscale ramps, etc.) that can be scoped rather than eye-balled?

When I read "blacks are crushed", 9 out of 10 times it is because of a value range error. You should be able to open a DCP for at least 15 seconds of playtime natively in Resolve. I don't know if R15 will play the whole movie... I own a license of easyDCP for that express purpose.

jPo, CSI

Many versions later and DCP in Resolve is still a mess in short summary. There is basically no control over it and no real knowledge what is going on behind the hood.

More tests and something useful to report.

My observation that blacks are crushed comes from the SMPTE bars at the begining of the timeline. The pluge chips disappeared except when I exported by video levels in which case they were too bright.

However,

Taking Walter's implied suggestion that the issue might be ACES, I had a DNxHR 12 bit RGB Quicktime export lying around. I pulled it in to a 709 project and exported an minute of DCP with the Kakadu non-interop setting. Interestingly that imported and converted in the viewer to 709 (where interop showed as XYZ unconverted in my ACES project) so I could look at the bars. The pluge and Resolve scope were dead on exact from the QT file.

So the blacks being crushed seems to have been caused by the DCP-o-matic player that crushed super blacks. I'd guess that the only way to know for sure is take it to a screening room with a DCP projector.

FYI the Demo of EasyDCP Player read the blacks correctly after I told it the file was full range. I couldn't find any option like that in DCP-o-matic.