Quick Resolution Multiply (WLSH)

This node does one small thing and does it to save you from a specific, recurring annoyance: SDXL's conditioning setup wants both your actual generation size (width/height) and a separate target_width/target_height that's often meant to be some multiple of it - and if you ever change your base resolution, you have to remember to update both numbers, by hand, everywhere they're used. This node just does the multiplication for you and keeps the two in sync.

How it works. Feed it width and height (whatever your actual generation resolution is) and a multiplier (default 2), and it outputs width and height multiplied by that factor. That's the entire node - no image processing, no model involvement, just integer math. The README calls out the exact use case it was built for: SDXL's height (your real generation size) versus target_height (the conditioning target) - feed your real resolution into this node once, wire its output straight into the target_width/target_height fields of a node like this pack's own CLIP Positive-Negative XL (WLSH) or core's CLIPTextEncodeSDXL, and now if you ever change your base resolution upstream, the target numbers follow automatically instead of silently going stale.

Inputs: width and height (both default 512, range 16-8192), multiplier (default 2, up to 10000 - though realistically you'll be using something between 1 and 3 for this specific job). Outputs: width and height, multiplied. Wire the same source width/height into this node that you're feeding your actual conditioning node, so the two never drift apart.

Installing it

ComfyUI Manager: search "wlsh_nodes" or "WLSH Nodes", install, restart. Manual: cd ComfyUI/custom_nodes && git clone https://github.com/wallish77/wlsh_nodes, then restart ComfyUI. Nothing to download beyond the node code itself.

Common issues

There isn't much that goes wrong with a multiplication node, so the real trap is upstream of it: people wire this node's output into target_width/target_height but forget that the input side still needs to match their actual generation size, so if you resize your base latent without also updating what feeds this node, you're back to a stale mismatch - just one step removed instead of two. Beyond that, watch the multiplier range if you're using this for anything other than the target-size trick; a multiplier that pushes width or height past 8192 will get clamped or rejected by whatever conditioning node you're feeding it into, since SDXL's own fields cap there too.