LTX-2 Joint Refresh Latent (Disk)
The same identity refresh, but with your start frames on disk
- refresh_image
- vae
- latent
- latent
- report
This is the disk-fed twin of IAMCCS_LTX2_JointRefreshLatent. Same job - re-anchor a latent's tail to a fresh reference image so the next segment keeps the subject consistent - except instead of taking the start frames as an IMAGE input, it reads them from a directory of frame files. If your long video pipeline is already writing per-segment frames to disk to keep RAM sane, this is the version you want: no need to round-trip a whole start-image batch through memory just to inject a few frames of it.
Everything else is shared with the in-memory version, by design. The mode enum (tail_then_source_refresh default, tail_only, source_refresh_after_tail), the overlap/strength dials, the tail_preprocess quality pass - identical semantics, and it's the same code path underneath, just swapping the IMAGE input for a directory.
How it works
The only real input swap is start_dir (default iamccs_extension_disk/start): a directory of sequential frame files the pack already writes for its low-RAM flows. The node loads the tail frames from there, VAE-encodes them, and injects them into the latent tail at tail_strength (default 0.9), then re-encodes refresh_image and splices it in just past the protected overlap at source_refresh_strength (default 0.25).
Both injections use the same noise-mask trick as the parent node: mask = 1.0 - strength, so strong injection = hard lock, weak = the model is allowed to vary. overlap_frames (default 9) is in pixel frames and converts to latent frames via the VAE's temporal downscale factor. tail_preprocess with its crf (default 28) gives the tail a light re-encode before it goes in, which helps it blend with the fresh reference instead of clashing.
Inputs and outputs
start_dir- where the start/tail frames live on disk.refresh_image,vae,latent- as in the in-memory version.mode,overlap_frames,tail_strength,source_refresh_strength,tail_preprocess,tail_preprocess_crf.
Outputs: latent (refreshed) and report.
Install
ComfyUI Manager → "IAMCCS", or:
cd ComfyUI/custom_nodes
git clone https://github.com/IAMCCS/IAMCCS-nodes.git
Restart. No extra dependencies; it just needs the directory convention your pipeline already uses.
Gotchas
Path discipline is the whole failure mode here. iamccs_extension_disk/start is relative to ComfyUI's working directory, so if the frames land elsewhere - or the node runs before whatever writes that directory - you get empty or stale tail injection and the refresh silently under-delivers. The report string names the injection stages; when the tail stage says zero frames, check the path first. Otherwise, same advice as the parent: keep source_refresh_strength low (0.25 default is a good start) or you'll trade identity drift for frozen motion.
Inputs (10)
| Name | Type | Default | Description |
|---|---|---|---|
| start_dir | STRING | iamccs_extension_disk/start | — |
| refresh_image | IMAGE | — | |
| vae | VAE | — | |
| latent | LATENT | — | |
| mode | COMBO | tail_then_source_refresh | 3 options: tail_then_source_refresh, tail_only, source_refresh_after_tail |
| overlap_frames | INT | 91–512 | — |
| tail_strength | FLOAT | 0.900–1 | — |
| source_refresh_strength | FLOAT | 0.250–1 | — |
| tail_preprocess | BOOLEAN | true | — |
| tail_preprocess_crf | INT | 280–100 | — |
Outputs (2)
| Name | Type | Description |
|---|---|---|
| latent | LATENT | — |
| report | STRING | — |