PDA

View Full Version : New Nuke wiki


MartinConstable
12-19-2011, 12:34 PM
Dear all... I have just finished making a Wiki on the use of Nuke software: http://opticalenquiry.com/nuke/. It is still a bit rough round the edges so any comments or suggestions are welcome. It's primary purpose is as a teaching aid for my compositing class. It's ideal audience is someone who is just beginning to use Nuke and is not intended to be for 'high end' users. However, I have tried to make it as comprehensive as possible so I will welcome any obvios gaps being pointed out. Thanks in advance for your help.

beaker
12-27-2011, 07:59 PM
Under best practices part I have a few questions.

Donʼt use the reformat node unless you have to
I don't understand this one, why is reformat bad?

Consider masking stills in Photoshop
why would you want to mask in photoshop? Wouldn't it be faster if you want to re-adjust the mask that you just do it all in Nuke?

Donʼt leave 'fiddle' values in the parameters
When reading someone else's script it can be very annoying to open something like a ColorCorrect to discover that some of the parameters have been set to .0003 (or some other random, completely ineffectual value)
the difference between .0003 and .0002 in a black or white point can make a huge difference. Telling a student to reset back to defaults could completely mess up the color in a comp.

Avoid feeding more than two inputs into a merge node
Though the Merge node will accept many streams it does not do so in a way that is consistent and predictable. Consider instead stacking a whole bunch of merge nodes within the script.If your doing the same exact merge operation like an "over" then this works just fine. I would just bring up that the merge node can only do the same operation to all the inputs. Not necessarily say to never use it.


Donʼt use the composite image that comes out of a keyer
It is the alpha from the keyer that should be used. If you use the flattened comp then you are unable to color correct the foreground so that it matches the background.This used to be true under shake because they keyers only worked at 8 or 10 bit. These days though the output of the keyer is perfectly usable if needed. Some people use a combo of methods where you use the matte and the de-spill from the keyer but do the merge after the fact. I don't know if I would go as far as to say that you should only use the alpha out of a keyer.

MartinConstable
12-28-2011, 03:36 AM
Under best practices part I have a few questions.

Thank you for your feedback, these are all excellent questions. I am in awe of your reputation and confess that I have never worked as a professional compositor, and only taught Nuke for three years. First off, I have edited a lot of these points since first writing them, and also moved them to another page. They are now at:

http://opticalenquiry.com/nuke/index.php?title=Evaluating_Script_Structure
which is part of:
http://opticalenquiry.com/nuke/index.php?title=Script_Evaluation

In every case below I have re-written the points that you have referred to in order to make my position more clear. I guess that having to edit 20 or so scripts every week, each time seeing the same problems arise, has made me a touch dictatorial in my advice. I have tried in my re-write to be less black and white and more equivocal.

I don't understand this one, why is reformat bad?

There is nothing inherently wrong with using the reformat after a Read, however, For a lot of my students the Reformat node becomes an almost compulsory part of their script. They often dont even place a Transform before it, thereby ignoring any placement requirements that the reformatting requires. I have found that asking them to reformat in Photoshop forces these aesthetic decisions on them. I have changed it to:

Dont over-use the reformat node
If you wish to re-format a still image why not just do so in Photoshop? It requires less processing from Nuke and looks tidier. It also, in my experience, encourages a more careful evaluation of how the image might relate to the rectangle of the new format.

why would you want to mask in photoshop? Wouldn't it be faster if you want to re-adjust the mask that you just do it all in Nuke?

True, it is better workflow to keep the masks within Nuke where they can be edited on the fly. However, I have seen too many students try to use Roto to mask things like hair and objects that have many negative shapes. Changed to:

Consider masking stills in Photoshop
A Nuke roto is not always a good way to mask a still image. Consider using Photoshop masks instead: they are quicker to make and usually better at complex forms (far more able to cope with things like the soft edges of hair and far more capable of handling knock-out shapes and negative shapes). Save Photoshop result as tiff. Look at Photoshop Workflow for tips on how to do this.

the difference between .0003 and .0002 in a black or white point can make a huge difference. Telling a student to reset back to defaults could completely mess up the color in a comp.

I wrote this item badly. My point was that it can be tiresome to open up a ColorCorrect to find that every single value has been changed but only one of them has any significant effect on the image. My students panic when they see many sliders in a node, yet they also seem addicted to using things like ColorCorrect when a simple Multiply will do. Changed to:

Donʼt leave 'fiddle' values in the parameters
When reading someone else's script it can be very confusing to open something like a [[ColorCorrect]] and discover that some of the parameters have been set to random, completely ineffectual values (e.g. a saturation value of .00004). It is inevitable to want to fiddle with a set of paramaters whilst trying to get the best result, but if a parameter change has no effect then it should be returned to its default (to set to default Command click on the slider or contextual menu it). Try to get to know exactly what each parameter does and what its place within the adjustment is.

If your doing the same exact merge operation like an "over" then this works just fine. I would just bring up that the merge node can only do the same operation to all the inputs. Not necessarily say to never use it.

Good point. In fact I have just finished a script with a merge node accepting fifty feeds. However, as a norm it can present problems, especially when it comes to troublshooting (which I emphaisise in my teaching). Changed to:

Avoid feeding more than two inputs into a merge node
Though the Merge node will accept many streams it does not always do so in a way that is consistent and predictable. Also, a script that has all its merge operations stacked inside of one node is very hard to troubleshoot as its layers can not easily be turned off one by one. It can also be hell to re-order the layers such an arrangement. Consider instead stacking the merge operations one after the other.

To the point about not using the composite image as it comes out of the keyer:
This used to be true under shake because they keyers only worked at 8 or 10 bit. These days though the output of the keyer is perfectly usable if needed. Some people use a combo of methods where you use the matte and the de-spill from the keyer but do the merge after the fact. I don't know if I would go as far as to say that you should only use the alpha out of a keyer.

Again you are right. However, again I have to manage my student's bad practice. They can be lazy when it comes to integrating FG with MG... assuming that a keyer is a magic fix for everything (and also assuming that a pull can be done in one slick operation instead of a soft pull / hard pull combine). I tell them that it is a rare comp that will require no color adjustment to the foreground and that this should not be done before a keying operation. However, your point about the mixed workflow is a very good one. In general, I have found that HueCorrect to be a better de-spiller than the built in ones of any keyer. It also has the advantage of being easy to turn on and off (again troubleshooting). But there is no substitute for the 'replace with' option in the despill. Changed to:

Donʼt use a keyer node as a substitute for a merge node
The keyer's main job is to deliver an alpha, not to do the layering itself. The foreground of a comp done in a keyer is very difficult to color edit without also affecting the green screen values. The merging on the foreground with the background, and the associated color editing involved, is best handled as a completely separate operation to the key pull.

CGTalk Moderation
12-28-2011, 03:36 AM
This thread has been automatically closed as it remained inactive for 12 months. If you wish to continue the discussion, please create a new thread in the appropriate forum.