Mpi Wrap Crop

You padded your pano with MpiWrapPad, ran it through an upscaler or a refiner, and now you need the pad gone. Here's the thing that catches people: the image isn't the size it was. A 2x upscale turned your 128-column pad into 256 columns, and cropping a fixed 128 off each side would eat into the picture.

MpiWrapCrop solves the only hard part of that - knowing how big the pad is now - which is why it wants the image as it was before the pad.

How it works

You give it the padded image at whatever scale it currently is, the original pre-pad image as reference, and the pad you fed to MpiWrapPad. It computes the pad in the current image's own pixels:

p = round(pad × padded_width / (reference_width + 2 × pad))

That's it: the padded source was reference_width + 2×pad wide, so the fraction of the current width that the pad occupies is a straight proportion. Then it crops p columns off each side and hands you the image back.

Inputs and outputs

• image - a wrap-padded image, resized or not since. Refined, upscaled, whatever.
• reference - the image as it was before Mpi Wrap Pad. This is what makes the scale maths work.
• pad - the pad you used, default 32, range 0–2048.

One output: IMAGE.

Installing it

cd ComfyUI/custom_nodes
git clone https://github.com/MadPonyInteractive/ComfyUi-MpiNodes
# restart ComfyUI

No models, no weights. It's four lines of tensor slicing once the pad has been scaled, and it goes in the pack's MpiNodes/Scene category next to the other 360 helpers. The pack has no requirements.txt - it borrows numpy, scipy, opencv and torch from the environment ComfyUI already has.

Crop or Cut Merge?

There are two ways to undo the pad and they are not interchangeable.

MpiWrapCrop is the honest one: cut the columns off and keep what the model gave you. Use it when the padding did what it was supposed to - the refiner or upscaler produced a consistent image, and the left edge now continues smoothly into the right edge because it could see them as neighbours.

MpiWrapCutMerge is for when the model rendered the strip twice - once as the right pad, once in place at the left edge - and the two renders don't agree pixel for pixel despite being the same content. A plain crop there will show you the disagreement at the join. CutMerge joins the two renders along a hidden min-cost cut so neither shows.

If you're unsure which you have: crop first and look at the seam. If you can see a line, you wanted CutMerge.

Where people get burned

Reference means reference. Point it at a version of the image that's been cropped, resized, or generated differently and the width proportion is wrong, and you cut the wrong number of columns. Feed the actual pre-pad tensor - a reroute off the node that went into MpiWrapPad.

A small pad after a big downscale rounds to nothing. 32 columns on a 2x upscale is 64; on a 4x downscale it's 4; downscale hard enough and p rounds to 0 and the node returns the image unchanged. That's the implementation's graceful behaviour, not a crash - but it does mean a silently-uncropped image is possible if your pipeline shrinks instead of growing. It's the scaled crop you want afterwards, and if the pad rounds away, the seam you were protecting is sub-pixel anyway.

Pad 0 is a no-op, in case you're debugging and wondering why nothing changed.

It only knows width. The crop is horizontal, because the pad is horizontal - don't expect it to fix a vertical tiling seam.