LTX Identity Gemma-Vision (Caminho2)
Text-encode a reference image straight into conditioning
- clip
- reference_image
- conditioning
This one's short on documentation and light on GSC traffic, so let's be honest about what we know versus what we're inferring, and lean on the schema rather than guessing at internals. LTXIdentityGemmaVision takes a clip input, a reference_image, and a prompt string, and outputs a single conditioning. No model, no latent, no sampler wiring - this is a conditioning-only node that sits upstream of your usual LTXV chain.
The name is the biggest clue to what's going on. LTX-2 and LTX-2.3 both switched their text encoder from a CLIP-family model to Gemma 3 12B - a genuine LLM doing the text encoding, not a CLIP-style joint text-image model. "Gemma-Vision" strongly suggests this node runs that text-conditioned-vision pathway directly: instead of describing your reference image in words and hoping the prompt captures it, you hand the image itself alongside a short instruction (prompt defaults to "ref_t2v: a person in a room, medium shot.") and let the vision-capable encoder fold the two into one conditioning tensor. That default prompt's ref_t2v: prefix looks like a task tag the author's training pipeline expects, which is worth keeping rather than deleting if you're not sure what breaks without it.
Given the LTX-2 line's Gemma 3 12B encoder is a genuinely heavy component - 22+ GB in fp16, and the single biggest cause of out-of-memory errors reported after LTX-2 shipped - expect this node's clip input to want that same Gemma-based text encoder loaded, not a CLIP checkpoint from the 1.x/13B era of LTXV. If you're already running LTX-2 or LTX-2.3 locally you likely have this covered; if you're still on the older 2B/13B LTXV line, this node probably isn't for you.
What you set
There isn't much to tune:
reference_image- the thing whose appearance you want folded into conditioning.prompt- multiline text, defaulting to aref_t2v:-tagged scene description. Treat the prefix as part of the contract rather than boilerplate to delete.clip- your loaded text/vision encoder.
The single conditioning output is meant to feed wherever your workflow expects a positive (or similar) conditioning input - most likely paired with one of this pack's other identity or Edit Anything nodes, given the shared "Caminho2" naming and the BFS/LTX Identity category it lives in alongside the rest of the identity family.
Installing it
Same pack, same steps as every other node here. Through ComfyUI Manager, search "ComfyUI-BFSNodes." By hand:
cd ComfyUI/custom_nodes
git clone https://github.com/alisson-anjos/ComfyUI-BFSNodes.git
cd ComfyUI-BFSNodes
pip install -r requirements.txt
Restart ComfyUI. Beyond the base pack dependencies, budget for whatever your Gemma 3 12B text encoder normally requires - that's the heavy part of any LTX-2-era workflow, this node included, and it's an existing ComfyUI-LTXVideo component rather than something BFSNodes ships itself.
Honest gaps here
The README doesn't mention this node at all - it documents only a handful of the pack's nodes, and the identity family (this one included) is newer than what's written up. We don't have a tooltip or description to quote, so take the "Gemma vision-conditioning" read as an informed inference from the name, the clip+reference_image+prompt shape, and LTX-2's known architecture, not a confirmed mechanism. If you hit an error here, the ComfyUI console traceback and the pack's GitHub issues are going to be more reliable than anything written about this specific node right now - including this article.
Inputs (3)
| Name | Type | Default | Description |
|---|---|---|---|
| clip | CLIP | — | |
| reference_image | IMAGE | — | |
| prompt | STRING | ref_t2v: a person in a room, medium shot. | — |
Outputs (1)
| Name | Type | Description |
|---|---|---|
| conditioning | CONDITIONING | — |