If I create 2 gmasks, both 100% white over 0 black as described by the desktop dropper (working in Rec. 709) and subtract one from the other, the resultant black in the subtracted area is -1. If I invert one mask and multiply, the black is 0, as one would expect. Perhaps it has always been that way and I never noticed because I never did anything with the -1 black in which it made a difference until yesterday. Clamp, of course, fixes the issue, but why would I need to clamp it? 1-1 = 0.
No, you did it exactly as described. The only difference is that I started with a piece of footage (from the job that I encountered the issue on) and you started with a colour node. And I used gmask tracer. As soon as I have a moment I will look farther.
It’s always been that way. Use the blue inputs to combine two mattes—it’s got all the options you want and won’t create negative values.
1 Like
Gmask tracer doesn’t seem to change anything in my little setup. So the negative values must be coming from your footage is my guess.
Actually, I think if you move the dropper around a bit you may find sporadic instances of -1
Ah… You are correct. I was sampling the intersection of the masks. The -1.0 shows up when sampling the area outside of the intersection where the shape that is being subtracted would be.
Yes, and setting it to 2 Minus 1 (outside) as well does the trick. I guess I never had to use such a matte in a way where it made a difference until yesterday. (as a holdback matte for a colour node.)
1 Like
Yeah… I know we are supposed to use the matte inputs of the comp node to combine mattes because the math is geared for it but it’s kind of a PITA and disruptive to the flow when you have to view the matte out of the node vs. just the result like normal. Thankfully, there are methods for supporting my bad habits and doing it the right way. 
I guess now that I think about it, it would be nice if the comp node could correctly interpret our intentions based on the input. If it sees matte sources being piped into only the front and back inputs, assume we are being lazy about combining mattes and do the right thing (don’t generate negative values).
I get it now. It is subtracting 1 (from the white of one matte) from 0 (where the other matte was black) but 1 from 1 where there was white on white. Interestingly enough, it doesn’t do that in 8 bit.
1 Like
Yeah, it won’t do it in 8 bit cos 8-bit is an integer color space. The only possible values are 0-255.
Theoretically this would apply to 10 and 12 bit color as well, but (at least in batch) flame promotes all non-8-bit color to 16-bit float, which has a value range of -65,636 to +65,536.
So when you subtract in 8 bit flame gives up at zero, but in floating point it can do the math correctly and give you negative results.
I agree it’s all a bit confusing.
I love those blue comp inputs though. So useful!
A couple of nerdy points:
-
The comp node’s matte inputs have blend modes not available to the front inputs, and they are all super useful. Zero chaff. One inverts and multiplies one matte over the other, one does the opposite of that. It’s great, and you should use it because:
-
“Subtract” was never a good way to combine mattes. Like “Add” it’s raw-math-ness make it too agressive in the semi-transparent areas. The nicer way is to invert and multiply the matte over. See point 1 for a method of doing that in a single node.
5 Likes