DoM may be misinterpreting colourspace of source material?

[rtX]

I'm using DoM 2.10.5 and have just made a DCP from a Prores 4444 with full range/data levels (0-1023) rather than limited TV legal colour (64-940) for a theatrical DCP. I tested the DCP and the blacks are very, very crushed. My colleague who graded the picture (and who also uses DoM) says he can see the same issue when he uses DoM to make a DCP from the same source material. I'm using Windows and he is using MACOSX. When he views the source material (using Resolve or Media Composer or Premiere, having 'told them' the source file is full range), the blacks are not crushed, but after DoM has processed, they are. He believes that DoM is misinterpreting the source material as limited and processing accordingly. When I first load the source video Prores 4444 file, DoM offers me Rec.709 colour conversion. Changing this to any other setting (including 'None') does not seem to change the colour in the DoM 'preview' image.

I tested a DCP with colour correction set to 'None' and the result seemed to be different in the colours but the blacks remained very crushed.

Is there anyway of making sure that DoM overrides its interpretation so that it processes full range?

A little extra information: My colleague rolled back to an earlier version of DoM to process a file that he already made a full range DCP from and he reported that the blacks are now crushed using the old version, too, where they had been fine previously.
Interop
24 fps 2048x858 100Mbit/s JPEG2000 bandwidth
Encrypted
Scope container scaled to Scope

[carl]

How are you playing the DCP back when you see the crushed blacks?

Is there any chance you can make me an example Prores 4444 file using the same settings you used for your film?

[Carsten]

I think we had a discussion on this a long time ago. One statement at the time was that we have to assume FFMPEG deal correctly with this. Limited vs. full range was the reason I suggested to implement the video vectorscope in order to have a tool that is able to analyze potential issues. That said - I think full range violates the rec709 standard. 0-15 and 236-255 is allowed, but crushing and whiteout has to be expected. Yes, IF Carl is able to catch the data there for 8 and 10 bit, it would probably be nice to have a switch for full range in custom presets. I understand people are trying to squeeze out the maximum possible latitude range from their footage nowadays, but violating standards always goes with that risc.

The problem is, does every fileformat capable to transport rec709 signals offer flags capable to signal full range vs. limited? Automatic detection would be nice, but as we know, automatics do fail, so there should be a manual override.

- Carsten

[rtX]

I'll see if we can cut a section of a scene that's particularly affected and make a second or few seconds of DCP and origination material to send Carl this morning. May I send a Dropbox link or similar direct?

I tested the DCP in a professional screening room where it was projected from a professional server/projector pairing. But we have also checked the source and test output on a monitor in the grade room and can see the same difference there.

An important point is that we've not noticed any similar issue on previous DCP makes of other projects using full range Prores 4444 sources (the blacks do not appear crushed on previous DCPs), although using the source material of the previous DCP runs now renders noticeably crushed blacks in the preview window on the current DoM implementation. In fact, the preview window doesn't appear to change at all whatever colour conversion standard is selected. I'm not sure if that is intended or not.

Thank you for the feedback.