LM Studio FLUX.2 Prompt Generator from Image

Klein's other superpower is editing, and the classic move for an edit is: look at the reference image, then re-roll it with a better description. The problem is that turning "this photo of my dog" into a prompt Klein actually respects takes both a vision model and some writing muscle. This node is the vision sibling in the same pack as the plain LM Studio FLUX.2 Prompt Generator - point it at an image, it writes the FLUX.2 prompt for you, all locally.

It works exactly like its text-only cousin, except the input is an image (the IMAGE tensor straight off a Load Image node) instead of a draft prompt. Add an optional base_prompt for creative direction, pick your style, and out comes an enhanced_prompt STRING.

How it works

Run it and the node takes the first frame of your image tensor, clamps it to 0–255, converts it to JPEG, base64-encodes it, and sends it to LM Studio as a data:image/jpeg;base64,... URI in the standard OpenAI image_url multimodal message format. Then it appends the same style/word-count instruction the text node uses and POSTs to http://127.0.0.1:1234/v1/chat/completions - no key needed, thanks to LM Studio's placeholder Bearer lm-studio token.

Two things fall out of that. First, the image always goes out as JPEG - this simplified pack deliberately removed the image-format control the fuller generator exposes, and for describing a photo to an LLM that's fine. Second, and this is the one that bites people: your model must be a vision model. A text-only LLM can't read that image payload; it'll error or hallucinate a description. The README's recommended HauhauCS/Qwen3.5-35B-A3B-Uncensored-HauhauCS-Aggressive is a vision model, and on a smaller GPU it points you at a smaller or more quantized GGUF vision model. Qwen2.5-VL-class models work.

The cleanup is shared with the text node: it strips markdown, "Thinking Process:" blocks and label-prefixed reasoning, and if the result still reads like thinking it fires a second "repair" call asking the model to clean its own draft.

The inputs that actually matter

• image - wire it from Load Image or the VAE decode side of a prior generation.
• base_prompt - optional creative direction. This is where editing intent lives: "make it night, keep the subject and pose." Klein edits work best when you name both what must change and what must not, so a sentence here goes a long way.
• model - must be a vision model, exact ID from /v1/models.
• prompt_mode, target_word_count, temperature, max_tokens - identical to the text node, same defaults.

Output

One enhanced_prompt STRING. Wire it back into the same FLUX.2 text encoder for a re-roll, or into a Show Text node to eyeball the description first. The bundled workflow is exactly that: Load Image → this node → Show Text.

Installing it

Same pack as its sibling, same install:

cd ComfyUI/custom_nodes
git clone https://github.com/Slartibart23/comfyui-lmstudio-flux2-prompt-generator-simple

or ComfyUI Manager → search comfyui-lmstudio-flux2-prompt-generator-simple, then restart ComfyUI. requirements.txt is just requests; the rest of the stack already ships with ComfyUI. The LM Studio side is the real setup: load a vision model, open Developer, start the local server, and get the exact model ID with Invoke-RestMethod http://127.0.0.1:1234/v1/models.

Troubleshooting

• Text node works, image node errors or rambles - you almost certainly have a non-vision model loaded. Switch models in LM Studio.
• Output is incomplete or analytical - raise max_tokens (4096 → 8192) and LM Studio context length (16384+) on both sides. Same fix as the text node.
• Output starts with "Thinking Process:" - raise the same two settings, or use a non-reasoning vision model.
• Only the first frame is described - the node reads image[0]; a batched image only feeds the first frame through.

Honest take: this is genuinely handy for the "reproduce this reference" workflow, because you end up with a reusable description you can keep, tweak and edit rather than a one-shot generation. And it's fully local, which matters when your reference images aren't something you want sitting on a cloud vendor's API logs.