Images in a data pool

What of an image reaches the index, when chat shows the picture itself under the citation, and which image files a data source reads

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 wantPossible?The route
The assistant should know an image's content and be able to search itYesPut the image inside a document — see below
The assistant should show the image in chatYes, automatically under the citationPictures in chat
A user should open the original file and look for themselvesYes, for cloud data sources without an earlier restrictionOpening the original file

Attention

A cloud data source reads loose PNG, JPG, GIF and WEBP files, but no TIFF, BMP or SVG files. Those are skipped during sync and appear neither in the file list nor as an error in the log. It looks like a misconfiguration and is not one. Details: Loose image files. An Outpost behaves differently here, see below.

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 sitsRead
Inside a .docx or .pptxYes
Inside a PDF — embedded figures, plus pages with drawings or tables drawn as vector graphicsYes
Inside an .odtNo — 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, plus up to 12 PDF pages with drawn figures. In a catalogue with hundreds of figures, the ones towards the end stay unread.

On an Outpost

An Outpost 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), including TIFF, BMP and HEIC, which a cloud data source skips. No description of photos, charts or drawings is produced, text recognition performs markedly worse on drawings and scans, and pictures do not appear in chat.

Lines that look like text-recognition noise do not go into the index; the document's own text always stays complete. If text recognition cannot read a page of a scan or an image file reliably, such as a page that is upside down, the Outpost reports the file as failed. A previously indexed version of the file then stays searchable. What else it reads from Word and PowerPoint files: What gets read, and what does not.

Pictures in chat

For every image the vision model has read, MeinGPT keeps a copy. When an answer cites a passage that describes such an image, the chat shows the image as a thumbnail under the answer — with the number of the citation it belongs to. Clicking it opens the source preview at the cited passage, with the picture shown large above it.

Ask, say, "What does the clamping fixture look like?" and if the operating manual has a photo captioned "Fig. 1: Clamping fixture SV-200", that photo appears under the answer.

  • Only pictures from your sources appear. The assistant does not generate or link images; what is shown is only what belongs to the cited passage in the document.
  • A few, not all. At most three pictures per citation and four per answer. A picture that appears in several files shows once, with the numbers of all its citations. Which picture belongs to which passage is decided by where the picture sits in the document.
  • A drawn PDF page counts as one picture. For exploded views and circuit diagrams, the chat shows the whole page.
  • The copy is scaled down (at most 1600 pixels on the longer side) and stored without metadata such as camera or location data. The original stays where it is.

Note

Requirements. Pictures in chat appear for every cloud data source, for everyone who may use the source — except sources restricted earlier to Matching passages only or Text only, see Citations in answers. Whoever may not see the source does not see its pictures either. Pictures are kept while a file is being ingested: a file ingested before this feature and not changed since shows its pictures only once it is ingested again — change it, or ask support to have the data source re-ingested.

The kept pictures count toward your workspace's storage allowance. A picture that appears in several files of the same data source is stored and counted once. When a file is deleted, the chat stops showing its pictures immediately; the copies themselves are removed at the latest one day after the next sync, and immediately with the data source.

Curated images via a skill

For a manageable, curated set that does not live inside documents — exploded views, installed positions, type plates as individual files — a skill remains the route: put the image files with a SKILL.md into a .zip (at most 10 MB packed, 30 MB unpacked and 200 files per skill), upload it in the skill library or in the Skills section of the assistant editor, and describe in the SKILL.md when which image is shown. Because images are binary files, the skill needs the Code Sandbox.

Loose image files

A cloud data source reads JPG, PNG, GIF and WEBP files like documents, with nothing to switch on: the vision model describes each image file, the description is searchable, the file appears in the file list and the counts as usual, and the chat shows the picture under the citation. The same limits apply as for embedded images, at most 10 MB per image. TIFF, BMP and SVG are skipped.

A new data source reads image files from its first sync. Data sources that existed before image files were read are brought in step by step — a few every quarter of an hour, so that not all of them load their images at once; until then the Files tab lists the images as not read yet. Once a source's turn comes, the next sync picks up its image files — for OneDrive and Google Drive once, with a full comparison that takes a little longer. On SharePoint they appear only once they change; otherwise ask support to have the data source re-ingested.

If a folder of photos or screenshots should not be searched, do not connect it to the data source: every image file costs a model call when it is ingested and counts toward the storage allowance.

Best practices

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

One image per section, with a heading and a caption

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". A caption in this form is also what the chat shows with the picture.

Whatever identifies the image must be in it or right next to it

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.

Drawings and scans at a workable resolution

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.

No collection pages

Twelve details on one page produce one description covering twelve things. One page per detail produces twelve separately findable passages — and twelve pictures the chat can show one by one.

Verify instead of hoping

In the data source, open the Overview tab and use Try it to 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.

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 — works on every cloud data source for everyone who may use it — except sources restricted earlier to Matching passages only or Text only, see Citations in answers. On an Outpost it works only when the folder is set to Text and original files in the Outpost app; the preset is Text only. More: Release level.

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; neither appears in chat. See Confluence.
  • Images the model did not read. Logos, pictograms, very small and repeated images, and anything beyond the 64 images per file stay without a description — and so without a thumbnail.
  • Loading images into chat through a connector. The file connectors hand document formats to the chat, not image formats.

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.

Was this page helpful?