DCP has wrong gamma

[dhl]

Hi Carl and Carsten,

I've just spent that past couple hours with Jamie LeJune, a master colorist who has figured out the problem.

Even thought my source ProRes file was exported rec.709 it's actually graded in a BT.1886 color signal path. When we switched the DoM color setting to Rec.1886, the test DCP looked correct:

Screen Shot 2022-08-12 at 6.05.32 PM.png

Top left - ProRes source
Top Right - DoM Rec.1886
Bottom left - DoM Rec.709

Jamie said it's really great you have user options to select the output colorspace. This is impossible to do in Premiere Pro or FCP, though it is possible in Resolve.

I've been working in Premiere Pro and even though I've exported in Rec. 709, Premiere is internally maintaining the BT 1886 colorspace. It just doesn't give any user feedback or control during export.

I've learned more about color management this afternoon than I've known in decades.

I've confirmed that the Rec.1886 setting (maybe you should rename it BT.1886 to be exact?) looks correct in the monitor. We'll confirm our next DCP in a cinema to be sure we're definitely solved the problem.

I should note that I'm did this test with the current release version of DoM. I just downloaded the OpenGL fixed version of DoM Player and it's now displaying gamma properly with OpenGL:

Screen Shot 2022-08-12 at 6.29.52 PM.png

Hopefully we've solved both problems! I'll let you know how our cinema test goes. Many thanks to both of you for your help!

[Carsten]

I did the same today at our cinema, actually I just returned from there where I tested the clips after our late show.

While the regular rec.709 version does not look as washed out on our projector as in DCP-o-matic player in OpenGL (now solved), it indeed still lacks punch in DCI format on a proper DCI projector.

I created four different versions - rec.709 (gamma 2.2), BT.1886 (gamma 2.4), one with a gamma of 2.0, and one with gamma 2.6, and played them in a sequence. My personal preference was between 2.4 (BT1886) and 2.6.

It certainly is true that a black and white image directs your focus to the gradation more than a color image.

There is a long story about the relation and transition between rec.709 and rec.1886/BT.1886. We have both in DCP-o-matic, the essential difference is indeed the gamma 2.2 vs. 2.4. rec.709 actually does not have a spec'd display gamma at all (they were just assuming the default CRT gamma back in the early nineties). Some say, when today an imaging product indicates 'rec.709', it is actually BT.1886. BT.1886 finally brought the proper gamma spec, and one could say that the lower gamma (rec.709 and sRGB) are targeted towards standard daylight/office viewing environment (web video), while BT.1886/gamma 2.4 is targeted towards an improved 'home cinema' viewing experience. And finally, 2.6 is for a dark room, a cinema, an optimized theatrical environment. So, it doesn't surprise me that todays video editing applications use 2.4. Davinci, of course, allows for more detailed settings.




- carsten

[dhl]

Hi Carsten and Carl,

I'm preparing two DCPs to test in the cinema next week and am having an odd problem with DoM Player.

One of the the DCPs opens fine on my EXT2 formatted drive.

The other DCP opens fine on my macOS hard drives, but after I copy it to the EXT2 formatted drive, it gives this error:

Screen Shot 2022-08-17 at 11.47.56 PM.png

This is happening in both the release and beta versions of DoM Player. The .mxf file plays perfectly fine from the EXT2 drive in Video Village Screen.

Any idea what the problem might be?

Thanks!
--David

[carl]

Errors like this are a constant source of mystery that I still can't seem to reproduce locally. Are you using Paragon to access the EXT2 drive from macOS?

[Carsten]

We often see that with Paragon. Just don't use Paragon - it is very finicky with realtime access to multiple files.
An NTFS drive is perfectly fine. Although if the DCP ingests without error at the cinema from the ext2 drive, it will be okay.

[dhl]

Errors like this are a constant source of mystery that I still can't seem to reproduce locally. Are you using Paragon to access the EXT2 drive from macOS?

We often see that with Paragon. Just don't use Paragon - it is very finicky with realtime access to multiple files.
An NTFS drive is perfectly fine. Although if the DCP ingests without error at the cinema from the ext2 drive, it will be okay.

Yes, I'm using Paragon EXTfs for mac to format and access the drive. I did another test where I copied a working DCP to the EXT2 drive, then copied it back to the macOS desktop. Once copied back, I got the same error on the desktop, even though all the files appear to be identical. It's really weird!

I'm using a Hackintosh so I can boot into Windows and format the drive as NTFS there, but I can also upgrade Paragon and have NTFS on macOS.

Are you seeing the same error with NTFS drives formatted with Paragon on Mac?

[Carsten]

I use Tuxera NTFS and prefer it over everything Paragon.

If you just want to be sure, you could copy the DCP to an exFAT formatted drive (can be read and written by both Mac and windows), then copy it to NTFS while running windows.

Note, DCI servers will not read exFAT (with one exception), but NTFS is fine.

I never had a single issue with Tuxera.

[dhl]

I went ahead and took advantage of the Paragon discount and licensed NTFS for Mac. I reformatted the drive and now everything is working properly again so I think I'm good.

I assume it's okay to have two DCP folders on a single volume for ingest to the server, correct?

Thanks!
--David

[dhl]

One more thing:

Resizing the DoM Player window with OpenGL doesn't work properly:

resize-bug.png

Seems like a bug.

[Carsten]

Yes, multiple folders is okay. Every folder must only contain all files for a single DCP.


Yeah, the OpenGL output is a bit of a moving target. On many systems, safe mode works, but unfortunately, on high res macs, safe mode is unreasonably slow due to so far unknown reasons.