简介基于C与OpenCV的高精度手势检测项目面向具备一定视觉基础的开发者与研究人员主要解决自然人机交互中实时手势定位与姿态估计的部署难题。压缩包共六个文件包括两个C源文件、两个配套头文件以及两个ONNX模型文件整体大小约四点二一MB。其中ONNX模型来自MediaPipe预训练的手掌检测与手势姿态估计网络分别输出手部边界框与关键点坐标可直接结合OpenCV的视频捕获与图像处理流程进行实时推理。已有四百三十八人学习下载适合机器人控制、智能终端、虚拟现实等方向二次开发。资源将源码与模型分离手掌检测与姿态估计逻辑独立封装便于按需替换模型或调整预处理步骤也适合作为课程设计或工程原型的参考实现整个过程无需自行训练模型可大幅降低开发成本。1. 高精度手势检测为什么选 C 与 OpenCV 这条路先说个反直觉的结论做手势检测Python 生态确实方便但真正要落到产品里C 加 OpenCV 才是大多数人绕不开的主战场。原因很直接——嵌入式设备、工业一体机、桌面客户端的部署环境里Python 运行时往往太重而 C 的编译产物可以做到零依赖发布内存和延迟都可控。标题里说的“高精度手势检测”本质上是一个完整的视觉 Pipeline图像采集、手部区域定位、关键点提取、手势分类每一步都有精度损失的可能最后叠加出来的效果才是用户感知到的“精度”。这篇文章会把这条链路拆开讲从模型选型到 C 推理落地再到底层参数调优和踩坑记录目标只有一个让你在本地把一套可用、可测、可交付的手势识别 Demo 跑起来而不是停留在“能运行”的层面。2. 方案选型传统视觉与深度学习的分水岭2.1 为什么肤色分割和 HOGSVM 做不了“高精度”很多入门者上手第一个手势项目用的都是 HSV 肤色分割加轮廓检测。这套方案在纯色背景、均匀光照下确实能跑工业现场也偶尔能见到但它有三个硬伤第一肤色模型对光照极其敏感色温一变阈值就失效第二手臂和手背的肤色连成一片分割出来的是“手臂区域”而不是“手区域”第三没法区分手势类别——你只能得到手的外轮廓但“比了个几”这种语义信息完全拿不到。换句话说肤色分割解决的是“手在哪”而高精度手势检测要解决的是“手在做什么动作”这是两个维度的问题。HOG 加 SVM 的经典组合我也试过用一个公开手势数据集训练线性 SVM在测试集上准确率能到 90% 左右但一到真实场景就崩。原因是 HOG 特征对遮挡、旋转和手部形变太敏感而手势恰恰是形变极大的目标——同一个“OK”手势不同人的手指弯曲幅度差异非常大。后来我彻底转向了深度学习方案核心思路是用一个目标检测模型定位手部区域再用一个分类模型或关键点模型去判断具体手势两步串联。2.2 两条主流落地路线检测分类 vs 单阶段手势识别现在做手势检测主流的分法有两类。第一类是“两阶段”目标检测模型YOLO 系或 SSD 系先框出手的位置然后把框内的图像裁出来喂给一个手势分类网络比如 MobileNet、ResNet 的轻量版本。这种方案的好处是每个环节都可独立优化手部检测不准就换检测模型手势分类不准就单独调分类模型排查问题非常方便。第二类是“单阶段”用一个端到端的模型直接输出手势类别和关键点坐标典型代表是 MediaPipe 的 Hand Landmark 方案但它依赖其专有的 TFLite 模型用 C 集成时你需要自己处理模型文件和推理依赖。我一般会推荐两阶段方案原因是工程可控性高。手部检测模型你可以用 YOLOv5n 或 YOLOv8n 的 ONNX 导出手势分类模型可以用一个轻量的自定义 CNN两个模型分开部署、分开迭代。这样“高精度”才有得谈——当手势分类准确率不够时你不需要重新训练手部检测模型只需要扩充手势分类数据集就够了。2.3 选 C 和 OpenCV 的底气推理引擎与图像处理的配合选 C 不是情怀是落地场景逼的。OpenCV 负责图像采集VideoCapture、预处理resize、归一化、色彩空间转换、后处理可视化画框、画关键点深度学习推理交给 ONNX Runtime 或 OpenCV DNN 模块。这套组合里OpenCV 的 DNN 模块有个好处是零额外依赖一个动态库全搞定但对算子的支持完整度不如 ONNX RuntimeONNX Runtime 虽然要额外链接库但兼容性和性能都更好尤其是在 CPU 上支持多线程加速。我的建议是如果你的手势检测模型只用到了常规卷积、池化、全连接OpenCV DNN 够了如果模型里有自定义算子或较新的激活函数直接上 ONNX Runtime。以下是一个最小化推理模块的代码骨架用来验证模型能否被正确加载和推理#include opencv2/opencv.hpp #include opencv2/dnn.hpp #include iostream int main() { // 加载 ONNX 模型DNN 模块自带解析器 cv::dnn::Net net cv::dnn::readNetFromONNX(hand_det.onnx); // 读取一张测试图确认模型输入输出通道 cv::Mat img cv::imread(test_hand.jpg); cv::Mat blob cv::dnn::blobFromImage(img, 1.0 / 255.0, cv::Size(640, 640), cv::Scalar(0, 0, 0), true, false); net.setInput(blob); std::vectorcv::Mat outputs; net.forward(outputs, net.getUnconnectedOutLayersNames()); // 打印输出张量的形状验证模型 for (size_t i 0; i outputs.size(); i) { std::cout Output i : outputs[i].size[2] x outputs[i].size[3] std::endl; } return 0; }这段代码做的事很直白读图、转 blob、前向推理、打印输出维度。blobFromImage 里的参数是关键——1.0 / 255.0是归一化系数cv::Size(640, 640)是模型输入尺寸最后的true表示通道顺序从 BGR 转为 RGB。如果你的模型训练时用的是 RGB 输入这里就必须是 true否则推理结果会诡异检测框位置偏移、分类置信度普遍偏低。我见过太多人在这一步翻车输出张量维度对不上还以为是模型导出有问题其实是通道顺序搞反了。3. 模型训练与数据集构建高精度的源头在数据3.1 数据集的两种构建策略公开数据集与自采数据增强手势检测的数据集建设决定了你的精度天花板。公开数据集方面常用的有 11K Hands、HaGRID 这类大规模手势数据集类别覆盖常见手势但它们的图像大多是自拍视角或半身视角与你实际部署场景的摄像头角度可能差异很大。如果你的摄像头是俯拍桌面比如手势控制电脑公开数据集的分布就和真实场景偏差较大直接训练出来精度一定不达标。我的做法是“公开数据集预训练 自采数据微调”。先拿公开数据集训练一个基础模型然后架好摄像头采集自己真实场景下的手势图像标注后做微调。自采数据不需要太多——每个手势类别 300 到 500 张就足够把精度拉起来但采集时要注意覆盖不同肤色、不同手型、不同光照时段。数据增强方面随机亮度扰动、HSV 饱和度扰动、随机仿射变换小幅度的旋转和缩放、随机遮挡用黑色矩形块随机遮挡手部区域这四类增强对提升手势检测的鲁棒性最有效。3.2 训练手势分类模型一个可落地的轻量 CNN手势分类模型的输入是手部检测框裁剪出来的图像区域通常缩放到 96x96 或 128x128。模型不需要很重MobileNetV2 的 0.5 倍宽度系数就够了。下面是一个用 PyTorch 定义和训练手势分类器的简化示例核心是让你看到输入输出的组织方式而不是完整训练脚本完整脚本通常在训练框架目录下import torch import torch.nn as nn import torch.optim as optim from torchvision import transforms from torch.utils.data import Dataset, DataLoader class GestureCNN(nn.Module): def __init__(self, num_classes10): super().__init__() # 用深度可分离卷积替代标准卷积降低参数量 self.features nn.Sequential( nn.Conv2d(3, 32, kernel_size3, stride2, padding1), nn.BatchNorm2d(32), nn.ReLU(inplaceTrue), nn.Conv2d(32, 64, kernel_size3, stride2, padding1), nn.BatchNorm2d(64), nn.ReLU(inplaceTrue), nn.Conv2d(64, 128, kernel_size3, stride2, padding1), nn.BatchNorm2d(128), nn.ReLU(inplaceTrue), ) self.classifier nn.Sequential( nn.AdaptiveAvgPool2d(1), nn.Flatten(), nn.Dropout(0.5), nn.Linear(128, num_classes) ) def forward(self, x): return self.classifier(self.features(x)) # 数据增强亮度/饱和度扰动 随机仿射 train_transform transforms.Compose([ transforms.Resize((128, 128)), transforms.ColorJitter(brightness0.2, saturation0.2), transforms.RandomAffine(degrees10, translate(0.05, 0.05)), transforms.ToTensor(), transforms.Normalize(mean[0.485, 0.456, 0.406], std[0.229, 0.224, 0.225]) ])这个模型结构不复杂但有几个参数值得说第一Dropout(0.5)在手势分类任务里很关键因为手势数据集通常不大全连接层极易过拟合第二RandomAffine的旋转角度设成 10 度以内不要太大——手势分类对旋转有一定容忍度但超过 15 度的旋转会让模型混淆“二”和“三”这种相邻手势第三Normalize的均值和标准差用的是 ImageNet 统计值如果你的模型是从头训练而不是迁移学习这里可以改成自己数据集算出的均值和标准差精度会有 1-2 个百分点的提升。3.3 手部检测模型YOLO 系模型的训练与导出手部检测我一般直接用 YOLOv8n它在 COCO 上预训练过 person 类迁移到 hand 类很快收敛。训练时只需要把数据集标注成 hand 单类别或者保留 person 类别一起训效果更好默认的输入尺寸 640x640 不用改。训练完成后导出 ONNX 时要注意指定 opset 版本太低的 opset 不支持某些算子太高了 OpenCV DNN 可能解析不了。经验值是 opset 12 到 14这个范围在 OpenCV 4.8 以上版本和 ONNX Runtime 1.15 上表现最稳。导出命令一般是yolo export modelyolov8n.pt formatonnx opset12 simplifyTruesimplifyTrue会让 ONNX 模型经过优化器精简计算图去掉一些冗余的 reshape 和 transpose 操作推理速度能快 10% 到 20%。但注意simplify 有时会改变模型输出的张量排列方式导出后一定要用 ONNX Runtime 或 OpenCV DNN 跑一张测试图对比输出结果和 PyTorch 原始模型是否一致。我在一个模拟项目上遇到过 simplify 后输出张量的维度从 [1, 84, 8400] 变成 [1, 8400, 84] 的情况解析代码要跟着改否则检测框全部错位。4. C 端推理落地从模型加载到手势输出4.1 图像预处理的关键细节BGR/RGB、归一化、letterboxC 端做推理最容易出问题的就是预处理环节。训练时 PyTorch 的数据加载流程是读图PIL 默认 RGB→ resize → 归一化 → 转 tensor。C 端 OpenCV 读图默认是 BGR如果你直接用这个 BGR Mat 转 blob模型看到的通道顺序和训练时不一致推理效果会断崖式下跌。所以预处理的第一步永远是 BGR 转 RGBcv::cvtColor(img, img_rgb, cv::COLOR_BGR2RGB)。第二个关键是 letterbox。YOLO 系模型的输入是正方形但实际图像几乎都是矩形。直接把矩形图 resize 成正方形物体会被拉伸变形检测精度明显下降。正确做法是 letterbox缩放图像保持宽高比然后在边缘填充灰色通常是 114 或 128补成正方形。对应的 C 实现如下cv::Mat letterbox(const cv::Mat src, int target_size, cv::Vec4d params) { int orig_w src.cols; int orig_h src.rows; double r std::min((double)target_size / orig_w, (double)target_size / orig_h); int new_w round(orig_w * r); int new_h round(orig_h * r); cv::Mat resized; cv::resize(src, resized, cv::Size(new_w, new_h), 0, 0, cv::INTER_LINEAR); int pad_w target_size - new_w; int pad_h target_size - new_h; int pad_left pad_w / 2; int pad_top pad_h / 2; cv::Mat out(target_size, target_size, src.type(), cv::Scalar(114, 114, 114)); resized.copyTo(out(cv::Rect(pad_left, pad_top, new_w, new_h))); // 保存缩放比和填充尺寸后处理时需要反过来映射坐标 params cv::Vec4d(r, pad_left, pad_top, 0); return out; }这里params里的r、pad_left、pad_top必须保存下来后处理把检测框坐标映射回原图时要用。INTER_LINEAR是默认插值方式如果你追求更高的检测精度可以换成INTER_CUBIC但耗时大约增加一倍。实际项目里除非是静态图像处理视频流场景一律用INTER_LINEAR人的肉眼分辨不出那点差异。4.2 手部检测推理与坐标映射解析 YOLO 输出并映射回原图YOLOv8 的输出是一个 [1, 84, 8400] 的张量8400 是三个尺度特征图上的候选框总数84 是 4 个边界框坐标加 80 个类别得分。你训练成单类 hand 时最后一个维度会变成 54 坐标 1 分类得分或 64 坐标 2 分类包括背景类具体要看训练框架的实现。解析逻辑是先按置信度阈值过滤候选框再做 NMS 去重最后用之前保存的r、pad_left、pad_top把坐标映射回原图。核心代码如下std::vectorcv::Rect parse_yolo_output(const cv::Mat output, double conf_threshold, int img_w, int img_h, const cv::Vec4d letterbox_params) { std::vectorcv::Rect boxes; std::vectorfloat scores; int num_boxes output.cols; // 8400 int num_attrs output.rows; // 84 double r letterbox_params[0]; double pad_left letterbox_params[1]; double pad_top letterbox_params[2]; for (int i 0; i num_boxes; i) { const float* row output.ptrfloat(0) i * num_attrs; float score row[4]; // 单类模型的置信度 if (score conf_threshold) continue; // YOLOv8 输出的是 cx, cy, w, h归一化到 [0,1] float cx row[0] * 640.0f; float cy row[1] * 640.0f; float w row[2] * 640.0f; float h row[3] * 640.0f; // 映射回原图坐标 int x1 (int)((cx - w / 2 - pad_left) / r); int y1 (int)((cy - h / 2 - pad_top) / r); int x2 (int)((cx w / 2 - pad_left) / r); int y2 (int)((cy h / 2 - pad_top) / r); x1 std::max(0, std::min(x1, img_w - 1)); y1 std::max(0, std::min(y1, img_h - 1)); x2 std::max(0, std::min(x2, img_w - 1)); y2 std::max(0, std::min(y2, img_h - 1)); boxes.emplace_back(x1, y1, x2 - x1, y2 - y1); scores.push_back(score); } // NMS 去重IoU 阈值 0.45 是常见默认值 std::vectorint indices; cv::dnn::NMSBoxes(boxes, scores, conf_threshold, 0.45f, indices); std::vectorcv::Rect results; for (int idx : indices) { results.push_back(boxes[idx]); } return results; }这段代码里有几个容易忽略的细节。第一output.ptrfloat(0)拿到的数据是连续内存YOLOv8 的 ONNX 输出布局可能是 [1, 84, 8400]也可能被优化成 [1, 8400, 84]需要先用前面提到的验证代码打印维度确认第二row[4]是置信度的前提是模型输出为 [cx, cy, w, h, score]如果你的模型是多类输出这里要改成遍历所有类别找最大得分第三坐标映射时除以r之后可能出现负值所以 clamp 到图像边界是必须的否则画框时 OpenCV 直接崩溃。4.3 手势分类推理与计时把两步串成一个完整 Pipeline拿到手部检测框之后裁剪、缩放到 128x128、转 blob、推理手势分类模型这就是完整的 Pipeline。实际工程中我会把手部检测和手势分类放在同一个循环里同时用cv::getTickCount统计每帧推理耗时方便后续性能调优cv::VideoCapture cap(0); cap.set(cv::CAP_PROP_FRAME_WIDTH, 1280); cap.set(cv::CAP_PROP_FRAME_HEIGHT, 720); cap.set(cv::CAP_PROP_FPS, 30); while (true) { cv::Mat frame; cap frame; if (frame.empty()) break; // 推理计时开始 double t0 (double)cv::getTickCount(); // 步骤 1手部检测 cv::Mat rgb; cv::cvtColor(frame, rgb, cv::COLOR_BGR2RGB); cv::Vec4d lp_params; cv::Mat ltb letterbox(rgb, 640, lp_params); cv::Mat blob cv::dnn::blobFromImage(ltb, 1.0 / 255.0, cv::Size(640, 640), cv::Scalar(0, 0, 0), true, false); det_net.setInput(blob); cv::Mat det_out det_net.forward(); // 解析检测框略 std::vectorcv::Rect hands parse_yolo_output(det_out, 0.5, frame.cols, frame.rows, lp_params); // 步骤 2对每个检测框做手势分类 for (auto hand : hands) { cv::Mat hand_crop frame(hand); cv::Mat hand_resized; cv::resize(hand_crop, hand_resized, cv::Size(128, 128)); cv::Mat hand_blob cv::dnn::blobFromImage(hand_resized, 1.0 / 255.0, cv::Size(128, 128), cv::Scalar(0, 0, 0), true, false); cls_net.setInput(hand_blob); cv::Mat cls_out cls_net.forward(); // 取最高得分对应的手势标签 cv::Point max_loc; cv::minMaxLoc(cls_out, nullptr, nullptr, nullptr, max_loc); int gesture_id max_loc.x; // 绘制检测框和手势文本 cv::rectangle(frame, hand, cv::Scalar(0, 255, 0), 2); cv::putText(frame, gesture_names[gesture_id], cv::Point(hand.x, hand.y - 5), cv::FONT_HERSHEY_SIMPLEX, 0.8, cv::Scalar(0, 255, 0), 2); } // 帧率统计 double t1 (double)cv::getTickCount(); double fps cv::getTickFrequency() / (t1 - t0); cv::putText(frame, FPS: std::to_string(fps), cv::Point(20, 40), cv::FONT_HERSHEY_SIMPLEX, 0.8, cv::Scalar(0, 255, 255), 2); cv::imshow(Gesture Detection, frame); if (cv::waitKey(1) 27) break; // ESC 退出 }这个循环是完整的可运行版本。性能上要注意的是手部检测模型每帧推理一次手势分类模型对每个检测框推理一次。如果画面里同时出现两只手分类模型就要跑两次帧率会明显下降。一种优化策略是手部检测每 2 到 3 帧执行一次中间帧沿用上一次的检测框只跑手势分类。这样做帧率损失很小而且手势分类的精度几乎不受影响因为手部在帧与帧之间的移动幅度通常不超过检测框范围。5. 避坑手册手势检测最常见的 5 个翻车现场5.1 推理结果全零或检测框满天飞BGR/RGB 通道顺序错误现象模型能加载推理不报错但检测框全部集中在图像边缘或者置信度全部低于阈值画面里明明有手却检测不到。原因训练时模型看到的是 RGB 图像而 OpenCV 读图默认是 BGR。如果预处理时没有做通道转换模型输入分布完全错乱输出自然不可用。解决在blobFromImage的最后一个参数设为true表示 swapRB或者在cvtColor手动转换。验证方法是打印输入 blob 的第一个像素值再用 Python 读取同一张图做对比确认通道顺序一致。5.2 摄像头画面卡顿、帧率只有个位数VideoCapture 读取阻塞现象推理耗时只有几十毫秒但整体帧率就是上不去CPU 占用率也不高。原因cap frame是同步阻塞读取如果摄像头驱动缓冲机制不好read 操作会等待下一帧到来导致实际帧率被摄像头硬性帧率锁死。在 USB 摄像头上尤其明显尤其是从 V4L2 驱动读取时。解决把视频采集放到单独线程用环形缓冲存最近几帧主线程推理时直接取最新帧。OpenCV 自带的VideoCapture不支持多线程直接共享但你可以用cap.grab()配合cap.retrieve()手动控制或者用双线程加互斥锁保护Mat的读写。注意Mat是浅拷贝引用计数跨线程传递时要用clone()深拷贝否则主线程释放空间时采集线程还在写会引发段错误。5.3 检测框抖动厉害没有做时间域平滑现象手静止不动时检测框在±20 像素范围内来回跳手势分类结果也在两个类别间反复横跳。原因模型对每帧独立推理单帧的置信度波动会导致框位置抖动。摄像头本身也有噪声尤其是低光照环境下手部边缘的纹理变化会直接影响检测框的尺寸和中心点。解决对检测框中心点做 EMA指数滑动平均一阶滤波就能消掉大部分抖动// 全局变量保存上一次的平滑结果 cv::Rect smooth_hand; bool has_smooth false; cv::Rect smooth_rect(const cv::Rect raw, double alpha) { if (!has_smooth) { smooth_hand raw; has_smooth true; return raw; } smooth_hand.x (int)(alpha * raw.x (1 - alpha) * smooth_hand.x); smooth_hand.y (int)(alpha * raw.y (1 - alpha) * smooth_hand.y); smooth_hand.width (int)(alpha * raw.width (1 - alpha) * smooth_hand.width); smooth_hand.height (int)(alpha * raw.height (1 - alpha) * smooth_hand.height); return smooth_hand; }alpha取 0.4 到 0.6 之间比较合适。太大起不到平滑效果太小框会滞后手快速移动时框跟不上。5.4 手势分类误判率高但检测框准确分类头输入尺寸和训练不一致现象手部检测框非常准但手势分类结果混乱同一个手势十次推理六个结果。原因分类模型训练时输入是 128x128但推理时裁剪区域是检测框的原始尺寸直接 reshape导致宽高比失真。比如检测框是横向的手比“六”时直接 resize 成 128x128 会把图像压扁模型自然认不出来。解决裁剪后先做 letterbox 或等比例填充再 resize 到模型输入尺寸。另外还要注意分类模型的训练数据本身就是从检测框裁剪得到的你训练时如果用矩形框直接拉伸那推理时保持一致即可如果训练时用了正方形化预处理推理时也要做同样的预处理。数据管线的每个环节都要保持训练推理一致性这是“高精度”的基本功。还有一个常见但容易被忽略的问题手部检测框到手势分类头的数据流里blobFromImage的归一化系数必须和训练时完全一致。很多人在训练代码里用了transforms.Normalize(mean[0.485, 0.456, 0.406])但 C 推理时只用了1.0 / 255.0这等于把输入分布整体平移了模型输出概率就会偏向某些类别。要么 C 端手动实现减均值除标准差要么训练时索性不用 Normalize只用ToTensor()归一到 [0,1]两边就对齐了。5.5 模型加载慢且内存占用高OpenCV DNN 与 ONNX Runtime 的选择问题现象模型加载耗时 3 到 5 秒运行时内存峰值超过预期在低配嵌入式设备上直接被系统杀掉。原因OpenCV DNN 模块的readNetFromONNX在首次推理时会进行算子融合和内存布局优化这个时间通常在几秒级而且在 CPU 上默认不启用多线程优化的话内存占用会偏高。如果你的设备是 ARM 架构OpenCV DNN 的算子优化不如 ONNX Runtime 充分。解决换成 ONNX Runtime C API它有专门的 ARM 优化。其次模型加载后调用net.setPreferableBackend(cv::dnn::DNN_BACKEND_OPENCV)配合DNN_TARGET_CPU有时能减少加载时间但老版本 OpenCV 的 DNN 模块在解析复杂 ONNX 图时会额外消耗内存。如果你对性能敏感我的建议是直接用 ONNX Runtime它的初始化虽然也慢但跑起来更稳内存占用也更可预测。6. 进阶调优从能用 到 好用 的三个技巧先说量化。手势检测模型在 CPU 上推理FP32 的耗时可能是 INT8 的两倍以上。如果你用的是 ONNX Runtime可以在导出 ONNX 模型时用动态量化工具转成 INT8 版本精度损失通常不到 2 个百分点但帧率能提升 40% 到 60%。要注意的是量化需要校准数据拿几百张真实场景的图像喂给量化工具它才能估算出合理的量化范围。没有校准的量化会让手部检测框变得不稳定尤其是在暗光环境下。再说多线程流水线。把视频采集、手部检测、手势分类、绘制显示放到四个线程用队列连接整个系统的帧率可以再上一个台阶。手部检测和手势分类是两个独立的模型推理在双核以上的设备上天然可以并行。我的一个模拟项目里单线程 Pipeline 的帧率是 28 FPS改成双线程并行推理后直接稳定在 40 FPS。当然多线程会带来一个新的问题——检测和分类的时序不一致分类拿到的检测框可能是上一帧的。实际操作中这个延迟大约 30 到 50 毫秒人眼感知不到但如果你做的是实时交互比如手势控制音量这个延迟还在可接受范围内。最后是一个屡试不爽的技巧加一个手势状态机。原始模型对每一帧独立判断手势偶尔会出现“一帧是 1下一帧是 3再下一帧又是 1”这种闪烁。我一般会维护一个状态要求同一个手势连续出现 3 帧才切换状态且切换后至少保持 5 帧不变。这样误触率几乎降为零代价是手势切换的响应变慢约 100 毫秒——在交互场景里这点延迟完全值得。状态机加上去之后你会明显感觉到识别结果“稳”了不再像一个神经质的人在不停地改主意。这套东西做下来我自己最大的教训是不要在模型上下太多功夫要把精力平均分配到数据、预处理器、推理管线和后处理这四个环节上。模型再强预处理不一致照样白搭检测框再准没有状态机照样让用户觉得“这玩意不靠谱”。希望这篇文章能帮你把边界摸清楚少走我当年走过的弯路。本文还有配套的精品资源点击获取
