TF Compare Levels

This is the node the README points you to the moment an edit looks wrong, and it's the closest thing in the pack to an instrument rather than a tool. TF Compare Levels takes two trajectories - wire the original into before, the edited-and-resumed result into after - and tells you, per level and per token, what actually changed. It's the difference between squinting at two images and reading a number.

The report gives you the count of tokens that moved at each level, measured the same way the rest of the pack reasons about change: per-token cosine distance between feature vectors. That choice matters, because it means "changed" here means the same thing as "a different region" in TF Region Map - the measure is consistent across the whole editing vocabulary. The heatmap output draws one tile per level, brighter where tokens moved more, scaled to its own maximum so even a subtle edit shows up as a visible hotspot.

The structure of the result is the real diagnostic. A feature edit at level l* should leave every level below it untouched - sampling is Markov in the level index and edits only propagate upward. So a comparison that shows zero movement at levels below the edit, and movement above it, is the signature of a healthy edit. If the report shows nothing moved anywhere, your selection was probably empty or not where you thought - go look at what was actually selected. If levels above the edit look stale in the decoded images but the report shows changes down below, the likely story is that TF Resume From Level never ran, so the finer levels are still the old ones.

Two inputs earn a mention. decode_difference (off by default) additionally decodes both final levels and shows the pixel difference - that's two ViT-XL passes, which is why it's opt-in and why the latent heatmap is described as "free" by comparison. It only matters when you want to see the difference as an image rather than a map of the token space. And pipeline is needed only when decode_difference is on (the latent comparison needs no pipeline at all - it's pure numpy on the features) or when the trajectories came from TF Load Levels. size sets the output resolution of the heatmap.

There's an honesty limit worth internalizing: one before/after pair can't tell you whether the change came from your edit or just from re-sampling with a new seed. Both change the image. If you need to separate them - and you will, the first time a "big" edit turns out to be mostly seed noise - that's what TF Sweep Edit is for. It runs the same edit across several seeds against a no-edit baseline for each and reports the spread. TF Compare Levels is the eyeball check; TF Sweep Edit is the controlled experiment.

Install

Standard for the pack: Manager → search Trajectory Forcing, or clone https://github.com/korayulusan/ComfyUI-TrajectoryForcing into custom_nodes/. JAX-inside-ComfyUI, own Python 3.11 environment on CUDA 12, empty requirements.txt so Manager can't rewrite your torch, install.py that adds the JAX stack or declines with a printed reason (declining is normal and not an error). The README's env/setup.sh is the fallback. When in doubt:

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

Save the before trajectory with TF Save Levels before you start editing - a comparison only means something when you can regenerate or reload both sides.