There’s a lot wrong with ComfyUI. It just really doesn’t ever feel like it was made with professional VFX work in mind. A lot of this feeling comes from people making AI slop or doing amateur level work with ComfyUI, often working from mov’s or mp4’s, and not with EXRs or image sequences that eventually will have to go into other professional software. This feeling shows up everywhere, in small mannerisms in certain nodes or in workflows that just don't hold up when you're trying to use them for real production work. Plenty of tools try to fit the need, but nothing quite feels true, and everything ends up feeling a little clunky. The tools I've grown used to get close, but still seem to fall short.
ComfyUI-VideoHelperSuite has a fantastic preview system that renders sequences and images right onto the node, but a lot like other ComfyUI tools, it doesn't take VFX seriously, with no real EXR support, and widgets like "frame load" that clearly weren't built with a compositor in mind. Sumit Chatterjee's Nuke nodes for ComfyUI are closer. Marvelously Nuke inspired Read and Write nodes with proper colorspace handling, but they still aren’t built the way I actually want to work. Regardless, I also hate copying file paths back and forth by hand. Pulling a path out of Nuke and into a VHS node usually means editing it since VHS wants a folder, not a file path. And getting from ComfyUI to file explorer to actually view what you generated has no easy solution where in Nuke theres a simple python script that you can bind to a hotkey. Even concatenating save paths for a Save Image node that matches my pipeline structure is more annoying than it should be.
At first, it was incredibly simple to set up a python script from Nuke that would copy a prefilled Sumit-Nuke Read node or a VHS node to your clipboard, that you could paste into ComfyUI. Even a single right-click menu in ComfyUI that copies the file path straight into a Nuke Read node syntax was easy. But at the end of the day, a solution like that isn’t really a solution, its just a stopgap.
NukeLink connects Nuke and a local ComfyUI session so image sequences and single images can move between them directly. On the Nuke side it's a Python script with its own listener port, so ComfyUI can send nodes back through. ComfyUI receives nodes through a route added to its existing local server, so no separate app or port to manage. Sending a node over and getting one back both happen instantly.
Select Read nodes in Nuke, tab search or right-click, and hit "Send to ComfyUI," The file path, colorspace, frame range, and missing frames mode all come into ComfyUI as a new NukeLink Read node. No copying, no retyping. Anyone who remembers that old python script for sending Read nodes from Nuke to Mocha Pro will know exactly what I was going for.
A Path Builder node also drops onto the ComfyUI canvas alongside it, already filled in with your output location and shot name, pulled from your Nuke script's filename or a pipeline environment variable. When you've got a result you like in ComfyUI, right-click the NukeLink Write node, hit "Send to Nuke," and it drops into Nuke as a Read node, ready to go. Both Read and Write nodes have real-time previews built in, with playback controls in the right-click menu, similar to what ComfyUI-VHS does, but with a ton more image support and in a package friendly to Nuke artists.
But what a bitch and a half getting it all working was. I would’ve never thought having two widgets side by side in one row would’ve been so frustrating. Getting first_frame and last_frame to sit on the same row of the ComfyUI Read node, the way a real Nuke Read node has them, took about three days of trial and error. It sounds small, and it sounds stupid, but I think its simple things like this that really make it more user friendly for Nuke artists. Making those fake custom widgets actually behave like a native ComfyUI widgets was one of the biggest hurdles in this whole project.
One of the hardest problems was probably getting Send to Nuke and Open in Explorer to work reliably regardless if anything had actually been executed yet. Getting a variable properly tracked, then getting the node to climb back up the chain correctly to resolve the right file path, even in cases where nothing downstream had run. That took about two days on its own, with things breaking on and off all the time.
And then there was alpha. I must have gone through 4 Claude chats that kept premultiplying the RGB against alpha. Anyone who uses Nuke or even anyone in professional VFX knows, alpha is it’s own separate thing. It should never be considered just the “transparency” of the image. It’s a whole separate channel that can be used or not used for many other things. Claude never got it, I had to force it’s hand at the end, just taking code snippets and working in multiple chats to get it to do just what I wanted it to do.
Claude use was pretty heavy on this one, no Claude Code, no agent writing code on its own, all just off the shelf Claude chat. Every line went through me copying and pasting and reviewing. Writing Python code was familiar territory, but the JavaScript and tensor stuff was not. I'm on and off learning JavaScript right now, but it's not something I touch every day or need to in VFX. I could still read the code, and follow what was going on, and hold Claude accountable to what I actually wanted, but a fair amount of the code was over my head at times.
But the actual judgment calls, what a real Read node in ComfyUI should feel like, how a compositor expects a node to work, why alpha can't be treated like how Photoshop or AfterEffects treats it, why a stopgap wasn't going to cut it, it all came from trying to build a tool that would be genuinely useful to artists.
