1. 从内存到屏幕：为什么Mat图不能直接丢给CDC
做过Windows桌面图像处理的朋友，大概率都遇到过这样一个场景：用OpenCV把图片读进来，算法跑完，结果稳稳当当地躺在cv::Mat里，可一到要把它显示在MFC对话框或者某个自绘控件上，就卡壳了。Mat是OpenCV那套内存管理和像素布局的产物，而CDC是Windows GDI的绘图上下文，两者中间隔着一道数据格式和坐标体系的墙。标题里说的“opencv中的Mat图使用CDC显示”，本质上就是解决这道墙的问题——把一块连续的、可能是BGR排列、行字节数还带对齐填充的内存，翻译成GDI能认的位图，再画到窗口上。
这件事看起来简单，但真动手写，坑一个接一个。有人直接把Mat.data传给SetDIBitsToDevice，结果图像花屏；有人用CImage中转，发现颜色通道反了；还有人每次刷新都重新构造位图，界面卡得没法看。我前后在好几个工业检测和医疗影像的桌面项目里处理过这个问题，从最早的逐像素SetPixel（慢到怀疑人生），到后来用StretchDIBits配合BITMAPINFO，再到封装成可复用的显示类，踩过的坑足够写一篇长文。
这篇文章面向的是正在用MFC、Win32或者任何基于CDC的Windows界面框架，同时又在项目里引入了OpenCV做图像处理的开发者。不管你是刚把OpenCV配进VS的新手，还是已经写过几版显示逻辑但总觉得不够顺滑的老手，下面这些内容应该都能帮你把“Mat到CDC”这条路彻底走通。我会从内存布局讲起，把BITMAPINFO的构造、行对齐的处理、颜色通道的转换、缩放绘制的参数选择，一直到双缓冲和性能优化，全部拆开揉碎说清楚。核心关键词就一个：Mat图用CDC显示，围绕它把每个环节的“为什么”和“怎么做”都交代明白。
2. 先搞懂Mat的内存布局，再谈显示
2.1 Mat的数据区到底长什么样
很多人显示出问题，根子不在CDC，而在对cv::Mat内存布局的理解有偏差。Mat并不是简单的一块像素数组，它由两部分组成：矩阵头（包含行数、列数、类型、步长等信息）和一个指向实际数据的指针data。真正决定显示效果的是data指向的那片内存怎么排布。
对于最常见的8位三通道图像（CV_8UC3），每个像素占3个字节，按B、G、R的顺序排列（OpenCV默认BGR）。但关键在于，每一行的字节数不一定等于宽度乘以通道数。OpenCV为了内存对齐和SIMD优化，会让每行字节数按一定规则向上取整，这个值就是Mat::step，也叫步长或stride。比如一张宽度为333的BGR图，每行理论上是999字节，但实际step可能是1000或者1004，多出来的字节是填充，不包含有效像素。
如果你直接把data当成紧密排列的数组去构造GDI位图，并且告诉系统宽度是333、每行999字节，那么从第二行开始，像素就会整体偏移，图像呈现斜向的撕裂或错位。这是新手最常遇到的第一个坑。
2.2 行对齐：那个容易被忽略的填充字节
GDI的位图也有自己的对齐要求。BITMAPINFOHEADER里的biWidth和biBitCount决定了每行像素数据，而系统默认按4字节对齐来解读DIB数据。也就是说，如果一行像素的字节数不是4的倍数，GDI会认为后面有填充，并按照对齐后的偏移去读下一行。
这就产生了一个匹配问题：OpenCV的step和GDI期望的行字节数可能不一致。解决办法有两种思路。第一种是让OpenCV输出一张“紧凑”的Mat，即step恰好等于width * channels，这样和GDI的期望对齐方式如果一致就能直接用；第二种是不管OpenCV的step是多少，在构造BITMAPINFO时把biWidth设成step / channels（对于8位图），让GDI按照OpenCV的实际步长来解读。第二种做法更通用，但需要小心通道数和位深的对应关系。
我个人的习惯是：在显示之前，先判断mat.step是否等于mat.cols * mat.elemSize()。如果相等，说明是紧凑的，可以直接用真实宽度；如果不相等，要么用copyTo或者clone配合Mat的连续化处理，要么在BITMAPINFO里用步长反推宽度。前者多一次内存拷贝但逻辑简单，后者零拷贝但需要精确计算。对于实时性要求高的场景，后者更优。
2.3 通道顺序与颜色空间：BGR不是RGB
OpenCV读进来的彩色图默认是BGR顺序，而Windows的DIB（设备无关位图）在24位或32位格式下，内存中的字节顺序是B、G、R（对于24位）或B、G、R、A（对于32位）。这一点上两者其实是一致的，所以如果你直接把BGR的Mat数据喂给32位或24位的DIB，颜色是对的。但如果你中间经过了cvtColor转成RGB，再拿去显示，红蓝就会互换，人脸变蓝、天空变红。
这里有个容易混淆的点：CImage或者某些GDI+的接口可能期望RGB，而StretchDIBits配合BITMAPINFO时，24位和32位的DIB本身就是BGR顺序。所以用CDC原生接口显示Mat时，保持BGR反而省事。如果你非要用CImage做中转，记得它内部也是BGR，但CImage::SetPixel之类的接口用的是COLORREF，那是另一套。
另外，灰度图（CV_8UC1）的处理更简单，没有通道顺序问题，但要注意调色板。8位DIB需要一个颜色表，灰度图需要构造一个256项的RGBQUAD数组，从黑到白线性排列。如果忘了设调色板，显示出来可能是一片黑或者随机颜色。
3. 核心桥梁：BITMAPINFO的构造与参数计算
3.1 BITMAPINFO结构拆解
BITMAPINFO是GDI用来描述DIB的，它包含一个BITMAPINFOHEADER和一个可选的调色板数组。对于24位和32位图，调色板可以省略（传NULL），但对于8位图必须提供。BITMAPINFOHEADER里几个关键字段：
biSize：结构体大小，固定为sizeof(BITMAPINFOHEADER)。biWidth：图像宽度，单位是像素。但如前所述，当Mat的step和GDI对齐不一致时，这里可能要填步长换算后的值。biHeight：图像高度。正数表示自下而上存储，负数表示自上而下存储。OpenCV的Mat是自上而下的，所以这里通常填负数，比如-mat.rows，这样第一行数据对应图像顶部。biPlanes：固定为1。biBitCount：每像素位数，8位灰度填8，BGR填24，BGRA填32。biCompression：压缩方式，通常用BI_RGB（0），表示无压缩。biSizeImage：图像数据大小，BI_RGB时可以填0。
构造时最容易出错的是biWidth和biHeight的符号。我见过有人填了正的高度，结果图像上下颠倒，还以为是OpenCV读反了。其实只要把biHeight设为负的mat.rows，就能让GDI按照Mat的自然顺序从上到下绘制。
3.2 步长不匹配时的宽度换算
假设有一个CV_8UC3的Mat，cols = 333，step = 1000（实际可能是1000，因为3333=999，对齐到4的倍数就是1000）。如果直接告诉GDI宽度是333、24位，GDI会认为每行是3333=999字节，并按4字节对齐到1000字节去读下一行。巧的是，这里OpenCV的step也是1000，两者恰好一致，所以能正常显示。但如果step是1004呢？GDI按999对齐到1000，而OpenCV实际是1004，从第二行开始就会错位4个字节。
这时候有两种处理方式。第一种是把biWidth设为step / 3，即1004/3=334（取整），这样GDI认为每行是334*3=1002字节，再对齐到1004，正好和OpenCV的step匹配。但这样会多显示出一列无效像素（因为实际宽度是333），不过这些像素是填充字节，通常不影响视觉。第二种是先把Mat紧凑化，用mat.clone()或者mat.copyTo(temp)，让step等于cols * 3，然后再用真实宽度。第一种零拷贝但会多画一列，第二种多一次拷贝但干净。
对于32位图（CV_8UC4），每像素4字节，天然4字节对齐，step通常就等于cols * 4，不存在对齐问题，处理起来最省心。所以如果你的场景允许，把Mat转成BGRA再显示，能避开很多麻烦。
3.3 调色板的构造（8位灰度图）
8位灰度图需要构造一个RGBQUAD数组，长度为256。每个元素的rgbRed、rgbGreen、rgbBlue都设为索引值，rgbReserved为0。这样索引0对应黑色，索引255对应白色。构造完调色板后，BITMAPINFO需要分配足够的内存来容纳头部和调色板，通常用malloc(sizeof(BITMAPINFOHEADER) + 256 * sizeof(RGBQUAD))，然后分别填充。
如果忘了这一步，或者调色板全填0，显示出来就是全黑。有些开发者用CreateDIBSection创建位图时传了NULL调色板，对于8位图也会导致同样的问题。所以灰度图显示，调色板是必须的。
4. 从Mat到屏幕的完整实操流程
4.1 方案一：StretchDIBits直接绘制
这是最直接的方式，不需要创建任何GDI位图对象，直接把Mat的数据指针和BITMAPINFO传给StretchDIBits，由系统完成绘制。适合一次性绘制或者不频繁刷新的场景。
步骤大致如下。首先准备好BITMAPINFO，根据Mat的类型填充头部。然后获取目标DC，比如在OnPaint里用CPaintDC dc(this)。接着调用dc.SetStretchBltMode(COLORONCOLOR)来设置缩放模式，避免颜色失真。最后调用StretchDIBits，参数依次是目标DC、目标矩形左上角和宽高、源矩形左上角和宽高、源数据指针、BITMAPINFO指针、颜色使用方式（DIB_RGB_COLORS）和光栅操作码（SRCCOPY）。
这里有个细节：StretchDIBits的源矩形坐标是相对于DIB的，如果biHeight是负数，源矩形的y坐标从0开始就是顶部。目标矩形则根据你的控件大小来定。如果不需要缩放，源和目标宽高一致即可。
这种方式的优点是代码短、零拷贝（除了GDI内部的转换），缺点是每次绘制都要重新解析DIB，如果窗口频繁重绘，CPU占用会比较高。另外，如果Mat的数据在绘制过程中被修改，可能导致撕裂，所以多线程环境下需要加锁。
4.2 方案二：CreateDIBSection加内存DC
这是更工程化的做法，适合需要频繁刷新或者要做双缓冲的场景。核心思路是用CreateDIBSection创建一个GDI位图，它同时返回一个指向位图数据的指针，我们可以直接把Mat的数据拷贝进去，然后用BitBlt或StretchBlt从内存DC画到屏幕DC。
具体流程：先填充BITMAPINFO，调用CreateDIBSection，得到一个HBITMAP和void* pBits。然后根据Mat的step和位图的stride，逐行或者整块拷贝数据。如果位图的stride和Mat的step一致，可以直接memcpy整块；如果不一致，需要逐行拷贝，每行拷贝min(mat.step, bitmapStride)字节。拷贝完成后，创建一个兼容DC，用SelectObject把位图选进去，最后用BitBlt画到目标DC。
这种方式的优势在于，位图创建一次可以重复使用，只要尺寸不变。每次Mat更新后，只需要重新拷贝数据，然后触发重绘。配合双缓冲（先在内存DC上画好，再一次性BitBlt到屏幕），可以彻底消除闪烁。
4.3 方案三：CImage中转（适合快速原型）
如果你的项目里已经用了ATL/MFC的CImage，可以用它作为中转。CImage内部封装了DIB，支持从内存加载。大致做法是创建一个CImage对象，调用Create创建指定宽高和位深的图像，然后用GetBits拿到数据指针，把Mat的数据拷贝进去，最后用CImage::Draw或者BitBlt画到DC。
但要注意，CImage的Create默认创建的位图是自下而上的（正高度），而Mat是自上而下的，拷贝时需要翻转行序，或者创建时用负高度。另外，CImage的GetPitch返回的是每行字节数，拷贝时要按这个值来。这种方式代码量少，但多了一次拷贝，且CImage的接口在某些老版本VS上有兼容性问题，适合对性能要求不高的场景。
4.4 关键参数计算实例
假设有一个cv::Mat，类型CV_8UC3，rows = 480，cols = 640，step = 1920（640*3=1920，恰好4字节对齐）。构造BITMAPINFO时，biWidth = 640，biHeight = -480，biBitCount = 24，biSizeImage = 1920 * 480。数据指针直接用mat.data。这种情况下，step和GDI期望的行字节数一致，可以直接绘制。
如果cols = 641，step可能是1924（6413=1923，对齐到4的倍数）。此时GDI按6413=1923对齐到1924，恰好和step一致，也能直接绘制。但如果step是1928（某些SIMD对齐要求），GDI按1924解读，就会错位。这时要么把biWidth设为1928/3=642（多一列），要么先clone成紧凑Mat。
对于32位图，CV_8UC4，cols = 641，step = 2564（641*4=2564，4字节对齐），GDI期望的也是2564，完全一致，无需任何处理。所以能用32位就用32位，省心。
5. 性能优化与双缓冲实战
5.1 为什么你的界面刷新会闪
在没有双缓冲的情况下，每次OnPaint直接往屏幕DC上画，如果绘制过程涉及多次操作（比如先填充背景再画图），用户会看到中间状态，表现为闪烁。尤其是当图像较大、绘制耗时较长时，闪烁非常明显。解决办法就是双缓冲：创建一个与屏幕兼容的内存DC和一个兼容位图，所有绘制操作先在内存DC上完成，最后用一次BitBlt把整个内存位图拷贝到屏幕DC。这样用户看到的永远是完整的画面。
在Mat显示的语境下，双缓冲的位图可以复用前面CreateDIBSection创建的那张DIB，也可以单独创建一个兼容位图。如果复用DIB，那么Mat数据拷贝到DIB后，直接BitBlt到屏幕即可，连内存DC的额外绘制都省了。但要注意，如果需要在图像上叠加文字或标记，这些操作应该在内存DC上做，而不是直接改DIB数据。
5.2 减少拷贝：直接使用Mat数据作为DIB
CreateDIBSection的一个强大之处在于，它允许我们指定一个外部数据指针吗？不，它自己分配内存。但我们可以反过来，用CreateDIBSection创建位图后，把Mat的数据拷贝进去。有没有办法让GDI直接使用Mat的内存，避免拷贝？有，就是用StretchDIBits或者SetDIBitsToDevice，它们接受外部数据指针。但这两个函数每次调用都会让GDI去解析数据，没有缓存机制，频繁调用性能不如DIB。所以如果刷新率很高，还是拷贝到DIB更划算，因为拷贝是线性的内存操作，很快，而GDI解析DIB的开销更大。
另一个减少拷贝的思路是，如果Mat本身就是连续的且step匹配，可以直接用CreateDIBSection创建位图后，用memcpy整块拷贝，这比逐行拷贝快很多。所以尽量让Mat保持连续。
5.3 缩放绘制的质量与速度权衡
StretchDIBits和StretchBlt都支持缩放，但缩放模式影响质量和速度。SetStretchBltMode可以设置COLORONCOLOR（速度快，颜色可能失真）、HALFTONE（质量好，速度慢）等。对于图像显示，如果缩放比例不大，COLORONCOLOR通常够用；如果需要高质量缩放，可以用HALFTONE，但要注意它需要设置画刷，否则可能全黑。
如果对缩放质量要求很高，建议先用OpenCV的resize把Mat缩放到目标尺寸，再用1:1绘制。OpenCV的插值算法（如INTER_LINEAR、INTER_CUBIC）比GDI的HALFTONE更可控，而且可以利用多核。这样虽然多了一次resize，但绘制时是1:1，速度反而可能更快，质量也更好。
5.4 多线程环境下的数据同步
如果图像处理在后台线程，显示在UI线程，那么Mat的数据可能在绘制时被修改，导致画面撕裂或崩溃。解决办法是在拷贝数据到DIB时加锁，或者使用双缓冲的Mat：后台线程处理完一帧后，把Mat拷贝到一个“待显示”的Mat，然后通过消息通知UI线程。UI线程在绘制时，从“待显示”的Mat拷贝到DIB。这样锁的粒度很小，不影响处理速度。
我通常会在显示类里维护两个Mat：一个m_matDisplay用于UI线程读取，一个m_matPending用于后台线程写入。后台线程写完后，用std::swap或者加锁拷贝交换两者。这样UI线程永远读的是完整的帧。
6. 常见问题与排查技巧实录
6.1 图像花屏、斜向撕裂
这是最典型的问题，原因几乎总是步长不匹配。排查方法：打印mat.step和mat.cols * mat.elemSize()，如果不相等，就是步长问题。解决方式如前所述，要么调整biWidth，要么clone成紧凑Mat。另外，如果biHeight符号错了，图像会上下颠倒，但不会撕裂。
6.2 颜色不对，红蓝互换
检查是否在显示前做了cvtColor转成RGB。如果用了CImage，确认它的通道顺序。对于StretchDIBits，24位和32位DIB本身就是BGR，所以Mat保持BGR即可。如果显示出来是灰度或者偏色，检查biBitCount是否和Mat的通道数匹配。
6.3 图像全黑或全白
对于8位灰度图，检查调色板是否构造。对于24位图，检查数据指针是否为空，或者biSizeImage是否设错。另外，如果biHeight是正数且数据是自上而下的，可能画到了屏幕外。
6.4 刷新闪烁严重
启用双缓冲。如果已经用了双缓冲还闪，检查是否在OnEraseBkgnd里返回了TRUE，避免背景擦除。另外，确保所有绘制都在内存DC上完成，最后一次性BitBlt。
6.5 内存泄漏与GDI对象泄漏
每次CreateDIBSection创建的HBITMAP和CreateCompatibleDC创建的DC，在不用时都要DeleteObject和DeleteDC。如果显示类在每次绘制时都创建新的位图，很快就会耗尽GDI对象。正确的做法是在类初始化时创建一次，尺寸变化时重建，析构时释放。
6.6 大图显示卡顿
如果图像很大（比如4K），每次拷贝和绘制都很耗时。可以考虑只显示感兴趣区域（ROI），或者用OpenCV先缩小到屏幕尺寸再显示。另外，用SetStretchBltMode(COLORONCOLOR)代替HALFTONE能提升速度。
7. 封装一个可复用的Mat显示类
7.1 类的职责与接口设计
把前面这些逻辑封装成一个类，比如CMatDisplay，职责很明确：接收Mat，在指定的CDC上绘制。接口可以设计为void Draw(CDC* pDC, const cv::Rect& dstRect)，内部处理位图创建、数据拷贝和绘制。类内部维护HBITMAP、BITMAPINFO*、内存DC等资源，尺寸变化时重建。
为了适应不同的Mat类型，可以在SetImage时记录类型，并在Draw时根据类型选择位深和调色板。对于不支持的格式，可以内部转换，比如把CV_8UC1转成CV_8UC4再显示，虽然多一次转换，但简化了逻辑。
7.2 资源管理与异常安全
GDI资源不是RAII的，需要手动释放。在类的析构函数里，确保DeleteObject(m_hBitmap)和DeleteDC(m_hMemDC)被调用。如果类可能被拷贝，要禁用拷贝构造和赋值，或者实现引用计数。另外，BITMAPINFO如果是动态分配的，也要在析构时free。
在Draw函数里，如果CreateDIBSection失败，要有降级处理，比如回退到StretchDIBits。异常安全方面，尽量不用异常，用返回值或断言。
7.3 与MFC控件集成
如果要在CStatic或者自定义控件上显示，可以在控件的OnPaint里调用显示类的Draw。如果控件需要支持鼠标交互（比如缩放、平移），可以在显示类里增加视口变换，把鼠标坐标映射到图像坐标。这部分扩展性很强，但核心的Mat到CDC的转换逻辑不变。
我自己的项目里，这个显示类还集成了帧率统计和内存占用监控，方便调试。对于工业检测场景，还会叠加一些ROI框和文字标注，这些都在内存DC上绘制，不影响Mat数据。
7.4 跨平台与可移植性思考
虽然CDC是Windows特有的，但Mat到屏幕的思路在其他平台也类似。比如在Linux上用GTK或Qt，需要把Mat转成对应的图像格式。核心的步长处理、通道顺序、缩放策略是通用的。所以把显示逻辑抽象成“Mat到某种位图描述”的转换，再针对不同平台实现绘制，能提高代码复用率。
最后分享一个小技巧：在调试显示问题时，可以先把Mat用imwrite存成图片，确认Mat本身没问题，再把问题范围缩小到显示环节。另外，用mat.isContinuous()判断是否连续，能快速定位步长问题。这些年在不同项目里反复用这几招，基本能覆盖九成以上的显示异常。
