ImpactImageInfo

ImpactImageInfo tells you the shape of an image. Feed it any IMAGE and it spits out four numbers: how many images are in the batch, the height, the width, and the channel count. No processing, no model, no cost - it just reads the tensor's dimensions and reports them as integers you can wire elsewhere.

That sounds trivial, and it is, but it's the kind of trivial that unblocks real workflows. ComfyUI images are tensors, and a surprising number of nodes want to know a dimension of the image you're already holding - a downstream resize that should match the source width, a crop that needs the current height, a latent you're about to create at the same size, a loop that should behave differently on a batch of 8 than on a single frame. Rather than hardcoding "1024" and hoping the input matches, you read the real value off the image and pass it along. When the input changes, the number follows automatically.

The four outputs

The single input is value, an IMAGE. The outputs, all plain INTs:

• batch - how many images are stacked in this batch. 1 for a single image, higher if you're processing several at once.
• height - pixel height.
• width - pixel width.
• channel - number of color channels. Usually 3 (RGB); 4 if there's an alpha channel.

You wire any of these into any integer socket downstream - a width or height field you've converted to an input, a math node, a comparison, a resize target. The batch output is the quietly useful one for anyone building Impact Pack's experimental loops: it lets a workflow branch on how many images it's actually handling.

When to reach for it

The honest answer is: when a node downstream needs a dimension of an image you don't want to type by hand. That's it. It's a small piece of plumbing that keeps a graph adaptive - it makes width, height, and batch size flow from the actual image instead of from a constant you have to remember to update. If you're building anything that should work across different input sizes, reading the real dimensions beats assuming them.

It lives in Impact Pack's Logic category (in the experimental _for_test corner) alongside the counter and comparison nodes, which is a hint about its intended company: it's a source of numbers for logic and loops, not an image-processing node. But there's nothing stopping you using it in a plain linear workflow whenever you need to know how big something is.

Gotchas

Genuinely almost none. It doesn't touch the GPU in any meaningful way, doesn't need a model, and can't really fail if you feed it an actual image. The one thing to keep straight is which output is which - it's easy to grab height when you wanted width, since they're adjacent and both just say INT downstream. Double-check the socket name when a resize comes out sideways.

The other mild "gotcha" is expectation: some people go looking for extra metadata - bit depth, format, EXIF, the seed that made it. This node doesn't carry any of that. ComfyUI images at this stage are just tensors, so all there is to read is the shape: batch, height, width, channels. If you need generation metadata, that lives elsewhere, not here.

Installing it

ImpactImageInfo ships inside ComfyUI Impact Pack, so you get it by installing the pack. Cleanest route: ComfyUI-Manager → search ComfyUI Impact Pack → Install → restart. Manual: cd ComfyUI/custom_nodes && git clone https://github.com/ltdrdata/ComfyUI-Impact-Pack, then install the pack's requirements.txt in the same Python environment ComfyUI uses (portable build: ..\..\..\python_embeded\python.exe -m pip install -r requirements.txt), and restart. Since v7.6 the pack won't auto-install its dependencies, so a manual clone that skips the requirements step fails to load. Impact Pack is ltdrdata's - the ComfyUI-Manager maintainer - so it's rock-solid, and this node in particular pulls in nothing extra: no models, no heavy libraries. If the pack loads, it works.