高智勇，李學(xué)衡

(中南民族大學(xué)生物醫(yī)學(xué)工程學(xué)院，武漢430074)

遠(yuǎn)程醫(yī)療從廣義上講是指:使用遠(yuǎn)程通信技術(shù)、全息影像技術(shù)、新電子技術(shù)和計(jì)算機(jī)多媒體技術(shù)，發(fā)揮大型醫(yī)學(xué)中心醫(yī)療技術(shù)和設(shè)備優(yōu)勢(shì)，對(duì)醫(yī)療衛(wèi)生條件較差的及特殊環(huán)境提供遠(yuǎn)距離醫(yī)學(xué)信息和服務(wù).狹義上講:包括遠(yuǎn)程影像學(xué)、遠(yuǎn)程診斷及會(huì)診、遠(yuǎn)程護(hù)理等醫(yī)療活動(dòng).實(shí)時(shí)閱片系統(tǒng)就是大型醫(yī)學(xué)中心的專家利用自身的醫(yī)學(xué)經(jīng)驗(yàn)和良好的醫(yī)療設(shè)備對(duì)醫(yī)療衛(wèi)生條件較差環(huán)境的醫(yī)生就病人的影像資料進(jìn)行交流和指導(dǎo)，最后給出診斷［1-4］.此閱片系統(tǒng)是其他遠(yuǎn)程醫(yī)療活動(dòng)的基礎(chǔ)，因此良好的實(shí)時(shí)閱片系統(tǒng)的設(shè)計(jì)是遠(yuǎn)程醫(yī)療系統(tǒng)中最重要的組成部分之一.

目前，GE、飛利浦、西門子等國(guó)外醫(yī)療行業(yè)巨頭在遠(yuǎn)程醫(yī)療的整個(gè)系統(tǒng)的設(shè)計(jì)和產(chǎn)品已經(jīng)相當(dāng)成熟，設(shè)計(jì)系統(tǒng)中閱片速度是很快，性能穩(wěn)定，但價(jià)格貴.而國(guó)內(nèi)的公司產(chǎn)品價(jià)格便宜但閱片速度達(dá)不到實(shí)際應(yīng)用的要求.故本文重點(diǎn)工作為在不增加硬件成本的前提下，提高閱片

與顯示速度，以能夠滿足實(shí)際應(yīng)用的速度要求，同時(shí)降低整套系統(tǒng)的價(jià)格.

1 遠(yuǎn)程實(shí)時(shí)閱片系統(tǒng)

國(guó)家十二五計(jì)劃中醫(yī)療保障行業(yè)規(guī)劃提出了遠(yuǎn)程醫(yī)療的基本硬件架構(gòu):遠(yuǎn)程醫(yī)療之間的通信線路為光纖專線(20MB)，整個(gè)系統(tǒng)的設(shè)計(jì)可以基于局域網(wǎng)進(jìn)行運(yùn)行設(shè)計(jì).局域網(wǎng)采用客戶端/服務(wù)器(C/S)模式，在C/S模式中S端負(fù)責(zé)拷屏、數(shù)據(jù)預(yù)處理、壓縮編碼，C端負(fù)責(zé)控制拷屏、解碼、影像顯示等功能.C/S模式的通信采用基于Socket實(shí)現(xiàn)進(jìn)程間通信［5］.遠(yuǎn)程實(shí)時(shí)閱片系統(tǒng)的框架圖如圖1所示.

圖1 遠(yuǎn)程實(shí)時(shí)閱片系統(tǒng)框架圖Fig.1 Framework map of real time diagnostic system

在具體實(shí)現(xiàn)時(shí)，閱片系統(tǒng)的各功能模塊按多線程進(jìn)行展開.當(dāng)用PACS View打開DICOM醫(yī)學(xué)影像時(shí)，實(shí)時(shí)閱片系統(tǒng)的服務(wù)端主要負(fù)責(zé)將屏幕上的醫(yī)學(xué)影像拷貝到內(nèi)存中，再將內(nèi)存影像數(shù)據(jù)進(jìn)行處理并壓縮.針對(duì)服務(wù)端任務(wù)，可以創(chuàng)建并行處理線程和抓屏主線程兩個(gè)線程處理相應(yīng)任務(wù).客戶端也創(chuàng)建兩個(gè)線程:接受服務(wù)器處理線程和發(fā)送客戶端命令線程，以處理客戶端任務(wù).接受服務(wù)器處理線程主要處理對(duì)服務(wù)器端傳輸過來(lái)的影像數(shù)據(jù)進(jìn)行解碼，數(shù)據(jù)預(yù)處理的反操作，在客戶端顯示等功能.發(fā)送客戶端命令線程主要完成局域網(wǎng)通信通暢的確認(rèn)，以及客戶端界面的操作消息傳遞等任務(wù).

當(dāng)客戶端打開子進(jìn)程VNC Client.exe，服務(wù)端打開子進(jìn)程VNC Server.exe時(shí)，客戶端通過連接服務(wù)端的IP發(fā)送連接請(qǐng)求，服務(wù)端選擇接受請(qǐng)求，VNC實(shí)現(xiàn)遠(yuǎn)程控制，實(shí)現(xiàn)閱片.

雖然閱片系統(tǒng)的速度隨著數(shù)據(jù)量的大小、各模塊實(shí)現(xiàn)的技術(shù)方法不同而有較大的差異，但是系統(tǒng)要求最終的效果是C/S兩端操作能夠同步流暢.影響系統(tǒng)執(zhí)行速度主要有兩個(gè)原因:(1)由于所需處理的影像為DICOM格式，其分辨率為1080P，所需要進(jìn)行處理和傳輸?shù)臄?shù)據(jù)量本身就很大;(2)專家在閱讀和處理DICOM影像時(shí)，會(huì)對(duì)影像進(jìn)行操作，如對(duì)影像進(jìn)行拖動(dòng)，放大和縮小等，需要實(shí)時(shí)處理和更新顯示相關(guān)影像.對(duì)應(yīng)閱片系統(tǒng)的工作流程，閱片系統(tǒng)中的各模塊的耗時(shí)也會(huì)有所不同.在系統(tǒng)的服務(wù)端耗時(shí)比較多的是拷屏、編碼等技術(shù)環(huán)節(jié)，客戶端耗時(shí)比較多的是解碼等技術(shù)環(huán)節(jié).為了提高系統(tǒng)執(zhí)行速度，同時(shí)保證整個(gè)畫面的同步和流暢性，本文從影像拷屏，編碼，解碼等多個(gè)技術(shù)環(huán)節(jié)進(jìn)行綜合考慮，以提高系統(tǒng)處理速度.

2 VNC服務(wù)端

本系統(tǒng)用于實(shí)現(xiàn)服務(wù)端功能的兩個(gè)線程分別是抓屏主線程和并行處理線程.

抓屏主線程主要負(fù)責(zé)實(shí)現(xiàn)影像的快速拷貝.遠(yuǎn)程閱片系統(tǒng)速度很大程度上取決于拷屏速度，如果拷屏的幀率小，后續(xù)的相關(guān)處理也會(huì)較為緩慢，從而導(dǎo)致系統(tǒng)處理速度變慢.故選擇合適的拷屏方式非常重要.此外，由于本系統(tǒng)在實(shí)際操作的時(shí)候，光標(biāo)經(jīng)常移動(dòng)，造成拷屏前后圖像變化頻繁，因此有必要對(duì)拷屏之后的圖像進(jìn)行預(yù)處理，對(duì)圖像進(jìn)行分割，以減少編碼的數(shù)據(jù)量.

并行處理線程主要實(shí)現(xiàn)圖像的快速編碼.針對(duì)DICOM影像的特點(diǎn)和遠(yuǎn)程醫(yī)療系統(tǒng)的要求，需要選擇合適的編碼方法.

2.1 抓屏主線程

(1)服務(wù)端的連續(xù)拷屏.

通?？狡劣袃煞N方式:使用GDI函數(shù)拷屏和使用DirectX方式拷屏.GDI函數(shù)拷屏方式認(rèn)為桌面也是一個(gè)窗口，桌面也有一個(gè)窗口句柄(HWND).具體實(shí)現(xiàn)時(shí)，首先得到桌面的窗口句柄和桌面窗口的DC，然后創(chuàng)建和屏幕兼容的位圖和DC并把這個(gè)位圖選進(jìn)該DC.當(dāng)準(zhǔn)備好抓屏?xí)r，就復(fù)制桌面窗口DC的內(nèi)容到兼容DC，完成抓屏過程，最后釋放創(chuàng)建的對(duì)象.其偽代碼如下:

void CaptureScreen()

{

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

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

CreateCompatibleBitmap();

CreateCompatibleDC();//創(chuàng)建和屏幕DC兼容的位圖和DC

SelectObject();//把這個(gè)位圖選進(jìn)該DC

BitBlt();//復(fù)制桌面窗口DC的內(nèi)容到兼容DC

ReleaseDC();

ReleaseDC();

DeleteObject();//釋放創(chuàng)建的對(duì)象

}

DirectX方式拷屏中，為每個(gè)DirectX程序設(shè)置一個(gè)緩沖的內(nèi)存區(qū)域-前臺(tái)緩沖.前臺(tái)緩沖保存了與桌面相關(guān)的顯存內(nèi)容，即屏幕圖像.Direct3Ddevice9接口提供了前臺(tái)緩沖獲得方法，使用Direct3Ddevicesurface9得到圖像數(shù)據(jù)的機(jī)制，再把這些數(shù)據(jù)復(fù)制到指定的內(nèi)存即可.其偽代碼如下:

void CaptureScreen()

{

Direct3Ddevice9-＞ GetFrontBuffer();//獲得前臺(tái)緩沖，得到對(duì)象指針

Direct3Ddevicesurface9-＞ LockRect();//捕捉到圖像數(shù)據(jù)

Memcpy();//把捕捉到的圖像復(fù)制到程序定義的內(nèi)存中，即可對(duì)圖像進(jìn)行處理

Direct3Ddevicesurface9-＞UnlockRect();//釋放

}

為了滿足實(shí)時(shí)閱片系統(tǒng)的要求，本文在分別對(duì)上述兩種方法進(jìn)行分析和測(cè)試.測(cè)試結(jié)果表明GDI函數(shù)方式以24bitBmp格式拷屏的幀頻達(dá)到75左右，但DirectX方式幀頻只有不到30.GDI的幀數(shù)能達(dá)到系統(tǒng)要求，故本系統(tǒng)采用GDI方式拷屏.

(2)圖像預(yù)處理.

在閱片過程中，大部分需要顯示的圖像并不會(huì)有太大改變.除了進(jìn)行縮放、拖動(dòng)等操作外，圖像的變化大部分是由于鼠標(biāo)變換所造成的局部變化.針對(duì)閱片系統(tǒng)的這一特點(diǎn)，為了減少數(shù)據(jù)量，本文把一幀圖像人為地分割成若干個(gè)128×128圖像塊.這樣可以實(shí)時(shí)捕捉圖像的局部變化，既能減少處理的圖像數(shù)據(jù)量，又能反映出前后兩幀圖像的變化.

在具體實(shí)現(xiàn)過程中，圖像或屏幕分辨率不一定是128的整數(shù)倍.此時(shí)對(duì)于不能被整除的邊緣像素不做處理，以避免在客戶端上顯示出黑柵條紋.從程序?qū)崿F(xiàn)的角度來(lái)看，造成前后兩幀圖像變化的主要原因有由鍵盤、鼠標(biāo)光標(biāo)的變換所產(chǎn)生的消息而造成的.因此，只需要對(duì)相應(yīng)消息進(jìn)行響應(yīng)就可以實(shí)現(xiàn)圖像局部變化、更新和顯示.

VNC S端在創(chuàng)建抓屏主線程，把屏幕拷貝到內(nèi)存之后，使用隊(duì)列發(fā)送數(shù)據(jù)時(shí)，先判斷隊(duì)列中是否存在多條數(shù)據(jù).如果隊(duì)列只有一條數(shù)據(jù)就可以將數(shù)據(jù)直接發(fā)送出去;如果隊(duì)列中存在多條數(shù)據(jù)就應(yīng)該打成一大包再發(fā)送出去.最后把上述數(shù)據(jù)提交給并行處理線程.

2.2 并行處理線程

并行處理線程主要實(shí)現(xiàn)DICOM圖像編碼.圖像編碼技術(shù)有很多種，其中比較成熟的有H.264編碼.H.264進(jìn)行圖像編碼具有低碼率、高質(zhì)量、容錯(cuò)能力強(qiáng)、網(wǎng)絡(luò)適應(yīng)性強(qiáng)等優(yōu)點(diǎn).因此，本系統(tǒng)采用H.264 編碼［6-8］.

H.264有 3 種測(cè)試模型:JM、X264、T264.由于JM模式實(shí)時(shí)性太差，本文采用X264、T264兩種模型進(jìn)行測(cè)試，通過測(cè)試客戶端頻繁拖動(dòng)影像的流暢程度，以及拖動(dòng)時(shí)所占用帶寬的條件選取測(cè)試模式進(jìn)行編解碼.但由于X264只有編碼，解碼的碼流還需要用FFMPEG的庫(kù)進(jìn)行解碼.

在具體實(shí)現(xiàn)過程中，由于DICOM格式的圖像存儲(chǔ)格式為RGB，H.264能壓縮的格式為YUV，故把RGB24格式的圖像數(shù)據(jù)轉(zhuǎn)化為YUV420.YUV格式采用4:2:0格式，每個(gè)像素12位，即1.5B.在程序中，聲明一結(jié)構(gòu)體類型的容器Vector ImageBox來(lái)記錄每個(gè)線程負(fù)責(zé)處理的數(shù)據(jù)塊.聲明三個(gè)在動(dòng)態(tài)內(nèi)存中存儲(chǔ)數(shù)據(jù)的一個(gè)數(shù)據(jù)流的類MemoryStream Buffer記錄上次數(shù)據(jù);NewBuffer記錄當(dāng)前數(shù)據(jù);XorBuffer記錄上次和當(dāng)前Xor后的數(shù)據(jù).

因?yàn)橥ㄟ^Buffer中的數(shù)據(jù)與NewBuffer中的當(dāng)前數(shù)據(jù)進(jìn)行異或運(yùn)算，異或的結(jié)果為0，則說明兩個(gè)數(shù)據(jù)塊沒有變化，為1說明數(shù)據(jù)發(fā)生變化.有考慮利用分塊后圖像的MD5碼進(jìn)行比較，雖然能判斷出變化的結(jié)果，但比較數(shù)據(jù)的處理速度沒有異或快.故選擇用異或進(jìn)行處理.

在抓屏主線程將拷屏的數(shù)據(jù)提交給并行處理線程之前，初始化相關(guān)數(shù)據(jù)，設(shè)置H.264編碼的壓縮損耗率等.在編碼的時(shí)候壓縮損耗率(quality 1～6，1質(zhì)量最高，壓縮率最低)設(shè)置為2.

3 VNC客戶端

客戶端也包括兩個(gè)線程:發(fā)送命令線程和接收服務(wù)器命令進(jìn)行處理線程.其中耗時(shí)比較多的就是命令處理線程中的碼流解碼過程.由于服務(wù)端選用T264編碼，解碼只能 T264解碼，X264也只能用FFMPEG進(jìn)行解碼.為了提高系統(tǒng)運(yùn)行速度，本文對(duì)FFMPEG解碼也進(jìn)行了相應(yīng)的優(yōu)化.

3.1 VNC客戶端發(fā)送命令線程

客戶端發(fā)送命令線程主要是客戶端的操作信息的發(fā)送，在此之前要打開系統(tǒng)兩端的通信通道，并測(cè)試局域網(wǎng)通信是否暢通.在發(fā)送的過程中將要發(fā)送數(shù)據(jù)放在發(fā)送隊(duì)列里，對(duì)數(shù)據(jù)量進(jìn)行判斷后再發(fā)送.如果隊(duì)列里只有一個(gè)數(shù)據(jù)，就直接發(fā)送;如果隊(duì)列有多個(gè)數(shù)據(jù)，就打成一個(gè)大包一同發(fā)送.同時(shí)線程給上層進(jìn)程發(fā)送消息的機(jī)制.

3.2 VNC客戶端接收服務(wù)器命令進(jìn)行處理線程

客戶端接收服務(wù)器命令進(jìn)行處理線程主要負(fù)責(zé)對(duì)服務(wù)端發(fā)送過來(lái)的界面操作消息進(jìn)行處理.系統(tǒng)中鼠標(biāo)的移動(dòng)信息在客戶端和服務(wù)端是一致的(即客戶端鼠標(biāo)發(fā)生移動(dòng)時(shí)，服務(wù)端也有相同的移動(dòng)，同時(shí)在服務(wù)端操作鼠標(biāo)時(shí)，客戶端的鼠標(biāo)做響應(yīng)的動(dòng)作)，此時(shí)鼠標(biāo)消息和圖像數(shù)據(jù)分開處理.當(dāng)鼠標(biāo)的信息發(fā)生更新時(shí)，客戶端會(huì)將利用Zip壓縮算法把上述消息壓縮成具有鼠標(biāo)屬性的數(shù)據(jù)結(jié)構(gòu).當(dāng)客戶端接收到服務(wù)端請(qǐng)求更新時(shí)，把網(wǎng)絡(luò)傳輸過來(lái)已經(jīng)編碼的圖像數(shù)據(jù)存放在接收隊(duì)列中進(jìn)行解碼.

本文采用FFMPEG來(lái)解碼X264的數(shù)據(jù)流和T264的解碼.FFMPEG是一個(gè)在Linux平臺(tái)下開發(fā)的開源免費(fèi)跨平臺(tái)的視頻和音頻流方案，包含性能強(qiáng)大的音視頻編解碼庫(kù)libavcodec，有很高的可移植性和編解碼質(zhì)量.為了能夠使用上述編解碼庫(kù)，需要把在Linux系統(tǒng)下開源代碼移植到windows平臺(tái)，并針對(duì)本系統(tǒng)的特點(diǎn)進(jìn)行優(yōu)化.重點(diǎn)工作是為解碼器分配內(nèi)存avcodec_alloc_frame()、獲得一個(gè)Nal數(shù)據(jù)nalLen=getNextNal()，之后對(duì) Nal解碼 avcodec_decode_video.為了能夠在客戶端顯示影像，需要對(duì)解碼后的碼流進(jìn)行反預(yù)處理.把解碼后的YUV做異或運(yùn)算后恢復(fù)壓縮之前的圖像數(shù)據(jù).最后在客戶端進(jìn)行醫(yī)學(xué)影像進(jìn)行顯示.

4 系統(tǒng)測(cè)試

本系統(tǒng)利用dephi編寫閱片系統(tǒng)界面，以及整個(gè)系統(tǒng)的代碼.系統(tǒng)實(shí)現(xiàn)后，利用DICOM格式的醫(yī)學(xué)圖像進(jìn)行測(cè)試，側(cè)重點(diǎn)在于測(cè)試X264與T264流暢性和帶寬.

本文采用量化參數(shù)(QP范圍0～51)恒定的方式進(jìn)行編碼.經(jīng)過測(cè)試當(dāng)QP＞25時(shí)，傳輸過來(lái)的圖像經(jīng)過放大出現(xiàn)明顯的馬賽克現(xiàn)象，當(dāng)QP＜20時(shí)，傳輸過來(lái)的圖像速度慢.本文取QP=23，圖像質(zhì)量，傳輸速度皆達(dá)到要求.

服務(wù)端利用PACSView打開DICOM影像資料.在實(shí)驗(yàn)中發(fā)現(xiàn)，當(dāng)快速頻繁的拖動(dòng)DICOM影像資料，X264編碼的圖像在客戶端流暢性很好，能滿足實(shí)際的應(yīng)用要求.兩種方案的測(cè)試結(jié)果見表1.通過測(cè)試結(jié)果可以看出，采用X264編碼，F(xiàn)FMPEG方式解碼，圖像的傳輸速度能達(dá)到實(shí)時(shí)閱片系統(tǒng)的要求.

表1 不同解碼方式下的傳輸與顯示速度Tab.1 Transmission and display speed in different decoding ways

與其它通用圖像傳輸系統(tǒng)如qq、Lync sevre2010遠(yuǎn)程控制的效果相比，qq、Lync server2010遠(yuǎn)程控制中傳輸?shù)膱D像分辨率為720P，圖像質(zhì)量達(dá)不到醫(yī)學(xué)圖像要求.

現(xiàn)有閱片系統(tǒng)如GE、飛利浦、西門子等公司的遠(yuǎn)程醫(yī)療系統(tǒng)的中閱片系統(tǒng)的在不同操作情況下的流量大體如下:正常放大、縮小、拖動(dòng)的流量:380～470KBit/s，急速放大、縮小、拖動(dòng)的最高流量:18.5MBit/s.對(duì)比與目前已成熟的遠(yuǎn)程閱片系統(tǒng)如表2.

表2 不同實(shí)時(shí)閱片系統(tǒng)顯示速度Tab.2 Display speed of different real time diagnostic system

從表2可以看出，本系統(tǒng)在性能方面基本接近或超過同類成熟產(chǎn)品.此外，對(duì)本系統(tǒng)進(jìn)行了長(zhǎng)時(shí)間模擬實(shí)際遠(yuǎn)程醫(yī)療應(yīng)用，結(jié)果表明本系統(tǒng)具有很好地穩(wěn)定性，能很好地滿足實(shí)時(shí)閱片系統(tǒng)實(shí)際操作要求.

采用銳取公司的高清編碼器DSS-ENC-1000來(lái)專門處理DICOM圖像壓縮、傳輸?shù)燃夹g(shù)環(huán)節(jié)，通過樣機(jī)測(cè)試，在閱片過程中正常放大、縮小、拖動(dòng)的流量為280～300KBit/s，急速放大、縮小、拖動(dòng)的流量為13.5 MBit/s.與本系統(tǒng)相比，雖然本系統(tǒng)測(cè)試結(jié)果稍差，但是考慮到其性能已經(jīng)能到達(dá)實(shí)際應(yīng)用要求，沒有必要應(yīng)用高清編碼器來(lái)增加系統(tǒng)的成本.

5 結(jié)語(yǔ)

本文設(shè)計(jì)了一種遠(yuǎn)程醫(yī)療中的實(shí)時(shí)閱片系統(tǒng)，很好地解決了因?yàn)閳D像數(shù)據(jù)量大而帶來(lái)的處理速度慢問題.在不改變硬件環(huán)境的條件下，采用GDI函數(shù)方式進(jìn)行拷屏，對(duì)圖像進(jìn)行分塊預(yù)處理，采用X264編碼與移植后的FFMPEG解碼，使得整個(gè)系統(tǒng)的處理速度與國(guó)外同類成熟產(chǎn)品接近，基本可以替代;與使用編碼器的系統(tǒng)相比，性能稍差但是成本卻大為降低，具有很好的市場(chǎng)效應(yīng).在實(shí)際應(yīng)用中，可以在此系統(tǒng)基礎(chǔ)上添加語(yǔ)音系統(tǒng)、攝像系統(tǒng)、錄播、轉(zhuǎn)播等功能模塊，開發(fā)出完整的遠(yuǎn)程醫(yī)療會(huì)診系統(tǒng).

［1］李奕霖.重慶市新橋醫(yī)院遠(yuǎn)程醫(yī)療會(huì)診系統(tǒng)的設(shè)計(jì)與實(shí)現(xiàn)［D］.重慶:重慶大學(xué)，2008.

［2］聶秀英.標(biāo)準(zhǔn)與遠(yuǎn)程醫(yī)療服務(wù)［J］.電信網(wǎng)技術(shù)，2011，3(8):31-34.

［3］張祺琪，劉敬浩.遠(yuǎn)程醫(yī)療會(huì)診系統(tǒng)的設(shè)計(jì)與實(shí)現(xiàn)［D］.天津:天津大學(xué)，2012.

［4］杜南，韓燮.基于DICOM的遠(yuǎn)程醫(yī)療系統(tǒng)的實(shí)際與實(shí)現(xiàn)［D］.太原:中北大學(xué)，2011.

［5］龐倩.遠(yuǎn)程醫(yī)療視頻通信融合平臺(tái)解決方案［J］.中國(guó)新通信，2010，1(19):77-79.

［6］畢厚杰.新一代視頻壓縮編碼標(biāo)準(zhǔn)—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.