### Re: BMPCC lack of saturation at 3200K

Posted:

**Tue Jan 02, 2018 9:13 pm**Yes, my experience also, stage lights are all over the place, from 2800 to 3200 K. That is why you need to do a color temp metering check.

Cheers

Cheers

Page **2** of **2**

Posted: **Tue Jan 02, 2018 9:13 pm**

Yes, my experience also, stage lights are all over the place, from 2800 to 3200 K. That is why you need to do a color temp metering check.

Cheers

Cheers

Posted: **Thu Jan 04, 2018 1:11 am**

Jamie LeJeune wrote:So ACES needs to change the RRT instead?

There is some more info with a workaround and examples discussed here:

http://acescentral.com/t/colour-artefac ... aces/520/1

Arri rendering:

ACES rendering:

Posted: **Fri Jan 05, 2018 7:40 pm**

Robert Niessner wrote:Regarding tungsten stage light: normally tungsten bulbs for stage usage are rated 2800-3000K, while tungsten bulbs for film are rated 3200K. That is also the reason why tungsten bulbs for film have a lot less life time than bulbs for stage - higher Lumen per Watt.

I feel I owe you an apology.

Cheers

Posted: **Tue Jan 09, 2018 11:33 pm**

CaptainHook wrote:

There is some more info with a workaround and examples discussed here:

http://acescentral.com/t/colour-artefac ... aces/520/1

Thank you for the link! The LMT that can be downloaded there solves the problem quite well.

As far as I can tell, to work properly it has to be applied to the clips by the contextual menu in the media pool or in the timeline. Adding it to a node in the color page doesn't work. It appears that Resolve limits it to the application of just one transform at that level. Is there a method I'm missing that allows the application of more than one LMT at that level?

I'd bet there are external tools that can combine the transforms from multiple LMTs into a single LMT. Perhaps Light Space offers that function?

Posted: **Wed Jan 10, 2018 4:49 am**

Jamie LeJeune wrote:I'd bet there are external tools that can combine the transforms from multiple LMTs into a single LMT. Perhaps Light Space offers that function?

Depends what the LMT is doing, but with the ACES LMT for fixing chroma clipping it's just a matrix multiplication, so if you have another matrix you can just multiply them together (remember order matters) if they both assume the same gamma. Open the DCTL from the ACES link in a text editor and you can see more what i mean.

Posted: **Wed Jan 10, 2018 8:40 am**

CaptainHook wrote:Open the DCTL from the ACES link in a text editor and you can see more what i mean.

Thank you for the tip! Guess I have to learn more about DCTLs and matrices. Been meaning to do that. Know any solid resources for learning about those topics?

Posted: **Thu Jan 11, 2018 12:20 am**

Depends on how deep you want to go. As a start to get a "feel" i would suggest a practical exercise in Resolve:

Setup 3 nodes, node 1 use the ResolveFX colour space transform plugin to convert to linear from your source, then node 3 convert back to the source space from linear (just change gamma for now and leave colour). In node 2 go to the RGB mixer and uncheck preserve luminance.

The RGB mixer is a 3x3 matrix. You don't have a ton of precision here and the panels offer slightly more but it will give you an idea.

Play around with adding different amounts of each component to each channel. As a tip, make sure each channel sums to 1.0 to avoid overall tint shifts. For instance, say for the Red channel you increase red's contribution to 1.25, leave green at 0.0 and set blue to -0.25 (or RR=1.25, RG = 0.0, RB = -0.25) these 3 values sum to 1.0 so the overall gain of the red channel remains the same and doesn't introduce a tint, but the mixing of the colours has been affected.

What you're doing here is applying a 3x3 matrix in linear. So you take the input RGB and do matrix multiplication (RGB = 1x3 vector multiplied by a 3x3 matrix). So looking at the ACES dctl we have the following matrix:

Notice here each row/line sums to 1.0 also (last line probably suffers some rounding/precision error but close enough). The first row/line is the red channel (RR, RG, RB), the second the green channel (GR, GG, GB), etc.

In the DCTL it shows you the math too:

p_R, p_G, p_B is the input pixel separated into each channel (RGB). Result.xyz is the output pixel also just storing RGB (calling it xyz here).

So replacing the variable names to make it clearer and inserting the actual matrix, look at it as:

That's all the DCTL is doing. The output is a single pixel made from RGB again. It assumes its in linear as there's no gamma transform. So if you used the Resolve CST plugin to transform from the working space into linear, and back, you can apply this in a node in-between using the example setup i describe above (just use the DCTL in node 2) and should be okay.

We're already greatly off thread topic so hopefully that helps (with some google to fill the gaps or take you further).

Setup 3 nodes, node 1 use the ResolveFX colour space transform plugin to convert to linear from your source, then node 3 convert back to the source space from linear (just change gamma for now and leave colour). In node 2 go to the RGB mixer and uncheck preserve luminance.

The RGB mixer is a 3x3 matrix. You don't have a ton of precision here and the panels offer slightly more but it will give you an idea.

Play around with adding different amounts of each component to each channel. As a tip, make sure each channel sums to 1.0 to avoid overall tint shifts. For instance, say for the Red channel you increase red's contribution to 1.25, leave green at 0.0 and set blue to -0.25 (or RR=1.25, RG = 0.0, RB = -0.25) these 3 values sum to 1.0 so the overall gain of the red channel remains the same and doesn't introduce a tint, but the mixing of the colours has been affected.

What you're doing here is applying a 3x3 matrix in linear. So you take the input RGB and do matrix multiplication (RGB = 1x3 vector multiplied by a 3x3 matrix). So looking at the ACES dctl we have the following matrix:

- Code: Select all
`0.9404372683, -0.0183068787, 0.0778696104`

0.0083786969, 0.8286599939, 0.1629613092

0.0005471261, -0.0008833746, 1.0003362486

Notice here each row/line sums to 1.0 also (last line probably suffers some rounding/precision error but close enough). The first row/line is the red channel (RR, RG, RB), the second the green channel (GR, GG, GB), etc.

In the DCTL it shows you the math too:

- Code: Select all
`result.x = mat[0] * p_R + mat[1] * p_G + mat[2] * p_B;`

result.y = mat[3] * p_R + mat[4] * p_G + mat[5] * p_B;

result.z = mat[6] * p_R + mat[7] * p_G + mat[8] * p_B;

p_R, p_G, p_B is the input pixel separated into each channel (RGB). Result.xyz is the output pixel also just storing RGB (calling it xyz here).

So replacing the variable names to make it clearer and inserting the actual matrix, look at it as:

- Code: Select all
`outRed = (0.9404372683 * inRed) + (-0.0183068787 * inGreen) + (0.0778696104 * inBlue);`

outGreen = (0.0083786969 * inRed) + ( 0.8286599939 * inGreen) + (0.1629613092 * inBlue);

outBlue = (0.0005471261 * inRed) + (-0.0008833746 * inGreen) + (1.0003362486 * inBlue);

That's all the DCTL is doing. The output is a single pixel made from RGB again. It assumes its in linear as there's no gamma transform. So if you used the Resolve CST plugin to transform from the working space into linear, and back, you can apply this in a node in-between using the example setup i describe above (just use the DCTL in node 2) and should be okay.

We're already greatly off thread topic so hopefully that helps (with some google to fill the gaps or take you further).

Posted: **Thu Jan 11, 2018 3:40 am**

Thanks! And yes, back to the regularly scheduled program