DCP / DPX source / Gamma

Hello all,

I have to make a DCP from a DPX 16 bit sequence. The colourist told me it was rendered from DaVinci using the default Davinci YRGB with RCM at Rec.709 and Gamma 2.4. The monitoring screen was also set at 2.4.

From what I read / understand, since DPX sequences are into a RGB colour space, their gamma is always 2.2.

EasyDCP (standalone) can do 2.2->2.6 or 2.4->2.6 gamma conversion. Should I use the 2.2->2.6 matrix since I set the DPX sequence as input ?

Can you also confirm that in this DaVinci configuration, the DPX are linear and not logarithmic?

Thank you.

From what I read / understand, since DPX sequences are into a RGB colour space, their gamma is always 2.2.

If they graded with a display calibrated to 2.4 gamma then it is 2.4 gamma.

From what I read / understand, since DPX sequences are into a RGB colour space, their gamma is always 2.2.

If they graded with a display calibrated to 2.4 gamma then it is 2.4 gamma.

Thanks. So DPX is not necessary in gamma 2.2?

[Peter Chamberlain]

Correct. They can be any gamma and Log or Lin or some variation.

Start with the guidelines you have been given that they are 2.4, if they look ok on a rec709 display then they are probably linear.

From what I read / understand, since DPX sequences are into a RGB colour space, their gamma is always 2.2.

If they graded with a display calibrated to 2.4 gamma then it is 2.4 gamma.

Thanks. So DPX is not necessary in gamma 2.2?

Why would they be? In such a case DPX would be so limited. They can be about everything- it's all about correct interpretation on the import as headers are quite often wrong or not read by the app. Tell Resolve what they are and it all should be good.

Thanks all. I've been confused about all this because easyDCP informations ask DPX in gamma 2.2. By the way, they suggest a 2.4->2.6 transform for Quicktime ProRes source input only:

https://www.easydcp.com/support-faq.php?id=63

And they conclude by:

Alternative solutions to prevent from Gammashift:
– Use DPX or TIFF still image picture sequences instead of QuickTime video.

I thought it would mean that 2.2->2.6 transform can be used for any DPX sequence.

Key point here is interpretation. Because easyDCP has to convert source to another color spaces it has to know what your source is in order to apply correct math. That's why you have to tell it if it's Rec.709 2.4 or 2.2 gamma or if it's P3 etc. This can be done automatically by relying on MOV or DPX headers info, but this is far from perfect, so the best is to set it manually to be 100% sure.

Key point here is interpretation. Because easyDCP has to convert source to another color spaces it has to know what your source is in order to apply correct math. That's why you have to tell it if it's Rec.709 2.4 or 2.2 gamma or if it's P3 etc. This can be done automatically by relying on MOV or DPX headers info, but this is far from perfect, so the best is to set it manually to be 100% sure.

So there's no reliable tool to know the color space and/or a gamma of a MOV or DPX?

For example, Mediainfo reads the DPX sequence I was talking about as RGB (which would mean gamma 2.2). But it's actually Rec 709 2.4.

Don't rely on these headers as 50% of tools set them wrongly! Some things don't have headers at all- e.g. MOV has no flag for limited or full range.
Many tools also don't read these info, but has hard coded rules based e.g. on resolution or simply assume 1 rule.
If you want do things reliably set it manually. Good apps have such a settings.

Short answer for your question (as a longtime easyDCP user) if the graded materials are sent as Rec 709 2.4 gamma, then use the transform function 2.4 to X'Y'Z option. That will give you the correct transforms from Rec 709 2.4 to X'Y'Z 2.6.

Some of these easyDCP help info is outdated or just not accurate. What they seem to say is QT files tends to look washed out depending on the OS/SW used. If it's washed out, then by changing gamma transform from let's say 2.2 to 1.6 (treating the images as if they were 1.6 gamma) will yield slightly steeper tonal curve making the image less washed out. But then again they say that they cannot give the correct info about which transfer function should be used. That just sounds arbitrary.

As some of the earlier posts mentioned, if you grade using a display with 2.2. gamma then the files will be encoded with a reverse gamma of 2.2 which looks correct on a 2.2 gamma display. The same goes with 2.4 gamma. For any of the images to look correct on either of the displays all you need to do is use the correct transforms 2.4 to 2.2 or 2.2 to 2.4 for the images to look correct on the respective display. Same goes when you do the transform from 2.2/2.4 to 2.6 and then the images will look correct on a 2.6 display. These things sounds complicated only because some vendors make it sound complicated.

Din

Short answer for your question (as a longtime easyDCP user) if the graded materials are sent as Rec 709 2.4 gamma, then use the transform function 2.4 to X'Y'Z option. That will give you the correct transforms from Rec 709 2.4 to X'Y'Z 2.6.

Some of these easyDCP help info is outdated or just not accurate. What they seem to say is QT files tends to look washed out depending on the OS/SW used. If it's washed out, then by changing gamma transform from let's say 2.2 to 1.6 (treating the images as if they were 1.6 gamma) will yield slightly steeper tonal curve making the image less washed out. But then again they say that they cannot give the correct info about which transfer function should be used. That just sounds arbitrary.

As some of the earlier posts mentioned, if you grade using a display with 2.2. gamma then the files will be encoded with a reverse gamma of 2.2 which looks correct on a 2.2 gamma display. The same goes with 2.4 gamma. For any of the images to look correct on either of the displays all you need to do is use the correct transforms 2.4 to 2.2 or 2.2 to 2.4 for the images to look correct on the respective display. Same goes when you do the transform from 2.2/2.4 to 2.6 and then the images will look correct on a 2.6 display. These things sounds complicated only because some vendors make it sound complicated.

Din

So it means that when you make a DCP and receive a QuickTime ProRes as source, you have to ask your customer which gamma it was used for the colour grading, right? The problem is that most of people ignore this info, usually because they don't even know who made the grading.

My current workflow is to set manually the DaVinci RCM in Gamma 2.2 as input / timeline / output, bring the Quicktime ProRes into the timeilne, and render a DPX sequence (10 bit if ProRes 4:2:2 HQ, 16 bit if ProRes 4:4:4:4). And then i feed easyDCP (standalone software) with the default 2.2->2.6 color transform. Does it sound you like a mistake according you wrote earlier?

Thanks.

Yes. You have to know how video was created- this is of course key info

Regarding your case- if you overwrite gamma then it can be correct or wrong depending how video was made. If people don't know then I would not care much as in worse case shadows will be bit lifted or crushed. Your workflow is not 100% correct as it only gives 100% correct results for sources which have 2.2 gamma.

So it means that when you make a DCP and receive a QuickTime ProRes as source, you have to ask your customer which gamma it was used for the colour grading, right? The problem is that most of people ignore this info, usually because they don't even know who made the grading.

My current workflow is to set manually the DaVinci RCM in Gamma 2.2 as input / timeline / output, bring the Quicktime ProRes into the timeilne, and render a DPX sequence (10 bit if ProRes 4:2:2 HQ, 16 bit if ProRes 4:4:4:4). And then i feed easyDCP (standalone software) with the default 2.2->2.6 color transform. Does it sound you like a mistake according you wrote earlier?

If your intention is to represent the colour of your graded source material accurately then you need to know exactly what sort of calibration the display had when the source was graded. Both colour space and gamma. If it's Rec 709, then it could be either 2.2 or 2.4 depending on how they calibrated their monitors. If it's projection then possibly 2.6 gamma either P3 or Rec 709. Without knowing this info you're just making a guess and none of the setting will matter as it will be either a hit or a miss.

By having 2.2 as input/timeline/output, basically you're not doing any changes to the gamma of the source. So might as well have 2.4 or 2.6 as input/timeline/output as all are the same there won't be any gamma transforms. Basically you need to know the exact display gamma of the grading system for you to use the correct transform.

Unless you're actually doing a specific gamma change, you don't need to specify anything when you render out the prores HQ or 444 to DPX as the DPX will contain the original gamma of the prores files intact. What you do need is, at the stage of converting the files into jpeg 2000 sequence using the standalone easyDCP SW, to specify the correct gamma & colour space transform. After all, the prores could even be a P3 file if they actually used that colour space when grading and not do any colour space transforms when outputting.

Also note that if the original camera footage of the graded source is not greater than 10 bit, then you're not going to benefit by the 16 bit TIFF/DPX.

If your prores has proper 2.2 or 2.4 gamma and has no gamma shift like when you export from final cut pro 7, then I believe you should be able to do the conversion using the prores directly using easyDCP, bypassing some rendering time and storage space used to make the DPX.


Again, if you want complete accuracy, then you need to know the colour space and gamma.

Din

If your prores has proper 2.2 or 2.4 gamma and has no gamma shift like when you export from final cut pro 7, then I believe you should be able to do the conversion using the prores directly using easyDCP, bypassing some rendering time and storage space used to make the DPX.

Again, if you want complete accuracy, then you need to know the colour space and gamma.

Din

Exactly.
I'm not sure why you are going through Resolve at all. easyDCP should handle (specially when you can manually set what your source is) ProRes properly.

Resolve (same way as easyDCP) has to read ProRes YUV data and convert it using proper math, so if you can specify this math as manual setting then even bad headers in ProRes MOV file can't affect whole conversion (assuming actual video YUV data is correct).
It's only when you rely on MOV headers things can go very wrong. Properly created "modern" MOV file doesn't actually carry gamma info at all (it use to carry it), but metadata is carried as color space- Rec.709 etc which "includes" gamma value. Whole thing is way not flexible enough and very outdated, so that's why you can't really rely on MOV headers in this case.

Here is what Apple says (how things should work in ideal world):
"Color Parameter Atoms ('colr')
This atom is a required extension for uncompressed Y´CbCr data formats. The 'colr' extension is used to map the numerical values of pixels in the file to a common representation of color in which images can be correctly compared, combined, and displayed. The common representation is the CIE XYZ tristimulus values (defined in Publication CIE No. 15.2).

Use of a common representation also allows you to correctly map between Y´CbCr and RGB color spaces and to correctly compensate for gamma on different systems.

The 'colr' extension supersedes the previously defined 'gama' Image Description extension. Writers of QuickTime files should never write both into an Image Description, and readers of QuickTime files should ignore 'gama' if 'colr' is present.

The 'colr' extension is designed to work for multiple imaging applications such as video and print. Each application, driven by its own set of historical and economic realities, has its own set of parameters needed to map from pixel values to CIE XYZ.

The CIE XYZ representation is mapped to various stored Y´CbCr formats using a common set of transfer functions and matrixes. The transfer function coefficients and matrix values are stored as indexes into a table of canonical references. This provides support for multiple video systems while limiting the scope of possible values to a set of recognized standards.

The 'colr' atom contains four fields: a color parameter type and three indexes. The indexes are to a table of primaries, a table of transfer function coefficients, and a table of matrixes."