dsh-read-animation

dsh-read-animation

A DeepSeek Harness plugin that lets the agent actually see an animated GIF.

read_image on a GIF gives the model one picture — the first frame — and no

signal that the other frames existed. This plugin decodes every frame and hands

the model a labelled sequence of real frames sampled across the animation's

timeline.

dsh plugin --profile web add dsh-read-animation

---

The problem

DeepSeek Harness normalizes every stored image to a single-frame 8-bit sRGB

raster before it reaches a model, and it does this to animations too.

@deepseek-ai/dsh-attachment-local excludes image/gif from its pass-through

path and re-encodes through a pipeline that never sets animated or page, so

sharp returns page 0 and the rest are dropped on the floor.

Measured, on this machine, against an 8-frame GIF:

metadata:  {"format":"gif","width":240,"height":160,"pages":8,
            "delay":[80,80,80,80,80,80,80,80],"loop":0}
default -> 240x160  pages=1     ← what read_image delivers
animated -> 240x1280 pages=1    ← all eight frames, when asked for

No layer above the read step can repair this. By the time a vision plugin, an

image router, or the LLM adapter sees the image it is already a single frame —

which is why the growing ecosystem of DSH vision plugins

([dsh-multimodal](https://github.com/SCT192221/dsh-multimodal),

[dsh-mmroute](https://github.com/jmxsxwyzjdwl/dsh-mmroute),

[dsh-vision-mix](https://github.com/haiziyao/dsh-vision-mix),

[dsh-tool-plus](https://github.com/xiaoso456/dsh-tool-plus), …) all say they

"support PNG/JPEG/WebP/GIF" without any of them showing you motion. The

animation is still intact in exactly one place: the file. So the tool lives

there.

Animated PNG has the same disease with a worse prognosis: libvips 8.18.7 does

not read acTL/fcTL/fdAT at all, reports an APNG as a one-page PNG, and

silently discards every frame after the first. This plugin detects that case from

the chunk stream and refuses it by name instead of returning frame 0.

Two ways in, both handled

Pasting into the chat box. That path is already clean on the browser side: the

paste handler hands the clipboard's own File straight to the upload path, and

that path encodes image/gif and image/webp unchanged (imageMediaType()

accepts both and returns them as-is) — no canvas, no drawImage, no toBlob.

The bytes reach the Host whole. The Host normalizes them through

attachments.saveImages. In DSH 0.2.2 this happens during upload, so prompt

admission receives an already-stored image reference.

The plugin wraps saveImages, captures the animation from its raw inputs, and

stores the original and decoded frames against the returned image reference.

This covers raw uploads and older encoded-prompt admission:

you paste 1 animation
   ├─ the message: unchanged — the picture you sent, not one word added
   ├─ the UI: the animation itself, played from the original bytes
   └─ the model: one sheet of its frames, each labelled with index and time

What you send is what you send. Nothing is added to the message you wrote,

and it does not turn into eight stills.

And it keeps playing in the UI. The Web UI has exactly one way to display a

durable image: session.readAttachment(id) → the Host's

ctx.attachments.readImage(ref) →

URL.createObjectURL(new Blob([bytes], { type: attachment.mediaType })). Both the