Shake to Nuke, a transition guide - Part IV: Operators (nodes)

Written by Ivan Busquets on .

4. OPERATORS (nodes)

In this last part of the Shake to Nuke transition, I'll go through the different categories of nodes in Nuke, and outline some of the biggest differences you may find coming from Shake.

For a full description of the available operators/nodes available in Nuke, the user manual is the best reference available. If you come from Shake, there's a useful table of equivalences between Shake and Nuke operators in Appendix C of the user manual (p. 1101). You can always check this 'oldie but goodie' compilation by Hugh Macdonald:

http://www.nukepedia.com/written-tutorials/shake-to-nuke-node-guide/

In this guide, I won't go into the details of the correlation between Shake and Nuke nodes, but will try to go through the different groups of operators (I/O, filters, grading, etc) and for each category cover some common tasks in Shake that have a different approach in Nuke, or point out some differences that are often a source of confusion for Shake users when jumping onto Nuke.

 

4.1 - I/O


Nuke's Read and Write nodes work quite similarly to Shake's FileIn and FileOut. The main difference (and a big one indeed) is that Read and Write nodes can handle colorspace conversions themselves. This is usually confusing for many users coming from Shake, but if properly set up, you can forget about converting colorspaces back and forth 99% of the time. I strongly recommend some further reading to understand how and when conversions are taking place inside Read and Write nodes, but once you do, you can safely rely on them doing the right thing and only manually override their behaviour if something goes wrong (for example, if you're loading images that don't comply with the rules set up for the conversions)

http://www.nukepedia.com/written-tutorials/shake-to-nuke-a-transition-guide-part-ii-color-management/

Apart from this difference, some Shake users tend to miss the retiming options they have in SFileIn nodes. Nuke's Read nodes don't handle any timing operations other than setting the first and last frame of the image sequence (and a field to set an expression to handle what file is read on each frame). For time changes, including time offsets, retimes, freezing a frame, frame blending, etc... it is better to use separate Time operators.

 

4.2 - Time


Nuke is a lot more powerful than Shake when it comes to handling time changes in your script.

In Shake, your options for time manipulation were pretty much reduced to the timing controls inside each SFileIn, and the long dreaded TimeX node ;-)

In Nuke, there's time operators that can be introduced at any point in the script to offset, freeze, or retime the whole tree above the time operator.

TimeOffset

Multiple TimeOffset nodes. Nuke can request different frames of the tree upstream

 

This is indeed very powerful, and a painless way to offset parts of the tree that contain animated controls, or split off multiple branches of the same tree, each having different time offsets. However, keep in mind that this will effectively force the whole tree above to be calculated once for every frame that is requested, so if you're splitting off multiple branches, or doing something like a frame blend (where multiple frames need to be computed to produce the result), you might not want to precomp your input anyway first, specially if that portion of the tree is heavy to process.

 

4.3 - Filters


Every compositing software has its own collection of filters, and people are used to just play with them to get familiar with the results. Nuke should be no different. You'll recognize most of the filters you can find in Shake, plus a few of its own.
However, there's a couple of things worth mentioning here, since they're not necessarily obvious:

  • Size of blur and defocus filters: Shake's blur and defocus nodes (and all its derivates, IBlur, IDefocus, etc) let the user define the size of the filter in pixels. From a user point of view, that means a blur of 10 pixels applied to a perfectly straight line will make the edge of the line spread along 10 pixels. In Nuke, blur and defocus size is defined by a "size" knob that does not correlate to Shake's size in pixels. As a rule of thumb, you can expect Nuke's size parameter to be 3 times as sensitive as Shake's. So, a blur of size 10 in Nuke should yield similar results to a blur of 30 pixels in Shake. In most cases, you'll just adjust that parameter by eye, but keep this in mind if you're trying to port Shake macros into Nuke gizmos. If something in your macro is driving the size of a blur/defocus, you might get very different results in Nuke if you use the same values. It's also good to keep this in mind if you're ever asked to do a 'blur of 1 pixel', or if you have become used to a certain amount of blur you like to apply to CG renders, for example.
  • Where's IBlur and IDefocus in Nuke? Those are Shake macros that don't have an obvious equivalent in Nuke. For an IBlur equivalent, you should use an IDistort node, that lets you blur the image based on another image/channel. However, on mattes containing large gradients, this can produce some steppy results (the amount of blur not increasing progressively, but in noticeable 'steps'). When faced with this problem, you can always use a ZBlur node with the math knob set to "direct". For IDefocus, also use the ZBlur node with the math knob set to "direct", but the filter_shape set to 1.





4.4 - Channels



This is a very extense chapter in Nuke, but an important one to learn coming from Shake.

Check out this tutorial about channels and channel operators in Nuke, by Matt Leonard:

http://www.nukepedia.com/written-tutorials/understanding-nukes-unique-layer-and-channel-system-including-the-shuffle-nodes/

 

4.5 - Grading


One of the most frequently asked questions by people with a background in Shake is: do grade nodes concatenate in Nuke?
Short answer is "No, because they don't need to".

Long answer: Nuke does all grading operations using 32 bit float precision. So, there's no loss (or negligible loss in very extreme color corrections as a result of rounding), and all the data can be recovered by reversing the original grade at any point. And remember, Shake's grading nodes don't concatenate when used on float images either.

Some Shake users like using simple grading operators to split colour corrections into multiple, single-purpose nodes (add, mult, compress, expand, gamma…). While it's possible to use the same approach in Nuke, the Grade node offers a convenient way to group some of those simple operations into a single node. Speaking in Shake's terms, think of it as a group that contains an expand node (blackpoint/whitepoint), a compress node (lift/gain), a mult (multiply), an add (offset), and a gamma (gamma, huh!) in one node.

gradeNode

Breakdown of Nuke's Grade node into the equivalent grade nodes in Shake

 

For more info on Nuke's grading nodes, here's an excellent video tutorial by Frank Rueter that also outlines some color correction workflows in Nuke:

http://www.nukepedia.com/video-tutorials/16/video/

 

4.6 - Keying

 

With the additions of Keylight (in Nuke 6.0) and Ultimatte (Nuke 6.1), along with the long standing Primatte and IBK Keyer, Nuke offers a great keying toolset.

Coming from Shake, you're most likely already familiar with Keylight and Primatte, so spend some time exploring Ultimatte, but specially the IBK Keyer, a very powerful yet often underestimated keyer.

Here's some resources to learn how to use the different keyers in Nuke:


4.7 - Transforms

 

  • Do Nuke's transformation nodes concatenate? Yes, they do, just like in Shake. As long as transformation nodes are stacked together, they will concatenate so your image will only be filtered once for the final tranformation.

  • A transform node that deserves special attention in Nuke is the Reformat node. As a general rule, you would use a Reformat for anythin g that involves changing the format of the incoming image (upres/downres, hard crops, viewporting, changing the aspect ratio of the image...)

In Shake's terminology, a Reformat can do the work of a Resize, a Zoom, a Window, a Viewport or a Fit node, depending on its settings. In fact, it can do a lot more than that, and you'll end up using Reformat a lot, so I recommend getting familiar with all its options and understanding what they do (the tooltips on each one of the knobs in the Reformat properties provide very good information on what to use them for). Just to get you started, here's a quick guide on how the aforementioned Shake nodes could be replicated using different parameters in a Reformat node:


reformatOptions

 

  • Some transformation nodes in Shake have a "useReference" option that's often used to apply only the motionblur of a certain transformation, without applying the transformation itself. In Nuke, there's a different but equally effective way to motionblur an image based on the animation in a transformation node using MotionBlur2D and VectorBlur. MotionBlur2D takes both your image and a transformation node as inputs, and stores motion vectors into a layer/channel of your choice. You can then use VectorBlur to use generate a motionblurred image based on those vectors.

shakeMotionBlurRef

Adding motion blur from transformation data in Shake

 

nukeMotionBlur2D

Adding motion blur from transformation data in Nuke


4.8 - Tracking


2d-tracking and transformations based on a track (matchmove, stabilize) are all done within the Tracker node (same way you can use a Stabilize node in Shake to do both the tracking and the matchmove or stabilize).


Tracking features in Nuke using the Tracker node works just like in Shake, but it's worth pointing out that, for 4 point tracks, Nuke does not do any cornerpinning when applying the transformation in either matchmove or stabilize modes. It will use all 4 points to calculate translation, rotation and scale, but not introduce any perspective changes to your images. If you need to do that, copy all the data from the tracker into a CornerPin2D node.

To use tracking data in a Cornerpin2D node:

  • Copy the data from your 4 tracks into the to1, to2, to3 and to4 knobs of a Cornerpin2D. You can do this by either copying the values only, or making a link to the tracker values. (Check Part I of this guide for more details on copying/linking values between knobs)

copyTrackData

Ctrl + dragging between two knobs automatically creates an expression link

  • After copying/linking the data for all 4 tracks, the Cornerpin2D node will pin the corners defined in the 'From' tab, into the 4 corners you just copied into the to1, to2, to3 and to4 knobs. This is cool if you really want to map the whole input image onto those four corners of the track (like tracking the corners of a TV and pinning a whole image into that). However, in most cases you will want to be able to set a 'reference frame', or a frame at which the Cornerpin should not modify the image. You will most likely want to do this when you try to track in something that's already lined up with your tracked plate at a given frame (like a patch you've painted, or a matte painting done to a specific frame). If that's the case, you'll need to go into the 'From' tab of the Cornerpin2D node and edit all the 'from' points so they match the 'to' points at the reference frame. The easiest way to do this is using expressions. See the following screenshot for an example:

cornerPinExpressions

Setting the 'reference frame' to frame 10

 

  • If you want to be able to change your reference frame in a more flexible way, you could always create a user knob called 'referenceFrame', and then use it in the expression as follows:
from3.x
from3.y
to3.x(referenceFrame)
to3.y(referenceFrame)

 

 

Tip: If you want to use tracking data on vertices of a Bezier or a Rotopaint Spline, you can drag & drop from the knob that holds your tracking data onto a spline vertex in the Viewer.

 

4.9 - Merge

One of the most important things to know about Nuke's Merge nodes is that the B input is always the main branch/input. Read "Part III: Data Flow" of this guide for more info about this feature (http://www.nukepedia.com/written-tutorials/shake-to-nuke-a-transition-guide-part-iii-data-flow/)


Apart from that, you'll find all the Layer operations you're used to having in Shake under the Merge node in Nuke. Out of the whole list of Merge operations, here's a few that may be new to you coming from Shake, and others that don't do exactly the same even if they have the same name as their Shake counterpart. In most cases, the difference between operators of the same name will be small, and/or only happen under special circumstances, but it's good to know about them, specially if you are porting scripts/macros from Shake to Nuke and you experience slightly different results:

  • Atop: This produces slightly different results than Shake. In Shake, an Atop can be described as an Inside and then an Over between the result and the background input. In Nuke, it would be the equivalent of A inside B, plus B held out by the alpha of A (similar to the over operation, but using the original alpha from A, instead of the resulting alpha of A inside B). If you like to dig deeper into the maths, the difference in the equations would be: "A*B.alpha+(B*(1-A.alpha*B.alpha))" in Shake, and "A*B.alpha+(B*(1-A.alpha))" in Nuke.
  • Average: When in full effect, same as a mix of a 50% in Shake.
  • Disjoint over: not available in Shake, although you might have rolled your own techniques to do the same thing. Ever had to deal with two renders held out by each other? A straight over would leave a small seam where the two elements overlap, because the over operation does a holdout on the background itself, therefore leading to a double-holdout (double premult) issue. That's where disjoint over comes into play. Essentially, what it does is unpremultiply B wherever it overlaps with A before doing the over operation.
  • Divide: same as Shake's IDiv, except when the B input has values of 0 or below. Shake's IDiv has the ignoreZero parameter turned on by default, which checks only for values of 0.0 to avoid divisions by 0 (although you can turn that off). Nuke's divide operation checks whether the B input has values of 0 or lower, and in both cases returns the value of A instead of the A/B division. This shouldn't affect you when dealing with regular images, but if you're doing operations with normal or world position vectors, you might want to keep an eye on this, since it could throw unexpected results. If you need to replicate the behaviour of Shake's IDiv in Nuke, use a MergeExpression node with the following expression for each channel: "A.r/B.r" , or, if you want to mimick the ignoreZero setting: "B.r==0.0?A.r:A.r/B.r"
  • Multiply: same as Shake's IMult, except when both inputs have negative values. For each pixel that has a negative value on both inputs, Nuke's multiply won't return a straight multiplication, but copy the value from input A instead. This shouldn't affect you when dealing with regular images, but if you're doing operations with normal or world position vectors, you might want to keep an eye on this, since it could throw unexpected results. If you need a straight multiply operation like Shake's, use a MergeExpression node instead and type in a multiply function (A.r*Br, A.g*B.g...)
  • Hypot: no equivalent in Shake. As described in the Nuke's User Guide, 'hypot' resembles the plus and screen operations. The result is not as bright as plus, but brighter than screen. Unlike the screen operation, hypot does not clip pixel values to a maximum of 1.0. A good alternative to the screen merge operation.
  • In / Mask: equivalent to Shake's Inside. Only difference between the two is the order of the inputs.
  • Out / Stencil: equivalent to Shake's Outside. Only difference between the two is the order of the inputs.
  • Minus / From: equivalent to Shake's ISub. Only difference between the two is the order of the inputs.
  • Matte: same as Premult A , then A Over B. Use it to comp an unpremultiplied FG element (for example, you just copied an alpha into a non-premultiplied element, and want to skip the premult node) over a BG.
  • Screen: almost the same as Shake's Screen, except that Nuke protects the values above 1.0 to avoid the old 'Screen in float' problem. On the other hand, though, Nuke's Screen can clip values on the lower end. This is because of the very nature of the method it uses to protect the values above 1.0. So, watch out for that, specially if you are using log images and do a standard conversion to linear (where code values below 95 go into negative). A screen operation with something that's got 0 as the lowest value would effectively be clamping your negative values. For the math-curious, here's the different implementations of Shake and Nuke Screen. Shake: "(a+b-a*b)"; Nuke: "max(max(a,b), a+b-a*b)"

 


This is the end of this 4-part Shake to Nuke transition guide. Hopefully it will shed some light into the most obscure areas of Nuke, and make your transition a bit easier.

Feel free to post any comments / suggestions.

Happy comping,

Ivan

Comments   

 
# Pannneer selvam 2010-08-24 12:26
Thanks for the Great effort... keep doing such work for this community
 
 
# paddy eason 2010-08-30 09:43
Yep, thanks a lot for those. One day, one day, I will learn Nuke. Honest. Oh - but I love the rounded buttons in Shake so much! Nuke is UGLY!
 
 
# Igor Majdandzic 2010-09-17 03:56
Hey Ivan, good 4part tutorial. Should have read it when transitioning. Thanks for the effort.
 
 
# Sri kanth 2010-09-19 12:44
Great stuff.......... .......... Thank you ivan!
 
 
# Rafael Lewis 2011-11-04 00:30
Excellent, appreciate it!
 

You have no rights to post comments

We have 2346 guests and 108 members online