🕵️ Optic Scanner

Optic Scanner is the node that matters most in FiL_Design_ImageMind - the README says so itself, and for once the author isn't overselling. Everything else in the LLM half either feeds this node or consumes what it writes. Feed it an image and it sends that image to a vision model and gets back a generation prompt tuned for a specific target: Z-Image, FLUX, SDXL, QWEN, Krea 2, Ideogram 4, or a universal video profile. Leave the image socket empty and it becomes a text-to-prompt expander instead. Both halves are genuinely useful, which is rare.

What the output is actually made of

The output is not one template with a text box. It's five independent axes that stack - agent, agent_focus, detail_level, model_type, and a style - plus your prompt and negative_prompt steering on top. The agent is the single biggest quality lever in the whole pack. Twelve subject lenses (Portrait, Products, Nature & Landscape, Fashion, Animals, Architecture, …) each tell the model exactly what fields to describe and what to ignore. Run a product photo through Products and you get "anodized unibody, MagSafe and two USB-C on the left edge." Run the same photo through Portrait and the model chases hair/skin/pose fields that aren't in the frame - output gets visibly worse. Match the agent to the subject.

agent_focus lays a craft layer on top without replacing the agent (📐 Composition, 💡 Lighting & Color, 🔬 Ultra Detail, 🎬 Cinematic, 🎭 Emotion & Motion). detail_level is a real word budget, not "more adjectives": tiny (20–50 words) up through ultra (500–1200). model_type rewrites phrasing and length ceiling for the target generator and never touches which facts got pulled out. response_format shapes the text - prose, flat comma tags, or JSON for the Ideogram/FLUX schema.

The two knobs that read backwards

negative_prompt never reaches the model as an SDXL-style negative. For FLUX/Z-Image/Krea 2/Ideogram 4/Video - none of whose APIs take a negative input - it's rewritten into positive constraints: "don't include blurry" becomes "express the scene without blurriness." Type the same words with SDXL and you get a plain Avoid: clause. And prompt, when an image is connected, is not a description - the image is the source of truth. It's a targeted instruction layered on top: "emphasise the fabric texture and stitching." It can't swap the subject (that comes from the image); it steers how the answer reads. Without an image, prompt becomes the entire idea to expand.

prompt_mode decides one call or two. Auto (default) runs a single Hybrid call until you pick a style, then switches to Two-Stage - stage one writes a plain factual description, stage two restyles that locked description. That's the more reliable path for style work, and it's why the style contracts can detect when a preset plainly doesn't match the photo and downgrade it to background flavour instead of inventing neon signs into a field. If a style "didn't take," check metadata_dict.response_outcome - it reports whether the final text actually used the required cues.

Wiring and debugging

Three outputs: prompt (into your CLIP Text Encode), metadata_json, and metadata_dict - a dict that carries sent_prompt, the exact system/user text of the LLM call that produced your result. When a generation comes out weird, that's where you look first. The width/height inputs are sockets, not panel fields - wire the target resolution in from Empty Latent Image and the prompt tailors its composition to that aspect ratio.

The biggest complaint people raise with LLM-in-graph prompts is subject drift and dirty output. This pack's answer is structure: the agent templates constrain what's described, and the metadata tells you what was actually sent. Two tight calls beat one freeform rewrite - the same lesson the community converged on for prompt-enhancer nodes generally.

Setup: it needs config from FiLProviderLoader. For first runs, pick Ollama as the provider (no key), match the agent to your subject, and leave model_type on Auto/None. If the model list is empty or vision calls fail, that's a provider problem, not a scanner problem - see the Provider Loader article.