DCP has wrong gamma

[dhl]

Hello,

We've noticed a large gamma shift between my ProRes 4444 master source and DCP-o-Matic's DCP output. This change is apparent in both the DCP-o-matic player and onscreen when projected. The DCP looks washed out, lacking proper contrast and pop.

I've used DCP-o-Matic's default settings and my source is rec709 ProRes 4444. Any advice on how to correctly match my DCP gamma to my ProRes master?

Screen Shot 2022-08-09 at 8.49.38 PM.png

Many thanks for your help!

--David

[Carsten]

Try the full/limited range interpretation in DCP-o-matic. Maybe your master has been created with data levels. Where does the master file come from?

[dhl]

Try the full/limited range interpretation in DCP-o-matic. Maybe your master has been created with data levels. Where does the master file come from?

Thanks for the reply. The master was created in Premiere Pro using ProRes 4444, with Rec. 709 color space, 16-bit depth, Render at Maximum depth checked, and Use Maximum Render Quality checked.

I made this DCP with all default settings. I'll try running a test with the Full range selected and let you know how it goes.

Thanks!
--David

[dhl]

Try the full/limited range interpretation in DCP-o-matic. Maybe your master has been created with data levels. Where does the master file come from?

I tried selecting Full (JPEG, 0-255) under Range, but it had the opposite effect. The image is now even more washed out than before:

Screen Shot 2022-08-10 at 5.18.38 PM.png

Any advice on how we can go in the other direction getting darker blacks and higher contrast?

Thanks!
--David

[Carsten]

Hmmm...

The visual difference in gamma is huge enough to qualify this as an issue

Wondering wether FFMPEG has trouble to properly identify this particular ProRes format.

Do you still have access to this Premiere Project? Could you, as test, export a short passage in plain ProRes 422 and try that one?

Could you make a short snippet of the ProRes4444 master available? A few seconds around the image you posted, no audio, would be sufficient.


I guess it would be possible to correct this in DCP-o-matic using a custom color transform with a modified gamma.

[dhl]

Ye

Hmmm...

The visual difference in gamma is huge enough to qualify this as an issue

Wondering wether FFMPEG has trouble to properly identify this particular ProRes format.

Agreed, I did another test and there may actually be a couple issues going on. For this test I exported a snippet as JPEG2000 MXF op1a 12-bit.

The results surprised me. When range was set to Video, the blacks were crushed in both the DCP-o-matic preview and the DCP in the player.

When I switched the range to Full and the DCP-o-matic preview looked correct! But strangely when I looked at the DCP in player, it was washed out like before. Something seems broken. Take a look:

Screen Shot 2022-08-10 at 5.52.31 PM.png

Happy to send a ProRes 4444 snippet, it's attached below. Thanks again!

DCP-o-matic_2K_test.mov

[Carsten]

Hmm. I just created a ProRes4444 (no alpha, 16Bit) test export from Premiere Pro myself, and I don't see that gamma issue in DCP-o-matic. However, that was just an arbitrary color clip, just to see wether there is an obvious interpretation issue with that ProRes dialect.

Now, your clip---



Which version of DCP-o-matic are you using? And I assume, on a Mac?

[Carsten]

Weird. Looks 'normal' on my system. I see the same halftone rendering in both DCP-o-matic preview, Quicktime 7 Pro, and Quicktime X for the master, and DCP-o-matic player (DCP). All at defaults (rec.709, limited/video range).
My (up-to-date) VLC can't render this specific ProRes variant, though.

Again, which version of DCP-o-matic are you using? Could there be a specific interpretation issue in your version?

I am using the current 2.16.18 on a Mac. If at all, the Quicktime X has a tad bit of highlight clipping around the right side of the nose, I'd say, but, all are far from being as flat as your example.

- Carsten

[dhl]

Hmm. I just created a ProRes4444 (no alpha, 16Bit) test export from Premiere Pro myself, and I don't see that gamma issue in DCP-o-matic. However, that was just an arbitrary color clip, just to see wether there is an obvious interpretation issue with that ProRes dialect.

Now, your clip---



Which version of DCP-o-matic are you using? And I assume, on a Mac?

Very odd.
I'm using version 2.16.5 git cda2e54419

If you can get my clip working my team will be very happy!

[Carsten]

I wouldn't expect something like that between 2.16.5 and 2.16.18, but, wild guess - try the latest version.


The difference you see with the JPEG2000 export from Premiere is easy to explain - with JPEG2000 content, DCP-o-matic disables any color processing and just passes through the images, as it assumes the content has been compressed for digital cinema in another application. So, DCP-o-matic assumes it is, essentially, JPEG2000 in X'Y'Z', gamma 2.6. But that is a digital cinema specific JPEG2000 'dialect', the Premiere (or Davinci) 'plain' JPEG2000 export is not targeted at DCI/DCP compliance. So it would be RGB, gamma 2.2 or so, and would give a completely wrong DCP.


Be careful to assume JPEG2000 is always DCI/DCP compliant. If not constrained to proper DCI/DCP parameters, such DCPs will usually cause problems like frame skipping, false colors, playout server crashing, etc. The Kakadu DCP export in Davinci uses a different JPEG2000 encoder than Davincis JPEG2000 image export, and the Wraptor DCP encoder in Premiere Pro uses a different JPEG2000 encoder than Adobes JPEG2000 image encoder in Premiere. Completely different code and, thus, image parameters.

I happen to have 2.16.5 stored on my machine, will see if I can replicate the issue.