AcademiaSD MOSS Layout Analyze

A two-input, one-output node that exists because a button needed somewhere to live. You'll rarely place it on purpose - you'll drop it by accident, or see it named in the console and get curious. Short answer: it's the worker behind MOSS Layout's Analyze Image button.

What it does

Give it a picture and a Qwen3-VL, get back a layout: a paragraph describing the whole scene, plus every character, object and legible text block it found, each with a caption and a box. That's the shape the MOSS Layout editor wants, so it's what the button drops onto your canvas as draggable boxes.

The interesting part is why you'd want it at all. Rebuilding an existing image is normally manual: look at the reference, judge that the sign sits 12% in from the left, drag a box, type the sign's wording. The VLM does that pass in one shot, reading the text off the sign as it goes. Qwen3-VL is right for it because bounding-box grounding is trained in, so coordinates are a native output rather than something bolted on (kg/entities/qwen3-vl.json). Asking a model to describe an image and asking it where things are, in numbers, are different jobs.

How it works, mechanically

The node scales the image down to roughly a megapixel (aspect preserved) and sends one vision pass with a strict instruction: a single JSON object, nothing else, boxes on a 0–1000 grid, elements largest-first, at most 20, captions capped at 25 words. Text items come back as literal characters, line breaks intact, in their own script - one item per block. Labels are only ever character, object or text, the three kinds MOSS-Image accepts.

Generation is greedy, and the code notes why: repetition penalty punishes the repeated digits inside coordinate numbers and shoves the boxes off position. That's a genuinely good piece of forensics, and it's the kind of thing you'd otherwise spend an evening debugging.

The output gets repaired before you see it. Small models leave JSON unterminated when they hit the length cap, so the parser strips any thinking block, walks back from the end closing open strings and brackets until it parses, dropping trailing items if it must. Anything that isn't a four-number box is discarded, boxes under half a percent of the canvas are dropped as noise, and coordinates are divided by 1000 and clamped to 0–1 because the editor stores fractions.

One plumbing detail explains behaviour you'll notice: IS_CHANGED returns float("nan"), the standard ComfyUI idiom for "always run this". Every press analyses again, even on an identical image - what you want from a button, mildly annoying if you wired it into a graph and expected caching (docs/knowledge/comfyui-node-plumbing.md has the NaN trick).

Inputs and output

Two required inputs, nothing optional:

• vlm - a Qwen3-VL text encoder, loaded as a CLIP the way the pack's Prompt Enhancer loads it. The tooltip's own suggestion is to reuse the one you already have.
• image - the reference to analyse. Only the first frame is used, so batching ten images doesn't give you ten layouts.

One output, layout, a STRING of JSON with a caption and the items array. Wire it into anything that takes text - a preview, a save-text node, your own string munging - or just leave the node alone and let the button do the work.

Install

Same pack, same steps: ComfyUI Manager → search AcademiaSD, or

cd ComfyUI/custom_nodes
git clone https://github.com/AcademiaSD/comfyui_AcademiaSD

then restart. No requirements beyond what ComfyUI already installs. You'll find it at Academia SD/MOSS-Image.

The real dependency is the VLM. Qwen3-VL is in the same family as MOSS-Image's text encoder, so the workflow that already has a MOSS stack loaded usually has a usable CLIP sitting there. Which size you pick matters more than anything else on this node.

Common issues

"The model found nothing to place" is the button's message when the parse yields zero valid boxes. Usually it's an encoder that can't do grounding - a text-only Qwen3 rather than the -VL variant, or an aggressively quantized one. The prompt demands a JSON shape and a small model answers in prose instead; the parser then has nothing to recover.

Sloppy boxes. The author is blunt about it: 8B places boxes noticeably better than 4B, and abliterated builds lose precision. Boxes hovering around the right thing rather than sitting on it mean the node did its job and the model didn't.

Output node, so it runs on its own terms. Being an output node is how the Analyze button queues it in isolation without your sampler firing. Drop it on a canvas with a Load Image and a CLIP, hit Queue, and it analyses and prints the box count - the fast way to test an encoder before committing it to a whole layout.