Fix Dimensions (Div by 16)

Does exactly what the name says: takes a width and a height, and rounds each one to a multiple of 16.

Why this is worth having in your graph at all. Modern video and latent-diffusion models don't accept arbitrary pixel dimensions - they downsample internally by some fixed factor, and if your resolution isn't a clean multiple of that factor, you get a hard failure or a silent, ugly resize rather than a helpful warning. This isn't a hypothetical: LTX-2.3 requires width and height divisible by 32 and fails outright on off-grid values rather than rounding for you, and other architectures land on 8 or 16 depending on how aggressively they compress. Feeding a sampler a resolution it wasn't built to accept is a genuinely common way to lose ten minutes to a cryptic error, and a tiny node that snaps your numbers to a safe grid before they ever reach the model is cheap insurance - there's not much reason not to drop it in front of anything that cares about this.

Inputs and outputs. width and height, both integers, default 512, range 64–8192 in steps of 1. The outputs are width and height again - the rounded values, ready to feed straight into whatever needed clean numbers in the first place.

One limit worth being upfront about: there's no tooltip, no description, and critically no parameter for choosing which multiple to round to. The title - "div by 16" - is the actual contract here, not a suggestion. If your target model needs a different grid (32, for LTX-2.3, for instance), this node's output may still land on the wrong multiple for that model even though it did exactly what it says on the tin.

There's also nothing in the schema saying which direction it rounds - up to the next multiple of 16, down to the previous one, or to whichever is nearest. For most workflows the difference is trivial (you're talking about a handful of pixels either way), but if you're chaining this ahead of something that needs an exact canvas size rather than "close enough," it's worth running a quick test with an odd number and checking the output yourself rather than assuming a particular rounding direction.

Installing it. Ships inside comfyui-sortlist. Search comfyui-huyl2-nodes in ComfyUI Manager, or clone directly:

cd ComfyUI/custom_nodes
git clone https://github.com/huyl3-cpu/comfyui-sortlist

Restart ComfyUI.

Troubleshooting. If a downstream sampler still complains about dimensions even after running through this node, the multiple mismatch above is the first thing to check - 16 satisfies plenty of architectures but not all of them, and a model that specifically wants 32 will still reject a number that's merely divisible by 16 (every multiple of 32 is a multiple of 16, but not the reverse). Confirm what your specific model actually requires before assuming this node is doing something wrong.