Atlas Assess Image 🧭

Atlas Assess Image 🧭 is the pack's pre-flight check: a vision-language model looks at your photograph before anything else consumes it and tells you what the scene actually needs. Scene type, depth-model choice, how to separate sky, where the depth bands should sit, which geometry each layer wants, whether a camera move is even viable and what breaks first. It turns the "what settings do I use?" question from guesswork into a recommendation with a score.

How it works

The node sends your photo to a VLM with an expert instruction prompt encoding Atlas's full settings knowledge - the same rules the documentation teaches. The VLM doesn't change anything itself; it recommends. That's the pack's LLM-confirm principle and it's worth internalizing: you wire the advice downstream, but the artist stays in charge.

Providers are the same set as AtlasVLMScaleCues: ollama (default), lmstudio, and llamacpp for local servers, plus openai for any OpenAI-compatible cloud endpoint (OpenRouter etc. via base_url). Blank model defaults to the provider's pick - for Ollama that's gemma3:4b.

What comes out

The outputs are the genuinely clever part - the assessment is staged into the pack's five-layer master workflow:

• sam_prompt_* (sky, far, bg, mid, fg) - one SAM3 segmentation prompt string per layer, wired straight into the sky SAM node and the four scope rows. No hand-typing prompts. A layer the photo doesn't have yields ""; only sky falls back to the literal word "sky".
• geom_* (far/bg/mid/fg) - per-layer geometry recommendations (relief/card/ground), wired into the clean-plate layers' geometry_override string input.
• band_* (far/bg/mid/fg) - subject-aware depth-band boundaries, jointly derived so adjacent bands always share edges.
• settings_json - the machine-readable recommended settings block, for anything that wants the whole plan at once.
• report - the human-readable version, including an honest camera-move rubric (score, max orbit degrees, what breaks first). Wire it to a Show Text node.

The extra_instructions box is a sleeper hit: tell it "the camera move is a slow dolly-in on the tower" and the band and patch advice tailors itself to the intended move.

The gate behavior

By default (auto_continue ON) the node is advisory: the assessment runs, its outputs flow downstream, and the same queue continues - the solve gate and patch gate become the workflow's checkpoints. Turn auto_continue OFF and you get the hard per-image gate: the image output returns an ExecutionBlocker until you approve via the ▶ Continue Workflow button. The assessment is cached per image, so approving never re-runs the VLM.

Two operational notes. First, offload_model (default off) frees the VLM's VRAM after a successful assessment so the heavy pipeline - depth, SAM, LaMa - doesn't fight it for memory; on llama.cpp it isn't possible (the server owns its model). Second: if you use the openai provider, prefer the OPENAI_API_KEY environment variable over the api_key field - the field gets saved into the workflow file, and you don't want a key traveling around in shared JSON.

Install is the pack's clone-and-go; this node itself needs no heavy extras (it's an HTTP client), but the SAM prompts it emits expect a SAM3 setup downstream.