"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
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. An Outpost behaves differently here, see below.
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.
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), 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.
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".
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.
Verify instead of hoping
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.
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 is the route.
Put the images in a skill package
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.
Attach the package to the assistant
Drag and drop it into the Skills section of the assistant editor. That section requires the Code Sandbox, which is on by default.
Say in the system prompt when to show it
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.
Note
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.
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.
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.
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.