ControlNet with Prompts

ControlNet setups are the worst offender for graph clutter - a loader for the ControlNet model, a Load Image for your condition map, two CLIP Text Encode nodes, and an Apply ControlNet (Advanced) node tying it all together, before you've even reached your sampler. This node is that whole cluster collapsed into one box: two prompts in, ControlNet-conditioned positive/negative conditioning out.

It's part of palant's Integrated Nodes for ComfyUI, the same pack behind txt2img and Double Prompt - this one is just the more elaborate of the pack's shipped examples, showing that "integrated node" doesn't have to mean a whole standalone workflow; it can be a mid-graph subassembly too.

What it does, and what it doesn't

Under the hood it's Load ControlNet Model → Apply ControlNet (Advanced), fed by two CLIP Text Encode nodes and a Load Image. What it is not is a preprocessor. The image you plug in needs to already be the condition map - an edge detection, a depth map, a pose skeleton, whatever your ControlNet was trained on - not a plain photo. If you need to turn a normal photo into a canny edge map or a depth map first, that's a separate step handled by the ControlNet Auxiliary Preprocessors pack, which isn't part of this node. Feed it a raw photo and you'll get results, just not the ones you're after.

The condition itself works by steering generation toward the spatial structure in your image (edges, depth, pose - whatever type your ControlNet checkpoint was trained on) while your two prompts still control content and style. Think of it as the "where" to your prompt's "what."

Inputs and outputs that matter

• clip, text, text_2 - same deal as Double Prompt: shared CLIP input, two prompts, one positive and one negative.
• control_net_name - pick your installed ControlNet checkpoint. It has to match your base model's architecture - an SD 1.5 ControlNet will not load against SDXL or Flux, they're trained from scratch per architecture and aren't interchangeable.
• image - your pre-processed condition map, chosen from previously uploaded images.
• strength - how hard the condition steers generation, 0-10 range but you'll rarely go past 1-2 in practice. 1.0 was the old SD-era default; most current union ControlNets recommend running noticeably lower, in the 0.65-0.9 range, so if a modern model looks overcooked or ignores your prompt entirely, try turning this down before anything else.
• start_percent / end_percent - when during sampling the condition is active, as a fraction of total steps. The classic trick here is starting at 0.0 and ending around 0.5, so ControlNet locks in composition early and then gets out of the way, letting the model add its own detail in the later, finer-grained steps instead of fighting the condition the whole way through.
• vae (optional) - only needed for the handful of ControlNet variants that require a VAE-encoded hint rather than a raw image; leave it unplugged unless your specific ControlNet model's documentation asks for it.

Outputs are positive and negative CONDITIONING, already carrying both your prompt and the ControlNet steering - wire them straight into a KSampler exactly like you would with plain CLIP Text Encode outputs.

Installing it

Comes bundled with the pack, no separate install:

• ComfyUI Manager - search "Integrated Nodes for ComfyUI."
• Manual - cd ComfyUI/custom_nodes && git clone https://github.com/palant/integrated-nodes-comfyui, then restart ComfyUI.

The node itself needs no extra dependencies, but you will need to separately grab a ControlNet checkpoint for your base model (they're not bundled with anything - control_net_name starts empty until you place one in your ControlNet models folder) and, unless you already have pre-made condition images, the Auxiliary Preprocessors pack to generate them.

Common issues

control_net_name is empty / node won't show model options. You haven't downloaded a ControlNet checkpoint yet, or it's in the wrong models folder. This node just lists whatever ComfyUI already sees.

Results ignore your image entirely, or look nothing like the condition. Almost always a mismatch between the ControlNet checkpoint's trained architecture and your base checkpoint - check both are the same family (SDXL ControlNet needs an SDXL base, and so on).

Output looks fried, oversaturated, or completely overridden by the condition. Strength is probably too high for a modern model. Try dropping into the 0.65-0.9 range rather than the SD-era default of 1.0.

Composition is locked too rigidly and the model can't add its own detail. Pull end_percent down from 1.0 - releasing the condition partway through sampling (a common setting is ending around 0.5) is the standard fix, letting the ControlNet fix composition early and the model take over for detail.