omost json2py
Turn an LLM's scene layout into Omost-compatible code
- omost_py
This one only makes sense once you know what Omost is. Omost (from lllyasviel, the same author behind IC-Light) is a technique for using an LLM to plan an image's composition before generation happens - instead of one flat text prompt, the model breaks a scene into regions, each with its own local description and rough placement, expressed as structured data that a compatible renderer turns into actual regional conditioning. This pack borrows the idea directly - it's credited by name in the README's "loan list" of projects it draws from - and omost json2py is the adapter node that makes it work inside an LLM-driven agent pipeline.
The problem it solves
Omost's original implementation expects its scene layout as Python code - literally a .py snippet describing regions and prompts in a specific structured form. That's a fine format for a human writing a layout by hand, but it's a rough one to get an LLM to produce reliably: getting a language model to emit syntactically valid Python, every time, with zero syntax errors, is harder than getting it to emit JSON, which most modern chat models are specifically trained and constrained to produce cleanly (JSON mode, structured outputs, and so on). So the practical pattern is: have the LLM output the scene layout as JSON instead, then convert that JSON into the Python format Omost's rendering side actually consumes.
That conversion is this node's entire job. One required input, omost_json - a multiline string, since a scene layout with several regions is naturally a chunk of structured text, not a one-liner - and one output, omost_py, the converted Python representation ready to feed into whatever handles Omost-format layouts downstream in your graph.
Where it fits
The pattern is: an LLM node (prompted specifically to produce an Omost-style scene breakdown) generates the JSON, this node converts it to the .py format, and that feeds into Omost-compatible rendering further down the workflow. It's a narrow, specific node - you're not going to reach for it outside an Omost-style regional-composition workflow - but for that specific use case it's the piece that makes "have an LLM plan the composition" actually connect to "have Omost render it."
Installing it
Part of the full pack, no separate download:
- ComfyUI Manager: search "comfyui_LLM_party", install, restart ComfyUI.
- Manual:
cd ComfyUI/custom_nodes && git clone https://github.com/heshengtao/comfyui_LLM_party, thenpip install -r requirements.txtinside your ComfyUI Python environment, restart.
This node itself is pure text conversion and needs nothing beyond the base install - the heavier requirement is whatever's actually rendering the Omost layout on the image side of your workflow, which is a separate concern from this pack.
Common issues
Since this node's whole purpose is bridging "LLM output" and "structured format," malformed JSON from the model is the most likely thing to break it - the same failure mode this pack's dedicated JSON Repair node exists to catch. If your LLM's Omost-layout generation is even slightly inconsistent (a trailing comma, an unescaped quote inside a description string), running the raw output through JSON Repair before it reaches this node is cheap insurance against a conversion failure that has nothing to do with this node's own logic.
The other thing worth checking if the conversion "succeeds" but the resulting image composition looks wrong: confirm the LLM's JSON actually matches the schema Omost expects for regions and prompts. This node converts the structure it's given - it doesn't validate that the JSON is semantically the right shape for Omost, just that it can be turned into equivalent Python. A well-formed but wrongly-shaped JSON object will convert cleanly and still produce a broken layout downstream.
Inputs (1)
| Name | Type | Default | Description |
|---|---|---|---|
| omost_json | STRING | — |
Outputs (1)
| Name | Type | Description |
|---|---|---|
| omost_py | STRING | — |