Text Encode (JoyImageEdit Plus)

The one-line take

This is the multi-reference sibling of TextEncodeJoyImageEdit - the node that lets JD's JoyAI-Image-Edit-Plus look at up to five reference images while it follows your edit instruction. One reference is the basic edit game; two or more is where this model gets genuinely interesting, because it can copy a face from one photo, a jacket from another, and a pose from a third, all in one pass. It ships in the same ComfyUI-JoyAI pack and is what you want when single-image editing isn't enough.

How it works

Same family as the single-reference node: it bucketizes each image, tokenizes your prompt with visual tokens attached, VAE-encodes every reference, and tucks the whole set into the conditioning as reference_latents. The Plus twist is that each reference is independently bucketed - the node center-crops every input onto JoyAI's 1024 aspect-ratio grid on its own, so your five refs can all be different sizes and it doesn't care. It then builds the prompt in the layout the Plus model was trained on: one visual token block per reference, followed by your edit instruction, wrapped in the proper Qwen3-VL chat template.

Two details matter. First, order is semantic: image1 through image5 map to the reference sequence the model sees, so swap two wires and the model's understanding of "who is who" swaps with them. Second, the output you care about for sampling is target_image - the last reference, bucketed - because the Plus pipeline defaults its output size to the final reference. Feed that into VAE Encode, then KSampler at denoise = 1.0.

The inputs and outputs that matter

Inputs are clip, prompt, vae, and the star of the show: images. That's an auto-growing socket - connect image1 and a fresh image2 input appears, up to five. The tooltip says it plainly: "1–5 reference images, each independently bucketed to its own aspect-ratio bucket." Wire the same references into both the positive and negative copies of the node, just like the single-ref version; an empty negative prompt still needs its images. Outputs are CONDITIONING and target_image, and both feed the standard KSampler path.

Install

Identical to the rest of the pack: ComfyUI Manager (search "ComfyUI JoyAI"), or:

cd ComfyUI/custom_nodes
git clone https://github.com/Nynxz/ComfyUI-JoyAI

Then restart and restart nothing else - the pack ships with zero Python dependencies. The one gotcha specific to Plus is the model file. The single-ref transformer lives on jdopensource/JoyAI-Image-Edit-ComfyUI; the Plus transformer is a separately-packed bf16 file on nynxz/JoyAI, and it's tagged with joyimage_variant: plus safetensors metadata so the stock Load Diffusion Model node routes it to the Plus config automatically. If you point it at an untagged file, the loader treats it as the base model and you'll get the wrong architecture silently. You also need the Qwen3-VL-8B text encoder (Load CLIP, type joyimage) and the Wan 2.1 VAE, same as the single-ref workflow.

Common issues

• Untagged model file → wrong routing. This is the Plus-specific trap. Base and Plus share identical tensor shapes, so the only thing distinguishing them is that metadata tag. Use the file from nynxz/JoyAI, not the single-ref file.
• Out-of-order references. Order is semantic, and there's no visualizer - miswire and you'll see the edit apply to the wrong subject. Label your LoadImage nodes.
• Too many refs for your VRAM. Every reference is a full VAE-encoded latent plus visual tokens in the encoder context. This is already a bf16 16B model; a five-reference run is the heaviest load this pack can hand your GPU. The original ComfyUI integration needed north of 30GB; this pack's normal model-path handling helps with memory management, but it's still not a laptop card's job.
• The usual JoyAI rules still apply: image inputs must be single images (no batches), don't add a CFGNorm or custom sampler_cfg_function node (the model self-installs its guidance rescale and rejects overrides), and skip ControlNet entirely.

One more framing note: the Edit Plus file and graph are the pack author's own reconstruction against the official Diffusers reference, not something JD shipped as a ComfyUI node - so if something misbehaves, that's where to poke first.