OminiControl Subject

Subject-driven generation, in case the name doesn't land: give OminiControl Subject one reference image of an object - a watch, a mug, a sneaker, a T-shirt - and it re-renders that exact object into a brand new scene from your prompt. Same item, different lighting, different angle, different world. It's the "put my product on the moon" trick, and it's the headline feature of the OminiControl research project (arXiv 2411.15098, from NUS) that this pack wraps.

The RunningHub_ prefix isn't a mystery: RunningHub is a cloud ComfyUI platform, and this is their port of the OminiControl codebase into plain ComfyUI nodes. No API, no key, no cloud dependency - it all runs on your own GPU, which is the nice part.

How it works

OminiControl's bet is that you don't need a full ControlNet copy of FLUX to steer it. Instead a tiny LoRA (about 0.1% of the model's parameters) teaches FLUX to treat a reference image as extra tokens in the sequence. Your subject gets VAE-encoded into "condition tokens" spliced in beside the image and text tokens during denoising, tagged with a type id so the model knows this is a subject to preserve, not scenery to reinterpret. Because the base is FLUX.1-schnell, sampling runs in just 8 steps.

The node hides all of that plumbing. It encodes your prompt with T5 + CLIP, encodes the subject image, loads the subject_512.safetensors control LoRA, samples, decodes - and hands you a finished image. No KSampler, no separate Flux loader, nothing else in the graph.

The three inputs

• subject_image (IMAGE) - your reference shot. Crop the object reasonably tight before loading; everything gets resized to 512×512.
• prompt (STRING) - describe the new scene and refer to the object as "this item", "the object", or "it". The example workflow ships with a good one: "A very close up view of this item. It is placed on a wooden table." Don't describe the object's appearance - the image is doing that job.
• seed (INT) - the noise seed. More on that below.

The output is a single image (IMAGE) at a fixed 512×512, wired straight into a SaveImage or PreviewImage.

Installing it

ComfyUI Manager (search ComfyUI_RH_OminiControl), or the manual route:

cd ComfyUI/custom_nodes
git clone https://github.com/HM-RunningHub/ComfyUI_RH_OminiControl
# restart ComfyUI

The heavy lift is models, and this is where people bail. You need the whole FLUX.1-schnell in diffusers format (transformer shards, T5-XXL, CLIP-L, VAE, tokenizers - call it 30+ GB) sitting at ComfyUI/models/flux/FLUX.1-schnell, plus the control LoRA at ComfyUI/models/flux/OminiControl/omini/subject_512.safetensors. The pack ships no requirements.txt; the README recommends diffusers 0.31.0 for FluxPipeline support, so pin that if your ComfyUI env is older.

Where people get burned

• FileNotFoundError almost always means a model isn't at the exact path the README's directory tree shows. The node hardcodes those paths.
• bfloat16 everywhere. The pipeline runs in bf16, so you need an Ampere-or-newer NVIDIA card - this pack is built and tuned for a 4090. An old card will error on dtype or crawl.
• The seed is a lie. The code does seed % (2 ^ 16) - and in Python ^ is bitwise XOR, so 2 ^ 16 is 18, not 65536. You get roughly 18 distinct outcomes, not 2^64. Don't spend an hour hunting the perfect seed; vary the prompt instead.
• Objects, not people. The original model was trained on objects; a face in the subject image will drift. Use this for products, not portraits.
• One image per run - the node asserts a batch size of 1.

If you're doing e-commerce mockups, consistent product shots, or generating reference images to train a LoRA later, this is genuinely the cheapest way to get there on FLUX without a ControlNet stack.