WanLightx2vSchedulerBasic
The node that fixes Wan 2.2's burnt-out lightx2v look
- SIGMAS
Your Wan 2.2 clips with the lightx2v LoRA come out looking like someone grabbed the contrast slider and yanked it - blown-out highlights, edges that look oversharpened, lighting that snaps between frames instead of flowing. That's not your CFG being too high. That's the LoRA getting fed a denoising trajectory it was never trained on. WanLightx2vSchedulerBasic exists to fix exactly that, and it's the node in this pack you'll actually keep.
Why the burnt-out look happens
Lightx2v is a step-distillation LoRA - Kijai's extraction of the LightX2V framework's distilled Wan 2.2 weights. Distilled models are trained on a specific noise schedule, and lightx2v's LoRAs were distilled at 4 steps on the timestep trajectory [1000, 937.5, 833.3, 625, 0]. ComfyUI's built-in samplers pick their own sigma spacing for whatever step count you choose, and that spacing almost never matches what the LoRA saw in training. At 8, 16, or 20 steps you're asking it to denoise at noise levels it's never seen, and the artifacts are exactly the burnt-out, over-sharp, flickering mess everyone complains about. The fix, which went around r/comfyui in mid-2025 and is the whole reason this pack exists: hand the LoRA the noise curve it was trained on, at any step count, via custom sigmas.
How it works
The node computes sigmas on the fly from the same shift formula the lightx2v developers derived: t_shift = shift * t / (1 + (shift - 1) * t), applied over steps evenly spaced values of t from 1.0 down to 0.0, then scaled between sigma_max and sigma_min. A shift of 5.0 recreates the training curve's shape; the result is a descending schedule from 1.0 to 0.0 that keeps the noise levels in the range the LoRA actually knows.
Only four inputs, and the defaults are already what you want:
- steps - your total sampling steps. 4 is the "native" count, but the whole point is that 8, 16, and 20 work too. The README suggests those four values.
- sigma_max / sigma_min - use 1.0 and 0.0 for theoretical accuracy. That's the recommendation, not an option.
- shift - 5.0 for lightx2v. This is the parameter that matters; straying from it is how you reintroduce the artifacts.
The single SIGMAS output feeds straight into KSamplerAdvancedPartialSigmas from the same pack, or any node that accepts a sigmas tensor - the standard KSampler won't take one, which is why the pack ships its own sampler.
Install
No dependencies, no model downloads, nothing to babysit. Either search "Wan2.2 Lightx2v Scheduler" in ComfyUI Manager, or:
cd ComfyUI/custom_nodes/
git clone https://github.com/opparco/ComfyUI-WanLightx2vScheduler
Then restart ComfyUI. There's no requirements.txt - it's a handful of nodes using ComfyUI's own sampling internals. The lightx2v LoRAs themselves you still grab separately from Kijai's HuggingFace repo (Kijai/WanVideo_comfy, the LoRAs/Wan22_Lightx2v folder).
Gotchas
- It prints every generated schedule to the console (
SIGMAS: tensor(...)). Harmless, just noisy. - With lightx2v, CFG must be 1.0. The sampler in this pack defaults to that, but if you're wiring sigmas into another setup, don't forget.
- If you're not using lightx2v, this node buys you nothing. It's a targeted fix for a specific distilled LoRA, not a general-purpose scheduler - and that's fine, it's the right tool for one job.
Inputs (4)
| Name | Type | Default | Description |
|---|---|---|---|
| steps | INT | 41–10000 | — |
| sigma_max | FLOAT | 1.000–5000 | — |
| sigma_min | FLOAT | 0.000–5000 | — |
| shift | FLOAT | 5.00.1–100 | — |
Outputs (1)
| Name | Type | Description |
|---|---|---|
| SIGMAS | SIGMAS | — |