DetailerX Preview

DetailerX runs a chain: upscale, then class-aware detailers for faces, hands, and whatever else you switch on, then a finishing stack of deterministic processors - levels, sharpen, grain, LUT, camera simulation, DLSS5. Switch six of those on and hate the result, and the useful question is which one. DetailerX Preview answers it by keeping a snapshot of the image after every enabled stage and letting you flip between them.

What it is

A viewer, with one input and no outputs. Connect processor_images from DetailerX and you get arrow controls that step through the stages in execution order, plus a batch stepper for multi-image runs and a compare mode. It's the visual bisect tool for a chain that's too long to reason about on paper.

If you've ever toggled processors on and off, re-queued, and squinted at two images in separate windows - this is that loop, collapsed into one queue and one panel.

How it works

processor_images is a DETAILERX_PROCESSOR_IMAGES bundle, not an IMAGE. DetailerX builds it as it runs: a clone of the untouched original plus one cumulative image batch per enabled processor, each tagged with its stage id, display label and state. Cumulative is the key word - stage 7's snapshot is everything stages 1 through 7 did, not stage 7 in isolation. That's what makes the compare mode meaningful.

The node validates the bundle (batch size must stay constant through the chain, and every stage has to be a real RGB or RGBA tensor), then writes the batches out as temporary PNGs under ComfyUI/temp/workflowx_detailer_preview/, in a folder keyed to the node's id, deleted on each run so you never see last queue's leftovers. Along the way it pairs each stage with the previous one's files, which is how Compare: Previous processor works - the pairing is baked into the payload it hands the frontend, not derived at render time.

That payload travels on ComfyUI's ui channel, which is why the node can show images while having no image sockets: none of this data is meant to pass downstream.

The one input, and how to read the panel

processor_images is it. Everything else is node-face UI.

Compare has three settings - Off, Original, and Previous processor - with wipe and side-by-side layouts. Original is the one to start with: it tells you how far the whole chain has drifted from what went in. Previous processor is for hunting the step where things went wrong, and it's usually a two-second answer. When you're chasing a subtle thing like a colour shift or a creeping skin-smoothing, flipping between consecutive stages beats any before/after.

Fit and 100% are on the node; the enlarged overlay and fullscreen inspector add zoom in/out, keyboard navigation and Ctrl+wheel zoom, and in fullscreen the wipe split follows your mouse instead of sitting on a slider - which sounds like a gimmick and isn't, because dragging one handle across a face is the fastest way to spot a bad seam.

Only enabled processors appear, and hidden ones are omitted rather than greyed out. The stage order you see is actual execution order, which is not the same as the order of the rows you dragged around if you've toggled visibility since - hidden processors keep their position in the underlying order and reappear where they were.

Install

ComfyUI Manager → WorkflowX-Configurator, or:

cd ComfyUI/custom_nodes
git clone https://github.com/haroonaslam/WorkflowX-Configurator

Restart and hard-refresh. The preview itself has no heavy dependencies, but DetailerX does - ultralytics, segment-anything, opencv-python, spandrel, hydra-core, iopath - and its SAM, detector and upscaler assets come from the pack's WorkflowX Downloader node.

Common issues

DetailerX Preview requires the processor_images output from DetailerX is the standard mistake: plugging in an IMAGE, or the detailer_masks output, both of which look like plausible preview inputs and neither of which converts. Same class of error for a bundle written by an older DetailerX version - the bundle version is checked, and a mismatch is rejected instead of half-rendered.

A panel with nothing in it means every processor was disabled, or the run was bypassed; the bundle carries a bypass reason string for exactly that case. And the temp folder is wiped before each run, so stage images never accumulate or bleed between queues.

Two expectations to set. First, these files are temporary previews - if a stage is worth keeping, save it from final_image or your own branch of the graph. Second, the bundle is process-local workflow data: it's meant to be looked at in this session. Treat the viewer as a window, not an archive.