Cloud Get Image Size

Cloud Get Image Size is the pack's tape measure. Give it a CLOUD_IMAGE handle and it returns the image's width, height, and batch_size as three CLOUD_INT values - without the image ever leaving the cloud. It's the cloud-side version of the stock GetImageSize, and the pack's own docstring points at its real use: it gets used heavily inside the LTX templates to drive resize and aspect-ratio calculations.

Here's the subtle part worth understanding before you reach for it. The values aren't computed when you build the graph, and they aren't pulled down to your machine as live numbers. This is a handle-based cloud chain, so the size is computed cloud-side during execution: when the terminal node submits the whole graph, the cloud runs GetImageSize and feeds the resulting integers to whatever downstream cloud nodes consume them - a resize here, an aspect calculation there - all within the same submission. If your goal is to read the size locally at graph-build time to make decisions before running, this node won't help; the values only exist when the chain runs. If your goal is to drive cloud-side layout math off an image you've already got in the chain, it's exactly right.

The inputs and outputs

• image (CLOUD_IMAGE) - from a Cloud Empty Image, a Cloud VAE Decode, or any cloud image-producing node.

Outputs: width, height, batch_size - all CLOUD_INT, in that order. Wire them into other cloud nodes that take numeric inputs (resize nodes, aspect calculators). Note the type is deliberately CLOUD_INT, not a plain INT - these are cloud-side values, so they'll only connect to sockets that expect them.

How it works

Like every node in the pack, it appends a GetImageSize spec with three output slots to the accumulating workflow JSON and returns one handle per slot. No pixels are transferred, no file is opened on your machine. The whole point is keeping the image and its metadata in the cloud for as long as possible - the kind of plumbing that makes sense the moment you're feeding cloud-side resize decisions off a cloud-side image.

How to install

cd ComfyUI/custom_nodes
git clone https://github.com/Dobidop/ComfyUI-CloudAPI-worker

Copy config.json.example to config.json, paste an API key from https://platform.comfy.org/profile/api-keys, restart. Or install via ComfyUI Manager. Dependencies: requests, Pillow, safetensors.

Common issues

• "The values are never available locally" - by design. If you need a size before running, you're using the wrong tool; compute it from the local source image instead.
• Wiring a CLOUD_INT into a plain INT input - it won't connect; the socket types are intentionally different. Keep size math inside the cloud chain.
• PoC expectations - a small utility in a single-author proof-of-concept pack. It does its one job; just remember the pack's own caveat that rough edges are expected beyond the example workflows.