ui: add read_media tool by parabelboi · Pull Request #25877 · ggml-org/llama.cpp

parabelboi · 2026-07-18T22:32:56Z

This adds a server-tool that allows vision models to analyze server-side images. It fixes #25875

Overview

This tool is reading only a single file for now:
The image data is base64 encoded and passed to the UI, which decodes it, fills the <img> tag and removes the data URI before passing the tool result back to the model.

Additional information

Requirements

I have read and agree with the contributing guidelines
AI usage disclosure: YES, brainstorming, analyzing and coding

ggml-gh-bot · 2026-07-18T22:37:40Z

Hi @parabelboi, thanks for your contribution!

Per our contribution guidelines, the automated PR checker found the following issue(s) that need your attention:

PR Template not respected: Please respect the template when creating a new pull request. Make sure to fill out all required sections.

Please note that maintainers reserve the right to make final decisions on PRs. If you believe there is a mistake, please comment below.

parabelboi · 2026-07-18T23:05:08Z

collapsed:

expanded:

allozaur

few architectural remarks. but i really like it :) great stuff. @ngxson @ServeurpersoCom u guys can do a more thorough review/testing on the server side + security aspects

allozaur · 2026-07-20T14:18:33Z

+		const extras = section.toolResultExtras;
+		if (!extras || extras.length === 0) return null;
+		// Extract the attachment name from the cleaned result text
+		const match = section.toolResult?.match(/\[Attachment saved: ([^\]]+)\]/);


let's move the regex to constants

allozaur · 2026-07-20T14:18:58Z

+		if (trimmed.startsWith('Image: ')) {
+			path = trimmed.slice('Image: '.length).trim();
+			fileName = path.split('/').pop() ?? path;
+		} else if (trimmed.startsWith('Size: ')) {
+			const match = trimmed.match(/Size:\s*(\d+)\s*bytes/);
+			if (match) sizeBytes = parseInt(match[1], 10);
+		} else if (trimmed.startsWith('MIME: ')) {
+			mimeType = trimmed.slice('MIME: '.length).trim();


magic strings/regexes — let's move to $lib/constants

allozaur · 2026-07-20T14:19:11Z

+export function parseReadImageMeta(section: AgenticSection): ReadImageMeta | null {
+	if (!section.toolResult) return null;
+
+	const lines = section.toolResult.split('\n');


should use existing NEWLINE constant

ngxson

I don't think it should be a dedicated tool. Instead, it should be read_file tool with a parameter type:

type: can be "text" or "media"; if "media", returns file content as base64 with mimetype; media file can be image, audio or video file

parabelboi · 2026-07-21T22:33:38Z

Unfortunately I see the image twice, but only directly after the tool-call. I did not notice until now, because switching to another conversation or reloading the tab makes the duplicate go away.

That must have been caused by an unclean source or build directory. After a clean checkout and rebuild the problem is gone.

parabelboi · 2026-07-22T10:01:03Z

I don't think it should be a dedicated tool. Instead, it should be read_file tool with a parameter type:
* `type`: can be `"text"` or `"media"`; if "media", returns file content as base64 with mimetype; media file can be image, audio or video file

I also thought about this, but decided to have a separate tool, because for two reasons:

First (technical) point is, that users can decide to disable read_image (or read_file) separately in the UI.
For instance, users of text-only models can simply disable read_image.
That saves some tokens when processing the context, because unneeded parameters (i.e. a potentially implemented scale_down_to_max_resolution parameter) do not have to be described to the model in that case.
The same argument would be true, if one wanted to further extend the read_file tool for videos: there you might want to have a cut_to_max_length or a skip_seconds parameter. That description would also have to be consumed by the model, if you only want it to analyze images. Also the UI should look different for videos. Does it make sense to load multiple videos at once? Maybe not, but for images it does.

Second (non-technical) point was, that it might be quicker to integrate a new tool, than to extend an existing one. It would create less friction because of separation of concerns.

ngxson · 2026-07-22T14:39:01Z

+    return (it != mime_map.end()) ? it->second : "application/octet-stream";
+}
+
+struct server_tool_read_image : server_tool {


first, I'd expect to have a generic read_media tool that allow reading image/audio/video

second, if we expect to keep read_media / read_file as separate tools, I'd expect server_tool_read_media to be a derived class of server_tool_read_file

the read_media::invoke() should do only one job: convert the output to base64 and provide the appropriate mime type

Would it be sufficient if the server_tool_read_media class is a derived class of server_tool_read_file, but would only support images (for now)?

And do you still want to have a media-type parameter and if so, would it be ok, if it's optional? Because making it mandatory and defining media-specific options based on media-type would make the json-schema more complicated.

hmm I think it's ok to allow image-only server_tool_read_media for now, maybe we should add a param type that can be image/audio/video in the future, tbd

Very good, I'll rename the tool and leave the type parameter out for now.

Also I'd concentrate to only a single file for now:
I already have a branch that reads in multiple images successfully, but that required a small fix in agentic.svelte.ts (directly after the tool call, attachments have been displayed duplicated, after a page reload everything was fine again). That could lead to a regression in mcp tools and needsmore testing especially with multiple attachments. Also it's way more code to review and test. Especially the code that collects the list of files based on a glob expression still contains bugs. So it's probably a good idea to leave that code out for now.

I managed to also get support for audio working. I currently don't have an audio capable model to test (it's still downloading), but at least the plain-text message was passed to the LLM and the audio data could be played successfully.

ngxson · 2026-07-22T14:46:54Z

The same argument would be true, if one wanted to further extend the read_file tool for videos: there you might want to have a cut_to_max_length or a skip_seconds parameter.

hmm ok maybe better to skip video for now, as the file can be large. but audio might still be a valid use case

for video, we might be better to allow /v1/chat/completion to read the file directly somehow, but I need to think more about it because that can introduce a huge security risk. the tools system doesn't apply because it's already allowed to read arbitrary files by default.

ngxson · 2026-07-24T03:02:30Z

 }

+//
+// read_media: read a media file (image or audio) and return base64-encoded data with metadata


this is not the good placement in the file, move it to after the last tool definition above

yes, indeed. section has been moved

ngxson · 2026-07-25T08:28:38Z

@ggml-gh-bot review

ggml-gh-bot · 2026-07-25T08:28:41Z

Automated code review

Review of PR #25877 - read_media server tool + UI audio-attachment support.

I ran the always-on scope/security/general checks plus the Server checklist (touched paths are tools/server/ and tools/ui/). No new model/ggml/public-API changes.

Blocking

(point 1) Audio attachments are stored with the wrong field, breaking the type contract, model input, and UI rendering. tools/ui/src/lib/stores/agentic.svelte.ts:1036-1041 pushes

{ type: AttachmentType.AUDIO, name, mimeType, base64Url: trimmedLine }

But DatabaseMessageExtraAudioFile (tools/ui/src/lib/types/database.d.ts:21-27) requires base64Data: string and has no base64Url field. Image extras use a full data URI in base64Url; audio extras use raw base64 in base64Data (see tools/ui/src/lib/utils/convert-files-to-extra.ts:80-87). Consequences:

This object literal does not satisfy the DatabaseMessageExtra union (missing required base64Data), so the change does not typecheck as written.
chat.service.ts:1252 sends audio.base64Data to the model, which is undefined here.
ChatMessageToolCallBlockReadMedia.svelte (~line 53-54) and ChatMessageToolCallBlockDefault.svelte:118 render mediaAttachment.base64Url / line.media.base64Url, which is undefined for audio, so the <audio><source src=...> is broken.

Decide on one shape and apply it consistently: either push base64Data (stripping the data:...;base64, prefix) and have the two UI components build the data URL as `data:${mimeType};base64,${base64Data}`, or extend the audio extra type to also carry a base64Url and use it everywhere. As committed the feature cannot work for audio.

(point 2) Server advertises audio formats the model-input path cannot handle. get_mime_from_extension in server-tools.cpp returns audio/opus, audio/ogg, audio/flac, audio/mp4 (m4a). But AUDIO_MIME_TO_EXTENSION (tools/ui/src/lib/constants/mcp-resource.ts) lacks audio/opus, audio/ogg, audio/flac (so those files get a wrong .mp3 attachment name), and getAudioInputFormat (chat.service.ts:46-62) only ever returns WAV or MP3 - any other audio mime is sent to the model as format: MP3 with non-MP3 data, which the input_audio API rejects. Either restrict the server tool's mime map to .wav/.mp3 (and document that), or extend both the extension map and the format mapping. Also note: files whose extension yields application/octet-stream (e.g. .svg, or any uppercase extension) are not stripped by extractBase64Attachments (agentic.svelte.ts:1000-1044), so the full multi-MB base64 data URI stays in the tool result text that flows into the model context - bound the set of accepted extensions and have the unknown case return an error instead of a data URI.

Will slow the review

(point 3) --tools help text and README list of available tools were not updated. common/arg.cpp:3168 and tools/server/README.md:200 enumerate read_file, file_glob_search, grep_search, exec_shell_command, write_file, edit_file, get_datetime - add read_media to both so --help and the docs stay in sync.

(point 4) No test for the new builtin tool. tools/server/tests/unit/test_tools_builtin.py covers read_file/write_file/edit_file/grep_search. Add a small test invoking read_media against a known fixture (assert the File:/Size:/MIME: lines and the data: URI shape, plus the too-large and bad-path error paths), matching the existing style.

Nits

(point 5) Stray duplicated // comment line above // public API in server-tools.cpp:1216-1217, and two consecutive blank lines after the server_tool_read_media struct (server-tools.cpp:1164-1166). Clean both up.

(point 6) Svelte indentation in ChatMessageToolCallBlockDefault.svelte:119-122 (and the same block in the new ChatMessageToolCallBlockReadMedia.svelte): the inner {/if} closing the audio vs img branch is indented one level deeper than its {:else}, making the if/else hard to read. Align it with the rest of the block.

(point 7) get_mime_from_extension (server-tools.cpp:1069) compares the raw extension against lowercase map keys, so .PNG/.WAV fall through to application/octet-stream. auto ext = fs::path(path).extension().string(); then lowercase ext before the lookup (consistent with IMAGE_FILE_EXTENSION_REGEX/AUDIO_FILE_EXTENSION_REGEX being case-insensitive on the UI side).

(point 8) {"size_bytes", (int)file_size} (server-tools.cpp:1163) narrows a uintmax_t to int. The 16 MB cap keeps it safe today, but prefer (size_t) (or (int64_t)) to match the (size_t) cast used in the error string just above and avoid a latent truncation if the cap is ever raised beyond INT_MAX.

Overall the metadata/parsing wiring (prefix constants on both sides, ATTACHMENT_SAVED_REGEX ↔ extractBase64Attachments ↔ parseReadMediaMeta) is a reasonable design and reuses the existing image-attachment machinery; the integration is split correctly across BuiltInTool/BUILTIN_TOOL_UI/the dispatch block. The blocking issues are the audio data-shape mismatch and the unsupported audio formats - both need resolving before this is mergeable.

This review was generated automatically by pi coding agent using zai-org/GLM-5.2. It may contain mistakes. Maintainers make the final call.

ngxson · 2026-07-25T08:38:18Z

please address point 1, 2, 3; testing is optional, but recommended to add

parabelboi · 2026-07-26T13:39:05Z

please address point 1, 2, 3; testing is optional, but recommended to add

I already tried several models with audio support, but did not get it working. I guess now I know why ;-)
Thanks for the detailed review. I just had a quick look, and everything make sense. I'll work it in during the next few days.

parabelboi · 2026-08-09T10:41:58Z

please address point 1, 2, 3; testing is optional, but recommended to add

Hi ngxson,

I addressed all three points and rebased the branch to current master.

Audio input also now works, even if the model does not support audio:
In that case the UI will popup a warning about a potentially missing mmproj file.
The user will still be able to listen to the audio file, while the model can hallucinate lyrics based on the filename ;-)
For images it should be the same, displaying in the UI always works, analyzing only if model supports it.

I'll also (try to) have a look into the remaining comments (especially the "missing testcase" one).

ngxson · 2026-08-09T11:20:46Z

/bot review

parabelboi · 2026-08-11T10:16:27Z

Hi @ServeurpersoComm,

Hi, Keeping the plain-text parsing is fine by me, we ended up doing the same on file_glob_search to keep the web UI handling simple. If @ngxson is OK with the architecture I have no objection, this tool fills an obvious need. Just drop .tiff/.webp from the image extensions since stb_image can't decode them. I'm adding the branch to my server to test it today

I made a quick code check :

Two small regressions from the rebase: tests/unit/agentic-hotpath.bench.ts still imports parseToolResultWithImages which no longer exists after the rename to parseToolResultWithMedia, and AUDIO_FILE_EXTENSION_REGEX is imported in agentic.svelte.ts but never used, which will trip eslint. Both are one-line fixes.

You are right. I think I introduced a bug with the rebase: I just tested with an audio capable model, and audio input does not work anymore. I'll have a look.
.

ngxson

@parabelboi sorry I still need to rethink this tool, I'm not convinced that it should be a server tool.

the problem is that for all other tools, the frontend simply forward the request and response between model <--> backend without any transformations. however, this is the important part: the read_media tool is not in this category, the response must be preprocess to put the base64 into the correct field of the message, it is not "just another raw json" response

in addition: frontend must switch the tool based on model's capability, backend doesn't do this. so an always-enabled read_media make no sense as it will be toggled by the frontend anyway.

so what I expect is something like this instead:

no new server tool, just extend the current read_file tool to return base64 instead (via a new header X-Resp-Type, not a param, so that it's not exposed to the LLM)
read_media will become a synthetic tool provided by the frontend

this keep the backend tool as pure i/o primitive. please follow this plan instead.

parabelboi · 2026-08-11T19:30:57Z

@parabelboi sorry I still need to rethink this tool, I'm not convinced that it should be a server tool.

the problem is that for all other tools, the frontend simply forward the request and response between model <--> backend without any transformations. however, this is the important part: the read_media tool is not in this category, the response must be preprocess to put the base64 into the correct field of the message, it is not "just another raw json" response

in addition: frontend must switch the tool based on model's capability, backend doesn't do this. so an always-enabled read_media make no sense as it will be toggled by the frontend anyway.

so what I expect is something like this instead:
1. no new server tool, just extend the current `read_file` tool to return base64 instead (via a new header `X-Resp-Type`, not a param, so that it's not exposed to the LLM)

2. `read_media` will become a synthetic tool provided by the frontend
this keep the backend tool as pure i/o primitive. please follow this plan instead.

@ngxson, I am sorry to hear that. Three weeks ago I opened an issue regarding a read_image tool and proposed a design and a draft implementation. You asked me to broaden the scope, I invested some more time and extended it. We went through some review cycles and I invested some more time to polish it. And now (two one-liners before the goal) you are asking me to go back to the start? And what if in three weeks later you (or another maintainer) would be asking me to follow yet another path?
At least you are not begging for new contributors.

ngxson · 2026-08-11T19:48:36Z

unless you can prove it otherwise, I want to point out the obvious here:

I asked out to broaden the scope (add audio) support, correct, but it has nothing to do with the point I brought in my last message ui: add read_media tool #25877 (review)
it's completely normal to maintainers to ask for extra changes - just ask an AI to verify this point. maintainers are human, if we could point you to the exact direction right from the beginning, we should have been AI, not human
I believe what I asked you is not that complicated. I can prompt an AI to do it in 5 minutes - but I didn't do that, why?

edit: sorry for being a bit harsh here, but I want to remind that this is not the only PR that I had the reviewed today. I appreciate your time & efforts, but technical requirements is till technical requirements, we cannot merge a PR that will be replaced right after it's merged

if you really don't want to continue with this PR - just tell us - I can take over it & push changes directly here if you like

ServeurpersoCom · 2026-08-11T19:48:51Z

Thanks for pushing this as far as you did, and sorry the review loop cost you so many evenings. Design churn on a tool we will have to live with for a long time is not a judgment on your work, it is just how these things settle, and with today's AI tooling a prototype is cheap enough that throwing one away is a normal step rather than a loss. If you would rather stop here, that is completely fine: once the design is settled with ngxson I can rewrite it from scratch in a few hours, and that is only possible because your attempt mapped out the paths that do not work. The feature is wanted, so it will land either way.

parabelboi · 2026-08-11T20:39:54Z

unless you can prove it otherwise, I want to point out the obvious here:

1. I asked out to broaden the scope (add audio) support, correct, but it has nothing to do with the point I brought in my last message [server: add read_media tool #25877 (review)](https://github.com/ggml-org/llama.cpp/pull/25877#pullrequestreview-4905412320)

2. it's completely normal to maintainers to ask for extra changes - just ask an AI to verify this point. maintainers are human, if we could point you to the exact direction right from the beginning, we should have been AI, not human

3. I believe what I asked you is not that complicated. I can prompt an AI to do it in 5 minutes - but I didn't do that, why?

@ngxson:
I don't want to prove anything here. I respect your design decision and I am sure it will be better at the end.
The whole point is about your bad timing:
You had almost two weeks to think through the design (with a working prototype in front of you).
I started to invest brain cycles with the rebasing and polishing. That was the time consuming part.
You should have asked me to follow the better approach maybe just two days earlier.
And now you are arguing that anybody can do it with AI in 5 minutes. Not helpful either.

parabelboi · 2026-08-11T20:48:57Z

edit: sorry for being a bit harsh here, but I want to remind that this is not the only PR that I had the reviewed today. I appreciate your time & efforts, but technical requirements is till technical requirements, we cannot merge a PR that will be replaced right after it's merged

if you really don't want to continue with this PR - just tell us - I can take over it & push changes directly here if you like

I think that would be good.

ngxson · 2026-08-11T21:22:14Z

You had almost two weeks to think through the design (with a working prototype in front of you).
I started to invest brain cycles with the rebasing and polishing. That was the time consuming part.
You should have asked me to follow the better approach maybe just two days earlier.

if I knew about it beforehand but intentionally held off and only told you afterwards, that would have been 100% my fault. but the reality: I only thought about it today. your blaming is wrong here

that being said, I will take over this PR as you confirmed above

parabelboi · 2026-08-11T21:30:08Z

You had almost two weeks to think through the design (with a working prototype in front of you).
I started to invest brain cycles with the rebasing and polishing. That was the time consuming part.
You should have asked me to follow the better approach maybe just two days earlier.

if I knew about it beforehand but intentionally held off and only told you afterwards, that would have been 100% my fault. but the reality: I only thought about it today. your blaming is wrong here

that being said, I will take over this PR as you confirmed above

Sorry, I did not want to imply intentional holding off. Let me rephrase it:
If you'd have asked me two days earlier, to follow the better approach, I'd have appreciated it.

ngxson · 2026-08-11T21:57:53Z

Tested:

If vision-only model attempt to load audio file:

ngxson · 2026-08-11T22:00:07Z

can be merged after @allozaur or @ServeurpersoCom review the UI part

parabelboi · 2026-08-11T22:48:10Z

Tested:

... also good on my side.

And thanks for taking over. This is now of course the better solution. I was just a bit frustrated about the wasted time. Well not a total waste, because I learnt something of course ;-)

alan-l · 2026-08-12T03:50:39Z

With bated breath, I await this beast to be released!
I'm wondering if this tool will accommodate reading PDFs in vision mode? I would love to point the AI at a directory and have it read all PDFs I put in there.

allozaur

Few architectural nits. Let's address them and then we good to go

Replace the magic strings, regexes and number in the read_media parser and service with named constants. Path splitting reuses FILE_PATH_SEPARATOR_REGEX, the size header regex moves to READ_MEDIA_SIZE_REGEX derived from PREFIX_SIZE, and FILE_EXTENSION_SEPARATOR lands next to it in constants/code.ts.

allozaur · 2026-08-12T07:15:52Z

@ngxson GH blocks merging unless u approve as u requested changes earlier

ServeurpersoCom · 2026-08-12T07:21:35Z

Noticed a few minor (display) issues while reviewing, nothing blocking. Will follow up in a separate PR :)

Signed-off-by: Gabe Goodhart <ghart@us.ibm.com> * origin/master: (383 commits) cmake : introduce semantic versioning (ggml-org#26839) gguf : harden loader against malformed tensor dims and metadata types (ggml-org#25596) kleidiai: Add runtime feature detection mechanism for aarch64/kleidiai (ggml-org#26076) model : disallow integer dflash sliding_window_pattern (ggml-org#26900) sync : ggml cmake : add config version support (ggml/1582) server : support slot save/restore with media inputs (ggml-org#26640) ui: add read_media tool (ggml-org#25877) opencl: default FA c8 cluster width to 16 on X1E (ggml-org#26433) tests : update speculative params (ggml-org#26925) vulkan: add TQ2_0 (ternary) support (ggml-org#25850) wavtokenizer-dec : bound posnet/convnext block_count against n_layer_all (ggml-org#26892) convert : handle per_layer_config in Gemma4 (transformers 5.15) (ggml-org#26882) opencl: use flat mv q5_k when weight exceeds image1d_buffer_t limit (ggml-org#26880) chat : fix muse-glimmer detection of tool calls after EOM (ggml-org#26879) ci : add missing release check (ggml-org#26923) CUDA: only disable CUDA graphs when mul_mat_id actually needs a stream sync (ggml-org#26802) cuda : add warp-per-row wkv7 kernel for single-token decode (ggml-org#26111) spec : update speculative-simple (ggml-org#26904) chat : tighten bare function parsing for Qwen models (ggml-org#26793) ...

* server: add read_image tool (ggml-org#25875) Adds a server-tool that allows vision models to analyze server-side images. This tool is reading a single file for now: The image data is base64 encoded and passed to the UI, which decodes it, fills the <img> tag and removes the data URI before passing the tool result back to the model. * cleanup read_image tool: move magic strings to constants * Add dedicated constants file: tools/ui/src/lib/constants/read-image.ts with PREFIX_IMAGE, PREFIX_SIZE, PREFIX_MIME constants * Use ATTACHMENT_SAVED_REGEX from agentic.ts in ChatMessageToolCallBlockReadImage.svelte * Use NEWLINE constant from code.ts instead of hardcoded '\n' * Use PREFIX_SIZE in regex pattern for size parsing * Add SERVER_TOOL_READ_IMAGE_PREFIX_* constants in C++ server-tools.cpp to match the TypeScript PREFIX_* constants for consistency * server: rename read_image tool to read_media for images and audio * Rename server_tool_read_image to server_tool_read_media in C++ * Rename enum BuiltInTool.READ_IMAGE to READ_MEDIA * Rename UI constants, parser, and Svelte component files * Update display label from 'Read image' to 'Read media' * ui: consolidate audio data URI handling into shared utility * Extract getAudioInputFormat to a shared utility (was duplicated inline) * Store raw base64 in base64Data on the message object * Use base64Data to construct data URIs for audio rendering * Update agentic store to build INPUT_AUDIO parts from base64Data * server: read_media: restrict audio to wav/mp3 and minor fixes * Server get_mime_from_extension now only advertises audio/wav and audio/mpeg (the only formats the model's input_audio API accepts) * Case-insensitive extension matching (fixes .MP3, .Wav, etc.) * Unknown extensions return an error instead of a multi-MB data URI that inflates model context with garbage * Updated tool description to document supported formats * Frontend AUDIO_MIME_TO_EXTENSION trimmed to match server * fix a missing import in tools/ui/src/lib/stores/agentic.svelte.ts * server: read_media: add to --tools help text and README tool list * ui: fix indentation in ChatMessageToolCallBlockDefault.svelte * server: read_media tool: fix a cast to use the correct type * server: read_media: multiple fixes * server-tools.cpp import cctype, remove UTF-8 char, check mime before reading file * ui: add MimeTypePrefix.AUDIO and use it in agentic.svelte.ts * server: make read_media inherit from read_file and add uses_cwd * ui: fix formating issues * rm from server * move it to frontend-only tool * correct partial commit * rm unused * ui: address review from allozaur Replace the magic strings, regexes and number in the read_media parser and service with named constants. Path splitting reuses FILE_PATH_SEPARATOR_REGEX, the size header regex moves to READ_MEDIA_SIZE_REGEX derived from PREFIX_SIZE, and FILE_EXTENSION_SEPARATOR lands next to it in constants/code.ts. --------- Co-authored-by: ckrafft <ckrafft@epyc> Co-authored-by: Xuan Son Nguyen <son@huggingface.co> Co-authored-by: Pascal <admin@serveurperso.com>

parabelboi requested review from a team as code owners July 18, 2026 22:32

github-actions Bot added server server/ui labels Jul 18, 2026

parabelboi changed the title ~~server: add read_image tool (#25875)~~ server: add read_image tool Jul 18, 2026

allozaur requested changes Jul 20, 2026

View reviewed changes

parabelboi requested a review from allozaur July 20, 2026 19:13

allozaur requested review from ServeurpersoCom and ngxson July 20, 2026 21:58

ngxson requested changes Jul 21, 2026

View reviewed changes

ngxson reviewed Jul 22, 2026

View reviewed changes

parabelboi requested a review from ngxson July 23, 2026 18:47

parabelboi changed the title ~~server: add read_image tool~~ server: add read_media tool Jul 23, 2026

ngxson reviewed Jul 24, 2026

View reviewed changes

parabelboi force-pushed the add-read_image-tool branch 2 times, most recently from 23ee634 to 2ac20c5 Compare August 9, 2026 10:26

parabelboi requested a review from a team as a code owner August 9, 2026 10:26

github-actions Bot added the documentation Improvements or additions to documentation label Aug 9, 2026

parabelboi requested a review from ngxson August 9, 2026 10:42

ngxson requested changes Aug 11, 2026

View reviewed changes

ngxson added 2 commits August 11, 2026 23:45

rm from server

ad72f21

move it to frontend-only tool

ffbcaa7

correct partial commit

bf610f1

ngxson changed the title ~~server: add read_media tool~~ ui: add read_media tool Aug 11, 2026

rm unused

5c39e36

allozaur requested changes Aug 12, 2026

View reviewed changes

ServeurpersoCom approved these changes Aug 12, 2026

View reviewed changes

allozaur approved these changes Aug 12, 2026

View reviewed changes

ServeurpersoCom requested a review from ngxson August 12, 2026 07:15

allozaur added the merge ready A maintainer can use this label to indicate that they consider the changes final and ready to merge. label Aug 12, 2026

ngxson merged commit 4dd1275 into ggml-org:master Aug 12, 2026
25 of 31 checks passed

parabelboi deleted the add-read_image-tool branch August 12, 2026 19:25

Uh oh!

Conversation

parabelboi commented Jul 18, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Overview

Additional information

Requirements

Uh oh!

ggml-gh-bot Bot commented Jul 18, 2026

Uh oh!

parabelboi commented Jul 18, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

allozaur left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ngxson left a comment

Choose a reason for hiding this comment

Uh oh!

parabelboi commented Jul 21, 2026

Uh oh!

parabelboi commented Jul 22, 2026

Uh oh!

ngxson Jul 22, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

parabelboi Jul 22, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

parabelboi Jul 23, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ngxson commented Jul 22, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ngxson commented Jul 25, 2026

Uh oh!

ggml-gh-bot Bot commented Jul 25, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Blocking

Will slow the review

Nits

Uh oh!

ngxson commented Jul 25, 2026

Uh oh!

parabelboi commented Jul 26, 2026

Uh oh!

parabelboi commented Aug 9, 2026

Uh oh!

ngxson commented Aug 9, 2026

Uh oh!

parabelboi commented Aug 11, 2026

Uh oh!

ngxson left a comment

Choose a reason for hiding this comment

Uh oh!

parabelboi commented Aug 11, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ngxson commented Aug 11, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

parabelboi commented Jul 18, 2026 •

edited

Loading

parabelboi commented Jul 18, 2026 •

edited

Loading

ngxson Jul 22, 2026 •

edited

Loading

parabelboi Jul 22, 2026 •

edited

Loading

parabelboi Jul 23, 2026 •

edited

Loading

ggml-gh-bot Bot commented Jul 25, 2026 •

edited

Loading

parabelboi commented Aug 11, 2026 •

edited

Loading

ngxson commented Aug 11, 2026 •

edited

Loading

ngxson commented Aug 11, 2026 •

edited

Loading