Batch Image Metadata

So you've got an image in an S3 bucket and the pack handed you a BUCKET_MANIFEST output. It's a dict full of useful facts - but in ComfyUI, a dict isn't something you can route around. Batch Image Metadata exists to split that manifest into discrete typed outputs you can actually wire into text, numbers, and logic.

One manifest input, twelve outputs. It doesn't touch the bucket; it just unpacks. Think of it as the ComfyUI equivalent of json.loads(...) followed by "give me the fields I care about."

The outputs that matter

The full schema list is:

• key (STRING) - the <subfolder>/<uuid> key. The one you'll use most: feed it into anything that needs to reference the asset, like a save-name builder or an API call.
• media_type, file_format - "image" and "png"/"jpg"/"webp".
• created_at (STRING) - ISO timestamp of when it was stored. Empty if the manifest was derived.
• batch_size (INT) - number of frames stored under this key (one key can hold a whole batch, named _0, _1, ...).
• width, height (INT) - pixel dimensions. Great for resolution gating or aspect-ratio math.
• description, author, tags (comma-separated), source - the human/VLM-written fields.
• derived (BOOLEAN) - true if the manifest was inferred at load rather than read from a stored <key>.json.

Where you'd actually use it

Typical setups: take width/height and feed them into a conditional so you only process images above a certain resolution; pass tags to a text encoder or wildcard expander; or grab key and push it into an HTTP node so a queue worker knows which bucket object to pull. The batch angle matters too - because a single key can resolve to a whole batch of frames, batch_size is how you know how many images you actually got without counting the tensor.

If you're driving ComfyUI as an API, this is the node that tells your caller what just happened - dimensions, batch count, whether it's a real stored manifest or a reconstruction. That's its home turf.

Install and gotchas

Install the pack once (ComfyUI Manager, search In-N-Out Bucket, or clone it into custom_nodes and pip install -r requirements.txt), restart, and it lives under buckets/image.

The gotcha to remember: derived isn't an error. Assets uploaded before manifests existed, or with no <key>.json present, get a manifest reconstructed on the fly - dimensions and batch size come from the decoded pixels, created_at is empty. Write metadata with Set Image Metadata to make the record permanent. And if your Input node is showing empty strings everywhere, the first thing to check is the bucket connection, not the node - a manifest that failed to load simply defaults.