TF Decode Levels

TF Generate hands you four latent levels and no picture, and this is the node that turns them into one. TF Decode Levels runs the trajectory through the RAE decoder, and the reason you'd bother decoding more than the final level is the whole point of Trajectory Forcing: the decoder is frozen and lives in the same DINOv2 space as the latents, so every intermediate level decodes to a legible image, not just the last one.

That's a genuinely different situation from a diffusion model, where intermediate latents are visual noise and only the endpoint means anything. Here level 0 is a coherent "object and background" sketch, level 1 adds parts, level 2 subparts, and level 3 is the fine finish - each one a real image you can look at, edit, or save. If you've ever sat in front of a diffusion sampler wishing you could see what a given step "thinks," this is the research method that actually delivers it.

The one input that matters most is which: all levels, final level only, or a single named level. It's a dropdown, and there's a deliberate design note hiding in the tooltip - the old "mode plus number" UI left a number that did nothing in two of its three modes, so the author collapsed it into one control. level_override (default -1, auto) only matters for a hypothetical model with more than four levels, which no released checkpoint has, so leave it alone. label_levels (on by default) stamps "Level 2 (subparts)" under each frame because a plain batch preview shows no captions, and sheet_layout decides whether the levels come back stitched into one contact sheet or as separate frames. The contact sheet is the sane default: ComfyUI pages a multi-frame output behind a little 1/4 button, so four decoded levels would otherwise look like level 0 alone. Contact sheets are also the only shape SaveImage writes as one file - a batch writes one file per frame.

Outputs are images (the decoded levels as a single IMAGE) and a warnings string. The optional pipeline socket is normally unnecessary because the trajectory carries the pipeline that made it - you only wire it for a trajectory you restored with TF Load Levels, which has no pipeline of its own.

Two practical notes. First, decoding is the expensive part of this pack's memory story: building the RAE decoder is what takes you from ~4.6 GiB (compiled sampler) to ~6.6 GiB peak, and it's a ViT-XL class network, so decoding all four levels is four passes. On an 8 GB card the README's own advice is to decode final level only rather than all four. Second, this is where a first-run download hides: the decoder weights (~1.6 GB) fetch lazily on the first decode, and if you used TF Load Pipeline's warmup, that download happens behind the load progress bar where you can see it.

Install

The pack installs like its siblings: Manager → search Trajectory Forcing, or clone https://github.com/korayulusan/ComfyUI-TrajectoryForcing into custom_nodes/. The catch, shared by every node here, is that it runs a JAX model inside ComfyUI and usually needs its own Python 3.11 env on CUDA 12 - requirements.txt is deliberately empty so Manager can't rewrite your torch, and install.py declines gracefully when your setup won't work rather than silently breaking it. When it declines, the README's env/setup.sh builds a separate venv. If anything's ambiguous afterwards:

cd ComfyUI/custom_nodes/ComfyUI-TrajectoryForcing
python -m tf_nodes.doctor

Want to check whether a decoded level is really "right"? Compare two trajectories at the latent level with TF Compare Levels - it's cheaper than decoding and reports exactly which tokens moved.