图像处理命令行工程：ImageMagick、libvips 与批量管线（横纵综合报告） 未开始

题记与说明

本报告由两份部件报告综合而成：纵轴《图像处理命令行工程：ImageMagick、libvips 与批量管线 —— 纵向发展史（1987–2026）》（parts/2026-11-05-图像处理命令行工程-ImageMagick-libvips-vertical.md）与横轴《图像处理命令行工程：ImageMagick、libvips 与批量管线 — 横轴对比报告》（parts/2026-11-05-图像处理命令行工程-ImageMagick-libvips-批量管线-horizontal.md）。
写作日期：2026-11-05。方法：横纵分析法（历时轴叙事 + 共时轴对比 + 交叉洞察）。
事实基础：两份部件报告当日联网检索的一手来源（官方文档/wiki/基准页、GitHub API、npm registry、邮件列表存档），本综合时对三处口径分歧做了现场复核（见下表），终稿修订时又复核一轮并扩充了复核清单，复核命令与结果一并给出（见 [39]）。本稿为终稿（final），已按独立审读意见逐条修订；初稿保留于 drafts/ 未改动。
手册定位：与姊妹课题《ffmpeg 视频处理自动化配方库》互为配套——ffmpeg 管音视频与时间轴，本课题管图像与静帧管线。

版本口径说明：两份部件的三处分歧与复核结果

两份部件报告写于同一天、各自实测，存在三处数字口径差异。本综合报告于 2026-11-05 逐条现场复核并统一，避免矛盾带入正文：

以下正文中，[n] 均指向文末合并去重后的《参考来源》编号。

TL;DR

IM 与 libvips 两条线——整图入内存 vs 流式按需计算——走完四十年，汇流成一个问题：可靠、安全、并行地处理一百万张图。三个转折：2013 维基媒体以小内存的 VIPS 换掉 IM 缩略图系统；2016 ImageTragick 证明 shell delegate 是系统性风险；2026-05 IM6 停常规维护（安全至 2029-04）。当前截面：libvips 系（sharp 周下载 1.57 亿）赢性能与内存——官方基准任务下快约 7.7 倍、峰值内存约省 16 倍（该任务是 IO 重的裁剪-缩放-锐化，偏向流式实现，引用此倍数务必带脚注，见性能一节 [28]）；IM 赢约 190 格式与合成操作。选型是分层组合：ffmpeg 管时间轴、libvips 管吞吐、IM 管兜底、优化器收尾，编排用 make（最小可跑模板见文末"最小可运行批量管线"一节）；铁律"并行度 ≈ 内存预算 ÷ 单任务峰值"。

纵轴：发展脉络（1987–2026）

三条线——ImageMagick 线、libvips 线、批量管线/配套生态线——在时间上各自演进，最终汇流到同一个问题域。总览：

阶段一（1987–1995）：一次显示需求与一个"图比内存大"的项目

ImageMagick 的起点不是图像行业，而是一位主管的请求。作者 John Cristy（时在杜邦）回忆：主管 Dr. David Pensak 要求把计算机生成的图像显示在一台只能同时显示 256 色的显示器上。当年 24 位真彩显示器罕见且昂贵，杜邦里化学家、生物学家多而计算机科学家少，Cristy 转向 Usenet 求助，USC 信息科学研究所（ISI）的 Paul Raveling 不只给了方案，还给了现成源码——一个把 24 位图降到 256 色的量化算法。这就是 ImageMagick 最初的核心能力（色彩量化 + 显示）[1]。

1990-08-01，Cristy 决定"报答 Usenet"，说服杜邦管理层把版权转给 ImageMagick Studio LLC，并将工具发布到 Usenet 的 comp.archives 组——这是 ImageMagick 的公开诞生日 [1][2]。到 90 年代中期，社区反馈积累成 ImageMagick 4.2.9，Cristy 自述当时"以为它已经完成了"——它已被全球数千用户使用，甚至进入了当时新生的 Linux 发行版 [1]。主要参与者还有 Bob Friesenhahn（早期 Usenet 用户，后来 5 时代的核心贡献者）。ImageMagick 从第一天起就是命令行工具——这个基因决定了它后来成为脚本化批处理的基础件。

大洋另一端，1989 年底，EU 资助的 VASARI 项目启动：用相机完整记录古典油画表面、长期追踪颜色退化，覆盖英德法意。伦敦扫描仪由 Kirk Martinez（Birkbeck 学院）与国家美术馆的 David Saunders 负责；Martinez 雇了 Nicos Dessipris，Saunders 雇了刚拿到理论计算机科学博士的 John Cupitt。需求是 7 个色彩波段、16 位、约 20 像素/毫米——单通道就约 1GB。当时找不到能处理这种尺寸的图像库（Sun 工作站 4 万英镑、64MB 内存、25MHz），于是自己写了一个：这就是 VIPS，用内存映射文件 + 逐扫描线流水线实现"远超内存的大图" [6][33]。

这个阶段的差异本质是初始约束不同：ImageMagick 生于"显示器只有 256 色"，VIPS 生于"图比内存大"。两条约束分别铸成两个项目此后四十年的架构哲学（详见交叉洞察一）。

阶段二（1996–2005）：社区化、API 化与第一次分裂

ImageMagick 线：Bob Friesenhahn 主动联系 Cristy，建议改进 API 让其他语言能调用，并写了 C++ 封装 Magick++，还贡献了模块加载器、自动文件识别与测试套件；Glenn Randers-Pehrson（PNG 专家）、William Radcliffe、Leonard Rosenthol 相继加入。用户从数万计开始对"破坏 API 的发布"反应激烈 [1]。2002-11-19，API 冻结之争谈崩，Friesenhahn 率人分叉出 GraphicsMagick（分叉代码取自 IM 5.5.2 发布前数日的基线——GM 官方 NEWS 自述 "several days before the ImageMagick 5.5.2 release" [3]），主打跨版本 API/命令行稳定性，2003-03-15 正式宣布——第一次大分裂，也是"稳定性派"与"演进派"矛盾的制度化 [3][4]。2004-04-15，ImageMagick 6.0.0 发布，直接推手是 Anthony Thyssen：他指出 IM 命令行处理多张图像时"混乱且无定义"，提出选项按位置分组、对多图序列可预期的解析设计——这套设计成为 IM6 的骨架，也是今天 magick 用法可预期的根源 [1][5]。

libvips 线（平行发生）：1993 年后续项目 MARC 把 VIPS 变成彩色计测相机与图录印刷系统；Cupitt 接管 VIPS、GUI 与相机软件；VIPS 获得双 CPU SMP 支持，并实现"算子链式执行、免中间磁盘"——这是它低内存特性的起源。GUI 从 SunView 的 "vf"（含表达式语言）演进为 Motif 的 "ip"，再迁到 GTK+（先叫 nip，GTK2 重写后即 nip2）。Viseum、ACOHIR、Artiste 等项目推动 VIPS 从 Sun 迁到 Linux，支持 >2GB 文件与最多 64 CPU。1997 年 Martinez 转到南安普顿大学；2005 年 Cupitt 从国家美术馆转到帝国理工学院做医学影像，VIPS 增加 Analyze/DICOM3/FITS/Matlab/Radiance 格式、运行时代码生成与 sequential mode [6]。

配套生态：2000-12-20，Fabrice Bellard（化名 "Gérard Lantau"）提交 FFmpeg 初始版本——图像与视频两条命令行处理线的"对位工具"自此存在 [7]。

驱动因素：图像工具从"个人工具"变成"数千用户依赖的基础件"后，API 稳定性成为主要矛盾（分裂之源）；libvips 一侧的驱动力始终是数据规模（美术馆/科研的大图），为此不惜自研架构。

阶段三（2006–2012）：批量工程化与 libvips 的"推倒重来"

mogrify（原地批量改写）、montage 等 IM 子命令早已存在，但真正把"批量"变成一门工程的是 shell 生态：find -print0 | xargs -0 -P 多核并行成为惯例。2010-06-01，Ole Tange 发布 GNU Parallel 20100601（同年 8 月成为正式 GNU 包），把并行调度、输出整形、特殊文件名处理、远端分发标准化；2011 年他在 USENIX ;login: 发表的 *GNU Parallel: The Command-Line Power Tool* 成为这十年的标准引用 [8][9][38]。ImageMagick 在这一时期仍以 6.x 稳步迭代（2008 年加入 liquid rescale 接缝雕刻），稳固了"网页缩略图/图片站标配"的地位 [2]。

libvips 这边，2010 年 Cupitt 自述旧库已"相当臃肿：许多系统实现在错误的层级上，层级间大量重复"，团队决定基于 GObject 设计一套全新 API。这次重构于 2015 年 4 月随 libvips 8.0 完成，但流式（streaming）、按需计算（demand-driven）、"一切皆操作"（everything is an operation）三大设计决策在此期间成形；8.0 引入的 vips_thumbnail() 把"读图 + 缩放"合并为一次流式操作，成为后来 Web 缩略图管线的性能基石 [6]。

同一时期 FFmpeg 经历 2011-03-13 的 libav 分叉（2020 年 libav 停止维护）[7]。多核 CPU 与 Web 规模化让"逐张循环处理"在性能上破产，并行调度工具把命令行批处理推向工程化——批量管线从 Unix "文化"升格为"工程"（详见交叉洞察四）。

阶段四（2013–2016）：libvips 出圈与 ImageTragick 安全拐点

这是三条线最密集的一段。

libvips 的出圈。2013 年年中，维基媒体宣布缩略图系统从 ImageMagick 迁往 VipsScaler（VIPS 的 MediaWiki 扩展），动因是 VIPS 用极小内存即可缩放超大 PNG；9 月完成部署——这是 libvips 第一次在大规模生产环境"以性能换掉 ImageMagick" [11][12]。2013-08-20，Lovell Fuller 在 npm 发布 sharp 0.0.1，把 libvips 包成 Node.js 模块，官方口径比最快的 ImageMagick/GraphicsMagick 配置快约 4–5 倍、内存更低 [13][14]。2015 年 4 月，libvips 8.0 正式发布，vips8 API 全面落地 [6]。ImageMagick 侧同期：IM 7.0.0 自 2014 年 1 月起以 beta 滚动发布（HDRI 默认、逐通道 alpha、像素缓存重构），2015 年进入 7.0.x 正式系列（首个稳定版的确切发布日未逐日核实，按多方口径 2015 年处理）[15]。

ImageTragick：命令行图像处理的分水岭。2016 年 4 月底，研究者披露 CVE-2016-3714：ImageMagick 把文件名未经充分过滤就传给 delegates（外部代理命令，如 HTTPS、MSL），攻击者可借恶意图像注入 shell 元字符实现远程代码执行；6.x < 6.9.3-10 与 7.x < 7.0.1-1 受影响。Cloudflare 随即在野外观察到真实攻击载荷 [16][17][18]。2016-05-03，修复版 6.9.3-10 的源码包出现在官方发布档案 [19]。后果深远：policy.xml 安全策略成为运维标配（禁用危险 delegates、限制格式与内存），"图像上传即攻击面"从此进入所有 Web 框架的威胁模型 [16]。

驱动因素：Node.js 服务端爆发给 libvips 带来了前所未有的用户面（sharp）；而 ImageTragick 证明"一个处理用户输入的 C 库 + shell delegates"是系统性风险——安全默认值自此成为本课题的一等公民需求。

阶段五（2017–2022）：现代格式、构建系统与安全默认值

libvips 线：8.7（2018-07-26）默认关闭 vips7 旧 API（需显式 vips7compat.h）；新增 vips_magicksave()——经 libMagick 写任意 IM 支持的格式，作者是 Magick.NET 维护者 Dirk Lemstra（GitHub bio 自述 "Maintainer of @ImageMagick and its .NET … library called Magick.NET"，属 ImageMagick 生态而非 GraphicsMagick [10][41]），两个曾经的"敌对"项目开始互操作；引入 Google PDFium PDF 加载器（摆脱 poppler 的 GPL 限制）[10]。8.13.0（GitHub release 2022-07-21）加入 HDR HEIC/AVIF 支持、vips_operation_block_set()（可按操作黑名单封禁——ImageTragick 教训的 API 化）并切换到 meson 构建系统 [22]。

ImageMagick 线：IM6（6.9.x）与 IM7 双线并行维护长达十年——官方发布档案显示 6.9.x 从 2015-03 一直发版到 2026-07 [19]；IM7 的 magick 统一命令逐步取代 convert/mogrify 等散装命令（脚本兼容层长期保留），并以 HDRI/浮点像素为默认处理模型 [15]。

配套生态：FFmpeg 5.0 于 2022-01 发布，JPEG XL、AVIF 等静图格式陆续进入其支持列表，图像管线与视频管线的格式版图开始互相追赶 [7][30]；云端批量缩略图（AWS Lambda + sharp、容器 + magick/vipsthumbnail）成为默认架构，"每请求起进程跑 ImageMagick"的模式被库内调用取代。

驱动因素：版权/许可证工程（GPL poppler → PDFium）、格式换代（HEIF/AVIF/WebP）、以及容器化对"小依赖、低内存"的苛刻要求——libvips 的流式架构在云环境里从"学术优势"变成"成本优势"。

阶段六（2023–2026）：IM6 退役、libvips 现役与管线常态化

以下版本点除注明外均为本综合报告 2026-11-05 现场复核（GitHub API / 官网下载页），与两份部件当日实测一致：

• IM6 退役：官方公告（ImageMagick6 仓库 discussion #422）——2026-05-01 起 IM6 停止常规维护与新特性，仅安全修复至 2029-04-01；6.9.13 系列继续滚动发安全版 [19][20]。三十年主分支就此进入倒计时。
• ImageMagick：IM7 现役稳定版 7.1.2-35（2026-10-31），7.1.2 系列自 2025-07 起数周一个点版本（复核实测 7.1.2-0 @ 2025-07-13，per_page=100 窗口；复核窗口 per_page=8 内为 7.1.2-28 @ 2026-07-27 至 7.1.2-35 @ 2026-10-31 共 8 个，其中 -28/-29 同日发布）[29][39]。
• libvips：现役 8.18.7（2026-09-26），8.19.0-rc1（2026-11-01） 已在测试；一年内 8.17.0（2025-06）→ 8.18.0（2025-12）保持半年一个 minor 的节奏 [22]。
• sharp：npm 最新 0.35.5；2026-10-28 至 11-03 一周下载量 157,439,870 次（npm downloads API 实测，两份部件独立取得同一数字）[13][23]——命令行时代的"批量图像处理"如今大半发生在 sharp/libvips 的进程内管线里。
• ffmpeg（配套）：现役稳定版 9.0.2（2026-09-18，官网下载页复核） [30]；与本课题在媒体处理手册中构成"视频/音频 ↔ 静态图像"互补对。

驱动因素：维护经济学——双主线维护成本过高，IM6 退役把存量脚本推向 IM7（convert→magick）或 libvips/sharp；同时 AI 时代海量图片预处理（训练集清洗、缩略图、格式归一）让"低内存、可流式、可并发"的批处理能力从运维细节变成基础设施指标。

纵轴小结：三股驱动力，两种架构哲学

• 驱动力换手：1987–2005 的驱动力是学术与博物馆的大图需求（VASARI/VIPS）与社区互助文化（ImageMagick）；2006–2016 换成 Web 规模化（维基媒体、sharp）；2016 之后是安全与云成本（ImageTragick、容器、Lambda）。
• 两种架构哲学：ImageMagick 始终是"整个图像读进内存再处理"的整图模型，靠 6.0 的命令行重构与 7.0 的 HDRI/像素缓存改良；libvips 从 1989 年的第一天就是"边读边算、算子链式、按需求值"的流式模型。前者赢在无所不包的格式与脚本生态，后者赢在内存与吞吐——维基媒体 2013 年的迁移和 sharp 的周下载量都是这个架构差的市场裁决 [6][11][23]。
• 两次分裂，两种结局：2002 年 GraphicsMagick 因"API 稳定性"离开 ImageMagick，至今仍独立演进、退守稳定 API 生态位 [3][4]；2011 年 libav 因治理问题离开 FFmpeg，2020 年弃守回融主线 [7]。分裂的结局不止"回融"一种；对立生态之间仍会长出兼容桥（libvips 8.7 的 vips_magicksave() 经 libMagick 写格式 [10]）。

横轴：横向对比（2026-11-05 截面）

研究对象与五层竞品圈

课题由三件事咬合而成：ImageMagick（命令行瑞士军刀，格式覆盖与合成能力天花板）、libvips（流式按需计算的 C 库 + vips/vipsthumbnail CLI，性能与内存天花板）、以及批量管线工程（shell/xargs/parallel/make 的编排方法论）。竞品场景属于"竞品充分"型，且竞品天然分层——图像处理工具链不是一个市场，而是五个：

1. 直接同类：GraphicsMagick（2002 年 11 月从 IM 5.5.2 fork、主打 API/ABI 稳定，命令 gm）[3][4]；NetPBM（最老牌工具集，今天更多以 PPM/PGM/PAM 中间格式角色出现在管线里——ImageMagick 调 ffmpeg 解视频帧时用的正是 PAM 流）[32]。
2. 语言内嵌库：Pillow（Python 事实标准，13.0.0，2025-10-15）[34]；OpenCV（视觉算法库，格式能力是副产品；本次未核验具体小版本）。
3. 专项优化器：cwebp、avifenc（libavif）、oxipng、jpegoptim/mozjpeg——单格式做到极致的"手术刀"，与全能工具互补不是替代。
4. 服务化封装：imgproxy（Go + libvips 的独立缩略图服务器，另有商业版 Pro）[35]；Thumbor（Python、基于 Pillow）；Cloudinary/imgix 等托管 SaaS——Cloudinary 的图像管线就构建在 ImageMagick 之上（HEIC 依赖 libheif delegate）[36]。
5. 相邻巨头：ffmpeg。它管音视频，但图像侧既有竞争（解静图也很快，见下节基准）又有互补（ImageMagick 靠 ffmpeg delegate 读视频）[28][32]。

竞争格局一句话：在"高吞吐 Web 缩略图"这一层，libvips 正在吃掉 ImageMagick 的份额；在"万能格式胶水"这一层，ImageMagick 仍无对手；GraphicsMagick 退守稳定 API 生态位；Pillow/OpenCV 各自绑定语言；imgproxy 类服务是 libvips 的工程化出口。

核心对比总表

截至 2026-11-05，版本均经两份部件当日检索 + 本综合复核（OpenCV 除外）：

能力：格式覆盖与操作广度

格式广度上 ImageMagick 仍是冠军，但它的广度一半是自己挣的、一半是"借"来的：官方格式页列约 190 个格式标签（另加 30 个伪格式），其中 PDF/PS/EPS 标注"Requires Ghostscript"、HEIC 标注"Requires libheif delegate library"、JPEG XL 需独立 delegate、APNG/MPEG 的读取直接交给 ffmpeg（delegates.xml 将 MPEG 委托给 ffmpeg/avconv 的实践证据见 [21]）[24][32]。这套 delegate 机制是双刃剑：新格式出个 delegate 就能接上，覆盖速度极快；但每一层外挂都是一条 shell 命令，安全面随之扩大（本节末与安全治理部分展开）。

libvips 的哲学相反：解码全部走进程内 C 库（libheif、libpng、OpenEXR……），没有 shell delegate 层，约 300 个算子覆盖算术/卷积/形态学/色彩/重采样/统计 [26]。8.18 一次补上两块短板：经 dcrawload（基于 LibRaw）读相机 RAW、UltraHDR 支持，另加 Oklab 色彩空间 [27]——至此 JPEG/PNG/TIFF/WebP/HEIC/AVIF/GIF/PDF/SVG/JXL/OpenEXR/FITS/RAW 全部库内闭环。

操作广度上 IM 仍领先一个身位：文字排版、montage 拼图、极坐标、宝丽来特效这类"合成艺术"操作，vips 只有基础等价物。色彩管理双方都有（IM 的 profile 操作、vips 经 lcms 的 ICC 支持）；HDR 上 8.18 的 vips（128-bit 复数数值类型、OpenEXR、UltraHDR）与 IM（libultrahdr delegate、OpenEXR）打平，ffmpeg 则是动态范围视频调色的主场（tonemap 类滤镜）[31]。动画处理 IM/vips 都能读写 GIF/APNG/WebP 序列，但时间轴重编码、字幕、变速是 ffmpeg 的领地——这是"分工手册"（交叉洞察・建议第 5 条）的依据。

性能与内存：一份可以引用的实测基准

libvips 官方 wiki 基准页做了一件朴素的事：读入 10000×10000 像素的 8-bit RGB 平铺 TIFF，四边各裁 100px，双线性缩小 10%，套 3×3 锐化卷积，存盘。计时与峰值内存（ps 采样 RSS）如下 [28]。引用前须带上版本标注的脚注：页面自述"最后运行于 2025-08-12、各包取当时稳定版"，但其版本列标注 vips 8.18——按 GitHub Releases 实测，v8.18.0 发布于 2025-12-17（连 rc1 也要到 2025-12-05 才出现），2025-08-12 当时的 libvips 稳定版应为 8.17.x。页面两处自述互相矛盾（疑为版本列事后更新而未重跑），本报告按页面原样引用相对倍数与内存数，并如实标注此矛盾；机器为 16 核 AMD Threadripper PRO 3955WX，Ubuntu 发行版软件包 [28][39]：

\* 倍数按本表用时列 ÷ 0.57 s 复算（1.51 ÷ 0.57 ≈ 2.65）。基准页"times slower"列对本行标注 1.96×，与其自身用时列不符（1.96 × 0.57 ≈ 1.12 s ≠ 1.51 s），疑为旧次运行残留；本表以复算值为准。另：Pillow-SIMD 峰值内存约为 vips C 的 11 倍（1040 ÷ 94）。官方页同任务还有 convert（4.44 s，7.79×）等 IM 条目，与上表 ImageMagick 行（7.74×）同量级 [28]。

三个解读，比数字本身重要：

1. 倍数不是全部，内存才是批量管线的命门。 批量场景的吞吐上限 ≈ 内存预算 ÷ 单任务峰值内存。同样 8 GB 机器，ImageMagick 一路并行 5 个 worker 就见顶，libvips 能开几十个——流式架构让内存不随图像尺寸线性增长。Trendyol 的工程团队正是据此把服务从 ImageMagick 迁到 libvips [37]。
2. 这个测试偏向 libvips，引用时要带脚注。 官方页自己写明：任务是 IO 重的（利于流式）；16 核机器惩罚了不自动多线程的实现（原文点名 Pillow、ymagine、OpenCV、ImageScience），并提示 Pillow 的最公平对照是"vips 单线程"条目；个别系统因格式限制用了 JPEG 或条带 TIFF。Pillow-SIMD 的时间其实相当能打，输在整图加载的内存曲线上。
3. ffmpeg 在纯静图任务上并不慢（3.61×），它输在图像算子贫瘠而非速度——这坐实了"分工"而非"替代"的结论：视频帧吞吐交给 ffmpeg，像素工艺交给图像 CLI。

许可与运维成本

许可成本都是零，真实的成本差在运维：单任务 1.5 GB vs 94 MB 的峰值内存差直接换算成云实例规格；ImageMagick 的 delegate 链（Ghostscript、ffmpeg、libheif）让每个 CVE 都要追到外挂库；学习成本上 IM 文档浩繁但模式统一（一个命令全家桶），vips 命令面窄但绑定 API 更现代。

生态与集成：谁被谁依赖

libvips 官网点名的上层采用者：sharp（Node）、imgproxy、Mastodon、Ruby on Rails、MediaWiki，另有 Ruby/Python(pyvips)/PHP/.NET/Go/Lua/Crystal/Elixir/Java/Nim 全套绑定和 WASM 构建 [26]。sharp 的 npm 周下载量 157,439,870（官方 API，2026-10-28~11-03 窗口）[13][23]——这已经不是单个库的数字，是整个 Node 部署基座的数字（其中既有直接调用，也有上层框架与工具链的间接依赖）。

ImageMagick 的生态深度在"被集成"：Cloudinary 明确建立在它之上 [36]，WordPress/PHP 世界经 imagick 扩展依赖它，无数 CI 脚本和桌面临时任务把它当默认工具。GraphicsMagick 的生态则是一群需要 gm 命令永不改参数的老系统。部署摩擦：Windows 侧 IM/GM/ffmpeg 均可经 winget/scoop 安装，libvips 提供官方预编译 Windows 二进制 [26]，sharp 则把预编译二进制做进了 npm 包——部署摩擦最小。配套的元数据工具 exiftool（Phil Harvey 的跨平台元数据读写器，批量管线的验收与隐私剥离标配，见建议 5 配方 F-05）经 winget install OliverBetz.ExifTool 安装，包 ID 经 winget 实测核对 [39]。

成熟度与安全治理

三个项目都过了而立之年（IM 1990 年前后 [1][2]、libvips 血统追到 1989 Birkbeck [6][33]、GM 2002 [3]）。发版节奏差异悬殊：IM 7.1.2 系列数周一个点版（本综合复核：2026-07-27 的 -28 到 2026-10-31 的 -35 共 8 个，其中 -28/-29 同日）[29]；GM 一年一两版、主打不惊吓 [3]；libvips 约半年一个 minor [22]；Pillow 严格执行季度制（1/4/7/10 月）[34]。

安全史是这个赛道最有信息量的横向维度，因为它直接暴露了架构差异（事件的时间序见纵轴阶段四，此处按维度合并、不重复叙事）：

• ImageTragick（CVE-2016-3714，2016-05 披露）：传给 delegate 的文件名未过滤 shell 元字符，可致 RCE；标准缓解是 policy.xml 里 rights="none" 屏蔽 EPHEMERAL/HTTPS/MSL/SHOW 等危险 coder [16][17]。这是"外挂 shell delegate"架构的系统性代价。
• ImageMagick 的 ffmpeg delegate 陷阱：让 magick 读 MP4 时，实际执行 ffmpeg -nostdin -v -1 -vframes %S -i '%i' -vcodec pam …，长视频可能被抽完所有帧直至耗尽资源 [32]——手册明确建议绕开（应对方式见交叉洞察·建议第 4 条：视频侧一律直接调 ffmpeg）。
• 2025 年的续集：ImageMagick CVE-2025-55004（7.1.2-1 修复）[29]；libvips CVE-2025-59933（8.17.2 修复）[22]；Pillow 13.0.0 一次修掉 EPS/JPEG/TIFF 三处关键缺陷，其中含 Ghostscript 命令执行路径 [34]——注意 Pillow 的这处风险同样来自外挂 Ghostscript，说明"解析器 + 外部程序"的攻击面是赛道共性，不是某家的原罪。

判断：全能型工具的攻击面天然大，vips 的进程内库解码架构在同类风险上暴露面更小；但治理能力上 ImageMagick 的 policy.xml 机制十年打磨，反而是文档化最充分的。

用户视角：各自活成了什么样

社区的真实选型（综合公开口碑 [13][33][35][37]）大致是四句话：Node 开发者已经用脚投票给 sharp（"标准的高性能选项"，安全响应快 [13]）；运维工程师把 imgproxy 当 libvips 的工程化出口（URL 签名 + CDN 缓存，Trendyol、Evil Martians 有完整迁移叙事 [35][37]）；脚本党留在 ImageMagick，因为它"什么都敢吃"，代价是慢、吃内存、偶尔踩 delegate 的雷；GraphicsMagick 的用户要的不是快，是 gm 的参数十年不变。一个反直觉点（交叉洞察五展开）：用户用 ImageMagick 的方式早已偏离官方定位——多数人只用它做一次性转换和 magick montage 拼图，而公开可见的大规模高吞吐层则在向 libvips 系集中：维基媒体的缩略图迁移 [11]、Trendyol 的服务迁移 [37]、sharp 亿级周下载所代表的 Node 生态 [23]，是这一趋势的三个公开投影。

适用场景决策表

交叉洞察：两轴合读说明了什么，对用户意味着什么

洞察一：架构哲学是初始约束的化石，价格体系替技术做裁决

纵轴显示两个项目的初始约束完全不同：ImageMagick 生于"显示器只有 256 色"的显示问题，整图加载在 1987 年是合理解；VIPS 生于"单通道就 1GB、机器只有 64MB 内存"的美术馆扫描，流式按需计算是当年的唯一解 [1][6]。四十年后约束反转——内存不再稀缺，但云按内存计费、容器按内存调度、批处理按内存决定并行度——于是横轴截面出现约 7.7×/16× 的差距（官方基准，任务偏向流式，引用带脚注 [28]），维基媒体 2013 年的迁移 [11] 和 sharp 的亿级周下载 [23] 就是市场裁决书。教训：架构哲学不是永恒最优解，是初始约束的化石；当约束被价格体系重新定价时，赢家换人。对用户的操作含义：评估任何"老工具"时，先问它当年为什么这样设计、那个约束今天还在不在——还不在，它就是负担。

洞察二：一次安全事件重排了整个横轴

把纵轴的 2016 年和横轴的 2026 年对齐看：ImageTragick 不只是 ImageMagick 的一次运维事故，它把"shell delegate"架构的代价显性化，此后横轴上看到的三个现象全是它的下游——其一，vips 的"无 shell 层、进程内解码"从学术洁癖变成安全卖点 [26]；其二，libvips 8.13 的 vips_operation_block_set() 把"禁危险 coder"从 policy.xml 配置升级为 API [22]；其三，imgproxy 把"security"写进核心原则，用 URL 签名 + 容器隔离成为 libvips 的工程化出口 [35]。换句话说：横轴今天"服务化封装吃掉直接命令行调用"的格局，是纵轴 2016 年那颗子弹飞了十年的落点。安全治理从 policy.xml 走向进程隔离不是风格变化，是那条轴决定的。

洞察三：分裂的两种结局——回融与退守

两次大分裂在纵轴上走向了不同结局。libav（2011 年 fork 自 FFmpeg）2020 年停止维护、回融主线 [7]——"分裂被主线吸收、以兼容层收场"的镜像案例。GraphicsMagick（2002 年 fork 自 IM 5.5.2）则至今仍独立演进：未被吸收、也未回融，退守"API/命令行十年不变"的稳定生态位 [3][4]——这是分裂的另一种结局：守住细分生态位。两条对立线之间照样会长出工程桥：2018 年 libvips 8.7 的 vips_magicksave() 经 libMagick 写格式，作者是 Magick.NET 维护者 Dirk Lemstra [10][41]——libvips 与 ImageMagick 生态的互操作样本。对用户的启示：fork 不是终局判决，当年选 fork 押注的是"哪个矛盾更重要"（稳定性 vs 演进）；十年后回融与退守两种结局都真实存在，选型看的是当下的需求匹配，不是阵营史。

洞察四：批量管线走完了"文化 → 工程 → 基础设施"三级跳

纵轴上这条线很清楚：1980 年代 Unix 管道是文化（find | xargs，凭手艺）；2010 年 GNU Parallel 把并行调度、输出整形、远端分发标准化，是工程 [8][9]；2017 年后云上常驻缩略图服务（VIPS_CONCURRENCY 线程池、imgproxy、Lambda + sharp）是基础设施 [26][35]。横轴的并行度公式正好是三级跳的工程摘要：文化时代没人算内存，工程时代用 parallel -j 控制进程数，基础设施时代内存本身就是计费单位。AI 时代的海量图片预处理（训练集清洗、缩略图、格式归一）正把这条轴进一步推成"基础设施指标"——这是 2023–2026 阶段的核心驱动 [23]。

洞察五：官方定位与真实用户行为的背离

横轴发现一个反直觉现象：多数 ImageMagick 用户只用它做一次性转换和 magick montage 拼图，而公开可见的大规模高吞吐层在向 libvips 集中——维基媒体缩略图系统 2013 年迁移 [11]、Trendyol 图像服务迁移 [37]、以 sharp 为底座的 Node 生态（周下载亿级 [23]）是文中可查的三个投影。纵轴解释了为什么 IM 依然不死：它的价值早已从"性能"转移到格式兜底 + 脚本生态 + 合成艺术操作的既得资产——一个工具的历史越久，护城河越可能从"快"变成"什么都敢吃"。选型时因此不要问"哪个更好"，要问"我的瓶颈在格式广度还是吞吐"——前者 IM 无对手 [24]，后者 vips 无对手 [28]，多数真实系统两个都要。

对用户的判断与建议

1. 选型是分层组合题，不是单选题。 一张完整的批量图像处理栈：

时间轴/编解码   → ffmpeg（帧是两个世界的通用语）
高吞吐静帧加工  → libvips（vipsthumbnail / sharp / imgproxy）
疑难格式兜底    → ImageMagick（约 190 格式 + delegate 生态）
最后一档压缩    → cwebp / avifenc / oxipng（专项优化器）
编排            → make 增量构建 + GNU parallel / VIPS_CONCURRENCY

2. 并行策略跟架构走。 Pillow/OpenCV 不自动多线程，靠进程级并行吃满 CPU；ImageMagick 是否多线程取决于构建（如是否启用 OpenMP），但其瓶颈不在核数而在内存——整图加载的内存随并发线性叠加，并行仍走进程级，只是进程数受内存预算约束；libvips 单进程内水平多线程，进程级并行会互抢线程，多开进程数不宜超物理核：

# 整图加载型：Pillow/OpenCV 不自动多线程，靠进程池吃满核；
# ImageMagick 并行同样走进程级，进程数受内存预算约束（是否多线程取决于构建）[38]
ls *.jpg | parallel -j8 'magick {} -resize 1600x -quality 82 web/{/}'
# libvips 型：少进程 + 高线程（-o 接收含 %s 的输出路径模板，%s=输入文件名去扩展名 [40]）
VIPS_CONCURRENCY=8 vipsthumbnail -s 320 -o 'thumbs/%s.jpg' *.jpg

内存预算公式（依据基准表）：并行度 ≈ 可用内存 ÷ 单任务峰值内存——ImageMagick 每槽按 1.5 GB 计，libvips 按 0.1–0.3 GB 计。批量管线的增量构建用 make：把每张图的目标文件作为 target，源图 mtime 变了才重跑，万级图库的重复处理成本趋近于零（可运行模板见下文"最小可运行批量管线"一节）。

3. IM6 存量迁移窗口已经打开。 IM6 常规维护已于 2026-05-01 停止，安全修复只到 2029-04-01 [20]。存量 convert 脚本应在两年内迁到 magick（IM7）或直接迁 vips/sharp；迁移优先级按"高吞吐路径先迁"排——它们同时是内存账单最大和 ImageTragick 类风险暴露最多的地方。

4. 安全底线，无论选谁。 policy.xml 禁危险 coder 仍是 IM 侧第一道闸 [16]；绝不用 magick in.mp4 out.png 抽帧——delegate 会执行 ffmpeg 且可能抽完全部帧 [32]，视频侧一律直接调 ffmpeg；面向用户上传的服务走容器隔离 + URL 签名（imgproxy 模式）[35]；静态链接 libvips 注意 LGPL 再链接义务 [26]。"解析器 + 外部程序"的攻击面是赛道共性（Pillow 的 Ghostscript 缺陷同源 [34]），任何外挂解码器都要进 CVE 跟踪清单。

5. 精选配方（与 ffmpeg 课题的接口）。 分工原则：ffmpeg 管时间轴与编解码，图像 CLI 管静帧像素工艺，帧（图像文件/管道流）是两者的通用语。配方编号 F-01 起连续编号，为本节自编，与姊妹手册无编号耦合。实测状态：以下配方均未在本机复核环境实测（该环境仅安装 ffmpeg）；其中 vipsthumbnail -o 的输出路径模板语义已对照官方 man 页核对 [40]——-o 接收含 %s 的路径模板（%s=输入文件名去扩展名），不能只给目录，这是对常见误用（含本报告初稿）的更正；其余用法以官方文档为准，落地前请先小批量试跑。配方用到的 exiftool（前文竞品圈未列，补一句定位）：Phil Harvey 的跨平台元数据读写器，批量管线的验收与隐私剥离标配；Windows 经 winget install OliverBetz.ExifTool 安装（包 ID 经 winget 实测核对 [39]）。

# F-01 抽帧 → 缩略图管线（vipsthumbnail 的 -o 接收含 %s 的路径模板 [40]）
ffmpeg -i in.mp4 -vf fps=1 -q:v 2 f_%04d.jpg && vipsthumbnail -s 320 -o 'thumbs/%s.jpg' f_*.jpg
#（换 IM：magick mogrify -path thumbs -resize 320x f_*.jpg）
# F-02 序列帧 → 视频（渲染农场导帧回灌）
ffmpeg -framerate 24 -i f_%04d.png -c:v libx264 -pix_fmt yuv420p -movflags faststart out.mp4
# F-03 视频 → 高质量 GIF（palettegen/paletteuse 双色板 [31]）
ffmpeg -i in.mp4 -vf "fps=12,scale=480:-1:flags=lanczos,split[a][b];[a]palettegen[p];[b][p]paletteuse" out.gif
# F-04 HEIC/RAW 入口（IM 需 libheif delegate [24]；RAW 走 libvips 8.18 库内闭环 [27]）
magick in.heic -quality 88 out.jpg
vips dcrawload img.cr2 img.jpg   # 或直接 vipsthumbnail img.cr2
# F-05 元数据验收：批量剥离隐私
exiftool -all= -overwrite_original thumbs/*.jpg

6. 趋势与风险各一。 可以下注的三个走向：高吞吐层加速 vips 化（imgproxy 生态成熟、Trendyol 等大厂迁移、sharp 亿级周下载是同一件事的三个投影 [35][37][23]）；新格式竞赛进入"库内闭环"阶段（AVIF/JXL/UltraHDR/RAW 被 8.18 一波补齐后，选型权重从"支不支持"滑向"多快多省" [27]）；安全治理从 policy.xml 走向进程隔离（利好服务化封装 [35]）。风险各一：ImageMagick 的风险是 delegate 链的长期安全维护负担；libvips 的风险是上游小众格式仍需借道 IM/GM——vips 虽早在 2005 年就内置 DICOM3 基础支持 [6]，但超出其 loader 覆盖的老式/非标准 DICOM 变体没有保证，底层依赖随之集中 [26]。

7. 验证方法（本综合报告即照此执行）。 版本取官网/GitHub API、性能取官方基准 wiki、下载量与许可取官方 API 实测；二手评测只用来找线索，不用来下结论。两份部件同日实测出现的版本口径分歧（IM -34/-35、ffmpeg 8.0/9.0.2），正是靠"回到一手来源再测一次"消解的。

最小可运行批量管线：目录约定 + make 增量构建 + 失败处理 + 验收

上面七条建议给的是选型、配方与判断，这一节把它们拼成一个可以直接抄走的最小骨架——"批量管线"四个字的工程落地。实测状态：本节模板未在本机复核环境跑通（该环境无 make / GNU parallel），语法为 GNU make 与 GNU parallel 的标准用法，落地前请先小批量试跑；Makefile 的 recipe 行必须以制表符开头。

目录约定——约定先行，管线才可重跑：

raw/   原图，只读：任何步骤都不得写回 raw/
work/  中间产物：抽帧、去噪等可丢弃步骤，可随时清空
out/   最终交付物：缩略图、转码图，只允许完整文件进入
log/   构建日志与失败清单，按日期归档

make 增量构建模板——把每张图的目标文件作为 target，源图 mtime 未变就跳过：

SRC := $(wildcard raw/*.jpg)
OUT := $(patsubst raw/%.jpg,out/%.jpg,$(SRC))

.DELETE_ON_ERROR:            # 任一步失败即删除写了一半的产物，半成品不进 out/

all: $(OUT)

out/%.jpg: raw/%.jpg | out
	magick $< -resize 1600x -quality 82 $@    # 换 libvips：vipsthumbnail -s 320 -o 'out/%s.jpg' $<

out:
	mkdir -p out

• 断点续跑：首次 make -j8 全量构建；中断或失败后再跑 make，只重建缺失与过期的 target——万级图库的重复处理成本趋近于零（并行方式与内存预算见建议 2）。
• 失败重试：.DELETE_ON_ERROR 保证"写一半"的文件不混进交付目录，make 退出码非零即停，接 CI/定时任务即可告警。个别源图损坏这类永久性失败不要让它卡死整批——make -k 跑完可跑的，再从日志收集失败清单人工处置；用 GNU parallel 时，--joblog log/build.log --retry-failed 可只重跑上次失败的任务。
• 日志：make -j8 2>&1 | tee log/build-$(date +%F).log，让每次构建可追溯。

parallel 变体（不想写 Makefile 时的等价一行）：

ls raw/*.jpg | parallel -j8 --joblog log/build.log \
  'magick {} -resize 1600x -quality 82 out/{/} || echo {} >> log/failures.txt'
# 重试：parallel --joblog log/build.log --retry-failed

验收——管线跑完不算完，验收过关才算完：

# 数量核对：raw/ 与 out/ 一一对应
ls raw/*.jpg | wc -l; ls out/*.jpg | wc -l
# 可读性抽查：随机抽样若干张，确认能被独立解码
magick identify out/sample.jpg        # libvips 侧等价：vipsheader out/sample.jpg
# 元数据验收：交付图剥离隐私元数据（配方 F-05）
exiftool -all= -overwrite_original out/*.jpg

这套骨架的最小完备集是三件套：增量（make target / parallel --joblog）、容错（.DELETE_ON_ERROR、-k、--retry-failed、失败清单）、验收（数量 + 解码抽查 + 元数据）。远端分发、缓存、通知等更大的需求，在这之上按需生长。

参考来源

以下为两份部件报告来源合并去重后的清单（编号 [1]–[38]），全部 URL 原样保留；末尾 [39] 为本综合报告新增复核记录，[40]–[42] 为终稿修订时新增的一手来源。

1. ImageMagick 官方 History（Cristy 自述，官方页镜像；原站 imagemagick.org/history.php 本次访问已 404）：https://perlwatch.net/docs/sharedocs/ImageMagick-6/www/history.html
2. Wikipedia – ImageMagick：https://en.wikipedia.org/wiki/ImageMagick
3. GraphicsMagick News（2002-11-19 分叉自 5.5.2，原文 "several days before the ImageMagick 5.5.2 release"；1.3.46 @ 2025-10-29）：http://www.graphicsmagick.org/NEWS.html
4. GraphicsMagick 版权与许可（独立于 IM 的声明，MIT 风格）：http://www.graphicsmagick.org/Copyright.html
5. ImageMagick 6.0.0 发布公告（2004-04-15，邮件列表存档）：https://sourceforge.net/p/fontlinge/mailman/fontlinge-devel/thread/200404151403.i3FE3pI0025878@studio.imagemagick.org
6. libvips 官方 Wiki – History（全文阅读）：https://github.com/libvips/libvips/wiki/History
7. Wikipedia – FFmpeg：https://en.wikipedia.org/wiki/FFmpeg
8. GNU Parallel 20100601 首发（info-gnu 邮件列表，2010-06-01）：https://lists.gnu.org/archive/html/info-gnu/2010-06/msg00005.html
9. Tange, *GNU Parallel: The Command-Line Power Tool*, USENIX ;login: 36(1), 2011：https://www.usenix.org/publications/login/february-2011-volume-36-number-1/gnu-parallel-command-line-power-tool
10. libvips 官方博客 – What's new in 8.7（2018-07-26，全文阅读；magicksave 一节原文仅称 "Work by dlemstra"）：https://www.libvips.org/2018/07/26/What's-new-in-8.7.html
11. Wikimedia Diff – VipsScaler 部署（2013-09-12）：https://diff.wikimedia.org/2013/09/12/vipsscaler-implementation-wikimedia-sites
12. Wikitech-ambassadors – 迁移公告（2013-06）：https://lists.wikimedia.org/pipermail/wikitech-ambassadors/2013-June/000270.html
13. sharp npm 主页（"比 ImageMagick/GraphicsMagick 快 4–5x"）：https://www.npmjs.com/package/sharp
14. Fuller, *Looking sharp: 10 years of Node.js image processing*, LNUG 2024-06：https://lnug.org/talks/looking-sharp-10-years-of-node-js-image-processing-lovell-fuller-at-lnug-104-june-2024-YEE1Kp4ZS4w
15. ImageMagick 官方 changelog（IM7 起的变更记录）：https://imagemagick.org/changelog
16. ImageTragick 披露站：https://imagetragick.com
17. NVD – CVE-2016-3714：https://nvd.nist.gov/vuln/detail/CVE-2016-3714
18. Cloudflare – Inside ImageTragick（2016-05-09）：https://blog.cloudflare.com/inside-imagetragick-the-real-payloads-being-used-to-hack-websites-2
19. ImageMagick 官方发布档案（6.9.3-10@2016-05-03、6.9.13-54@2026-07-27 等，部件实测）：https://download.imagemagick.org/archive/releases/
20. IM6 End-of-Life 公告（ImageMagick6 discussion #422：2026-05-01 停常规维护 / 安全至 2029-04-01）：https://github.com/ImageMagick/ImageMagick6/discussions/422
21. delegates.xml 将 MPEG 委托给 ffmpeg/avconv 的实践证据（正文引用见"能力：格式覆盖与操作广度"一节）：https://stackoverflow.com/questions/48493012/ 、https://trac.macports.org/ticket/42299
22. libvips GitHub Releases（8.13.0@2022-07-21 … 8.18.7@2026-09-26、8.19.0-rc1@2026-11-01；CVE-2025-59933 于 8.17.2 修复）：https://github.com/libvips/libvips/releases
23. npm downloads API（sharp，2026-10-28~11-03 一周 157,439,870 次，实测）：https://api.npmjs.org/downloads/point/last-week/sharp ；registry 许可字段 https://registry.npmjs.org/sharp/latest
24. ImageMagick 官方 formats 文档（约 190 格式标签与 delegate 依赖）：https://imagemagick.org/formats/
25. ImageMagick License（"Compatible with the GPL v3"）：https://imagemagick.org/license/
26. libvips 官网（版本、绑定、格式、采用者、许可）：https://www.libvips.org/
27. What's new in libvips 8.18（2025-12-04，UltraHDR/dcrawload/Oklab；发布本体为 2025-12-17）：https://www.libvips.org/2025/12/04/What's-new-in-8.18.html
28. libvips 官方基准 wiki（Speed and memory use，页面自述最后运行 2025-08-12；版本标注矛盾见正文说明）：https://github.com/libvips/libvips/wiki/Speed-and-memory-use
29. ImageMagick GitHub Releases（发版节奏；CVE-2025-55004 于 7.1.2-1 修复）：https://github.com/ImageMagick/ImageMagick/releases
30. ffmpeg 官网与下载页（9.0.2）、8.0 "Huffman"（2025-08-22）LWN 报道：https://www.ffmpeg.org ；https://ffmpeg.org/download.html ；https://lwn.net/Articles/1034813
31. ffmpeg 滤镜文档（palettegen/paletteuse、tonemap 等）：https://ffmpeg.org/ffmpeg-filters.html
32. ImageMagick 的 ffmpeg delegate 命令实据与抽全帧资源警告（Magick.NET issue #312；Omeka 论坛）：https://github.com/dlemstra/Magick.NET/issues/312 ；https://forum.omeka.org/t/imagemagick-issue/27903
33. sharp 文档（libvips 起源 1989 Birkbeck College）：https://sharp.pixelplumbing.com
34. Pillow 13.0.0（2025-10-15，季度节奏，EPS/JPEG/TIFF 安全修复）：https://pypi.org/project/pillow/ ；https://github.com/python-pillow/Pillow/releases
35. imgproxy 文档与服务器基准（Go + libvips，Pro 商业版）：https://docs.imgproxy.net ；https://imgproxy.net/blog/image-processing-servers-benchmark
36. Cloudinary 基于 ImageMagick 的官方叙述与 HEIC/libheif 佐证：https://cloudinary.com/blog/the_power_of_imagemagick_with_the_speed_and_simplicity_of_cloudinary ；https://stackoverflow.com/questions/60791269/
37. Trendyol：ImageMagick → libvips/imgproxy 迁移实践：https://medium.com/trendyol-tech/implementing-an-image-processing-service-using-imgproxy-e4755a47f3c5
38. GNU Parallel 官网：https://www.gnu.org/software/parallel/
39. 本综合报告复核记录（2026-11-05，初稿初核 + 终稿复核各一轮，均为实测）：curl -s "https://api.github.com/repos/ImageMagick/ImageMagick/releases?per_page=8"（7.1.2-35 @ 2026-10-31 至 7.1.2-28 @ 2026-07-27 共 8 条，其中 -28/-29 同日）；…releases?per_page=100（7.1.2-0 @ 2025-07-13）；curl -s "https://api.github.com/repos/libvips/libvips/releases?per_page=25"（v8.19.0-rc1 @ 2026-11-01、v8.18.7 @ 2026-09-26、v8.18.0 @ 2025-12-17、v8.18.0-rc1 @ 2025-12-05、v8.17.2 @ 2025-09-13）；curl -s https://ffmpeg.org/download.html（当前主推 ffmpeg-9.0.2 tar 包）；curl -s https://raw.githubusercontent.com/wiki/libvips/libvips/Speed-and-memory-use.md（基准页全文：自述最后运行 2025-08-12；版本列 vips 8.18、pillow-simd 9.5.0、ffmpeg 7.1.1、IM 7.1.1；pillow-simd 行用时 1.51 s / ratio 列 1.96）；curl -s https://raw.githubusercontent.com/libvips/libvips/master/man/vipsthumbnail.1（-o/--path 输出路径模板语义，默认 %d/tn_%s.jpg）；curl -s https://api.github.com/users/dlemstra（bio："Maintainer of @ImageMagick and its .NET … library called Magick.NET"）；curl -s http://www.graphicsmagick.org/NEWS.html（"several days before the ImageMagick 5.5.2 release"）；winget search exiftool（包 ID OliverBetz.ExifTool，13.59）。
40. vipsthumbnail(1) man page（libvips 仓库 master 分支；-o/--path 为输出路径模板，%s=输入文件名去扩展名，示例 vipsthumbnail --size=64 -o thumbnails/%s.png fred.jpg）：https://raw.githubusercontent.com/libvips/libvips/master/man/vipsthumbnail.1
41. Dirk Lemstra GitHub 主页（bio：Maintainer of @ImageMagick and its .NET Standard/Framework library called Magick.NET）：https://github.com/dlemstra
42. libvips/nip4 仓库（"image processing spreadsheet"，2024-02 创建）：https://github.com/libvips/nip4

不确定点诚实声明

• IM 7.0.0 首个稳定版的确切发布日未逐日核实（多方口径为 2015 年，beta 自 2014-01 起）[15][29]。
• ImageMagick 官网 history/changelog 等页面本次直连多为 404/超时，改用镜像与 GitHub 仓库佐证 [1]。
• IM6 EOL 公告在部件检索中曾有"6.9.13-60 为 6.x 最后发布"之说，与官方档案实测（2026-07 仍有 6.9.13-54 及更晚编号）口径不一致；本报告按官方公告"安全修复持续中"表述 [19][20]。
• OpenCV 的具体小版本、imgproxy 的具体小版本未核验，正文如实标注，未做推测性填充。
• sharp 周下载量 157,439,870 对应窗口为 2026-10-28~11-03，为两份部件当日经 npm 官方 API 独立取得的同一数字；本综合未重测（窗口会随日期平移），引用时请带窗口日期 [23]。
• libvips 基准页内部矛盾（自述运行日 2025-08-12 vs 版本列 vips 8.18，而 8.18.0 实测 2025-12-17 发布）无法从页面本身判定孰真孰假，本报告按页面原样引用相对倍数与内存数并如实标注 [28][39]。
• Pillow-SIMD 行的倍数矛盾（页面 ratio 列 1.96× vs 用时列 1.51 s 复算 2.65×）同样按"以用时列复算为准 + 脚注标明"处理 [28]。
• 配方区（建议 5 的 F-01–F-05）与"最小可运行批量管线"一节的 Makefile/parallel 模板均未在本机复核环境实测（该环境仅安装 ffmpeg，无 make/parallel/图像 CLI）；vipsthumbnail -o 的路径模板语义已对照官方 man 页核对 [40]，exiftool 的 winget 包 ID 已实测核对 [39]，其余请以官方文档为准。
• exiftool 的 scoop 安装方式未核验，Windows 侧仅确认 winget 渠道。