路牌检测这个话题，几乎是每个学计算机视觉的人都会碰到的练手项目。前阵子我重新整理了一套基于OpenCV和VS2015的Kmeans颜色聚类实现，顺手把整个流程从环境配置到最终检测效果都过了一遍，写成这篇文章。内容面向准备做图像分割、目标检测课程设计，或者刚接触OpenCV的开发者，也适合那些想快速把Kmeans聚类落地到实际项目里的人。
这篇文章会尽量覆盖三件事：为什么用颜色聚类来做路牌检测，具体怎么一步步实现，以及那些文档里不会写的坑。Kmeans颜色聚类的思路并不复杂，但真正跑到实际图像上，你会发现光照、噪声、目标大小、颜色混淆这些问题全冒出来了。我用的环境是VS2015加OpenCV 3.4，整个项目也是C++实现的，文中给出的代码片段可以直接复制到工程里跑。
1. 项目整体设计与思路拆解
1.1 为什么选择颜色聚类而非传统目标检测
路牌检测这个需求，最直观的思路是训练一个深度学习检测器，比如用YOLO或者SSD。但在课程设计或者快速原型验证阶段，往往没有足够的标注数据，也没有GPU环境。Kmeans颜色聚类方案的最大优势就是零训练、零标注，纯粹靠颜色在图像中的分布规律做分割。这类路牌本身具有非常高的颜色辨识度：常见的指示类路牌以蓝底为主，告警类以红底或黄底为主，这样一个强颜色先验条件，正是聚类算法发挥作用的场景。
我当时也考虑过直接用固定HSV阈值做颜色分割，比如把H通道限定在某个区间内直接提取蓝色区域。这种方式实现更快，但问题也很明显：阈值是写死的，换一张图光照不同，或者画面里出现与路牌颜色接近的物体，比如蓝色的汽车、蓝色的天空，误检率一下就上去了。Kmeans做的事情是自适应的颜色分组，它不关心某个颜色是不是“蓝色”，而是把图像中所有像素按照颜色相似度分成K个族，再从中挑出符合路牌颜色特征的族。这种自适应性让它在不同场景下的鲁棒性比固定阈值高不少。
从项目整体的角度考虑，Kmeans方案还能顺带覆盖几个计算机视觉的基础模块：颜色空间转换、图像预处理、连通域分析、形态学操作、轮廓特征筛选。做一个路牌检测程序，实际上是把一整条经典的CV流水线完整走了一遍，这对学习CV基础概念的价值比单纯调一个YOLO模型大得多。
1.2 系统处理流程与模块划分
整个程序的流程可以拆成下面几个环节：
- 图像读取与预处理（缩放、去噪、颜色空间转换）。
- Kmeans颜色聚类，把图像所有像素归到K个颜色中心。
- 根据聚类中心筛选目标颜色族，生成二值掩膜。
- 形态学操作去除细小噪声，填充孔洞。
- 连通域或轮廓提取，用面积、长宽比、圆度等特征过滤候选区域。
- 在原始图上绘制检测框并输出结果。
这个流程里最难调的是第2步到第5步之间的衔接。很多初学者做完聚类，拿着标签图不知道下一步怎么办。我这里先点破一个关键：Kmeans输出的labels本质上是一张索引图，每个像素的值是0到K-1之间的类别编号，而不是颜色值。你需要根据聚类中心向量判断哪个类别属于“路牌颜色”，然后把这个类别对应的像素全部置为白色，其余置为黑色，这样才拿到真正能喂给轮廓检测的二值图。
模块划分的时候我遵循一个原则：每个阶段尽可能独立成函数，输入输出都明确。比如聚类函数只接收图像返回标签矩阵，筛选函数只接收标签矩阵和聚类中心返回掩膜。这样后续调整某一环的参数，比如把K从3改成4，不会牵一发而动全身。
2. 环境搭建与工具选型细节
2.1 VS2015与OpenCV版本搭配
选择VS2015不是随便拍的。OpenCV官方发布的Windows预编译库从3.4版本开始对VC14（即VS2015）支持得最稳定，3.4.x系列里我推荐用3.4.9，这个版本既能用官方编译好的库，又能兼容绝大多数传统CV接口。如果上OpenCV 4.x，VS2015用vc14编译会遇到不少兼容性问题，比如部分头文件在旧标准下的编译错误，折腾起来非常浪费时间。所以这套程序的最佳搭配就是VS2015加OpenCV 3.4.9。
环境配置方面，我习惯用属性表来管理OpenCV，而不是每次新建工程手动配置一次。新建一个Debug属性表，把下面的路径写进去：
- 包含目录：
D:\opencv\build\include、D:\opencv\build\include\opencv、D:\opencv\build\include\opencv2 - 库目录：
D:\opencv\build\x64\vc14\lib - 附加依赖项：
opencv_world340d.lib（Debug版）、opencv_world340.lib（Release版）
属性表的好处是，以后所有用到OpenCV的工程只需添加一次现有属性表，不用重复配置。另外建议把D:\opencv\build\x64\vc14\bin加入系统Path环境变量，否则运行时程序会提示找不到opencv_world340d.dll。
2.2 环境配置踩坑记录
VS2015配OpenCV有几个高频坑，我直接列出来：
一是Debug和Release库混用。Debug模式下链接了opencv_world340.lib，运行时不会立刻报错，但聚类结果会出现各种诡异的内存错误。原因是两个库的迭代器、容器内部实现不同，混用会造成栈损坏。正确做法是Debug工程只链接带d后缀的库。
二是平台位数弄混。你配置了x64库，但VS里解决方案平台是Win32，链接阶段报一堆LNK2019错误。常见解决办法是把整个解决方案切到x64，注意不光是编译选项，配置管理器里的活动解决方案平台也要切。
三是动态库缺失。程序编译通过但启动时弹出黄色感叹号，说找不到opencv_world340d.dll。这个本质是环境变量Path里没有包含OpenCV的bin目录。改完Path后记得重启VS，否则环境变量不会生效。
四是工程路径不能有中文。VS2015这个老版本对中文路径的处理非常糟糕，我在调试时发现图片读取API返回空Mat，排查半天发现是工程放在桌面的中文文件夹里。Model经验：所有OpenCV项目的路径统一用英文，连文件名也不要带中文。
还有一个性能相关的配置建议：Debug模式下运行聚类会特别慢，因为OpenCV的Debug库没有做优化。如果只是验证算法结果，建议用Release模式跑，速度能差5到10倍。调试逻辑用Debug，跑效果看性能切Release。
3. Kmeans颜色聚类原理与核心实现
3.1 Kmeans算法原理与K值选择
Kmeans的核心思想很简单：给定K个初始聚类中心，把每个像素分配到距离最近的中心，然后重新计算每个类的均值作为新中心，迭代直到中心变化小于阈值。OpenCV里的实现使用的是cv::kmeans函数，内部支持Kmeans++初始化方法，能显著降低初始中心随机性带来的不稳定性。
调用形式如下：
double cv::kmeans( InputArray data, // 输入数据，每行一个样本 int K, // 聚类数 InputOutputArray bestLabels, TermCriteria criteria, // 迭代终止条件 int attempts, // 随机初始化次数 int flags, // 初始化方法 OutputArray centers // 聚类中心 );attempts参数值得特意说明。如果你设置成3，算法会分别用不同的随机初始中心跑3次，最终返回误差最小的一次。这个参数直接决定了结果的稳定性，我建议至少设3到5，实测下来聚类结果不再出现明显的类别跳变。
K值的选取是这个项目里最需要讲道理的地方。我试了几种场景，K=3是比较常用的起点：一类是路牌主色（蓝或红），一类是道路背景（灰、深色），一类是天空或绿化带等亮色区域。如果画面更复杂，比如同时出现多种颜色的车辆和广告牌，K=3会把它们硬并到某一类里，掩膜会多出很多噪声区域，这时候可以把K提高到5或6。需要注意的是，K值越大，聚类运行时间越长，掩膜也会越碎。
线形示例：一张1280x720的图，像素数约92万，数据矩阵为92万行3列，K=4、attempts=3的时候，单次聚类在Release模式下大约耗时200到400毫秒。如果图再大，比如1920x1080，耗时可能超过1秒。建议先把图像缩放到宽600到800的区间再做聚类，速度提升明显，路牌检测的精度不受影响。
3.2 色彩空间选择：RGB与HSV的取舍
Kmeans可以直接在RGB空间跑，效果能用但不理想。原因在于RGB三个通道的相关性太强，光照变化会同时影响多个通道，聚类出的颜色簇与人类感知的颜色类别差异较大。举个具体的例子：深蓝色路牌在RGB空间里是（20, 40, 120），阴天时可能变成（40, 70, 160），两个值之间的距离相比晴天时大很多，聚类时可能被分到两个不同类别里。
HSV空间解决了这个问题。H通道代表色相，S代表饱和度，V代表亮度。在HSV下，颜色分群主要看H通道，亮度变化主要影响V，在一定程度上解耦了光照影响。我最终的实现用了HSVL颜色空间，具体做法是把BGR图像转成HSV，然后对H、S、V三个通道一起做聚类。为什么不只对H通道聚类？因为只用H通道会出现两个问题：饱和度极低的灰色区域，比如水泥路面，其H值是没有意义的随机数，聚类到哪类都不稳定；低亮度区域也一样，V太小的时候颜色可信度很低。所以H、S、V一起用，虽然光照仍然有影响，但比纯RGB好得多。
不过HSV有一个经典的坑：H通道是角度量，取值范围是0到180，0和180在数值上差得很远，但代表的颜色几乎一样（红色）。如果直接对H通道做欧氏距离聚类，红色可能被切成两类，各在0和180附近。这种情况在处理红色路牌时特别明显。解决办法有几个：
- 把H通道转换成二维笛卡尔坐标：
x = S*cos(2*H*PI/180)，y = S*sin(2*H*PI/180)，再把x、y和V拼接成三维向量。这个方案最严谨，我推荐使用。 - 或者简单粗暴一点：只在聚类之后做合并，把最接近0和最接近180的红色中心合并成一个类别。
实际项目里我采用的是第一种做法，转换后聚类结果稳定很多。代码如下：
// BGR -> HSV cv::Mat hsv; cv::cvtColor(src, hsv, cv::COLOR_BGR2HSV); // 将H通道的角度信息映射到二维平面，避免0和180相邻问题 cv::Mat channels[3]; cv::split(hsv, channels); cv::Mat H = channels[0]; cv::Mat S = channels[1]; cv::Mat V = channels[2]; cv::Mat hx, hy; // H范围0~180，转换为弧度 H.convertTo(H, CV_32F); S.convertTo(S, CV_32F); V.convertTo(V, CV_32F); hx = S.mul(cv::Mat(H.size(), CV_32F, cv::Scalar(1))) ; // 实际计算时使用 cos 和 sin cv::Mat ang = H * 2 * CV_PI / 180.0; cv::Mat cosA, sinA; cv::cos(ang, cosA); cv::sin(ang, sinA); hx = S.mul(cosA); hy = S.mul(sinA);这里有一点必须提醒：cv::kmeans的输入是CV_32F类型的浮点矩阵，如果直接把8UC3的Mat传进去，数据会读成一堆无符号字符，聚类结果完全错误。转换时必须先把图像矩阵转成CV_32F，然后再reshape成N行3列。很多人在这里踩坑，检查代码表现就是聚类输出看起来毫无规律。
3.3 核心代码实现与参数讲解
完整的聚类部分代码模板如下：
cv::Mat src = cv::imread("road_sign.jpg"); if (src.empty()) { std::cout << "image load failed" << std::endl; return -1; } // 1. 缩放图像，加速聚类 cv::Mat small; float scale = 640.0f / src.cols; cv::resize(src, small, cv::Size((int)(src.cols * scale), (int)(src.rows * scale))); // 2. BGR -> HSV，H转换笛卡尔坐标 cv::Mat hsv, feature; cv::cvtColor(small, hsv, cv::COLOR_BGR2HSV); std::vector<cv::Mat> hsvCh; cv::split(hsv, hsvCh); cv::Mat Hf, Sf, Vf; hsvCh[0].convertTo(Hf, CV_32F); hsvCh[1].convertTo(Sf, CV_32F); hsvCh[2].convertTo(Vf, CV_32F); cv::Mat angle = Hf * 2 * CV_PI / 180.0; cv::Mat cA, sA; cv::cos(angle, cA); cv::sin(angle, sA); cv::Mat hx = Sf.mul(cA); cv::Mat hy = Sf.mul(sA); std::vector<cv::Mat> feats = {hx, hy, Vf}; cv::merge(feats, feature); // 3. 转成Nx3浮点矩阵 cv::Mat samples = feature.reshape(1, feature.rows * feature.cols); // 4. Kmeans聚类 int K = 4; cv::Mat labels, centers; cv::TermCriteria criteria(cv::TermCriteria::EPS + cv::TermCriteria::COUNT, 10, 1.0); cv::kmeans(samples, K, labels, criteria, 5, cv::KMEANS_PP_CENTERS, centers); // 5. labels 恢复成图像尺寸 cv::Mat labelImg(small.size(), CV_32S); for (int i = 0; i < small.rows; i++) { for (int j = 0; j < small.cols; j++) { labelImg.at<int>(i, j) = labels.at<int>(i * small.cols + j); } } // 6. 后续掩膜提取基于 labelImg 和 centers关于TermCriteria的三个参数：EPS表示聚类中心变化小于1.0时停止迭代，COUNT表示最多迭代10次。10次往往足够收敛，如果设置超过50，耗时增加但结果几乎不变，原因是Kmeans在CV里本身收敛很快。
cv::KMEANS_PP_CENTERS就是Kmeans++初始化，选择离已有中心最远的点作为新中心，能明显改善聚类质量。flags还有cv::KMEANS_RANDOM_CENTERS，那是纯随机，我不建议用，同一张图每次跑结果可能都不一样。
4. 路牌检测完整流程与实操记录
4.1 聚类后的掩膜提取
拿到labels和centers后，下一步是根据聚类中心的颜色特征找出哪一类是路牌颜色。这里有一个简单的判别策略：遍历centers的每一行，该行就是聚类中心在特征空间的坐标，其中第一维和第二维是色相映射值。绝大多数情况下，路牌蓝色中心在HSV中的H约等于110（OpenCV的0~180范围），红色中心H约等于0或170附近。如果你像我一样把H映射成了笛卡尔坐标，可以再用cv::cartToPolar把它还原成H角度，或者直接判断映射值特征。
写一个类别筛选函数：
bool isTargetClass(const cv::Mat& center) { // center 是 1x3 的浮点行向量 double hx = center.at<float>(0); double hy = center.at<float>(1); double v = center.at<float>(2); double h_deg = std::atan2(hy, hx) * 180.0 / CV_PI; if (h_deg < 0) h_deg += 360.0; // 目标：蓝色 或 红色 bool isBlue = (h_deg >= 100 && h_deg <= 130) && v > 50; bool isRed = (h_deg <= 20 || h_deg >= 340) && v > 50; return isBlue || isRed; }这个函数等于把Kmeans的结果和路牌颜色先验结合了起来。你也可以不判断聚类中心颜色，而是直接在所有类别里找蓝色或红色区域，但那样就退回了固定阈值法的思路。用聚类中心判断的好处是，每个类别内的颜色已经做过统计平均，比逐像素阈值更稳定，不容易受单点噪声影响。
判定出目标类别后，生成掩膜：
cv::Mat mask = cv::Mat::zeros(small.size(), CV_8UC1); for (int i = 0; i < small.rows; i++) { for (int j = 0; j < small.cols; j++) { int c = labelImg.at<int>(i, j); if (targetClassIds.count(c)) { mask.at<uchar>(i, j) = 255; } } }如果有几类中心都满足颜色条件，可以把它们全部加入目标集合。比如同时有亮蓝和暗蓝两个类都需要保留。
4.2 形态学处理与连通域分析
原始掩膜提取出来通常很粗：边缘锯齿、内部小孔、背景里的零星噪点，可能还有少量的误分割区域。直接用cv::findContours找轮廓的话，轮廓数量可能上百个，噪声轮廓的面积也不小，后续筛选压力很大。形态学处理是这一步的核心。
我常用的流程是先做一次开运算，再闭运算。开运算（先腐蚀后膨胀）用来去掉掩膜上的孤立小点和细长突起；闭运算（先膨胀后腐蚀）用来填充路牌内部因为反光或遮挡产生的小孔洞。核的大小很讲究：
- 3x3的核效果太轻，几乎起不到过滤作用。
- 7x7的核会让小尺寸路牌细节丢失，边缘被磨平，后续长宽比判断失真。
- 5x5椭圆核是大部分场景的合理折衷，既能清除细小噪声，又不会明显改变路牌形状。
操作代码：
cv::Mat kernel = cv::getStructuringElement(cv::MORPH_ELLIPSE, cv::Size(5, 5)); cv::morphologyEx(mask, mask, cv::MORPH_OPEN, kernel); cv::morphologyEx(mask, mask, cv::MORPH_CLOSE, kernel);形态学之后做连通域标记。cv::connectedComponentsWithStats比findContours更适合这个场景，因为它能直接输出每个连通域的外接矩形、面积、中心点等统计信息，省得再写一堆轮廓计算代码。
cv::Mat stats, centroids; int nComp = cv::connectedComponentsWithStats(mask, labels, stats, centroids, 8, CV_32S);从第1个连通域开始遍历（第0个是背景），读取每块的面积、宽高、外接矩形。注意这里stats的结构是N行5列，分别为左边界x、上边界y、宽度w、高度h、面积area，类型是CV_32S，读取时要用stats.at<int>(i, col)。
4.3 形状特征筛选与识别判定
连通域标完以后，并不是每个蓝色组件都是路牌。实际场景里会出现蓝色垃圾桶、蓝色广告牌、蓝色彩钢房，这时候就需要用几何特征做进一步的过滤。
我总结了两类硬性约束和一类软性评分：
面积约束。候选连通域面积至少要占整幅图像面积的0.5%以上。一张64万像素的原图，候选区域的像素数至少要3200。这个阈值可以根据路牌在画面中的大小合理缩放，防止把远处的小目标漏检，同时过滤掉大量微小噪点。
尺寸约束。宽度和高度都要大于某个最小值，比如20像素。太窄的组件大概率是树干、标线等细长物体。另一个重要特征是长宽比，普通矩形指示路牌一般在1:1到3:1之间，三角形警告牌的比例接近1:1。如果连通域长宽比大于6，比如马路上的长条阴影，基本可以直接排除。
圆度和矩形度辅助判断。圆度等于4*PI*面积 除以 (周长^2)，正圆是1。矩形度等于面积 除以 外接矩形面积，正矩形是1。因为我这里主要检测矩形或正三角路牌，所以矩形度设为0.6以上。这个特征能有效过滤带圆角的广告牌和任意形状的反光区域。
筛选流程的伪代码如下：
for (int i = 1; i < nComp; i++) { int area = stats.at<int>(i, cv::CC_STAT_AREA); int w = stats.at<int>(i, cv::CC_STAT_WIDTH); int h = stats.at<int>(i, cv::CC_STAT_HEIGHT); int x = stats.at<int>(i, cv::CC_STAT_LEFT); int y = stats.at<int>(i, cv::CC_STAT_TOP); if (area < small.rows * small.cols * 0.005) continue; if (w < 20 || h < 20) continue; double ratio = (double)w / h; if (ratio > 6.0 || ratio < 0.25) continue; // 计算矩形度 double rectRatio = (double)area / (w * h); if (rectRatio < 0.6) continue; // 通过所有约束，认定是路牌候选 cv::rectangle(small, cv::Rect(x, y, w, h), cv::Scalar(0, 0, 255), 3); }这一步我发现一个比较隐蔽的现象：路牌外边框的黑边会对掩膜提取造成干扰。很多路牌是白底黑边，或者蓝底白边，聚类时黑色边框会被单独并成一类，导致路牌目标的掩膜被分成两块，中间出现黑色空隙。闭运算能把小的空隙填掉，但如果空隙太大，候选区域会被拦腰截断。解决方案是把黑色类别也纳入目标类别后做合并，或者适当增大闭运算核的尺寸。后来我采用的方法是先判断某类别是否为接近黑色的类别，如果是就把它的像素也标为目标类，这样整块路牌才能连成一个完整的连通域。
5. 常见问题与调试经验实录
5.1 程序崩溃与内存问题排查
这个项目里我遇到最多的问题集中在cv::kmeans的输入数据上。第一类崩溃是数据矩阵类型不对，把8UC3的Mat直接当作输入，运行到一半报内存访问越界。解决办法就是前面提到的convertTo(CV_32F)。
第二类是reshape的使用错误。reshape(1, feature.rows * feature.cols)中，第一个参数是通道数，设为1表示每个样本是一维的行向量。如果原feature是3通道，会先按通道分离再合并成单通道多行。我最初在这里误以为要设为3，结果数据直接被横向拉长，聚类结果完全错乱，程序还不报错，排查起来特别费劲。
第三类是labels和labelImg的类型不匹配。cv::kmeans输出的labels都是CV_32S，而cv::connectedComponentsWithStats的输出lables也要求CV_32S，两者一致。但如果你尝试用CV_8U去读labels，即使不崩溃，读取到的值也全是乱码。
另外要提醒的是，图像读取失败时imread会返回一个空Mat，此时如果不加src.empty()判断直接往下执行，任何操作都会崩溃。特别是图片路径带中文时，OpenCV老版本会静默返回空Mat，而不是报文件找不到。程序看起来没有任何报错信息，就是直接闪退，这是最隐蔽的一种情况。
5.2 聚类结果不稳定与光照干扰
Kmeans聚类受初始中心影响很大。即使我设置了KMEANS_PP_CENTERS和attempts=5，偶尔还会出现同一张图前后跑两次结果不同的情况，主要体现在路牌颜色类别被拆分或者合并。解决办法有两个方向：一是提高attempts到10，让算法做更多次尝试；二是固定随机数种子，OpenCV里没有直接设置随机种子的接口，但可以在调用kmeans前用cv::theRNG().state设置一个固定值，这样结果可复现，调试起来方便很多。
光照干扰是另一个大问题。强逆光场景下，路牌颜色发暗，聚类时V通道权重会把它归入阴影类，导致掩膜完全空白。我采取的缓解措施是降低V通道的特征权重，在merge特征时把V乘一个0.5的系数：
Vf = Vf * 0.5;这样聚类的划分更多依赖色相信息，亮度变化的影响被削弱。代价是原本靠亮度区分的类别可能会混在一起，但对路牌检测来说，颜色信息比亮度信息更重要，这个方向是对的。
还有一个反直觉的情况：过曝的白色路牌反光区域在HSV里饱和度为0，这类像素的H通道数值不稳定，聚类时会随机归到某一类，导致掩膜内部出现大量空洞。开闭运算能填掉不少，但最根本的办法还是测试时避免正对强光拍摄，或者在预处理阶段先做一定程度的对比度拉伸。
5.3 检测不到路牌或误检的排查速查表
我把实际调试中遇到的情况整理成一张表，遇到问题可以对照着快速定位：
| 现象 | 可能原因 | 排查方向 |
|---|---|---|
| 完全检测不到路牌 | K值太大，路牌颜色被拆分 | 降K值并检查聚类中心色相 |
| 完全检测不到路牌 | 目标类别判断条件错误 | 打印聚类中心，确认H角度范围 |
| 完全检测不到路牌 | 掩膜被形态学核过度侵蚀 | 换成3x3核或取消形态学步骤 |
| 检测到大量无关区域 | K值太小，目标和背景被并为一类 | 提高K值，让背景分裂成多类 |
| 检测到部分路牌而非整体 | 黑色边框分割了连通域 | 把近黑色类别一起归为目标 |
| 路牌框位置严重偏移 | 图像缩放后坐标未映射回原图 | 记录scale系数，绘制时反向计算坐标 |
| 运行时内存飙升 | 输入图像过大未缩放 | 先resize到宽640以内 |
| 结果每次跑都不一样 | attempts太低或随机种子未固定 | 设attempts=5以上，固定RNG状态 |
倒数第二条要单独解释。很多人在原图上直接聚类，1920x1080的图像有207万个像素点，每个样本3维浮点，内存占用约25MB，看起来不大，但OpenCV内部拷贝和迭代过程会额外开几块同样大小的临时缓冲区，实际峰值内存轻松超过200MB。如果程序同时开了Debug模式，内存占用更高，稍大一点的图就会触发断点。缩略图聚类、在原图上绘制框，是内存和安全性的双赢。
6. 效果评估与多场景扩展思路
6.1 多场景实测效果总结
我在三组不同图像上做了测试。第一组是典型的晴天城市场景，路牌清晰、背景以天空和绿化为主，K=4时聚类结果最理想，路牌掩膜完整，误检区域很少。第二组是阴天灰蒙蒙的场景，路牌和天空的蓝都比较灰暗，聚类时容易把天空和路牌并到同一类，导致掩膜包含大片天空区域，此时把K提高到6，并降低V权重，效果明显改善。第三组是含有大量蓝色广告牌的场景，形状筛选阶段出现了几个误检框，靠矩形度阈值调到0.65才抑制住。
整体来说，这套Kmeans颜色聚类方案的准确率依赖场景复杂度。结构化道路场景下检测率比较高，目标区域占画面比例大于2%时基本稳定；目标很小或者背景颜色与路牌高度相似时，需要靠调参来找平衡，这也是所有传统CV方案的共性限制。
6.2 后续可以扩展的优化方向
如果是在课程设计基础上继续深入，有几个方向值得尝试：
把K值选择变成自适应。用轮廓系数或者肘部法则在运行时评估最佳K值，代替人工设定。OpenCV没有现成的评价函数，但可以在kmeans跑完以后计算各类内距离和类间距离，做一个简单的有效性指标。
加入形态学先验。矩形路牌可以利用直线检测或者角点检测进一步验证，比如cv::HoughLinesP检测边缘长直线，结合外接矩形的四个角点做透视矫正。这样即使是倾斜拍摄的路牌也能准确框出轮廓。
级联分类器或模板匹配。如果项目允许引入一点监督信息，可以用少量路牌模板做模板匹配，或者用HOG特征加SVM做形状验证，把候选区域二次判别，误检率能再降一个量级。
最后的个人心得是：这类基于颜色聚类的检测程序，不要把全部赌注押在聚类算法本身上。真正决定项目质量的是聚类的输入特征设计、后续的形状验证逻辑，以及针对特殊场景的参数调整策略。把Kmeans当作第一步分割器，后面跟上一堆轻量级的验证手段，这套组合在传统CV项目里设计得好的话，效果不比简单训练的深度学习模型差多少。如果你正在做类似的路牌检测或者颜色分割项目，建议先把本文第3节的代码完整跑通，再针对自己手头的场景调K值和筛选阈值，整个调参过程会比从零开始写要顺利得多。
