sizing for SDXL (int/float inputs)

The other sizing nodes in Ser-Hilary/SDXL_sizing take their numbers as strings you type - "1024", "16:9", "800x1200". That's lovely until you want the value to come from another node, and a string widget can't take a wire. sizing_node_unparsed ("sizing for SDXL (int/float inputs)") is the same engine with every input as a typed INT or FLOAT, and the author built it specifically for img2img. It's the one you reach for when your dimensions aren't something you type but something you measure.

How it works

Under the hood it's doing almost nothing different: it assembles the values you give it into the same string inputs the other nodes parse, then calls the exact same sizing routine. Same bucket math, same six conditioning outputs, same downscale output. What changes is how much the node is willing to figure out for you - here's where the -1 game comes in.

The inputs that matter

• gen_size_w / gen_size_h - your generation size. Set both to your input image's dimensions and they override native_res (as long as their area is at least 0.9 × native²; below that it assumes you're doing something small and keeps the native resolution). Leave at -1 to skip.
• native_res - plain INT, default 1024.
• aspect - a FLOAT (0.5, 1.78, whatever). -1 means "figure it out": from the gen sizes if both are set, otherwise from the original sizes.
• original_res_w / original_res_h - the hypothetical "original" training image. -1 on one of them derives it from the other plus the aspect; -1 on both falls back to the gen size. Yes, the word "original" gets fuzzy in img2img - the author says so himself. It means the theoretical training image, not your source picture.
• crop_extra and downscale_effect - same as the advanced string node; default both to 0 unless you specifically want extra cropping or downscaling.
• The optional set carries over: verbose, fit_aspect_to_bucket, strict_bucketing (note: no "Smallest Buckets" option here, just SDXL Report / Comfy / disabled), and extra_args with the same --sharp, --nocrop, --randomaspect toys.

Why you'd actually use it

Two reasons. First, img2img: the pack ships an example_img2img_workflow.json that wires get_aspect_from_image into this node, so your loaded image's real dimensions drive the gen size and aspect, and the conditioning matches the actual pixels instead of a guess. Second, any workflow where a resolution is computed upstream - a crop node, a ControlNet, a preprocessor - and needs to flow in as a number.

Install and gotchas

The pack install is the usual: ComfyUI Manager → search SDXL_sizing, or git clone https://github.com/Ser-Hilary/SDXL_sizing into ComfyUI/custom_nodes, then restart. No dependencies, no model files.

Two things bite people. The -1 rules read like a logic puzzle until you internalize that -1 just means "derive me from whatever you have" - and they're order-dependent, so a -1 on a field you thought you set will silently derive instead of error. And the 0.9×native² gen-size guard: if you feed it a 512x512 input for a 1024-native model, it treats that as below-threshold and keeps 1024 as native. That's intentional, not a bug - but it will surprise you the first time it does it.