FL Image Size

There's no dramatic mechanism to explain here - this is a small, honest utility node. FL_ImageDimensionDisplay (labeled "FL Image Size" in the node picker) reads an image's width and height and hands them back as a formatted string, so you can see them on-screen, log them, or feed them into something downstream that needs to know an image's dimensions as text rather than doing the math yourself.

How it works

It reads the tensor's shape (or the PIL image's .size, since it handles both formats per the README) and formats the width and height into a single readable string. No resizing, no side effects - purely informational. That "handles both formats" detail matters more than it sounds: a lot of small utility nodes in this ecosystem only ever see a torch tensor coming out of a normal image-loading path, and quietly break the moment something upstream hands them a raw PIL object instead (a directory-crawl node, say, or an API node that decodes an image itself before converting it). This one covers both without you needing to know which one you're passing.

The inputs and outputs that matter

Just one required input: image.

One output: a STRING with the formatted dimensions.

How to install it

Part of the ComfyUI_Fill-Nodes pack. ComfyUI Manager: search ComfyUI_Fill-Nodes, install, restart. Manual:

cd ComfyUI/custom_nodes
git clone https://github.com/filliptm/ComfyUI_Fill-Nodes

then restart. Zero dependencies beyond what ComfyUI already has - it's a one-line read of tensor shape.

Common issues & troubleshooting

It's read-only - don't expect it to change anything. People occasionally reach for this expecting a resize function because "dimension" nodes sometimes do double duty; this one strictly reports, it never resizes or crops. Pair it with a resize node if you actually need to change the size, not just check it.

Batched inputs report one image's dimensions. If you feed it a batch of images that vary in size (uncommon, since ComfyUI batches are usually uniform, but possible after certain operations), the string reflects whichever image the node reads - treat it as a spot-check on a batch, not a per-image report across the whole batch.

Best used as a debug tap, not a permanent fixture. The honest use case is dropping this into a graph mid-pipeline while you're debugging why an output came out the wrong size - wire it off a branch, check the string in the console or a preview widget, then remove it once you've confirmed what you needed to know. Leaving a dozen of these scattered through a finished workflow just adds clutter for no ongoing benefit.

A STRING output, not two INT outputs. If what you actually need downstream is the width and height as separate numbers - to drive a resize node's target dimensions, say, or to do arithmetic on them - this node won't get you there directly, since it hands back one formatted piece of text rather than two numeric sockets. You'd need a string-parsing node after it to split the value back out, which is worth knowing before you wire this in expecting numeric outputs.