Images

Several std-tools tools return an image for the model to look at. Since 0.6.0, every one of them first brings the image within limits that every supported model provider accepts, so a large photo or a high-resolution page no longer fails the model request — and with it the agent's turn.

Which tools scale

Tool	Server
read_image	Documents
render_document_page	Documents
render_document_thumbnail	Documents
read_document_pages_as_images	Documents
take_screenshot	Screenshot
fetch_image	Web
browser_screenshot, browser_zoom, and images from browser_run_script	Browser
computer_screenshot, computer_zoom	Computer (Desktop)

Only the image returned to the model is scaled. A file a tool writes to an output_path keeps its full resolution, and tools that write files and return paths — the Image Tools server and convert_document — do not scale at all.

The limits

Variable	Default	Limit
DPTTOOLS_IMAGE_MAX_EDGE_PX	1568	The longest side, in pixels
DPTTOOLS_IMAGE_MAX_MB	3	The encoded file size, in megabytes

Both are read once per process and must be positive integers.

The defaults come from the strictest values across the providers doc-processing-toolkit supports, as its model registry records them:

Provider	Longest side	File size
Anthropic	1568 px	5 MB
OpenAI	2000 px	20 MB
Google	—	20 MB
Fireworks	—	10 MB

The size limit is 70 % of the smallest provider limit, rounded down, because sending an image as base64 adds about a third to its size. An image within both defaults is safe on every provider. Raise them only if every model you use accepts more; larger images also cost more image tokens.

How an image is scaled

1. An image within both limits is returned unchanged, byte for byte, in its own format.
2. Otherwise it is resized with a Lanczos filter so its longest side fits, keeping the aspect ratio. Images are never enlarged.
3. It is encoded as PNG if the source was PNG or has transparency, and as JPEG (quality 85) otherwise.
4. While it is still over the size limit:
   • a JPEG steps its quality down, 85 → 75 → 65;
   • a PNG without transparency switches to JPEG;
   • then the scale shrinks by 15 % and the steps repeat. A PNG with transparency only shrinks.
5. If the image would have to shrink below 256 px on its longest side, the tool returns an Error: suggesting a larger DPTTOOLS_IMAGE_MAX_MB or a crop.

A scaled animated GIF or multi-page TIFF keeps only its first frame.

Some sizes at the defaults:

Source	Sent to the model
A 1440 × 900 screenshot	Unchanged
A 1920 × 1080 screenshot	1568 × 882
Two full-HD monitors, 3840 × 1080	1568 × 441
An A4 page rendered at scale=2.0, 1190 × 1684	1108 × 1568
A 4000 × 3000 JPEG photo	1568 × 1176 JPEG

Tips

• Crop rather than shrink for detail. When small print matters, cut out the region first with image_crop or image_zoom, then read_image the result: the region is then sent at full detail.
• Check before sending. get_image_metadata and image_get_info report an image's size without sending the pixels.
• In-process use needs toolkit 0.5.1 or later for any image result to reach the model as an image. See Compatibility.

Coordinates in the browser and computer servers

browser_screenshot and browser_zoom pass through the same scaling, and the scaling step reports the factor it applied. The browser server keeps that factor per tab, so when the model gives x and y in screenshot pixels, the server maps them back to real page pixels before it clicks. At the default viewport of 1440 × 900 nothing is scaled, so the factor is 1.

The computer server works the same way (new in 0.6.0): x and y are in the pixels of the latest computer_screenshot. The default virtual display, 1440 × 900, is sent unchanged. A real screen in host mode is often larger: a 1920 × 1080 monitor is sent as 1568 × 882, and every coordinate the model sends is mapped back to real pixels. The screenshot's result text gives both sizes, for example "Screenshot of monitor 1 (1920x1080, scaled to 1568x882)." computer_zoom enlarges a region up to 4× to read small text.