Reorder Node Question
by Jimmy Spangler
on
May 10, 2008 at 2:55:25 am
I am attempting to pull some Green Screen keys from some 1080p footage using Keylight. I am pulling a decent key with keylight but I want to create a holdout matte.
I am duplicating my Keylight Node and connecting the original Green Screen FG into it. I want to chew the matte down a bit so after the Keylight node I add a Reorder Node set to aaaa. Then I dilate, add a blur, connect it to the Garbage Matte input of the Original Keylight, but in the Keylight it is taking the Alpha Channel from the blue node that has junk in it.
Why isn't the Reorder Node making everything that comes after it an RGBA version of the Alpha that it is spitting out? It was my understanding that the Reorder set to" aaaa" would make all channels following it in the tree a copy of the alpha. I thought, that with it set this way, any following node would be showing the alpha channel whether you were looking at R, G, B, or A.
Am I wrong? How can I chew the matte down and blur it without using the Reorder node?
Re: Reorder Node Question by Andrew Shanks on May 11, 2008 at 4:37:28 am
Re-order does just as it says, ....you can test it in the viewer by doing a key, placing a re-order after with the following aaan (n being for none so it has no alpha), then with cursor over the viewer and click through the shortcuts r,g,b,a then back to c (to return to normal colour view), you'll see that the alpha has now been copied to every RGB channel, but deleted from the alpha channel.
As for your problem, ...I don't know why things are going weird, but the first thing to note is that keylight uses the alpha channel of whatever is plugged into its garbage matte or hold out matte nodes (if you go into keylight and twirl down the 'plumbing' section you can change that, as with any matte input, to be another channel such as R,G or B if you wish). The mattechew node also works on the alpha channel, not the rgb. What this means is that you don't actually need to put a re-order in at all.
The process from the way you've said you want to tackle this would be something like (in simple form)
file in,
perform keylight to get a good edge,
copy that keylight node and branch it off the source (you now have two identical keylights off the one file-in, I'll refer to the first edge keylight as keylight(1) and the copy as keylight(2)).
You could now tweak the screenrange control on keylight(2) to make a hicon matte (i.e. hard edge black and white),
now place a keychew node in after keylight(2),
in the viewer switch to look at the alpha channel only (press A with cursor over viewer),
erode and soften matte until your happy (this doesn't need to be exact at this point),
plug output of keychew into the holdout matte of keylight(1)
View keylight(1)'s alpha, load keychews parameters and start playing around with the chew slider, you'll see the matte change to reflect the effect (i.e. if you effectively grow the matte feeding into keylight(1)'s holdout node, it will overtake the nice edge matte you have there, ...not what you want but you can see what its doing then button it off a bit so its just filling holes.
Does that make it any clearer? Bottom line is you don't need to use re-order, I often will throw them into scripts just to aid quick viewing when running round a script (I'm not having to toggle a and c all the time, one click to check is all thats needed), but really they're not doing anything usedul other than in that case, as the nodes usually use alphas (or can be told to use an RGB channel for matte input).
Re: Reorder Node Question by Jimmy Spangler on May 11, 2008 at 6:00:37 am
Thanks for your response, Andrew.
After doing a bit of research I figured out that the Keylight uses the Alpha anyway...but it doesn't explain why a few strange things are happening.
1. The first time I tried this I duplicated the Keylight1 and made Keylight2. Instead of pumping up the Screenrange on it to make it a hicon matte, I used a reorder set to aaaa and then put a contrast lum after it to make it hicon. The Contrast Lum node did not affect the Alpha channel. Then I Eroded it, blurred it and put it into the Holdout input of Keylight1. But it took in the Alpha from Keylight2 (ie, was not affected by the contrast) Therefore there was some noise in it.
I guess I don't understand why after the reorder node was used why any of the following nodes would have the alpha in its original form. Shouldn't the redorder node copy the alpha to the RGBA channels of everything that follows it?
My tree went: Keylight2 (duplicate of Keylight1) > Reorder (set to aaaa) > ContrastLum > Dilate > Blur > Holdout Matte Keylight1
There shouldn't be a reason why the original alpha is being fed into the Holdout Matte, is there?
2. When I did just pump screenrange on Keylight2 and disregard the reorder node, the holdout matte, which seemed to be free of any artifacts, introduced noise back into the final composite. When I would toggle between the original FG image and the final Comp, there was new noise introduced. When I would toggle ignoring the holdout matte, the noise would toggle on and off with it.
I know this is hard to diagnose without seeing an example, but I can email a sample frame of the FG, BG and the script if anyone wants to take a look...it is really stumping me.
Re: Reorder Node Question by Andrew Shanks on May 11, 2008 at 9:04:43 am
Okay, I think i get your meaning now (but if I've got the wrong end of the stick I apologize in advance).
1. when you re-ordered, you bought the alpha into the rgb channels which meant you were able to manipulate the contrast, etc of the matte (as you know). The re-order only works for that instant in time, once it has done its job on the flow of pixels going through it, it has no other baring on things further down the flow (i.e. the new RGBA stays intact until another node manipulates it). You changed the look of the RGB after the reorder, but you didn't touch the alpha channel (reorder doesn't set up any sorts of links to tell other nodes later in the flow that "if you now manipulate the rgb can you copy that back to the alpha channel", it is a simple channel swapping node, thats it, ...shake likes to keep things in a nice open logical flow like that), the original alpha therefore went unchanged through to keylight(1). If you wanted it to work correctly, echoing the changes to the RGB matte you just did, you'd either go into the piping control in keylight(1) and set the matte channel for the holdout input to R channel (or G or B), or throw a second re-order (set to something like RGBR or RGBG or RGBB or RRRR, or GGGG or BBBB, ...doesn't really matter as long as the original Alpha gets replaced one of the colour channels you just manipulated) just prior to plugging that flow into keylight(1)'s holdout matte input. ....does that make sense?
2. crunching the matte using the screenrange control for keylight2 is fine but you'll need to soften and erode the matte before you bring it in as a holdout matte, ....you want the white area of the matte to not touch the edges of your edge matte (keylight(1)). The higher the screenrange, the higher the contrast, the more detail is destroyed (noise is quite likely to take solid blobby form depending on the shot and how much the mattes been crunched), ...holdout mattes should not contaminate a nice grey edge matte, their purpose is to fill in holes that the edge matte has in its interior, ....likewise a garbage matte should not contaminate the edge region either, its purpose being to get rid of uneven lighting, etc, that the edge key didn't deal with (i.e. filling in the black region of the matte without touching the grey edge border). The reason for softening is purely for blending the core, edge and garbage mattes neatly.
The edge matte is all important, so make sure you erode the core matte properly (a small erode should be enough to get rid of most noise).
Re: Reorder Node Question by Jimmy Spangler on May 11, 2008 at 6:24:51 pm
Andrew, thank you very much for the explanation. Now I see why another reorder would be needed to override the alpha.
I am new to Shake and have done all the tutorials and it is now all sort of making sense. I probably need to go through and do the tutorials again now that I understand the concepts more.
Now I fear that once I learn the program it will be too late and I nobody will be using Shake any longer.
Re: Reorder Node Question by Andrew Shanks on May 11, 2008 at 8:59:40 pm
You'll do fine, you seem to be asking the right sorts of questions (i.e. you have a problem, you try fault finding for yourself, then when things just don't make sense you pose an intelligent question here, which is good), and shake is one of those things that can seem a little daunting to start with but suddenly it just clicks and everything becomes second nature. I wouldn't worry about Shake being obsolete anytime soon, Shake is still the main compositor you'll find in places like London (a lot of facilities there have started writing their own upgrade versions after buying the code from apple), there are even still some post houses in LA (and I'm sure elsewhere) that are running the last windows version of shake (2.5) which was EOLed back in 2002. The other thing about shake is that once you know it, it doesn't take long to transfer your skills across to the likes of Nuke and Fusion (the techniques remain the same even if the nodes have different names and GUI isn't identical (they're close enough that its not a hard transition).
If you're seriously getting into shake I suggest getting the apple shake 4 quick reference guide, its a cheap small notebook style book that is a great reference book for everything shake (I have it in my bag all the time in case I have to use some node I haven't touched before, or want to search for node options on some new problem I'm faced with).
