图像透视变换这个主题，我在实际项目里踩过的坑比想象中多得多。很多人第一次接触它，以为就是调一个cv2.warpPerspective函数、传一个3x3矩阵就完事了，结果跑出来要么图像被拉伸得面目全非，要么四个角点算错导致整个画面偏移，要么变换后边缘出现大片黑边不知道怎么处理。这篇内容就是把我这些年做文档扫描矫正、车牌识别预处理、AR贴图对齐、工业检测定位等场景里积累的透视变换经验，从头到尾拆一遍。不管你是刚学完OpenCV基础操作想往高阶走，还是已经在做视觉项目但透视变换这块总是调不好，下面这些内容应该都能直接拿去用。核心关键词就一个——透视变换，但我会把它背后的数学原理、角点选取逻辑、矩阵计算细节、插值方式选择、边界处理策略全部展开讲透，让你不只是会调函数，而是真正理解每一步在干什么、为什么这么干。

1. 透视变换到底在解决什么问题

1.1 从生活场景理解透视变换的本质

你拿手机拍一张桌面上平铺的A4纸，拍出来的照片里纸张是什么形状？大概率是一个梯形或者不规则的四边形——近大远小，这是透视投影的必然结果。但如果你要把这张纸的内容做OCR识别或者存档，你需要的是一张正正经经的矩形图像。把梯形“掰正”成矩形的这个过程，就是透视变换要干的事。

用更技术化的话说：透视变换（Perspective Transformation）是把一个平面上的四边形区域，通过一个3x3的变换矩阵，映射到另一个平面上的四边形区域。它和仿射变换（Affine Transformation）最大的区别在于——仿射变换保持平行线仍然平行，而透视变换不保持。正因为不保持平行性，它才能处理“近大远小”这种真实的透视畸变。你可以把仿射变换理解成透视变换的一个特例：当变换矩阵最后一行是[0, 0, 1]时，透视变换退化成仿射变换。

这个区别在实际选型时非常关键。我见过不少项目，明明需要做文档矫正，结果用了cv2.warpAffine，怎么调都矫正不彻底，原因就是仿射变换只有6个自由度，搞不定透视畸变需要的8个自由度。透视变换的3x3矩阵有9个元素，但整体缩放不影响映射结果，所以实际自由度是8，刚好对应四个点对（每个点对提供两个方程，四对点八个方程解八个未知数）。

1.2 透视变换在真实项目中的典型应用场景

我在不同项目里用到透视变换的场景大致可以归成几类，每一类对角点精度和变换质量的要求都不太一样：

文档扫描与矫正是最常见的场景。拍书页、拍发票、拍合同，拍出来总是歪的、斜的、带透视的。用透视变换把文档的四个角点映射到标准矩形的四个角，就能得到一张“扫描件”效果。这个场景对边缘处理要求高，因为文档外面通常还有桌面背景，变换后要裁掉多余部分。

车牌识别预处理里也用得很多。摄像头装在路上，拍到的车牌往往有倾斜和透视变形，先做透视矫正再送进识别模型，准确率能明显提升。这个场景的特点是角点定位精度要求极高，差几个像素识别率就掉。

工业视觉定位中，相机固定在产线上方，但工件摆放角度有偏差，需要把工件区域变换到标准视角再做模板匹配或缺陷检测。这类场景对实时性要求高，矩阵计算和插值方式的选择要权衡速度与精度。

AR贴图与图像合成里，要把一个平面图案“贴”到真实场景的某个平面上（比如把海报贴到墙面上），需要根据墙面的四个角点计算透视矩阵，把图案变换过去。这个场景对视觉自然度要求高，插值质量直接影响观感。

还有一类是鸟瞰图生成，车载环视系统里把前视摄像头拍到的地面图像变换成俯视图，用的也是透视变换。这个场景对矩阵的物理意义要求明确，通常需要根据相机内外参来推导，而不是单纯靠四个点对来解。

1.3 为什么四个点对就能确定一个透视变换

这个问题我当初也困惑过。一个3x3矩阵有9个未知数，为什么给四对点（8个坐标值）就能解出来？原因在于齐次坐标的缩放不变性——矩阵乘以任意非零常数，映射结果不变。所以我们可以固定矩阵的某一个元素（通常是h33 = 1），把未知数降到8个。四对点对，每对提供两个方程（x方向和y方向各一个），刚好八个方程解八个未知数。

具体来说，设变换矩阵为：

H = [[h11, h12, h13], [h21, h22, h23], [h31, h32, h33]]

对于源点(x, y)和目标点(x', y')，映射关系是：

x' = (h11*x + h12*y + h13) / (h31*x + h32*y + h33) y' = (h21*x + h22*y + h23) / (h31*x + h32*y + h33)

令h33 = 1，每个点对展开成两个线性方程，四个点对组成一个8x8的线性方程组。OpenCV的cv2.getPerspectiveTransform内部就是用高斯消元或者类似方法解这个方程组。理解这一点很重要，因为它解释了为什么四个点不能有任意三点共线——共线会导致方程组退化，解出来的矩阵不稳定甚至无解。

注意：cv2.getPerspectiveTransform要求输入四个点，顺序必须对应——源点的第一个点映射到目标点的第一个点，以此类推。顺序搞错是新手最常见的错误之一，变换结果会完全错乱。

2. 核心细节解析与实操要点

2.1 角点顺序的约定与常见踩坑

OpenCV对透视变换的四个角点顺序没有强制规定，但你必须保证源点和目标点的顺序一一对应。实践中我习惯统一用“左上、右上、右下、左下”的顺时针顺序，这个约定在绝大多数场景下都适用，也方便记忆和调试。

问题在于，你从图像里检测出来的四个角点，顺序往往是乱的。比如用轮廓检测拿到四个顶点，它们的排列顺序取决于轮廓的起始点和遍历方向，可能是“右上、左下、左上、右下”这种完全没法用的顺序。这时候就需要做角点排序。

我常用的排序逻辑是这样的：先按x坐标排序分成左右两组，每组再按y坐标排序分出上下，这样就能得到左上、左下、右上、右下，再调整成顺时针顺序。但这个方法有个前提——四边形不能旋转得太厉害（比如超过45度），否则“左”和“右”的判断会出错。更稳健的做法是计算四个点的质心，然后按每个点相对于质心的极角排序，这样不管怎么旋转都能得到一致的顺时针或逆时针顺序。

import numpy as np import cv2 def order_points(pts): # pts: 4x2 的numpy数组 rect = np.zeros((4, 2), dtype="float32") s = pts.sum(axis=1) rect[0] = pts[np.argmin(s)] # 左上：x+y最小 rect[2] = pts[np.argmax(s)] # 右下：x+y最大 diff = np.diff(pts, axis=1) rect[1] = pts[np.argmin(diff)] # 右上：y-x最小（即x-y最大） rect[3] = pts[np.argmax(diff)] # 左下：y-x最大 return rect

这段代码用的是x+y和y-x的极值来判断四个角，对于大多数“大致正向”的四边形都很稳。但如果四边形旋转超过45度，x+y最小对应的可能不是左上而是别的角，这时候就得换成基于质心的极角排序。我在一个旋转工件检测的项目里就遇到过这个问题，工件可以任意角度摆放，最后是用np.arctan2算极角排序解决的。

2.2 目标尺寸的计算：不能拍脑袋定

确定了源点之后，目标点怎么定？很多人直接写死一个固定尺寸，比如(300, 400)，结果要么图像被压扁，要么被拉伸，比例完全不对。正确的做法是根据源四边形的实际边长来估算目标矩形的宽高。

常用的估算方式是：宽度取上边和下边长度的最大值，高度取左边和右边长度的最大值。这样能保证变换后的图像不会丢失源图像的信息（不会因为目标太小而压缩掉细节）。

# 假设 rect 是排好序的四个点：左上、右上、右下、左下 (tl, tr, br, bl) = rect width_top = np.linalg.norm(tr - tl) width_bottom = np.linalg.norm(br - bl) max_width = max(int(width_top), int(width_bottom)) height_left = np.linalg.norm(bl - tl) height_right = np.linalg.norm(br - tr) max_height = max(int(height_left), int(height_right)) dst = np.array([ [0, 0], [max_width - 1, 0], [max_width - 1, max_height - 1], [0, max_height - 1] ], dtype="float32")

这里有个细节：目标点坐标用max_width - 1而不是max_width，是因为像素坐标是从0开始的，宽度为max_width的图像，最右边的像素索引是max_width - 1。这个差1的问题在精度要求高的场景（比如工业测量）里会造成系统性偏差，虽然视觉上几乎看不出来，但如果你的项目涉及尺寸测量，这个细节必须注意。

还有一种情况是目标尺寸有明确规格要求，比如文档矫正后要输出标准A4比例（√2:1），那就不能单纯按边长估算了，得按比例来定。我一般会先算出估算宽高，然后按目标宽高比调整其中一个维度，保证比例正确。

2.3 变换矩阵的求解与验证

拿到源点和目标点之后，一行代码就能求出矩阵：

M = cv2.getPerspectiveTransform(src, dst)

但求出来之后一定要验证。验证方法很简单：把源点用这个矩阵变换一遍，看结果是否和目标点吻合。OpenCV提供了cv2.perspectiveTransform来做点集的透视变换：

# src_pts 形状为 (1, 4, 2) src_pts = src.reshape(-1, 1, 2) transformed = cv2.perspectiveTransform(src_pts, M) print(transformed.reshape(-1, 2)) # 应该和 dst 非常接近

如果误差很大（超过1个像素），说明矩阵求解有问题，常见原因包括：点顺序不对应、存在三点共线、坐标数据类型不对（必须是float32或float64）。我遇到过一种情况是传入的坐标是整数类型，OpenCV内部转换时精度丢失导致矩阵轻微偏差，改成float32就解决了。

另外，cv2.getPerspectiveTransform在点数正好是4的时候用，如果你有超过4个对应点（比如用多个点做最小二乘拟合），应该用cv2.findHomography，它支持RANSAC等鲁棒估计方法，能自动剔除误匹配点。这个在特征点匹配做图像配准的场景里特别有用。

2.4 插值方式的选择：不是越高级越好

cv2.warpPerspective的flags参数控制插值方式，常用的有：

选插值方式的核心逻辑是看像素值的语义。如果图像是普通的RGB照片，双线性基本够用，速度快质量也不差。如果是分割掩码或者类别标签图，绝对不能用双线性或双三次，因为插值会产生“中间值”——本来只有0和1的掩码，插值后出现0.5，语义就乱了，这时候必须用最近邻。如果是做图像放大展示，双三次或兰索斯能保留更多高频细节，但计算量也上去了。

我在一个实时视频处理的项目里，最初用了双三次插值，帧率掉到15fps，换成双线性后回到30fps，画质肉眼看不出明显差别。所以实时场景优先双线性，离线高质量处理再考虑双三次以上。

3. 完整实操流程与关键环节实现

3.1 从一张倾斜拍摄的文档照片到标准扫描件

下面这个流程是我在文档矫正项目里反复打磨过的，直接可以拿去改改用。整体分五步：灰度化与预处理、边缘检测、轮廓提取与四边形筛选、角点排序、透视变换与裁剪。

第一步，预处理。直接对彩色图做边缘检测噪声会很多，先转灰度，然后做高斯模糊抑制噪声。高斯核大小我一般用(5, 5)，标准差设0让OpenCV自动算。如果图像对比度低，可以加一步直方图均衡化，但要注意均衡化可能放大背景噪声，视情况而定。

gray = cv2.cvtColor(image, cv2.COLOR_BGR2GRAY) blurred = cv2.GaussianBlur(gray, (5, 5), 0)

第二步，边缘检测。Canny的阈值选择是个经验活。我通常用双阈值，低阈值设50、高阈值设150作为起点，然后根据实际图像调整。一个更自动化的做法是用图像中位数来定阈值：低阈值取中位数的0.66倍，高阈值取中位数的1.33倍。这个方法在光照不均的场景下比固定阈值稳。

v = np.median(blurred) lower = int(max(0, 0.66 * v)) upper = int(min(255, 1.33 * v)) edged = cv2.Canny(blurred, lower, upper)

边缘检测后通常要做一次膨胀或闭运算，把断开的边缘连起来，方便后续找轮廓。

第三步，轮廓提取与四边形筛选。用cv2.findContours拿所有轮廓，然后按面积从大到小排序，遍历找第一个“近似四边形”的轮廓。近似的方法是用cv2.approxPolyDP做多边形逼近，epsilon参数取轮廓周长的2%左右。如果逼近结果正好4个顶点，就认为找到了文档区域。

cnts, _ = cv2.findContours(edged.copy(), cv2.RETR_EXTERNAL, cv2.CHAIN_APPROX_SIMPLE) cnts = sorted(cnts, key=cv2.contourArea, reverse=True) screen_cnt = None for c in cnts: peri = cv2.arcLength(c, True) approx = cv2.approxPolyDP(c, 0.02 * peri, True) if len(approx) == 4: screen_cnt = approx break

这里有个坑：如果图像里有多个四边形（比如桌面上还有别的纸），按面积排序取最大的不一定是你想要的那个。更稳的做法是加约束条件，比如面积占全图比例在合理范围内、长宽比接近文档比例等。

第四步，角点排序。用前面讲的order_points函数把四个点排成左上、右上、右下、左下。

第五步，透视变换与裁剪。算目标尺寸、求矩阵、做变换。变换后图像边缘可能有黑边（因为源四边形外面的区域被映射进来了），需要按目标尺寸裁剪掉。

warped = cv2.warpPerspective(image, M, (max_width, max_height))

如果源四边形检测得准，变换后基本就是干净的文档图像。检测不准的话，边缘会有残留背景，这时候可以加一步自适应阈值二值化，把背景压掉。

3.2 手动指定角点的交互式方案

自动检测不是万能的，复杂背景下轮廓提取经常失败。这时候退而求其次，做一个交互式选点工具，让用户手动点四个角。用cv2.setMouseCallback监听鼠标事件，记录点击坐标，点满四个就触发变换。这个方案在内部工具里非常实用，虽然不自动化，但胜在稳定可靠。

points = [] def mouse_callback(event, x, y, flags, param): if event == cv2.EVENT_LBUTTONDOWN and len(points) < 4: points.append((x, y)) cv2.circle(img_display, (x, y), 5, (0, 255, 0), -1) cv2.imshow("select", img_display) cv2.namedWindow("select") cv2.setMouseCallback("select", mouse_callback) cv2.imshow("select", img_display) cv2.waitKey(0)

手动选点的关键是点击顺序要和目标点顺序一致，所以界面上最好有提示文字告诉用户“请按左上、右上、右下、左下顺序点击”。我做过一个版本是在每个点旁边标注序号，用户体验好很多。

3.3 批量处理时的性能优化

单个图像做透视变换很快，毫秒级。但如果是批量处理几千张图，或者视频流逐帧处理，就得考虑优化了。几个实测有效的点：

矩阵复用。如果所有图像的变换关系相同（比如相机固定、工件位置固定），矩阵只需要算一次，后续所有帧直接复用。这个优化在视频处理里能省掉每帧的矩阵求解开销。

降低分辨率。如果只是做检测定位，不需要全分辨率变换，可以先把图像缩小再处理，矩阵按比例缩放后应用。比如原图1920x1080，缩到960x540处理，矩阵的平移分量要相应缩放。

避免不必要的拷贝。warpPerspective的输出尺寸如果和输入相同，可以传入dst参数复用内存，减少分配开销。不过这个优化收益有限，主要瓶颈还是在插值计算上。

用cv2.INTER_NEAREST做预览。交互式调参时用最近邻插值快速预览，确认参数后再用高质量插值出最终结果。这个技巧在调角点位置时特别有用，响应速度快很多。

3.4 变换后黑边与越界问题的处理

透视变换后出现黑边是常态，因为目标图像里有些像素对应的源坐标超出了原图范围，OpenCV默认填0（黑色）。处理方式取决于你的需求：

如果黑边在图像外围，直接按有效区域裁剪即可。计算有效区域的方法是：把原图的四个角点用逆矩阵变换到目标空间，取包围盒。或者更简单——把目标图像的四个角点用逆矩阵变换回源空间，看哪些落在原图范围内。

如果黑边混在图像内部（比如源四边形不是凸的，或者变换矩阵有问题），那就不是裁剪能解决的了，得回头检查角点顺序和矩阵正确性。

还有一种情况是变换后图像内容超出了目标尺寸被截断。这时候要么增大目标尺寸，要么接受截断。我一般会在估算目标尺寸时留一点余量（比如加10个像素），避免边缘内容被切掉。

提示：cv2.warpPerspective的borderMode参数可以控制边界填充方式，默认是cv2.BORDER_CONSTANT（填常数，默认0）。如果希望边缘像素向外延展而不是填黑，可以用cv2.BORDER_REPLICATE。这个在图像拼接场景里有用，能减少拼接缝的突兀感。

4. 常见问题与排查技巧实录

4.1 变换结果完全错乱——先查点顺序

这是最高频的问题。表现是变换后的图像旋转了、镜像了、或者内容跑到画面外面去了。九成以上的原因是源点和目标点的顺序没有一一对应。排查方法很简单：把源点和目标点分别画出来，标上序号，肉眼核对。我习惯在调试时把四个点用不同颜色画在图上，源图一种颜色方案，目标图同色对应，一眼就能看出顺序对不对。

另一个容易忽略的点是坐标系的y轴方向。图像坐标系的y轴是向下的，如果你从别的系统（比如某些CAD软件）拿来的坐标是y轴向上的，直接传进去就会上下颠倒。这个坑我在一个跨系统对接的项目里踩过，调了半天才发现是坐标系约定不同。

4.2 矩阵求解报错或结果不稳定

cv2.getPerspectiveTransform本身不报错，但如果输入有问题，解出来的矩阵可能是病态的（元素值极大或极小），变换结果完全不可用。常见原因：

• 三点共线：四个点里有三个在同一直线上，方程组退化。检查方法是用cv2.convexHull或者叉积判断四个点是否构成凸四边形。
• 点重复：两个点坐标相同，相当于只有三个有效点，解不出唯一矩阵。
• 坐标精度不足：整数坐标在计算过程中精度丢失，改用float32。

我一般会在求矩阵前加一个简单的合法性检查：四个点两两距离都大于某个阈值（比如10像素），且构成的四边形面积大于某个阈值。不满足就报错或走降级方案。

4.3 变换后图像模糊或出现锯齿

模糊通常是插值方式选择不当或者目标尺寸远大于源区域导致的。如果源四边形在图像里只占很小一块（比如100x100像素），你把它变换到1000x1000的目标尺寸，相当于放大了10倍，任何插值方式都会模糊，因为源信息量就那么多。这时候要么接受模糊，要么用超分辨率方法先放大再变换。

锯齿则通常出现在用最近邻插值做放大时，边缘呈阶梯状。换成双线性或双三次能明显改善。但如果图像本身是二值掩码，锯齿是不可避免的（最近邻的固有特性），只能通过后续形态学操作平滑边缘。

4.4 常见问题速查表

4.5 几个容易被忽略的实操心得

角点精度比矩阵精度更重要。我做过对比实验：矩阵计算用float32和float64，变换结果差异在0.01像素级别，肉眼不可见。但角点位置偏2个像素，变换后边缘偏差可能到5个像素以上。所以精力应该花在提高角点定位精度上，而不是纠结矩阵计算的数值精度。

先做透视变换再做其他处理。有些流程是先做滤波、增强再变换，这其实不合理。透视变换会改变像素的空间关系，先做的滤波在变换后可能效果打折。正确顺序是：原图→透视变换→后续处理。当然如果变换本身需要边缘信息来定位角点，那定位阶段可以用处理后的图，但最终变换要用原图。

保存中间结果用于调试。透视变换的调试链条比较长（预处理→边缘→轮廓→角点→矩阵→变换），任何一步出问题都会导致最终结果不对。我习惯在每一步cv2.imwrite存一张中间图，出问题时逐张看，很快能定位到哪一步坏了。这个习惯帮我省了大量时间。

目标尺寸的宽高比要心里有数。如果你知道源物体是标准A4纸，那变换后的宽高比应该是1:1.414。如果算出来的目标尺寸宽高比偏离这个值太多，说明角点检测有问题（比如把纸张边缘和桌面边缘混在一起了）。用先验知识做交叉验证，能提前发现很多错误。

测试用例要覆盖极端情况。我维护了一套测试图集，包括：正对拍摄（几乎无透视）、大角度倾斜、部分遮挡、低对比度、强光照不均、旋转超过45度。每次改代码都跑一遍，确保没有回归。这套图集里最容易被忽略的是“几乎无透视”的情况——变换矩阵接近单位矩阵，如果代码里有除以接近零的量，这时候会出问题。

5. 从透视变换延伸出去的几个实用方向

5.1 逆向变换：从矫正图回到原图

透视变换是可逆的，cv2.invert或者直接对矩阵求逆就能得到逆变换矩阵。这个能力在实际项目里很有用。比如你在矫正后的文档图上做了标注（框出了某个字段），需要把标注框映射回原图显示，这时候就用逆矩阵把标注框的四个角点变换回去。

M_inv = np.linalg.inv(M) # 或者用 cv2.invert(M, M_inv)

需要注意的是，逆变换的数值稳定性取决于原矩阵的条件数。如果原变换的透视畸变非常大（矩阵接近奇异），逆变换的误差会被放大。这种情况下建议用np.linalg.solve而不是直接求逆，数值上更稳。

5.2 与特征点匹配结合做图像配准

前面讲的都是基于手动或规则检测的四个角点。如果两张图之间没有明显的四边形对应关系，但有大量纹理特征，可以用特征点匹配（SIFT、ORB等）找到多对匹配点，然后用cv2.findHomography求单应矩阵。这个方法在图像拼接、多视角融合里是标准做法。

findHomography和getPerspectiveTransform的区别在于：前者接受任意数量的点对（至少4对），用最小二乘法或RANSAC求解，能处理误匹配；后者严格要求4对点，且假设点对完全准确。实际项目里如果匹配点超过4对且有噪声，一定用findHomography。

H, mask = cv2.findHomography(src_pts, dst_pts, cv2.RANSAC, 5.0)

RANSAC的重投影阈值设5.0是个常用起点，表示内点允许的最大重投影误差是5像素。阈值太小会导致内点太少解不稳定，太大则误匹配混进来。根据实际匹配质量调整。

5.3 透视变换在文档去畸变中的进阶用法

简单的四点透视变换只能矫正“平面到平面”的畸变。如果文档是弯曲的（比如翻开的书），四点变换就不够了，需要更复杂的方法，比如基于网格的薄板样条变换或者基于深度学习的文档去畸变模型。但四点变换仍然可以作为预处理步骤——先把文档的大致区域矫正到正向，再用更精细的方法处理局部弯曲。

我在一个古籍扫描的项目里就是这么做的：先用四点透视变换把书页区域矫正到大致正向，然后用基于文本行检测的方法估计局部弯曲，做二次矫正。两步走的效果比单用任何一种都好。

5.4 实时视频流中的透视变换稳定性处理

视频流逐帧做透视变换，最大的问题是帧间抖动——角点检测在相邻帧之间可能有几个像素的跳动，导致变换结果闪烁。解决方法是对矩阵或者角点做时间域平滑。简单做法是对连续几帧的角点坐标做移动平均，或者对矩阵元素做指数加权平均。更讲究的做法是用卡尔曼滤波跟踪角点位置。

我用过最简单的方案是：维护一个长度为5的角点队列，每帧新检测到的角点和队列里的做加权平均（新帧权重高），用平滑后的角点算矩阵。这个方案实现简单，效果立竿见影，代价是引入了轻微延迟（大约2-3帧），在对实时性要求极高的场景要权衡。

注意：平滑只应该用在角点检测有噪声的情况下。如果角点检测本身很稳定（比如相机和物体都固定），加平滑反而引入不必要的延迟和漂移。

6. 我个人在实际操作中的几点体会

透视变换这个工具，函数调用本身五分钟就能学会，但真正用好需要理解它背后的几何意义和数值特性。我见过太多项目在角点检测上偷懒，随便找个轮廓近似就拿来用，结果变换质量惨不忍睹，然后花大量时间在矩阵和插值上找原因，方向完全错了。

角点定位才是整个流程的瓶颈。自动检测方案在受控环境（背景干净、光照均匀、物体标准）下能到亚像素精度，但在复杂环境下经常失败。我的经验是：能加约束就加约束。比如知道文档是白色的，就在检测前做颜色过滤；知道工件有特定形状，就用模板匹配辅助定位；知道相机固定，就用背景差分找前景。这些先验知识能把角点检测的鲁棒性提升一个档次。

另一个体会是关于精度和速度的权衡。很多教程一上来就推荐双三次插值、float64计算，好像精度越高越好。实际项目里，双线性加float32在绝大多数场景下完全够用，速度快一倍以上。真正影响结果质量的是角点精度和目标尺寸合理性，而不是插值的阶数。先把这两点做扎实，再考虑要不要上更高精度的方案。

最后说一个调试习惯：每次变换后，把源四边形和目标四边形都画出来叠在原图上对比。这个可视化能让你一眼看出角点选得对不对、目标尺寸合不合理、变换方向有没有反。比盯着变换后的图猜原因高效得多。我现在的代码模板里，调试开关一打开就自动生成这张对比图，已经成为肌肉记忆了。