Screen brightness

[tba]

We have now run our 1st DCP in a 5.1 cinema and it worked quite well. The only real issue we had was with the picture brightness which is fine on our monitors and in the luminance graphs but was not as brilliant on the big screen. Is this due to the 709/XYX conversion or is there some other setting I have missed?

[Carsten]

Usually they can and should match. However, while cinemas are usually calibrated to a certain brightness, as well as color and gamma reproduction, monitors regularly are not calibrated. You need to think about calibrating your monitors, and/or compare in another cinema.
When you go to cinemas in the future, it is helpful if you inquire the major parts of the Installation, like projector type, lamp wattage, server type, screen size/aspect ratio, cinema audio processor type. If problems arise, it is easier to track down reasons for them

The color conversion in DCP-o-matic takes care that rec709 sources are converted to DCI XYZ as closely as possible. As rec709 is very different from DCI XYZ, and projection is very different from self-illuminating displays, there will always be SOME differences, however, they can be controlled to the point that the creative team of a production should feel satisfied.

- Carsten

[tba]

could this be the answer I was looking for?

viewtopic.php?f=2&t=969

''DCI uses a 'display' gamma of 2.6. As it is, if you create J2C or XYZ-TIFFs in Resolve, the export module does NOT automatically apply an inverse 2.6 gamma to the files - the XYZ or J2C will keep the 2.2/rec.709 gamma. That is because Resolve is a pro tool. It expects the proper gamma to be created by the operator in the application, as the final step of the grade, before the export. Gamma is not metadata, but is conveyed in the image data, so you can not just output a rec.709 project and add some 'gamma 2.6 metadata'. If you export a rec.709 project to a common rec.709 format, like ProRes, everything is fine - DCP-o-matic rightfully expects the file to be rec.709 and will apply the proper color and gamma transform to create DCI compliant gamma 2.6 XYZ J2C files.''

[Carsten]

Depends on how you generated the source footage. It if doesn't meet DCP-o-matics source expectations, the gamma will be wrong.

If you graded and exported in rec709 with a 'close to 2.2-2.4 gamma', DCP-o-matic should transform properly to 2.6.

How did you export your project from Resolve?

When you imported the source footage into DCP-o-matic, what did you think about the preview brightness/color?

- Carsten

[tba]

DPX

[Carsten]

DPX has a complicated set of parameters, and Carl changed DPX handling within the recent versions. If you search the forum and Mantis for DPX, you will find some of that. If you grade in rec709, it makes little sense to use DPX as an export format, or, at least it is not a necessity to maintain image quality.

https://dcpomatic.com/forum/viewtopic.p ... esolve+dpx

You may try some of your DPX sequence (choose a light critical scene) with 2.11.44 and see wether it makes a difference. The way you describe the difference, it should be visible when you load your existing and new DCP into DCP-o-matic standalone player and compare. The player screen of course is in no way calibrated, but a difference may still be visible.

I just converted a DPX I found at creative cow with both 2.10.5 and 2.11.44, and it appears identical both in DCP-o-matic preview als well as the DCP in DCP player. Also renders very similar in Photoshop. But, this may be a DPX that DCP-o-matic has no trouble with. Media Info tells me it is 10Bit RGB DPX version 1.0, but that is not enough info. Check your Resolve DPX export settings for full/limited range (black/highlight levels).

- Carsten

[tba]

Thanks. Do you think that DNXHR 4.4.4 should be a workable alternative to DPX i.e not great quality difference in the fnal DCP?

[Carsten]

Yes, ProRes or DNXHD/DNxHR should be fine. If you find the right export parameters for DPX, it should work as well, but it needs some testing. Another disadvantage of DPX and other image sequence is that you probably will not be able to play the content in realtime in preview. Not a big thing, since you know your footage from Resolve already. I would also assume that with a very fast computer and many encoding servers, conversion from DPX is slower, as uncompressed image series needs a very fast storage to load at higher fps. It may work from SSDs.

- Carsten

[tba]

oddly enough DNxHR is slower than DPX in the DCP process.. 8fps compared to about 10fps but the main advantage is that the DNxHR file is about 20% the size of the DPX files.

[Carsten]

Yes, DCP-o-matic uses the FFMPEG framework, and the codec support may be sub-optimal for proprietary or exotic codecs.

ProRes uses wavelet (similar to DCP/J2C), while DNxHR I think uses (M)JPEG, so without having performed comparisons on my own, I would consider ProRes (and Cineform) the slightly higher quality codecs. But that doesn't necessarily mean FFMPEG/DOM will decode/uncompress faster.

Are you doing 2k or 4k? What type of storage is your source media residing on? What CPU type is your DCP-o-matic main application running on, and what type of CPUs your encoding servers.

In general, I would recommend to export short snippets of your movie from resolve in different codecs and with different paramaters, encode them with DCP-o-matic, and then evaluate. Resolve (and DCP-o-matic) has a batch processor in the export/broadcast window to facilitate that.
I understand that even many commercial/Pro applications will not interpret all variations of DPX correctly, so expect them to be exported in specific versions.

- Carsten