P3-D65... Is it a D60sim?

resolve
Tags: #<Tag:0x00007f3c61446e58>

(Charles Boileau) #1

Hi to all,

I’m researching if we should look into using P3-D65 to calibrate our projectors. I feel like it would be better for the clients to see the same WP in all our mastering rooms.

Please keep in mind I’m using Davinci Resolve 14.3.

If I look inside the current ODTs I see the following:

ODT.ARRI.P3D65_48nits_dark.ctl: Is expecting P3-DCI and shifting it to P3-D65… The “dark” thing is. I assume, for the viewing environment.
ODT.Codex.P3DCI_48nits_D65sim.ctl: Seems to do the same.

In Resolve, we have a P3-D65 ODT. I don’t see this ODT anywhere in the provided transforms in ACES 1.0.3.

  • Is this one of the aforementioned transforms?
  • Is the Resolve ODT expecting a P3-D65 calibrated projector?
  • Is the Resolve ODT “shifting” the WP to D60?

Again thanks to everyone here for the help.

Cheers!


(Scott Dyer) #2

Let me try to address each invidiually…

Where did you get this transform? This isn’t part of 1.0.1, so without seeing the code, I can’t tell you definitively what it’s doing. Is there any information in the header comments about what it does?
If it follows our naming convention, then this would be for a P3D65 calibrated projector and would include a chromatic adaptation from D60 to D65. Thus neutral (equal) ACES values would measure off the screen at chromaticities x=0.3127, y=0.3290 (D65). Because the projector is calibrated to D65, this would have equal projector code values also.

Again, impossible to confirm without seeing the code, but if it follows our naming convention, then this would be for a P3DCI calibrated projector and would include a chromatic adaptation from D60 to D65.
Neutral (equal) ACES values would measure off the screen as chromaticities x=0.3127, y=0.3290 (D65), and unequal projector code values would be needed to make this happen. In this case, equal projector code values would yield chromaticities x=0.314 y=0.351 (DCI) - the calibration white point.

Correct, we do not have a P3D65 ODT as part of 1.0.3. Don’t ask me why not.

It’s probably equivalent to the ODT.ARRI.P3D65_48nits_dark.ctl that you mentioned, but again, I cannot confirm this because I don’t know what Resolve implemented nor what is in the CTL transform you have.

I would assume so, yes. You could test this by using it on a P3D65 calibrated projector and measuring off the screen to see if a neutral ACES value such as [1 1 1] comes out at D65.

Likely not. It more likely shifting the WP from D60 to D65.
Now, if it had said “D60sim” in the name, then it would still not be shifting from D65 to D60, because ACES is already at D60 be default. However, what would happen in this case is that neutral ACES values would measure off the screen at chromaticities x=0.3217 y=0.3377 (ACES white). Because the projector is calibrated to D65, it would require unequal output code values for this.


(Scott Dyer) #3

Also, note that 1.1 will add official support for P3D65 calibrated projectors: https://github.com/scottdyer/aces-dev/tree/v1.1-dev/transforms/ctl/odt/p3


(Nick Shaw) #4

I think both the ODTs he is looking at are from Joseph Goldstone’s fork of aces-dev:


(Scott Dyer) #5

Ah, yes. I thought they sounded familiar…

@CharlesBoileau
ODT.ARRI.P3D65_48nits_dark.ctl says it’s for a device calibrated to D65 and has an observer adapted white point of D65.
ODT.Codex.P3DCI_48nits_D65sim.ctl says it’s for a device calibrated to DCI white and also has an observer adapted white point of D65.

So what I said above holds true - equal ACES code values (e.g. 0.18, 0.18, 0.18) should measure as D65 - assuming they are used with the assumed projector calibration white points (i.e. D65 and DCI, respectively).


(Matthias Tomasi) #6

Charles,

I agree that there is equity in having a consistent white point. But how are you then creating the DCI-P3 deliverable with the theater white point? Do you switch ODT and projector calibration back to P3-Theater for review and export? Or do you “trust” the system enough to just render out using the P3 ODT without actually seeing the output (in effect using it like a data LUT)?


(Nick Shaw) #7

Bear in mind that DCI does not mandate a white point for DCPs. I believe anything between D55 and D65 is permitted.

So there is no requirement to adapt the white point when making a DCP. It is a creative choice.


(Matthias Tomasi) #8

That’s a very good point! But (and please correct me if I’m wrong) when the white point of the projector in commercial cinema (i.e. our mastering target) is fixed at x=.314, y=.351, and the WP of the projector in the mastering suite is at D65, the resulting difference will have to be addressed at one point. I would imagine this to include a slight reduction in white luminance in order to fit one color volume into the other, slightly different, one.


(Charles Boileau) #9

Keep in mind that DCPs also have a different WP in XYZ (x0.3333 y0.3333) so you’re always going towards this “in the end”. The important point would be to clearly identify the master as P3-D65 so it can be converted to whatever colorspace you’d need. So in that sens when creating the DCP I wuld just flag it as P3-D65 and the DCP software would do the work necessary to display it properly. The XYZ WP is actually quite close to D65 (more so that DCI).


(Charles Boileau) #10

Thanks Scott… I must of looked at the wrong fork. But I was sure it was the 1.0.3. That being said that doesn’t make much difference at this point as we don’t know how BMD implemented it. I’ll just have to try it on a full white image and see if the WP changes visually. Thanks!