Repository navigation
id: research: image/video conversion tooling — kitty graphics protocol and video-to-ASCII #5971
Description
Part of the worlds design program: #5955. Statements S73–S74 of the 2026-11-04 brief. Filed as dedicated research per Drew's rule for sub-parts needing their own documentation.
Task (Drew, in substance)
We need a basic system to convert images and videos into the kitty protocol, and there are also IDF video-to-ASCII tools out there — some of those might be used as well. Survey what exists before building anything:
- Kitty graphics protocol: encoder/tooling landscape (library support, terminal support matrix), stills vs animation/video over the protocol, bandwidth and chunking behavior.
- Adjacent terminal graphics: sixel, iTerm2 inline images — only insofar as the fallback tiers need them.
- Video-to-ASCII: the IDF tools Drew names and the wider field (jp2a-style stills pipelines,
mpvASCII outputs, dedicated converters) — quality, speed, color fidelity, licensing (this feeds the licensing program too: a converter's license constrains bundling). - Where conversion should live: upload-time (presentation-layer conversion tools, per the assets design child of #5955), client-side at render time, or both for different tiers.
Not this
#787 is the kitty keyboard protocol on the raw input path — a different protocol that happens to share the terminal. This research is graphics/media only; don't merge the two.
Done looks like
A research doc: tooling survey with licenses, a recommended converter pipeline per tier (kitty graphics / ASCII video / static ASCII), and the conversion-placement decision with reasons.
Activity
developing-today commentedon Nov 5, 2026
CODE-1637
dezren39 commentedon Nov 5, 2026
🤖 Agent note · done
Triage findings (verified fresh 2026-11-05):
task/triage,status/needs-triage,priority/low,queue/queued,app/id,kind/design— no hard-stop labels (held,user/owned,do-not-merge,do-not-auto-edit).priority/low, and not superseded or already handled.