ToonComposer SLRA Sequential Wrapper

If you've ever wished Tencent's ToonComposer - the research pipeline that turns rough sketch keyframes into colored, in-betweened cartoon animation - worked inside ComfyUI, you're not alone. Someone on r/StableDiffusion literally asked for a port and got upvotes for it. This node is somebody's answer to that request. It's just not a finished one.

Set your expectations now: this pack contains a single node, the README is a title and nothing else, and the repo was built by an AI agent (its AGENTS.md is a Spanish-language "project context for AI agents" with strict development rules). The name "SLRA Sequential Wrapper" makes more sense when you know the original: ToonComposer's method adapts a video diffusion model segment by segment - sequential low-rank adaptation - and the official demo wants ~57GB of VRAM for a 61-frame 480p clip. This node's entire pitch is doing that in chunks on a 24GB card with a 14B video model in fp8. That's the dream. Read the shipped code before you trust it.

What the wrapper actually does

Feed it a model, a latent, an image, a sequential_state dict, and the path to an "SLRA" .safetensors file, and here's the honest breakdown of what happens:

• It reads index and count out of sequential_state - the standard KJNodes loop bookkeeping - and computes frame boundaries as 4n + 1 chunks (17, 33, 65…), the temporal-latent convention used by LTX-family video DiTs. Then it prints those numbers and never slices anything. The chunking is logging, not logic.
• It clones the model so your base isn't mutated.
• It loads the SLRA file from your models/loras folder and casts every tensor with down, up, or slra in its key to float8_e4m3fn, then add_patches them into the clone. In ComfyUI that's a diff patch: each tensor is added to the matching model weight at full strength (no rank, no alpha, no scaling). Keys that don't match the model's state dict are dropped silently.
• It moves the image to the GPU as fp8 and hangs it on the model as tooncomposer_sparse_sketches. Nothing in the shipped code ever reads that attribute - the comment even admits the sketch injection is "typically" where the real work would go. The image input is decorative.
• It returns the patched model and the exact same latent you gave it. Pass-through, untouched.

So the part that genuinely works is a specific one: it hot-loads a delta-weight file into your video model per loop iteration, in fp8, without touching the original. Everything that would make it "ToonComposer" - sketch conditioning, frame chunking, the inbetweening - is scaffolding waiting for a real implementation.

The inputs that matter

You only really set two things:

• slra_name - a dropdown populated from your models/loras folder. You supply the file; the pack downloads nothing.
• chunk_size - default 17, clamped to the 4n+1 pattern. Affects the (printed) slice boundaries and, presumably, how much the eventual real version fits in VRAM.

model, latent, and image are your normal video-model plumbing; sequential_state is a DICT from a KJNodes-style loop. Outputs: a MODEL (your patched clone) and a LATENT (your input, unchanged) - wire the model into your sampler.

Installing it

No dependencies beyond base ComfyUI (requirements.txt is empty of anything ComfyUI doesn't already ship), so it's boring and safe:

cd ComfyUI/custom_nodes
git clone https://github.com/Meisoftcoltd/comfyui-ToonComposer
# restart ComfyUI

Or search comfyui-ToonComposer in ComfyUI Manager and let it handle the clone. The one heavy lift is model files: the actual ToonComposer weights live on HuggingFace as full checkpoints, not a ready-made LoRA - expect to dig for (or build) an SLRA-format delta file before the dropdown shows anything useful.

Where it will bite you

The dropdown is empty until a .safetensors lands in models/loras - refresh after dropping one in. If your file's keys don't contain down/up/slra or don't match the model, you get a silent no-op: no error, no effect, and the model and latent just flow through. And because the fp8 cast is a raw rounding to a 3-bit-mantissa format before the add, quality loss is real on non-40-series cards that compute in higher precision anyway. Treat this as an experiment to read, not a production tool - it's the skeleton of a great idea, with the organs still on order.