Interview with Jack Binks

 

Morning Jack, let's start with a bit of history.

Good to see you Ben! So I studied engineering up in York, and during my time there started playing with AE, plus later on a bit of Shake. By the tail end of the obligatory post-graduation nonsense jobs I found myself working in an place building editorial suites, still messing around with comping. Wind forward a couple of months, job hunting for a ‘real job’ down in London; a recruitment agent unwittingly sends over a spec for a job at the Foundry, tacked onto the rest of the pile of rubbish they try and convince is ‘just the thing for you.’ Fortunately in this case it was, and I started work here late ‘05.

Back then it was 15 people putting out a selection of excellent plug-ins, helping with a range of tasks across a number of hosts, delightfully situated above KFC (particularly relevant I guess to those old school Nukers who remember the chicken nuggets incidents). Summer of 06, in the heatwave - non UK residents read: mid 30s - was both my first exposure to Nuke, and also happened to be when our air con failed (anyone else in Soho remember the power cuts?). Not sure whether it was the pervasive smell of chicken fat from the open windows, or the rather unfinished OFX host of the Nuke 4.5 line, but suffice it to say I didn’t really enjoy the experience! After a few days usage however I had to go back to Shake for an impromptu Furnace demo and was surprised to find myself really missing some of the workflow improvements, if that’s what working undo, extended to per node undo should be termed...

By mid ‘07 we’d acquired Nuke, and Feli, one of the old school Nukers, had introduced a bunch of us to its intricacies - I was loving it. Since then I’ve had the pleasure of being involved in a huge range of things related to Nuke, working with an array of talented people from the comping community. Nowadays we’re a lot bigger than back in ‘05, both in people count and girth (speaking for myself at least). We’ve moved offices, and are now over a Maccie D’s (moving up in the world?).

Strangely, I guess one of the things that’s had the biggest impact on users day to day lives was putting together the default layouts that came with 5.0. At the time I figured they were placeholders for the beta line and would be gutted and redone over the subsequent builds, but it never really seems to have happened - maybe someday soon! Then again, who needs more than Shift+F6, remove toolbar?

So what is this thing you call J_Ops?

In my day to day job I’m mainly involved in the product side of things, rather than engineering. J_Ops is a way to dust off the uni programming skills in my own time (yes, I am that sad!), as well as play with tools which are more driven by what I want, than by what clients specifically say to the Foundry they want.

In terms of what it consists of - at the minute J_Ops is 12 nodes, focussing on a fairly diverse range of tasks from colour correction through to rigid body physics.

I should just take the opportunity at this point to emphasise that J_Ops is nothing to do with the Foundry (usual disclaimer - see dev blog for extended version - I’m sure if TF’s engineers were doing it they’d do a much better job!).

Why did you decide to make J_Ops?

Initially it was because I was using Nuke for a bunch of photography work, and I was too cheap to buy lightroom/photoshop (hey, rents in london are expensive enough - don’t leave much room for such frivolity)! That, plus the ‘keeping the c++ skills’ up mentioned above.

After a bit I figured that some of the tools might be handy for others as well, so put them out to the community. Additionally, I occasionally get involved in short film projects on the side and may need specific tools for those, so knock them up.

Why the name?

Yeah, it’s not very good is it?! Entries on a postcard in the comments section!

So at The Foundry we’ve always put the first letter of the suite name, followed by an underscore, at the front of the individual plug-in name so as to easily differentiate from built in tools of a similar nature (a ‘well done in advance’ to the pedant out there that points out that this isn’t the case for Keylight or RollingShutter, but they’re single plug-ins in the bundle :) ).
When I first started building tools they were off the NDK samples, so since my name’s Jack I stuck a J_ in front, and J_Ops came from that.

What was in the first release?

First release wasn’t actually a J_Ops one, it was just J_Scopes - as the name suggests, histograms, vectorscopes and whatnot.

How much of your time has it taken?

Overall, absolutely no idea! Tend to work on them when on trains, planes, etc, much to the chagrin of the girlfriend... I guess that’s one of the benefits of London as driving anywhere is guaranteed to take longer than its public transport equivalent, at least on a week day. It also tends to get done in fits and starts around other out of work projects with less time flexibility (short films and the like).

So would you call yourself a programmer?

Not really; I did some at uni, which I largely forgot in the intervening period, which just goes to show any of you can do the same. Just get stuck into small changes in the samples and build up from there -once you’ve got something useful, stick it on Nukepedia. It’s certainly helped broaden my overall understanding of a huge range of topics, from colour management through to day to day handy stuff such as script troubleshooting and optimisation.

Any idea who uses it?

Well, its one of the most downloaded bundles on Nukepedia (second only to a wallpaper, which I’ve got to beat one of these days - maybe I ought to include one?!), so hopefully a fair number of people.
A bunch of users have contacted me to say they find them really handy, which is always great to hear (one of the main reasons why I’ve not just kept them to use for myself, so do say if you find them useful!). I’d always imagined it was going to be mainly smaller places and freelancers, ie those without internal development resources, but I was really gratified to hear from a couple of very large post houses that I’m not sure I can name, who have either made use of them directly, or developed in house equivalents.
In particular I hear of a lot of people using the dSLR raw reader, the 3 way colour corrector and the J_MergeHDR nodes.

What does J_MergeHDR do?

Well, I was hoping it was a self explanatory name.... <laughs>
BM: yeah, yeah, a little more detail please!
It takes a series of bracketed LDR exposures; environment fisheyes, chrome balls, and the like, allows you to rip out the metadata to set up the exposure of each and merge them together as set a target exposure. Optionally you can also profile the camera response, using Debevec’s matrix inversion method, to get scene referred values, as well as align your brackets.
BM: why not just use the Furnace alignment tools?
They can work in a lot of circumstances (and are certainly a lot faster), and may even produce better results so it’s worth testing those out as well. However optical flow based techniques can get thrown off by significant luminance shifts, and since LDR brackets are by their very definition of different exposures they may well fail. The method included in J_MergeHDR is a technique first (as far as I know) put forward by Greg Ward specifically for use in brackets like these.

Which ops are you most proud of?

Well, it’s difficult to be too proud as the real heavy lifting is most cases is done by some really superb third party libraries that have been kindly released by their authors under permissive licenses. So the real pride should be on the part of the people behind the Bullet physics, the Libraw and the VXL libraries. That said, I’m quite chuffed with the 3 way viewer control system, and of course the new Mullet tools in 2.0.

Mullet tools? What are they?

They’re a suite of nodes offering rigid body physics inside of Nuke’s 3D system, so you can take standard geo, make it a body in a physics world and let it bounce around according to forces and constraints you set up.

But why "Mullet"?

I was trying to think of something that suggested Bullet (the games library this is based on) and Nuke in one, but unfortunately mullet came up first, and once Rob E (The Foundry + Solid Angle) had knocked up a rough hair piece based icon it just stuck!

Did they take the longest?

Yeah, I think overall they probably did, if you include all the ops in that set. The previous release was about a year prior to 2.0 and I’d been working on it on and off since then.

Will any of J_Ops find its way into Nuke?

So obviously the tools are completely separate from the Foundry, and I’m sure there would be some shuddering on behalf of the hard core professional engineers if they saw some of the code. That said, Nuke is largely driven by client needs, and since I do help out with some of the design and direction work with Nuke I’ll always be shoving my oversized proboscis in with thoughts on how things should be done! Good example is an early J_rawReader, which was the first place to offer control over the underlying debayering process via flags sent in this case to DCRaw. Subsequent builds of Nuke also incorporated similar options into the core crwReader.

What's next?

Good question! In the not too distant future I guess there will have to be a Nuke NDK compatibility update build, but beyond that there’s a lot of different options that I’m interested by! Just need to find spare time to work on them....

 

---

 

J_Ops including J_Mullet is available for free here
Toolsets that proces the above animated gifs can be dowloaded here