Blackmagic Forum

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

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:

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

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?

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.

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?

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:

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).

Thanks! And yes, back to the regularly scheduled program