Remap Image Range (Swwan)

What it's for

ComfyUI images are floats in 0–1. Some things - normal maps, certain depth and control signals, hand-rolled maths, anything derived from a signed quantity - want to live in -1 to 1 instead. Remap Image Range is the converter, and it's the smallest node in this batch: three widgets, one line of arithmetic.

It's KJNodes' RemapImageRange, kept under Swwan/Advanced/Image. Reach for it when a downstream node's expectations don't match what you've got, or when you've done maths on pixels and need the numbers back in a sane band before anyone looks at them.

How it works

The transformation is literally image = min + image * (max - min). Two independent things happen:

The remap. With min=0, max=1 (defaults) nothing changes. With min=-1, max=1 a 0–1 image becomes -1–1, and a -1–1 becomes -3–1 - the node doesn't detect what range you're starting from, it just applies the affine map. Which means you have to know your input range before you set these, and there's no preview that tells you.

The clamp. clamp defaults to true, and this is where people get stung. Read the source and you'll see the clamp call is torch.clamp(image, min=0.0, max=1.0) - hard-coded to 0–1, not to the min/max you just set. So remapping into -1–1 with clamping enabled crushes every negative value to 0, which is the exact opposite of what you asked for. If you want to produce a signed image, turn clamp off - and then be aware that values outside 0–1 will travel onward, which some downstream nodes tolerate and some clip silently.

Flip the flag's meaning in your head: it isn't "keep within the target range", it's "keep within the displayable range". That's a defensible design (it stops a stray bright pixel from poisoning a save), but it isn't what the label implies.

The node also promotes fp16 input to fp32 before doing the work, so you don't lose precision doing the multiply in half precision. Cheap, sensible, and the kind of detail that explains why this pack bothers to reimplement things.

Output is a single IMAGE.

Pairs well with

Images to RGB, from the same pack, does something related but not the same: it folds a dynamic range whose maximum exceeds 1 back down before an 8-bit conversion. The split is worth keeping straight - Remap Image Range is for going up or into the negatives; Images to RGB is for coming back down to something a saver can write. If you remap to -1–1, build your control signal, then want to look at it, fold it back with an explicit remap or a normalise node rather than hoping the preview does the right thing.

The other natural partner is the split/merge pair in the same category, since channel-wise maths with negative results is one of the main reasons you'd end up here.

Install

cd ComfyUI/custom_nodes
git clone https://github.com/aining2022/ComfyUI_Swwan
cd ComfyUI_Swwan
python -m pip install -r requirements.txt

Restart, hard-refresh the browser, search Swwan. Nothing but torch is involved: no OpenCV, no scipy, no model, no GPU requirement. It runs on CPU fine.

Common issues

My -1–1 image came out half black. clamp was on. Turn it off - the clamp bounds are 0–1 regardless of your settings.

Nothing changed. Defaults are 0 and 1, which is the identity map. You need to move min or max.

Values above 1 keep showing up downstream. That's clamp off and a remap with max > 1. Some nodes handle it, savers don't. Normalise before the output.

The image looks washed out after remapping to -1–1 and back. Two affine maps through 0–1 can lose headroom if anything clipped in between. Do the round trip once, on a copy, and check the max before you trust it.

Missing node in an old KJNodes workflow. Same contract, different ID (SwwanRemapImageRange) - the pack renames KJNodes overlaps rather than aliasing them, so run python scripts/migrate_workflow.py old.json --dry-run instead of renaming by hand.