Terminating a child process from python

I’ve been working on improving my renderfarm, and I’ve run into some trouble trying to close clients remotely. You can easily end a python process with sys.exit(), however if a rendering application (say Nuke) has been spawned by the script, it will not close. After some digging (and a bunch of great help from stackOverflow) I seem to have come up with a solution. When you call a 3rd party application with either call() or:

process = Popen(allRenderArg, env=os.environ)

Python will create a tiny, dummy process which only exists to call that application. When you exit your script, python will clean up those dummy processes, but won’t kill child processes, thereby leaving the renders going.

The solution that I’ve come up with is to get the pid of those dummy python processes, then use some unix commands to find the pids of their children, and kill them with os.kill(). If this was a linux platform I could do it in a more efficient way (possibly using pstree) but on OSX I have to use grep and some fancy code:

processId = process.pid
print "attempting to terminate "+str(processId)
command = " ps -o pid,ppid -ax | grep "+str(processId)+" | cut -f 1 -d \" \" | tail -1"
ps_command = Popen(command, shell=True, stdout=PIPE)
ps_output = ps_command.stdout.read()
retcode = ps_command.wait()
assert retcode == 0, "ps command returned %d" % retcode
print "child process pid: "+ str(ps_output)
os.kill(int(ps_output), signal.SIGTERM)
os.kill(int(processId), signal.SIGTERM)

There might be a nicer way, but I don’t know it.

OSX Paths, X11 and paths.d

If you’re working with a renderer from the command line, you’ll often need the location of that renderer in the path, so you can call it easily (without always needing the full path). On OSX, there is a folder paths.d under /etc, where you can place text files that will contain paths to be appended to $PATH in terminal sessions:

/etc/paths.d/Nuke6.3v8 contents:

/Applications/Nuke6.3v8/Nuke6.3v8.app/Contents/MacOS

This morning I was attempting to add some other versions to the path (7.0v1, 7.0v6) and I was running into some ridiculous errors. When I added another file:

/etc/paths.d/Nuke7.0v1 contents:

/Applications/Nuke7.0v1/Nuke7.0v1.app/Contents/MacOS
what I got in my path was instead
/Applications/Nuke7.0v1/Nuke7.0v1.app/Contents/MacOS1/bin

Why? I have no idea. I tried different file names, different text encoding types, etc and was always getting that extra text on the end. I noticed that I had one other file in my paths.d, from the installation of the osx developer tools: 50-X11. When I removed that file, everything worked! However, I want to keep that in my path (not sure what apps might be there), so I renamed it to x11 and now that extra text is gone.

I hope this helps someone else in the same situation. I don’t understand what macintosh is doing half the time, and this is that half.

Nuke command line, “argument not used”

Working with my python-based nuke render farm, I’ve been shoring up the code to deal with some unusual instances (single frames, fewer frames than clients, et al). When passing arguments to Nuke for rendering, I used this format:

Nuke7.0v6 -m 8 -x projectFile.nk -F 250-500

When I need to send multiple frames, or frame ranges, to the same instance, the documentation says you can use multiple instances of the -F argument, like so:

Nuke7.0v6 -m 8 -x projectFile.nk -F 250-500 -F 550-700

What you’ll get, though, is only the second specified frame range (in this case, 550-700) rendering, and the following output:

"-F": argument not used
"250-500": argument not used
"-F": argument not used

After discussing with Foundry support, it seems the -F switch will only work if placed before the -x switch, like so:

Nuke7.0v6 -m 8 -F 250-500 -F 550-700 -x projectFile.nk
Otherwise, Nuke assumes the last number is the legacy method of passing frame ranges to the command line renderer, and ignores your -F switch. I’ve requested that this be specifically mentioned in the documentation.

Houdini Animation Curves otl

curves

I’ve recently been working on an idea that requires me to do separate luminance values in an image into x discreet “steps”, such as 0-12. However I don’t want to do the distribution linearly (read: equally distributed), I need to account for the fact that luminance is non-linear.

Continue Reading →

Technodolly Focus, Z-Depth, and Lens Distortion

techno_dolly

Any comp lives or dies on subtle qualities of a scene – color, depth of field, lens distortion, etc etc. Solving lens distortion with nuke is pretty easy once you understand the process (and immensely easy if you prepare ahead of time!); without a good lens distortion solve you’ll never get a convincing composite. Depth of field is easier to do a guess-and-check method, but of course we’d much rather get an accurate result. We’ll discuss both, but first a quick overview of the technodolly itself.

Continue Reading →

Luminance Curves

grayscale_curve-perceptual

Often in compositing, I will need to take one set of values and convert it to a different set of values. Say I have a linear image, with luminance values in a range from 0 – 4.589:

Input: Output:
0 0
4.589 1
If I want to do some fancy operation on that image based on it’s luminance, I’ll probably want to convert that range to 0-1, so it’s easier to work with. The easiest and most straight-forward type of conversion is a linear one, of course, where we simply divide all the luminance values by the largest value, giving us a range of values between 0 and 1:

Continue Reading →

./hello -t “world”

I can’t count the number of times I’ve run into an issue in my work as a Technical Director that I’ve solved just by googling it, and landing on some random blog or forum post. The goal of this site is to add my experiences to the great reference library.