Images as Evidence: What an Image Analyzer Is Good At

A narrower lane than you expect

Of the four modalities, images have the smallest surface area in Content Understanding, and that is the first thing to internalise. An image analyzer takes a picture, applies a schema you defined, and returns structured data. It exposes almost no processing switches — the one meaningful configuration option is whether the response includes detailed output. There is no layout flag, no barcode flag, no page structure, because those ideas belong to documents.

The value proposition is standardisation. Instead of writing bespoke logic for each kind of photograph your business collects, you describe the fields you want and get the same JSON shape back regardless of what the picture looks like. That consistency is what makes large image collections tractable for analytics and search.

What the schema can ask for

Image fields can be generated or classified. They cannot be extracted, because extract — pulling a value from a located position in the content — is a document-only method. In practice that means you ask an image analyzer questions like: describe what is happening here; how many units of this product are on the shelf; is this weld defective; which of these five categories does this chart belong to.

Classification fields pair with an enumerated list of options, and the same limits apply as elsewhere: up to a thousand fields, and three hundred classify categories across the schema. Descriptions still act as prompts, so the guidance from schema design carries over unchanged — be specific, use the vocabulary of your domain, avoid negative definitions.

The scenarios the documentation puts forward

Four use cases recur, and they are worth remembering because they map cleanly to exam scenarios.

Retrieval-augmented generation, where key details pulled from images build an index that a chat experience can answer from. A photograph that nothing has ever described is invisible to search; a photograph with a generated description and a few typed fields is retrievable.

Business intelligence over charts, where performance graphs are read and turned into reportable numbers rather than sitting in slide decks.

Manufacturing quality control, where defects such as scratches, cracks or misalignment are detected on a production line.

Retail shelf analysis, where products are detected, counted and described to keep stock and placement under control.

The common thread is that each replaces a human looking at a picture and writing something down.

The trap that matters most

There is one explicit caveat on the image documentation, and it decides more questions than anything else in this slice: image analyzers are not the right tool when the analysis is really about text in the picture. If your goal is to read words off a scanned page, a photographed form or a screenshot, the document path is the correct one — a document field extraction schema, with its character recognition, layout analysis and grounding.

This catches people because the input is a JPEG in both cases, and file type feels like it should decide the modality. It does not. The document analyzers accept image file types precisely so that photographs of documents can be handled as documents. Ask what the content is, not what the file extension is.

A useful test: if the answer you want is written somewhere in the picture, you probably want the document lane. If the answer requires looking at the picture — counting, judging, describing, comparing — the image lane fits.

Figures inside documents are a third thing

Confusingly, the richest image work in Content Understanding is not done by image analyzers at all. Document analyzers can describe figures in natural language and can analyse them more deeply, turning charts into structured data and diagrams into component descriptions. Both are off by default because they cost generative model calls, and both are document-analyzer options.

So there are three distinct paths involving pictures, and being able to separate them is a genuine competence:

A standalone photograph analysed for its own sake goes through an image analyzer. A photograph of a document goes through a document analyzer. A chart embedded within a report goes through a document analyzer with figure analysis switched on, so that the chart's data becomes part of the document's output.

Practical limits

Images are accepted in the usual consumer formats and there is a size ceiling in the hundreds of megabytes, but the constraint that bites is resolution. Very small images below a modest pixel floor are rejected, and very large ones above a ten-thousand-pixel ceiling are too. If your capture pipeline produces thumbnails or enormous scans, the analyzer is not where that gets fixed.

Framing for the exam

If you studied earlier vision material, you may be looking for a separate image service with its own tagging, description and classification endpoints. That is not the shape of this syllabus. On this exam, image work is one modality of one tool: you define a schema, choose generate or classify per field, and read structured JSON back. The interesting decisions are which lane the content belongs in and what the fields should be — not which specialised vision product to call.