1. 从内存到屏幕为什么Mat图不能直接扔给CDC做过图像处理的朋友大概率都经历过这个场景用OpenCV吭哧吭哧算完一张图cv::Mat里数据整整齐齐结果一到界面上就犯难——怎么把它显示到Windows窗口里尤其是用MFC或者Win32 API写界面的项目手里握着的是CDC设备上下文而OpenCV给的是Mat两者之间隔着一道看不见的墙。这道墙的本质是两套完全不同的图像内存组织方式。Mat是OpenCV自己的矩阵容器它的数据布局、通道顺序、行对齐规则都是OpenCV说了算而CDC背后是Windows GDI那一套它期望的是DIB设备无关位图格式的数据。你直接把Mat的data指针丢给GDI函数轻则花屏重则程序直接崩掉。这不是危言耸听我见过太多人在这一步栽跟头。这篇文章就是要把这道墙拆掉。我会从Mat的内存布局讲起说清楚它和Windows位图之间的差异到底在哪然后给出几种从简单到实用的转换方案重点讲StretchDIBits这条最常用的路子也会聊聊性能优化和那些文档里不会写的坑。不管你是刚接触OpenCV和MFC的新手还是已经写过几版显示代码但总觉得不够稳的老手应该都能从里面找到点有用的东西。先说清楚适用场景你用的是Windows平台界面层是MFC的CDC或者Win32的HDC图像数据来自OpenCV的cv::Mat目标是把Mat的内容正确、高效地画到窗口上。如果你用的是Qt或者其他跨平台框架思路类似但API不同本文不展开。2. Mat的内存布局与GDI位图的格式差异2.1 Mat不只是一块连续内存那么简单很多人以为Mat就是一块连续的像素缓冲区mat.data指向首地址mat.total() * mat.elemSize()就是总字节数。这个理解在大多数情况下没错但它掩盖了几个关键细节而这些细节恰恰是显示出问题的根源。第一个细节是行步长step。Mat的每一行在内存里不一定是紧挨着的。OpenCV出于SIMD对齐的考虑会给每行末尾补一些填充字节让行宽对齐到某个边界通常是4字节或更多。也就是说第0行结束到第1行开始之间可能有几个字节的间隙。mat.step表示的是每行占用的实际字节数含填充而mat.cols * mat.elemSize()只是有效像素的字节数。这两个值在图像宽度不是对齐边界整数倍的时候会不一样。第二个细节是通道顺序。OpenCV默认用BGR顺序存储彩色图像而Windows GDI的24位或32位DIB用的是BGR对于24位或者BGRA对于32位。这一点上两者其实是一致的所以颜色不会反。但如果你用的是RGB顺序的Mat比如从某些相机SDK直接拿到的数据直接显示就会红蓝颠倒。第三个细节是数据类型。Mat可以是CV_8U、CV_16U、CV_32F等等。GDI能直接显示的只有8位无符号整型。如果你手里是浮点Mat或者16位Mat必须先转换到8位否则显示出来必然是一团糟。2.2 GDI期望的DIB长什么样Windows GDI显示图像的核心函数是StretchDIBits或者SetDIBitsToDevice它们都要求一个BITMAPINFO结构加一个像素数据指针。BITMAPINFO里最关键的是bmiHeader它描述了图像的宽、高、位深、压缩方式等信息。这里有几个容易踩的点。第一biHeight可以是正数也可以是负数。正数表示图像是自下而上存储的bottom-up也就是第一行数据是图像的最下面一行负数表示自上而下top-down。OpenCV的Mat是自上而下的所以你应该把biHeight设成负数这样GDI就知道第一行是顶部。如果你设成正数图像会上下颠倒。第二biBitCount要和你提供的数据匹配。24表示每像素3字节32表示每像素4字节。用32位有个好处行对齐天然满足因为每行字节数永远是4的倍数不需要额外处理填充。用24位的话如果图像宽度不是4的倍数每行末尾需要补0到4字节边界这个填充你得自己加。第三biSizeImage可以设成0对于BI_RGB未压缩格式GDI会自动计算。但设成实际大小更稳妥。2.3 两者对齐规则的冲突是花屏的元凶把上面两点合起来看问题就清楚了。Mat的行步长是OpenCV按自己的规则对齐的DIB的行步长是GDI按4字节边界对齐的。这两个值在图像宽度满足某些条件时恰好相等在另一些条件下就不等。如果你直接把mat.data交给StretchDIBits并且告诉它图像宽度是mat.cols那么当两个步长不一致时GDI会按它自己算的步长去读数据读到的位置就错位了表现出来就是图像斜切、花屏或者颜色错乱。我刚开始写这类代码的时候就遇到过一张宽度为奇数的灰度图显示出来是斜的查了半天才发现是步长问题。后来养成了一个习惯只要涉及Mat到GDI的转换第一件事就是检查mat.step和mat.cols * mat.elemSize()是否相等不等就得特殊处理。3. 用StretchDIBits打通Mat到CDC的显示链路3.1 为什么选StretchDIBits而不是SetDIBitsToDeviceGDI里能画DIB的函数不止一个。SetDIBitsToDevice只能按1:1的比例画不支持缩放StretchDIBits支持源矩形和目标矩形的独立指定可以缩放、可以只画一部分。在实际项目里图像显示区域的大小往往和图像本身不一样需要缩放适配所以StretchDIBits是更通用的选择。而且它的参数设计也更灵活源矩形和目标矩形分开指定做局部放大、平移查看都很方便。StretchDIBits的函数签名是这样的int StretchDIBits( HDC hdc, int xDest, int yDest, int DestWidth, int DestHeight, int xSrc, int ySrc, int SrcWidth, int SrcHeight, const VOID *lpBits, const BITMAPINFO *lpbmi, UINT iUsage, DWORD dwRop );关键参数是lpBits像素数据指针、lpbmi位图信息、iUsage通常用DIB_RGB_COLORS、dwRop光栅操作码通常用SRCCOPY。源矩形和目标矩形分别用xSrc/ySrc/SrcWidth/SrcHeight和xDest/yDest/DestWidth/DestHeight指定。3.2 构造BITMAPINFO的正确姿势构造BITMAPINFO看着简单但细节不少。对于24位BGR图像代码大概是这样BITMAPINFO bmi {0}; bmi.bmiHeader.biSize sizeof(BITMAPINFOHEADER); bmi.bmiHeader.biWidth mat.cols; bmi.bmiHeader.biHeight -mat.rows; // 负数表示自上而下 bmi.bmiHeader.biPlanes 1; bmi.bmiHeader.biBitCount 24; bmi.bmiHeader.biCompression BI_RGB; bmi.bmiHeader.biSizeImage 0; bmi.bmiHeader.biXPelsPerMeter 0; bmi.bmiHeader.biYPelsPerMeter 0; bmi.bmiHeader.biClrUsed 0; bmi.bmiHeader.biClrImportant 0;biHeight设成负数这一点再强调一次因为它是上下颠倒问题的直接原因。biSizeImage设0让GDI自己算对于BI_RGB格式是安全的。对于32位BGRA图像把biBitCount改成32即可。32位的好处是每像素4字节行步长天然是4的倍数不需要处理填充而且可以带Alpha通道虽然StretchDIBits本身不做Alpha混合但数据格式是兼容的。3.3 处理行步长不匹配的两种策略如果mat.step不等于mat.cols * mat.elemSize()直接传mat.data就会出问题。有两种处理方式。第一种是逐行拷贝到临时缓冲区。分配一块大小为mat.rows * mat.cols * mat.elemSize()的连续内存然后一行一行地memcpy过去每行拷贝mat.cols * mat.elemSize()字节。这样得到的缓冲区行步长就是紧凑的可以直接交给GDI。缺点是每次显示都要拷贝一遍大图会有性能开销。int rowBytes mat.cols * mat.elemSize(); int compactStep rowBytes; std::vectoruchar buffer(mat.rows * compactStep); for (int i 0; i mat.rows; i) { memcpy(buffer.data() i * compactStep, mat.ptr(i), rowBytes); }第二种是利用GDI的步长参数。StretchDIBits本身没有步长参数但BITMAPINFOHEADER的biWidth决定了GDI计算步长的方式。如果你把biWidth设成mat.step / mat.elemSize()也就是把填充也算作像素然后源矩形只取前mat.cols列理论上可以让GDI按Mat的步长去读。但这样做有个前提mat.step必须是mat.elemSize()的整数倍而且GDI对biWidth的处理在不同位深下行为不完全一致实测下来不够可靠。所以我个人更推荐第一种方案简单直接不容易出幺蛾子。提示如果图像不大或者显示频率不高逐行拷贝的开销可以忽略。如果追求极致性能可以在Mat创建时就保证它是连续的mat.isContinuous()为true这样mat.step mat.cols * mat.elemSize()就不需要拷贝了。3.4 完整的显示函数实现把上面的东西串起来一个完整的显示函数大概长这样void ShowMatOnCDC(CDC* pDC, const cv::Mat mat, const CRect rcDest) { if (mat.empty() || !pDC) return; // 确保是8位3通道或4通道 cv::Mat displayMat; if (mat.type() CV_8UC3) { displayMat mat; } else if (mat.type() CV_8UC4) { displayMat mat; } else if (mat.type() CV_8UC1) { cv::cvtColor(mat, displayMat, cv::COLOR_GRAY2BGR); } else { // 其他类型先转8位 cv::Mat tmp; mat.convertTo(tmp, CV_8U); if (tmp.channels() 1) cv::cvtColor(tmp, displayMat, cv::COLOR_GRAY2BGR); else displayMat tmp; } int channels displayMat.channels(); int bitCount channels * 8; int rowBytes displayMat.cols * channels; // 处理行步长 const uchar* pBits displayMat.data; std::vectoruchar compactBuf; if (displayMat.step ! (size_t)rowBytes) { compactBuf.resize(displayMat.rows * rowBytes); for (int i 0; i displayMat.rows; i) { memcpy(compactBuf.data() i * rowBytes, displayMat.ptr(i), rowBytes); } pBits compactBuf.data(); } BITMAPINFO bmi {0}; bmi.bmiHeader.biSize sizeof(BITMAPINFOHEADER); bmi.bmiHeader.biWidth displayMat.cols; bmi.bmiHeader.biHeight -displayMat.rows; bmi.bmiHeader.biPlanes 1; bmi.bmiHeader.biBitCount bitCount; bmi.bmiHeader.biCompression BI_RGB; pDC-StretchDIBits( rcDest.left, rcDest.top, rcDest.Width(), rcDest.Height(), 0, 0, displayMat.cols, displayMat.rows, pBits, bmi, DIB_RGB_COLORS, SRCCOPY); }这个函数处理了类型转换、行步长、位深设置基本能覆盖大部分场景。调用的时候传一个CDC指针、一个Mat和一个目标矩形就行。4. 显示效果调优与性能取舍4.1 缩放质量StretchDIBits的拉伸模式StretchDIBits在缩放时默认用的是COLORONCOLOR模式这个模式速度快但质量一般缩小图像时会有明显的锯齿和细节丢失。如果你需要更好的缩放质量可以在调用之前设置拉伸模式int oldMode pDC-SetStretchBltMode(HALFTONE); pDC-SetBrushOrg(0, 0); // HALFTONE模式需要设置画刷原点 pDC-StretchDIBits(...); pDC-SetStretchBltMode(oldMode);HALFTONE模式会做一定的插值缩小图像时效果明显好于COLORONCOLOR但速度会慢一些。SetBrushOrg那行在HALFTONE模式下是必须的否则可能出现对齐问题。实测下来对于几百KB的普通图像HALFTONE的开销完全可以接受如果是每秒几十帧的实时视频流可能就得权衡一下了。4.2 大图显示的卡顿从哪来显示大图卡顿通常有三个来源。第一是前面说的行步长拷贝如果每帧都要拷贝几MB的数据累积起来很可观。第二是缩放本身的计算量尤其是放大倍数较大的时候。第三是GDI的绘制是在UI线程做的如果图像很大会阻塞消息循环导致界面无响应。针对第一点尽量让Mat保持连续避免拷贝。cv::Mat::create创建的Mat通常是连续的但通过ROI感兴趣区域得到的Mat往往不连续。如果你要反复显示同一个ROI可以先clone()一份连续的出来。针对第二点如果缩放比例固定可以考虑先把图像缩放到目标尺寸再显示这样StretchDIBits做的就是1:1拷贝快很多。OpenCV的cv::resize用的是优化过的算法质量也比GDI的拉伸好。针对第三点如果确实需要显示很大的图像可以考虑用双缓冲先在内存DC里画好再一次性BitBlt到屏幕DC。这样能减少闪烁但不会减少总计算量。真正的解决办法是把图像处理放到工作线程UI线程只负责最后的绘制。4.3 内存DC与双缓冲的配合在MFC里做双缓冲很常见配合Mat显示也不复杂。核心思路是创建一个和客户区等大的兼容DC和兼容位图所有绘制操作先在内存DC上做最后统一拷贝到屏幕DC。void CMyView::OnDraw(CDC* pDC) { CRect rcClient; GetClientRect(rcClient); CDC memDC; memDC.CreateCompatibleDC(pDC); CBitmap memBmp; memBmp.CreateCompatibleBitmap(pDC, rcClient.Width(), rcClient.Height()); CBitmap* pOldBmp memDC.SelectObject(memBmp); // 先在内存DC上画背景 memDC.FillSolidRect(rcClient, RGB(240, 240, 240)); // 再画Mat ShowMatOnCDC(memDC, m_mat, rcClient); // 最后一次性拷贝到屏幕 pDC-BitBlt(0, 0, rcClient.Width(), rcClient.Height(), memDC, 0, 0, SRCCOPY); memDC.SelectObject(pOldBmp); }这样做的另一个好处是当窗口被其他窗口遮挡后重新露出时不会出现残影。不过要注意每次OnDraw都创建兼容位图开销不小更好的做法是把内存DC和位图作为成员变量只在窗口大小变化时重建。5. 那些文档里不会写的坑与排查经验5.1 图像上下颠倒biHeight符号的陷阱这个问题我提过好几次但还是要单独拿出来说因为它太常见了。BITMAPINFOHEADER的biHeight为正时表示bottom-up为负时表示top-down。OpenCV的Mat是top-down的所以必须用负数。但有些示例代码里用的是正数然后显示出来是颠倒的作者可能又加了一个翻转操作来修复结果代码里多了一次无谓的cv::flip。正确的做法就是直接用负数不需要翻转。如果你拿到一段别人的代码发现里面有cv::flip配合显示先检查一下biHeight的符号很可能那个flip是多余的。5.2 颜色通道错乱BGR与RGB的识别OpenCV默认BGRGDI的24位DIB也是BGR所以正常情况下颜色是对的。但如果你从某些来源拿到的是RGB数据比如某些网络摄像头的SDK、某些图像解码库直接构造Mat显示就会红蓝互换。判断方法很简单显示一张有明显红色和蓝色的图看颜色对不对。如果不对用cv::cvtColor(mat, mat, cv::COLOR_RGB2BGR)转一下。还有一种情况是4通道图像。OpenCV的CV_8UC4默认是BGRAGDI的32位DIB也是BGRA所以直接显示颜色是对的。但如果你把4通道当3通道处理就会出问题。5.3 内存越界步长计算错误导致的崩溃前面说的步长问题如果处理不当轻则花屏重则内存越界访问导致崩溃。特别是当mat.step小于mat.cols * mat.elemSize()的时候这种情况理论上不应该出现但如果你手动构造过Mat或者用了某些非标准的数据源是有可能的GDI按biWidth算出来的步长会比实际数据大读到后面就越界了。排查这类问题我通常会在显示之前加一段断言检查ASSERT(mat.step (size_t)(mat.cols * mat.elemSize())); ASSERT(mat.depth() CV_8U);如果断言触发说明数据有问题先解决数据问题再谈显示。5.4 频繁显示时的资源泄漏排查StretchDIBits本身不涉及GDI对象的创建和销毁所以一般不会泄漏。但如果你在显示函数里创建了兼容DC、位图、画刷等GDI对象忘记释放就会泄漏。Windows的GDI对象数量是有限制的默认每个进程10000个泄漏到一定程度程序就会出问题。排查GDI泄漏可以用任务管理器看GDI对象列如果数字持续增长不下降就有泄漏。也可以用专门的工具。我自己的习惯是任何CreateXXX都配一个DeleteXXX用RAII封装起来避免忘记。5.5 多线程环境下CDC使用的注意事项CDC和HDC不是线程安全的。如果你在工作线程里处理完图像想直接在工作线程里调用StretchDIBits画到窗口上这是不行的。正确的做法是把处理结果传回UI线程在UI线程的OnDraw或者消息处理函数里绘制。如果一定要在工作线程里准备绘制数据比如构造BITMAPINFO、拷贝像素缓冲区这些是可以的只要不碰CDC就行。把准备好的数据打包通过PostMessage发给UI线程UI线程收到后再调用StretchDIBits。6. 从显示到交互Mat在CDC场景下的延伸用法6.1 鼠标坐标到图像坐标的映射显示出来只是第一步接下来往往要处理鼠标交互——比如在图像上画框、取点、测量距离。鼠标事件给的是客户区坐标你需要把它转换成图像坐标。转换的关键是知道图像在客户区里的显示矩形也就是StretchDIBits的目标矩形。假设目标矩形是rcDest图像尺寸是imgW x imgH鼠标点是pt那么图像坐标是int imgX (pt.x - rcDest.left) * imgW / rcDest.Width(); int imgY (pt.y - rcDest.top) * imgH / rcDest.Height();反过来图像坐标转客户区坐标int clientX rcDest.left imgX * rcDest.Width() / imgW; int clientY rcDest.top imgY * rcDest.Height() / imgH;这两个转换在实现画框、取点等功能时是基础。注意整数除法的精度问题必要时用浮点计算再取整。6.2 在Mat上叠加绘制再显示有时候你不想在CDC上画而是想直接在Mat上画比如用OpenCV的绘图函数画了框和文字然后整体显示。这样做的好处是绘制逻辑和图像处理逻辑统一在OpenCV里不用混用GDI和OpenCV两套绘图API。cv::rectangle(mat, cv::Rect(100, 100, 200, 150), cv::Scalar(0, 0, 255), 2); cv::putText(mat, Target, cv::Point(100, 90), cv::FONT_HERSHEY_SIMPLEX, 0.8, cv::Scalar(0, 255, 0), 2); ShowMatOnCDC(pDC, mat, rcDest);这种方式在需要频繁更新叠加内容的场景下很方便因为每次都是重新画一遍Mat再显示不用担心GDI绘图状态的残留问题。6.3 显示区域的裁剪与局部放大StretchDIBits的源矩形参数支持只显示图像的一部分这为实现局部放大提供了便利。比如你想显示图像中以(cx, cy)为中心、大小为w x h的区域并放大到目标矩形int srcX cx - w / 2; int srcY cy - h / 2; // 边界检查... pDC-StretchDIBits( rcDest.left, rcDest.top, rcDest.Width(), rcDest.Height(), srcX, srcY, w, h, pBits, bmi, DIB_RGB_COLORS, SRCCOPY);配合鼠标滚轮事件调整w和h就能实现缩放查看。配合鼠标拖动调整cx和cy就能实现平移。这套逻辑在图像查看器类的工具里很常用。6.4 保存显示结果为图片有时候用户想把当前显示的内容包括叠加的框和文字保存下来。如果叠加是在Mat上做的直接cv::imwrite就行。如果叠加是在CDC上做的就需要先把CDC的内容抓成位图再保存麻烦一些。所以如果保存是需求之一建议尽量在Mat上做叠加。cv::imwrite(output.png, mat);简单直接不依赖GDI。7. 一些实测下来的经验参数与建议关于位深选择我个人的建议是如果不需要Alpha通道用24位如果需要Alpha或者追求行对齐的便利用32位。32位虽然多占25%的内存和带宽但省去了行填充的处理代码更简单而且在现代机器上这点开销基本可以忽略。关于缩放模式静态图像显示用HALFTONE实时视频用COLORONCOLOR。如果实时视频也想要好一点的质量可以先把Mat用cv::resize缩放到接近目标尺寸再用COLORONCOLOR做最后的微调这样兼顾质量和速度。关于双缓冲只要窗口有频繁重绘的可能就值得上双缓冲。MFC的OnEraseBkgnd记得返回TRUE避免背景擦除导致的闪烁。关于类型转换显示函数里做类型检查和转换是必要的但不要每次显示都做。如果Mat的类型在多次显示之间不变可以在外面转好一次显示函数只负责画。这样能省掉重复的转换开销。最后说一个我踩过的坑StretchDIBits的返回值是成功绘制的扫描行数失败返回GDI_ERROR。有些情况下它会静默失败比如内存不足如果你不检查返回值可能以为画成功了但屏幕上是空的。建议在调试版本里加一个返回值检查至少打个日志。int ret pDC-StretchDIBits(...); if (ret GDI_ERROR) { TRACE(StretchDIBits failed, error code: %d\n, GetLastError()); }这个习惯帮我定位过好几次莫名其妙的白屏问题根源都是GDI资源耗尽或者参数不合法。