# Full-pipeline renders — 1024x640

These are the samples as the vendor's graph actually produces them: sample at
512x320, upscale the latent 2x, sample again at 1024x640. Everything else in
`../` stops after the first pass.

That second pass was skipped in this project from the start, on a written
assumption that a 16 GB card could not afford four times the token count. It
was never measured. Measured, it peaks at **10.03 GiB** and adds about a minute
— and it is the difference between soft and sharp: **4.1x the Laplacian
variance** against the one-pass output enlarged afterwards, on a common grid.
The comparison crop is at `../idol/sharpness-1pass-vs-2pass.png`.

| file | seconds | prompt |
|---|---:|---|
| `00-robot.mp4` | 2.0 | humanoid robot, rain-slick loading bay |
| `01-dune.mp4` | 2.0 | lone figure walking a red dune at sunset |
| `02-forge.mp4` | 2.0 | blacksmith, anvil, sparks — **does not follow the prompt, see below** |
| `02-forge-unpadded-local.mp4` | 2.0 | the same prompt, encoded unpadded, which does |
| `03-road.mp4` | 2.0 | sports car through a wet mountain hairpin at night |
| `04-smoke.mp4` | 2.0 | rescue robot in a collapsed corridor |
| `05-idol-15s.mp4` | **15.0** | the anime idol prompt, 361 frames |

Prompts are the ones in `../README.md` and `../idol/prompt.txt`, unchanged.

## Rendered on the Space, not the workstation

All six came from
[the Space](https://huggingface.co/spaces/topabaem/LTX-2.5-Text-Encoder-4bit-8GB-Demo),
which runs this same 4-bit encoder on ZeroGPU. The 15-second two-pass render
takes 110 s there. The local V100 was lent to another job at the time, and this
did not need it.

One consequence worth stating: the Space encodes through ComfyUI's own path,
which left-pads every prompt to 1024 tokens. The clips in `../` were encoded
unpadded. Same encoder, same weights, slightly different conditioning — so
these are not the one-pass clips with a second pass bolted on, they are
different samples.

## One of these does not follow its prompt, and it is informative

`02-forge.mp4` is not a forge. It is a man beside a tree, and three seeds
(20260815, 7, 42) all landed somewhere unrelated.

That prompt renders correctly in `../` — anvil, glowing steel, hammer, sparks.
`02-forge-unpadded-local.mp4` is that render, kept here for the comparison.

The difference is not the second pass: re-running on the Space at `refine=0`,
same seed, still gives the man and the tree. It is **the conditioning path**.
The Space encodes the way ComfyUI does, left-padding every prompt to 1024
tokens; the clips in `../` were encoded unpadded. Same encoder, same weights,
same DiT, same seed, same resolution — and one finds the forge while the other
does not.

It does not run one way. On this batch the padded path produced a *better*
robot, dune and idol than the unpadded renders in `../` did, and the unpadded
path is the one that finds the forge. The honest statement is that padding
changes **which prompts land**, not how good the output is, and this project's
own note in `ltx_conditioning_dump.py` — that the padded path is simply the
right one for feeding a DiT — is not supported by that.

Which of the two is closer to what Lightricks intended has not been established
here, and neither has whether the padded implementation is faithful.

## What is deliberately not here

**The BF16 comparison in `../` was not regenerated.** Both of its sides are
one-pass and differ only in the encoder, which is the whole point of it.
Re-rendering one side at twice the resolution would have replaced a controlled
comparison with a pretty one.

**Image-to-video cannot use the second pass yet.** `LTXVLatentUpsampler`
discards the noise mask, so a guide would have to be rebuilt at the new scale,
and nothing does that. The Space hides the control on that tab rather than
offering something that would fail.