远程医疗中实时阅片系统的设计

高智勇，李学衡

(中南民族大学生物医学工程学院，武汉430074)

远程医疗从广义上讲是指:使用远程通信技术、全息影像技术、新电子技术和计算机多媒体技术，发挥大型医学中心医疗技术和设备优势，对医疗卫生条件较差的及特殊环境提供远距离医学信息和服务.狭义上讲:包括远程影像学、远程诊断及会诊、远程护理等医疗活动.实时阅片系统就是大型医学中心的专家利用自身的医学经验和良好的医疗设备对医疗卫生条件较差环境的医生就病人的影像资料进行交流和指导，最后给出诊断［1-4］.此阅片系统是其他远程医疗活动的基础，因此良好的实时阅片系统的设计是远程医疗系统中最重要的组成部分之一.

目前，GE、飞利浦、西门子等国外医疗行业巨头在远程医疗的整个系统的设计和产品已经相当成熟，设计系统中阅片速度是很快，性能稳定，但价格贵.而国内的公司产品价格便宜但阅片速度达不到实际应用的要求.故本文重点工作为在不增加硬件成本的前提下，提高阅片

与显示速度，以能够满足实际应用的速度要求，同时降低整套系统的价格.

1 远程实时阅片系统

国家十二五计划中医疗保障行业规划提出了远程医疗的基本硬件架构:远程医疗之间的通信线路为光纤专线(20MB)，整个系统的设计可以基于局域网进行运行设计.局域网采用客户端/服务器(C/S)模式，在C/S模式中S端负责拷屏、数据预处理、压缩编码，C端负责控制拷屏、解码、影像显示等功能.C/S模式的通信采用基于Socket实现进程间通信［5］.远程实时阅片系统的框架图如图1所示.

图1 远程实时阅片系统框架图Fig.1 Framework map of real time diagnostic system

在具体实现时，阅片系统的各功能模块按多线程进行展开.当用PACS View打开DICOM医学影像时，实时阅片系统的服务端主要负责将屏幕上的医学影像拷贝到内存中，再将内存影像数据进行处理并压缩.针对服务端任务，可以创建并行处理线程和抓屏主线程两个线程处理相应任务.客户端也创建两个线程:接受服务器处理线程和发送客户端命令线程，以处理客户端任务.接受服务器处理线程主要处理对服务器端传输过来的影像数据进行解码，数据预处理的反操作，在客户端显示等功能.发送客户端命令线程主要完成局域网通信通畅的确认，以及客户端界面的操作消息传递等任务.

当客户端打开子进程VNC Client.exe，服务端打开子进程VNC Server.exe时，客户端通过连接服务端的IP发送连接请求，服务端选择接受请求，VNC实现远程控制，实现阅片.

虽然阅片系统的速度随着数据量的大小、各模块实现的技术方法不同而有较大的差异，但是系统要求最终的效果是C/S两端操作能够同步流畅.影响系统执行速度主要有两个原因:(1)由于所需处理的影像为DICOM格式，其分辨率为1080P，所需要进行处理和传输的数据量本身就很大;(2)专家在阅读和处理DICOM影像时，会对影像进行操作，如对影像进行拖动，放大和缩小等，需要实时处理和更新显示相关影像.对应阅片系统的工作流程，阅片系统中的各模块的耗时也会有所不同.在系统的服务端耗时比较多的是拷屏、编码等技术环节，客户端耗时比较多的是解码等技术环节.为了提高系统执行速度，同时保证整个画面的同步和流畅性，本文从影像拷屏，编码，解码等多个技术环节进行综合考虑，以提高系统处理速度.

2 VNC服务端

本系统用于实现服务端功能的两个线程分别是抓屏主线程和并行处理线程.

抓屏主线程主要负责实现影像的快速拷贝.远程阅片系统速度很大程度上取决于拷屏速度，如果拷屏的帧率小，后续的相关处理也会较为缓慢，从而导致系统处理速度变慢.故选择合适的拷屏方式非常重要.此外，由于本系统在实际操作的时候，光标经常移动，造成拷屏前后图像变化频繁，因此有必要对拷屏之后的图像进行预处理，对图像进行分割，以减少编码的数据量.

并行处理线程主要实现图像的快速编码.针对DICOM影像的特点和远程医疗系统的要求，需要选择合适的编码方法.

2.1 抓屏主线程

(1)服务端的连续拷屏.

通常拷屏有两种方式:使用GDI函数拷屏和使用DirectX方式拷屏.GDI函数拷屏方式认为桌面也是一个窗口，桌面也有一个窗口句柄(HWND).具体实现时，首先得到桌面的窗口句柄和桌面窗口的DC，然后创建和屏幕兼容的位图和DC并把这个位图选进该DC.当准备好抓屏时，就复制桌面窗口DC的内容到兼容DC，完成抓屏过程，最后释放创建的对象.其伪代码如下:

void CaptureScreen()

{

GetDesttopWindow();//得到桌面的窗口句柄;

GetDC();//取得桌面窗口的DC;

CreateCompatibleBitmap();

CreateCompatibleDC();//创建和屏幕DC兼容的位图和DC

SelectObject();//把这个位图选进该DC

BitBlt();//复制桌面窗口DC的内容到兼容DC

ReleaseDC();

ReleaseDC();

DeleteObject();//释放创建的对象

}

DirectX方式拷屏中，为每个DirectX程序设置一个缓冲的内存区域-前台缓冲.前台缓冲保存了与桌面相关的显存内容，即屏幕图像.Direct3Ddevice9接口提供了前台缓冲获得方法，使用Direct3Ddevicesurface9得到图像数据的机制，再把这些数据复制到指定的内存即可.其伪代码如下:

void CaptureScreen()

{

Direct3Ddevice9-＞ GetFrontBuffer();//获得前台缓冲，得到对象指针

Direct3Ddevicesurface9-＞ LockRect();//捕捉到图像数据

Memcpy();//把捕捉到的图像复制到程序定义的内存中，即可对图像进行处理

Direct3Ddevicesurface9-＞UnlockRect();//释放

}

为了满足实时阅片系统的要求，本文在分别对上述两种方法进行分析和测试.测试结果表明GDI函数方式以24bitBmp格式拷屏的帧频达到75左右，但DirectX方式帧频只有不到30.GDI的帧数能达到系统要求，故本系统采用GDI方式拷屏.

(2)图像预处理.

在阅片过程中，大部分需要显示的图像并不会有太大改变.除了进行缩放、拖动等操作外，图像的变化大部分是由于鼠标变换所造成的局部变化.针对阅片系统的这一特点，为了减少数据量，本文把一帧图像人为地分割成若干个128×128图像块.这样可以实时捕捉图像的局部变化，既能减少处理的图像数据量，又能反映出前后两帧图像的变化.

在具体实现过程中，图像或屏幕分辨率不一定是128的整数倍.此时对于不能被整除的边缘像素不做处理，以避免在客户端上显示出黑栅条纹.从程序实现的角度来看，造成前后两帧图像变化的主要原因有由键盘、鼠标光标的变换所产生的消息而造成的.因此，只需要对相应消息进行响应就可以实现图像局部变化、更新和显示.

VNC S端在创建抓屏主线程，把屏幕拷贝到内存之后，使用队列发送数据时，先判断队列中是否存在多条数据.如果队列只有一条数据就可以将数据直接发送出去;如果队列中存在多条数据就应该打成一大包再发送出去.最后把上述数据提交给并行处理线程.

2.2 并行处理线程

并行处理线程主要实现DICOM图像编码.图像编码技术有很多种，其中比较成熟的有H.264编码.H.264进行图像编码具有低码率、高质量、容错能力强、网络适应性强等优点.因此，本系统采用H.264 编码［6-8］.

H.264有 3 种测试模型:JM、X264、T264.由于JM模式实时性太差，本文采用X264、T264两种模型进行测试，通过测试客户端频繁拖动影像的流畅程度，以及拖动时所占用带宽的条件选取测试模式进行编解码.但由于X264只有编码，解码的码流还需要用FFMPEG的库进行解码.

在具体实现过程中，由于DICOM格式的图像存储格式为RGB，H.264能压缩的格式为YUV，故把RGB24格式的图像数据转化为YUV420.YUV格式采用4:2:0格式，每个像素12位，即1.5B.在程序中，声明一结构体类型的容器Vector ImageBox来记录每个线程负责处理的数据块.声明三个在动态内存中存储数据的一个数据流的类MemoryStream Buffer记录上次数据;NewBuffer记录当前数据;XorBuffer记录上次和当前Xor后的数据.

因为通过Buffer中的数据与NewBuffer中的当前数据进行异或运算，异或的结果为0，则说明两个数据块没有变化，为1说明数据发生变化.有考虑利用分块后图像的MD5码进行比较，虽然能判断出变化的结果，但比较数据的处理速度没有异或快.故选择用异或进行处理.

在抓屏主线程将拷屏的数据提交给并行处理线程之前，初始化相关数据，设置H.264编码的压缩损耗率等.在编码的时候压缩损耗率(quality 1～6，1质量最高，压缩率最低)设置为2.

3 VNC客户端

客户端也包括两个线程:发送命令线程和接收服务器命令进行处理线程.其中耗时比较多的就是命令处理线程中的码流解码过程.由于服务端选用T264编码，解码只能 T264解码，X264也只能用FFMPEG进行解码.为了提高系统运行速度，本文对FFMPEG解码也进行了相应的优化.

3.1 VNC客户端发送命令线程

客户端发送命令线程主要是客户端的操作信息的发送，在此之前要打开系统两端的通信通道，并测试局域网通信是否畅通.在发送的过程中将要发送数据放在发送队列里，对数据量进行判断后再发送.如果队列里只有一个数据，就直接发送;如果队列有多个数据，就打成一个大包一同发送.同时线程给上层进程发送消息的机制.

3.2 VNC客户端接收服务器命令进行处理线程

客户端接收服务器命令进行处理线程主要负责对服务端发送过来的界面操作消息进行处理.系统中鼠标的移动信息在客户端和服务端是一致的(即客户端鼠标发生移动时，服务端也有相同的移动，同时在服务端操作鼠标时，客户端的鼠标做响应的动作)，此时鼠标消息和图像数据分开处理.当鼠标的信息发生更新时，客户端会将利用Zip压缩算法把上述消息压缩成具有鼠标属性的数据结构.当客户端接收到服务端请求更新时，把网络传输过来已经编码的图像数据存放在接收队列中进行解码.

本文采用FFMPEG来解码X264的数据流和T264的解码.FFMPEG是一个在Linux平台下开发的开源免费跨平台的视频和音频流方案，包含性能强大的音视频编解码库libavcodec，有很高的可移植性和编解码质量.为了能够使用上述编解码库，需要把在Linux系统下开源代码移植到windows平台，并针对本系统的特点进行优化.重点工作是为解码器分配内存avcodec_alloc_frame()、获得一个Nal数据nalLen=getNextNal()，之后对 Nal解码 avcodec_decode_video.为了能够在客户端显示影像，需要对解码后的码流进行反预处理.把解码后的YUV做异或运算后恢复压缩之前的图像数据.最后在客户端进行医学影像进行显示.

4 系统测试

本系统利用dephi编写阅片系统界面，以及整个系统的代码.系统实现后，利用DICOM格式的医学图像进行测试，侧重点在于测试X264与T264流畅性和带宽.

本文采用量化参数(QP范围0～51)恒定的方式进行编码.经过测试当QP＞25时，传输过来的图像经过放大出现明显的马赛克现象，当QP＜20时，传输过来的图像速度慢.本文取QP=23，图像质量，传输速度皆达到要求.

服务端利用PACSView打开DICOM影像资料.在实验中发现，当快速频繁的拖动DICOM影像资料，X264编码的图像在客户端流畅性很好，能满足实际的应用要求.两种方案的测试结果见表1.通过测试结果可以看出，采用X264编码，FFMPEG方式解码，图像的传输速度能达到实时阅片系统的要求.

表1 不同解码方式下的传输与显示速度Tab.1 Transmission and display speed in different decoding ways

与其它通用图像传输系统如qq、Lync sevre2010远程控制的效果相比，qq、Lync server2010远程控制中传输的图像分辨率为720P，图像质量达不到医学图像要求.

现有阅片系统如GE、飞利浦、西门子等公司的远程医疗系统的中阅片系统的在不同操作情况下的流量大体如下:正常放大、缩小、拖动的流量:380～470KBit/s，急速放大、缩小、拖动的最高流量:18.5MBit/s.对比与目前已成熟的远程阅片系统如表2.

表2 不同实时阅片系统显示速度Tab.2 Display speed of different real time diagnostic system

从表2可以看出，本系统在性能方面基本接近或超过同类成熟产品.此外，对本系统进行了长时间模拟实际远程医疗应用，结果表明本系统具有很好地稳定性，能很好地满足实时阅片系统实际操作要求.

采用锐取公司的高清编码器DSS-ENC-1000来专门处理DICOM图像压缩、传输等技术环节，通过样机测试，在阅片过程中正常放大、缩小、拖动的流量为280～300KBit/s，急速放大、缩小、拖动的流量为13.5 MBit/s.与本系统相比，虽然本系统测试结果稍差，但是考虑到其性能已经能到达实际应用要求，没有必要应用高清编码器来增加系统的成本.

5 结语

本文设计了一种远程医疗中的实时阅片系统，很好地解决了因为图像数据量大而带来的处理速度慢问题.在不改变硬件环境的条件下，采用GDI函数方式进行拷屏，对图像进行分块预处理，采用X264编码与移植后的FFMPEG解码，使得整个系统的处理速度与国外同类成熟产品接近，基本可以替代;与使用编码器的系统相比，性能稍差但是成本却大为降低，具有很好的市场效应.在实际应用中，可以在此系统基础上添加语音系统、摄像系统、录播、转播等功能模块，开发出完整的远程医疗会诊系统.

［1］李奕霖.重庆市新桥医院远程医疗会诊系统的设计与实现［D］.重庆:重庆大学，2008.

［2］聂秀英.标准与远程医疗服务［J］.电信网技术，2011，3(8):31-34.

［3］张祺琪，刘敬浩.远程医疗会诊系统的设计与实现［D］.天津:天津大学，2012.

［4］杜南，韩燮.基于DICOM的远程医疗系统的实际与实现［D］.太原:中北大学，2011.

［5］庞倩.远程医疗视频通信融合平台解决方案［J］.中国新通信，2010，1(19):77-79.

［6］毕厚杰.新一代视频压缩编码标准—H264/AVC［M］.北京:人民邮电出版社，2005.

［7］Wiegand S，Sullivan G.J，Bjontegaard G，et al.Overview of the H.264/AVC Videa Coding Standard［J］.IEEE Trans Circuits and Systems for Video Technology，2003，7(7):560-576.

［8］Wenger G.H.264/AVC over IP［J］.IEEE Trans Circuits and Systems for Video Technology，2003，7(7):645-656.