Ollama OCR with URLs fails where filepaths succeed

[simonw]

Really weird bug. I wrote about this here: https://simonwillison.net/2025/May/18/qwen25vl-in-ollama/

llm install llm-ollama
ollama pull qwen2.5vl

llm -a https://static.simonwillison.net/static/2025/poster.jpg \
  'convert to markdown' -m qwen2.5vl

I got back:

It looks like the image you provided is a jumbled and distorted text, making it difficult to interpret. If you have a specific question or need help with a particular topic, please feel free to ask, and I'll do my best to assist you!

But... the same exact prompt after downloading the file gives a much better result:

wget https://static.simonwillison.net/static/2025/poster.jpg
llm -m qwen2.5vl 'convert to markdown' -a poster.jpg

https://gist.github.com/simonw/2b46e932a16c92e673ea09dfc0186ec2

[simonw]

I thought maybe llm-ollama was sending the URL to the server instead of the base64 bytes (like you can do with OpenAI) and as a result it got different output - but no, that's not how that code works: https://github.com/taketwo/llm-ollama/blob/df288b839933e489a6c9e7d19861ef4d25c91707/llm_ollama/__init__.py#L156-L166

    def build_messages(self, prompt, conversation):
        messages = []
        if not conversation:
            if prompt.system:
                messages.append({"role": "system", "content": prompt.system})
            messages.append({"role": "user", "content": prompt.prompt})
            if prompt.attachments:
                messages[-1]["images"] = [
                    attachment.base64_content() for attachment in prompt.attachments
                ]
            return messages

It makes no sense to me why that would behave differently for a URL v.s. a filepath:

llm/llm/models.py

Lines 84 to 96 in f320de1

	def content_bytes(self):
	content = self.content
	if not content:
	if self.path:
	content = open(self.path, "rb").read()
	elif self.url:
	response = httpx.get(self.url)
	response.raise_for_status()
	content = response.content
	return content
	def base64_content(self):
	return base64.b64encode(self.content_bytes()).decode("utf-8")

[simonw]

Next steps to investigate: add a breakpoint to llm-ollama, grab the base64 encoded string from both a URL and a filepath for this image, save and decode that base64 and compare them to see if there are any differences.

[rishabh1024]

Can I take up this issue?

[andrejartuchov-prog]

On current main / llm 0.31 + llm-ollama 0.16.1 I couldn't reproduce a code-path difference: Attachment.content_bytes() returns byte-identical data for the URL and the downloaded file (same sha256, 514141 bytes, resolve_type image/jpeg for both), so llm-ollama sends the exact same base64 payload to Ollama either way. Since the bytes reaching the model are identical, the different OCR output looks like qwen2.5-VL nondeterminism rather than an attachment bug — possibly already resolved since the May 2025 report.

One separate, real thing worth noting: content_bytes() uses httpx.get(url) without follow_redirects=True, so any image URL that 30x-redirects would fetch the redirect body instead of the image (this particular URL returns 200 directly, so it isn't the cause here). Looks like #1421 already proposes adding follow_redirects for exactly that.