USDU Tile Calculator

Six numbers, one tiny node, better tiles

Ultimate SD Upscale wants a tile width, tile height, padding and mask blur. The defaults are 512/512/32/8, which are fine for a square image and increasingly wrong the further your aspect ratio is from square. On a 896×1472 portrait with 512-pixel tiles you get a grid that doesn't divide evenly, one column of skinny tiles down the side, and a seam pattern that follows it. Everybody has hand-tuned their way out of this.

The Tile Calculator does the arithmetic: give it the image's aspect ratio and your upscale factor, and it hands back tile dimensions that land close to an even split of the target canvas with as few tiles as it can manage. It also passes through the two Ultimate SD Upscale+ additions - tile_skip_threshold and highpass_noise_strength - so wiring one node fills six sockets at once.

This is a plumbing node and I like it for that. It removes a whole class of "why does my upscale have a vertical line at x=1500" questions, and it's the kind of thing you should build into the workflow once rather than re-derive per image.

How it works

The maths, from the source: it computes the upscaled canvas from the source size times upscale_by, takes the aspect ratio, and picks a grid count as nx = round(sqrt(K × aspect)), ny = round(K / nx). So tile_factor behaves like "about this many tiles", reshaped to your aspect. Tile size is the canvas divided by that grid, floored to a multiple of 64 - which is the multiple USDU wants. Padding is roughly 15% of the tile width, snapped to a multiple of 8 and clamped to sane bounds. Mask blur comes out at half the padding's unit count, so blur and padding stay proportional.

The upshot: tiles that tile your image, not tiles that tile a square. The idea for the tile formula is credited to a ComfyUI workflow write-up by nobin - the node is the author's implementation of somebody else's arithmetic, which is a nice, honest thing to put in a docstring.

Inputs and outputs

• tile_factor (default 4, suggested 4–6) - the target number of tiles. Lower means bigger tiles and fewer of them: faster, more VRAM per tile, and more of each tile decided by the model rather than by the source. On a small card you'll want to go down, not up, and let tile_width come out larger only as far as VRAM allows. On 8GB, factor 4 at 2x from a ~1280 base is usually comfortable.
• upscale_by (2.0) - must match the upscale_by you put on the USDU+ node. These two aren't linked; if they disagree, the tiles are sized for a canvas that doesn't exist.
• image (optional socket) - connect the image you're about to upscale and the size is read from it. Do this; the width/height fallbacks (896×1472) will otherwise silently assume someone else's resolution.
• tile_skip_threshold (1.0) / highpass_noise_strength (0.6) - echoed straight to the matching USDU+ inputs. Note the defaults differ from USDU+'s own: on the USDU+ node these are 0 (off); here they default to on. That's the author's intent - connecting the calculator is opting into both features.

Six outputs: tile_width, tile_height, tile_padding, mask_blur, tile_skip_threshold, highpass_noise_strength. Drag each to the identically-named input on Ultimate SD Upscale+.

Install

cd ComfyUI/custom_nodes
git clone https://github.com/nyanmi-1828/ComfyUI-WeightFerry

Manager → WeightFerry → install → restart is the other route. No dependencies, no models. NVIDIA and ComfyUI 0.38.0+ for the pack; this node itself just does arithmetic and would work anywhere.

Where it goes wrong

Mismatched upscale_by. The calculator sizes tiles for source × upscale_by, and USDU+ builds its canvas from its own upscale_by. Two different numbers, two different grids. Set both, or drive both from the same place.

Overriding the computed values afterwards. If you connect tile_width and then also type a number into the field, the connection wins - but people regularly connect three of the six outputs and hand-edit the rest. That's how you end up with a 15% padding rule applied to a tile size the node didn't choose.

Turning tile_factor up to get more detail. It doesn't work that way. More, smaller tiles means less context per tile - each redraw sees a smaller neighbourhood and is more likely to invent something that doesn't match its neighbour, which is exactly the tile-divergence artifact people blame on denoise. Bigger tiles with more padding are usually better-looking if you have the VRAM.

Not checking the console. The node logs the grid it chose - canvas size, tile size, padding, blur, rows × columns. That line is the fastest way to tell whether you asked for something absurd, like a 4×12 grid of 64-pixel tiles on a 2x upscale. If the numbers look wrong, they are; nothing downstream will fix them.

Forgetting the fallback dims exist. Leave image unconnected and dial the wrong width/height and every number downstream is wrong in a way that still generates an image. Wire the image. It costs one link.