MOSS i2i Text Encode (page + text)

A normal CLIP Text Encode turns words into conditioning. This one turns a picture plus words into conditioning: the page goes through Qwen3.5's vision tower ahead of your text, in the same user turn, and out comes a CONDITIONING that MOSS-Image can actually use. That's the whole trick - MOSS-Image has no image conditioning of its own, so if you want the model to know what's on the page and not just how big it is, something has to smuggle the picture into the prompt.

What it's for, and when you skip it

The pack gives you two ways to get a page into MOSS-Image, and this is the softer one. The vision tower returns the page's content - the model sees the panel, the faces, the shapes - but it does not return line placement, because each token covers a 32×32 px tile and position information is gone. Exact line work comes from the other path, the VAE reference in MOSS i2i Reference.

So the practical question is which colorize LoRA you're holding, and the README answers it directly:

| LoRA generation | Reference | Prompt encode | |---|---|---| | v3 (ref_isolate in the metadata) | full size, isolated | plain CLIP Text Encode - this node not used | | v2 | half size | this node, page + text |

If your LoRA is v3, don't wire this in, and don't take that as the node being useless - it's just that v3 was trained on a text-only prompt plus a full-size latent reference, and mixing in the vision path puts the model somewhere it wasn't tuned for.

The mechanism

The node builds one sequence: <|vision_start|>[page]<|vision_end|>{text}. The page is first fit to the target size (cover + centre crop, Lanczos), then pushed through Qwen2-VL-style smart_resize at factor 32 - so the vision tower sees roughly the target's pixel count rather than whatever your scan happened to be. At 1 MP that's around 1000 image tokens, which is the honest cost of this node: it makes your context long.

Then it tokenises the block plus your text and swaps the single image-pad token for the actual pixel tensor before encoding. If it finds anything other than exactly one image slot it throws rather than guessing - which is your diagnostic when something upstream is wrong.

The inputs that matter

• clip - has to be the MOSS-Image CLIP (from the pack's loader, or the moss-image node). That's what the one-image assertion is really checking.
• image - the page, straight from Load Image. Same image you feed the Reference node; two paths, one page.
• text - multiline, dynamic prompts supported. Empty text is a valid mode: page only, no instruction.
• resolution - the author's tooltip, verbatim: target area ≈ resolution², native aspect, sides multiples of 16, matching the training cache's target_size, and "keep it equal on the Text Encode and Reference nodes so the vision tower and the ref see the same page." Defaults to 1024. Believe it.

Output is a single CONDITIONING, and it goes into your sampler's positive input. The negative is a plain CLIP Text Encode of "" - that's what the colorize LoRA was evaluated with, not a stylistic choice.

For colorize work the text field is where you type the colour tags the LoRA trained on: the copyright, comic for a manga page, hair, eye and clothing colours. It's Danbooru-flavoured vocabulary rather than prose, which is what you'd expect from anything in this corner of the ecosystem - the LoRA learned tags, so feed it tags.

Install

ComfyUI Manager, search "MOSS i2i" (the repo now ships as MOSS Toolkit; the URL redirects), or:

cd ComfyUI/custom_nodes
git clone https://github.com/sorryhyun/ComfyUI-MOSS-i2i

Restart ComfyUI. No extra pip packages for this node - the pack's declared dependencies are torch, numpy, pillow, all of which you already have. (anime-tools is only needed by the caption/layout nodes, and it's optional: without it the pack loads the i2i nodes and logs a warning.) The real install cost is model downloads - DiT, a Qwen3.5 text encoder that's 16.8 GB in bf16 or 9.2 GB as an INT8/fp8 single file, and the VAE, all under models/moss_image/<name>/.

Where people get burned

The RuntimeError about placing N images, expecting 1, means your clip isn't the MOSS-Image one. It's almost always a plain SDXL or Flux CLIP Text Encode's output being reused, or a loader wired from the wrong socket.

Resolution drift between this node and the Reference node is the quiet failure: the vision tower gets a page cropped to one size, the reference latent gets another, and the output looks like the model half-remembered the page. Set both, check both.

And a structural one - a CONDITIONING is a value in the graph, not a patch on the model. LoRA strength lives in the model path (a LoRA is an adapter on the DiT; see the pack's LoRA loader / Reference node), so turning this node's text down or up changes what you're asking for, and changes nothing about how hard the LoRA is applied. People conflate those two constantly on any architecture this new.