ImageTokensT2I

The weirdest part of the Lumina-DiMOO pipeline is that images are generated as text. Not a latent like Stable Diffusion - a sequence of discrete tokens. ImageTokens_T2I is the node that decides how big that sequence is, which is why it's the only thing between you and the output resolution. Its entire job: take a height and width, and build the empty token skeleton the generator will fill in.

It looks trivial, and honestly it is - but it's the node where you set what size image you want, so it's worth understanding what it's actually doing under the hood.

How it works

The model doesn't output pixels. It outputs a string of VQ codes, one per 16×16 pixel patch, drawn from an 8192-entry codebook. So a 1024×1024 image is a 64×64 grid = 4,096 tokens. ImageTokens_T2I computes that grid from your height and width, then wraps it in the model's special markers: a begin-of-image / end-of-image pair, answer markers, and a newline token after every row so the model knows where one line of the image ends. Every position starts as the mask token - literally the placeholder the diffusion process will fill in - so the structure is "here's an empty image-shaped hole, go paint it."

None of this touches the GPU. It's pure token arithmetic, which means you can rewire resolution at will without paying for an encode pass.

Two inputs, both integers, both with defaults that actually make sense:

• height / width (INT, default 1024) - the output canvas size in pixels. The generator and decoder read these from the token bundle later, so the resolution you set here is what you get out at the end.

One output:

• image_tokens (LUMINA_IMAGETOKENS_T2I) → Generator_T2I. That's the whole wire; nothing else consumes this type.

Size math that matters

Since tokens are 16×16 patches, resolution maps directly to compute. 1024×1024 is 4,096 tokens; the shipped text-to-image example uses 768×1536 (a portrait orientation with a nearly identical token count). Push to 1536×1536 and you've got 9,216 tokens - double the sequence, roughly double the generation time and memory. The config caps the default at 1024, and the sane move is to stay near a 1024² equivalent and upscale later rather than generate huge natively.

Installing and wiring it

This node comes with the ComfyUI-Lumina-DiMOO pack. Install via ComfyUI Manager (search the pack name), or:

cd ComfyUI/custom_nodes
git clone https://github.com/L-Hugh/ComfyUI-Lumina-DiMOO.git
cd ComfyUI-Lumina-DiMOO
pip install -r requirements.txt

Then restart ComfyUI. The full graph is LoadModel → ImageTokens_T2I and PromptBuilder → Generator_T2I → VQDecode → a preview node. The pack ships example workflows you can load from Templates → EXTENSIONS → ComfyUI-Lumina-DiMOO, and the t2i one is the fastest way to see this all wired together.

One thing to know before you click: the whole snapshot of weights is a ~17 GB download (see the LoadModel article for the hf download command), and the pack's requirements.txt pins old torch and transformers versions - a dependency minefield in shared environments. The token math here is the easy part; the environment is the actual obstacle.