SSR Apply Model

ApplySSR ("SSR Apply Model") is the payoff node in the four-node SSR-Encoder pipeline, and honestly the least glamorous one. LoadSSRAligner and LoadSSRAttention fetch the trained weights, EncodeSSRQuery builds the subject embedding from your reference image and text query - and then nothing happens until ApplySSR stitches it all into your checkpoint. Wire this one wrong and the other three might as well not exist. Wire it right and you get subject-driven generation where the text query decides what to copy from the reference, no LoRA training required.

Why you'd reach for it

SSR-Encoder (from the CVPR 2024 paper by Xiaojiu-z et al.) is a cousin of IP-Adapter: an image-prompting adapter that injects reference-image features through cross-attention while leaving your prompt path intact. The difference is selectivity. IP-Adapter more or less copies the whole image's vibe; SSR lets you point at the reference and say "give me the fur, not the woman." ApplySSR is where that injected attention physically gets installed, so think of it as the glue between the SSR machinery and the sampler.

How it works

The node clones your model (the original is untouched, which is a nice safety property), then walks through the ssr_attentions dictionary it received and replaces the UNet's text cross-attention (attn2) in each block with the SSR cross-attention module - input blocks 1–6, the middle block, and output blocks 3–11. Each of those modules runs the normal cross-attention and adds a scaled extra attention pass against the SSR embedding's key/value pairs. The positive embeds ride the positive (cond 0) branch, negative embeds ride the negative/uncond branch. The ssr_embeds you feed in carry their own per-query scales from EncodeSSRQuery, so ApplySSR itself has no strength slider - the strength was decided earlier.

Inputs and outputs

All three inputs are required, and they come straight from the other pack nodes:

• model (MODEL) - your base checkpoint, e.g. from CheckpointLoaderSimple.
• ssr_attentions (SSR_ATTENTIONS) - from LoadSSRAttention.
• ssr_embeds (SSR_EMBEDS) - from EncodeSSRQuery.

Output is a single patched MODEL. Feed that to the KSampler, not the original checkpoint. If you route the unpatched model into the sampler instead, you'll scratch your head over why nothing changed.

The standard graph reads: checkpoint → ApplySSR's model, LoadSSRAttention → ssr_attentions, EncodeSSRQuery → ssr_embeds, ApplySSR → KSampler. That's it. Because the node clones the model, you can also run one branch with SSR and one without from the same checkpoint and compare - the clone keeps them independent.

Installing

ComfyUI Manager: open the Custom Nodes Manager, search "SSR Encoder" (the pack title is ComfyUI-SSREncoder), install, restart. Manual route:

cd ComfyUI/custom_nodes
git clone https://github.com/logtd/ComfyUI-SSREncoder

Then restart ComfyUI. There's no requirements.txt and no pip step - the pack runs on stock ComfyUI (torch + safetensors + the built-in comfy API). What it can't live without are the two model files. Download ssr_aligner.safetensors (~25MB) and ssr_attentions.safetensors (~73MB) from huggingface.co/logtd/ssr_encoder into ComfyUI/models/ssr/. The loader nodes create that folder on import, but their dropdowns stay empty until the files land.

Common issues

The classic failure mode is silent: everything renders, nothing is SSR'd. Check, in order: the ssr_embeds wire actually reaches ApplySSR, EncodeSSRQuery has a non-empty query with a non-zero positive_scale (an empty query produces empty embeds, and the node has nothing to inject), and the patched MODEL is the one feeding the sampler. One more thing worth knowing: this is a hard-coded SD 1.5 tool. The aligner and attention layers assume a 768-dim CLIP text encoder and a ViT-L/14 vision encoder, so don't try to graft it onto SDXL or Flux - the dimensions simply won't fit. On SD 1.5 it's a fun, training-free way to pull one subject out of a busy reference, and ApplySSR is the quiet workhorse that makes it happen.