SP_FluxUnsampler

Ordinary img2img has a ceiling: push the denoise strength up far enough to actually change the image under a new prompt, and it stops looking like the image you started with. Unsampling is the community's answer to that - instead of adding random noise and denoising once, you run the diffusion process forward along a controlled path back toward noise, then forward again under a new prompt, and the result tracks the source image's composition far better than a plain low-denoise pass while still following the new prompt. People who've compared the two describe exactly this trade-off: a naive unsampling attempt could regenerate the source image but struggled to change anything beyond that, while a more controlled version - the kind of technique this pack's own SP_FluxUnsampler_ForwardODESampler node configures - held prompt adherence while keeping composition like a ControlNet and style like an IPAdapter, without needing either.

SP_FluxUnsampler is that whole pipeline packaged as a single node - it lives in the pack's Group Nodes category, ComfyUI's mechanism for collapsing a working multi-node sub-graph into one reusable box, so this saves you from wiring up the unsample pass, the forward resample pass, the scheduler, and the VAE decode by hand every time.

How it works

You feed it your Flux MODEL/CLIP/VAE, the source image, and the flux_unsampler_sampler config from the ForwardODESampler node. Two separate prompts matter here: positive_unsampler describes the image you're feeding in - it steers the inversion pass so the reconstruction stays accurate - and positive is the new prompt you actually want the output to follow. Everything else (steps, guidance, max_shift, base_shift, scheduler) is standard Flux sampling territory: 28 steps and guidance 3.5 match Flux's usual defaults, and max_shift/base_shift tune the same flow-matching schedule shift most Flux workflows expose.

Inputs and outputs

• model, clip, vae, image - your Flux checkpoint pieces and the source image.
• flux_unsampler_sampler - from SP_FluxUnsampler_ForwardODESampler.
• positive_unsampler (STRING, multiline) - describes the source image, for the inversion pass.
• positive (STRING, multiline) - the target prompt for the forward pass.
• steps (default 28), guidance (default 3.5) - standard Flux sampling settings.
• max_shift (default 1.15), base_shift (default 0.5) - flow-matching schedule shift.
• scheduler (enum, default simple; also sgm_uniform, karras, exponential, ddim_uniform, beta, normal, linear_quadratic, kl_optimal).
• tile_size (default 0, up to 2048) - tiled VAE decode; 0 presumably means untiled.
• vae_decode (default true) - whether to decode straight to an image or leave it at latent.
• preview (default true) - whether to show a preview during the run.
• Outputs: LATENT and IMAGE.

Installing it

ComfyUI Manager: search "SP-Nodes", install, restart. Manually:

cd ComfyUI/custom_nodes
git clone https://github.com/bananasss00/ComfyUI-SP-Nodes

then restart ComfyUI. No models to download for the node itself, but it needs a Flux checkpoint - Dev is the realistic choice, since Schnell's minimal step count and lack of a real guidance scale don't suit a technique built around a controlled multi-step inversion pass.

Common issues & troubleshooting

The output barely resembles the target prompt. Check positive_unsampler actually describes the source image rather than being left blank or copied from positive - a mismatched inversion prompt undermines the whole technique.

The output ignores the source entirely. That's the opposite failure, usually traceable back to the ForwardODESampler's eta/gamma/step-window settings rather than anything here - see that node's own troubleshooting if composition isn't holding.

Out of VRAM on larger images. That's what tile_size is for - a nonzero value tiles the VAE decode instead of doing it in one pass, which matters more on Flux's larger latents than it did on SDXL.

It's slow. Unsampling runs two full passes through the model instead of one (unsample, then resample) - that's the mechanism, not a bug. If speed matters more than fidelity to the source, plain img2img at a moderate denoise is still the faster option; this node is for when you've already tried that and it wasn't good enough.