Empty Latent by Ratio (WLSH)

Where Empty Latent by Pixels (WLSH) sizes things by total megapixel budget, this one sizes by the length of the shorter side - pick an aspect ratio, pick landscape or portrait, tell it how long you want the shorter edge to be, and it computes width and height from there and builds the latent to match. Same underlying idea as the pack's Image Scale by Shortside node, just applied to generating an empty latent instead of resizing an existing image.

This is the more natural way to think about resolution if you're used to SD 1.5-era conventions, where "512" was the native short-side number everyone built workflows around, or if you're working with a model whose sweet spot is expressed as a minimum edge length rather than a fixed pixel-count target. Set shortside to 512 for SD 1.5-style generation, bump it to 1024 for SDXL-scale work, or dial it to whatever your specific checkpoint's documented native resolution actually is - the node handles the aspect-ratio math so you don't have to work out the long-edge number by hand every time you change ratios.

Inputs: aspect is a 13-option enum - square through wide ratios, from 1:1 up through options like 3:1 and beyond, covering essentially every common framing choice. direction toggles landscape or portrait, swapping which dimension the shortside constraint applies to. shortside is an INT, 64 to 8192 in steps of 64, default 512 - the target length for whichever side ends up shorter. batch_size (1–64, default 1) sets how many latents come out of this one node.

Outputs, three of them: latent is the empty LATENT tensor, ready for your sampler's latent_image input. width and height come back as INTs too, computed from the ratio and shortside value - useful for wiring into anything downstream that needs the actual numbers, a filename string or an SDXL target-size field among the common cases.

Installing it: ComfyUI Manager, search "wlsh_nodes"; or manually:

cd ComfyUI/custom_nodes
git clone https://github.com/wallish77/wlsh_nodes

Restart ComfyUI. No models or extra dependencies - pure arithmetic plus latent construction.

Things worth knowing before you lean on this heavily. Because the constraint is on the shorter side, two different aspect ratios at the same shortside value will produce very different total pixel counts - a 1:1 at shortside 512 is a 512×512 image, but a 3:1 at the same shortside setting is a much bigger 1536×512 image. That's the intended behavior, but it means batch size and VRAM usage aren't predictable purely from the shortside number alone if you're switching ratios inside the same session. And as with any resolution-generating node, the numbers it hands you are only as good as your model's actual training range - a shortside of 512 makes sense on SD 1.5, but forcing that same value on an SDXL checkpoint will generate at a resolution well below what the model was trained on and can produce visibly softer, less detailed results than sticking to SDXL's own native sizes.