Scene Describe (LM Studio)

The sign-text pipeline asks a local vision model what a blank surface should say. Left alone it does something maddening: it will happily propose bakery lettering for a photo of a quarry, or - worse - transcribe the garbage already baked into the image, which means you pay the full cost of an edit to keep the slop. Scene Describe is the cheap fix. One description of the whole photograph, reused by everything downstream.

What it is

A VLM call over LM Studio's OpenAI-compatible endpoint that returns three strings: summary (one line about the picture), background (the scene around the lettering - light, weather, materials) and setting (what kind of place this is). The sign proposer takes the scene hint; the Ideogram caption builder takes the one-liner and the background line. Those last two are what keep the replacement text sitting in the same photograph as the rest of the frame instead of reading like a sticker, and they're what stops the proposer writing signage for the wrong kind of building.

The node's own description makes the case: without it, the proposer invents signage for the wrong kind of place, or falls back on transcribing the existing nonsense.

Inputs

• image - the picture to read.
• base_url - LM Studio, default http://localhost:1234/v1.
• model_id - default qwen3-8b-vl-instruct-abliterated, and name it. The tooltip is blunt about why: "whatever is loaded" is not a default, it's a silent failure. LM Studio lists models it hasn't loaded, the call returns nothing, and the graph carries on with an empty description. It must be a vision model - the abliterated build matters for the same reason it does everywhere else in this pack: a stock instruct model refuses on explicit material and you get an empty string instead of an error.
• temperature (0.0) - leave it. Measured over a hundred runs elsewhere in the project: at 0.2 and above, the model invents one-off answers that never repeat. You want the same input to give the same description, because every downstream decision is built on it.
• enabled - off passes the fallbacks through unchanged. That's for A/B testing: run the graph with the description on and off and see whether the sign text actually got better, rather than assuming.
• timeout (180 s) - generous on purpose. A 4B vision model on a busy GPU is not fast.
• Optional fallback_summary, fallback_background, fallback_setting - used when the model is unreachable or enabled is off, so the graph still runs from a fixed pair of sentences.

Outputs: summary, background, setting, report.

Install

cd ComfyUI/custom_nodes
git clone https://github.com/ping1979ping/comfyui-FVMtools

Restart ComfyUI, or install through ComfyUI Manager with comfyui-fvmtools. No Python dependencies - the node talks HTTP to LM Studio. Start LM Studio's local server (Developer tab), load a vision model, and confirm the endpoint with Reality Check Probe or by pasting the id straight from LM Studio's list.

Where people get burned

Empty description, no error. That's the failure this node is designed around and the one you'll actually hit: the call returns nothing, fallback_* is empty, and the proposer goes back to hallucinating. Check report - it records what happened rather than failing loudly.

A text-only model. LM Studio will happily load one, the endpoint answers, and you get plausible-sounding sentences about a scene it never saw. If the descriptions read like boilerplate, that's why.

Reaching for a big model. This is one paragraph of description per image in a batch loop. A 4B–8B vision model is the right size; the accuracy gain from a 32B is real but you're paying for it once per picture and the downstream job is "don't suggest a bakery in a quarry", which small models are perfectly capable of.