Get Image Size & Count (Swwan)
The node that tells you what you actually have
- image
- image
- width
- height
- count
A probe that doesn't break the wire
Every workflow eventually asks the same two questions: how big is this image and how many frames are in this batch? Both answers exist in the tensor, and neither is visible in the graph. This node exposes them as integers and passes the image straight through unchanged, so you can drop it inline anywhere - between a loader and a sampler, mid-chain, wherever - and lose nothing.
It's KJNodes' GetImageSizeAndCount, re-registered by the Swwan pack. And it's a plumbing node in the truest sense: it does no work, produces no pixels, and quietly prevents the class of bug where someone hardcodes 1216 and later swaps the loader.
What it gives you
Input: image - required, nothing else. There are no widgets to set, which is the point.
Outputs, in order:
image- the same batch, untouched. This is your pass-through, and it's why the node can sit in the middle of a chain instead of dangling off the end.widthandheight- pixel dimensions from the tensor's shape.count- the batch size, i.e. the number of images.
It also prints a summary straight onto the node in the UI, formatted as count x width x height. So even if you never wire the outputs anywhere, the node is a free readout - genuinely the fastest sanity check in ComfyUI when a workflow is producing something weird and you suspect the resize happened twice.
What you do with the numbers
The obvious one is driving size-dependent logic: feed width/height into a maths node to compute an aspect-correct resize, an upscale factor, or a latent size, and the graph follows the input instead of fighting it. The batch count is the other half - it's how you branch on "did the video model give me 1 frame or 81?", and it's what you check before slicing with Get Image Range From Batch, whose out-of-range error is much less informative than reading a number.
Numbers like these are also the honest way to wire conditional graphs. Compare count against a threshold, and you can route a single image down one path and a batch down another without anyone typing a magic number into a router.
Install
cd ComfyUI/custom_nodes
git clone https://github.com/aining2022/ComfyUI_Swwan
cd ComfyUI_Swwan
python -m pip install -r requirements.txt
Manager → ComfyUI Swwan, then restart ComfyUI and hard-refresh the browser. No models, no optional dependencies - it's reading image.shape, which costs nothing and cannot fail on a valid IMAGE.
Two things worth internalising
Width/height/count are batch-aware and shape-aware, not semantic. The order is [batch, height, width, channels] in ComfyUI's IMAGE convention, and the node reads shape[0], shape[1], shape[2] accordingly - so on a 1024×1536 portrait image you get width = 1024, height = 1536. If your downstream maths comes out swapped, you assumed the other convention.
Pass-through means the node is invisible to quality but not to caching. It's pure introspection, so it can't degrade anything. But it also means the node will not magically re-trigger a stale part of the graph - if you're debugging a size problem, remember that everything upstream of it is just as cached as it was.
One practical pairing: this node plus the pack's seed and maths nodes is the standard way to build "resize whatever comes in to a fixed megapixel budget" without ever looking at the image. Read the dimensions, compute the target, resize. That's a graph that survives you swapping a 512px SD1.5 test image for a 4K render at 2am, which is exactly when hardcoded sizes hurt most.
Inputs (1)
| Name | Type | Default | Description |
|---|---|---|---|
| image | IMAGE | — |
Outputs (4)
| Name | Type | Description |
|---|---|---|
| image | IMAGE | — |
| width | INT | — |
| height | INT | — |
| count | INT | — |