LC Get Latent Size 📐

A latent doesn't tell you its pixel size. Its tensor shape is the compressed size - [B, C, H/8, W/8] for most models - and when you need width and height in pixels (for an Empty Latent, a Resize target, or a Save widget) you end up doing the mental math or eyeballing a decode. LC Get Latent Size does the math for you: wire in a LATENT and it reports the pixel width and height - the numbers a resize or save node actually cares about - plus the batch and, for video latents, the frames.

It's a genuine quality-of-life node, the kind the ComfyUI pipeline is full of: not touching pixels, just turning an opaque tensor into plain numbers your graph can branch on. The plumbing-layer docs describe exactly this species - value nodes that turn something hidden in a wire into something visible and routable.

How it works

The node looks at the latent tensor's spatial dims and multiplies by a compression factor to get pixels:

• vae wired → it asks that VAE for its real spatial compression (spacial_compression_decode), so the number is model-accurate. For a video model whose VAE compresses time as well, the temporal handling matters.
• No VAE → it uses the compression widget, default 8, which is right for SD, SDXL, Flux, and MiniMax H3-style latents.

For 4D latents it reports frames as 1 (it's a still batch); for 5D video latents (batch × channels × frames × h × w) it pulls the frame count off the temporal axis. So this node is how you answer "what did my Wan/LTX latent actually produce" without decoding it just to find out.

The outputs that matter

• width / height (INT) - pixel dimensions, what Empty Latent, Resize, and Save expect.
• batch (INT) - number of images.
• frames (INT) - temporal length, for video latents; 1 for plain images.

Classic use: feed a sampler's latent in, take width/height, and drive a Resize or text-prompt node so your downstream steps always match what was actually generated - no more hardcoding 1024×576 and drifting out of sync when you change the latent.

How to install it

Part of lonecatone23/ComfyUI_LC_AV_nodes (LC Audio_Video nodes, MIT, by lonecatone23 - sibling to the image-side ComfyUI_LC123_nodes):

• ComfyUI Manager: search "LC Audio_Video" or ComfyUI_LC_AV_nodes.
• Manual: cd ComfyUI/custom_nodes && git clone https://github.com/lonecatone23/ComfyUI_LC_AV_nodes, restart (console: [LC AV] total 16 nodes).

No dependencies or downloads beyond core.

Where it bites

The compression fallback of 8 assumes a standard 8× spatial VAE. Video models vary - and some have a temporal dimension that changes how you count frames - so if you're on a model whose VAE isn't the usual 8× (and you haven't wired a VAE in), your pixel numbers will be off by that factor. Wiring the actual vae in sidesteps the guessing entirely, which is why the socket exists. If the numbers look wrong, that's your first suspect, not a bug in the node.