Omini Kontext Conditioning

FLUX.1-Kontext-dev takes one image and one sentence, and edits the image to match the sentence. That's its whole deal - in-context editing, no masks, no ControlNet. What it can't do, out of the box, is look at a second image. You can tell it "add a character," but you can't hand it the character. OminiKontextConditioning is the node that plugs that hole: it tucks a reference image into the conditioning so the model sees the character and the scene, and a matching LoRA does the rest.

The catch, and it's a real one: this only works if you're using a LoRA trained with the Omini Kontext framework. The node's own description says it flat out. The vanilla Kontext model isn't built to consume two images, so the LoRA is what teaches it where to find the reference. A normal Kontext character LoRA in the same graph does nothing.

How it works

Omini Kontext borrows its trick from OminiControl. Flux Kontext embeds images as tokens with 3D RoPE positional coordinates - x, y, and a sequence index. The author's insight was that you can nudge the reference image's coordinates so it occupies its own slot in that 3D grid instead of being glued to the base image. The trained LoRA knows exactly where that slot is, because the position is fixed at training time.

That's what the three delta_* inputs are. delta_0 is the sequence-index offset, delta_1 and delta_2 are height and width offsets in the position grid. The values must match the LoRA you loaded - this isn't a tuning knob you explore, it's a handshake.

• character_3000 / product_2000 (character or product on a white background): delta_0=0, delta_1=0, delta_2=96. That 96 is (1024+512)//16, the reference slot offset from the README.
• spatial-character-test (place the character where you want it in the scene): delta_0=1, delta_1=0, delta_2=0.

The inputs that matter

Three of them, and only the last three need you to think:

• conditioning - your prompt conditioning from a standard Flux CLIPTextEncode.
• latent - a VAE-encoded reference image. For the character models, the reference should be a cutout on a white background; for the spatial model, it must be the same size as your base image with the character drawn where you want it to land.
• delta_0 / delta_1 / delta_2 - the handshake values above. Wrong deltas and you'll get a garbled or duplicated reference smeared across the output.

It outputs a single CONDITIONING, which feeds the KSampler. Wire it into the positive/editing conditioning side.

Wiring it up

Load Diffusion Model (FLUX.1-Kontext-dev) → OminiKontextModelPatch → KSampler
DualCLIPLoader + CLIPTextEncode ─────────────────────────────→ OminiKontextConditioning → KSampler
LoadImage (reference) → VAEEncode ───────────────────────────→ OminiKontextConditioning

Load the matching LoRA at 0.5–0.7 strength and set CFG to 1.5 - both are from the README and both matter. The reference was trained at 512×512 but works fine at 1024×1024. If the inserted character comes out comically large, that's expected; the README says to just use a smaller reference resolution.

Install

ComfyUI Manager → search Omini Kontext → install, or:

cd ComfyUI/custom_nodes
git clone https://github.com/Saquib764/omini-kontext

Restart ComfyUI, then grab the LoRAs from saquiboye/omini-kontext on HuggingFace - character_3000.safetensors, product_2000.safetensors, spatial-character-test.safetensors.

Where it breaks

This is a one-person research project (last meaningful update was late 2025), so temper expectations: results are decent for character insertion into a scene but you'll see rough edges, and the spatial model takes "some freedom" about where the character actually lands. It's a proof of concept you can run locally, not a production editing tool - if you need a bulletproof second-image edit, Qwen-Image-Edit (with its own LoRA library) is the safer 2026 bet.