Emphasis Encode [EXPERIMENTAL] (CCN)

You know the drill from SD 1.5: wrap a word in (word:1.3) and it gets a little louder. It works there because CLIP reads weighted tokens directly. Then you switch to a Wan or T5-based model, type the same thing, and nothing happens - those encoders are fed clean text, and per the ComfyUI-era folklore now baked into the prompt-engineering knowledge base, the parentheses and colon are either ignored or, worse, read as literal punctuation inside an instruction. Emphasis Encode is the author's attempt to bolt that A1111 habit back onto models that threw it away. It's labeled [EXPERIMENTAL] for a reason, and you should treat it accordingly.

How it works

The node never modifies your prompt text. It parses the emphasis markers out of the string, tokenizes the clean text, and then multiplies the weights of the tokens that land inside each emphasized region before encoding. So (sunset:1.3) becomes "sunset" with those tokens weighted 1.3x, and ((word)) is shorthand for (word:1.1) - nested markers multiply, so ((word:1.2)) is 1.32x.

The catch is that it maps character positions to tokens with a blunt estimate: it divides the length of the clean text by the real token count and assumes each token covers that many characters. Token boundaries rarely line up with word boundaries, so the effect is approximate. That's the honest mechanism, and the author says it works best on single words or short phrases - don't expect surgical results on a run-on sentence.

The inputs that matter

• clip - your CLIP/text encoder, wired from whatever model you're using.
• text - the prompt, with emphasis markers inline. This is the whole point of the node.
• debug - flip this on and the node prints the full token mapping to your console, so you can actually see which token IDs got weighted and by how much. When a word refuses to respond, this is how you find out whether the emphasis landed on the wrong tokens.

It outputs a normal conditioning you feed to the sampler, plus two string outputs: parsed_info (a summary of what emphasis regions it found) and debug_output (the full diagnostic dump). The strings are handy if you want to log what the node decided to do, but for a normal generation you only care about the conditioning socket.

Installing it

This ships in ComfyCollectorNodes, so install the pack once and you get all twenty-ish nodes including this one. In ComfyUI Manager, search ComfyCollectorNodes, or clone it:

cd ComfyUI/custom_nodes
git clone https://github.com/valkymaera/ComfyCollectorNodes

Then restart ComfyUI. No model downloads, no extra Python deps - the pack is plain torch and PIL. All nodes appear in the menu with a (CCN) suffix.

Where people get burned

The big one is expectation setting. T5 and Wan encoders are resilient to token-weight fiddling in ways CLIP wasn't; some models respond nicely, others shrug. And because this re-encodes with modified tokens rather than nudging the conditioning, results vary model to model - that's the "experimental" in the name. If a region does nothing, try moving the emphasis to a shorter phrase, and use the debug output to confirm the node actually found your markers. And if you want the post-emphasis normalization options, check out the Advanced sibling - it adds a normalization dropdown on top of the same engine.