企业官网建设流程全解析

简介：一套基于C#与DirectShow的TCT病理图文分析系统完整源码，采用Visual Studio 2008开发，数据库为Access，单机版可无缝转为网络版，且已有医院实际投入使用。源码覆盖病理图文工作站的核心环节，包括运行期界面动态设计、所见即所得的病理报告书写窗口、DirectShow音视频与图像采集模块，以及多个自定义组件，适合医疗信息化开发者、C#进阶学习者以及需要了解DirectShow采集应用的程序员参考。包内共有1093个文件，其中以515个rtf报告文档、136个cs源文件、54个resx和53个resources资源文件为主，同时包含dll运行库、ico/gif图标、xml配置等，整体压缩包仅约9.54MB，目录结构清晰，便于按模块查找对应代码。目前已有177人学习查看，源码可直接打开运行并附带Access数据库和运行环境，既能完整梳理病理图文报告的业务流程与界面交互，也可从自定义组件中学习C#控件封装与设计思路。

1. TCT病理图文分析系统到底在解决什么问题：从显微图像采集到PACS归档的完整闭环

病理科做TCT（液基薄层细胞学检测）筛查时，一张玻片上往往有几十万个细胞，医生要在高倍显微镜下逐个视野观察、截图、写诊断结论，再把带图文标注的报告归档到医院影像系统里。这个流程里最容易卡住的不是诊断本身，而是图像采集和归档这两头的工程问题：集成的摄像头经常黑屏、染色图偏色、批量上传到PACS时网络被掐断。这篇笔记基于C#调用DirectShow实现图像采集、用.NET编写图文报告，并与PACS对接的落地路径，把原理、可复现代码和踩坑记录一起讲清楚，适合病理信息系统的开发者和医院信息科工程师。

2. 为什么 C# + DirectShow + .NET 是这套采集系统的合理选型：原理与边界

2.1 DirectShow 在显微镜图像采集链路里的位置

TCT病理图文分析系统的一头连着显微镜摄像头，另一头连着图文报告和PACS。摄像头这头在Windows上绕不开DirectShow，因为它是Windows 2000时代就被微软确立的多媒体框架，过去二十多年里，Olympus、Leica、Baumer 以及大量国产显微镜摄像头厂商提供的Windows驱动，绝大多数都实现了DirectShow滤镜。所谓滤镜（Filter），可以理解成一个把摄像头视频流接入系统的标准插座，只要驱动装好了，应用程序就能在系统的设备列表里找到这个插座，不需要关心底层的USB或GigE传输细节。

DirectShow的特点是推模型。摄像头在物理层按自己的节奏产生帧，DirectShow框架把这些帧按时间戳推进Graph管线，你的程序只是在管线的某个节点上接了一个桶，挡不住它、也催不动它。很多从文件和网络读数据转过来的C#开发者在第一次写采集代码时会犯方向性错误：他们总想着“下一帧在哪，我去取”。DirectShow里没有这个概念，你只能在SampleGrabber上挂一个回调，等框架把帧送过来。这个模型的后果是：回调线程里不能做耗时操作，否则会拖慢整个Graph，甚至导致画面掉帧；你在回调里拿到的帧数据是DirectShow内部的缓冲，如果不及时拷贝走，下一帧到达时会被直接覆盖。

在C#里使用DirectShow有两条主流路线，后面小节单独展开。这里先记住一件事：图像采集层不是业务逻辑层，它应该被隔离在独立模块里，对外只暴露“开始采集”“停止采集”“一帧图像到了”这三个入口，上层无论做预览还是截图，都不该感知DirectShow的类型存在。这样做既是为了换摄像头时改动最小，也是因为DirectShow的回调线程与UI线程天然不是同一个线程，隔离层正好当作线程边界，把跨线程问题在模块内部解决掉。

2.2 C# 互操作 DirectShow 的两条路线：现成封装库与自写封装

第一条路是引入现成的DirectShowLib.NET封装库，项目里引用它之后，ICaptureGraphBuilder2、IBaseFilter、ISampleGrabber这些COM接口全都有托管定义，直接new出来用就行。对于验证摄像头能不能出画面、临时写个小工具这类诉求，这条路一小时就能跑通。DirectShowLib在GitHub上能找到 .NET Framework 和 .NET Standard 的版本，但要注意它只是把COM声明做了托管化，摄像头的私有参数（增益、曝光、白平衡）依然以IAMCameraControl和IAMVideoProcAmp接口的形式暴露。厂商实现良莠不齐，有的摄像头在设置亮度时直接返回失败，而且没有任何异常信息。

第二条路是在DirectShowLib之上再包一层自己的采集接口，把设备枚举、Graph构建、帧回调、参数设置这四件事收拢到一个类里。我一般这样写：对外暴露Start(deviceIndex)、Stop() 和 FrameReady 事件，FrameReady的事件参数携带Bitmap和一个抓帧时刻的Stopwatch时间值；内部维护IGraphBuilder实例、ISampleGrabber实例和源滤镜的IBaseFilter。切换摄像头品牌时，只改内部构造，对外接口和上层界面完全不动。这套封装看起来多写了一点代码，但在TCT这种需要同时支持四五台显微镜工作站的场景里，省掉的是现场联调时反复改上层界面的时间。

接口封装好之后，剩下的核心难题是如何处理回调线程和UI线程的关系。DirectShow的SampleGrabber回调跑在系统内部的流线程上，频率等于摄像头帧率，常见工业摄像头在25FPS到30FPS。如果你在回调里直接抛事件给WPF的Dispatcher做图像刷新，UI线程会被刷爆，表现为鼠标卡顿、界面假死。我常用的做法是：回调里只把“最新一帧”放入一个只能容一个元素的新旧帧槽，UI侧用一个100ms的DispatcherTimer去取最新帧显示。预览清晰度足够，CPU占用也不会因为高帧率摄像头而失控。

顺带说一个C#基础但容易踩的点：帧数据在回调里到底用数组还是集合。DirectShow回调拿到的是IntPtr指针，必须立刻拷贝成托管数组保存。C#里byte[]是固定长度引用类型，适合做这种一次性缓冲区；List 是动态扩容集合，拿来做采集缓冲会有装箱、扩容和GC压力，回调里尤其不合适。所以代码里一律用byte[]做帧缓冲，只有需要动态追加数据时才考虑集合。

2.3 .NET 版本、DirectShow 运行库与CPU架构：先定架构再写代码

TCT系统里的.NET选型，核心约束在目标机器的系统版本上。医院工作站大量还是Windows 7或Windows 10精简版，.NET Framework 4.8在两者上都能装，而.NET 6/8虽然对Windows 7有兼容方案，但在病理科这种长时间不关机、跑着老旧采集驱动的机器上，我见过不止一次新运行时和摄像头驱动抢资源的现场。因此如果纯做Windows平台的TCT采集工作站，.NET Framework 4.8 + DirectShow仍然是最少出幺蛾子的组合。只要不碰Linux容器化，就没有必要为了跨平台去选新运行时。

部署时有个典型问题：.NET Framework 3.5在离线内网机器上安装经常报0x80072f8f，这是系统无法连接Windows Update导致的。医院内网机器没有外网权限是常态，部署时要么用带3.5的完整离线包，要么用dism从Windows安装镜像注入：

dism /online /enable-feature /featurename:NetFx3 /all /source:D:\sources\sxs /LimitAccess

注意 /source 指向Windows安装镜像的sxs目录，且必须管理员身份运行。这个报错在装机时很常见，先排查这台机器用的是原版镜像还是精简版镜像，精简版往往把sxs文件夹切掉了。

接下来是CPU架构的坑。显微镜摄像头厂商的驱动以32位为主，很多64位系统上厂商根本没提供x64驱动。如果整个项目用AnyCPU编译，在64位系统上进程是64位的，DirectShow加载32位驱动滤镜时会静默失败，最常见的结果是设备枚举有名字，但一建Graph就抛0x80040217（VFW_E_CANNOT_CONNECT）。实际项目里我建议采集模块固定x86编译，业务层可以是AnyCPU或64位，采集模块通过本机Socket把压缩后的JPEG传给上层报告模块。TCT图像分辨率高，单帧可能2048x1536，跨进程传图听起来重，但一张JPEG压到200KB以内走本机回环，实际只要几毫秒，远比自己跟驱动兼容性死磕划算。

选型阶段可以把这两条路线的差别做成判断表，我在设计评审时常用的口径如下。

这四行看起来简单，却是现场踩坑换来的。医院信息科可能下周就给你换一台不同品牌的摄像头来源，抽象层做得越早，后面越省命。

3. 搭采集管线：用 C# 调 DirectShow 从显微镜摄像头拿帧的最小可跑方案

3.1 枚举摄像头：拿到设备名列表的第一段代码

显微镜摄像头插上USB或接上采集卡后，DirectShow会把它注册为“视频输入设备”。C#侧第一步是把设备列表列出来，这在DirectShowLib里只需要一段循环：

using DirectShowLib; var devices = DsDevice.GetDevicesOfCat(FilterCategory.VideoInputDevice); for (int i = 0; i < devices.Count; i++) { Console.WriteLine($"[{i}] {devices[i].Name}"); }

DsDevice.GetDevicesOfCat 是DirectShowLib封装好的静态方法，按设备类别枚举系统注册表里的DirectShow滤镜。FilterCategory.VideoInputDevice 对应“视频输入设备”分类，返回列表里每个项的Name是注册名称，通常是摄像头商标加型号，比如“HC2800 Series Camera”或“USB Camera”。

这段代码的运行结果受32/64位影响：64位进程只能看到64位驱动注册的设备，32位进程只能看到32位驱动的。医院现场最常见的现象是：装好摄像头驱动后，厂商工具能出画，但自己的程序枚举列表是空的。先别改代码，先检查编译平台是不是x86，再去注册表看HKLM\SOFTWARE\WOW6432Node\Classes\CLSID下是否存在摄像头滤镜的CLSID，存在就说明是32位驱动，程序必须x86编译。

3.2 构建 Graph 并挂上 SampleGrabber：拿到帧的完整流程

拿到设备索引后，构建采集图是整个采集模块的心脏。下面这段是最小可跑的构建代码，把源滤镜加入FilterGraph，再把SampleGrabber接在源滤镜的输出引脚后面：

using DirectShowLib; var builder = (ICaptureGraphBuilder2)new CaptureGraphBuilder2(); var graph = (IFilterGraph)new FilterGraph(); builder.SetFiltergraph(graph); // 根据设备索引创建源滤镜 var source = (IBaseFilter)Activator.CreateInstance( Type.GetTypeFromCLSID(devices[deviceIndex].Clsid)!); graph.AddFilter(source, "source"); // 创建 SampleGrabber 并设置媒体类型 var grabber = (ISampleGrabber)new SampleGrabber(); var grabberFilter = (IBaseFilter)grabber; var mediaType = new AMMediaType(); mediaType.majorType = MediaType.Video; mediaType.subType = MediaSubType.RGB24; grabber.SetMediaType(mediaType); graph.AddFilter(grabberFilter, "grabber"); // 用捕获构建器把源滤镜和 SampleGrabber 连接起来 builder.RenderStream(PinCategory.Capture, MediaType.Video, source, null, grabberFilter); // 启动运行图 var mediaControl = (IMediaControl)graph; mediaControl.Run();

SetFiltergraph 把构建器和图绑定，AddFilter 把源滤镜和SampleGrabber滤镜都塞进图里。SetMediaType 告诉SampleGrabber我们要RGB24格式，这一步很关键，因为DirectShow会按这个格式协商连接，如果摄像头不支持RGB24，系统会自动插颜色转换滤镜，但转换过程中颜色精度会有可见损失。RenderStream 自动在源滤镜和目标之间找可用路径，途中会插入必要的转换滤镜。mediaControl.Run() 启动整个图，之后数据开始流动。

注意这段代码只建立了连接，还没有设置帧回调。要拿到每一帧的数据，必须让SampleGrabber工作在回调模式，并实现ISampleGrabberCB接口：

class FrameCallback : ISampleGrabberCB { public int SampleCB(double sampleTime, IMediaSample pSample) => 0; public int BufferCB(double sampleTime, IntPtr pBuffer, int bufferLen) { // 图像缓冲区指针，这里必须立刻拷贝成托管数组 byte[] copy = new byte[bufferLen]; Marshal.Copy(pBuffer, copy, 0, bufferLen); // 把 copy 交给队列或触发事件，交给 UI 侧取走 return 0; } }

BufferCB 是DirectShow把RGB24数据按字节拷贝到缓冲区后触发的回调，参数pBuffer指向数据起始位置，bufferLen是这一帧的字节数。算出这个缓冲区大小的公式是：宽乘以高乘以3（RGB24每像素3字节），再加上行对齐填充。代码里必须马上Marshal.Copy拷贝走，否则DirectShow内部缓冲会在回调返回后失效；而回调里new一个byte[]每帧都会产生GC压力，这也是后面避坑章里要展开的内存话题。

3.3 分辨率、帧率、曝光与白平衡：TCT 图像采集的几个关键参数

分辨率与帧率由IAMStreamConfig接口设置。常见做法是先取当前配置，修改视频信息头，再调用SetFormat。许多显微镜摄像头在预览时用640x480，抓取时切到硬件最高分辨率（比如2048x1536）再截一帧。切换分辨率后是否需要在Stop状态下重新运行Graph，不同厂商处理不一致，稳妥做法是改分辨率前先Stop，设置完再Run。

曝光和增益走IAMCameraControl接口，白平衡和亮度走IAMVideoProcAmp，三者共同的调用模式是“属性ID + 值 + 自动标志”。TCT染色图以紫红色和蓝色为主，细胞核深染，如果白平衡偏了，报告里的图像整体发蓝或发黄，病理医生会直接质疑系统。所以采集端一定要关闭自动白平衡，用固定的色温值标定；把自动曝光切到手动，设定固定曝光时间，防止不同玻片之间亮度不一致。附加好处是：后续做细胞图像分析时，光照一致性直接影响阈值分割效果，规则越稳定，算法越可靠。

这里给一组我常用的起始参数：分辨率设为摄像头的硬件最大分辨率，帧率预览时压到15FPS省带宽，抓图时切回最大分辨率；曝光时间手动设为8ms到15ms之间，视显微镜光源亮度而定；增益尽量压在1.0附近，增益一高暗部噪声立刻显现。每个摄像头标定时，拿一张标准TCT染色片在不同曝光下各拍一张，肉眼挑出细胞边界最锐利、背景最干净的那档，把参数写进配置项，现场换镜头光源时再微调。

4. 图文报告与 PACS 归档：TCT 图像如何进入医院影像流

4.1 报告排版与图像标注：从采集图到诊断报告的最小步骤

TCT图文报告的输出通常是两个方向：一个是本院LIS/病理系统里生成结构化报告，另一个是打印成纸质或PDF给患者追踪。生成结构化报告，我一般用HTML模板转PDF，因为病理科报告模板变化频繁，HTML改样式比改程序的界面快得多。嵌图时注意把采集到的Bitmap转成Base64放进 标签；如果报告里需要多个视野图，就按“取材部位+放大倍数+视野坐标”命名图片，在模板对应位置引用。

图像标注这个环节容易被忽略。病理医生希望在报告里圈出可疑细胞区域，再写上诊断意见。标注数据要用独立的图层保存，不能直接画进原始Bitmap里。我用的是一个Layer对象，内部保存一个List<标注图形>，每个标注图形从C#的Shape基类派生，记录矩形或椭圆和注释文本。报告生成时，原始图像和标注图层分开输出，这样医生改诊断意见时不需要重新截一张图。

C#的文档注释在这个阶段可以真正派上用场：给报告模板和标注类写上XML注释后，用Sandcastle或DocFX生成内部API文档，交付给信息科做二次开发时，对方不用翻源码就能知道哪些接口能调。医院信息系统的人员流动大，交接时一份完整的类注释比口头讲十遍强得多。

4.2 DICOM 与 PACS 对接：没有 DICOM 网关时的过渡方案

TCT图像要进PACS，正规路径是转成DICOM格式，走DICOM存储SCU推到PACS服务器。但很多医院病理科的PACS节点只开放了DICOM Web（QIDO-RS/WADO-RS）接口，传统的DICOM C-STORE走不通，这种情况就需要做一层适配。我遇到过的最小可行方案是：把TCT报告转成PDF或JPEG，用WADO-RS的的POST接口上传到PACS的“外部文档”节点，再在PACS系统里生成一条指向该文档的检查记录。

如果你需要直接推送DICOM，丢开自己手写DICOM消息常见的做法是fork一份开源的DICOM库（比如fo-dicom或者其他语言对应的实现），只保留C-STORE和DICOMDIR生成部分。需要注意DICOM里必须填写的PatientID、AccessionNumber、StudyInstanceUID、SeriesInstanceUID、SOPInstanceUID这些必填字段，缺哪个，PACS就回一个拒绝状态。我用fo-dicom（C#版本）构建Study/Series时习惯把SOPInstanceUID用Guid.NewGuid的N格式生成，同时把acquisitiondatetime取当前时间写入，避免同一次检查重复上传时UID冲突。

DICOM对接还有一个在医院环境里很磨人的点：PACS服务器网络地址经常是内网IP，走HTTPS时证书链不完备，.NET的HttpClient会直接抛SSL策略异常。联调时先确认PACS是http还是https，如果对方坚持https但证书是自签的，代码里加一个只在调试期生效的ServerCertificateCustomValidationCallback，生产环境必须换正式证书。这个坑几乎每个做PACS对接的团队都会遇到，表现形式千奇百怪，但根因都是证书信任链。

4.3 批量归档与失败重试：PACS 上传的并发与幂等策略

TCT系统常态是每天几百例，每例2到6幅图，批量上传时如果每传一个文件就起一个Thread，几轮下来PACS服务器和本机都会出问题。我用的是生产-消费模型加信号量限流：采集线程把待上传的图文记录放入ConcurrentQueue，后台两个上传线程以固定速率消费。每一条记录里保存一个UploadId（用Guid），PACS的回传确认会记录这个UploadId，再次上传时先查本地数据库有没有成功标记，避免重复上送。

private readonly SemaphoreSlim _gate = new(2, 2); async Task UploadAsync(ReportRecord record, CancellationToken ct) { await _gate.WaitAsync(ct); try { bool ok = await PushToPacsAsync(record, ct); if (ok) { record.UploadedAt = DateTime.Now; SaveMark(record.UploadId); } } catch (HttpRequestException ex) // 远程主机强迫关闭连接等网络异常 { Log.Error("PACS 上传失败, UploadId={UploadId}, 原因={Reason}", record.UploadId, ex.Message); } finally { _gate.Release(); } }

SemaphoreSlim在这里把并发上传数钉在2，避免瞬时把PACS压垮；HttpRequestException捕获网络层最典型的“远程主机强迫关闭了一个现有的连接”这类错误；SaveMark把成功标记落库，断网重发时先查这个标记。网络错误要区分是临时故障还是永久失败，临时故障做指数退避重试（第一次等2秒、第二次等4秒、最多三次），永久失败进手工处理队列，不要无脑循环。

5. 避坑指南：从黑屏到上传失败的四类真实排查记录

5.1 摄像头黑屏：Graph 构建成功但 SampleGrabber 收不到帧

现象：枚举设备正常，Graph构建不报错，Run之后预览窗口黑屏，SampleGrabber的回调一次都不触发。

原因：最常见的是摄像头被分辨率或格式协商卡住了。很多显微镜摄像头的DirectShow滤镜在预览模式只输出YUY2，而SampleGrabber强制要求RGB24，RenderStream虽然插入了颜色转换滤镜，但插入位置不对，数据流没有实际经过SampleGrabber。另外CAMERA在有些驱动下必须先在预览引脚Render一次，才能在捕获引脚出数据，直接只连Capture引脚会黑屏。

解决：先不设SetMediaType的subType，让DirectShow用默认格式连接，收到帧后自己转颜色；或者按官方示例先RenderStream一个预览引脚，再加SampleGrabber。现场排查时先用GraphEdit/GraphStudioNext打开同一个Graph，看数据流经过哪个滤镜断了，比自己猜快得多。

5.2 图像偏色：RGB24 与 YUY2 转换导致 TCT 染色图色彩发蓝

现象：摄像头画面在厂商工具里颜色正常，在自研系统里整体偏蓝、偏紫，细胞核和细胞质的色差变小。

原因：摄像头原生输出YUY2，DirectShow自动插入的颜色转换滤镜在转换时色彩矩阵选择不对，或者色温被系统重置到自动模式。TCT染色图本身以紫蓝色调为主，一旦转换偏差，看起来就是一片蓝紫分不清层次。

解决：采集端把自动白平衡关掉，锁定固定色温。同时在Graph里主动插入Color Converter滤镜，并在它前面把AMStreamConfig的视频格式改成YUY2，让它自己处理。一句话原则：不要让DirectShow隐式插入你不知道在哪的转换器，而是自己明确控制转换路径。

5.3 “远程主机强迫关闭了一个现有的连接”：PACS 上传中断的真实原因

现象：批量上传PC到一半，抛HttpRequestException：远程主机强迫关闭了一个现有的连接，后续所有记录全部失败。

原因：尾病例大多是PACS服务器端对长连接设置了空闲超时，或者上传的JPEG体积超过服务器默认的请求体上限。还有一个隐蔽原因：PACS的WADO端口是HTTP，但你在代码里用了共用HttpClient，前面的HTTPS请求和后面的HTTP走同一个连接池，协议不同导致连接被服务端强制关闭。

解决：把PACS上传请求按协议分开两个HttpClient实例，每个都设置连接空闲超时（ServicePointManager.MaxIdleTime），上传请求体限制先问清楚PACS管理员。HttpClient一定要用单例，不要每传一个文件就new一个；这个属于C#基础问题，但在对接现场踩上的人特别多。

5.4 32/64 位不匹配：设备枚举到了但一连接就失败

现象：代码里能枚举到摄像头名字，但RenderStream失败，报找不到合适的滤镜或者未指定错误，厂商Demo却能正常出画。

原因：厂商Demo是32位程序，你的程序是64位，或者反过来。DirectShow滤镜的注册位置分为32位和64位两套，进程位数决定注册表查找路径，两边各看各的，互不干扰。

解决：采集模块固定x86编译，并把AnyCPU项目的“Prefer 32-bit”选项关掉，确保进程位数一致。交付部署时在安装包里加一个检查工具，列出当前进程位数和摄像头CLSID注册位数，现场一眼就能定位。

5.5 内存暴涨：Bitmap 释放时机与缓冲池复用

现象：系统运行几个小时后内存从300MB涨到2GB，最后卡死，重启后正常。

原因：回调里每帧都new byte[]和Bitmap，交给UI后没有释放，DirectShow缓冲又被GC拖住不回收。还有在BufferCB里把拷贝后的数组再转换成Bitmap然后丢弃，造成双份内存压力。

解决：帧缓冲用对象池复用，队列里只保留最新一帧；Bitmap用using或手动Dispose。我在代码里定义了一个不超过2的缓冲池，抓帧时从池里取byte[]，用完归还。UI显示后立即做一次Bitmap克隆并释放原对象。这个改动把长期运行内存曲线从持续上涨变成一条直线。

6. 发布前的一个关键习惯：用帧时间戳把采集、报告、归档整条链路串起来验证

TCT系统最容易出的问题不是某个功能不能用，而是链路各环节的时间基准不一致：采集端认为抓的是10点02分的图，报告里盖的是10点02分的采集时间戳，PACS里记录的是10点10的上传时间。医生复查时按时间检索找不到图，根因就在这里。我养成的习惯是：从采集到归档，全链路只认一个时间源——采集帧在DirectShow回调里被拷贝走的那一刻，用Stopwatch.GetTimestamp记录，之后报告生成、上传PACS都沿用这个时间戳，不再重新取系统时间。

验证这套机制可以写一个小的自检流程：程序启动时自动抓一帧，记录采集时间戳；然后生成一份含该图的测试报告并提交到PACS测试节点；再从PACS查询这条记录，比较三个时间是否一致。用 SQL 检查本地库里采集时间、上传时间和PACS回执时间三者关系，一次跑通，基本可以说明链路是通的。这个自检步骤在每次更换摄像头或调整PACS地址后都跑一遍，能省掉现场一半以上的扯皮。

我自己的习惯是把这条自检写进日常工具里，交付时给信息科演示一次，之后他们自己也能跑。现场维护少踩坑，才是这套方案真正值得复制的理由。希望这个完整的“采集-报告-归档”链路梳理能帮到你，祝你的TCT系统上线顺利。

本文还有配套的精品资源，点击获取