1987年4月，Digital Equipment Corporation（DEC）发布了一款售价2795美元的彩色图形终端VT340。这台看似普通的设备悄然开启了一场持续近四十年的技术革命：如何在纯文本的终端环境中显示图形图像。从最初的Sixel位图格式到今天Kitty终端的高性能图形协议，终端图形显示技术经历了从硬件约束到软件创新、从专有标准到开放协议的完整演进。
字符世界的图形梦想
终端的本质是字符设备。从电传打字机时代继承下来的架构决定了终端的基本工作模式：接收字符流、渲染字形、滚动屏幕。这种设计在1970年代是合理的——2400bps的调制解调器无法传输大量像素数据，硬件终端也没有足够的内存存储位图。但当计算机图形学在1970年代末开始蓬勃发展时，终端的纯文本限制变得越来越明显。
flowchart TB
subgraph 终端架构演进
direction LR
A[电传打字机<br/>1960s] --> B[字符终端<br/>1970s]
B --> C[图形终端<br/>1980s]
C --> D[终端模拟器<br/>1990s+]
end
subgraph 技术约束
E[低带宽串口<br/>2400-9600bps]
F[有限内存<br/>几KB到几十KB]
G[硬件渲染限制<br/>字符ROM]
end
D --> H[现代终端图形协议<br/>突破纯文本限制]
DEC的工程师们面临一个根本性的技术挑战：如何在保持终端协议兼容性的前提下引入图形能力？解决方案必须满足几个约束条件：传输数据量要小（适应低速串口连接）、实现要简单（终端硬件资源有限）、要与现有文本协议共存（不能破坏向后兼容性）。
Sixel正是在这些约束下诞生的精巧设计。它的核心思想是将图像编码为可打印字符序列，使图形数据可以通过现有的终端协议传输。这种"带内信令"的方式意味着任何能处理文本的程序都能处理图形，只要终端理解Sixel编码。
Sixel：压缩的艺术
Sixel的名字来源于"six pixels"——六个像素。这个命名揭示了它的编码原理：将图像分割为6像素高的水平条带，每条带用一个ASCII字符表示。具体来说，字符码63（问号?）到126（波浪号~）分别表示0到63的二进制模式，正好覆盖6位二进制数能表示的全部64种像素组合。
flowchart TB
subgraph 原始图像
pixels[像素矩阵]
end
subgraph Sixel编码过程
split[分割为6像素高的条带]
encode[每条带编码为一个字符]
compress[运行长度编码压缩]
output[输出DCS序列]
end
pixels --> split
split --> encode
encode --> compress
compress --> output
subgraph 解码示例
char["字符 '~' (ASCII 126)"]
binary["二进制: 111111"]
pixels2["6个像素全部点亮"]
end
char --> binary --> pixels2
完整的Sixel序列使用设备控制字符串（DCS，Device Control String）封装。DCS是ECMA-48标准定义的控制序列类型，格式为DCS P1;P2;P3 q <sixel数据> ST，其中ST是字符串终止符。三个参数各有特定含义：P1控制像素宽高比，P2决定背景像素的处理方式，P3在VT300系列中被忽略。
flowchart LR
subgraph DCS序列结构
direction TB
A["DCS (0x90)"]
B["P1 宽高比参数"]
C["; 分隔符"]
D["P2 背景模式"]
E["; 分隔符"]
F["P3 水平网格"]
G["q 命令标识"]
H["Sixel数据"]
I["ST (0x9C)"]
end
A --> B --> C --> D --> E --> F --> G --> H --> I
颜色处理是Sixel设计中最精巧的部分。VT340支持16个颜色寄存器，每个寄存器可以存储RGB或HLS颜色值。图像中的像素不直接指定颜色，而是引用寄存器编号。这种间接寻址方式带来两个好处：大幅减少数据量（颜色只需定义一次），以及允许应用程序动态修改调色板实现动画效果。
flowchart TB
subgraph Sixel颜色系统
direction TB
subgraph 颜色定义阶段
A["#0;2;100;50;25"] --> B["定义寄存器0<br/>RGB: 100%, 50%, 25%"]
C["#1;2;0;100;0"] --> D["定义寄存器1<br/>纯绿色"]
end
subgraph 颜色使用阶段
E["#0~"] --> F["使用寄存器0<br/>绘制黄色像素"]
G["#1!10~"] --> H["使用寄存器1<br/>绘制10个绿色像素"]
end
end
B --> F
D --> H
Sixel的控制函数设计体现了对带宽效率的极致追求。重复引入符!允许用!N字符的格式将一个字符重复N次，对于大面积相同颜色的图像区域尤其有效。颜色引入符#切换当前颜色寄存器，光栅属性符"设置像素尺寸和图像边界。这些控制函数可以自由组合，形成紧凑的图形描述语言。
VT340的实际硬件实现揭示了一些有趣的工程权衡。终端有独立的图形平面和文本平面，图形不会覆盖文本，而是与文本共存于屏幕上。颜色调色板是全局资源——虽然协议允许定义256个颜色寄存器，但VT340硬件只能同时使用16个。后来的终端模拟器如mlterm和XTerm扩展了这个限制，支持最多256个颜色寄存器。
Sixel的滚动行为值得特别关注。VT340引入了Sixel显示模式（DECSDM）控制序列CSI?80h/l来控制图形的滚动行为。当启用滚动模式时，图形从当前光标位置开始绘制，如果超出屏幕底部则向上滚动。禁用滚动模式时，图形固定在图形页面的左上角，超出边界的部分被裁剪。这两种模式适用于不同的应用场景：前者适合内联图形，后者适合全屏图形应用。
ReGIS：矢量的另一种可能
在讨论终端图形协议时，不能忽略DEC同时引入的另一种图形系统：ReGIS（Remote Graphic Instruction Set）。如果说Sixel是位图格式，ReGIS就是矢量图形语言。它使用类似Logo语言的命令式语法，通过P[position]设置当前位置，V[vector]画线，C[circle]画圆，S[shade]填充区域。
flowchart LR
subgraph 图形格式对比
direction TB
subgraph Sixel位图
A["存储每个像素颜色"]
B["适合照片类图像"]
C["数据量较大"]
end
subgraph ReGIS矢量
D["存储几何命令"]
E["适合图表类图像"]
F["数据量小"]
end
end
G[圆形] --> H["Sixel: ~200字节"]
G --> I["ReGIS: C[50] ~5字节"]
ReGIS的设计哲学与Sixel截然不同。Sixel是图像的紧凑编码，ReGIS是图形的描述语言。对于由几何形状组成的图像，ReGIS的描述通常比Sixel的像素数据小得多。一个简单的例子是画一个圆：Sixel需要编码圆覆盖的每个像素，ReGIS只需要C[100]（半径100的圆）。
然而ReGIS在现代终端生态中几乎消失了。原因很复杂：矢量图形的渲染比位图复杂，需要终端实现完整的几何算法；ReGIS命令序列不像Sixel那样易于与现代图像处理库集成；最重要的是，现代显示器的高分辨率使得位图的视觉效果通常优于低分辨率矢量渲染。
但ReGIS的精神在某些现代协议中得到了延续。Kitty图形协议的z-index分层、透明度混合等功能，本质上是在追求ReGIS所设想的"图形与文本深度融合"的目标，只是采用了更现代的技术手段。
协议割据时代
VT340的成功（以及后来的VT330、VT382等型号）确立了Sixel作为终端图形标准的地位。但标准的确立并不意味着统一的实现。不同厂商的终端在Sixel的实现细节上存在微妙差异：颜色寄存器数量、调色板独立性、滚动行为等。这些差异在图形应用开发者面前埋下了兼容性地雷。
flowchart TB
subgraph 终端图形协议生态
direction TB
subgraph 传统协议
A[Sixel<br/>1987-]
B[ReGIS<br/>1987-]
end
subgraph 现代协议
C[Kitty Graphics<br/>2017-]
D[iTerm2 Inline<br/>2014-]
end
subgraph 支持终端
E[XTerm]
F[mlterm]
G[Kitty]
H[WezTerm]
I[iTerm2]
J[Windows Terminal]
end
end
A --> E
A --> F
A --> H
A --> J
B --> E
C --> G
C --> H
D --> I
D --> H
1990年代中期，两个趋势开始改变终端图形生态。第一是X Window System的普及使图形终端的需求下降——如果工作站可以直接运行图形应用，为什么还要在终端里显示图形？第二是PC终端模拟器的兴起带来了新的实现平台。XTerm作为X Window的标准终端模拟器，在很长一段时间内是唯一支持Sixel的主流软件。
这种状况在2010年代中期开始改变。日本开发者saitoha创建了libsixel项目，为Sixel带来了现代化的编码器和解码器实现。这个项目的重要意义在于它重新优化了Sixel编码算法——原始的ppmtosixel工具是为点阵打印机设计的，目标是减少打印头移动距离；libsixel则为终端模拟器优化，目标是减少序列长度和渲染时间。
libsixel引入了几项关键改进。高质量量化算法使用中位数切割（median-cut）方法将真彩色图像转换为有限调色板，效果明显优于传统的Floyd-Steinberg抖动。动态调色板优化避免了为简单图像保留完整256色调色板的开销。最重要的是，libsixel提供了完整的C API，使任何程序都能轻松集成Sixel输出能力。
另一个重要里程碑是mlterm终端模拟器。它的开发者arakiken不仅实现了完整的Sixel支持，还编写了详细的技术文档解释如何生成高质量的Sixel输出。这些知识后来被整合到libsixel中，成为开源社区共享的技术财富。
现代协议的崛起
Sixel的复兴遇到了一个根本性的限制：它毕竟是1980年代的技术，设计目标是在低速串口上传输图形。现代终端面临的需求完全不同：高分辨率显示器需要大量像素数据、远程桌面需要高效压缩、图形与文本需要复杂的混合渲染。
Kitty终端的图形协议代表了现代设计思路。它的核心原则是"终端不需要理解图像格式"——客户端发送原始像素数据或PNG压缩数据，终端负责渲染。这种分工让终端模拟器的实现变得简单，同时让客户端能够选择最优的传输格式。
Kitty协议使用应用编程命令（APC，Application Programming Command）序列封装，格式为ESC_G<控制数据>;<负载>ESC\。控制数据是逗号分隔的键值对，负载数据经过Base64编码以避免与终端控制字符冲突。协议支持多种像素格式：24位RGB、32位RGBA、以及PNG格式。PNG格式特别有趣——它允许客户端利用PNG的高效压缩，同时让终端直接解码渲染。
flowchart TB
subgraph Kitty协议传输方式
direction TB
subgraph 本地传输
A[图像数据] --> B[写入文件/共享内存]
B --> C[发送路径给终端]
C --> D[终端直接读取]
end
subgraph 远程传输
E[图像数据] --> F[Base64编码]
F --> G[分块传输<br/>每块≤4096字节]
G --> H[终端解码渲染]
end
end
subgraph 关键参数说明
I["f=格式<br/>24/32/100(RGB/RGBA/PNG)"]
J["s=宽度, v=高度"]
K["a=动作<br/>T传输/p放置/q查询"]
L["t=传输方式<br/>d直接/f文件/s共享内存"]
M["z=z-index<br/>负值=文本下方"]
end
传输介质的多样性是Kitty协议的另一大创新。对于本地应用，协议支持直接文件路径和共享内存对象——终端直接读取文件，避免了数据拷贝。对于远程应用，协议定义了分块传输机制：将Base64编码的负载数据分割为不超过4096字节的块，每块用m=1标记（最后一块为m=0）。这种设计在SSH等协议限制单个转义序列长度时特别有用。
Kitty协议的查询机制解决了终端能力检测的难题。客户端可以发送带有图像ID（i参数）的图形命令，终端会响应成功或失败消息。更优雅的是查询动作a=q——终端尝试验证数据但不存储图像，这为协议支持检测提供了可靠方法。
z-index分层渲染是Kitty协议最具野心的功能。负值z-index的图形渲染在文本下方，正值渲染在文本上方，相同z-index的图形按ID顺序叠加。这让文本与图形的复杂混合布局成为可能——可以在图像上叠加半透明文本，也可以让图像作为文本背景。
Unicode占位符是Kitty协议的又一精巧设计。通过特殊字符U+10EEEE和前景色编码图像ID，应用程序可以在任何支持Unicode的程序中嵌入图形占位符。文本编辑器、终端复用器（如tmux）会在移动文本时自动移动占位符，终端则负责在占位符位置渲染实际图像。这种设计巧妙地绕过了tmux等程序不理解图形协议的障碍。
iTerm2的Inline Images Protocol采取了不同的技术路线。它使用OSC 1337序列（ESC]1337;File=...BEL），设计目标是简单易用。协议支持多种尺寸指定方式：字符单元格数、像素数、百分比、自动。内联参数inline=1决定图像是直接显示还是下载到文件。
iTerm2协议的一个实用特性是支持GIF动画。当图像是动态GIF时，终端自动播放动画帧。这在显示系统监控图表、演示动画等场景中非常有用。协议还支持文件传输——省略inline参数时，终端将数据保存为文件而非显示图像。
WezTerm采取了"全都要"的策略，同时支持Sixel、Kitty协议和iTerm2协议。这种务实做法反映了终端图形协议的当前困境：没有单一标准，不同应用依赖不同协议，终端必须实现多种协议才能提供良好的兼容性。
实现的艺术
终端图形显示的实现涉及许多不明显的工程挑战。最基本的问题是图像与文本的混合渲染——图像占据屏幕空间，但文本光标如何移动？滚动时图像如何处理？
flowchart TB
subgraph 图形与文本混合渲染挑战
direction TB
subgraph 光标移动
A[放置图像后] --> B{光标如何移动?}
B --> C[移动图像宽度列]
B --> D[移动图像高度行]
B --> E[保持不动 C=1]
end
subgraph 滚动处理
F[用户滚动历史] --> G{图像如何处理?}
G --> H[随文本滚动]
G --> I[固定位置]
G --> J[进入历史缓冲区]
end
subgraph 调色板冲突
K[图像调色板] --> L[文本ANSI颜色]
L --> M[如何隔离?]
M --> N[独立调色板]
M --> O[全局调色板]
end
end
Kitty协议定义了清晰的语义：放置图像后，光标移动图像宽度对应的列数和高度对应的行数。但C=1参数可以禁用这种自动移动。图像与滚动区域的交互更复杂：当图像底部触及滚动区域底部时，图像随文本一起滚动；未触及滚动底部的图像保持固定位置。
调色板独立性是一个容易被忽视的问题。Sixel图像有自己的颜色调色板，而终端文本有另一套ANSI颜色定义。两者的冲突会导致颜色混乱。XTerm的实现方案是让Sixel调色板与文本调色板独立——修改一个不影响另一个。但早期实现并非如此，某些终端会破坏性地修改全局调色板。
图形滚动与文本滚动的协调是另一个难题。当用户向上滚动查看历史记录时，图形应该如何处理？Kitty协议将图像存储在终端的虚拟屏幕缓冲区中，滚动只是改变视口位置，图像自然随之移动。但tmux等终端复用器在会话间切换时会丢失图形数据——协议没有定义图形状态如何在会话间传递。
性能优化是现代实现的关注重点。libsixel使用运行长度编码（RLE）压缩连续相同颜色的像素。Kitty协议支持ZLIB压缩，对于大面积单色或渐变图像效果显著。本地传输时，共享内存消除了数据拷贝开销——终端直接映射客户端的内存空间读取像素数据。
终端能力检测是一个未完全解决的问题。传统方法是检查TERM环境变量，但这个变量定义的是终端类型（如xterm-256color），并不说明是否支持图形协议。COLORTERM变量用于指示真彩色支持，但没有对应的"GRAPHICSTERM"变量。实践中，应用程序通常尝试发送协议查询命令，根据响应判断支持情况——但这种方法在SSH远程连接时可能失效，因为中间层程序可能吞掉响应。
生态系统与应用
终端图形能力的实用化催生了丰富的应用生态。chafa是一个典型的例子——它将任意图像转换为终端可显示的格式，支持Sixel、Kitty协议、iTerm2协议，也支持回退到Unicode字符艺术。这种多协议支持使chafa成为终端图像显示的瑞士军刀。
timg更进一步，支持在终端中显示视频。它使用终端的图形协议显示视频帧，帧率取决于终端的渲染速度。在Kitty终端中，配合GPU加速渲染，视频播放流畅度可以接受。mpv播放器也支持终端图形输出，通过--vo=kitty或--vo=sixel选项启用。
flowchart LR
subgraph 终端图形应用生态
direction TB
subgraph 图像查看
A[chafa<br/>多协议图像转换]
B[timg<br/>图像/视频查看]
C[mpv<br/>终端视频播放]
end
subgraph 数据可视化
D[gnuplot<br/>Sixel输出终端]
E[GR.jl<br/>Julia绘图后端]
F[matplotlib<br/>终端后端]
end
subgraph 系统工具
G[neofetch<br/>系统信息+图像]
H[ranger<br/>文件管理器预览]
I[broot<br/>文件浏览器]
end
end
数据可视化是终端图形的重要应用场景。gnuplot从5.2版本开始支持Sixel输出终端（sixelgd、sixeltek），可以在终端中直接显示图表。Julia语言的GR.jl绘图后端支持Sixel输出，使得在终端中运行的数据分析脚本能够直接显示图形结果。
neofetch系统信息工具利用终端图形显示用户头像或操作系统Logo。当检测到支持的终端时，它会输出图形格式的图像，比ASCII艺术更精细。类似的还有各种终端文件管理器（如ranger、broot），它们在文件预览中显示图像缩略图。
终端图形甚至进入了游戏领域。SDL1.2-SIXEL项目将Simple DirectMedia Layer图形库移植到Sixel后端，使原本依赖X11的游戏能够在纯终端环境运行。QEMU虚拟机的SDL输出可以导向Sixel终端，实现在终端窗口中显示虚拟机图形界面。虽然这些应用更多是技术演示而非实用工具，但它们展示了终端图形的潜力边界。
Windows Terminal的加入
很长一段时间里，Windows平台是终端图形的荒漠。Windows Console的历史设计不支持ANSI转义序列，更不用说Sixel这样的高级功能。开发者需要使用ANSICON等第三方工具才能获得基本的ANSI支持。
Windows 10 v1511（2015年11月）开始改变这种状况，添加了对ANSI转义序列的支持。但完整的图形协议支持直到2024年才实现——Windows Terminal Preview 1.22引入了Sixel支持。这得益于社区贡献者的努力，将libsixel的核心逻辑移植到Windows Terminal的渲染引擎中。
Windows Terminal实现Sixel的挑战在于其DirectWrite渲染架构。DirectWrite是Windows的文本渲染引擎，设计用于高质量字体渲染，而非位图图形。实现团队需要创建一个独立的图形层来渲染Sixel图像，同时处理与文本层的合成。
Windows Terminal的Sixel实现仍然有限制。目前不支持动画GIF，颜色调色板大小有限制，某些Sixel控制函数的行为与VT340不完全一致。但作为Windows平台的第一个官方Sixel实现，它的意义在于建立了基准——以后的标准可以在此基础上改进。
标准化的困境
终端图形协议面临的核心问题是缺乏统一标准。ECMA-48定义了DCS的基本格式，但Sixel的具体语法和语义从未标准化。Kitty协议和iTerm2协议是各自终端的私有扩展，尽管它们都开放文档并欢迎其他终端实现。
这种碎片化状态与Web标准的演进形成对比。Web有W3C定义标准，有浏览器厂商的协作（尽管不总是顺畅），有Can I Use网站跟踪特性支持。终端世界没有类似的组织——ECMA很早就停止更新终端相关标准，xterm的控制序列文档是事实标准但缺乏正式定义。
缺乏标准导致兼容性矩阵复杂化。终端A可能支持Sixel但不支持Kitty协议，终端B相反，终端C两者都支持但实现细节有差异。应用程序需要检测终端类型并选择合适的输出格式，这增加了开发复杂度。
一些尝试正在改善这种状况。社区维护的终端兼容性矩阵列出了各终端的特性支持情况。Kitty协议的作者Kovid Goyal公开邀请其他终端实现该协议，并提供参考实现。libsixel项目的持续维护使Sixel在现代系统上易于使用。
未来方向
终端图形技术向何处去？几个趋势正在浮现。
GPU加速渲染正在成为终端模拟器的标配。Alacritty、Kitty、WezTerm都使用GPU进行文本渲染，图形协议自然也可以利用GPU加速。Kitty协议的z-index混合本质上需要图形处理器的支持才能高效实现。未来的终端可能直接支持WebGL或类似的图形API。
更丰富的图形原语可能是下一步演进方向。目前的协议都是像素导向的——发送像素数据，终端渲染。ReGIS式的矢量命令可能以现代形式回归：发送SVG或类似的矢量描述，终端渲染为位图。这对于高分辨率显示器特别有价值——矢量图形在任何分辨率下都保持清晰。
与终端复用器的更好集成是迫切需求。tmux和GNU Screen是目前最流行的终端复用器，但它们对图形协议的支持有限或不支持。tmux需要显式启用Kitty图形协议支持，Screen的图形支持更是不完整。复用器转发图形数据的技术挑战在于：如何在会话间传递图形状态？如何处理窗口大小变化？
安全性考虑正受到更多关注。ANSI转义序列曾被用于终端安全攻击——恶意序列可以读取剪贴板、改变窗口标题、隐藏后续输出。图形协议引入新的攻击面：恶意图像数据可能导致终端崩溃或内存耗尽。Kitty协议的文件路径参数尤其敏感——终端需要验证路径不指向敏感文件。
WebAssembly可能是终端图形的未来载体。一些项目正在探索在终端中嵌入WASM运行时，允许运行编译为WASM的图形应用。这种方案结合了Web技术的丰富生态和终端的轻量级特性——应用逻辑在WASM中运行，输出通过图形协议显示。
四十年的回响
从VT340到Windows Terminal，从低速串口到SSH连接，从硬件终端到GPU加速模拟器，终端图形技术走过了漫长而曲折的道路。Sixel作为这场革命的起点，其核心设计原则至今仍有价值：将图形编码为文本序列，利用现有协议基础设施传输，与文本内容无缝共存。
今天，在终端中显示图像不再是技术奇观，而是日益普通的操作。开发者用终端文件管理器预览图像，数据科学家在远程服务器上运行脚本并直接看到图表，系统管理员用图形化的系统信息工具快速了解服务器状态。这些场景的实现，建立在前人解决带宽约束、内存限制、兼容性挑战的基础之上。
终端图形协议的标准化仍未完成，不同协议的竞争仍在继续。但这也许正是健康的演进方式——创新需要实验空间，最佳方案需要在竞争中证明自己。当某一天，任何终端图像查看工具都能在任何终端上正常工作，而不需要检测终端类型、尝试多种协议时，这场四十年的技术演进才算真正成熟。
timeline
title 终端图形协议发展历程
section 1980年代
1987 : VT340发布<br/>Sixel/ReGIS诞生
section 1990年代
1996 : XTerm添加Sixel支持<br/>图形终端逐渐式微
section 2010年代
2014 : libsixel项目启动<br/>Sixel编码优化
2016 : mlterm完善Sixel实现
2017 : Kitty图形协议发布
2018 : iTerm2内联图像协议
section 2020年代
2021 : WezTerm多协议支持
2024 : Windows Terminal支持Sixel
参考文献
- DEC VT330/VT340 Graphics Programming Manual, EK-VT3XX-GP-001, March 1987
- ECMA-48: Control Functions for Coded Character Sets, 5th Edition, June 1991
- VT100.net VT340 Sixel Graphics Documentation, Chapter 14
- libsixel: A SIXEL encoder/decoder implementation, https://github.com/libsixel/libsixel
- Kitty Graphics Protocol Documentation, Kovid Goyal, https://sw.kovidgoyal.net/kitty/graphics-protocol/
- iTerm2 Inline Images Protocol, https://iterm2.com/documentation-images.html
- ANSI Escape Code - Wikipedia, https://en.wikipedia.org/wiki/ANSI_escape_code
- Sixel - Wikipedia, https://en.wikipedia.org/wiki/Sixel
- DEC VT340 - Terminals Wiki, https://terminals-wiki.org/wiki/index.php/DEC_VT340
- chafa: Terminal graphics for the 21st century, https://github.com/hpjansson/chafa
- timg: A terminal image and video viewer, https://github.com/hzeller/timg
- Windows Terminal Preview 1.22 Release, Microsoft Developer Blogs, August 2024
- Sixel Graphics Support in Windows Terminal, GitHub Discussion #18500
- Console Virtual Terminal Sequences, Microsoft Learn
- VT100 User’s Guide, Chapter 3: Programmer Information
- XTerm Control Sequences, Thomas E. Dickey, invisible-island.net
- Terminal colours are tricky, Julia Evans, October 2024
- Standards for ANSI escape codes, Julia Evans, March 2025
- libsixel Homepage, saitoha, https://saitoha.github.io/libsixel/
- DEC Video Terminals - The VT100 and its Successors, Richard Shuford
- ReGIS Graphics Documentation, DEC VT340 Programmer Reference Manual
- GPU accelerated terminal emulators discussion, Reddit r/linux
- Alacritty: A GPU-Accelerated Terminal Emulator, https://github.com/alacritty/alacritty
- WezTerm Documentation, https://wezfurlong.org/wezterm/
- Terminal Graphics Protocol Support Issue, anthropics/claude-code GitHub
- Sixel support in mlterm, arakiken documentation
- VT340test: Tests of VT340 compatibility, https://github.com/hackerb9/vt340test
- ANSI Terminal Security in 2023, dgl.cx
- Don’t Trust This Title: Abusing Terminal Emulators, CyberArk Research
- gnuplot sixelgd terminal documentation
- GR.jl: A Julia plotting backend with Sixel support
- neofetch Image Backends documentation
- ranger file manager image preview
- broot terminal file explorer
- SDL1.2-SIXEL project
- Xsixel: X11 on SIXEL terminals
- GNU Screen Sixel branch, arakiken fork
- Terminal Compatibility Matrix, TmuxAI
- Kitty vs iTerm2 comparison, Terminal Trove
- The new standard of SIXEL development, Hacker News Discussion
- sixel for terminal graphics, konfou.xyz
- DEC Special Graphics - Wikipedia