DBFluxFill: An AI Inpainting Gizmo
April 27, 2026
I think generative fill is one of the few AI tools that's actually useful in everyday VFX tasks. The kind of thing that would have taken me an hour to paint out you can now knock out in a few minutes. So when I started messing around with Flux Fill in ComfyUI, the obvious question was why am I leaving Nuke to do this?
That's what I’m trying to do with DBFluxFill. It’s a Nuke gizmo that lets you use FLUX.1 Fill Dev AI inpainting directly into your node graph. No ComfyUI, no external applications, no switching contexts. Just a node.
I built it specifically for freelance and indie compositors. The kind of people who want to use inpainting in their pipeline but may have never touched ComfyUI, don't know Python, and don't really have any interest in learning a new tool just to remove a rig from a shot. It can scale to studio use too, though I'd assume most studios already have their own systems for this.
Hook up an image, hook up a mask, and hit Generate. The result drops back into the node graph as a PNG, with the seed, steps, guidance, and prompt all stored in a user tab. So your outputs are reproducible, and you know exactly what generated what.
One of the big design decisions was making sure the user never had to touch a terminal to get this running. The installer handles the full Python environment setup and offers to download the models for you. Three model variants are available during install: bf16, fp8, and gguf, so the user can pick the one that fits their VRAM rather than being locked into the huge bf16 model.
The installer was built using Tkinter which made perfect sense considering the tool was so Python heavy to begin with. The installer needed to be standalone and not introduce any new dependencies, and Tkinter ships with Python. It turned out to be a great decision, even if building a multi-screen installer UI in Tkinter was frustrating on more than one occasion.
The inference runs as a subprocess in an isolated Python environment. The installer downloads and sets up a standalone Python 3.11 install separately from anything else on your system, so there's nothing to configure and nothing that interferes with existing Python installs you might have.
The downside is that Nuke freezes during generation while it waits for the subprocess to finish, and has to load the model every time “Generate” is clicked. To get around that there's a “Generate Keep Loaded” mode, which spins up a persistent process that keeps the model in VRAM between runs. Subsequent generations are significantly faster since you're not reloading the model each time.
In my testing I found that “warm” or “Keep Loaded” generations were still far slower than what I was getting from ComfyUI, but I figure the convenience of never having to open and deal with ComfyUI will be a huge plus.
I'm comfortable in Python, but this project has a lot going on under the hood. The Nuke integration, the subprocess architecture, the HuggingFace Diffusers pipeline, a multi-screen installer UI. Which is a big reason why I used Claude (not Claude code unfortunately) for most of the project.
Working with Claude on something this big has its up and its downs. Usage limits on the free plan, context getting lost mid-conversation, having to re-explain things that were covered three messages ago. Claude also has a tendency to just run without asking where to go. A small typo and it might regenerate the entire script. Ask it a question and it'll sometimes barrel straight past it and start re-writing code. There were a ton of moments that felt like I was working with a child genius that had some intense ADHD.
There's also a certain laziness that started to be really frustrating. It constantly tried to satisfy the tool for my machine, my setup, my workflow. I was trying to build a public tool and it kept acting like I was the only person who'd ever use it. 'But for your use case...' 'On your hardware this is fine...' It was constantly trying to get my “problem” (whatever it thinks that may be even if it’s not the problem I’m trying to solve at hand) done no matter how many holes or residual problems it’d leave in it’s wake.
But I finished it! I'd never touched Tkinter before this project. I’d never touched Hugging Face Diffusers, I’d never touched subprocess architecture, but now I have! It's not how I expected to learn any of this, but I came out the other side with a finished tool and a lot more Python experience than I started with.
That said, it wasn't all Claude. Knowing what a compositor actually needs, knowing how the Nuke Python API works, knowing what the user experience should feel like, that all came from me. There was a lot of tweaking, a lot of catching mistakes in the code, a lot of pushing back when Claude didn’t understand how real compositors work. Building something like this solo would have otherwise meant months of work or a whole team. So now it’s built!