TS Studio Manifest

Here's the thing that makes TS Image Studio work at all: its backend workflows are plain ComfyUI graphs, but the studio has to know what a graph is before it can build a UI for it. Is this one a text-to-image mode or an edit mode? What controls does it expose - a prompt, a seed, reference slots? What models does it depend on? That's metadata, and metadata needs a home.

TS_StudioManifest is that home. It's the marker node that carries the manifest of a backend workflow - one per backend file - as JSON describing the backend's id, family, mode, controls, reference slots, and dependencies.

How it works

The studio reads the manifest from the exported workflow to decide how to render its interface and how to dispatch a run. The node itself does almost nothing at execution time: it validates the manifest text and passes it straight through. The intelligence lives in the studio's reader, which consumes this marker just like it consumes the other TS_Studio* markers.

The single input is manifest - a multiline STRING, default "{}". The full schema is documented in the pack's doc/IMAGE_STUDIO_PLAN.md, §4, which is the authoritative reference if you're authoring a backend. The single output, also manifest, is the same text passed along so it can flow into whatever consumes it downstream.

When you'd actually touch it

If you only use the studio with its built-in backends, you will never touch this node. It exists so backend authors can ship new modes - your own model, your own graph - and have the studio build a form for them without any code change. That's the same data-driven pattern the rest of the studio is built on: a new model is a new workflow file with a manifest, not a fork of the app.

If you're authoring, the fields that matter are the ones that tell the studio how to behave: id (unique per backend), family and mode (what the backend generates), controls (which marker parameters the UI should expose), reference slots, and dependencies. Get the id wrong and the studio may treat two backends as the same one; get the controls wrong and users see the wrong form.

Installing it

Part of comfyui-timesaver: ComfyUI Manager → search Timesaver, or

cd ComfyUI/custom_nodes
git clone https://github.com/AlexYez/comfyui-timesaver
cd comfyui-timesaver
python -m pip install -r requirements.txt

then restart ComfyUI.

Gotchas

The one that bites: a manifest that's valid JSON but says the wrong thing. The node validates, it doesn't judge - a syntactically fine manifest describing the wrong mode will happily pass through and then confuse the studio downstream. Also, "one per file" is a rule, not a suggestion; two manifest markers in one backend and the studio doesn't know which one describes the file. Keep it to one, keep the JSON valid, and the studio does the rest.

There's one more thing worth knowing about this pack generally: it's built on the ComfyUI V3 API (comfy_api.v0_0_2), a pinned namespace. That's why marker nodes like this one work across pack updates - ids, inputs and defaults are frozen on purpose, so a backend you author today keeps loading after git pull.