File size: 4,313 Bytes
132a3de 03b5f64 132a3de 03b5f64 132a3de 03b5f64 132a3de 03b5f64 132a3de 03b5f64 132a3de | 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 | # 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.
> **Historical preprocessing notice (2026-08-22):** every clip in this folder
> predates the current `gemma4-raw-intermediate-slots-v1` conditioning contract.
> The old path applied the encoder's learned final norm to all 49 hidden-state
> slots; the current path preserves raw intermediate slots and keeps only the
> model-returned final slot normalized. These clips therefore document the old
> runtime and must not be used as a current-runtime oracle.
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 an earlier Space runtime, not the workstation
All six came from
[the Space](https://huggingface.co/spaces/topabaem/LTX-2.5-Text-Encoder-4bit-8GB-Demo),
using this same 4-bit weight file on ZeroGPU before the conditioning correction.
The 15-second two-pass render took 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 did not follow its prompt; its cause is unresolved
`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 was not the second pass: re-running on the old Space at
`refine=0`, with the same seed, still gave the man and the tree. At the time this
was attributed to left padding because the Space padded to 1024 tokens and the
local comparison did not. That causal attribution is no longer valid: the old
Space path also applied the learned final norm to every hidden-state slot, while
the current contract preserves raw intermediate slots. Padding and hidden-state
normalization changed together, so these files cannot isolate either variable.
On this historical batch, the old padded path produced a better robot, dune, and
idol, while the old unpadded path found the forge. The defensible conclusion is
only that the two legacy preprocessing paths produced different samples. A
controlled rerender that changes one variable at a time—and a corrected-contract
BF16 oracle—would be needed to assign the cause.
## 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.
|