十六站走完，回头看整条链路：采集、解析、处理、分析、输出、展示——把第 1 章的路线图、第 2 到 15 章的工具与心法，织成一张随时可查的全景图
核心方法论：融会贯通
「画家之所以画得好一座桥，是因为他既懂石头的结构，又懂光影的走向。达芬奇的手稿里，解剖、几何、机械、绘画各占一页，但它们本该是一张网。这一章我们把网织起来：先看图像处理的完整生命周期（16.1），再逐个回访工具链上的每一站（16.2），用一条 RAW 照片的流水线把各章 API 串起来（16.3），把四类工程问题的方法论沉淀成档案（16.4），最后眺望格式演进与 AI 时代（16.5），并交给你一张全书速查表（16.6）。融会贯通，就是把散落的招式连成自己的套路。」
第 1 章 1.6 节给过一张全书路线图：十六个章节分成「图像基础与格式」（1~4）、「图像处理库实战」（5~8）、「计算机视觉与 GPU 加速」（9~12）、「深入工程实践」（13~16）四个部分。现在站在终点回头看，这张路线图其实是沿着一条隐形的流水线铺开的。把第 1 章 1.3 节的三类需求（转码、预览、视觉）翻译成六个环节，就是图像处理的完整生命周期：采集 → 解析 → 处理 → 分析 → 输出 → 展示。一张照片从相机快门到用户屏幕，每一步都有专门的工具、专门的账本、专门的坑——全书十六章，正好一站一站地把这条路走了一遍。
逐个环节对号入座。采集是入口：相机拍出的 CR2、手机存下的 HEIC、用户随手传的 JPEG，格式五花八门——这正是第 1 章说的「格式碎片化」。解析是把文件解码成像素矩阵：RAW 底片要交给 LibRaw（第 3、6 章），通用格式靠 libvips 或 OpenCV 的加载器，元数据则由 Exiv2 与 exiftool 解读（第 4 章）。处理是转码与缩放：libvips 的 thumbnail 把 HEIC 变成网页要的 JPEG（第 7 章），内存账本按「宽 × 高 × 通道 × 字节」计算（第 15 章）。分析是理解内容：Mat 承载像素（第 9 章），Harris 角点与 Canny 边缘提取骨架（第 10 章），嫌 CPU 慢就上 CUDA 像素级并行（第 11、12 章）。输出是把结果编码回文件：imwrite 落盘、imencode 进内存（第 9 章），JPEG 一代损失的铁律在这里把关（第 2 章）。展示是分发：给列表页 200 宽的缩略图、给详情页 1280 的大图——第 1 章的带宽账本决定给哪张。
# 一张照片从快门到用户屏幕，走完整个生命周期（对照 1.3 节的三类需求）
# ① 采集 相机/手机拍摄，或用户上传 → IMG_0001.CR2 / IMG_0001.HEIC
# ② 解析 把文件解码成像素矩阵——格式不同，解码器不同（第 3、6、7 章）
# ③ 处理 转码、缩放、颜色空间转换（第 2、7、15 章）
# ④ 分析 理解内容：角点、边缘、识别（第 9、10 章）
# ⑤ 输出 编码回 JPEG/WebP/PNG，按场景决定质量与尺寸（第 2、9 章）
# ⑥ 展示 分发缩略图/大图，带宽账本决定给哪张（第 1 章）# 六环串成一条命令链——每一站都是前面章节出现过的真命令
$ file IMG_0001.CR2 # ① 采集：先认门牌号（第 3 章）
# Canon CR2 RAW image data, 6000x4000, little-endian
$ exiftool -DateTimeOriginal IMG_0001.CR2 # ② 解析：元数据先行（第 4 章）
# 2026:08:08 10:24:36
$ vips thumbnail IMG_0001.ppm thumb.jpg 800 # ③ 处理：缩略图（第 7 章）
$ ./mark_features thumb.jpg marked.jpg # ④ 分析：角点标注（第 10 章）
$ ls -lh thumb.jpg marked.jpg # ⑤ 输出：编码产物落盘
# ⑥ 展示：CDN 按设备分发 200/800/原图三个版本，对应第 1 章的带宽账本生命周期画出来了，再把工具摆进对应的站。全书反复出场的主力是四座：LibRaw 负责「读」RAW——第 6 章讲过它的核心三步 open_file() → unpack() → dcraw_process()，分别对应第 3 章五层结构里的「解析文件头与元数据」「解压传感器图像数据」「去马赛克等后处理」，命令行对应 dcraw_emu（素材时代的叫法是 libraw_dcraw）；libvips 负责「转」——需求驱动、水平线程（第 15 章展开过），vips thumbnail / vipsthumbnail 一条命令出缩略图，几乎不占内存；OpenCV 负责「看」——imread 把图读进 Mat，cvtColor、cornerHarris、Canny 做视觉分析，imwrite 落盘（第 8、9、10 章）；CUDA 负责「快」——nvcc 编译内核，cudaMalloc/cudaMemcpy/cudaFree 管理显存，把逐像素的操作从 CPU 循环搬上 GPU（第 11、12 章）。
四座站怎么配合？记住一条主线：数据以「像素矩阵」为通用货币，站与站之间只交换文件或内存缓冲。RAW 底片只有 LibRaw 读得懂，解成位图后 libvips 就能缩、OpenCV 就能分析——第 7 章提过，libvips 自己也通过 libraw 插件读 RAW，OpenCV 的 imread 也能读常见格式，但「各有所长、按需取用」才是选型的正解：解码方言最全的是 LibRaw，批处理最省内存的是 libvips，算法体系最全的是 OpenCV，像素级并行最快的是 CUDA。第 5 章的六库对比表（Exiv2 元数据 / libvips 高性能 / CImg 单头 / LibRaw RAW / CxImage Windows / OpenCV 视觉）做的正是这件事：先认清每个工具的生态位，再谈组合。
# 第 5 章六库全景，一站一句——职能定位决定选型：
# Exiv2 —— 元数据读写：open → readMetadata → exifData（第 4 章）
# libvips —— 高性能转码：需求驱动、水平线程，几乎不占内存（第 7、15 章）
# CImg —— 单头文件轻量库：矩阵运算与显示方便（第 5 章）
# LibRaw —— RAW 解码专用：open_file → unpack → dcraw_process（第 3、6 章）
# CxImage —— Windows/MFC 生态的图像类（第 5 章）
# OpenCV —— 计算机视觉事实标准：Mat + 特征检测 + DNN（第 8、9、10 章）# 一条 RAW 照片的旅程：四站接力，各管一段（对应 16.1 的生命周期）
$ dcraw_emu IMG_0001.CR2 # 站 1：LibRaw 把底片解成位图（第 6 章）
$ vips thumbnail IMG_0001.ppm web.jpg 1280 # 站 2：libvips 转码出预览图（第 7 章）
$ opencv_version # 站 3：OpenCV 就位，待会儿做视觉分析（第 8 章）
# 4.13.0
$ nvcc --version # 站 4：CUDA 编译器就位，像素级并行加速（第 11 章）
# Cuda compilation tools, release 12.4理论回顾不如一条真流水线。素材里反复出现的 IMG_0001.CR2（6000×4000 的佳能底片）今天走完全程：第一站 LibRaw 解码，dcraw_emu 把底片解成同名 PPM（Netpbm 格式，每像素 RGB 三字节，第 1 章那个 2×2 的 tiny.ppm 的放大版）；第二站 libvips 缩略，vips thumbnail 把 6000×4000 的位图缩成 800 宽 JPEG——需求驱动让它只算要用的像素，峰值内存远小于全量解码；第三站 OpenCV 分析，写一个 mark_features.cpp：imread 读缩略图、cvtColor 转灰度、cornerHarris 算角点响应、threshold 筛出真正的角点、circle 画圈、imwrite 落盘。三站之间只交换文件，每一站都是前面章节写过的 API，没有任何新面孔。
为什么先缩略再分析？算一笔第 15 章的账：6000×4000×3×1 = 7200 万字节，约 68.7 MiB——这是全量解码的代价；缩到 800 宽之后只有 800×533×3×1 ≈ 1.3 MiB，内存差 55 倍，cornerHarris 的邻域求和运算量也按像素数同比缩小。服务端批量处理时，这笔账按并发数再放大（第 1 章的 3.4 GiB 案例）。还要复习第 2 章的铁律：中间产物绝不做「JPEG 转 JPEG」——所以本流水线从 RAW 直接到 PPM（无损）再到 JPEG，全程只有一次有损编码。这也解释了为什么「原始上传文件原样存档、下游产物从原始文件现算」是转码管线的正确姿势。
# 流水线第一步：LibRaw 解码（CR2 → PPM，默认产物与输入同名）
$ dcraw_emu -v IMG_0001.CR2
$ file IMG_0001.ppm
# IMG_0001.ppm: Netpbm PPM image, 6000x4000, RGB
# 素材时代的叫法是 libraw_dcraw，现行 0.22 源码树对应 dcraw_emu（第 6 章）
# 流水线第二步：libvips 缩略图（PPM → 800 宽 JPEG，需求驱动几乎不占内存）
$ vips thumbnail IMG_0001.ppm thumb.jpg 800
$ vipsheader thumb.jpg
# thumb.jpg: 800x533 uchar, 3 bands, srgb, jpegload
# 流水线第三步：OpenCV 特征标注（第 10 章，下一块代码的 mark_features.cpp）
$ g++ mark_features.cpp -o mark_features $(pkg-config --cflags --libs opencv4)
$ ./mark_features thumb.jpg marked.jpg
$ ls -lh IMG_0001.CR2 IMG_0001.ppm thumb.jpg marked.jpg// mark_features.cpp —— 缩略图上标注角点（复用第 9、10 章的 Mat 与 Harris）
#include <opencv2/opencv.hpp>
#include <iostream>
int main(int argc, char** argv) {
cv::Mat img = cv::imread(argv[1], cv::IMREAD_COLOR);
if (img.empty()) return 1; // 空 Mat 直接退（第 9 章）
cv::Mat gray, R, Rth;
cv::cvtColor(img, gray, cv::COLOR_BGR2GRAY); // 转灰度：Harris 的输入
cv::cornerHarris(gray, R, 3, 3, 0.04); // 角点响应图（10.3 节）
cv::threshold(R, Rth, 0.01, 255, cv::THRESH_BINARY); // 阈值筛角点
for (int y = 0; y < Rth.rows; y++)
for (int x = 0; x < Rth.cols; x++)
if (Rth.at<uchar>(y, x) != 0)
cv::circle(img, cv::Point(x, y), 4,
cv::Scalar(0, 0, 255), 2); // 红圈标角点
cv::imwrite(argv[2], img); // 服务端用 imwrite 落盘
return 0;
}# 每一站的账（第 15 章的内存公式：宽 × 高 × 通道 × 字节）：
# CR2 文件 ~20 MB 压缩后的底片（第 3 章）
# 解码成 RGB 位图 6000×4000×3×1 = 72,000,000 B ≈ 68.7 MiB ← 全量解开的代价
# 800 宽缩略图 800×533×3×1 ≈ 1.3 MiB ← 需求驱动只算要用的
# 缩略图阶段内存差约 55 倍——这就是「先缩略、再分析」的原因
# 铁律复习（第 2 章）：中间产物别做 JPEG 转 JPEG，一代损失逐级叠加画一幅完整的画，先打轮廓再填细节；搭一条图像流水线也一样：先定六环节（采集→解析→处理→分析→输出→展示），再给每站挑工具，最后才写代码。站与站之间用「文件 + 像素矩阵」两个约定交换数据，任何一站换掉都不影响其他站——这就是融会贯通的结构感。
十六章学完，真正能带走的是方法论。把全书内容按问题类型归档，正好四类。第一类：格式问题——「这是什么格式、该选什么格式、文件里藏着什么」归第 2、3、4 章：JPEG 的 DCT 与量化解释有损从哪来（2.2），RAW 的五层结构与 IFD/tag 让底片不再神秘（3.2），EXIF 与 XMP 是拍摄参数的存档（4.2）。这类问题的关键词是「结构」：先读文件头认门牌号，再谈解析。第二类：库的问题——「该用哪个库、怎么装、怎么调」归第 5 到 10 章：六库对比定生态位（5），LibRaw 三步走读 RAW（6），libvips 转码（7），OpenCV 的安装与 Mat 核心（8、9），特征检测（10）。关键词是「生态位」：每个库都有自己的主场，选型先问场景。
第三类：排错问题——「报错了怎么办」归第 13、14 章，这是全书最硬核的部分：依赖与链接排错（13）教你先画依赖树、再用 ldd 取证、用 nm 验符号——第 7 章存档的 fribidi 悬案（undefined reference）在那里正式结案；版本与崩溃调试（14）教你 ABI 的概念、用 core dump 封存现场、gdb 的 bt/frame/print 三板斧、-g -O0 让证据可读、strace 做外层定位——第 6 章存档的 g++ 4.8.5 崩溃案在那里结案。关键词是「先取证，不猜」：报错形态决定路线——not found 指向版本、undefined reference 指向链接、Segmentation fault 指向内存。第四类：性能问题——「怎么变快」归第 15 章：先测后优立规矩，time 与 steady_clock 掐表，内存账本与缓存局部性，线程池与任务并行，libvips 的需求驱动与水平线程是完整战例。关键词是「先测后优」：没有数字，不动代码。
# 四类问题 → 对应章节 → 核心方法（16.4 节正文）：
# 格式问题：第 2 章 JPEG DCT/量化，第 3 章 RAW 五层结构，第 4 章 EXIF/XMP
# 关键词：结构——先读文件头，再谈解析
# 库的问题：第 5 章选型，第 6 章 LibRaw，第 7 章 libvips，第 8-10 章 OpenCV
# 关键词：生态位——每个库都有自己的主场
# 排错问题：第 13 章依赖链接，第 14 章版本与崩溃调试
# 关键词：先取证，不猜——报错形态决定路线
# 性能问题：第 15 章先测后优、内存账本、缓存、多线程
# 关键词：没有数字，不动代码# 排错工具箱复习（第 13、14 章）：先读报错形态，再选取证工具
$ ldd /usr/local/vips/bin/vips | grep fribidi # 13.2：解析到了哪份库？
# libfribidi.so.0 => /lib64/libfribidi.so.0 (0x00007f...) ← 正确路径
$ nm -D /usr/lib64/libfribidi.so.0 | grep fribidi_get_par # 13.3：符号在不在？
# 0000000000002a30 T fribidi_get_par_embedding_levels_ex
$ ulimit -c unlimited # 14.4：崩溃必留现场
$ gdb -q ./raw2ppm core.12345 # 14.4：复盘崩溃瞬间
(gdb) bt # 调用栈，帧 0 是崩溃点
$ strace -o trace.log ./raw2ppm IMG_0001.CR2 # 14.6：死前走到哪一步先看格式演进。第 2 章讲过选型的本质是「体积、质量、功能、兼容性」的取舍，这条规律二十年没变，变的只是候选格式：JPEG（1992，有损 DCT）统治了照片三十年；PNG（1996，无损 DEFLATE）守住图形与透明；WebP（2010）由 Google 推出，支持有损、无损与透明，同等质量下体积通常小于 JPEG，libvips 的依赖矩阵里那个 libwebp 就是它（第 7 章）；HEIC（2015）是 HEIF 容器 + HEVC 编码，iPhone 默认格式，第 7 章用 libheif + libde265 装过它的解码链；AVIF（2019）是 HEIF 容器 + AV1 编码，编码开放、免专利费，被普遍视为 JPEG 的下一代继任者。第 7 章结尾埋的那句「HEIC/AVIF 的演进脉络第 16 章再串一遍」，就在这里兑现：容器（HEIF）与编码（HEVC/AV1）分离的架构，让同一套容器可以换装不同的编解码器——这正是第 7 章「容器层与编解码层」系统分析的价值。
再看 AI 方向。第 8 章装 OpenCV 时提过一句「4.0 起内置 DNN 深度学习模块」——那是传统视觉与深度学习的接口。今天图像处理的上层建筑已经换成神经网络：训练框架（PyTorch、TensorFlow）负责从数据里学出模型，推理库（ONNX Runtime、OpenVINO、TensorRT）负责把模型高效跑起来——OpenVINO 专攻 CPU 与集显、TensorRT 专攻 NVIDIA GPU，跟第 11 章 CUDA 的加速思路一脉相承；而第 10 章学的 Harris 角点、Canny 边缘这些「手工特征」，正是理解 CNN 特征提取的最好地基——卷积核扫图像和 Sobel 算子扫图像，数学上是同一族操作。继续学习的路线建议：先把第 15 章的性能心法内化（任何 AI 推理服务最终都要回到内存账本与并发），再补线性代数与概率统计，然后用 OpenCV 的 DNN 模块或 PyTorch 跑一个图像分类/分割的小项目，把传统视觉与深度学习在同一个数据集上对照——你会发现，融会贯通的不是工具，是「图像 = 像素矩阵 + 数学操作」这个第一性原理。
# 格式演进时间线（第 2、7 章素材）：
# JPEG 1992 有损、DCT、8×8 块 —— 照片事实标准
# PNG 1996 无损、DEFLATE、透明 —— 图形/UI 标准
# WebP 2010 有损+无损+透明 —— 体积通常小于 JPEG（libwebp）
# HEIC 2015 HEIF 容器 + HEVC 编码 —— libheif + libde265（第 7 章）
# AVIF 2019 HEIF 容器 + AV1 编码 —— 开放、免专利费
# 选型的本质不变：体积 / 质量 / 功能 / 兼容性的取舍（第 2 章格式选型表）# AI 图像时代的工具箱（传统视觉的延伸，第 8 章提过 OpenCV 内置 DNN 模块）
$ python3 -c "import cv2; print(cv2.__version__)"
# 4.13.0
# 推理库：ONNX Runtime / OpenVINO / TensorRT —— 把训练好的模型跑起来
# 训练框架：PyTorch / TensorFlow —— 数据、模型、训练的三角
# 传统视觉（Harris/Canny 手工特征）→ 深度特征（CNN 卷积核）是同一目标的两代实现
# 学习路线：性能心法（第 15 章）→ 线性代数/概率 → 小项目对照传统与深度方法最后一节是一张可以贴墙上的速查表。按 16.1 的六环节分组，收录全书出现过的真命令与真 API，每一条都标了出处章节——排错时先翻表定位「这是哪一类问题、该用什么工具」，再回对应章节查细节。表里刻意没有新面孔：十六个章节里反复出现的，才是真正值得肌肉记忆的东西。
| 环节 | 工具 | 命令 / API | 章节 |
|---|---|---|---|
| 解析 | file / vipsheader | file IMG.CR2、vipsheader out.jpg | 3.1 / 7.7 |
| 解析 | exiftool / Exiv2 | exiftool photo.jpg、Exiv2::ImageFactory::open → readMetadata | 4.4 / 4.5 |
| 解析 | LibRaw | dcraw_emu、open_file → unpack → dcraw_process | 6.5 / 6.6 |
| 处理 | libvips | vips thumbnail、vipsthumbnail --size、vipsheader | 7.7 / 15.6 |
| 处理 | OpenCV | cv::imread、cv::imwrite、cv::imencode/imdecode | 9.1 / 9.5 |
| 分析 | OpenCV | cv::cvtColor、cv::cornerHarris、cv::Canny | 10.3 / 10.5 |
| 分析 | OpenCV | Mat 的 at / ptr、CV_8UC3 | 9.3 / 9.4 |
| 加速 | CUDA | nvcc、__global__、cudaMalloc / cudaMemcpy / cudaFree | 11.5 / 12.1 / 12.5 |
| 排错 | ldd / nm / ldconfig | ldd 二进制、nm -D 库、ldconfig、-rpath | 13.2 / 13.3 / 13.5 / 13.6 |
| 排错 | gdb / strace | gdb -q ./prog core、bt、strace -o trace.log | 14.4 / 14.6 |
| 性能 | time / chrono | time ./prog、std::chrono::steady_clock | 15.1 / 15.2 |
| 性能 | 线程池 / libvips | hardware_concurrency、vips_concurrency_set、VIPS_CONCURRENCY | 15.5 / 15.6 |
# 一键体检全书装过的工具链（全部来自前面章节的验证命令）
$ cmake --version | head -1 # 8.3：构建配置工具
$ g++ --version | head -1 # 6.4 / 14：编译器（ABI 的源头）
$ pkg-config --modversion libraw # 6.4：RAW 解码库
$ pkg-config --modversion vips # 7.5：高性能图像库
$ opencv_version # 8.5：计算机视觉库
$ nvcc --version # 11.5：CUDA 编译器
$ exiftool -ver # 4.5：元数据瑞士军刀# 交付前的总检：给第 1 章到第 15 章的每个领域请一位代表
$ file out.jpg # 格式对不对（第 3 章）
$ exiftool out.jpg # 元数据在不在（第 4 章）
$ vipsheader out.jpg # 尺寸/通道/加载器（第 7 章）
$ time ./pipeline.sh IMG_0001.CR2 # 先测后优，留个基线（第 15 章）
# 全链路收束：采集→解析→处理→分析→输出→展示，六站各有其主，工具各归其位判断下列说法对错：① 图像处理生命周期的六环节是「采集 → 解析 → 处理 → 分析 → 输出 → 展示」；② 中间产物用 JPEG 转 JPEG 没有问题，反正质量设高一点就行；③ nvcc 属于 CUDA Toolkit，nvidia-smi 由显卡驱动提供；④ ldd 能直接查出「undefined reference」的根因是版本冲突还是符号缺失；⑤ AVIF 与 HEIC 使用同一个容器（HEIF），只是编码不同。
六环节见 16.1 节；一代损失见第 2 章；「两半分离」见第 11 章；取证工具分工见第 13 章；容器与编码分层见第 7 章与 16.5 节。
① 对——16.1 节的全景图；② 错——每次 JPEG 保存都重新量化、再丢一轮信息，这就是「数字一代损失」，中间产物应该用 PPM/PNG/TIFF 等无损格式，只有最终交付才转 JPEG（第 2 章）；③ 对——驱动管「跑」、Toolkit 管「编」，nvidia-smi 由驱动提供，nvcc 来自 Toolkit（第 11 章）；④ 错——ldd 只回答「解析到哪份库」，符号在不在要靠 nm -D 查，根因要靠组合取证（第 13 章）；⑤ 对——HEIF 是容器，HEVC 与 AV1 分别是 HEIC 与 AVIF 的编码（第 7 章、16.5 节）。
你要把服务端收到的相机 RAW 底片（4000×3000）加工成 800 宽的缩略图，并在缩略图上标注角点供人工复核。① 写出三站流水线的完整命令/程序调用序列（用本章的 mark_features 程序）；② 解释为什么「先缩略、再分析」而不是直接分析原图；③ 算一算全量解码与缩略后各占多少内存（近似 MiB 即可）。
三站对应 16.3 节：LibRaw 解码、libvips 缩略、OpenCV 特征；内存公式是第 15 章「宽 × 高 × 通道 × 字节」；先缩略的理由看 16.3 节第二段。
① dcraw_emu IMG_0001.CR2（解出 PPM）→ vips thumbnail IMG_0001.ppm thumb.jpg 800 → g++ 编译 mark_features.cpp 后用 ./mark_features thumb.jpg marked.jpg 标注角点（16.3 节）；② 先缩略再分析：分析算法的计算量与像素数成正比，cornerHarris 每个像素都要算邻域梯度，800 宽缩略图只有原图的约 1/37 像素，速度与内存同比例下降，且 libvips 的需求驱动让它只解「缩小要用的部分」，峰值内存远小于全量解码（16.3 节、第 15 章）；③ 全量解码 4000×3000×3×1 = 3600 万字节 ≈ 34.3 MiB；800 宽约 800×533×3×1 ≈ 1.3 MiB（第 15 章公式）。
你在一台新服务器上按本书流程编译程序，遇到两个报错：A. 链接时 libpango-1.0.so: undefined reference to 'fribidi_get_par_embedding_levels_ex'；B. 程序运行时执行 LibRaw::open_file 直接 Segmentation fault。请分别判断：① 各属于 16.4 节四类问题中的哪一类？② 各用什么工具、按什么顺序取证？③ 分别对应哪一章的系统解法？
报错形态决定路线：undefined reference 指向链接，Segmentation fault 指向内存；链接问题用 ldd/nm，崩溃问题用 core dump + gdb。
① A 属于排错问题里的「依赖与链接」（第 13 章），B 属于排错问题里的「版本与崩溃」（第 14 章）；② A：先 ldd /usr/lib64/libpango-1.0.so 看 fribidi 解析到哪份库，再 nm -D 查符号在不在，判断是版本不匹配还是符号缺失，必要时 ldconfig 刷新缓存或 -rpath 指路（13.2-13.6 节）；B：先 ulimit -c unlimited 让 core 落盘，再 gdb -q ./prog core 用 bt 看崩溃帧，配合 -g -O0 重编让行号可读，必要时 strace 看死前最后一批系统调用（14.4-14.6 节）；③ A 对应第 13 章 fribidi 案例，B 对应第 14 章 g++ 4.8.5→4.9.2 案例——核心都是「先取证，不猜」。
你从零搭建一个图片服务，输入是 iPhone 用户上传的 HEIC 与相机 RAW，输出是网页缩略图（JPEG/WebP）与「角点标注预览」两张图。请给出：① 完整的工具链选型清单（每件工具一句话职责，并注明出处章节）；② 处理流水线（从上传到输出，按 16.1 六环节标注）；③ 装完环境后的一键体检命令序列；④ 上线前要用第 15 章的方法做哪两件事。
工具清单对照 16.2 节四座主力站 + 元数据工具；流水线对照 16.3 节；体检命令就是 16.6 节第一块代码；性能两件事是「先测基线」与「算内存账」。
① LibRaw（RAW 解码，第 6 章）+ libheif/libde265（HEIC 解码链，第 7 章）+ libvips（转码缩略，第 7 章）+ OpenCV（角点标注，第 10 章）+ exiftool（元数据检查，第 4 章），可选 CUDA（批量加速，第 11、12 章）；② 采集（用户上传）→ 解析（exiftool 验元数据、LibRaw/libheif 解码成位图）→ 处理（vips thumbnail 出 800 宽 JPEG/WebP）→ 分析（mark_features 标注角点）→ 输出（imwrite 落盘）→ 展示（CDN 分发多尺寸，第 1 章带宽账本）；③ cmake --version、g++ --version、pkg-config --modversion libraw、pkg-config --modversion vips、opencv_version、exiftool -ver（16.6 节）；④ 先测后优：用 time 测一批真实样本的转码基线，再决定要不要上 CUDA 或调并发；算内存账：单图峰值内存 × 并发数 = 预算，超出则限制上传尺寸或加流式解码（第 15 章）。