Hi guys, getting some shitty edges as soon as I comp some well-shot green screen over a purple background, and I suspect Iāve stuffed up my colour settings.
Forgive me, Iām a total colour n00b.
So Iāve started a project in 2026.2.2, and selected Aces 2.0 as my default project setting. First mistake, but I really need to learn this stuff so why the hell not.
My footage is 6k Sony Venice, and inside Action it inherits the SLog 3 Venice-S-Gamut3.cine LUT.
My viewer is ACES SDR 100 nits by default. Iāve got a purple gradient in the BG managed to the Venice LUT so they match. Trouble is - Iām getting a horrid pink edge around my key. Why is that and how do I fix it?
Actually Ryland - your question made me think that was the problem, and so I set the CM inside the menu to āfrom sourceā and then did the conversion inside a CM node instead, and itās fixed! Thankyou! Why did it do that though?
Not super familiar with the gradient node. I just played around with it for a few minutes to try and make a purple gradient and I pretty quickly got myself into a place where the values were exceeding one. Log values over one generally donāt play nice. Probably something to do with that, but since I rarely comp in Log, use the color picker for creating colors, or use gradient, Iām not really sure.
I never really stopped to think about it before, but I guess color source and gradient donāt really have a colorspace? Theyāre just raw values so the Tagging menu is just about how theyre being displayed to you through the viewer. If you set RGB to .5 and cycle through the tags it will adjust the display values but the working values donāt change. My guess then is that you had values either over one or below zero and applying an input transform from aces to sLog brought those values back into a range where they would play nicely with your source image.
Thanks for that, I figured it was a illegal colour thing and did initially try clamping but none of that made any difference at all. I donāt really know enough about colour but at least I know enough to get by now, thanks again!
A little gotcha with the gradient node in linear space (not sure if you are doing it in linear or rec) high luma levels print through into the gradient if attached to the clip.
my hunch is it was because you were tagging images instead of converting them.
Scene-linear, log, and video images all looking correct via tagging, but retain their wildly different pixel values (10.0 white in linear, 0.68 white in log, 1.0 white in rec*, for example) so when you try to combine them and then view the result through a viewing lut, things will go wonky.
It seems like you worked it out with a CM node set to input transform, which is indeed The Way (insert baby yoda gif).
Generally I try to get everything into ACEScg and go from there. In some cases Iāll work with the cameraās version of scene linear. Somewhere back in like 2020 there was a thread about moving between ACEScct and ACEScg for various tools but I canāt find it so here is the one-sentence version:
Do all compositing work in scene linear and all color work in log.
You could make a case for keying in log, although Iād still do the actual comp part (after generating a fill and matte) in linear.
I think I copied this from a thread from you andy_dill at some point. I remember you did a video that was helpful a few years back. I often find myself referring to itā¦
Operations That Work Best with Scene-linear Colors
The following operations work best with scene-linear colors (that is, with code values that are directly proportional to light energy in the scene):
compositing and blending
optical effects, including lens blur and defocus operations
motion blur
anti-aliasing
resizing
sub-pixel repositioning
3D rendering
lighting and re-lighting
Operations That Require Video Colors
The following operations require video colors (that is, color values that are restricted to the range [O,
1]):
color inversion
converting RGB to HLS, HSV, or YCbCr
Operations That Work Best with Video or Log Colors
The following operations work best with video or log colors:
Those two should (broadly) be in the log area, not linear. The reason is that certain resize kernels will apply sharpening that can go negative when the difference between adjacent pixels is too extreme. It usually manfests as oddly colored pixels next to bright lights, or overly crunchy edges.
Youāre right, doing a resize in scene-linear space is prone to artifacts from kernels that have negative coefficients. I will submit a change to fix that (though Iām not sure if theyāve already pulled the content for the next release yet).
Any day something we wrote could be mistaken for something @andy_dill wrote is a good day.
