ChronoEdit_SM_Latent

ChronoEdit doesn't edit your image the way img2img does. It treats the edit as a short film: the reference frame goes in, a sequence of "reasoning" frames plays out, and the edited result comes out the other end. ChronoEdit_SM_Latent is the front half of that trick - it turns your single image into the latent sequence the sampler needs, and wraps it in the conditioning socket the whole pipeline expects.

What it takes

• vae - a VAE socket. Use ChronoEdit_SM_LoadVAE or just a core VAELoader pointed at the Wan 2.1 VAE. Same VAE should decode on the other side, for sanity's sake.
• clip_vision - a CLIP_VISION socket, loaded from clip_vision_h.safetensors (the Wan CLIP vision H, from the Comfy-Org repackage the README links). This is what gives the model a visual "memory" of your image while it denoises.
• image - the reference you want edited.
• width / height - 0 means "figure it out." Set them and the node upscales your image to that size; leave at 0 and it computes a sensible multiple of 16 from the source. Keep them aligned with what your VAE and VRAM can chew - 720p edits on a 12GB card are already ambitious.
• num_frames - the combo 5 or 29, and this is the meaningful choice. 5 gives you a short, quick edit clip. 29 flips the whole pipeline into temporal reasoning mode: the sampler (see ChronoEdit_SM_KSampler) uses the extra frames to "reason" about the edit before committing, and you get a longer sequence out of the decode.

What it does to your image

Two parallel encodes. The VAE compresses the image into latents, which get padded with empty frames up to num_frames - that padding is what lets the sampler denoise an edit across time instead of pasting onto a still. Meanwhile the CLIP vision encoder produces penultimate_hidden_states as image embeddings, the token-level description of what's in the frame. Both get packed into a cond CONDITIONING dict along with the frame count.

One mechanical note: if the vae you wired in is a diffusers AutoencoderKLWan (the ChronoEdit_SM_LoadVAE route), the node encodes through the diffusers video processor and samples latents with argmax - the same path NVIDIA's own inference script uses. With a regular ComfyUI VAE it takes the core-encode route. Both work; just know the two routes are slightly different code paths, so if you switch VAE loading styles between runs, don't be startled if results shift a touch.

Wiring it up

cond goes to the KSampler's cond input - nothing else can sit there. The rest of the chain is standard: CLIPTextEncode gives the sampler its positive/negative prompts, the model + LoRA feed its model input, and whatever the sampler outputs flows to ChronoEdit_SM_Vae. Install follows the pack recipe (Manager: search ComfyUI_ChronoEdit_SM; or clone + pip install -r requirements.txt). Nothing extra to download for this node itself - the VAE and CLIP vision are already required by the README's model layout.