Painter Flux Image Edit

If you've built a Flux 2 Klein editing workflow by hand, you know the drill: text encode node, VAE encode node, a Reference Latent node to shove your source image into the conditioning, then wire all three into the sampler and hope you got the order right. PainterFluxImageEdit collapses that whole chain into one box. Plug in CLIP and a prompt and it's a plain text-to-image node; plug an image into image1 and it silently becomes an editing node instead. No mode switch to flip, no extra nodes to swap out - it just notices the image is there.

That dual-mode trick is the entire pitch. Flux 2 and its distilled Klein checkpoints already unify generation and editing in one model - that's the headline feature that made Klein the default local edit model through mid-2026 - but ComfyUI's stock node graph still makes you assemble the plumbing yourself. This node is that plumbing, pre-wired.

How it works. Feed it a prompt and a CLIP model and it encodes your positive and negative conditioning like any text-encode node would. Drop an image into one of the image slots and it also VAE-encodes that image and folds it in as a reference latent, the same mechanism the standalone ReferenceLatent node uses to give an edit model something to look at besides your words. Attach a mask on the first image and it restricts the edit to that region rather than touching the whole frame. The three outputs - positive, negative, latent - go straight into a KSampler set up for your Flux 2 checkpoint. That's the whole workflow: this node, then a sampler, then a VAE decode.

Inputs that matter. clip and prompt are your text side - nothing unusual there. mode is the one Flux-2-specific control: it's an enum that tells the node how many reference images to expect, from 1_image up through 10_image. Match it to however many imageN slots you've actually connected. width and height set your output resolution directly in the node (steps of 8 - the README is explicit that Flux 2 wants dimensions that are multiples of 8, so don't fight that), and batch_size is the usual batch count. Everything past that is optional: vae for the encode step, image1 through image10 for your references, and image1_mask - which, per the author, only ever affects the first image. Mask a second or third reference and it's ignored.

One thing worth flagging honestly: the pack's own README describes "up to 3 reference images," but the node itself exposes ten image slots and a matching ten-way mode selector. That's not a documentation typo so much as the README being written for an earlier, more modest use case - Flux 2 as a model architecture genuinely supports up to ten reference images for multi-subject composition, so the wider slot count on the node tracks what the underlying model can actually do. Just don't be surprised the README undersells it.

Installing it. Easiest path is ComfyUI Manager - search ComfyUI-PainterFluxImageEdit and install. Manually, it's the standard drop-in:

cd ComfyUI/custom_nodes
git clone https://github.com/princepainter/Comfyui-PainterFluxImageEdit.git

Restart ComfyUI afterward. There's no separate Python dependency list and no bundled model download - the node is pure graph glue, so all the weight is in what you already need for Flux 2: the Klein or Dev checkpoint, its VAE, and the Qwen3 CLIP text encoder BFL ships alongside it.

Where people actually get stuck, and it's not this node: it's the CLIP model feeding it. Klein's text encoder is a real Qwen3 LLM wrapped in a chat template, and running a heavily distilled/fp8 version of it against the 9B edit checkpoint is a known way to get badly broken, "cursed" output - extra limbs, blown-out compositions, nothing coherent - regardless of which conditioning node built the prompt. If your renders look garbled through this node, swap to the full-precision qwen_3_8b text encoder (or a solid GGUF quant of it) before you suspect the node itself; that single change is the fix people report. Beyond that, the two real footguns are dimension-related - keep width/height on multiples of 8 - and mode-related: if mode doesn't match the number of images you've wired up, or you're expecting a mask to apply to image2/image3 and it doesn't, that's expected behavior, not a bug.