Nuke Comping Strategies: Advanced Labeling

Previously, in Nuke Comping Strategies: Label Things, we examined Nuke’s built-in tools for taking notes and finding them again. Here are two ways to make our labeling easier and deeper.

Introspective Labels

Labeling nodes manually gets a bit dicey when we’re labeling with data that’s easily changeable. The Blur node above is labeled with the size of the blur it’s making. That’s super-handy when we’re reading the node graph because we don’t have to open the Blur’s control panel to see how much blur it’s giving us. But if we’re doing this manually, we have to remember to update the label every time we change the blur size. Ick. Nobody’s ever going to remember to update those labels.

That’s where introspective labeling comes in. Nuke comes with the scripting language TCL built in, and we can use that to make labels that update themselves when we twiddle knobs. For example, put this in the Label knob of a Blur node: [value size]. The square brackets tell Nuke to evaluate the text inside them as a TCL expression, getting the value of the node’s size knob, and then put the result into the label in place of the TCL script. Now the node’s label will update automatically when we change the size knob.

We can apply this idea in lots of places, such as a Transform that tells us its filter mode (filter: [value filter]), or for making it clear whether a Tracker is stabilizing or matchmoving ([value transform]).

Each of these introspective labels means we don’t have to open the node’s control panel to see how it’s set up. It’s telling us in the node graph.

One thing to watch out for is that sometimes the knob names as Nuke knows them internally are not the same as the labels they have in the graphical user interface (GUI). If you’re not seeing the result you expect, hover your mouse over the knob and look at the tooltip. In the case below, Grade’s “gain” knob is actually labeled “white” internally. Use the knob name that appears in the tooltip.

We can even use TCL to reach back up the pipe to the top node in a graph and grab its name with [value [topnode].name]. Note that topnode follows the B pipe.

Topnode and careful node naming can help make the hidden inputs often found in a DasGrain setup more easily understandable. Sure, we could have labeled those dots manually, but this way we can see right away if their inputs ever get accidentally patched to something else. It happens!

One other thing to watch out for if we plan to use this technique a lot is that evaluating expressions relatively lightweight, but can potentially bog Nuke down if we have a lot of them. Switching to lazy expression evaluation will help lighten the load. In Nuke Preferences, go to Performance => Expressions, and set the Expression Re-Evaluation mode to “lazy.”

For more information about how TCL works in Nuke, pull down the Help menu to “Documentation” and follow the “TCL Scripting” link.

editLabel(), a. k. a. Building the Missing Keyboard Shortcut for Labeling

One drawback to the Label knob is that we need to open the node’s properties panel and switch to the Node tab before we can leave ourselves a note. Maybe this is why so many nodes go unlabeled. Why doesn’t Nuke come with a keyboard shortcut for easily editing node labels?!

Don’t fret! We can make our own. Here’s how.

To create this shortcut, we’ll be editing our menu.py file. Don’t know what that is? Have a look at this explanation from Foundry: What are the init.py and menu.py startup script files? Python scripting in Nuke is a rather deep rabbit hole that we won’t dive down here. If you’re not comfortable making and editing this file or writing Python generally, stop now and read through Nuke’s documentation or find someone to guide you.

Assuming that you’re starting with a brand-new, empty menu.py file. Add the following editLabel() function:

# Edit Label
def editLabel():
    """Pop up a dialog allowing the user to edit the contents of the selected node's label."""

    # selectedNodes() is much easier to work with than selectedNode()
    nodes = nuke.selectedNodes()

    if len(nodes) < 1:
        return
    elif len(nodes) > 1:
        nuke.message('Edit Label: Too many nodes selected. One at a time, please.')
        return

    node = nodes[0]
    label = node.knob('label')
    contents = label.value()
    new_contents = nuke.getInput('Edit label', contents)
    if new_contents is None:
        return
    if contents != new_contents:
        label.setValue(new_contents)

Special thanks: The editLabel() code originally came from Nuke’s Python manual somewhere around version 7. Sadly, it’s no longer in there. I’ve refined it a bit, but the foundation was provided by some kind technical writer back in the day. Many thanks to that anonymous person who has saved me untold hours.

As it says in the document string, this function pops up a dialog that you will use to edit the label of the node that you have selected. Now we need to tie this function to a keyboard shortcut (Control+L) so we can trigger it wherever we want. Add a few blank lines after the editLabel() function, and add this chunk. Feel free to put your name in place of “UserName

m = nuke.menu('Nodes')
user = 'UserName'
tm = m.addMenu(user)
tm.addCommand('Edit Label', "editLabel()", shortcut='Ctrl+L')

These lines create a new menu in Nuke’s Nodes panel that has whatever name you put in instead of UserName. You did replace UserName, didn’t you? Once menu.py is complete, restart Nuke so that it picks up the new code. Notice the new menu in the Nodes panel? Now, give editLabel() a try. Select a node and hit Ctrl+L. Type something in the text box and hit return. Nifty, right?

Hands-free Labeling

Being able to easily change a node’s label is nifty. But what if we didn’t have to do it at all? What if the label we want could automatically be inserted when we create the node? It’s possible using Nuke’s knobDefault() function. Add the following to menu.py:

nuke.knobDefault("Blur.label", "[value size]")

Restart Nuke to read in the updated menu.py. Then notice that each Blur node we drop into the node graph displays the blur size right on it.

We can use the same approach to make Trackers that show their transform mode and reference frame values. Notice that we’re telling Nuke to set a knob default for “Tracker4,” even though the node is labeled “Tracker” in the GUI. This is another one of those internal vs. GUI name situations like with the knobs above. Select the node and hit i to show the info panel and use the name that is listed under “Class.”

nuke.knobDefault("Tracker4.label", "[value transform]\nref: [value reference_frame]")

Or Multipy, Add, and Gamma nodes that show their current value. 

nuke.knobDefault("Multiply.label", "[value value]")
nuke.knobDefault("Add.label", "[value value]")
nuke.knobDefault("Gamma.label", "[value value]")

Notice what happens to the label when we split the Value knob and set different values for red, green, blue, and alpha. Neat, huh?

We’re only scratching the surface here. knobDefault() can be used for lots of other handy things. Have a look at Nuke’s documentation to get going with it.

https://learn.foundry.com/nuke/content/comp_environment/configuring_nuke/setting_default_parameter_values.html

https://learn.foundry.com/nuke/developers/131/pythondevguide/_autosummary/nuke.knobDefault.html

There we have it — three ways to make labeling easier and even more useful so we can get more done with less effort. Let me know how these work for you!

Nuke Comping Strategies: Label Things

“I’ll remember this when I come back to it later.”

This is one of the easiest lies to tell ourselves when we’re compositing. Here are a few techniques for turning that lie into the truth when you (or whoever touches this shot next, see Rule 4) come back to your script.

The reality is, even if we do continue the work hours, days, or even weeks later, we won’t remember the details of what we were doing. If we haven’t left ourselves any notes, we’ll have to spend time figuring out what all this stuff is and what it’s for all over again. That’s time wasted.

Or maybe we do still remember the details. But holding them in memory was not the best use of our brain power during that period. In Getting Things Done, David Allen describes the mental effort of keeping our to-do list in our head and how carrying that list leaves us less capacity for addressing the problems at hand. That’s brainpower wasted.

Writing things down in a place where we’ll see them again is Allen’s key tool for unlocking productivity. We can’t bring our full attention to bear on our current problem until we get that list off our mind. But we won’t be able to get that list off our mind unless we know it’s in a place where we’ll see it again when we need to. Luckily, Nuke comes with some built-in labeling tools that are perfect for writing down that information in exactly the place we’ll need it later.

Node Name

Node names are editable. There’s even a keyboard shortcut for it. Select the node, hit n,and type. It only takes a few seconds to turn Roto11 into Roto_redDress, making it so much easier to remember the next time we see it.

Nuke will even let us remove the node’s class from the name, but be careful. We get very used to having it there. It’s frustrating to have to open the properties panel to tell whether that orange node is a Blur or a Defocus.

Node Labels

Every Nuke node has a Label knob with a text box where we can type anything we want. This is the perfect place for a quick comment about the purpose this node serves in the comp, about where it came from, or any other piece of data that may be useful later. 

Labeled Dots

Dots stick the label text out the side to increase readability. Labeled Dots are really useful for labeling the output point of a section of our script, such as an assembled AOV build, or the group of nodes that create our background.

We can even make the label text really big, so it’s still readable even while we’re viewing the entire graph. (Extra points for stepping down the label sizes as you move into smaller and smaller subsections of your graph. These will get hidden and revealed automatically, maintaining readability as you zoom the Node Graph in or out.)

Sticky Notes

A big, yellow StickyNote makes an eye-catching reminder of something that’s unfinished or will need refinement before final delivery.

They’re also a great place to hold a to-do list. Place it close to the main Write node and give it three sections: “done,” “to-do,” and “questions.” When notes come up in reviews, make them new entries in “to-do.” As you address each note, move it to “done.” Having that to-do list written down frees us up to focus on one task at a time.

As we work, there will be things that we see that will need to be addressed for final, but will need to wait for later because the shot isn’t yet at that level of scrutiny. Add a to-do item so you don’t lose track of it.

Similarly, issues may pop up that need a lead’s or supervisor’s input. Add them to “questions” so whoever’s reviewing can respond.

All this note-taking seems like a lot of work at first. But the magic of keeping these running lists is that when it’s time to publish and send for review, we can copy this whole thing and paste it into the submission comments. Now anyone who views our work knows exactly what we did since the last version, has a list of the problems that we know need to be solved in later versions, and can clear up any questions we asked. This tells them way more than a cryptic “improved integration” note ever would. Clear and open communication builds trust (Rule 3) and makes your working life easier.

Pro tip: Start the text with <alignl> to get nice, left-justified lists instead of centered ones.

Backdrops

The Backdrop is the least useful node for organizing and labeling, even though it was designed for, and is commonly used for those purposes. 

Why? 

It is harder to select a Backdrop than the nodes it contains, especially as it gets bigger.

Backdrops do not expand automatically as the portion of the node graph that they contain grows. Ever tried to grab the bottom-right corner of a big Backdrop when zoomed out in the Node Graph? Such a pain. So fiddly and slow. And no setup ever got smaller as it got closer to final. Everything grows,all the time.

Finally, the default behavior adds bright, random color to your node graph, making it more difficult to see subtle color differences in your Viewer. 

Okay, so what should we do instead?

Arrange each chunk of nodes so it can be easily selected in a single swipe, without also selecting unwanted nodes. This replicates the organizing feature of the Backdrop while avoiding the selecting and resizing problems.

Then, use a Dot to label the chunk’s output. Make the text size appropriate to the size of the chunk. Large labels will still be visible when viewing the entire Node Graph, and smaller ones will become visible as we zoom into smaller sections of the graph.

Using these two techniques (as in the script in Labeled Dots, above) gives us a script that’s more flexible and easier to refactor as the shot evolves. The easier rearranging our Node Graph is, the more likely we are to do it, giving us easier to read scripts with much less time spent tracing pipe paths and figuring out what feeds where.

Wrapup

Labeling things pays dividends when we come back to our scripts and can get right to work. It pays back double when our script gets handed off to someone else before we get back to it. That person will be able to find their way around just like we did thanks to our handy labels. They’ll think we’re pretty nice to work with.

And what about that day your supe has to hop into one of your scripts? (You know they’re the ones who fix any last-minute issues in our comps once we’ve rotated onto other shows, right?) That day is going to be a stressful one for them. If they find a conveniently-labeled, organized script, they’ll be able to get right to work and fix the issue. Easy-peasy. And they’ll also remember how nice your stuff was to work with the next time they’re requesting people for their crew. Being easy to work with puts you at the top of the list.

Comp Rules

One of the challenging parts of compositing is that there are always multiple ways to do anything. How do we know which way is best? Use these Comp Rules.

Rule 1: Keep it simple.

Nothing in VFX is ever simple. But that doesn’t mean your work should be complicated.

The minimum viable product is an idea from business development. Apply this idea to compositing. When starting a new comp, only build out as much of the comp as is necessary to get the feedback you need.

As you get that feedback and respond to it, keep simplicity in mind. Organize and label things clearly so that your comp is easy to understand (because Rule 4.) Keep building the minimum viable product in the context of that new feedback. Sometimes the process will lead to complication. Don’t stress. (Rule 6).

Rule 2: Faster is better.

Compositing is an iterative process. Each time you go through the review cycle (make a change, render, review, plan the next step, repeat), your work gets better. The faster you can get through the cycle, the faster you can get to final. Consider how your choices affect both render speed and interactivity in the GUI.

Picking up someone else’s work? See what you can do to make it run faster. If all else fails, precomp the parts you aren’t actively working on. Don’t wait for anything that you’re not adjusting.

Rule 3: Build trust.

This rule has nothing at all to do with compositing practice — it’s all about people skills. Having the trust of your immediate supervisor and teammates will make your job easier and help you final faster.

How can you build that trust? Be predictable. Communicate early and often.

You’ve been assigned some work, and probably a deadline to finish it. If you don’t have the time, materials, or anything else you need to finish the work by the deadline, that’s a problem.

Don’t ignore the problem. Sing out about it. Do it as early as possible. You may be reluctant to pass along bad news or be seen as a complainer. But you might be the only person in your team that is aware of the problem right now. If you stay quiet, other people will find out about the problem eventually. But by then it’ll be too late to fix it easily. Raising an issue early means you and your team have more options.

Problems arrive for so many different reasons. Maybe you misunderstood the brief. Maybe there’s a bottleneck somewhere upstream in the pipeline. Maybe the client changed their mind about what they want. Each one of these is only a problem until it’s acknowledged and solved. So speak out, get it solved, and get back to work.

Hiding problems destroys trust. Revealing them — especially if you can offer possible solutions when you do — builds it, and makes your work life better.

Rule 4: You won’t be the last person to work on it.

Don’t assume that nobody else is going to see the mess you are currently making in your comp script. Picking up work from other compositors is a regular part of the VFX process. Chances are that you won’t be the last person to touch the comp you’re doing now, even if you do take it to final. Did you know that your comp supe will be the one who opens up your script to hit a last-minute client note that comes in after you and the rest of the compositors have rotated onto new shows? Your supe may not be in the most forgiving mindset while they wade into your mess, and might still have that in mind the next time you’re on their crew. It’s a sobering thought, no?

So make your work easy for someone else to pick up, whether it’s your supervisor, your crewmate, or even you if you have to go back to something after some time has passed. Work in single-purpose sections that have clear inputs and outputs. Label things. Leave notes about what’s done and what still needs attention. Clean up your messes. Do it because your script is a representation of you, and because you remember Rule 3.

Rule 5: Check your work.

Have you ever sat in dailies and watched a render-mangled version of your shot loop on the big screen? It’s not fun, is it? You missed an opportunity to get feedback on your work and wasted the time of everyone in the room. That happened because you didn’t check your work.

Check every render, every time. Difference your output against the plate and make sure there are only changes where there are supposed to be changes. Check your frame edges. Check your grain.

Checking your work doesn’t only apply to your comp’s output. How do you know the track you just made is good? Check it. Reversing a matchmove yields a stabilize. If the feature you just tracked jumps around in the stabilize, that track is no good. Redo it.

Picking up a new matte painting or an AOV build for your CG monster? Check the new work against the previous version to make sure that nothing changes that wasn’t supposed to change.

Build a reputation for finding and fixing errors before someone else points them out. Do it by checking your work.

Rule 6: Every rule has an exception.

No simple heuristic will always work in every situation. Production shots have a way of blooming in complexity. It’s not always easy to contain the chaos. Don’t worry. But also, don’t give up on the rules entirely. Stay focused on getting your shot to final. Keep going where the process leads.

Rule 7: Facilitate changes.

Change is inevitable. You are working to someone else’s specifications. Don’t fight it, flow with it.

Make your life easier by building structures that are easily modified. Make edits at source resolution when possible. Make sure each section of your comp has a single function and that it has clear inputs and outputs.

Responding to last-minute changes becomes much easier when you’re prepared for it. And being able to respond with, “Okay, will do.” instead of, “That will take three days.” helps your supervisor relax. (See Rule 3.)

That’s it.

What do you think of these rules? Have a bone to pick? Did I miss something? Please let me know! In the spirit of Sister Corita, “There should be new rules next week.” Stay tuned.

Back in the VFX world

Previously on this blog, I wrote about how proud I am to have walked away from my film career as a compositor. I still am proud of that decision, but now the situation has changed and I’m back in VFX, working as a senior compositor at Crafty Apes.

It’s so weird to feel grateful for the pandemic, but I do. Pre-pandemic, all the VFX jobs were locked up in the VFX studios, which were all located in major metropolitan areas like London, New York, Vancouver, and of course, Los Angeles. Doing that work necessitated living close enough to the studio to get there every day. When things locked down for the pandemic and everyone left the studio, that didn’t mean the work stopped. There’s no way it could. Do you remember when we were all stuck at home, hungry for distraction? Those distractions don’t manufacture themselves. All those new streaming distractions during that time were made possible by all of those same VFX workers. But now they were working at home instead of the studio, thanks to herculean efforts by the studios’ tech staffs and careful negotiating by production.

And once it’s possible to work on this material outside the studio, it makes no difference whether you’re doing it in the same city as the VFX studio, or clear across the country. This is where I come back into the story. Compositing is the most challenging and rewarding work I have ever done. But as I wrote earlier, it’s also quite disruptive to the work-life balance. I let it go for seven years. But now I’m back. Remote work makes the balance a bit easier to maintain. Working from home means I can be there for meals with the family even if I’m working long days. I can still drop Noah off at school and tuck him in at bedtime. And we can stay here in Winston-Salem, hundreds of miles from the nearest VFX studio.

I’m grateful for that.

Proud to be a quitter

Noah and I make a selfie on 21 August 2017. We’re standing next to a reflection of the partial eclipse on the wall.

For me, proud is an interior state. I don’t do it out loud. But I was pushed to write about the thing I’m most proud of in my work recently, and figured maybe it could help someone else. So here goes.

The thing in my work that I’m most proud of is quitting my film career. I used to work as a compositor on feature films. Look me up on IMDB and you’ll see a big list of films, some of them pretty well known. It was an extremely challenging job and I was good at it. It sounded impressive at dinner parties, requiring a careful explanation that still sometimes left folks puzzled, but impressed. But it was brutal from a life-work balance perspective. It’s hard to put down roots when you know you’ll have to move to a different city—maybe even a different continent—again in a year or two. Never knowing if you’ll be home for dinner or bedtime, never knowing when weekend plans will have to be scrapped, it’s rough on the family dynamic.

So I quit. Because life and family is more important than work. My job is a bit more modest now, but I’m home every evening for dinner, and I have time for my darkroom.

I don’t regret that decision one bit. Especially when I can duck out in the middle of the day to view an eclipse with my favorite people.

Thank you to Jessica Singerman for the photo.

Open post

Characterizing Instax Mini, part 1: the setup

Inspired by Steve Yedlin‘s work with cinema film, I’m going to try to characterize the look of Instax film. I’ll then apply the look of that photochemical process to digital photographs. This project will be ongiong as I dig through the data and build a model to simulate the film.

In order to understand how Instax represents various colors at various brightnesses, I shot an exposure wedge of an X-Rite ColorChecker target. An exposure wedge is a sequence of images shot at different exposures, ranging from very dark to very light. This is what it looked like when I finished.

The ColorChecker is useful because it provides a consistent ranage of flat color patches. Between the primary (red, green, and blue) and secondary (cyan, magenta, and yellow) patches, lie all the other more more sublte colors. I’m hoping to discover or invent a way to use those primaries and secondaries to reshape the digital colorspace. The grey patches on the bottom row will help track neutral colors. The top two rows represent common colors like skin tones, pastel colors, foliage, and blue sky. They will become useful later as I fine tune the model.

I shot the exposures with a Lomo Instant Automat. The Automat’s onboard meter assumes that the scene in front of the camera is average because, well, that’s how onboard meters work. So I made my scene as average as possible. I made a really big grey card with a piece of plywood and some 18% grey paint. This card fills the camera’s field of view and helps the meter set a consistently correct exposure. I taped my ColorChecker and a few other references in the middle of it and chcecked that the lighting was even from top to bottom. That white paper on the desktop is a big bounce card to fill in the bottom half. I ended up only one third of a stop different from top to bottom.

The camera was pointing right at my big grey card, so it handled the normal exposure with no problem, but without manual exposure controls I had to trick it do the overexposed and underexposed steps. I cut 3″ squares from Rosco half-stop, full-stop, and two-stop neutral density gels. To get underexposure, I held the gel over the lens to cut the amount of light getting to the film. For overexposure, I held them over the meter’s photocell opening to trick into thinking my office was very dark. I layered two gels to get to three and four stops. This gave me an exposure wedge that goes from 3 stop underexposed to four stops overexposed.

Now that I have the prints scanned, it’s time for some hard-core numerical analysis. I’ll start that in the next post, but we can already see some interesting artifacts as we compare the exposures.

As we might expect, we see the greatest saturation around normal exposure and it reduces as we go towards underexposure and overexposure. Yellows and oranges (a.k.a. skin-tone hues) seem to be doing pretty well in both underexposure and overexposure. This makes sense in a film tailor-made for selfies. Greens drop out after 1 stop of underexposure and shift toward orange in overexposure. The darkest colors, blues and purples, are taking a beating in underexposure. They don’t really show up at all until the normal exposure. These non-linearities that are built into Instax film would be hard to identify in normal photos, but our ColorChecker provides a useful reference for identifying them.

Steve Yedlin and display preparation

Cinematographer Steve Yedlin has been doing some super cool work on how to prepare digital images so they look like they were captured with film. Maybe you’ve heard of him, maybe you haven’t. I knew his work from Brick and Looper even though I didn’t know his name until recently. I’m very much looking forward to seeing his work on the new Star Wars movie.

Yedlin loves film, but he doesn’t believe in “the mystery of film.” He believes film has specific artifacts that can be isolated, modeled, and simulated. According to him, as long as you find all the artifacts and model them accurately, you can then recreate the “look” of film using digital cameras.

Have a look at Yedlin’s Display Prep Demo. In it, he compares cinematic images shot on film with digital footage that he prepared to look like film using the techniques he’s developed. See if you can pick which clips are film and which are digital. I sure can’t. He claims that nobody has been able to pick which is which with any sort of consistency.

VFX artist and supervisor, Todd Vaziri (@tvaziri), wrote up a great introduction (which is sadly no longer available on Storify) to Yedlin and what he’s getting at with film modeling.

Yedlin has done a bunch of writing on his web site and on Twitter (@steveyedlin) about film and color. There’s a lot of detail that that I’m glossing over here. Definitely go read it from the source. I especially recommend On Color Science for Filmmakers. Here’s a taste:

“When filmmakers with brand allegiance to celluloid deride digital acquisition as having a recognizably bad video look, they’re absolutely right in describing a survey of what they’ve seen in the past. But the reason they’re right is not the reason they often proffer, which is that film enjoys some sort of magical privilege that digital is perpetually barred from. It’s simply because many filmmakers today who use digital formats unquestioningly accept the standard methods of display preparation which are rooted in video engineering and not photographic richness. The two recognizable looks being compared (the “film look” and the “video look”) are merely the most stereotypical of pre-packaged display recipes for each camera-type, not mutually exclusive attributes enforced by the camera or film-stock brands.”

TimeBlur for concatenating motion blur

Last week I needed to concatenate the motion blur for a SplineWarp, a Transform, and two CornerPins in Nuke. The Transform and the CornerPins, of course, concatenate beautifully once you make sure they are all using the same filter and motion blur settings. But the SplineWarp doesn’t. In fact, it doesn’t even have a motion blur option. Bummer.

I worked around this problem by using a TimeBlur node. Wrapping the stack of transforms in a NoTimeBlur/TimeBlur sandwich gave me motion blur concatenation for all four nodes. It also let me turn off motion blur on the Transform and CornerPin nodes. This made me happy because motion blur on the CornerPin is slow. The default of 10 divisions was a little overkill for my application, so I turned it down to 5 and got a bit of a performance boost.

Don’t forget to add the NoTimeBlur directly upstream from the nodes you want to TimeBlur. If you don’t, you’ll be doing expensive fractional frame processing for the entire node tree u

Scroll to top