简介：面向使用VS2008、OpenCV与MFC进行图像处理入门实践的开发者，这份工程资料围绕米粒计数这一典型场景，演示如何完成图像读取、目标分割、数量统计，并进一步计算最大米粒的面积与周长，适合课程设计、实验课和计算机视觉初学者参考。压缩包共29个文件，约9.42MB，包含C++源码与头文件、MFC工程及解决方案、可执行程序、测试图片和说明文档等，便于直接打开工程对照学习与复现实验。现有1113人学习下载。资料还保留了LPCTSTR与const char*转换、字符集设置及Debug/Release编译差异的排错线索，能帮助读者理解UNICODE与多字节环境下的常见配置问题。借助完整工程结构与示例图像，读者可快速定位MFC界面、OpenCV处理逻辑和结果展示之间的关系，并在此基础上扩展面积、周长统计或改进分割流程。
1. 米粒计数的老工程：VS2008 + OpenCV + MFC 到底解决什么问题
一批米样倒在灯箱上，任务就三句话：数清有多少粒、找出最大的那一粒、报出它的面积和周长。手工数到第三盘基本就废了，眼睛花、数重、还容易把碎米漏掉。这个基于 VS2008 + OpenCV + MFC 的米粒计数工程，干的就是把这三件事自动化：读一张米粒图片，走一遍灰度化、二值化、形态学滤波、轮廓提取，对话框上直接给出总粒数、最大米粒的面积（像素平方）和周长（像素），并把最大那一颗用矩形框标出来。
它适合两类人。一类是图像处理刚入门、想找一个能从 UI 到算法完整跑通的轮廓计数 demo 的在校开发者；另一类是手上还压着 VS2008 老工程、需要把 OpenCV 塞进 MFC 做检测的维护岗。它不做品种识别、不做瑕疵分级，只做几何量统计，代码量小、链路短，拿来当模板改的成本很低。
2. 工程结构与运行环境：让 OpenCV 在 VS2008 里和 MFC 握上手
这个工程最容易卡住的不是算法，是环境。VS2008 默认的平台工具集、运行库、字符集，和你在网上随手下载的一份 OpenCV 预编译库之间，经常对不上号。所以先把工程骨架摸清楚，再动手配路径，能省掉一半的编译错误。
2.1 目录与文件清单
一个典型的单文档对话框式结构长这样，核心逻辑集中在一个对话框类里，没有多余的分层：
RiceCount/ ├── RiceCount.sln // VS2008 解决方案 ├── RiceCount/ │ ├── RiceCount.h / .cpp // CWinApp 派生类，程序入口 │ ├── RiceCountDlg.h / .cpp // 主对话框，按钮响应 + 算法调用 + 结果回显 │ ├── CvvImage.h / .cpp // OpenCV 图像绘制到 MFC 设备上下文的封装 │ ├── stdafx.h / .cpp // 预编译头 │ ├── resource.h │ └── res/ │ └── RiceCount.ico ├── testdata/ │ └── rice01.bmp // 测试图，浅色背景 + 深色米粒 └── opencv/ // 按需放置，或使用系统环境变量对话框上一般只放四个控件：一个CStatic做图像显示区，一个「打开图片」按钮，一个「计算」按钮，一个多行只读CEdit或者几个CStatic用来显示粒数、最大面积、最大周长。资源 ID 按默认的IDC_STATIC_IMG、IDC_BTN_OPEN、IDC_BTN_CALC、IDC_EDIT_RESULT命名即可，不要在图省事全用IDC_STATIC1这种，后期加控件会乱。
CvvImage这个文件要单独说一句：它是 OpenCV 1.x 时代自带的 MFC 图像显示封装，2.x 之后被移除了。老工程里它通常是从旧版本源码里抠出来放进项目的，如果你手头的 OpenCV 版本里没有，要么补这两个文件，要么改用StretchDIBits自己画。血泪经验是后者更稳，因为CvvImage在不同版本的头文件依赖上会打架。
2.2 工程属性配置：三个地方必须对齐
打开「项目属性」，注意 VS2008 的配置管理器里 Debug 和 Release 是分开的，改完一个要切到另一个再改一遍，否则会出现「Debug 能跑、Release 链接报错」这种让人怀疑人生的情况。
第一处是 C/C++ 的附加包含目录，指向 OpenCV 的include目录，注意要写到opencv这一层，因为代码里通常写的是#include "cv.h"、#include "highgui.h"：
C/C++ -> 常规 -> 附加包含目录 <OpenCV根目录>\include\opencv第二处是链接器的附加库目录，指向lib目录：
链接器 -> 常规 -> 附加库目录 <OpenCV根目录>\lib第三处是附加依赖项。Debug 配*d.lib，Release 配不带d的版本，这是最容易翻车的点之一，混用会在链接阶段报一堆LNK2005重复定义：
链接器 -> 输入 -> 附加依赖项（Debug） cxcore200d.lib cv200d.lib highgui200d.lib ml200d.lib cvaux200d.lib 链接器 -> 输入 -> 附加依赖项（Release） cxcore200.lib cv200.lib highgui200.lib ml200.lib cvaux200.lib版本号按你实际安装的来，不要照抄。库名不对，链接器会直接告诉你「无法打开输入文件」，这个错误信息很明确，照着改就行。真正隐蔽的是平台不匹配：VS2008 新建工程默认是 Win32，如果你的 OpenCV 库是 64 位的，链接阶段会报「模块计算机类型 x86 与目标计算机类型 x64 冲突」。解决方式只有两条路——要么把解决方案平台切到 x64，要么换一份 32 位库，别试图用「忽略默认库」去绕，绕不过去。
2.3 从零跑起来的三步
第一步，拷一张测试图到testdata下，格式建议用 BMP。BMP 没有压缩、没有色彩管理，读进来是什么就是什么，调参数的时候不会因为解码差异怀疑自己。
第二步，把图像路径写死在「打开图片」按钮的响应函数里先跑通，别一上来就挂CFileDialog。老工程里cvLoadImage对中文路径是直接返回 NULL 的，先用纯英文短路径验证算法链路，再回头处理路径问题，能少走很多弯路。
第三步，在「计算」按钮的响应函数里下断点，观察cvFindContours返回的轮廓数量。这个数字如果等于 0，问题一定在二值化；如果远大于目测粒数，问题一定在噪声或粘连。这两类问题在后面的章节里都会展开。
提示：VS2008 调试时如果
cvLoadImage返回空指针，先确认路径；路径没问题就看工作目录。VS 默认的工作目录是工程目录，不是testdata，写相对路径时容易对不上。
3. 图像预处理链路：从彩色原图到能数轮廓的黑白图
预处理决定了后面计数的上限。轮廓算法本身没什么可调的，cvFindContours就是个连通域追踪，输入什么样它就给什么样。所以真正要花时间的，是把米粒和背景分开、把粘连和孔洞处理掉。
3.1 读取与灰度化
读图和灰度化是标准动作，这里用 OpenCV 的 C 接口，因为老工程里 C++ 接口的cv::Mat和 MFC 的混用会带来额外的头文件顺序问题：
// 打开并转为灰度图，src 保持彩色用于最后叠加标注 IplImage* src = cvLoadImage("testdata/rice01.bmp", CV_LOAD_IMAGE_COLOR); if (src == NULL) { AfxMessageBox(_T("图像读取失败，检查路径是否为中文")); return; } IplImage* gray = cvCreateImage(cvGetSize(src), IPL_DEPTH_8U, 1); cvCvtColor(src, gray, CV_BGR2GRAY); // BGR 顺序，不是 RGBCV_LOAD_IMAGE_COLOR强制三通道，即使原图是灰度图也会被展开成三通道，这样后面的cvCvtColor不会因为通道数不匹配断言失败。IPL_DEPTH_8U是 8 位无符号，像素取值 0～255，这是绝大多数阈值操作的前提，别改成IPL_DEPTH_32F，cvThreshold的 Otsu 模式对浮点图支持不好。
如果米粒是深色、背景是浅色（这是灯箱拍摄的常见情况），灰度化之后米粒的像素值低、背景高。这时候直接做二值化会得到「背景白、米粒黑」的图，轮廓算法会把背景当成一个大连通域。处理办法有两个：在阈值类型里加CV_THRESH_BINARY_INV做反色，或者二值化后用cvNot整体取反。我一般用前者，少一次内存拷贝。
3.2 Otsu 自动阈值二值化
固定阈值是最容易翻车的做法。同一批米，灯箱亮度差一点、相机曝光差一档，固定阈值 100 就可能把米粒吃掉一半或者把阴影全算成米粒。用 Otsu 让算法自己找分割点：
IplImage* bin = cvCreateImage(cvGetSize(gray), IPL_DEPTH_8U, 1); // 阈值传 0，Otsu 会自动计算；INV 让米粒变白（前景 255）、背景变黑 double thresh = cvThreshold(gray, bin, 0, 255, CV_THRESH_BINARY_INV | CV_THRESH_OTSU); TRACE(_T("Otsu 自动阈值 = %.1f\n"), thresh);cvThreshold的返回值就是它算出来的阈值，把它TRACE出来很有用：如果这个值跑到 20 以下或者 230 以上，说明图像对比度极低，八成是拍糊了或者光照严重不均，这时候不管后面怎么调都是白费劲。正常米粒图的 Otsu 阈值一般落在 80～160 之间，具体取决于背景亮度。
这一步之后建议直接cvSaveImage把bin存一张出来看。很多「计数不准」的问题，看一眼二值图就明白了——边缘毛刺、米粒中间有黑洞、两粒米连成一片，全在这张图上。
3.3 形态学开运算与孔洞填充
二值图上的噪声主要有两类：背景上的零星白点（灰尘、反光），和米粒内部的黑色孔洞（胚芽凹陷、米粒裂纹）。前者会把计数抬高，后者不影响计数但会让面积偏小。
开运算先腐蚀后膨胀，专门吃掉小噪点：
// 3x3 椭圆核，比矩形核更贴合米粒的圆润边缘 IplConvKernel* kernel = cvCreateStructuringElementEx( 3, 3, 1, 1, CV_SHAPE_ELLIPSE, NULL); IplImage* opened = cvCloneImage(bin); cvMorphologyEx(bin, opened, NULL, kernel, CV_MOP_OPEN, 1);cvCreateStructuringElementEx的五个参数分别是宽、高、锚点 x、锚点 y、形状。3×3 的核对米粒这种尺寸（一张普通分辨率图里单粒米大概 200～800 像素面积）是合适的，核再大会把粘连米粒之间的细连接也腐蚀断，反而制造出假轮廓。CV_MOP_OPEN只做一次就够，迭代次数多了会把小米粒整个抹掉。
孔洞填充用闭运算，或者更直接的办法是轮廓提取时用CV_RETR_EXTERNAL只取外轮廓，内部孔洞自然被忽略。这里我倾向后者，少一次形态学运算，速度也快一些。但如果米粒中间的大孔洞把轮廓切成了环形，外轮廓的面积会把孔洞也算进去，这时候就得先填洞再提取。填洞的土办法是cvFloodFill从图像角点泛洪，或者用轮廓的层级关系判断——对米粒这个场景，闭运算已经够用。
3.4 边界处理与图像边框
还有一个容易被忽略的点：如果米粒贴到了图像边缘，它的轮廓会被图像边界截断，面积算出来偏小，最大米粒的判定就可能出错。
常见做法是在预处理阶段给图像加一圈黑边，物理上把米粒和边界隔开：
// 四周各扩 10 像素黑边，避免贴边米粒轮廓被截断 CvRect roi = cvRect(10, 10, src->width, src->height); IplImage* padded = cvCreateImage( cvSize(src->width + 20, src->height + 20), IPL_DEPTH_8U, 1); cvZero(padded); // 全部置 0（黑） cvSetImageROI(padded, roi); cvCopy(opened, padded); // 把二值图拷进 ROI cvResetImageROI(padded);cvSetImageROI设定感兴趣区域后，cvCopy只作用于这块区域，坐标原点仍在整图左上角。用完必须cvResetImageROI，否则后续的绘制和显示会在错误的位置上。加边之后，贴边的米粒就变成了完整轮廓，代价是遍历时要跳过那些面积等于全图面积的外框轮廓——加边本身是黑的，不会产生轮廓，所以一般不用额外处理，但如果加边时手滑用了白色填充，就会多出一个整图大小的轮廓，把「最大米粒」直接顶掉，这种错误排查起来很费时间。
存一张处理完的二值图出来对比，是这条链路上性价比最高的调试手段。
4. 核心算法：轮廓提取、面积周长与最大米粒定位
预处理产出的是一张干净的黑白图，接下来就是数数。这一段的代码不长，但有两个内存细节和三个参数容易被忽略，写错一处结果就全乱。
4.1 cvFindContours 的调用方式与内存管理
cvFindContours会直接修改输入图像，这是它最反直觉的地方。如果你后面还要拿这张二值图做显示或者再算一遍，必须先克隆：
IplImage* contourSrc = cvCloneImage(padded); // 防止原二值图被改写 CvMemStorage* storage = cvCreateMemStorage(0); CvSeq* contours = NULL; // CV_RETR_EXTERNAL 只取最外层轮廓；CV_CHAIN_APPROX_SIMPLE 压缩水平/垂直/斜向的冗余点 int rawCount = cvFindContours(contourSrc, storage, &contours, sizeof(CvContour), CV_RETR_EXTERNAL, CV_CHAIN_APPROX_SIMPLE, cvPoint(0, 0));CV_RETR_EXTERNAL只返回最外层轮廓，正好对应「一粒米一个外轮廓」的需求，米粒内部的孔洞不会被当成独立目标。CV_CHAIN_APPROX_SIMPLE会把同一条直线上的中间点压掉，只保留拐点，周长计算的精度不受影响，但遍历的点数少很多。
CvMemStorage是所有轮廓点的内存池，函数返回的CvSeq指针指向这个池子。它不会自动释放，如果你的程序支持连续处理多张图（比如批量统计），每处理一张就必须cvReleaseMemStorage(&storage)并把contours置空，否则内存会一路涨上去，跑几十张图之后程序就卡死。这是我在类似工程里踩过的最典型的一个坑，现象是「前几张正常、后面越来越慢、最后无响应」，跟算法一点关系都没有。
还有一个隐藏问题：cvFindContours返回的整数是轮廓总数，但它统计的是所有层级；用CV_RETR_EXTERNAL时这个数和实际遍历h_next得到的数是一致的，用CV_RETR_TREE时就不一定了。所以计数以遍历结果为准，不要直接拿返回值当粒数。
4.2 面积与周长：单位、精度与筛选
遍历轮廓用h_next横向链表，每一个节点就是一个候选米粒：
int grainCount = 0; double maxArea = 0.0, maxPerimeter = 0.0; CvRect maxRect = cvRect(0, 0, 0, 0); for (CvSeq* c = contours; c != NULL; c = c->h_next) { // CV_WHOLE_SEQ 表示整条序列；面积取绝对值防止方向导致负值 double area = fabs(cvContourArea(c, CV_WHOLE_SEQ)); // 面积过小的当成噪点丢弃，阈值按单粒米的像素面积下限取 if (area < 100.0) { continue; } // 周长：第三个参数 closed=1 表示轮廓闭合，米粒必须闭合 double perimeter = cvArcLength(c, CV_WHOLE_SEQ, 1); grainCount++; if (area > maxArea) { maxArea = area; maxPerimeter = perimeter; maxRect = cvBoundingRect(c, 0); // 外接矩形，用于最后画框 } }几个参数要说明白。cvContourArea的第二个参数是序列范围，CV_WHOLE_SEQ表示整条轮廓；有些老代码写CV_WHOLE_SEQ_END_INDEX，效果一样但可读性差。返回值带了符号，取决于轮廓点是顺时针还是逆时针，所以必须fabs，不加绝对值会出现「面积为负、最大米粒判定失效」的玄学现象。
cvArcLength的第三个参数closed一定要传 1。传 0 的话它不计算首尾闭合那一段，周长会偏小，而且偏小的比例跟轮廓点数有关——点数越多偏得越少，于是出现「大米的周长误差小、小米的误差大」这种看起来毫无规律的结果。
面积筛选阈值 100 是个经验值，取决于你的图像分辨率和拍摄距离。判断方法很简单：把图放大了目测一粒米大概占多少像素，面积差不多是外接矩形面积的 0.7 倍。如果阈值设得太高，碎米会被漏掉；设得太低，二值化残留的噪点会被算成米粒。这个值在实际工程里必须可配，写死在代码里换一批样本就得重编译，这是后一章要改造的地方。
4.3 结果回显与最大米粒标注
算完之后要把结果画回彩色原图，再显示到 MFC 的CStatic上：
// 在原图上画出最大米粒的外接矩形，绿色，线宽 2 cvRectangle(src, cvPoint(maxRect.x, maxRect.y), cvPoint(maxRect.x + maxRect.width, maxRect.y + maxRect.height), CV_RGB(0, 255, 0), 2, 8, 0); // 结果拼成一段文本，一次性刷到编辑框 CString msg; msg.Format(_T("米粒总数：%d 粒\r\n最大米粒面积：%.1f 像素²\r\n最大米粒周长：%.1f 像素"), grainCount, maxArea, maxPerimeter); SetDlgItemText(IDC_EDIT_RESULT, msg);cvRectangle的线宽参数之后那几个参数是新版本才有的，老版本签名更短，编译报「参数过多」就说明你的头文件和库版本对不上，减掉后面的参数即可。CV_RGB是宏，顺序是 R、G、B，和cvCvtColor的CV_BGR2GRAY顺序不同，这里容易记混，画出来颜色不对先查这个。
显示到控件上时，直接用CvvImage::DrawToHDC把图像画到CStatic的矩形里。如果控件尺寸和图像尺寸不一致，会拉伸变形，看起来米粒被压扁了。稳妥的做法是按控件大小等比缩放一份副本再画，原始图像数据不动，因为面积周长是基于原图坐标算的，缩放后的图像只用于显示。
// 等比缩放到控件大小后绘制，避免拉伸 CRect rc; GetDlgItem(IDC_STATIC_IMG)->GetClientRect(&rc); CvvImage img; img.CopyOf(src); img.DrawToHDC(pDC->GetSafeHdc(), &rc);结果里的「像素²」和「像素」必须在界面上写清楚。很多人拿到这个工程后直接把面积当成平方毫米用，差了标定系数，报出去的数字没有物理意义。要换成实际单位，得在拍摄时放一枚已知尺寸的参照物，算出每像素对应多少毫米，面积系数是这个值的平方。这一步不在原始需求里，但二次开发时基本都会提。
5. 避坑与排查：这类老工程最容易翻车的五个地方
5.1 编译链接阶段：库对不上导致的连环报错
现象：工程能编译，链接阶段报一堆LNK2005重复定义，或者LNK2019无法解析的外部符号，符号名里带着cv前缀。
原因：Debug 配置里混进了 Release 版的库，或者cxcore、cv、highgui三个库的版本号不一致。OpenCV 不同小版本之间的 ABI 不完全兼容，混着用链接器就会找不到对应实现。另一个常见原因是运行时库设置不一致——工程用了「多线程调试 DLL」，而库是按「多线程」编译的，也会报重复定义。
解决：把附加依赖项按 Debug/Release 两套完整配好，别只改一个。改完执行一次「生成 → 清理解决方案」，再重新生成，因为 VS2008 的增量编译有时不会重新链接。运行时库在 C/C++ → 代码生成里统一改成「多线程调试 DLL (/MDd)」，和预编译库对齐。
5.2 图像读取阶段：路径正确但返回空指针
现象：cvLoadImage返回 NULL，AfxMessageBox弹出来说读取失败，但路径在资源管理器里复制粘贴过去是能打开的。
原因：中文路径。OpenCV 这版读图接口内部走的是窄字符 API，遇到非 ASCII 路径直接失败，不报错，只返回空。另一个原因是相对路径的基准目录不是你以为的那个——VS2008 调试时的工作目录默认是工程目录，而你把图放在了testdata子目录里。
解决：调试阶段一律用绝对路径的英文目录，确认算法通了再处理路径问题。真要支持中文路径，改成用CFile读二进制流，再用cvDecodeImage解码，绕开文件名 API。或者最土的办法：读之前把文件拷到临时目录并重命名为纯英文，处理完再删掉。
5.3 计数结果阶段：粒数明显偏少
现象：图里目测 60 多粒，程序报 40 出头。
原因：米粒粘连。两粒米挨在一起，二值化之后连成一个连通域，CV_RETR_EXTERNAL只会给它一个外轮廓，计数自然少。开运算的核再大一点会加剧这个问题，因为腐蚀会把细连接断开又让轮廓合并得更彻底。
解决：先确认是不是粘连——把二值图存出来看，如果能看到明显的「哑铃形」连通域，就是这个问题。轻度的用距离变换加分水岭分离，重度的要调整拍摄方式，让米粒单层平铺、互不接触。还有一个务实的补丁：统计所有轮廓的面积中位数，把面积超过中位数 1.8 倍的轮廓按倍数拆分计数，精度不高但实现成本极低，适合样本稳定的场景。
5.4 计数结果阶段：粒数明显偏多
现象：目测 50 粒，程序报 70 多。
原因：二值化把背景上的反光点、灰尘、灯箱接缝算成了前景，或者米粒边缘的毛刺在轮廓追踪时被拆成了两个轮廓。还有一种情况是米粒中间的深色裂纹把一粒米切成了两半。
解决：先看二值图。反光点多就加大开运算的核或者先做一次高斯模糊（cvSmooth用CV_GAUSSIAN，3×3 就够）。毛刺多就在轮廓筛选里加周长面积比约束——正常米粒的周长平方除以面积大概在 15～25 之间，明显超出这个范围的是噪声。裂纹导致的断裂只能用闭运算先把米粒「焊」回去，核的大小要试，试到二值图上没有断裂为止。
5.5 运行稳定性：处理几十张图后卡死
现象：单张图正常，连续点「计算」按钮二三十次之后界面无响应，任务管理器里内存一路涨。
原因：CvMemStorage、IplImage都没释放。每次点按钮都cvCreateImage和cvCreateMemStorage，但函数退出时没有对应的cvReleaseImage和cvReleaseMemStorage。OpenCV 的 C 接口不会自动回收，全靠手工。
解决：把每次计算的临时图像和内存池集中在一处释放，用goto或者do { } while(0)包一层，保证任何分支退出前都走到释放逻辑。更稳的写法是把这些资源封成一个小的 RAII 结构体，析构时统一释放，这样即使中间return也不会漏。改完之后连续点一百次，内存曲线应该是平的。
注意：调试版和发布版的轮廓数偶尔不一致，先别怀疑算法。多数情况下是二值化阈值因为浮点精度或优化级别产生了微小差异，导致某个临界噪声点被算了进去。把面积筛选的下限抬高一点，这种抖动就消失了。
6. 二次开发：把写死的参数变成可调，再补一套验证方法
拿到这个工程之后，第一件该做的事不是加功能，是把硬编码的参数抽出来。面积筛选阈值、形态学核大小、Otsu 是否启用，这三个参数决定了 90% 的结果差异，每次都改代码重编译，效率太低。
我一般的做法是在对话框上加三个控件：一个CSliderCtrl控面积下限（范围 20～2000），一个CComboBox选核大小（3×3、5×5、7×7），一个CCheckBox切换固定阈值和 Otsu。参数一变就重算，界面上立刻能看到粒数和标注框跟着动，调参从半小时缩短到半分钟。
// 从界面控件读取参数，替换原来写死的常量 int minArea = m_sliderArea.GetPos(); // 面积下限，实时可调 int ksize = m_comboKernel.GetCurSel() * 2 + 3; // 3 / 5 / 7 bool useOtsu = (m_checkOtsu.GetCheck() == BST_CHECKED); IplConvKernel* k = cvCreateStructuringElementEx( ksize, ksize, ksize / 2, ksize / 2, CV_SHAPE_ELLIPSE, NULL); // Otsu 与固定阈值走不同分支，固定阈值给一个手动输入框 double th = useOtsu ? cvThreshold(gray, bin, 0, 255, CV_THRESH_BINARY_INV | CV_THRESH_OTSU) : cvThreshold(gray, bin, m_nFixedThresh, 255, CV_THRESH_BINARY_INV);参数联动之后，验证方法也得跟上。我习惯准备三张图：一张标准样本（米粒互不接触、光照均匀），一张粘连样本，一张有灰尘噪声的样本。每次改完参数，三张图的期望结果写在一张纸上——标准样本要求误差在 ±2 粒以内，粘连样本允许偏低但不能低于目测数的 80%，噪声样本要求不出现明显虚高。这套基准跑下来，改动是不是真的变好，一目了然。
如果要往实用方向走，还有两处值得补。一是物理单位换算：在拍摄时放一枚已知直径的参照物，程序里框选参照物算出像素/毫米比例，面积和周长就能输出成平方毫米和毫米，这个改动不大但让结果有了工程意义。二是批量处理：把「打开单张」扩成「选择文件夹」，循环读图、循环计算、结果导出成 CSV，这时候前面说的内存释放就必须做扎实，否则跑几十张就卡死。
有一次我图省事，把面积阈值直接写成了 500，因为手头那批样本的米粒都比较大。换了一批碎米率高的样本之后，程序报出来只有个位数，我还以为是二值化出了问题，查了两个小时才发现是阈值把大部分米粒都筛掉了。从那以后我每次加任何硬编码的数值参数，都强制在界面上留一个可调的入口，哪怕只是个临时的输入框，也绝不直接写死在算法里。希望这个习惯也能帮到你。
本文还有配套的精品资源，点击获取
