Krea2 img2img ⚡

Krea2's graph is short: load, prep, sample. Krea2 img2img is the prep - one node that takes your prompt, builds the latent (or starts from a photo), attaches a control image if you're using a Control LoRA, and outputs model, positive, negative, latent and denoise ready for a stock KSampler. You type the prompt directly into it. There's no separate CLIPTextEncode, no separate empty-latent node, and no separate ControlNet Apply in the default graph. Everything that Krea2 needs before sampling happens here.

The inputs that matter

• prompt / negative_prompt - typed here. Krea2's encoder is a Qwen3-VL, so write sentences.
• image - the init image for img2img and (in auto_depth/auto_canny mode) the source photo the control map is derived from. Leave unconnected for txt2img.
• control_mode - the interesting one. auto_depth (default) derives a depth map from image using the pack's Depth Anything V2; auto_canny derives a canny edge map (plain cv2.Canny, no model, no download); manual means you connect control_image yourself - for any widened-projection Control LoRA the two auto modes don't cover (pose/lineart/normal).
• control_image - your own control map (depth/canny/pose/etc). Overrides auto-derivation whenever connected, and is required in manual mode.
• control_channel_mode / control_normalize / control_invert / control_batch_mode - the map-prep knobs: grayscale for depth, rgb for canny/pose/lineart; per_image_minmax for depth, none for edges; control_invert if your preprocessor's convention is reversed from the LoRA's training convention; batch mode for frames.
• edit_reference - the other Krea2 LoRA mechanism (see below). Only for in-context/edit-style LoRAs.
• strength, width / height, batch_size - the img2img/geometry basics.

Two LoRAs, two mechanisms - read this twice

There are two unrelated families of Krea2 LoRA in the wild, and this node supports both, deliberately:

• Widened-projection Control LoRAs (the depth one) ship with the DiT's first input-projection layer widened to accept control tokens. Loaded via Krea2 Control LoRA Loader, and used here through control_mode/control_image. This is "structure comes from the map, content from the prompt."
• Ordinary in-context LoRAs (e.g. krea2_canny-v0.1.safetensors) have no widened projection - they're plain LoRAs, loaded with stock LoraLoaderModelOnly, and used here through edit_reference: the reference image gets VAE-encoded and attached to positive conditioning as reference_latents. This is the Qwen-Image-Edit-style "structure from the edges, content from the text prompt" flow.

The only thing that changes between the two is which input slot your photo goes into: control_image-adjacent modes for the depth LoRA, edit_reference for the canny one. Mixing them does nothing - and the node guards the dangerous direction (Control LoRA loaded, no usable image → it raises instead of sampling a half-configured model; control image with no Control LoRA → ignored with a warning).

Installing it

Part of the CCTech pack, installed once:

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

Restart; find it under 🤖 CCTech/Krea2. You still need Krea2 Model Loader feeding it the model/clip/vae, and the Control LoRA loader (or a stock LoRA loader for the in-context kind) upstream on model.

The workflow

Krea2 Model Loader → Krea2 Control LoRA Loader (any Krea2 LoRA file - it auto-detects which mechanism it needs) → this node → Krea2 KSampler or stock KSampler → VAE Decode. That's the whole thing. The one-node design is the pack's answer to the reference pack's separate Encode+Apply split, and it's genuinely easier to keep straight.