Describe to Picker

The Describe to Picker node analyzes a photo and fills the picker nodes you connect to it. A vision model looks at the main subject and the scene. It returns choices that exist in each picker's catalog, such as the person's age and hair, the makeup, the shot size or the lens. One run fills every connected picker.

When to use it

• Turn a reference portrait into a full casting brief: connect Person, Styling and Framing, then feed them into Generate Image or Generate Video.
• Set up a recurring character, with its styling and its lens look, from a single photo.
• Match the camera of a reference image: detect its shot size, angle, lens and film stock.

Quick start

Inputs

The output, Picker JSON, is structured data with one part for each connected picker. Only picker nodes can read it: it does not connect to text inputs.

What it fills

The node analyzes exactly the pickers wired to its output, and no others. There is no picker setting to choose: the wiring is the choice.

Every value is a real choice from the picker's own catalog, so a picker never receives a value it does not know. A trait that is not visible in the photo is left out.

How pickers apply the result

Each picker decides how to use its part of the result, with two settings in its settings panel.

When image JSON is injected chooses how new values merge with the picker's current choices:

Auto-apply on change is on by default. When it is on, every new result is applied at once, with the chosen mode. A choice you change by hand stays until the next run. Until then, the picker shows an Update from injected button that applies the result again. When it is off, the picker shows Update from injected after a new run or a change by hand. Otherwise it shows Up to date. Every run counts as a new result, even when it returns the same values.

In every mode, only the picker's choices change. The picker's label, its pre and post text and its layout stay as they are.

Settings

Credits

A run is one vision call, however many pickers you connect. The call is charged for the tokens it actually used, at the selected model's rate. The tokens are the analysis prompt, the photo and the answer. The analysis prompt lists the catalog of every connected picker, so each connected picker makes the prompt longer. The full rules are in How LLM calls are charged.

• Before the run, the Run button shows an estimate (≈ and a number) of a typical read on the selected model. The estimate grows with the number of connected pickers.

• The model sets the rate. The default, Gemini 3.8 Flash, is one of the cheapest models. Claude Sonnet 5.5 and Claude Opus 5 cost more. Claude Opus 5.5, Claude Fable 5 and Gemini 4 Argon are the most expensive.

• Some calls run directly with the maker. This happens in Advanced mode, and when a Claude model has any reasoning effort, because Claude's effort takes effect only there. The call is then charged at the rate of the maker's own service. Claude Opus 5.5 runs at High by default, so every read of Claude Opus 5.5 started from the editor runs there. Gemini 4 Argon always runs on Google's own service.

• A hold comes first. When the run starts, Nodaro holds enough credits for the longest answer the model may write. A balance below the hold is refused before anything runs. After the call, the run is charged what it used.

• When Claude is unavailable. When a Claude model cannot answer because its service is down or busy on Nodaro's side, the same analysis runs once on Gemini 3.8 Flash. The run is charged what both reads used: the Claude attempt, if its maker billed it, plus the Gemini 3.8 Flash read at its own rate. If Gemini 3.8 Flash fails too, the run fails and is charged only for any billed usage.

• A content refusal. When the model declines the photo on content grounds, the run fails with the content-policy message. It is not sent to another model. The refusal is charged when the model's maker billed it, and refunded when it did not.

• An empty read. When the analysis finds no trait for any connected picker, the run fails with the message "We couldn't read anything in this photo — try a clearer photo of one person". The message then says whether you were charged. When the model's maker billed the read, it adds "You were charged N credits for the model's attempt". When the maker did not bill it, it adds "You weren't charged", and the credits are refunded.

• Other failures. A failure that the model's maker billed, such as an answer cut off at the limit or an answer that never matched the catalogs, is charged for that usage, and the error says how much. A failure that was not billed is refunded.

Troubleshooting

The run is refused with a message to connect a picker node. Nothing that the node can fill is wired to its output. Connect at least one Person, Styling, Framing, Lens or Camera / Film Stock picker.

A picker did not change after the run. Auto-apply on change may be off on that picker. Click Update from injected on the picker, or turn on Auto-apply on change.

The run fails with "We couldn't read anything in this photo". The model found no trait for any connected picker. The message says whether the attempt was charged. Try a clearer photo of one person.

The node described the wrong person. When a photo has several people or a busy background, add Extra guidance (optional), such as describe the woman in the red coat.

Tips

• Fill several pickers in one run. Person, Styling and Framing together turn one photo into a casting, look and shot brief, in one call to the model.
• Protect your own choices. Use Fill empty only when you have chosen a few defining traits by hand and want the photo to fill in the rest.
• Refresh without losing extras. Use Overwrite detected (keep rest) to update what the photo shows and keep the choices you added by hand.
• Recast from scratch. Use Full override (clear undetected) for a clean, photo-driven version of the picker.

From the API

POST /v1/describe-to-picker runs the same analysis from code. It answers in the same request with { jobId, pickerJson, gaps }. pickerJson gives each picker its detected values, as { "<picker>": { "<dimension>": "<id>" } }, with a list of ids where a dimension takes several picks.

Stream the answer. Send Accept: text/event-stream to receive the answer as server-sent events, so that a client can show each trait as soon as the model has written it. An error found before the stream opens, such as an invalid request or too few credits, is still a plain HTTP response with the usual JSON error body. The stream answers 200, and each event is one data: line with a JSON object, { "type", "data" }:

• The stream ends after done or error. Ignore comment lines, such as : keepalive.
• With a Claude model run with a reasoning effort (Claude Opus 5.5 has High by default), or in Advanced mode, traits can arrive as field events. Other runs send only done, including the default model, Gemini 3.8 Flash, and a run that fell back to it.
• A field event never carries a value that the rules for people under 20 could remove. Such values arrive only in done.
• One request is one analysis, charged the same way as without a stream. It is charged for what it used when done arrives. On error, it is charged for any usage the model's maker billed, and refunded otherwise. If the client disconnects, the analysis still finishes and is charged.

See Run a single node.