1. 内容整体设计与思路拆解
1.1 这一篇要解决什么问题
图像旋转在图形算法里属于最基础、最常见的几何变换之一，但我敢说，十个用OpenCV做过旋转的人，至少有五六个在第一版代码里遇到过“旋转之后图片被裁掉一块”或者“旋转中心完全不对”这种问题。原因倒不难理解：旋转本身的数学公式只有一行，但落到二维图像上，牵扯到坐标系定义、变换矩阵、边界处理、插值策略，任何一环没想透彻，出来的结果就是歪的。
这个系列前面已经讲过了图像平移和缩放，平移是加法、缩放是乘法，都比较符合直觉。旋转跟它们最大的不同在于：旋转后的图像尺寸会变，而且像素坐标的映射关系不再是整数对应整数，等于把一个规规矩矩的矩形网格搅成一堆浮点坐标，然后再重新采样回来。这个“先散射、后重采样”的过程，决定了旋转代码的复杂度远远高于平移。
本篇讲的“常规旋转”，是指这样一类操作：给定一张输入图像，指定旋转角度（以及可选的旋转中心和缩放系数），输出一张旋转后的图像。这是OpenCV里getRotationMatrix2D加warpAffine的标准组合，也是图像运动专题里后续各种高级效果的基石。理解了这条线，再去看自动矫正、任意角度的透视变换、动态帧稳定这些复杂话题，都会轻松很多。
1.2 为什么先讲“常规旋转”而不是“无损旋转”
实际项目里经常听到“无损旋转”这个词，严格说图像的旋转没有真正的无损，因为插值必然带来精度损失。大家说的“无损”一般是指“不损失图像内容”，也就是旋转后画布足够大，把整张图片都包进去。那为什么不直接讲这种呢？
因为“常规旋转”是对旋转本质的直白表述：输入一个图像、一个角度，输出一个结果，这个结果可能是完整内容，也可能是一部分被裁掉的——取决于你给的输出尺寸参数。这个看似“不完美”的行为，恰恰是理解旋转矩阵输出尺寸为什么必须是手动指定的关键。OpenCV不会自动帮你算新画布的大小，这就是新手最容易栽跟头的坑。把常规旋转讲透了，后面再讲自动扩大画布、自动裁剪边缘，就只是在同一个框架上做微调而已。
1.3 常规旋转的三个核心决策点
动手写代码之前，先在大脑里过一遍整条链路。常规旋转的代码不超过十行，但这十行背后有三个决策点：
第一，旋转中心选在哪里。是图片左上角？几何中心？还是某个自定义锚点？这直接决定了旋转后的视觉结果。很多人默认用图片中心，但实际业务里（比如模板匹配、图标摆正、人脸对齐）往往需要指定关键点作为旋转中心。
第二，输出画布的尺寸。是保持原图尺寸（w, h）不变，还是按旋转后的外接矩形大小重新计算？前者简单但会裁掉边缘内容，后者需要额外两步坐标计算。
第三，插值方式与边界填充模式。旋转过程中像素点落在非整数坐标上，必须通过插值估算像素值；与此同时，旋转后图像的四个角必然有一部分落在原图像范围之外，这部分区域怎么填、填什么值，也需要明确。
这三个决策点全部都是由参数体现的，下面逐个展开。
2. 核心细节解析与实操要点
2.1 旋转矩阵的数学原理：为什么OpenCV用的是2x3矩阵
二维平面里绕原点逆时针旋转θ角的矩阵，数学标准形式是：
[ cosθ -sinθ ] [ sinθ cosθ ]但图像处理里有个容易忽略的前提：图像坐标系的y轴是向下的（原点在左上角）。同样一个θ角，在数学坐标系里是逆时针，搬到图像坐标系里就成了顺时针。这也是为什么OpenCV里getRotationMatrix2D指定正角度时旋转方向是逆时针还是顺时针，跟你的坐标理解直接相关。
OpenCV实际使用的变换矩阵是2x3的仿射矩阵，比纯理科的2x2旋转矩阵多了一列平移项。这是因为绕图像中心的旋转，等价于先把坐标平移到中心、旋转、再平移回去，这三次变换压缩成一个矩阵就是2x3形式。也就是说：
[ α β (1-α)*cx - β*cy ] [-β α β*cx + (1-α)*cy ]其中α = scale * cosθ，β = scale * sinθ。getRotationMatrix2D内部做的就是这一件事，给定旋转中心、角度和缩放系数，生成2x3矩阵。理解这个公式的价值在于：当你需要在旋转之外再叠加平移（比如把旋转后的图平移到一个特定位置），你知道怎么手动拼矩阵，而不是再调用一个黑盒。
2.2 角度、方向与坐标系：最容易绕晕的部分
我在带新人时发现，旋转方向的理解分歧几乎是必然出现的问题。原因就是上面说的：图像坐标系y轴向下，导致你在纸上画画时习惯的逆时针方向，在图像里未必是逆时针。
getRotationMatrix2D(center, angle, scale)中的angle，单位是度，正值表示逆时针旋转。注意，这个“逆时针”是数学坐标系里的说法。放到图像坐标系里，由于y轴反转，视觉上正角度实际看到的是顺时针。我举个例子：
- 一张长条横幅图片，图像内容是左侧一个圆、右侧一个方块，如果你希望圆跑到右上角，传入正45度，实测会发现圆是往右下角跑的——因为视觉上表现为顺时针。
- 反过来说，想看到数学意义下的逆时针旋转，angle要传负值。
这个坑在写程序时不会报错，但结果永远跟你心里想的不一样。我的习惯是，拿到一张图先做一个45度的极简测试，确认方向再跑正式流程。别嫌麻烦，这一步十秒钟，能省掉后面一个小时的调参。
2.3 插值方式的选择逻辑
warpAffine的插值参数是很多人直接填INTER_LINEAR就不管了，但实际不同场景差别很大：
- 放大场景（比如把一张小图标旋转并放大）：用
INTER_CUBIC或INTER_LANCZOS4，边缘更平滑，但计算量会上升。如果只是单张图像处理，无所谓；如果是在视频流里逐帧做，性能差距就能感知到了。 - 缩小场景：用
INTER_AREA，抗锯齿效果好。 - 一般场景：
INTER_LINEAR是实测最均衡的默认值，速度和质量都说得过去。 INTER_NEAREST只有像素风、精灵图这类特殊需求才用，放大后视觉效果会比较糙，但优点是速度快、无模糊。
我在实际项目中，静态图像处理默认INTER_CUBIC，视频流处理默认INTER_LINEAR。原因很简单：视频帧数多，INTER_CUBIC的耗时大约是INTER_LINEAR的2到3倍，而在旋转角度不变的情况下，肉眼很难分辨两者的差异。
2.4 边界填充模式：黑边的背后逻辑
旋转后四个角一定有区域落在原图像之外，warpAffine的borderMode决定这些位置填什么。默认是BORDER_CONSTANT，填黑色（0,0,0）。所以你会看到黑边。
这里有一个容易被忽略的参数：borderValue配合BORDER_CONSTANT使用。比如你处理白底文档扫描图，默认黑边会非常扎眼，把它改成(255,255,255)就好很多。cv2.copyMakeBorder里定义的BORDER_REPLICATE、BORDER_WRAP等模式在warpAffine里也都适用，但日常场景中最多用的还是BORDER_CONSTANT和BORDER_REPLICATE。后者用边缘像素延伸填充，在图像拼接、纹理处理时比单纯填常数要自然。
3. 实操过程与核心环节实现
3.1 基础版本：固定画布旋转
先上最直接、绕不开的基础代码。这个版本不做画布扩展，直接保留原始尺寸，适合演示核心变换链路，也是排查问题的基本单元：
import cv2 import numpy as np img = cv2.imread("sample.jpg") h, w = img.shape[:2] center = (w // 2, h // 2) angle = 45 scale = 1.0 M = cv2.getRotationMatrix2D(center, angle, scale) rotated = cv2.warpAffine(img, M, (w, h)) cv2.imwrite("rotated_fixed.jpg", rotated)这段代码跑完，输出图片的长宽和原图一样，但旋转后原本图像的四角会被切掉，同时出现四个黑色三角区域。尺寸参数(w, h)是输出画布尺寸，不是原图自动变换的结果。这一点一定记住：warpAffine只负责按矩阵变换像素坐标，画布多大完全看第三个参数。
如果用这段代码输出45度旋转的图，你会发现黑边占据了相当大的面积，直接发给项目组基本会被打回。所以实际使用中，下一步几乎必然要做画布扩展。
3.2 画布扩展：让旋转后的内容完整显示
要让旋转后的完整图像都落在画布内，关键一步是计算旋转后的外接矩形。先说结论：外接矩形的宽高公式为
new_w = int(w * abs(cosθ) + h * abs(sinθ)) new_h = int(w * abs(sinθ) + h * abs(cosθ))这个公式不需要死记，理解过程即可：旋转后图像的四个角的位置由cosθ和sinθ决定，要保证四个角都在画布内，就需要取每个角在水平和垂直方向投影的最大范围。用绝对值是因为角落在不同象限时的投影方向不同，长度恒为正值。
但还有一个细节：旋转中心在计算外接矩形后可能不再位于新画布的中心。原因是按原图中心旋转，当画布尺寸从(w,h)变成(new_w,new_h)时，中心点被平移了。所以除了用getRotationMatrix2D生成变换矩阵，还需要调整矩阵最后的平移项，让原图中心映射到新画布中心。
标准做法是把矩阵第三列的偏移量手动加上新画布中心与旧画布中心的差：
h, w = img.shape[:2] angle = 45.0 radians = math.radians(angle) cos_a = abs(math.cos(radians)) sin_a = abs(math.sin(radians)) new_w = int(w * cos_a + h * sin_a) new_h = int(w * sin_a + h * cos_a) M = cv2.getRotationMatrix2D((w / 2, h / 2), angle, 1.0) M[0, 2] += (new_w - w) / 2.0 M[1, 2] += (new_h - h) / 2.0 rotated = cv2.warpAffine(img, M, (new_w, new_h))这里M[0, 2]对应x方向平移，M[1, 2]对应y方向平移。旋转变换本身没有改变，只是把平移量修正了。
实测：一张1920x1080的图旋转30度，new_w约等于1920 * 0.866 + 1080 * 0.5 = 2202，new_h约等于1920 * 0.5 + 1080 * 0.866 = 1895。新画布比原图大了一圈，内容完整保留，底色是纯黑。如果你是处理透明背景的PNG，记得把borderValue改成(0,0,0,0)（RGBA透明），不然后续合成会有黑色底。
3.3 旋转中心不为图像中心的情况
有些场景需要围绕图像内的某一个点旋转。比如把一张照片里的“人脸中心”作为旋转中心，或者围绕一个物体锚点旋转。做法是一样的，只是center参数换成那个点：
anchor = (x, y) # 自定义旋转中心 M = cv2.getRotationMatrix2D(anchor, angle, scale)但这时候要注意：旋转后，这个锚点会留在原位，而图像内容会绕着它转。如果你想在旋转后依然把锚点放在画布某个固定位置（比如始终让锚点位于画布中心），你需要额外做一次平移。做法是：先把锚点平移回目标位置，再做旋转，再补偿偏移。矩阵层面就是在M[0,2]和M[1,2]上手动增加目标坐标与锚点坐标的差值。
我做图标自动摆正时经常用这种思路：先检测图标中心或某个特征点，以该点为中心旋转，让图标的主轴朝向水平或垂直方向，然后平移让特征点落在画布中央。三步操作完全可以合并到一个矩阵里，避免图像多次拷贝带来的质量损耗。
3.4 旋转+缩放组合操作
getRotationMatrix2D的第三个参数是scale。设成0.5就是旋转的同时缩小一半，设成2.0就是放大一倍。这个参数在实现“缩放到适合大小再摆正”的场景很实用，比如OCR预处理时对倾斜的票据图像先做轮廓检测，算出角度和缩放比例，一次性完成摆正与缩放。
组合操作后的外接矩形计算稍微复杂一点，需要先把缩放系数乘进cos和sin：
scale = 0.8 cos_a = abs(scale * math.cos(radians)) sin_a = abs(scale * math.sin(radians)) new_w = int(h * sin_a + w * cos_a) new_h = int(h * cos_a + w * sin_a)实测效果：原图较大，旋转45度同时缩放0.8，输出画布比旋转后未缩放的版本小，但比直接缩小不旋转的版本大。因为旋转本身需要容纳对角线方向的内容，尺寸响应是旋转与缩放的叠加结果，不能只看任何一个单独的因素。
4. 常见问题与排查技巧实录
4.1 旋转后图片裁掉了：画布尺寸不够
最经典的症状是：旋转后图像的角被切掉，露出的黑色区域恰好是三角形。排查方法很简单，先确认warpAffine的输出size，再看旋转矩阵的平移项。
处理建议：按3.2节的方式计算外接矩形并补偿平移。如果是因为旋转角度是90度的倍数，公式依然成立（cos或者sin为0），不需要特殊处理分支。
如果是视频流里逐帧旋转，不建议每帧都计算外接矩形。提前算好最大可能尺寸（取所有旋转角度中外接矩形的最大值），一次性分配缓冲区即可。
4.2 旋转方向反了：检查你的坐标系预期
如果你旋转正45度，结果看起来像负45度，不用怀疑代码逻辑，而是坐标系直觉问题。图像y轴向下，数学正角度在图像里视觉上表现为顺时针。想获得视觉逆时针，angle传入负值即可。
开发排错时建议打印原始图像几个关键点坐标，配合旋转矩阵手动带入公式验证。比如原图右上角(w,0)，旋转45度后理论坐标应该是
x' = cos45 * w - sin45 * 0 = 0.707 * w y' = sin45 * w + cos45 * 0 = 0.707 * w如果实际结果不是这个方向，就是坐标理解的问题。
4.3 旋转后图像内容偏移到一侧：中心偏移补偿缺失
这个问题的本质是画布变了但平移项没补偿。典型场景：原图尺寸1920x1080，旋转90度，用外接矩形计算new_w=1080，new_h=1920。但如果不补偿平移项，原图中心在旋转后映射到了新画布的左上方，内容整体偏移。实际效果看起来就是图没居中，而是贴住了一条边。
我的排查顺序：先检查M[0,2]和M[1,2]是否包含了(new_w - w)/2的修正量。没有就补上，问题立即消失。
4.4 旋转后图像变模糊：插值方式不合适
INTER_LINEAR在常规情况下质量足够，但如果你对图像细节要求高（比如文字识别前的矫正），可以换成INTER_CUBIC。实测同一种图片，用INTER_CUBIC处理后的文字边缘明显锐利一些，但对噪声比较多的图像，结果反而可能更不好看。另外，如果旋转角度很小（比如小于5度），很多人的经验是直接用仿射变换而不是旋转矩阵，因为小角度下旋转矩阵的某些项接近恒等，用优化过的仿射变换效率更高——但这个提升在实际工程中一般感知不到，除非处理超大批量图片。
4.5 常见问题速查表
| 现象 | 可能原因 | 解决方案 |
|---|---|---|
| 四角被裁 | 画布尺寸小于外接矩形 | 用外接矩形公式计算new_w/new_h |
| 黑边突兀 | 默认borderMode填充黑色 | 更换borderValue或borderMode |
| 内容不居中 | 缺小平移补偿 | M[0,2]、M[1,2]增加(dw/2、dh/2) |
| 旋转方向反 | 坐标系预期与公式不符 | 角度取反测试 |
| 边缘锯齿 | 插值方式偏弱 | 改用INTER_CUBIC，或者先放大再旋转 |
| 透明图黑底 | 未指定RGBA的borderValue | 设置borderValue=(0,0,0,0) |
4.6 一个容易忽略的工程问题：旋转中心在浮点边界
当图像宽高是偶数时，几何中心(w/2, h/2)可能是浮点数。OpenCV的getRotationMatrix2D接受浮点坐标，但输出像素填充时存在0.5像素的偏移。这种偏移在单次旋转时几乎不可见，但如果你做多次旋转叠加（比如图像稳定算法里每帧修正角度），累积误差会让你头疼。
工程上应对方案是：统一用(w / 2.0, h / 2.0)作为中心，并在所有变换中保持同一坐标约定，避免一次用整除一次用浮点。这也是为什么我在上面的代码里特意写w / 2.0而不是w // 2，虽然局部看差不多，但累积效果差别很大。
5. 常规旋转的边界拓展：当角度与尺寸变化交织
5.1 任意角度旋转后的边缘损失估算
很多场景不需要完整保留图像内容，比如图像配准、模板匹配的后处理，只需要输出一个固定大小的变换结果。这时你就不必计算外接矩形，直接用原图尺寸或者某个固定尺寸即可。但心里要有个预期：角度越大，边缘损失越严重。
以一张512x512的正方形图片为例，旋转45度，原始尺寸画布下边缘损失的像素面积大约占比近一半。四角的内容全部被裁掉。这在某些场景是致命的（比如安全监控画面的旋转），但在另一些场景（比如目标检测里对检测框的微调）是可以接受的，因为目标通常在画面中心附近。
在选方案前先问自己：我需要的是“内容完整”还是“尺寸固定”？这两个需求对应完全不同的代码路径，不要写到一半再改。
5.2 旋转与透视、仿射变换的关系
常规旋转是仿射变换的一个特例，仿射变换又是投影变换的特例。OpenCV里warpAffine处理仿射变换，warpPerspective处理透视变换。之所以要把这个关系理清，是因为在实际项目中常常会遇到“不只是要旋转，还要做一个倾斜矫正”的情况。
比如你做翻拍文档的矫正，文档在照片里既歪斜（旋转）又有透视变形（近大远小），单靠旋转矩阵是修不好的。这时候应该用getPerspectiveTransform找四个角点做透视变换。我在这类项目里的经验是：先用旋转做初对齐，再用透视做精矫正，两步分开调试比一步到位更容易排查问题。别嫌两步麻烦，每一步的误差源头都清晰可查，出问题时不至于一脸懵。
5.3 性能优化：大批量旋转的加速思路
如果面对的是一万张图需要做旋转预处理，逐张调用warpAffine是可以的，但有几个显而易见的加速点：
- 预先计算所有相同的旋转矩阵，不要每张图重复调用
getRotationMatrix2D。 - 如果多张图尺寸相同，可以把多张图堆叠成一个batch，用GPU版本或矢量化的方式一次性处理。
- 对视频流逐帧旋转：
INTER_LINEAR比INTER_CUBIC更合适，画布尺寸提前固定。
实测下来，批量处理一万张1080p图片，预计算矩阵约能省去2%~3%的耗时，插值方式选择带来的差异大约是15%左右，最大的瓶颈还是在单张图像的内存拷贝上。所以如果你的硬件内存紧张，优先考虑减小图像尺寸而不是优化插件参数。
6. 这些坑我都踩过，写出来帮你避雷
回到开头说的：旋转代码本身五句话讲完，但它包含的坐标理念是这个图像运动专题里承上启下的一环。平移是直线思维，缩放是尺度思维，旋转是角度思维——从这一篇开始，你处理的不再是“像素在哪里”的问题，而是“像素应该从哪里来”。学习建议：把3.2节的代码自己动手跑一遍，改成任意角度试试，然后把center、angle、scale、borderMode四个参数都调一遍，观察结果变化。试完这一轮，你对warpAffine的理解基本就到位了。
在实际工程项目中，我踩过最大的一个坑是关于中心偏移的，当时在做一个自动摆正的路牌识别系统。画像旋转15度，直接输出原尺寸，结果边界处恰好是路牌边缘，识别率掉了三成。后来排查到是输出画布没有扩展，平移项没有补偿，改了之后识别率立刻恢复。这个教训让我养成了一个习惯：任何用到warpAffine的地方，写代码之前先回答三个问题——旋转中心在哪？输出画布多大？补偿平移了吗？三个问题都答清楚，代码往往一遍就能跑对。
常规旋转下一步的演进方向是自动计算旋转角度（比如通过图像主方向分析、文本行的倾斜检测、特征点匹配估算），这些后续内容都会在本系列的图像运动专题里展开。但在那之前，把基础旋转的每个参数吃透，跨过去之后的路会顺很多。
