Cc-Node saturation affects only pre-merge, contrast all? Why

R16 studio Fusion

I have a greenscreen object (which I decreased in size with merge) that is too contrasty and too saturated (background is BRAW)

Nodes are in this order: media with greenscreen, cc, deltakeyer, merge, mediaout.
On merge is also the background-clip.

When I desaturate the media with the cc node, it affects only the media and the key (which I rearranged), but it does not affect the whole picture, it does not affect the background-clip.

But when I decrease contrast or gain it also affects the background-clip.

I only want to decrease the contrast in the foregorund greenscreen media, not the background clip.
How?

Why does the cc also affect the whole picture/backgound clip?

It's not, actually. What it's affecting is the black pixels in the foreground. A pixel with a value of (0,0,0,0) has no saturation at all. So a saturation adjustment cannot affect it. Likewise, a Gain or Gamma adjustment, which both leave 0 alone, will also have no effect on a black pixel. Contrast and Lift, however, can both change the black point. They're raising the value of that 0, so you're no longer merging black, no alpha, you're merging some value greater than 0 with no alpha, which is the same as an Add.

In order to prevent this from happening, you need to divide your image by its alpha, perform the color correction, then post-multiply again to restore the image to its previous state. The ColorCorrector, and many other color nodes, have a convenient Pre-Divide/Post-Multiply button that does this within the tool. Or you can bracket your color corrections with an AlphaDivide and AlphaMultiply, if you've got a chain of them all in a row.

Some software refers to this as "Unpremultiply" and "Premultiply," which is really confusing terminology. But if you've encountered those words before, this is the same thing.

Some software refers to this as "Unpremultiply" and "Premultiply," which is really confusing terminology. But if you've encountered those words before, this is the same thing.

Premultiplication is what the team of people who invented the alpha channel (Alvy-Ray Smith) and premultiplication operation (Tom Porter and Tom Duff) called it, so it is the original terminology. Personally I think it makes more sense to call it this way, because it encapsulates the same thing as if you explicitly added an unpremultiplication operation before color correction and premultiplication after it. "Un"premult undoes the premultiplication and multiplication by alpha is called "pre"multiplication because it is done before the merging. Calling it post-multiplication is pretty fuzzy, because it removes any meaningful connection to why it is done in the firstplace (to do the multiplication operation before the final merge) and attaches its meaning to color operation instead as "pre-color" divide and "post-color"multiplication.

This article about the origins of alpha is very interesting, but keeps saying "premultiplied alpha" as if alpha itself was multiplied with something and changed. It isn't ofcourse, RGB (or some other) channels are multiplied with alpha value and alpha doesn't change one bit.
https://www.cs.princeton.edu/courses/archive/spring05/cos426/papers/smith95c.pdf

Thank you.

Yes, well, it took me quite a bit of effort to wrap my head around the concept because the terminology, while precise, is complex. And because when I was in school, it was hard to find someone online who was 1: speaking at a basic enough level to be understood by a beginner, 2: interesting in sharing knowledge instead of obfuscating it, and 3: actually knew what they were talking about. If at any point someone had just said "to unpremultiply means to divide RGB by the alpha channel" it would have saved me so much headache!

Pre/post/whatever is not the important thing, unless you're constructing the actual compositing algorithm. What's important, from a user's perspective, is understanding what is being multiplied, not when it's happening. And let's not even get into Adobe's use of "straight alpha." I mean, that doesn't say anything useful at all!

And let's not even get into Adobe's use of "straight alpha." I mean, that doesn't say anything useful at all!

It means only people in straightjackets understand that

Understanding the actual compositing algorithm (which is simple linear interpolation from A to B) is the most helpful thing in understanding all the alpha related issues, if everyone started from doing the A*a + B*(1-a) on paper at first, so much headache would be removed.

It hasn't been covered why it is necessary for color operations yet. There are two reasons:
a) dividing color value with alpha restores the original intensity, which is what we actually want to change;
b) dividing and multiplying again after forces all nonzero RGB values where alpha is zero, back to zero (it is basically an error correction step).

The a) reason might seem silly, but restoring original intensity prevents situations where nonlinear color operations like changing gamma apply different change to pixels which originally had the same color. This can introduce color casts and other nasty problems. If an object covers pixel only half-way, it is still the same color, but final pixel value is changed (due to transparency/occlusion). We want to recolor our original object before slamming transparency on top to get correct result, otherwise it is like painting floor without moving furniture.