Evaluating Script Structure

From RMIT Visual Effects
Jump to: navigation, search

Nuke is a very 'adult' application that lets you handle your material in any way that you wish. Unlike Photoshop, Nuke will not give you a warning beep or forbid you from doing anything. For this reason it is very easy to accidentally do things in the 'wrong' way. This is a short (non comprehensive) list of common 'bad practice' items. Of course, sometimes these 'rules' may be broken, but only as an exception.

File Dos and Dont's

Folders and files should be well managed: consistently and rationally named. This course has specific conventions which you are expected to follow.

Always set the format and FPS in settings before you start

The format, once set, will determine all default formats after that. This is very important as a wrongly set format can cause the format of all default nodes to be set to something other than the format that you are working in. This can be infuriating and make script maintains every difficult.

Manage folders and files

File and folder naming conventions:

  • For small projects, go here.
  • For large projects, go here.

Donʼt use absolute file paths

An absolute path is one that specifies the location of the file with respect to the computor e.g. My_Computer/school/lesson_one/asset.JPG. A relative path is one that defines the location relative to a file or a folder.

When reading and writing files, this course expects you to (as much as possible) use paths that are relative to the Nuke file. An absolute path 'breaks' when the project folder is moved to a new computor, and each filepath will then have to be manually repaired. A relative path, on the other hand, is far more durable.

There are two flavours of relative paths: those that look 'downstream' (i.e. into the same folder in which the Nuke file is located, or other folders within it) or 'upstream' (i.e. in the parent folders of the folders in which the Nuke file is located).

Upstream and downstream, defined as relative to the Nuke file.

For downstream, the following relative filepath is recommend. This writes or reads into a folder called 'sources', which is located in the same folder as the Nuke file. The image below illustrates this relationship.

[file dirname [value root.name]]/sources/Asset_Name.JPG.
The destination folder of the downstream relative path.

For upstream, the following relative filepath is recommend. This writes or reads into a folder called 'comp-out', which is located 'upstream' to the Nuke file. The image below illustrates this relationship. To go further upstream, the value end-n needs to be increased.

[join [lrange [split [file dirname [knob root.name]] "/"] 0 end-1] "/"]/comp-out/01_01_qua_v1.jpg
The destination folder of the upstream relative path.

If by chance, you are keeping the footage on a network drive far away from your Nuke script, then the relative path method won't work as there will be a 'breakage' between the Nuke file and the source/write file. Instead of manually changing each node, you can configure a NoOp node so that it is referenced by the Read and Write nodes. The snippet below explains how this is done.

Press 'Expand' and select and copy everything below this line, then paste into the Nuke node graph.

set cut_paste_input [stack 0]
version 9.0 v7
StickyNote {
 inputs 0
 name StickyNote7
 label "<pre><b><-- This Read node refferences the filepath value in the node 'Project_Path' (which is an adapted NoOp node) \n\nInstructions for use: \n\n1)  Paste 'Project_Path' into your script.                   \n\n1)  In all your Read and Write nodes, substitute \\\[value Project_Path.filepath] for everything that preceds the filename.\n\n2)  In 'file path' of 'Project_Path', navigate to your sources folder\n\nAll Read and Write nodes will now call upon 'file path' of 'Project_Path' when looking for the 'sources' folder."
 selected true
 xpos -4012
 ypos 65
push $cut_paste_input
NoOp {
 name Project_Path
 label "\nPlace in this node the file\npath of your project.   "
 note_font "Verdana Bold Bold Bold Bold Bold Bold Bold Bold Bold Bold Bold Bold Bold Bold Bold Bold Bold"
 note_font_size 9
 note_font_color 0xff
 selected true
 xpos -4111
 ypos -92
 addUserKnob {20 User}
 addUserKnob {2 filepath l "file path"}
 filepath /Volumes/Internal_02/School/RMIT_VFX/lessons/lesson_01/01_01_qua/comp/_setup/sources/
 addUserKnob {26 ""}
 addUserKnob {26 directions l Directions: -STARTLINE T "Place here the path of 'top level' folder of your \nproject. If you don't know it drop the folder \ninto the node script and copy it from there \n(it will be in the file parameter of one the \nresulting read nodes)"}
Read {
 inputs 0
 file "\[value Project_Path.filepath]file_name.jpg"
 format "1920 1080 0 0 1920 1080 1 HD_1080"
 origset true
 version 1
 name Read3
 selected true
 xpos -4112
 ypos 55

For a fuller and more comprehensive look at file paths, have a look at this excellent pdf from the excellent Benjamin Seide.

Read node movies should be formatted as image sequences

Movies rendered as QuickTime files can sometimes be difficult to perform time edits upon. It is highly recommended that movies read into Nuke should be rendered first as image sequences.

Script Housekeeping Dos and Dont's

Comb your hair and clean your shoes.

Consider masking stills in Photoshop

A Nuke roto is not always a good way to mask a still image. Consider masking in Photoshop instead: for complex shapes they are quicker to make and better. Save the result as tiff. Look at Photoshop Workflow for tips on how to do this.

Avoid side masking a merge node

Side masks are for things like color corrections, filters etc. They are not to be used to determine transparency in a Merge node. If the same shape that you were recklessly going to use as a layer mask can be added to the Merge feeds as a Matte value.

Observe the primacy of the B feed

A script can be bothersome to manage if B feed primacy is not observed. See Primacy of the B Feed.

Avoid feeding more than two inputs into a merge node

Though the Merge node will accept many inputs, it does not do so in a way that is consistent and predictable. Consider instead stacking a whole bunch of merge nodes on top of each other.

Avoid using too many points when you roto

Too many points in a roto can be difficult to edit and hell to animate. Use as few as you can. More on roto here: Rotoscoping.

Avoid recycling masks

Two or more sequential nodes masked by the same channel can sometimes cause problems. Better instead to use a KeyMix (see the KeyMix page for details).

Color Grading Dos and Dont's

Some general rules to follow in color grading

Use HSL 'color thinking' space

Color is a volume, with a single color value being a point in that volume. Describing a point within a volume requires at least three coordinates (e.g. x, y and z). Such a three point system is referred to as a color space. In digital imaging the color space most commonly used is red, green and blue (RGB). This may be referred to as our 'working' space. However, when artists are thinking about color they traditionally refer to hue, saturation and lightness (HSL) color space. This is more perceptually agreeable that RGB... artists find it far easier to make aesthetic judgments in this space.

Value Comments
Hue This can be understood as the 'name space' of the color (i.e. whether it is a blue, green, pink etc).
Saturation This refers to the intensity (or purity) of the color. Hence black, white and grey all have zero saturation value and that ghastly pink shirt that your grandmother bought you for Christmas is highly saturated. Hue and saturation together make up the chroma component of the color.
Lightness The lightness values of an image is what we are left looking at if we pull the saturation of an image down to zero. To see the lightness values of an image, hover the cursor over the viewer and press the 'Y' key.

Both lightness and saturation are expressed in terms of intensity. They are bound by terminal extremes (maximum and minimum). They are also related: zero or maximum lightness (i.e. Black and white) both result in zero saturation. Hue is traditionally expressed as values arranged around a wheel (i.e. A color wheel).

When color grading, it is usual to first address lightness, followed by hue, then saturation. Sometimes an adjustment to one will result in a slight perpetual change to another. Annoying? Yes.

Respect the difference between R, G and B

As already stated, the working space of digital color grading is RGB. These channel are not identical in what they express:

Value Comments
Red This is where details live. Look at the red channel, and see how even-form it is and how well it contains all the fine features of the image.
Green Green is where the lightness values of the image lives. Look at the green channel and see how closely it matches the lightness values of the image. When making a hue adjustment, it is customary to leave the green channel alone, as any adjustment to it could effect the lightness of the image.
Blue Blue is where the large masses of the image lives. It also has the reputation of being the naughty channel, being much inclined to noisiness.

Color grade in order

Color grading may be divided into three stages, delivered in the following order:

  1. Color correction
  2. Color matching
  3. Color stylization

Splitting up compound color edits

Complex color edits are best split up into small components. For example, don't try to adjust the lightness and the hue in one operation. Splitting up such compound adjustments into smaller chunks makes them easier to edit and troubleshoot.

Consider using simple color tools before using complex ones

Fancy nodes with lots of sliders might look fun to play with but are they necessary? You will find that for a lot of color correction work simple nodes like Multiply or Saturation is enough. These require less processing, but also make the script easier to read.

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 a multiply has been set to .0003 (or some other random, completely ineffectual value). If you intend to change a value then do so. If not, then leave it at its default value (to set to default Command click on the slider or contextual menu it).

Merging and Premultiplication Dos and Dont's

The following rules apply to any merging operation.

Don't color correct premultiplied images

Color correction should not be done on images that are premultiplied. To un-premultiply you may use an Unpremult node, or use the (un)premult option within the node.

The (un)premult parameter of a color node.

Don't composite pre-multiplied images

Don't Don't composite a FG that is not pre-multiplied

Don't Double pre-multiplication

Do not apply premultiplication twice in a row to the same image. It can damage the edges of the alpha.

Color adjust only RGB

By default all color adjustments work on the alpha of an image as well as the RGB. Almost always this is not a good thing and can really screw up a comp. Set the color adjustment to RGB only.

The top color node is adjusting the RGBA of an image, the bottom is only adjusting the RGB(which is generally preferred).

Donʼt use the composite image that comes out of a keyer

Most high end keyers output a composite image (the foreground over the background). generally, this should not be used, as no color corrections can be done to the foreground. Better instead to use the keyer's alpha channel ina merging operation further down the node tree.