Krea2 Identity Edit (grounded encode) ⚡

The Krea 2 Identity Edit LoRA has a dirty secret: stock CLIPTextEncode never lets the model see the photo while it reads your instruction. The LoRA was trained with the edit prompt and the source image fed into the Qwen3-VL text encoder together, so if you encode the text alone you're running with half the recipe missing - quality drops sharply, especially for scene-referential edits like "the man on the left." This node is the missing half.

It's the "grounded encode" side of the pair. Its sibling, Krea2 Identity Edit (source patch), wraps the diffusion model so your photo's VAE tokens get injected as in-context reference frames (that's the appearance - face, clothes, lighting). This node handles the semantics: it encodes your prompt together with the source image through Qwen3-VL's own vision path, so "the sign in the back" actually refers to the sign in the back. Both nodes are required for correct results with the v1.2 Identity Edit LoRA. Don't skip one and wonder why the edits look like a bad photoshop job.

How it works

Krea 2's text encoder is Qwen3-VL-4B, a vision-language model. CLIPTextEncode just tokenizes text. This node instead calls clip.tokenize(text, images=[...], llama_template=...) - the real image-grounded call - so the instruction is encoded with the reference picture, tapping multiple vision layers the way the training recipe did. It's a faithful port of comfyui-krea2edit's Krea2EditGroundedEncode (Apache-2.0), and the whole pair is the reason that pack exists.

The inputs that matter

• clip and prompt - required. Use the Krea2 text encoder (Qwen3-VL-4B) from the pack's Krea2 Model Loader, and type the edit as an instruction, not a caption.
• image - the source photo being edited, same one you're feeding the source-patch node. Leave it unconnected and you get plain text-only encoding (stock behavior).
• image_b - a second reference for multi-ref LoRAs; vision blocks arrive in training order: scene, then subject.
• grounding_px (default 768) - caps the resolution fed to the vision encoder. The v1.2 LoRA was trained in the 384–768 range. Lower pushes harder on edit adherence, higher leans into identity/likeness. Community experience on slow workflows: 384 often lands cleaner than the default.
• system_prompt - advanced; override the grounding system prompt (empty = training default).

Output is a single CONDITIONING, wired into your KSampler. The classic setup runs this node twice: one instance with your instruction and the image feeding positive, one with an empty prompt and the same image feeding negative - that matches the LoRA's trained unconditional for CFG > 1.

Installing

Everything ships in the CCTech fork of the GGUF loader pack:

cd ComfyUI/custom_nodes
git clone https://github.com/ChrisColeTech/ComfyUI-GGUF-Loader
pip install --upgrade gguf

Restart ComfyUI. Then grab the weights the pack deliberately doesn't bundle - krea2_identity_edit_v1_2.safetensors from conradlocke/krea2-identity-edit, plus the Krea2 diffusion model and Qwen3-VL-4B encoder. It loads under the 🤖 CCTech/Krea2 category.

Gotchas

The Identity Edit workflow is slower than a plain Krea2 gen because Qwen3-VL runs on the full image - users have reported 25-minute renders that collapsed to ~20 with 8–12 steps, ~1MP resolution, and a turbo checkpoint. Match the input and output aspect ratios exactly to avoid smudging. And remember: this node alone does nothing. It's one half of a pair, driving a LoRA that has to be loaded upstream via LoraLoaderModelOnly.