C#调用Halcon工业相机采集与HSmartWindowControl缩放平移

简介面向具备C#与Halcon基础的机器视觉、工业检测开发者这份示例工程围绕海康工业相机的图像采集与交互查看展开演示如何调用Halcon接口打开设备、抓取图像并在HSmartWindow控件中完成显示、鼠标拖拽平移和滚轮缩放可作为视觉软件中相机模块的基础实现参考。压缩包共46个文件、约22.53MB含10个cs源码以及sln、csproj工程文件另有HalconDotNet等5个dll、3个exe、config与resx等配置和资源文件目录按解决方案、属性、调试输出组织便于在Visual Studio中直接打开、编译与对照调试。已有931人学习适合借鉴其相机连接、图像刷新、显示窗口初始化和交互事件处理的代码组织方式。对低速采集项目可直接参考对高帧率场景也能据此扩展多线程或异步处理并为工业自动化、质量检测等实时看图需求提供起步模板。1. 相机能出图缩放却往左上角跑——先把这个场景说清楚调试台上最常听到的一句反馈是「图像出来了但鼠标一滚画面就自己往左上角溜」。这不是相机的问题也不是 C# 的问题而是 C# 采图、Halcon 算子处理、HSmartWindowControl 显示这三层之间的坐标系没有对齐。这个项目干的正是把三件事串成一条线用 C# 拉取国产 GigE 工业相机的实时流把原始帧转成 HObject 交给 Halcon再在 HSmartWindowControl 上做可交互的平移与缩放。适合两类人一类是刚接手视觉工位、需要在一周内把相机画面调出来的新手另一类是手里已有 Halcon 算法、只缺一个能拖能缩的看图控件的熟手。相机型号换了、分辨率换了代码骨架基本不用动。2. 项目结构与技术选型从取流到上屏的四层拆分这套东西如果一开始都塞进 Form1.cs写到五百行就会变成黑匣子改一个曝光参数要找十分钟。比较稳的做法是按「相机 → 转换 → 处理 → 显示」四层切开层和层之间只传 HObject 和少量元数据谁出问题一眼能定位。2.1 四层分层与目录清单工程按职责切目录不按文件类型切新人进来直接找对应层就行。目录职责关键类型Acquisition/相机连接、参数下发、取流回调、断线重连ICameraSource、VendorGigECamera、FrameArrivedEventArgsInterop/原始帧指针到 HObject 的转换、颜色空间处理HImageFactory、PixelFormatProcessing/Halcon 算子封装标定、找边、模板匹配Inspector、CalibrationMapView/HSmartWindowControl 封装、平移缩放、ROI 交互HalconViewControl、ViewTransformConfig/相机参数、显示参数的 JSON 落盘CameraConfig、ViewConfigInterop/单独拎出来是有原因的这一层是所有内存问题的发源地。把GenImage1、GenImage3、指针拷贝集中到一个文件里后面查内存泄漏只要盯这一个地方。我一般会在这一层强制要求「进多少帧、出多少帧、释放多少帧」三个计数器必须对齐跑一晚上对不上就直接定位。四种层的调用方向是单向的Acquisition只发事件不认识 HalconView只吃 HObject不认识相机 SDK。中间由主窗体做粘合。这个约束看起来啰嗦但它换来的好处是换相机品牌只需要重写Acquisition换显示控件只需要重写View另外两层不动。2.2 Halcon 直连相机与厂商 SDK 取流的取舍标题里有「C# 调用 Halcon 读取相机」实际上这条路有两条分支很多人到这一步就开始翻车因为选错了后面全是麻烦。第一条是 Halcon 自带的图像采集接口一句open_framegrabber就能拿到图像代码量最小// Halcon 直连 GigE 相机代码最短但可控性也最弱 HOperatorSet.OpenFramegrabber( GigEVision2, // 接口名需要本机安装并授权对应的采集接口 0, 0, 0, 0, 0, 0, progressive, // 场模式面阵相机一般用 progressive -1, // 位深-1 表示沿用相机默认 default, // 色彩空间 -1, // 通用参数 false, // 外部触发false 表示自由运行 default, // 端口 cam1, // 设备标识多相机时按枚举结果改 0, -1, out HTuple acqHandle); HOperatorSet.GrabImage(out HObject image, acqHandle); hSmartWindowControl1.HobjectToHimage(image);OpenFramegrabber的参数里-1大多表示「沿用默认」cam1是设备标识需要先用info_framegrabber枚举。这条路的好处是代码短、跟 Halcon 生态贴合坏处是参数控制粒度受限于接口实现改触发源、改 IO 输出、读相机温度这类操作基本没法做而且采集接口本身需要单独授权。第二条是走相机厂商的 .NET SDK 取流再转成 HObject。代码多写一百多行但相机的每一个 GenICam 节点都在手里。维度Halcon 直连厂商 SDK 转换初始代码量约 20 行约 200 行曝光/增益/触发控制受接口实现限制全量节点可读写硬触发与 IO 输出弱完整支持断线重连需自行封装SDK 提供事件授权依赖需采集接口授权只需 Halcon 基础库帧率上限高高但要自己管内存工业现场我一般选第二条。原因很实际产线上的相机基本都要接光电触发还要在检测完成后给 PLC 一个 IO 信号这两件事用直连方案做起来很别扭。而转换成本其实不高一次写好后所有项目复用。2.3 线程模型三条线程各管一段相机 SDK 的回调线程是它自己的线程池线程不是 UI 线程也不是你 new 出来的线程。这一点必须先想清楚否则后面一定会在某个位置抛跨线程异常。项目里的分工是三条线SDK 回调线程只做「取指针 打时间戳 塞最新帧」不做任何转换处理线程从最新帧槽位取图做 HObject 转换和算法UI 线程只负责DispObj。三条线之间用「最新帧槽位」而不是队列传递队列在视觉项目里几乎一定会积压积压的结果就是画面越跑越延迟最后延迟三秒操作员以为相机坏了。3. 采集链路从 GigE 取流到 HObject 的落地实现采集这一段是整个项目里最容易出玄学的地方。相机连上了、能出图但跑十分钟掉线一次或者帧率上不去标称 30fps 实测只有 12fps。这些问题八成不在 Halcon而在取流和转换这两步。3.1 相机抽象与参数下发先定接口把厂商 SDK 挡在接口后面。这样主窗体永远只面对ICameraSource测试时还能塞一个假实现跑离线图片。public interface ICameraSource : IDisposable { // 帧到达事件回调线程触发订阅方禁止在此直接操作 UI event EventHandlerFrameArrivedEventArgs FrameArrived; bool IsGrabbing { get; } void Open(CameraConfig cfg); // 连接 下发参数 void StartGrabbing(); // 开始取流 void StopGrabbing(); // 停止取流保留连接 } public sealed class FrameArrivedEventArgs : EventArgs { public IntPtr Data; // 原始帧首地址生命周期由 SDK 管理 public int Width; public int Height; public int Stride; // 每行字节数RGB 时通常是 Width * 3 对齐后 public bool IsMono8; // true 为灰度false 为 RGB24 public long FrameId; // 相机侧帧号用于统计丢帧 public DateTime Timestamp; }接口里把Data设计成IntPtr而不是byte[]是为了避免每帧一次几 MB 的托管堆拷贝。灰度 500 万像素的图一帧 5MB30fps 就是 150MB/s 的拷贝量GC 会被打得很惨。用指针直接喂给GenImage1Halcon 内部自己拷贝一次总共一次拷贝就够了。参数下发按配置对象走不要散落在代码里参数典型值说明ExposureTime3000 ~ 8000 us取决于光源和运动速度先定曝光再调增益Gain0 ~ 5 dB增益会放大噪声优先加光源TriggerModeOff / On自由运行用 Off产线接光电用 OnTriggerSourceLine0硬触发接在相机的输入线上AcquisitionFrameRate20 ~ 30超过处理能力就往下降别硬撑PacketSize8192千兆网卡配巨帧时才能拉满下发顺序也有讲究先停流、再改参数、再起流。运行中直接改曝光部分 SDK 会返回错误码另一部分会静默失败后者更麻烦你以为改了其实没改。3.2 回调取流与最新帧槽位回调函数里能做的事非常有限记住三条不碰控件、不转换图像、不阻塞。只做一件事——把最新一帧的引用换进去。private FrameArrivedEventArgs _latest; // 最新帧槽位 private int _pending; // 0 表示空1 表示有未消费帧 private long _dropped; // 被丢弃的帧数用于监控 private void OnSdkFrameArrived(object sender, SdkFrame e) { // 回调线程SDK 每次送帧都会进这里必须尽快返回 var args new FrameArrivedEventArgs { Data e.Ptr, Width e.W, Height e.H, Stride e.Stride, IsMono8 e.PixelType SdkPixelType.Mono8, FrameId e.Id, Timestamp DateTime.Now }; // 上一帧还没被处理线程取走直接丢弃这一帧绝不排队 if (Interlocked.Exchange(ref _pending, 1) 1) { Interlocked.Increment(ref _dropped); return; } Volatile.Write(ref _latest, args); // 保证处理线程能读到完整对象 _frameReady.Set(); // 唤醒处理线程 }Interlocked.Exchange是这里的关键。它在一行里完成了「置位并返回旧值」如果旧值已经是 1说明处理线程还没取走上一帧这一帧就直接丢掉。丢帧不可怕延迟才可怕。_dropped计数器是排查问题的第一手资料显示帧率掉到 10fps 时先看它是丢帧导致的还是处理慢导致的两者的处理方向完全相反。处理线程侧对应的是private void ProcessLoop() { while (!_cts.IsCancellationRequested) { if (!_frameReady.WaitOne(100)) continue; var frame Volatile.Read(ref _latest); if (frame null) continue; Interlocked.Exchange(ref _pending, 0); // 先释放槽位允许下一帧进来 HObject image null; try { image HImageFactory.FromRaw(frame); // 指针 - HObject var result _inspector.Run(image); // 算法层 _view.UpdateImage(image, result); // 交给显示层内部切 UI 线程 } finally { image?.Dispose(); // 必须释放Halcon 句柄不走 GC } } }finally里的Dispose不是可选项。HObject在 HalconDotNet 里包着一个非托管句柄GC 只回收托管壳子句柄要等Finalize才释放而Finalize线程根本跟不上 30fps 的节奏。跑两小时内存涨到几个 G基本都是这一行漏了。3.3 指针到 HObject 的转换细节转换这一步只有两个函数但坑不少。灰度图用GenImage1彩色图要么拆通道要么用GenImage3。public static class HImageFactory { public static HObject FromRaw(FrameArrivedEventArgs f) { HObject image; if (f.IsMono8) { // 灰度直接拿指针构造Halcon 内部会拷贝一份外部缓冲区归还 SDK 即可 HOperatorSet.GenImage1(out image, byte, f.Width, f.Height, f.Data); } else { // RGB24SDK 通常返回交错排列的 BGR 或 RGB // 先用 gen_image_interleaved 拆成三通道再合并避免手算偏移 HObject r, g, b; HOperatorSet.GenImageInterleaved(out r, f.Data, bgr, f.Width, f.Height, -1, byte, f.Width, f.Height, 0, 0, -1, 0); HOperatorSet.CountChannels(r, out HTuple ch); if (ch.I 3) { HOperatorSet.Decompose3(r, out HObject c1, out HObject c2, out HObject c3); r.Dispose(); HOperatorSet.Compose3(c1, c2, c3, out image); c1.Dispose(); c2.Dispose(); c3.Dispose(); } else image r; } return image; } }GenImageInterleaved的bgr这个参数跟相机输出格式强相关多数国产 GigE 相机默认是 BGR 顺序但有些型号可以配成 RGB配错了颜色就会红蓝互换看起来「颜色发紫」。这个现象我见过不止一次排查时先拿一张纯红物体对着拍如果显示成蓝色就是这个参数的问题。另外GenImage1传指针时SDK 缓冲区在回调返回后可能被复用所以必须确认 Halcon 已经完成拷贝再归还。GenImage1是同步拷贝函数返回时数据已经落到 Halcon 自己的内存里回调里直接调用是安全的。但如果你改成异步转换就必须在转换完成后再归还缓冲区否则会拿到半帧新数据的诡异图像。4. 显示与交互HSmartWindowControl 上的缩放平移实现前面都是准备工作这一节才是标题里最核心的部分。HSmartWindowControl 自带HMouseWheelZoom和HMoveContent两个属性打开就能拖能缩看着挺省事。但只要你把这两个属性设成true再去接管鼠标事件做 ROI 绘制就会立刻发现两者打架框选的时候画面跟着跑。所以这个项目里我把它俩都关掉自己实现可控性高得多。4.1 控件初始化与 part 的语义先建立正确的心智模型Halcon 窗口显示的不是「一张图」而是「图像坐标系里的一个矩形区域」这个矩形叫 part由(row1, col1, row2, col2)四个值定义。缩放平移的本质就是改这四个数图像本身一像素都没动。理解这一点后面所有计算都是初中的比例换算。private HWindow _window; private void InitWindow() { // 必须在句柄创建之后取 HalconWindow构造函数里拿到的是 null _window hSmartWindowControl1.HalconWindow; // 关闭内置交互全部自己接管 hSmartWindowControl1.HMouseWheelZoom false; hSmartWindowControl1.HMoveContent false; // 关闭自动保持宽高比否则像素与窗口的线性换算不成立 hSmartWindowControl1.KeepAspectRatio false; _window.SetWindowParam(graphics_stack, true); // 支持叠加层算法结果画在上面 _window.SetDraw(margin); _window.SetLineWidth(2); _window.SetColor(green); }HalconWindow属性在控件句柄创建前是 null放在窗体构造函数里必然空引用。稳妥位置是OnHandleCreated重写或Load事件。KeepAspectRatio设为false是为了让「窗口一个像素对应图像多少距离」在两个方向上保持一致否则后面用比例换算会算歪。代价是窗口比例和图像比例不一致时图像会变形但对标定之后的测量场景这反而是正确的显示方式。设置图像时还有一个高频翻车点// 错误做法每帧都这么写用户的缩放位置每秒被重置 30 次 hSmartWindowControl1.HobjectToHimage(image);HobjectToHimage内部会调用SetPart把整个图像铺满窗口。你刚把它放大到某个缺陷位置下一帧一到视图直接弹回全图。正确做法是只在第一帧或图像尺寸变化时设 part后续帧只画内容public void UpdateImage(HObject image, InspectionResult result) { if (InvokeRequired) { BeginInvoke(new Action(() UpdateImage(image, result))); return; } HOperatorSet.GetImageSize(image, out HTuple w, out HTuple h); if (_lastW ! w.I || _lastH ! h.I) { // 尺寸变化换相机、换分辨率才重置视图 _lastW w.I; _lastH h.I; _window.SetPart(0, 0, h.I - 1, w.I - 1); ResetViewState(); } HOperatorSet.DispObj(image, _window); // 只画内容不动 part DrawOverlay(result); // 叠加检测结果同样不动 part }DispObj的第二个参数是 HWindow不涉及 part 变更这是关键差别。很多人以为两者等价实际上一个是「换图并重置视图」一个是「往当前视图里画」。4.2 滚轮缩放以鼠标位置为锚点缩放的直觉是「鼠标指哪儿放哪儿大」数学上就是以鼠标对应的图像坐标为不动点把 part 的四个边界按同一个系数缩放。private const double ZoomIn 0.8; // 小于 1 表示视野变小即放大 private const double ZoomOut 1.25; private void OnMouseWheel(object sender, MouseEventArgs e) { if (_lastW 0) return; _window.GetPart(out HTuple r1, out HTuple c1, out HTuple r2, out HTuple c2); double row1 r1.D, col1 c1.D, row2 r2.D, col2 c2.D; // 鼠标当前指向的图像坐标当前 part 语义下 _window.GetMpositionSubPix(out HTuple mr, out HTuple mc, out HTuple _); double anchorR mr.D, anchorC mc.D; double k e.Delta 0 ? ZoomIn : ZoomOut; // 以锚点为中心收缩/扩张四个边界 double nr1 anchorR (row1 - anchorR) * k; double nc1 anchorC (col1 - anchorC) * k; double nr2 anchorR (row2 - anchorR) * k; double nc2 anchorC (col2 - anchorC) * k; // 缩放下限视野宽度小于 16 像素时不再放大避免数值精度问题 if (nr2 - nr1 16 || nc2 - nc1 16) return; // 边界钳制不允许把视野拖出图像外 ClampPart(ref nr1, ref nc1, ref nr2, ref nc2); _window.SetPart(nr1, nc1, nr2, nc2); }GetMpositionSubPix返回的是当前 part 下的图像坐标单位是像素带亚像素精度。anchorR/anchorC就是这一帧的不动点。公式anchor (old - anchor) * k的几何含义是锚点距离原边界多远缩放后仍保持同样的相对比例所以锚点在屏幕上的位置不动。ClampPart做两件事把窗口限制在[0, height-1] × [0, width-1]内同时保证窗口宽高不小于 16 像素。后者不是洁癖视野小到几个像素时浮点精度和GetMpositionSubPix的换算会开始抖鼠标不动图像也在颤看起来像相机在抖。滚轮事件还有一个平台差异WinForm 的MouseWheel只在控件获得焦点时触发。相机一跑起来焦点跑到别处滚轮就失灵。解决办法是在控件上挂MouseEnter时主动Focus()或者在窗体层面用IMessageFilter拦截WM_MOUSEWHEEL后者更稳但代码更多。4.3 拖拽平移与坐标基准更新平移看着简单——鼠标往右拖图像往右走——但实现里最容易翻车的地方是「基准点什么时候更新」。private bool _dragging; private double _lastR, _lastC; private void OnMouseDown(object sender, MouseEventArgs e) { if (e.Button ! MouseButtons.Left || _lastW 0) return; _window.GetMpositionSubPix(out HTuple r, out HTuple c, out HTuple _); _lastR r.D; _lastC c.D; _dragging true; hSmartWindowControl1.Cursor Cursors.Hand; } private void OnMouseMove(object sender, MouseEventArgs e) { if (!_dragging) return; _window.GetMpositionSubPix(out HTuple r, out HTuple c, out HTuple _); _window.GetPart(out HTuple r1, out HTuple c1, out HTuple r2, out HTuple c2); // 鼠标在图像坐标里的位移量part 反向移动同样的量 double dr _lastR - r.D; double dc _lastC - c.D; double nr1 r1.D dr, nc1 c1.D dc; double nr2 r2.D dr, nc2 c2.D dc; ClampPart(ref nr1, ref nc1, ref nr2, ref nc2); _window.SetPart(nr1, nc1, nr2, nc2); // 关键SetPart 之后同一个屏幕位置对应的图像坐标已经变了 // 必须在 SetPart 之后重新取基准否则拖动会越来越快 _window.GetMpositionSubPix(out HTuple nr, out HTuple nc, out HTuple _); _lastR nr.D; _lastC nc.D; }最后三行是这个功能里唯一的「后悔药」。GetMpositionSubPix的返回值依赖当前 partpart 一变同一个鼠标屏幕位置对应的图像坐标就变了。如果你在SetPart之前保存基准点下一帧算出来的位移会把「part 变化导致坐标漂移」也算进去结果是越拖越快鼠标移动一厘米图像跑十厘米。这个 bug 看起来像「鼠标加速」实际是坐标基准没更新我第一次遇到时盯了半小时才想明白。另一个细节是拖出边界时的抖动。鼠标移到窗口外面GetMpositionSubPix返回的是 part 边缘坐标位移量变成 0 或者跳变图像会一抽一抽。在ClampPart里把 part 限制住之后这种情况会缓和很多更彻底的办法是在MouseLeave时把_dragging置为false松开拖拽。再补一个双击复位操作员最喜欢这个private void OnMouseDoubleClick(object sender, MouseEventArgs e) { // 双击恢复全图视野 _window.SetPart(0, 0, _lastH - 1, _lastW - 1); }4.4 叠加层的坐标一致性检测结果要画在图上找到的边、匹配到的模板、测量出来的距离标注。这些绘制必须在同一套 part 语义下进行否则一缩放就飞。private void DrawOverlay(InspectionResult result) { if (result null) return; // 叠加层用图形栈不污染底层图像 _window.SetColor(green); foreach (var edge in result.Edges) { // 直接用图像坐标画线SetPart 已经处理了换算 _window.DispLine(edge.Row1, edge.Col1, edge.Row2, edge.Col2); } // 文字标注用 disp_message默认跟随图像坐标 HOperatorSet.DispText(_window, $OK {result.Score:F2}, image, result.Row, result.Col, green, box, false); }DispText的坐标系参数传image比window好window用的是窗口像素坐标图像一缩放文字就跑到别处image跟着图像坐标走缩放时文字会跟着放大或缩小位置始终对得上。5. 排查记录五个改写过多遍的坑相机和显示凑在一起问题很少出在单点上基本都在接缝处。下面五条是这类项目里复现率最高的每条都按现象、原因、解决写清楚。5.1 视图复位与坐标偏移第一条缩放几秒后自动回满屏。现象是用户拖到某个角落放大看缺陷画面每隔几秒或者每来一帧就跳回全图反复拖几次之后操作员就不愿意用了。原因几乎总是显示函数里调了HobjectToHimage这个函数内部会重置 part。另一条隐蔽路径是「图像尺寸变化检测」写错了每帧都判定成尺寸变化于是每帧都SetPart。解决办法是把「换图」和「重置视图」拆成两个方法尺寸变化才SetPart其余帧一律DispObj。排查时在SetPart前后各打一行日志看它一秒钟被调了几次一眼就能确认。第二条鼠标位置和图像对不上。现象是鼠标指着缺陷画出来的框偏了几十像素而且偏移量随缩放变化。原因是 DPI 缩放Windows 显示设置开 125% 或 150% 时控件的逻辑尺寸和物理像素不一致GetMpositionSubPix的换算就歪了。解决办法是在应用清单里声明 DPI 感知让应用自己处理缩放而不是被系统拉伸。另外如果控制代码里用了PointToClient自己算坐标就必须把 DPI 系数乘回去。我一般的做法是坐标一律从GetMpositionSubPix拿宁可少写几行自算逻辑也不碰 DPI 这个雷区。第三条拖拽越拖越快。现象是鼠标慢慢移动图像飞速跑出视野。原因是SetPart改变了鼠标位置对应的图像坐标而基准点没有跟着更新每次移动都把「视野位移」又叠加了一次。解决办法是在SetPart之后重新调用GetMpositionSubPix刷新_lastR/_lastC。这条经验值得写进注释里不然下一个人重构时很容易顺手删掉。5.2 采集卡顿与资源泄漏第四条一拖拽界面就卡成幻灯片。现象是静止时画面流畅一开始拖动画框相机帧率骤降鼠标拖动有明显延迟。原因是回调线程里用了Invoke同步版去更新 UIUI 线程正在处理鼠标事件回调线程就被阻塞SDK 的内部队列很快填满开始丢帧或者报超时。解决办法有两层采集回调里绝对不碰 UI只更新最新帧槽位UI 更新用BeginInvoke而不是Invoke并且加一个「已经在排队」的标记避免排队堆积。另外拖拽期间可以主动降显示帧率只画不处理鼠标松开后恢复正常操作手感会好很多。第五条跑两三个小时内存涨到几个 G 然后崩掉。现象是启动时内存五六百兆挂机一晚上变成三个 G最后抛异常或者直接无响应。原因是HObject没有释放。这个类型在 HalconDotNet 里包着非托管句柄GC 只回收托管部分句柄要等Finalize而Finalize线程的处理速度远跟不上 30fps。解决办法是把每个HObject的生命周期压到最短能用using就用不行就try/finally尤其是算法中间产生的临时图阈值结果、区域、轮廓漏一个都是慢性泄漏。验证方法是挂机时用任务管理器盯着私有工作集正常的曲线应该是一条平线缓慢上升就说明有地方漏了。顺带提一句相机连不上的问题虽然不属于显示层但排查时经常混淆。如果日志里是取流超时先看触发模式是不是被上次调试改成了On却没接触发线再看网卡巨帧有没有开、PacketSize是不是超过了网卡 MTU。这两个配置错一个相机能连上、能读参数就是一帧不出很容易被误判成 Halcon 的问题。6. 二次开发把 Demo 收成一个可复用控件这套东西最终要落到「拿来就用」上我把它收成了两个东西一个HalconViewControl用户控件一个ICameraSource接口实现。控件对外只暴露UpdateImage(HObject)、ResetView()、AddDrawingObject(...)三个方法内部把 part 管理、鼠标事件、DPI、叠加层全包住。窗体里剩下的代码就是订阅帧事件、调算法、调UpdateImage一行显示相关的逻辑都不用写。这套封装换到另一个工位上只改配置文件里的相机 IP 和曝光时间就能跑这是它最大的价值。改造时按这个顺序推进比较稳。第一步先把显示抽出来把HobjectToHimage全部替换成DispObj加一次性的SetPart这一步做完视图乱跳的问题基本消失。第二步加 ROI 交互用HDrawingObject在图像坐标上画矩形SetPart变化时 drawing object 不需要重建因为它的坐标本来就是图像坐标这一点比自己维护屏幕坐标省事得多。第三步才做多相机每个相机一个ICameraSource实例、一个处理线程共用一个显示控件切换靠下拉框注意切换时要停掉旧相机的取流并释放它产出的 HObject。验证方法我一般固定三个指标连续跑两小时看内存曲线是否走平用相机侧帧号和显示帧号做差看积压是否稳定在 0 到 1 帧缩放平移一百次之后GetPart的返回值是否仍然落在图像范围内且宽高不为负。第三个指标能提前抓出绝大多数坐标计算错误比肉眼观察可靠得多。还有一个技巧值得单独说把视图状态row1/col1/row2/col2和当前显示模式序列化进配置文件下次打开时恢复上次的视野。做标定调试的时候操作员每次都要重新缩放到同一个工位位置来回几十次人会烦。加上这个之后重新打开软件直接就在上次的位置省下的时间比写这段代码多得多。从那以后我每次接新的视觉工位都强制先跑一遍「连续两小时 缩放一百次 内存曲线」这三项不管需求多急。有两次就是因为跳过了这一步现场调试到半夜才发现是句柄没释放。希望这些能帮你少走一段弯路。本文还有配套的精品资源点击获取