做计算机视觉这门课的实验，很多人前面实验一、实验二混得挺顺，图像滤波、边缘检测、特征点提取，调几个 API 出几张图就交差了。到了实验三"图像拼接"，突然就卡住了——两张照片喂进去，出来的结果要么是纯黑、要么是半张图被裁掉、要么是明显的错位重影。更气人的是，网上搜到的代码复制下来跑一遍，换张图就崩。我前后带过几轮这样的实验，也帮不少人看过跑不通的代码，发现真正的问题往往不在"拼接"这一步，而在单应矩阵估计、画布坐标计算、融合策略这几个环节上。这篇就把图像拼接从特征点检测到最终融合的完整链路拆开讲清楚，解释每一步为什么要这么干、参数怎么定、跑崩了从哪里查。适合正在做这个实验、或者想把原理搞明白而不是只想交作业的人。
1. 图像拼接究竟在算什么东西
1.1 拼接的本质是求一个坐标映射，不是"把两张图拼一起"
大多数人第一次听到图像拼接，脑子里想的是 Photoshop 那种把两张图拖到一起、挪一挪对齐全的感觉。这个直觉没错，但落到代码里它就不成立了——计算机并不知道"挪多少"，它需要你算出一个精确的数学关系。
真实的过程是：在左图和右图里找到一批在现实中是同一个物理点的对应点对，然后用这些点对解出一个 3×3 的矩阵 H，让左图上的每一个像素坐标经过 H 变换之后，落在右图的坐标系里恰好贴在正确位置。这个 H 就是单应矩阵（Homography），也叫投影变换矩阵。拼图动作本身只是把变换后的左图和新画布"贴"在一起，真正的计算量全部在求 H 上面。
这就解释了为什么很多人代码写完图像出来是错的：他可能根本不知道要找对应点，只是把两张图横向拼在一起，结果接缝处对不上。图像拼接的核心从来不是"拼"，而是"对齐"。
记住一句话：图像拼接 = 特征匹配求 H + 透视变换贴图 + 融合消接缝。三件事里第一件决定成败，第二件决定有没有黑边，第三件决定好不好看。
1.2 为什么一定要求拍摄时有重叠区域
单应矩阵需要至少 4 组不共线的对应点对才能解出来，而对应点对来自两张图里共同出现的场景内容。如果两张照片拍的是完全不相干的东西，别说 4 组，1 组都找不到，H 根本无从谈起。
所以实验里选图有个硬性前提：相邻两张图必须有 30% 到 50% 的重叠内容。这个比例不是随便拍脑袋定的。重叠太少，能匹配上的特征点就少，而 RANSAC 又要在里面剔除误匹配，最后剩下的内点可能不够解出稳定的 H，甚至解出来的 H 是错的；重叠太多，虽然匹配点很充足、H 很准，但拼接带来的视野扩展几乎没有意义，一样是浪费。
我在实验里一般会推荐学生拍三张横向扫过的照片，每个相邻对让重叠部分占画面宽度的三分之一左右。这个比例下，一个纹理正常的场景通常能匹配出几百个特征点对，剔除误匹配后还剩几十到上百个内点，解出的 H 非常稳。
1.3 一条完整可跑的流程长什么样
把整个链路串起来，其实只有六步，但这六步每一环都有坑。
- 读入两张图，转成灰度图（特征检测只需要灰度信息）
- 用 SIFT 或 ORB 检测关键点并计算描述子
- 用 FLANN 或 BFMatcher 做描述子匹配，再用比值测试筛掉不可靠的匹配
- 用 RANSAC 从匹配点对里估计单应矩阵 H，同时得到内点掩码
- 计算变换后图像的边界范围，得到新画布尺寸和平移矩阵 T
- 用 warpPerspective 做透视变换，把变换结果和目标图叠加到画布上，再做融合
这套流程里第 5 步是最容易被忽略的。很多人写cv2.warpPerspective(img1, H, (w, h))直接用原图尺寸当画布，结果就是拼接后的左侧大片内容被裁掉，因为透视变换会把一部分坐标推到负值区域去，超出[0, w)的部分直接被丢弃。这是实验里报错最少、但结果最难看的一个问题。
2. 特征点检测与匹配：SIFT 和 ORB 到底怎么选
2.1 检测器的底层逻辑差异
SIFT 的核心是高斯差分金字塔。它在多个尺度上对图像做高斯模糊，相邻两层相减得到 DoG 响应图，然后在尺度空间和图像空间里找局部极值点。这么做的目的是让检测出的关键点具备尺度不变性——同一栋楼，远拍和近拍都能被检测到，只是尺度不同。再叠加方向分配，让它还具备旋转不变性。
ORB 走的是另一条路，它把 FAST 角点检测和 BRIEF 描述子结合起来，再加一层方向计算让 BRIEF 具备旋转不变性，同时用图像金字塔补上尺度不变性。速度比 SIFT 快一个数量级不止，代价是对大尺度变化和大视角变化的鲁棒性弱一些。
在实验场景下选哪个？我的建议是先跑 SIFT 把结果做对，再跑 ORB 做对比分析，这本身就是实验报告里很好的一个对比点。
| 维度 | SIFT | ORB |
|---|---|---|
| 速度（同尺寸图） | 慢，毫秒级到百毫秒级 | 快，通常快 5 到 10 倍 |
| 匹配点数量 | 多，纹理丰富场景可达上千 | 中等，通常几百 |
| 大尺度变化鲁棒性 | 强 | 较弱 |
| 旋转鲁棒性 | 强 | 中等 |
| 是否免费商用 | 早期有专利，现相关专利已到期 | 完全免费 |
| 适合场景 | 精度优先、图少、可离线 | 实时、嵌入式、视频流 |
2.2 匹配阶段：为什么必须做比值测试
拿到两组描述子之后，最直接的匹配方式是暴力匹配：对左图的每个描述子，计算它到右图所有描述子的距离，取最小那个。问题在于，如果场景里有大量重复纹理（比如砖墙、瓷砖地、树叶），最近邻匹配会产生大量"看起来很像但其实错了"的点对。
Lowe 提出的改进做法是：对每个描述子找最近邻和次近邻两个候选，只有当最近距离明显小于次近距离（通常取最近 < 0.75 × 次近）时，才认为这个匹配是可靠的。背后的逻辑很直白——如果一个点有两个几乎一样近的候选，说明这个描述子本身区分度不够，宁可不匹配也不要引入错误。这个 0.75 是经验值，降到 0.6 会匹配更保守、内点比例更高但总数变少，升到 0.85 则匹配数暴增但误匹配也暴增。
import cv2 import numpy as np def detect_and_match(img1, img2, ratio=0.75): gray1 = cv2.cvtColor(img1, cv2.COLOR_BGR2GRAY) gray2 = cv2.cvtColor(img2, cv2.COLOR_BGR2GRAY) sift = cv2.SIFT_create() kp1, des1 = sift.detectAndCompute(gray1, None) kp2, des2 = sift.detectAndCompute(gray2, None) index_params = dict(algorithm=1, trees=5) # 1 表示 FLANN_INDEX_KDTREE search_params = dict(checks=50) matcher = cv2.FlannBasedMatcher(index_params, search_params) raw = matcher.knnMatch(des1, des2, k=2) good = [] for pair in raw: if len(pair) < 2: continue m, n = pair if m.distance < ratio * n.distance: good.append(m) return kp1, kp2, good这里有个必须提醒的坑：不同 OpenCV 版本下knnMatch的返回结构不一样。老版本返回的是嵌套 list，直接for m, n in matches就行；较新的版本对每个查询点返回的是一个 tuple，长度可能不足 2（当目标描述子数量不够时），直接解包会抛ValueError: not enough values to unpack。我在上面代码里加了len(pair) < 2的判断，就是专门堵这个洞。
2.3 特征点数量异常时先查这几件事
实测中最常见的异常是匹配点数为零，或者只有寥寥几个。按这个顺序排查基本能定位：
- 图像通道搞错：把彩色图直接喂给
detectAndCompute，有些版本不报错但行为异常。老老实实转灰度。 - 重叠区域不足：两张图根本没有共同内容，再好的算法也救不了。
- 图片尺寸过大：一亿像素的图跑 SIFT 又慢又容易内存爆，做实验前先缩放到长边 1000 到 1500 像素。
- 纹理过于均匀：纯色墙面、天空占据主体的照片，特征点天然就少，换图比调参有效。
- 对比度过低：严重欠曝或过曝的图像，先做一次直方图均衡化再检测。
我把这些整理成一张排查表放在实验讲义里，学生自己对照着查，能省一大半问答时间。
| 现象 | 最可能原因 | 处理方向 |
|---|---|---|
| 匹配数为 0 | 无重叠 / 未转灰度 | 换图，检查通道 |
| 匹配数极少（<10） | 纹理弱、尺寸过大、对比度低 | 缩放、均衡化、换图 |
| 匹配数很多但 H 错 | ratio 阈值过松 | 降到 0.65 到 0.7 |
| 跑得极慢 | 图太大、trees/checks 参数过高 | 缩放、降 trees 到 4 |
3. 单应矩阵与 RANSAC：整个实验最容易翻车的一步
3.1 那个 3×3 矩阵在几何上代表什么
单应矩阵是一个 3×3 的矩阵，去掉整体尺度缩放后有 8 个自由度，所以理论上 4 组对应点就能把它定下来。它描述的是两个平面之间的投影映射关系——注意，是平面到平面。这也是为什么图像拼接里拍的东西最好是有一定距离的平面或者远景：如果前景有近处的物体、背景是远处的建筑，两者视差很大，单一 H 无法同时对齐两者，拼接结果就会出现前景错位、背景对齐的诡异效果。
这个限制在实验中很关键。拍桌面上的书本做拼接，书和桌面不在同一个深度，拼接出来必然有鬼影；拍远处的一整排建筑、一面墙、一块展板，效果就非常干净。我一般建议学生用室外建筑立面或者室内整面书墙作素材，成功率最高。
数学上，H 作用于齐次坐标：
$$\begin{bmatrix} x' \ y' \ w' \end{bmatrix} = H \begin{bmatrix} x \ y \ 1 \end{bmatrix}$$
最终像素坐标是(x'/w', y'/w')。这个除法就是"透视"二字的来源——离相机近的部分被放大，远的部分被压缩，正是人眼看世界的效果。
3.2 RANSAC 在做什么：不断抽样、不断投票
拿到几百个匹配点对之后，直接用最小二乘拟合 H 是灾难性的，因为里面一定混着错误匹配，最小二乘对离群点毫无抵抗力，几个坏点就能把结果拽偏。
RANSAC 的思路是"少数服从多数"的暴力民主：
- 随机抽 4 组点对，解一个候选 H
- 把所有匹配点对用这个 H 变换一遍，看变换后和实际位置的误差
- 误差小于阈值的算内点，统计内点数量
- 重复若干次，保留内点最多的那个 H
- 最后用这组内点重新精算一次 H
cv2.findHomography把这一整套封装好了，只需要传源点、目标点、方法（cv2.RANSAC）和重投影阈值。
src_pts = np.float32([kp1[m.queryIdx].pt for m in good]).reshape(-1, 1, 2) dst_pts = np.float32([kp2[m.trainIdx].pt for m in good]).reshape(-1, 1, 2) H, inlier_mask = cv2.findHomography(src_pts, dst_pts, cv2.RANSAC, 4.0) inlier_count = int(inlier_mask.sum()) print(f"总匹配 {len(good)}，内点 {inlier_count}，内点率 {inlier_count/len(good):.1%}")那个4.0是重投影误差阈值，单位是像素。含义是：一个点经过 H 变换后，如果和它对应点的距离在 4 个像素以内，就认为是内点。这个值不能乱设——设太小（比如 1.0），稍微有点噪声的点都被判成外点，内点数量不足，H 反而不稳；设太大（比如 20），一堆错误匹配被当成内点，H 直接被带偏。4 到 5 像素是绝大多数场景下的稳妥区间。
3.3 内点率是最有用的健康指标
我在实验里要求学生必须把内点率打印出来，因为它能直接反映这一步做得对不对。经验上的判断标准：
- 内点率> 60%：匹配质量很好，H 基本可信
- 内点率30% 到 60%：可以接受，但拼接结果可能有轻微错位
- 内点率10% 到 30%：勉强能解出 H，但结果大概率有肉眼可见的问题
- 内点率< 10%：基本上 H 是错的，别往下走了，回头查特征匹配
这个指标比"看图判断"可靠得多。有次学生交上来的结果图看着还行，我一问内点率只有 8%，仔细放大一看接缝处确实有 3 个像素的错位，只是缩略图看不出来。让他把 ratio 从 0.85 降到 0.7，内点率直接涨到 45%，拼出来的接缝就干净了。
还有一点值得提醒：点对的方向不能反。findHomography(src_pts, dst_pts, ...)解出的 H 是把 src 坐标系映射到 dst 坐标系。如果你后面warpPerspective的时候传图传反了，或者把 H 用在了错误的图上，结果必然是黑图或者完全错乱的图。我习惯在函数命名上就写清楚H_1_to_2，避免自己回头看不懂。
3.4 一个很少人注意的细节：点对顺序与类型
findHomography要求的输入形状是(N, 1, 2)的float32或float64数组。很多人用np.array([...])拼出来之后忘了reshape(-1, 1, 2)，OpenCV 会默默接受某些形状但在特定情况下给出错误结果，甚至直接 assert 失败。另外kp1[m.queryIdx].pt拿到的是(x, y)元组，kp里的pt字段顺序就是 x 在前 y 在后，这一点和img[y, x]的索引顺序相反，写可视化代码的时候特别容易搞反，画出来的连线满天飞。
4. 画布尺寸与透视变换：拼出来被裁掉半张的根因
4.1 透视变换会把坐标推到负值区
这是实验三最经典的翻车点。假设你把左图变换到右图坐标系，由于左图在物理上位于右图的左侧，变换后左图的大部分区域坐标会变成负数（x < 0）。而图像数组的合法索引是[0, width)，负坐标部分直接被丢弃。结果就是你只看到左图中靠右的一小条，其余全部消失。
解决办法分两步：先算出变换后图像的实际边界范围，得到最小负值xmin、ymin；再构造一个平移矩阵 T，把所有坐标整体往右下方推，让最小值变成 0；最后新画布的尺寸按变换后的总跨度来定，而不是用原图尺寸。
h1, w1 = img1.shape[:2] h2, w2 = img2.shape[:2] # 左图四个角点变换到右图坐标系 corners1 = np.float32([[0,0],[0,h1],[w1,h1],[w1,0]]).reshape(-1,1,2) corners1_t = cv2.perspectiveTransform(corners1, H) # 右图本身不动 corners2 = np.float32([[0,0],[0,h2],[w2,h2],[w2,0]]).reshape(-1,1,2) all_corners = np.concatenate((corners1_t, corners2), axis=0) xmin, ymin = np.floor(all_corners.min(axis=0).ravel()).astype(int) xmax, ymax = np.ceil(all_corners.max(axis=0).ravel()).astype(int) # 平移矩阵，把负坐标整体挪到非负区间 T = np.array([[1, 0, -xmin], [0, 1, -ymin], [0, 0, 1]], dtype=np.float64) out_w = xmax - xmin out_h = ymax - ymin canvas = cv2.warpPerspective(img1, T @ H, (out_w, out_h))T @ H这个顺序不能反。矩阵乘法不满足交换律，T @ H表示"先做 H 变换，再做 T 平移"，正是我们要的。写成H @ T就是先平移后变换，结果完全是另一回事。
4.2 把第二张图贴上去时的偏移量
变换完左图之后，右图需要贴到画布上正确的位置。右图本身没有经过变换，它的原点现在应该在画布的(-xmin, -ymin)处。
x_off = -xmin y_off = -ymin canvas[y_off:y_off+h2, x_off:x_off+w2] = img2这里有个细节必须处理：如果y_off是负数（说明变换后的左图在上方超出右图边界），上面这种直接切片会报负索引错误。稳妥的写法是先算好交集区域，或者用np.clip把偏移量限制在合法范围内再做切片。我自己习惯先判断：
y0, y1 = max(0, y_off), min(out_h, y_off + h2) x0, x1 = max(0, x_off), min(out_w, x_off + w2) canvas[y0:y1, x0:x1] = img2[y0 - y_off : y1 - y_off, x0 - x_off : x1 - x_off]两行改起来不麻烦，但能避免深更半夜跑出个莫名其妙的报错。
4.3 为什么会有黑边，以及该不该裁
即使坐标算对了，拼接结果也一定会有黑边——透视变换后的画布是个矩形，而被变换的图像是个不规则四边形，四边形的外面自然没有像素，OpenCV 默认填 0，也就是黑色。
黑边要不要裁剪，取决于你的实验目标。如果实验要求展示拼接结果，保留黑边反而更直观地说明了两张图的空间关系；如果要做出"成品全景图"，那就需要基于非零区域的边界做一次裁剪：
gray = cv2.cvtColor(canvas, cv2.COLOR_BGR2GRAY) ys, xs = np.where(gray > 0) crop = canvas[ys.min():ys.max()+1, xs.min():xs.max()+1]注意这个方法对真实图像里本身就很暗的区域不友好，会把正常内容误判成黑边。更稳的方式是同时维护一张 mask，warpPerspective 的时候把 mask 也变换一遍，用 mask 来判断有效区域。
| 问题现象 | 根因 | 修复方向 |
|---|---|---|
| 只剩一小条，大片缺失 | 直接用原图尺寸当画布，负坐标被丢 | 计算边界 + 平移矩阵 |
| 拼出来全黑 | H 方向反了或图传反了 | 检查 findHomography 的 src/dst |
| 结果上下颠倒或镜像 | H 解错，通常因匹配点全错 | 查内点率，回退匹配参数 |
| 右图位置偏移 | 贴图时偏移量算错 | 用-xmin, -ymin而非xmin, ymin |
| 边缘锯齿明显 | 插值方式不当 | warpPerspective 加INTER_LINEAR |
5. 融合这一步：为什么直接覆盖会露馅
5.1 简单覆盖的三个天然缺陷
最省事的做法就是第 4 节那段：左边变换完，右边直接切片赋值覆盖上去。这在功能上确实叫"拼接成功"了，但视觉上会暴露三个问题。
第一是硬接缝。两张图的交界处是一条锐利的线，人的眼睛对接缝极其敏感，哪怕只有 1 个像素的错位都能看出来。第二是曝光差异。哪怕是同一台相机同一场景，稍微改变拍摄角度，自动曝光就会给出不同的亮度值，左图偏亮右图偏暗，接缝线会变成一条明显的明暗分界。第三是轻微错位。由于 H 不是完美的，接缝两侧可能有 1 到 3 个像素的偏移，重叠区域出现"重影"。
这三点加在一起，就是很多人拼接结果"看着别扭"的真实原因。它不是算法错了，只是最后一步太粗糙。
5.2 加权平均融合：最简单也最够用
思路很简单：在重叠区域，不选其中一张，而是让两张按距离加权混合。靠近左图的边缘，左图权重大；靠近右图的边缘，右图权重大；中间五五开。这样接缝被"抹开"成一个渐变带，肉眼完全看不出来。
实现上，我一般会先用变换后的 mask 确定重叠区，再按 x 方向做线性插值权重。
# 分别得到两张图在画布上的有效区域 mask1 = cv2.warpPerspective(np.ones((h1, w1), np.uint8) * 255, T @ H, (out_w, out_h)) mask2 = np.zeros((out_h, out_w), np.uint8) mask2[y_off:y_off+h2, x_off:x_off+w2] = 255 overlap = cv2.bitwise_and(mask1, mask2) # 只在重叠区做线性渐变 blend = canvas.copy() left_w = np.linspace(1, 0, out_w).reshape(1, -1) right_w = 1.0 - left_w实际写的时候，做一个横向的渐变权重图再按 mask 加权求和就行。对于实验级别的需求，这种线性羽化已经能把接缝处理得相当干净，代码量也很小。
| 融合方式 | 实现复杂度 | 消接缝效果 | 适合场景 |
|---|---|---|---|
| 直接覆盖 | 最低 | 无 | 只看功能是否跑通 |
| 线性加权羽化 | 低 | 好 | 实验首选，多数场景够用 |
| 多频段（拉普拉斯金字塔）融合 | 中高 | 很好，兼顾细节和亮度 | 曝光差异明显、需要高质量 |
| 曝光补偿 + 羽化 | 中 | 很好 | 存在明显亮度差时 |
5.3 曝光差异的预处理：先补偿再融合
如果两张图的整体亮度差很明显，单纯羽化只能把硬接缝变成软过渡，明暗交界依然存在，只是不那么刺眼了。真正能解决的是先做增益补偿。
最简单的做法是算两张图在重叠区域的平均灰度比，把其中一张整体乘上这个系数拉到同一亮度水平，再做融合。稍微复杂一点可以用基于块的增益补偿，但实验场景下整体增益已经足够。
m1 = cv2.cvtColor(img1, cv2.COLOR_BGR2GRAY) m2 = cv2.cvtColor(img2, cv2.COLOR_BGR2GRAY) ratio = m1.mean() / m2.mean() img2_corrected = np.clip(img2 * ratio, 0, 255).astype(np.uint8)这种全局补偿当然没那么精确，但它能把明显的亮度落差压下去一大截，配合羽化效果相当可以。我在一个偏暗的室内场景上试过，不做补偿时接缝像一条刀痕，做完之后基本要盯着看才能找到接缝在哪。
5.4 顺序问题：三张图怎么办
如果实验要求拼三张以上的图，会立刻遇到一个顺序问题：到底以哪张图为基准坐标系？
我的做法是选中间那张做主图，然后把左边那张变换到中间图坐标系、右边那张也变换到中间图坐标系，这样左右两侧的透视畸变比较对称。如果以最左图为基准，往右递推下去，越远的图变形越大，最后一张可能会拉得不成样子。
实现上，多图拼接就是迭代调用单次拼接，每次把"已经拼好的结果"当成左图，去和新图配准。这里有个陷阱：随着画布越来越大，特征检测越来越慢，而且结果图内部的接缝累积误差会越来越明显。实话说，超过 4 张图还要求无缝，就需要上更完整的曝光补偿和光束法平差了，那已经超出课程实验的范畴。
6. 把整套东西跑通：代码骨架与排查清单
6.1 完整可运行的主流程
把前面各节的片段组装起来，整条链路是这样的：
import cv2 import numpy as np def stitch(img_left, img_right, ratio=0.75, ransac_thresh=4.0): kp1, kp2, good = detect_and_match(img_left, img_right, ratio) if len(good) < 10: raise RuntimeError(f"匹配点太少（{len(good)}），检查重叠区域和图像质量") src = np.float32([kp1[m.queryIdx].pt for m in good]).reshape(-1,1,2) dst = np.float32([kp2[m.trainIdx].pt for m in good]).reshape(-1,1,2) H, mask = cv2.findHomography(src, dst, cv2.RANSAC, ransac_thresh) inlier_rate = mask.sum() / len(good) print(f"匹配 {len(good)}，内点率 {inlier_rate:.1%}") if inlier_rate < 0.25: print("警告：内点率偏低，结果可能错位，建议收紧 ratio 阈值") h1, w1 = img_left.shape[:2] h2, w2 = img_right.shape[:2] c1 = np.float32([[0,0],[0,h1],[w1,h1],[w1,0]]).reshape(-1,1,2) c1t = cv2.perspectiveTransform(c1, H) c2 = np.float32([[0,0],[0,h2],[w2,h2],[w2,0]]).reshape(-1,1,2) allc = np.concatenate((c1t, c2), axis=0) xmin, ymin = np.floor(allc.min(axis=0).ravel()).astype(int) xmax, ymax = np.ceil(allc.max(axis=0).ravel()).astype(int) T = np.array([[1,0,-xmin],[0,1,-ymin],[0,0,1]], dtype=np.float64) out_w, out_h = xmax - xmin, ymax - ymin canvas = cv2.warpPerspective(img_left, T @ H, (out_w, out_h)) x_off, y_off = -xmin, -ymin y0, y1 = max(0, y_off), min(out_h, y_off + h2) x0, x1 = max(0, x_off), min(out_w, x_off + w2) canvas[y0:y1, x0:x1] = img_right[y0-y_off:y1-y_off, x0-x_off:x1-x_off] return canvas, H, inlier_rate跑通之后，建议拿同一组图分别用 ratio=0.7、0.75、0.8 各跑一次，把内点率和拼接结果对比着记录下来。这个对比表在实验报告里非常有说服力，也让你对参数的影响有直观认识。
6.2 一张按症状索引的排查表
代码调不通的时候，最忌从头到尾盲目改。按症状查更快：
| 症状 | 第一怀疑对象 | 验证方式 |
|---|---|---|
| 拼接结果全黑 | warpPerspective 的 H 参数 | 打印 H，看是否接近单位阵或含 NaN |
| 只有一张图的局部 | 画布尺寸计算 | 打印 xmin/ymin/out_w/out_h |
| 两图错位明显 | 内点率过低 | 打印内点率，回看匹配连线图 |
| 拼接方向颠倒 | src/dst 顺序 | 用 H 变换一个原点验证 |
| 接缝有明显明暗线 | 曝光差异 | 对比重叠区平均灰度 |
| 接缝重影 | 场景有近景物体，非平面 | 换远景素材重试 |
| 运行时崩溃在某行切片 | 偏移量为负 | 加 clip 保护 |
匹配连线图是个特别好用的调试手段，cv2.drawMatches一行就能画出来，横七竖八的乱线就是误匹配多的信号，笔画一致的平行线才说明匹配质量好。
6.3 我踩过的几个具体坑
第一个是图像尺寸过大导致的假失败。手机拍的照片动辄 4000×3000，SIFT 能跑但慢到怀疑人生，而且特征点数量爆炸，knnMatch耗时直接上到十几秒。我现在的习惯是统一先cv2.resize到长边 1200 左右再做所有处理，速度提升十倍不止，拼接质量几乎没差别，因为特征点的空间分布又不会因为缩放而改变。
第二个是彩色通道的 BGR/RGB 混乱。OpenCV 读图是 BGR，如果你用 matplotlib 显示就会反色，人脸变蓝色。这不影响拼接逻辑，但会把你看结果图的判断搞乱。显示时统一用cv2.cvtColor(img, cv2.COLOR_BGR2RGB)转一道。
第三个是测试图的选取。我一开始用了一张带大面积天空的照片，天空几乎无纹理，SIFT 在上面只能检出零星几个点，全部集中在建筑边缘，导致内点分布极不均衡，解出的 H 在天空区域严重失真，拼接结果上方的天空扭曲成一团。换成整面有砖纹的墙之后立刻正常。特征点的空间分布比数量更重要，全都挤在一个角落的点对解出来的 H 是不可信的。
第四个是忘了检查 H 是否可逆。如果两张图的拍摄角度差异极大（比如一张正视、一张侧视 60 度），单应关系本身就接近退化，解出来的矩阵数值极大，warpPerspective之后整张图被拉到无穷远。这种情况没有代码层面的解法，只能换素材，或者老老实实承认这两张图不适合做拼接。
6.4 实验报告里值得写的分析点
如果这个实验要交报告，光有结果图不够看。我建议至少补上这几项分析，每一项都不费太多事但能体现你真的理解了：
把不同 ratio 阈值下的匹配数和内点率列成表，画一条曲线，说明阈值和匹配质量之间的权衡关系。这个权衡在所有特征匹配任务里都是通用的，做一次就记住了。
把 SIFT 和 ORB 在同一组图上的耗时、匹配数、内点率、最终拼接效果放在一起对比。ORB 快但内点率往往低一截，这个现象正好能引出描述子鲁棒性的讨论。
用一张有近景物体的照片做一次失败案例，分析为什么单一 H 无法同时对齐近景和远景，然后从视差角度解释。这个分析做出来，说明你对平面假设的理解到位了。我见过的报告里，凡是能把失败案例讲清楚的，通常分数都不低，因为它证明了自己知道算法的边界在哪。
7. 收个尾
图像拼接这个实验，我前后帮人排查过不少次问题，发现真正卡住人的从来不是 SIFT 那几行调用，而是边界计算和坐标方向这类"数学上简单、写起来容易绕晕"的地方。我的建议是，别一上来就追求漂亮的结果图，先用一张干净的远景图，把内点率打印出来，确认 H 是对的，再去看画布算得对不对，最后才是融合。顺序反了，出了问题你会不知道是哪一层的错。
再分享一个小技巧：调试的时候把cv2.drawMatches的结果和warpPerspective的中间结果都存成文件，别只在屏幕上imshow。屏幕上的图缩放之后会掩盖一两个像素的错位，而文件里是原始分辨率，放大能看到真实情况。我见过不止一次，屏幕上看着没问题的结果，存成文件一看接缝歪了三四个像素。
