NS Refiner Schedule

NS Refiner Schedule is the "make it move" version of the pack's refiner conditioning tools. Where NS-RefinerGuidanceScale applies one fixed scale to the refiner's bigG conditioning, this node sweeps that scale over time - starting the refiner's influence at one strength and easing it to another as sampling progresses. For the small crowd still running an SDXL base → refiner pipeline, it's the difference between a static detail pass and one that fades in (or out) the way you actually want.

Why would you care about a schedule instead of a static number? The standard refiner complaint is that it can over-polish: cranked too hard it smooths skin into plastic, and it does that damage at the very end of the run where it's most visible. A schedule lets you run the refiner strong early in its stage and back off as it finishes, or start gentle and build. That's real control you can't get from a fixed scale.

How it works

The mechanism is worth understanding because it's elegant and it's how ComfyUI schedules conditioning at all. The node takes your refiner conditioning and, instead of returning one entry, returns segments separate conditioning entries (default 3, up to 20). Each entry:

1. Covers a slice of the sampling range - e.g. with defaults it spans 80%→100% of the run, split into three chunks.
2. Has the bigG component scaled by the interpolated value of start_scale_G → end_scale_G at that point in the schedule.
3. Carries start_percent/end_percent keys so the sampler knows exactly which timesteps to apply it to.

The sampler does the rest: it picks the right conditioning for each step, so you get a smooth ramp instead of a hard switch. The defaults tell you the intended use - start_scale_G 1.2 down to end_scale_G 0.8, over the 0.8→1.0 range, which matches how the refiner usually attaches to a run (the schedule_start tooltip literally says "Refinerは通常0.8から" - "refiner usually starts at 0.8").

The inputs that matter

• conditioning - your refiner conditioning, typically from NS-RefinerTextEncode.
• start_scale_G / end_scale_G - both 0.1–2.0. Start high → end low (the default) eases the refiner off as it finishes; flip it to fade the refiner in.
• schedule_start / schedule_end - 0–1, the portion of the run the schedule spans. 0.8→1.0 is the classic refiner window.
• segments - how many chunks the range is cut into. More segments = smoother ramp, slightly more conditioning entries flowing through the graph.
• interpolation - linear or cosine. Cosine eases the ends of the ramp; linear is a straight line between the two scales.
• normalize - same disable/enable toggle as the other guidance nodes; enable if you want to change only the ratio, not the overall magnitude.

Output is a CONDITIONING (multi-segment) that wires into the refiner KSampler's positive input. It does not touch the model or the sampler itself - it's pure conditioning surgery.

Gotchas

If schedule_start >= schedule_end, the node silently returns your conditioning unchanged. Easy to do if you type 1.0 and 0.8 in the wrong order, and you'll get a no-op with no error. Also note this is a refiner tool: it scales the 1280-dim bigG vector. For the base model's dual-encoder conditioning, the pack has the analogous NS-DualEncoderSchedule.

Installing it

One node in ComfyUI-NS-Util. ComfyUI Manager → Install via Git URL:

https://github.com/NakamuraShippo/ComfyUI-NS-Util

or clone into ComfyUI/custom_nodes and restart. No model downloads, dependencies are the pack's light trio (pyyaml, watchdog, opencv-python). If your workflow already runs a refiner, you've got everything else this needs.

The honest take

This is a niche node for a niche pipeline - if you've moved off the SDXL refiner, it's irrelevant. But it's a well-made niche node: the segment-splitting approach is the idiomatic ComfyUI way to do time-varying conditioning, and the defaults encode real knowledge about where a refiner should sit. Tune start_scale_G/end_scale_G, leave the range at 0.8→1.0, and you get a refiner that behaves the way it should have out of the box.