---
title: "Images in a data pool"
description: "What of an image reaches the index, why image files are skipped by default, and how an image becomes visible in chat"
canonical_url: "https://meingpt.com/en/docs/integrations/data-pool-images"
language: en
---

# Images in a data pool

## Three questions that get treated as one

"Can my AI work with images?" is really three questions with three different answers. Settle which one you mean first — otherwise you look for the fault in the wrong place.

| What you want | Possible? | The route |
| --- | --- | --- |
| The assistant should know an image's **content** and be able to search it | Yes | Put the image inside a document — [see below](#what-of-an-image-reaches-the-index) |
| The assistant should **show the image in chat** | Yes, via a skill | [Showing an image in chat](#showing-an-image-in-chat) |
| A user should **open the original file** and look for themselves | Yes, by default for cloud data sources | [Opening the original file](#opening-the-original-file) |

**By default, a loose image file in a cloud data source does none of these three.** PNG, JPG, TIFF, BMP and SVG are not on the list of formats a data source ingests — they are skipped during sync, with no entry in the file list, no error in the log, and no count among the skipped files. It looks like a misconfiguration and is not one. Details: [File formats](/en/docs/integrations/data-pools-rag#file-formats). An Outpost behaves differently here, see [below](#on-an-outpost).

## What of an image reaches the index

Images **inside** documents are read. A vision model looks at the images and writes what they show into the search index as text.

| Where the image sits | Read |
| --- | --- |
| Inside a `.docx` or `.pptx` | Yes |
| Inside a PDF — embedded figures, plus pages with drawings or tables drawn as vector graphics | Yes |
| Inside an `.odt` | No — text only |

What the model does with it:

- **Text in the image is transcribed verbatim** — headings, labels, captions, annotations, small print. Numbers, units and symbols stay as they are, and nothing is translated.
- **Tables stay tables.** A dimension table in a technical drawing lands in the index as a table, not as a run-on sentence.
- **Photos, charts and drawings get one short factual description** — even when they carry no text at all. The description is in English when the document is clearly English, otherwise in German.
- **It does not guess.** Industry, function, purpose or the identity of a part are named only when visible text supports it. That is deliberate: a guessed part number in the index is worse than none.
- **Logos, pictograms and very small images are skipped on purpose**, as are images repeated several times in a document — a logo in every header, for instance. They cost a model call and produce a description nobody searches for.
- **Purely decorative or blank images return nothing.** That is not an error.
- **Up to 64 images are read per file**, in document order. In a catalogue with hundreds of figures, the ones towards the end stay unread.

### On an Outpost

An [Outpost](/en/docs/integrations/vault) works without a vision model. It reads the text in images through classic text recognition — in Word and PowerPoint files as well as in standalone image files (PNG, JPG, TIFF, BMP, WEBP, HEIC), which, unlike a cloud data source, it does not skip. No description of photos, charts or drawings is produced, and text recognition performs markedly worse on drawings and scans.

## Best practices

The rule behind all of it is simple: **the model writes only what is visible.** Everything else follows from that.

The text around an image carries the file — it is what search finds the image through. "Fig. 4: tension rail, model XY, installed position" makes an image findable that would otherwise sit in the index as "a metal rail on black fabric".

Item numbers with a legend, a type plate, a dimension table, labelled axes. A close-up photo with no labelling at all can be described but not attributed — and the model is explicitly not supposed to guess the attribution.

What is legible gets read. Illegible spots are marked as such rather than guessed, and a 96-dpi screen grab of a dimension table loses exactly the numbers it is in the index for.

Twelve details on one page produce one description covering twelve things. One page per detail produces twelve separately findable passages.

In the data pool, open the **Test Search** tab, ask a real question and look at which document and which passage each hit comes from. That is the only solid proof that an image's content really is in the index.

## Showing an image in chat

The index holds an image's **description**, not the image. An assistant can therefore explain a detail but cannot show it on its own. If your users need to see the picture, a [skill](/en/docs/platform/skills) is the route.

The image files go into a `.zip`, together with a `SKILL.md` describing when which image is shown — ideally as a "model / detail → filename" table. Limits: 50 MB per package, 20 packages per assistant.

Drag and drop it into the **Skills** section of the assistant editor. That section requires the [Code Sandbox](/en/docs/platform/code-sandbox), which is on by default.

For example: "If a skill holds an image for a detail, output it in the chat alongside the explanation."

The assistant then mounts the package in the sandbox and returns the matching image as a file card in the chat. For PNG, JPG, GIF and WEBP a thumbnail appears inline in the conversation, along with a download.

This pays off for a manageable, curated set — exploded views, installed positions, type plates, anything where a sentence of text does not answer the question. For thousands of images it is the wrong route: a skill is a curated companion to your knowledge, not a second data pool.

## Opening the original file

Every citation in an answer can be clicked and shows the matching passage. Opening or downloading the file itself — to check a drawing against the original, say — only works when the data source is set to the release level **Original files**. For cloud data sources that is the default unless an admin lowers it; on an Outpost the preset is **Text only**. Where to set it and what the three levels mean: [Citations in answers](/en/docs/integrations/data-pools-rag#citations-in-answers).

## What does not work

So you do not go looking for it:

- **Images from Confluence pages.** The Confluence sync reads page text. An image embedded as an attachment lands in the index only as a placeholder with its file name; an image embedded by URL leaves nothing at all. See [Confluence](/en/docs/integrations/sources/confluence).
- **Loading images into chat through a connector.** The file connectors hand document formats to the chat, not image formats.
- **Displaying an image out of the index.** The index holds text. The image itself reaches the chat through a skill, or as the original file on a citation.

What does work at any time: **attaching an image in chat**. Practically every current flagship model accepts JPEG, PNG, GIF and WEBP as an attachment — see [Models](/en/docs/platform/models).

## Related pages

- [Data sources & RAG](/en/docs/integrations/data-pools-rag): connecting sources, file formats, indexing, access control
- [Data pool search settings](/en/docs/integrations/data-pool-search-settings): the four settings and the test search
- [Data quality](/en/docs/integrations/guide-data-quality): how to prepare documents for search
- [Skills](/en/docs/platform/skills): your own code packages on an assistant