带旋转角度的模板匹配C#与EmguCV的碰撞——这几个词放在一起做过机器视觉定位的朋友应该秒懂。我是做自动化设备视觉的这几年在产线上给机械手做过不少“抓取定位”的视觉引导项目最常碰到的情况就是工件在来料盘里角度乱飘有的歪5度有的歪30度机械手不能直接把工件抓走必须先算出它到底在哪个位置、转了多少度。传统模板匹配只会算平移相似度目标一转角度分数直接掉到没法用。今天这篇就把我怎么用C#搭EmguCV实现带旋转角度的模板匹配这件事从原理到代码再到调试排坑完整讲一遍。这个方案适合谁如果你手里正好是C#项目想在Windows上位机里直接调OpenCV系列算法又不希望引入太重的外部框架那这篇文章就是给你准备的。哪怕你是刚接触EmguCV的新人把下面的代码思路吃透也能在自己的Demo里跑通。1. 为什么需要给模板匹配加上旋转能力1.1 传统模板匹配的局限先回到最基础的那行代码。在EmguCV里常规模板匹配其实就是这么一句Mat result new Mat(); CvInvoke.MatchTemplate(grayImage, grayTemplate, result, TemplateMatchingType.CcoeffNormed);所谓的模板匹配就是拿模板窗口在搜索图上从左到右、从上到下逐像素滑动每到一个位置就算一次相似度最终生成一张和搜索图尺寸相关的结果图。结果是float矩阵每个像素值代表那个位置的匹配程度值越高越像。再用一次CvInvoke.MinMaxLoc找到最大值的位置就是模板最可能出现的地方。这套机制本身只解决了两个自由度x方向和y方向。它完全不关心目标在图像里转了多少度。因为模板窗口是静止的正矩形一旦目标发生了旋转模板窗口里的特征排列就变了。比如模板里那个方形工件的右上角原本在右上角目标旋转30度后这个角跑到了别的位置模板窗口滑过去计算得分时自然是“驴唇不对马嘴”。我印象很深的一个案例是给某条产线做接料盒定位。料盒里面放着几排小型零件来料方向随机机械手要根据视觉返回的角度去旋转吸嘴。最初直接用模板匹配零件正着摆分数能到0.92歪了10度就只有0.4左右完全没法用。所以那会儿我被迫到处搜“旋转模板匹配”的方案最后绕了一大圈还是自己动手扩展自由度比较实际。1.2 本质是把二维平移搜索变成三维搜索如果用一句话概括“带旋转角度的模板匹配”那就是把原本只搜x、y两个自由度的过程扩展成搜x、y再加上一个角度θ的三维搜索。打个比方。你手里有一张照片想在一堆杂乱照片里找出同一栋建筑。如果只允许水平移动照片上去比那建筑稍微歪一点就对不上但如果允许你把照片旋转到任意角度再贴上去比就能找到它。多角度模板匹配在原理上就是这么干的准备一堆旋转过不同角度的模板每个角度都做一次普通模板匹配然后从所有角度里挑分数最高的那组作为最终结果。这个思路听起来特别暴力但放在工业场景里反而是最稳的。因为它直接复用了像素级模板匹配的成熟算法不受纹理好坏影响边缘模糊、表面反光也能有一定的抗干扰能力。代价就是计算量上升原本一次匹配变成每个角度一次匹配。不过这问题也不是无解后面会讲到用“粗检精检”和金字塔把计算量压回去。所以你不需要一开始就去找什么“旋转不变模板匹配”的算法库本质上只要把角度这个自由度用穷举或分层搜索的方式加进去就能解决问题。C#里怎么落地接下来详细说。2. 技术选型为什么C#搭配EmguCV合适2.1 先看看有哪些备选方案在C#项目里做图像处理摆在我面前的路线其实有好几条我把自己实际比较过的情况列出来。第一条路是完全自己写像素匹配。比如用Bitmap拿到每个像素的灰度值然后写个双层循环遍历图像再写个相似度计算函数。这个方案的优点是没有任何第三方依赖但缺点非常致命速度慢、难优化而且你还要自己去实现图像的旋转插值、灰度归一化这些底层操作。为了一个模板匹配搭这么大一个轮子不划算。第二条路是用C封装OpenCV通过P/Invoke或者C/CLI提供给C#调用。这条路性能最好但开发效率低。你需要在OpenCV的C层面写一堆导出函数处理Mat内存生命周期、类型转换、异常传递调试起来非常折磨。对于产线设备这种需要快速验证、频繁调参的场景太耽误事。第三条路就是用EmguCV。它是OpenCV的.NET封装API风格和OpenCV基本一致底层还是原生库但你在C#里调用就跟调普通类库一样舒服。尤其是CvInvoke这个静态类把OpenCV的核心C接口几乎都给你包了一层。模板匹配、几何变换、图像读写几行代码就能调起来。第四条路是某些商业视觉软件自带的算法库比如一些配套视觉软件里的形状匹配模块。这类库在旋转匹配、亚像素精度、运行速度上做得确实很专业但普遍的问题是授权费用不低而且整套框架往往绑定特定相机品牌或界面环境。对于我们这种想在一个普通C#程序里插一段视觉算法的场景略显笨重。所以从“开发效率、底子可靠、可控性强”几个维度来看EmguCV在C#生态里是最平衡的选择。另外提一句EmguCV的授权协议有GPL和商业授权两套模式如果是做内部工具或开源项目一般不用太担心如果做商业闭源软件销售记得提前评估授权方式。2.2 先熟悉这几个核心API要写出带旋转角度的模板匹配你只需要先搞清楚EmguCV里这四组函数就够了。第一个是CvInvoke.MatchTemplate负责做一次标准模板匹配。传入搜索图、模板图指定匹配模式就会输出结果矩阵也就是每个位置的响应值热力图。匹配模式有几个选项我平时用得最多的是TemplateMatchingType.CcoeffNormed归一化相关系数对整体亮度和对比度变化相对不敏感。第二个是CvInvoke.MinMaxLoc从结果矩阵里找到最大值和最小值及它们的位置。找最高响应点时它就是我们要的目标位置。第三个是CvInvoke.GetRotationMatrix2D根据旋转中心、角度和缩放比例生成一个2×3的仿射变换矩阵。注意这个矩阵输出来就是OpenCV的Mat类型非常方便。第四个是CvInvoke.WarpAffine用生成的仿射变换矩阵对图像做实际旋转。它会输出一张旋转后的新图像旋转后超出边界的部分一般用指定颜色填充。把这四个函数串起来一个最原始的多角度模板匹配就成型了循环角度 → 旋转模板 → 模板匹配 → 找峰值 → 记录该角度下的最高分和坐标。接下来再根据工程需要做优化。3. 算法策略设计与优化思路3.1 方案A直接把模板旋转成一个集合最直观的实现方式就是从0度扫到360度每隔固定步长旋转一次模板把每个角度旋转后的模板都拿出来对搜索图做一次标准匹配。for (double angle 0; angle 360; angle step) { Mat rotatedTpl RotateImage(template, angle, fillValue); CvInvoke.MatchTemplate(src, rotatedTpl, result, TemplateMatchingType.CcoeffNormed); // 取最大分数和位置不断更新全局最优 }这套做法的优点是模板可以提前一次性预生成写成一个模板数组运行时只需要反复加载就行了。缺点是每个角度的模板尺寸会变。比如一个200×200的模板旋转45度后外接画布大约变成了283×283模板匹配速度会变慢而且旋转产生的黑色边角会干扰相关系数的计算。针对黑边问题经验做法是把填充颜色从黑色改成模板的平均灰度。图像旋转后用背景色填充空隙在视觉上和人眼看到的效果一致CcoeffNormed计算相关性时就不至于被大片黑色区域拉低分数。3.2 方案B反过来旋转搜索图方案A简单但在某些场合不如“旋转搜索图”这个思路稳定。因为模板不旋转就没有黑边问题模板的特征区域始终完整、干净。比如工件只在一个固定位置周围做小范围角度摆动时我就经常旋转搜索图然后让标准模板去匹配旋转后的搜索图。搜索图旋转之后模板匹配找到的位置是“旋转后坐标系”下的位置。要还原回原始搜索图的坐标需要把匹配点绕搜索图中心反向旋转一次也就是做坐标逆变换。这个操作在数学上是矩阵运算不复杂但写起来容易搞错我建议先用一组已知点去验证方向再放心用。方案B的典型缺点是如果搜索图很大每转一个角度就要对整个大图做一次仿射变换计算开销比旋转模板还要高。所以它更适合目标位置集中在图像中央区域、角度偏差较小的场景。3.3 方案C用“粗检精检”把计算量压下来直接每0.5度扫一圈360度需要720次匹配我这个急性子根本接受不了。实际项目里我基本都采用分层策略。第一轮叫粗检。用比较大的步长比如10度对0到360度全部扫一遍找到分数最高的那个角度。10度步长意味着要匹配36次。这一步不用追求精度只需要把真实角度定位到一个大致范围。第二轮叫精检。在粗检找到的最优角度前后各一个粗步长范围内比如最优角度-10度到最优角度10度再用0.5度或0.1度的小步长做精细扫描。这样一个范围里大概扫41次。最后总的匹配次数约36加41等于77次。相比于0.5度全扫的720次计算量差不多降成了原来的十分之一。而且因为真实角度和粗检角度的偏差不会超过一个粗步长精检范围完全覆盖得住精度一点不受影响。3.4 金字塔、并行计算和亚像素角度拟合除了粗精分层还有三个优化手段非常实用。第一是图像金字塔。把搜索图和模板同时缩小一半小图上粗检一次锁定大概的区域和角度再回到原图去精检。缩图后像素变少匹配速度成倍提升尤其是搜索图特别大的场面效果很明显。但有个窗口前提如果模板本身已经很小比如只有三四十像素再缩一倍细节就丢光了这种情况宁可不降分辨率。第二是并行计算。模板匹配的几个角度之间互不依赖天然适合并行。C#里直接用Parallel.For把角度数组分给多线程跑每个线程独立做匹配最后合并全局最优解。多核处理器越强速度优势越明显。需要注意并行访问共享变量时的线程安全更新最优解时加个锁就好。第三是亚像素角度拟合。精检步长再小也有离散误差我们可以用抛物线拟合来逼近更精确的角度。原理是取最优角度和它相邻两个角度的匹配分数拟合一条抛物线抛物线顶点的横坐标就是亚像素级的最优角度。公式很简单delta 0.5 * (scorePrev - scoreNext) / (scorePrev - 2 * scoreBest scoreNext) refinedAngle bestAngle delta * step实际测试下来这种拟合可以再提高0.1到0.3度的精度在一些对角度要求较高的场景很管用。4. C#实操落地一个可运行的核心示例4.1 准备项目和模板先在Visual Studio里建一个普通控制台项目或者类库通过NuGet安装EmguCV两个包即可Install-Package Emgu.CV Install-Package Emgu.CV.runtime.windows安装完之后引入常用命名空间。我用的是Emgu.CV 4.x版本配合.NET Framework 4.7.2以及.NET 6环境都试过API差别不大。using Emgu.CV; using Emgu.CV.CvEnum; using Emgu.CV.Structure; using System; using System.Drawing; using System.Linq; using System.Threading.Tasks;模板从哪里来工业上通常从一张标准的、目标姿态端正的图像里直接裁出目标区域保存成灰度图。如果现场条件允许可以在软件里让用户框选一次目标区域作为模板存到本地以后每次启动再加载。模板包含的特征越明确越好最好有明显的角点、边缘轮廓或局部纹理。模板背景尽量干净别把和工件无关的杂乱背景切进去否则匹配时目标周围的复杂背景也会因为相似而被误选。加载图像和模板统一转成灰度Mat src CvInvoke.Imread(search.png, ImreadModes.Grayscale); Mat template CvInvoke.Imread(template.png, ImreadModes.Grayscale);4.2 核心匹配函数实现这里给出完整度比较高的核心实现。先写一个旋转图像的工具方法负责把模板旋转到指定角度并自动计算旋转后外接画布的大小。private Mat RotateImage(Mat image, double angle, double fillValue) { PointF center new PointF(image.Width / 2f, image.Height / 2f); Mat rotMat CvInvoke.GetRotationMatrix2D(center, angle, 1.0); double rad angle * Math.PI / 180.0; double cosA Math.Abs(Math.Cos(rad)); double sinA Math.Abs(Math.Sin(rad)); int newWidth (int)Math.Ceiling(image.Width * cosA image.Height * sinA); int newHeight (int)Math.Ceiling(image.Height * cosA image.Width * sinA); Mat rotated new Mat(); CvInvoke.WarpAffine( image, rotated, rotMat, new Size(newWidth, newHeight), Inter.Linear, BorderType.Constant, new MCvScalar(fillValue)); rotMat.Dispose(); return rotated; }这个函数是旋转模板方案的地基。用默认的黑色填充会直接影响匹配分数所以我建议把fillValue设置为模板灰度的平均值。计算平均值可以提前做好比如在加载模板后调用CvInvoke.Mean(template)取第一个通道的值。接下来是带粗检和精检的搜索主逻辑。为了代码简洁我先把阈值处理写得简化一些实际项目里可以加一个最低分过滤防止低质量的匹配结果进入后续逻辑。public (PointF center, double angle, double score) Search(Mat src, Mat template) { double coarseStep 10.0; double fineStep 0.5; double bestScore 0; double bestAngle 0; PointF bestCenter PointF.Empty; // 第一轮粗扫全角度 for (double angle 0; angle 360; angle coarseStep) { using (Mat rotatedTpl RotateImage(template, angle, fillValue)) { if (rotatedTpl.Width src.Width || rotatedTpl.Height src.Height) continue; using (Mat result new Mat()) { CvInvoke.MatchTemplate(src, rotatedTpl, result, TemplateMatchingType.CcoeffNormed); double minVal 0, maxVal 0; Point minLoc Point.Empty, maxLoc Point.Empty; CvInvoke.MinMaxLoc(result, ref minVal, ref maxVal, ref minLoc, ref maxLoc); if (maxVal bestScore) { bestScore maxVal; bestAngle angle; bestCenter new PointF( maxLoc.X rotatedTpl.Width / 2f, maxLoc.Y rotatedTpl.Height / 2f); } } } } if (bestScore minAcceptScore) return (PointF.Empty, 0, bestScore); // 第二轮在粗检角度前后一个小邻域内精扫 double fineStart bestAngle - coarseStep; double fineEnd bestAngle coarseStep; Rectangle roi BuildRoiAround(src, bestCenter, template.Width, template.Height); using (Mat roiImage new Mat(src, roi)) { for (double angle fineStart; angle fineEnd; angle fineStep) { using (Mat rotatedTpl RotateImage(template, angle, fillValue)) { if (rotatedTpl.Width roiImage.Width || rotatedTpl.Height roiImage.Height) continue; using (Mat result new Mat()) { CvInvoke.MatchTemplate(roiImage, rotatedTpl, result, TemplateMatchingType.CcoeffNormed); double minVal 0, maxVal 0; Point minLoc Point.Empty, maxLoc Point.Empty; CvInvoke.MinMaxLoc(result, ref minVal, ref maxVal, ref minLoc, ref maxLoc); if (maxVal bestScore) { bestScore maxVal; bestAngle angle; bestCenter new PointF( roi.X maxLoc.X rotatedTpl.Width / 2f, roi.Y maxLoc.Y rotatedTpl.Height / 2f); } } } } } bestAngle (bestAngle 360) % 360; return (bestCenter, bestAngle, bestScore); }这个代码里有两个细节值得解释。第一为什么精扫时不在整张搜索图上匹配而是裁剪ROI因为既然粗检已经给出了目标的大致位置精扫只需要围绕这个位置进行完全没有必要把模板在整个搜索图上再滑一遍。ROI一般取模板宽高的2到3倍范围既保证目标不会因为粗检偏差而跑出窗口又大幅减少了精扫阶段的计算量。第二为什么旋转返回的坐标要加上rotatedTpl.Width / 2f和rotatedTpl.Height / 2f因为标准模板匹配返回的位置是“模板左上角在搜索图中的坐标”。但抓取定位通常需要目标中心点所以要把匹配位置加上旋转后模板宽高的一半。由于旋转是绕模板中心进行的外接画布的中心仍然对应原模板中心直接加一半宽高是成立的。4.3 精扫ROI的裁剪与坐标换算BuildRoiAround这个辅助函数也不难写。核心是计算一个以粗检中心为圆心、尺寸大约是模板两到三倍的矩形同时做边界裁剪防止矩形越出搜索图范围。private Rectangle BuildRoiAround(Mat src, PointF center, int tplWidth, int tplHeight) { int roiWidth tplWidth * 2; int roiHeight tplHeight * 2; int roiX (int)center.X - roiWidth / 2; int roiY (int)center.Y - roiHeight / 2; roiX Math.Max(0, Math.Min(roiX, src.Width - 1)); roiY Math.Max(0, Math.Min(roiY, src.Height - 1)); roiWidth Math.Min(roiWidth, src.Width - roiX); roiHeight Math.Min(roiHeight, src.Height - roiY); return new Rectangle(roiX, roiY, roiWidth, roiHeight); }这里有一点容易被忽略不要提前把ROI宽度算成比原图还大。如果粗检中心离图像边缘很近ROI越界后会被Math.Min和Math.Max裁剪掉一部分这时匹配区域变小是正常的只要模板还能完整放进ROI内部计算就没有问题。如果模板本身比裁剪后的ROI还大说明粗检中心位置本身不可信或者模板尺寸设计得过大需要回到模板准备环节去检查。4.4 结果输出和调试可视化算法跑到最后除了坐标和角度我强烈建议把调试图像保存下来。一次最简单的可视化就能避免很多“为什么分数这么低”“为什么位置偏了”的抽象困惑。Mat debug src.Clone(); CvInvoke.Rectangle(debug, new Rectangle((int)center.X - 20, (int)center.Y - 20, 40, 40), new MCvScalar(255, 0, 0), 2); CvInvoke.Line(debug, new Point((int)center.X, (int)center.Y), new Point((int)(center.X Math.Cos(angle * Math.PI / 180) * 60), (int)(center.Y Math.Sin(angle * Math.PI / 180) * 60)), new MCvScalar(0, 0, 255), 2); CvInvoke.PutText(debug, $angle{angle:F1} score{score:F3}, new Point((int)center.X - 40, (int)center.Y - 40), FontFace.HersheySimplex, 0.6, new MCvScalar(0, 255, 0), 1);图片保存到本地后再配合原图逐帧对比你可以很直观地判断匹配角度方向对不对、中心点是不是落在目标中心。别小看这个步骤我调试的时候至少有一半问题都是靠“看图”看出来的而不是靠日志和数字。5. 实战中的常见问题与排查经验5.1 黑边怎么处理才最稳前面提到旋转模板会产生黑边这是多角度模板匹配最典型的坑。如果你不加处理用默认的黑色填充旋转后的模板会发现分数整体偏低而且角度越偏分数越惨。我的经验是把填充值设置为模板区域的灰度均值。这样旋转后的空白角落在参与相关性计算时相当于中性背景不会产生突变性的干扰。实现上加载模板后先取一遍均值MCvScalar mean CvInvoke.Mean(template); double fillValue mean.V0;需要注意如果模板区域的灰度变化非常大比如一部分黑一部分白用全局均值填充也可能造成干扰。更彻底的做法是使用带掩码的模板匹配让旋转产生的填充区域不参与计算。EmguCV部分版本的MatchTemplate接口不一定暴露了mask参数遇到这种情况可以考虑换用其他库或者自己写一个带权重的相似度计算。对大多数场景均值填充已经够用。5.2 光照、反光和灰度差异模板匹配对光照变化比较敏感尤其是同一张图像里局部有过曝、反光或者阴影的时候。我遇到过一次比较折磨人的情况存档的模板是在正常光源下截的现场相机灯光老化后图像偏亮整个匹配分数从0.85掉到0.5左右怎么调阈值都没用。后来我总结了两条经验。第一模板匹配类型尽量使用CcoeffNormed它对线性的亮度变化有一定容忍力。第二预处理不要省略进入匹配前可以把搜索图和模板同时做一次高斯滤波把传感器噪声和细微光照纹路平滑掉分数会更稳定。如果现场光照变化太大还可以考虑直方图均衡化让两幅图的灰度分布更接近。反面教材也有。有一个项目里我在预处理阶段用了强烈的二值化把工件内部纹理全抹掉了结果模板匹配在各种无关区域疯狂误报。后面改回灰度匹配问题立刻消失。这提醒我们模板匹配的鲁棒性来自灰度细节别手贱做过强的预处理破坏纹理。5.3 模板特征不足和角度对称怎么办有一种情况会让人很抓狂匹配分数很高角度却是错的。最常见的原因是模板本身具有旋转对称性。比如一个圆形垫片上面没有任何定位孔或缺口你转90度、转180度它长得很像。这时候多角度模板匹配得分会出现好几个峰值甚至最高分对应的角度不是物理真实的摆放角度。处理思路有三个。第一在选模板的时候刻意选择一个具有非对称特征的局部区域比如带缺口、带引脚、带印刷字符的一角而不是整个工件的规则中心区域。第二如果目标整体对称性太高就不要依赖模板匹配给角度只让它给位置角度换用其他方法比如额外检测一个特征孔或角块的相对位置。第三对多个高分散布的角度使用聚类看哪一个角度附近的匹配位置最稳定综合判断。模板切得过大也是一个常见问题。模板越大包含的背景和其他干扰特征就越多匹配速度越慢误匹配概率反而上升。模板经验尺寸一般是目标占有搜索图面积的十分之一左右边界尽量紧贴目标轮廓。5.4 角度方向和坐标基准的坑OpenCV的旋转矩阵工作在图像坐标系下坐标原点在左上角x轴向右y轴向下。在这种坐标系里正角度的方向表现和人直觉里的“逆时针”可能是反的。我最初用模板旋转做定位时把匹配到的角度直接发给机械手结果机械手越转越歪。后来单独做了一个标定实验把一块工件摆成已知角度跑一次算法对照返回值才确认代码里需要加一个符号转换。这个问题是所有视觉项目里最容易出错也最不容易被发现的坑。我建议在正式集成前花十分钟做一次方向验证实验。具体做法是找一块旋转对称性较低的工件分别摆成0度、90度、180度、270度记录算法输出再和实际物理角度对比。只要这组数据对上了坐标和角度换算就基本稳了。6. 更进一步的优化与个人小结6.1 什么时候不该硬用模板匹配多角度模板匹配虽然能解决旋转问题但它也有自己的适用范围。如果你的搜索目标纹理非常丰富比如印刷电路板上的大片电容、芯片特征点数量充足那用特征点匹配可能是更轻快、鲁棒的选择。因为模板匹配本质上是全局像素对齐对目标形变、遮挡、部分缺失非常敏感而特征匹配只依赖局部特征点抗遮挡能力更强。还有一种情况我也会直接劝退模板匹配目标姿态变化远不止旋转还包括明显的缩放、透视、柔性形变。比如来料高度不同导致相机成像大小变化模板匹配就需要额外做多尺度搜索搜索空间增加一个缩放维度代价和复杂度都会显著上升。这时候如果条件允许用商业机器视觉软件里的形状匹配模块往往更省事它们在模型构建、层金字塔搜索、亚像素定位上做了大量优化鲁棒性和速度都比自研方案好。反过来讲如果对象是刚体、姿态变化以纯旋转为主、纹理并不丰富那么多角度模板匹配依然是一个性价比极高的方案。代码可控原理清晰调试路径短出现问题你自己就能改不必依赖黑盒。6.2 后续可以扩展的方向这篇文章给出的示例代码是以“单目标、已知尺度相近”为前提的。实际项目里还可以继续扩展。尺度方面可以在粗检阶段同时遍历多个缩放比例比如1.0、0.9、0.8等每组缩放角度少取一些先锁定大致缩放和角度再在原分辨率上精检。这就是把二维平移加旋转的三维搜索再扩成四维搜索。掩码方面如果你的工件背景复杂、形状不规则建议投入精力研究支持掩码的模板匹配。把模板的有效区域单独提取出来每次都只在有效区域内计算相似度能让分数更真实误匹配率更低。速度方面如果帧率高、搜索图大可以考虑把EmguCV的OpenCL后端打开或者把匹配任务拆给GPU处理。对于中等尺寸图像粗精配合加金字塔已经能把单帧消耗控制在几十毫秒级别足够的产线应用通常不需要再上GPU。最后再聊一点个人体会。我做这类视觉功能时最深的感受是算法本身并不难难的是你以为算法没问题实际调试时却发现图像采集、坐标标定、角度方向、模板截取这些边缘环节到处都在埋雷。多角度模板匹配在代码层面可能只要几个函数但它能不能在产线上稳定跑起来取决于你对图像质量、模板设计和坐标基准的细节是否较真。建议你把模板签名、匹配分数、调试图这些关键信息都保留下来建立一套属于自己项目的“视觉调试日志”排查问题时能省掉大量猜来猜去的时间。这样一套带旋转角度的模板匹配功能才能真正从Demo变成可靠落地的一环。
