Repeat VAE
Run an image through encode/decode N times and watch it degrade
- images
- vae
- IMAGE
Every VAE encode/decode round trip loses a little information - that's not a bug, it's what "lossy" means, and it's the reason chained img2img passes and stacked inpainting steps slowly grind an image down even when nothing else in the workflow is wrong. This node makes that effect visible on purpose. It takes an image, runs it through the same VAE's encode-then-decode cycle count times in a row, and hands you back whatever survives. Per the pack's README, it's built for testing and comparing VAEs against each other - run the same source image through two candidate VAEs at the same count and you get a real, measurable answer for which one degrades faster or uglier, instead of an argument about vibes.
How it works
There's nothing clever in the mechanism - it's just a loop around VAE Encode → VAE Decode, repeated. What makes it useful is that the known failure signature of repeated round trips is specific and recognizable: a drift toward one dominant color, contrast creeping up, fine detail falling away, and the effect is worst at low denoise because there's no fresh generation happening to add information back. Running that loop explicitly turns an abstract "VAEs are lossy" fact into something you can point at on screen.
Inputs and output
images(required, IMAGE) - the source image to degrade.vae(required, VAE) - the VAE doing the encoding and decoding.count(required, INT, 1 to 1,000,000, default 4) - how many encode/decode cycles to run.
Output is a single IMAGE - the result after all count cycles.
Practical guidance
You will never need anywhere close to the field's max. The degradation pattern above is usually obvious within single-digit to low-double-digit cycles; past that point you're mostly watching an already-collapsed image cycle in place rather than learning anything new. Start at the default of 4, and if you want to see a trend rather than one snapshot, bump it a few times and compare rather than jumping straight to a huge number thinking it's more rigorous - it's just slower.
Installing it
ComfyUI Manager: search TechNodes, install, restart. Or by hand:
cd ComfyUI/custom_nodes
git clone https://github.com/TechnoByteJS/ComfyUI-TechNodes --depth 1
No model downloads, no extra dependencies.
Where people get burned
Setting count extremely high on a large image is the obvious one - this is count sequential encode/decode passes, so runtime scales linearly with it, and the field's technical max of 1,000,000 is not a number anyone should actually hit. The more useful mistake to avoid is comparing VAEs that were never meant to sit side by side - an SD 1.5 VAE against an SDXL VAE, say. Each architecture's autoencoder is its own incompatible design, so a "worse" result might just mean you compared two things that were never trained against the same latent space, not that one VAE is genuinely inferior. Only use this to compare VAEs built for the same checkpoint family.
Inputs (3)
| Name | Type | Default | Description |
|---|---|---|---|
| images | IMAGE | — | |
| vae | VAE | — | |
| count | INT | 41–1000000 | — |
Outputs (1)
| Name | Type | Description |
|---|---|---|
| IMAGE | IMAGE | — |