简介LCD坏点检测程序是一份面向显示器质检人员、维修工程师及数码产品用户的实用工具源码包用于快速甄别液晶屏上的亮点、暗点和色点帮助评估屏幕质量、辅助验机或故障排查。压缩包内共28个文件整体约72KB以C源码cpp/h为核心包括LCDDlg.cpp、ButtonBT.cpp等界面与逻辑实现并附带工程配置文件vcl/vcw/vcp及多枚ico图标资源结构清晰方便在Visual Studio等环境中重建与二次开发。已有123人学习/下载。程序通过循环显示纯红、纯绿、纯蓝及黑白等测试画面激发每个像素的不同状态用户可据此观察是否存在颜色异常或不发光像素尤其适合新购设备验收、二手屏幕翻检以及维修后的显示效果验证。资源本身包含ReadMe说明与完整C工程开发者还可深入阅读源码理解坏点检测原理并扩展自定义测试模式实用性和可读性俱佳。1. 坏点检测是显示器验收的底线拿到一台新显示器或者给嵌入式设备换上一块新的LCD屏第一件事不是看色彩是否艳丽而是关掉灯光、把屏幕调成纯黑然后凑近找有没有不正常发光的亮点。很多面板在出厂时就有坏点只是普通使用场景下很难察觉。等你看视频、写代码时发现一个小亮点在屏幕中央跳再想去售后换货对方可能以“坏点数量未超标”为由拒收。这台LCD.rar里的测试程序就是用来提前做这道验收工序的。它不是一个驱动也不是一个展示Demo而是一个很纯粹的像素检测工具让LCD依次显示纯红、纯绿、纯蓝、黑、白等颜色让每一个子像素的状态被单独激发出来。无论你是做硬件维护的还是搞嵌入式开发的都应该装一份。2. 从液晶偏转到纯色扫屏LCD坏点测试的原理与程序设计2.1 坏点为什么会出现LCD面板中的每个像素由红、绿、蓝三个子像素构成每个子像素背后的薄膜晶体管TFT控制液晶分子的偏转角度从而决定光线穿透的程度。坏点本质上是某些子像素的TFT或液晶阵列在工作时失去了可控性。亮点是晶体管短路电流一直通过子像素永远处于最大透光暗点则是断路子像素永远关闭色点则是其中一两个子像素失控导致该像素只能显示非正常的混色。生产过程中的尘埃污染、光刻偏移、材料缺陷都会在阵列阶段留下这类问题而且坏点不会自行修复只会随着温度、老化而变得更明显。2.2 为什么纯色背景能暴露坏点要检测出失控的子像素就必须让它所在的状态与预期产生最大反差。在全黑画面下正常的亮点会格外扎眼在全白画面下暗点则无处遁形而红绿蓝三色分别扫描能判断具体是哪个子像素故障。这也是测试程序的核心逻辑不是用一张图片而是用一组纯色切换来逐通道激励像素。测试时显示器亮度要调到日常值环境光减弱让眼睛在每种颜色下停留23秒视觉系统才能稳定地捕捉到异常点。2.3 程序实现从MFC对话框到全屏取色在LCD.rar解压后的文件结构中LCDDlg.cpp和ButtonBT.cpp是两个最关键的源码文件。LCDDlg.cpp是主对话框逻辑负责处理全屏切换、颜色序列和消息响应ButtonBT.cpp则是一个自绘按钮类用来在测试界面里绘制可点击的颜色块按钮。典型的设计思路是对话框覆盖整个屏幕背景画刷跟随一个颜色索引动态变化用户单击按钮或按键盘键时索引递增OnPaint重新填充背景。常见的核心代码逻辑如下用于在MFC中实现全屏纯色切换// LCDDlg.cpp 片段 int g_ColorIndex 0; COLORREF g_Colors[] { RGB(0, 0, 0), // 黑色检测亮点 RGB(255, 255, 255), // 白色检测暗点 RGB(255, 0, 0), // 红色 RGB(0, 255, 0), // 绿色 RGB(0, 0, 255), // 蓝色 RGB(128, 128, 128) // 中灰 }; void CLCDDlg::OnLButtonDown(UINT nFlags, CPoint point) { g_ColorIndex (g_ColorIndex 1) % (sizeof(g_Colors) / sizeof(g_Colors[0])); Invalidate(FALSE); // 触发WM_PAINT重绘 CDialog::OnLButtonDown(nFlags, point); } void CLCDDlg::OnPaint() { CPaintDC dc(this); CRect rect; GetClientRect(rect); CBrush brush(g_Colors[g_ColorIndex]); dc.FillRect(rect, brush); }这段代码的逻辑说明如下g_ColorIndex是当前色号点击鼠标左键后索引加一并取模保证颜色循环。Invalidate(FALSE)告诉窗口重绘时保留现有背景避免闪烁。OnPaint里直接拿当前颜色创建画刷填充整个客户区没有任何图片加载所以切换速度非常快能让检测者连续对比几个颜色下的像素状态。参数方面RGB(r,g,b)的取值直接决定了测试色的纯度实际应用中红绿蓝应尽量取255满值灰色则取128用于观察半亮状态下的亮度均匀性。除了鼠标一般还会在OnKeyDown中做空格键响应一键切换颜色。这样测试时不需要低头看按钮视线可以始终停留在屏幕上。核心就是不要让任何UI元素干扰屏幕显示所以真正的测试模式里按钮区通常放在屏幕边缘且没有标题栏。3. 用LCD_TEST程序跑一遍全色域检测流程3.1 解压与编译环境准备LCD.rar解压后能看到LCD.vcb、LCD.VCW、LCD.VCP这类Visual C工程文件还有ARMV4IRel和ARMV4IDbg两个目录说明这套源码同时支持x86桌面环境和ARM4I指令集——后者常用于Windows CE/移动嵌入式设备。在PC上直接用VC6.0或更高版本打开LCD.VCW选择Win32 Release配置编译即可生成可执行文件。如果你的系统是64位Windows建议编译时设置工程为Win32平台否则某些旧版MFC库可能加载异常。若不想编译源码目录里通常也带了Release版本的exe可以直接在Windows 7/10的兼容模式下运行。3.2 测试前的环境调整测试环境直接影响坏点的可见度。屏幕亮度不要开到100%否则部分漏光区域会被误判为坏点建议调整到50%70%Windows显示缩放要设为100%否则GDI填充的窗口可能被拉伸导致颜色边缘发虚其它显示器尽量关闭动态对比度、HDR这类画质增强功能这些功能会改变某些灰阶下的亮度输出让检测结果变得不可靠。操作步骤可以拆成下面几步把桌面分辨率设置为液晶面板的物理分辨率保证像素一一对应。关闭桌面壁纸运行LCD_TEST.exe程序启动后自动进入全屏。先用黑色画面观察1分钟记录所有持续发光的点。切到白色用同样的方法记录所有不亮或偏暗的子像素。依次切到红、绿、蓝分辨每个异常点具体是哪个子像素出了问题。3.3 颜色序列与停留时间参数通常测试程序内置的颜色序列如下表所示表里的停留时间是一个参考值熟练后可以缩短到2秒但第一次检测建议放满3秒颜色切换RGB数值检测目标推荐停留时间黑0,0,0亮点、漏光3秒白255,255,255暗点、灰斑3秒红255,0,0红色子像素失效3秒绿0,255,0绿色子像素失效3秒蓝0,0,255蓝色子像素失效3秒中灰128,128,128颜色不均、残影4秒在纯红画面上如果某个点看起来呈黄色那说明它的蓝色子像素不工作呈青色则说明红色子像素故障呈品红则说明绿色子像素故障。这种判读能直接告诉你坏点的类型而不是笼统的说“屏幕有个点坏了”。3.4 在嵌入式LCD上运行资源里的ARMV4I编译目录是给ARM平台准备的。如果你在开发Windows CE或手持设备可以把这个exe直接拷贝到设备端运行。需要注意嵌入式LCD接口类型如40pin RGB或SPI会影响初始化时序但应用层测试程序只需要访问FrameBuffer因此即便底层驱动不同纯色填充的代码都可以复用。运行前要确保显示驱动已经正确设置分辨率否则FillRect画出来的色块可能只覆盖屏幕的一半区域。碰到这种情况检查注册表里的显示相关的分辨率配置而不是去改测试程序。4. 亮点暗点色点的判据与误判排除4.1 如何准确记录坏点坐标判断一个点是不是坏点要用“至少两种颜色下表现异常”作标准。比如某个点只有在纯蓝下发亮而红绿下正常那它是蓝色子像素的亮点如果某点在白屏下发暗同时蓝屏下发黄那就说明它至少有两个子像素存在故障。记录时不要用“左上角偏右一点”这种模糊描述应该用坐标。经典的做法是在程序中使用透明十字线或者用一张带刻度网格的截图来做定位。你也可以写一个小工具在测试结束后叠加一层带有横纵坐标的透明窗把鼠标指向异常点时状态栏显示当前像素的X/Y值。在MFC中GetCursorPos()配合ScreenToClient()就能实现。// 获取异常像素坐标 void CLCDDlg::OnMouseMove(UINT nFlags, CPoint point) { CPoint pt point; // 相对客户区坐标 CString str; str.Format(_T(X: %d, Y: %d), pt.x, pt.y); SetWindowText(str); // 临时显示在标题栏 CDialog::OnMouseMove(nFlags, point); }这里point是鼠标在客户区中的像素坐标也就是屏幕上的物理像素坐标在全屏模式下无坐标偏移。标题栏显示坐标的好处是不干扰检测画面而且你随时可以把鼠标移到坏点处读取数值。注意全屏模式下如果隐藏了标题栏你可能需要用TextOut在屏幕角落绘制坐标这时要保证字体大小适当不要覆盖太多显示区域。4.2 常见误判灰尘、水波纹和漏光很多新手会把背光模组的灰尘当成坏点尤其是黑屏下看到的白色小颗粒和亮点非常相似。最简单的区分办法是切换一帧颜色后观察该点是否保持同样的亮度和颜色。灰尘在红绿蓝三种屏幕色下通常都呈现白色或透明而真正的坏点会随背景色改变表现亮点永远亮暗点永远暗色点会有固定的颜色偏向。另一个容易误判的是面板边缘的漏光这在深色环境下尤其明显但漏光区域通常呈块状或条状不像坏点那样是尖锐的像素点用四倍放大镜一看就能分辨。4.3 测试程序卡在某种颜色时怎么办如果程序在切换颜色时卡住或者某个颜色没有充满整个屏幕大概率不是面板问题而是程序自身对颜色的处理出了问题。检查g_Colors[]数组中RGB参数是否有超出255的值或者有无符号整数溢出。在嵌入式平台上某些驱动对RGB565格式支持不好而程序里的RGB()宏生成的是32位COLORREF传给驱动后需要转换为16位色比如((r3)11) | ((g2)5) | (b3)转换错误会导致蓝屏和绿屏显示相同颜色。遇到这种情况不要急着怀疑面板先看驱动接口是不是RGB888如果只有RGB666那就手动裁剪低位数据。4.4 批量化检测多台屏幕对于维修站或质检部门一台台点鼠标切换颜色效率太低。一个实用的思路是用消息注入的方式自动化程序启动后默认全屏然后用SendMessage向测试窗口发送WM_LBUTTONDOWN模拟鼠标点击来触发颜色切换。你可以用一个简单的批处理脚本配合一个小工具每3秒发送一次点击让每一台被测屏幕按固定节奏自动跑完整个色序。这样做虽然简单但能解放双手而且时间间隔一致不会因为人眼疲劳降低检出率。5. 自定义测试模式与自动记录坏点坐标5.1 把颜色序列改成可配置的数组内置的六种颜色只覆盖了基础检测场景如果碰到特殊面板比如雾面屏需要观测斜视角度下的颜色偏移或者你想检测屏幕在低灰阶下的色阶断层就要自定义颜色序列。实践中最方便的做法是把g_Colors[]数组改成可从外部读取的配置程序启动时读取同目录下的colors.txt每行一个RGB三元组格式如下0,0,0 255,255,255 255,0,0 0,255,0 0,0,255 32,32,32 64,64,64 192,192,192然后修改初始化代码把文件里的数值按行解析成COLORREF。主循环逻辑完全不用改只要g_ColorCount随读取行数变化即可。这样想测灰阶过渡就能把色阶步长设为16想测暗部细节就加入几个低亮度色块。5.2 用脚本控制切换间隔并记录结果如果想把整个检测过程自动化并且把疑似坏点的坐标写入日志可以写一个简单的C线程来做这件事程序进入测试模式后每隔N秒自动切换颜色并把当前屏幕长宽记录下来。关键在于如何捕获鼠标标记的坏点坐标。常见方案是检测人员在发现坏点时按下R键记录红色子像素故障按下G键记录绿色按下B键记录蓝色程序把当时的鼠标坐标和对应标记写入CSV文件。最终你得到一份类似下面的记录X,Y,Type 1280,342,blue_subpixel_stuck 256,768,green_subpixel_dead这样就不需要人工把每个点记在纸上也可以在测试结束后直接打开CSV对照坐标在屏幕上复查。注意在录制坐标时必须确保当前屏幕分辨率没有改变否则坐标会和实际像素位置产生偏移。5.3 让程序在测试完成后自动退出最后给生产环境用的一个技巧程序可以通过命令行参数/auto进入无人值守模式依次显示完所有颜色后自动关闭并在目录下生成一份result.txt里面记录是否有按键事件发生。生产线上其实就是用这个模式把设备放上治具跑完一轮看日志里有没有坐标记录有则送到维修台没有则流入下一道工序。这种用法把坏点检测从一个需要人紧盯的操作变成了一个可量化、可追溯的质检步骤维护成本很低比用专业测试仪器便宜得多也足够发现绝大多数明显的阵列缺陷。本文还有配套的精品资源点击获取