[轉]DICOM醫學圖像處理：Deconstructed PACS之Orthanc

時間 2019-11-20

標籤 dicom 醫學圖像處理 deconstructed pacs orthanc 简体版

原文原文鏈接

轉載：http://blog.csdn.net/zssureqh/article/details/41424027

背景：

此篇博文介紹一個開源的、基於WEB的DICOM Server軟件。該開源軟件徹底使用C++編寫，不依賴於第三方數據庫（內置了SQLite數據庫）或其餘框架，支持RESTful API設計模式。官網上提供了源代碼，同時也給出了編譯後的Windows和Linux系統的二進制安裝包。Orthanc是PACS領域的一種改革，提出了「解構PACS概念」，即Deconstructed PACS，用戶能夠經過三種方式訪問Orthanc：DICOM Server、Web Server和RESTful API。php

Orthanc：

開源中國社區中對於Orthanc有一段這樣的描述：Orthanc是一個輕量級的，基於REST的DICOM服務器，主要用於衛生保健和醫療研究。Orthanc可將任意運行Windows和Linux的計算機編程DICOM存儲（或者說是一個小型PACS系統），其架構是輕量級的，沒有複雜的數據庫管理，不依賴於第三方軟件。html

除此之外，Orthanc官網（http://www.orthanc-server.com/about.php）對於Orthanc的描述着重提到：Orthanc之因此不同凡響是由於它提供RESTful API。所以，Orthanc可使用任何計算機語言開發。Orthanc存儲的DICOM圖像的標籤能夠以JSON文件格式下載，此外，Orthanc對於存儲的DICOM實例能夠動態生成對應的PNG圖像。python

Orthanc隱藏了複雜的DICOM文件格式和DICOM協議，使使用者只專一於DICOM文件內容。spring

Deconstructed PACS：

Deconstructed PACS是新一代的PACS系統，原文的描述爲"The latest strategy for imaging informatics is actually "deconstructed PACS," where the core elements of PACS are best-of-breed or component-based solutions, integrated together using standards-based approaches.」 PACS系統最先是經過組合多個獨立的子系統來實現簡單獲取和轉存圖像，對於圖像（images）和醫學信息（demographics）分別採用不一樣的網絡；隨後發展爲C/S模式，經過Client的工做站來實現（胖客戶端thick-client）；最後演變成基於瀏覽器的Web PACS（瘦客戶端thin-client）。數據庫

【Deconstructed PACS概念目前我尚未搞太明白，官網的資料比較多，後續會補充更多的資料，有興趣的讀者也能夠直接閱讀博文後我給出的鏈接】編程

Orthanc安裝：

經過上述簡短的介紹，想必你們已經對Orthanc有了大體的瞭解。下面給出Orthanc的安裝方法，Orthanc是一個開源軟件，所以有兩種安裝方式。json

Orthanc二進制包在Windows下安裝：

下載地址：http://www.orthanc-server.com/download-windows.php。在官網下載頁面中輸入基本信息就會在郵箱中得到下載連接，Windows下的二進制安裝包名稱爲：Orthanc-0.8.5-Installer.exe。雙擊安裝包，以下圖所示，單擊「下一步」就能夠順利完成安裝。windows

該文件夾用於設置Orthanc軟件的安裝目錄，即主要程序OrthancService.exe和Orthanc-0.8.5-Release.exe的存放位置。設計模式

此處用於設置Orthanc軟件中DICOM Server的數據存儲目錄，能夠簡單的理解爲mini-PACS的歸檔目錄，後續示例中的圖像就保存在該文件夾下。瀏覽器

此處用於設置Orthanc軟件在開始菜單中快捷鍵的文件夾。

單擊Install，稍等片刻便可完成Orthanc在Windows下的安裝。

Orthanc源碼在Windows下編譯運行：

開源軟件最經常使用的是源碼編譯，如是能夠生成跟本機系統最匹配的可執行文件。Orthanc源代碼下載地址爲：http://sourceforge.net/projects/orthancserver/files/Orthanc-0.8.5.tar.gz/download，源碼包名稱爲：Orthanc-0.8.5.tar.gz。解壓Orthanc-0.8.5.tar.gz到但願的目錄（本機我選擇C:\），獲得C:\Orthanc-0.8.5，以下圖：

打開INSTALL安裝說明文檔，能夠看到安裝必須的準備：

1）CMake，我直接利用本地安裝的CMake2.8（也能夠到官網下載最新版本：http://www.cmake.org/）；

2）Python，安裝過程當中有一些自動生成的腳本須要用到Python解釋器，下載地址http://www.python.org/，我本機安裝的版本爲：Python2.7；

3）7-Zip：用於解壓縮安裝過程當中下載的壓縮包，下載地址爲http://www.7-zip.org/。

在選擇CMake GUI界面，指定source code和build路徑後，單擊Configure會出現缺乏7-zip的錯誤提示，以下圖：

緣由是我本機起初並未安裝7-zip軟件。按照INSTALL給出的官網下載並安裝完成後，從新啓動CMake再次進行配置後，又會出現錯誤，以下所示。提示缺乏libgoogle-glog-dev package，這個應該是google的用於日誌記錄的庫。

在搜索並下載libgoogle-glog-dev package時遇到了問題，未找到直接的下載連接。所以利用CMake GUI編譯Orthanc的路暫時走不通。從新仔細閱讀INSTALL文檔，找到了在Windwos系統下利用Microsoft Visual Studio進行Orthanc源碼編譯的方法，具體說明以下：

Native Windows build with Microsoft Visual Studio
-------------------------------------------------
# cd [...]\OrthancBuild
# cmake -DSTANDALONE_BUILD=ON -DSTATIC_BUILD=ON -DALLOW_DOWNLOADS=ON -G "Visual Studio 8 2005" [...]\Orthanc

Then open the "[...]/OrthancBuild/Orthanc.sln" with Visual Studio.

利用cmd進入到命令提示符狀態，仿照上述代碼，建立安裝緩存目錄，mkdir c:\OrthancBuild；隨後啓動cmake命令行模式，按照INSTALL中的說明設置編譯模式，具體指令爲：

cd c:\OrthancBuild

cmake -DSTANDALONE_BUILD=ON -DSTATIC_BUILD=ON -DALLOW_DOWNLOADS=ON -G "Visual Studio 10" ..\Orthanc-0.8.5\Orthanc-0.8.5

注：目錄要指定到源碼中CMakeList.txt文件所在的層級。另外對於本地編譯器的選擇，能夠如今cmd狀態下輸入cmake，查看當前支持的編譯器類型，以下圖所示，我選擇的是Visual Studio 10。

上述打開了自動下載第三方支持庫的選項，即-DALLOW_DOWNLOADS=ON 。在啓動cmake後，會自動下載咱們在CMake GUI模式下提示缺乏的各類支持庫。等待全部第三方庫自動下載並安裝完成後，Orthanc源碼就順利編譯完成了，以下圖所示：

打開上圖中提示的Build files文件路徑C:\Orthanc-0.8.5，雙擊打開VS工程Orthanc.sln。選擇「生成」下的「批生成」，勾選ALL_BUILD項目，單擊「生成」後等待編譯完成。

順利編譯完成後，在C:\Orthanc-0.8.5\Debug目錄下看到了與二進制安裝後相同的可執行文件，名稱爲Orthanc.exe，以下圖所示：

至此利用Orthanc源碼進行安裝的過程順利結束。其實在CMake GUI模式下咱們勾選了配置項中的「ALLOW_DOWNLOADS」，也能夠順利完成Orthanc源碼的編譯。

Orthanc測試：

Orthanc被描述爲一款開源的、輕量級的，知足RESTfu API 的DICOM服務器。它獨特之處在於存在多種與Orthanc的交互方式，主要有三種：DICOM Server，Web Server和RESTful API。下面就利用這三種訪問方式對上述兩種安裝環境進行實例測試：

二進制包的測試：

1）做爲DICOM Server：

安裝並啓動OrthancService.exe後，在任務管理器中能夠看到啓動了兩個服務駐留進程OrthancService.exe和Orthanc-0.8.5-Release.exe

Orthanc提供了發送和接收DICOM圖像的基本功能，相似於一個mini PACS。能夠與DCMTK提供的工具包進行良好的交互，此處我就藉助DCMTK提供的storescu.exe工具將C:\test.dcm文件發送到Orthanc，具體指令以下：

storescu.exe –d –aec ORTHANC localhost 4242 c:\test.dcm

對於storescu.exe工具包的使用可參照我前幾篇的專欄，此處ORTHANC是Called AE Title，4242是Orthanc中DICOM服務的監聽端口，該信息在安裝過程當中指定的數據歸檔目錄（即c:\Orthanc）中的Connfiguration.json配置文件中能夠自行設置，上述命令行中的參數是Orthanc安裝時默認的設置。

命令執行後，storescu.exe的輸出結果以下圖所示，說明test.dcm文件已經順利發送到Orthanc。

打開Orthanc默認的數據歸檔文件夾C:\Orthanc\OrthancStorage\6a\d6能夠看到一個大小與test.dcm相同的文件，利用DICOM Viewer打開能夠看到二者是同一個文件。這說明Orthanc成功接收到storescu.exe發送的測試圖像。

2）做爲Web Server：

Orthanc內置了一個Web Server（也可嵌入到Apache服務中），即Orthanc Explorer。Orthanc Explorer提供了一種友好的交互方式，可經過拖拽文件的方式實現DICOM文件上傳。下面咱們演示一下：

在開始菜單中選擇Open Orthanc Explorer，或者在Chrome或者Firefox瀏覽器中直接輸入http://localhost:8042/app/explorer.html（注：目前不支持IE瀏覽器）。打開後此處能夠直接看到咱們剛纔利用storescu.exe上傳的test.dcm文件，以下圖所示：

單擊上圖右上角的Upload DICOM，出現以下界面：

此時咱們可使用「拖拽」方式實現DICOM文件上傳。下面我選擇c:\test2.dcm文件，拖拽到上述頁面中，而後單擊Start the upload，會彈出上傳進度條，以下所示：

返回上層界面，能夠看到咱們「拖拽」的test2.dcm文件已經順利完成上傳，以下圖所示：

3）利用RESTful API：

下面介紹Orthanc最使人振奮的訪問方式——RESTful API。它提供了一種使用標準網絡協議與圖像服務器進行交互的方式，使得能夠在任何地方（只要有網絡覆蓋）經過網絡鏈接訪問Orthanc服務器，而且無需考慮服務運行的平臺或開發語言。RESTful APIs使用URIs來實現資源的定位與訪問，此處的資源包括patients、studies和images三級，與DICOM協議中定義相同，傳統的PACS也多以此做爲數據庫的設計原則。對於該類請求，Orthanc會將文本信息以JSON格式返回（JSON是一種輕量級的普遍應用的文件格式）；對於圖像信息會返回PNG網絡圖像格式。該部分想必你們都很熟悉，下面咱們就直接演示一下：

此處藉助於curl.exe工具，在cmd模式下輸入：

cd c:\

curl –X POST http://localhost:8042/instances –data-binary @test3.dcm

獲得以下結果代表test3.dcm圖像上傳成功，

打開Orthanc Explorer能夠看到剛纔上傳的test3.dcm文件：

源碼編譯後測試：

在任務管理器中先手動終止OrthancService.exe和Orthanc-0.8.5-Release.exe兩個Orthanc後臺服務進程，轉到編譯源碼生成的目錄C:\Orthanc-0.8.5\Debug下，啓動Orthanc.exe，以下圖所示：（調試狀態下Orthanc.exe會輸出狀態信息，也能夠在命令行下啓動Orthanc.exe --verbose輸出調試信息）

仿照上一節，從DICOM Server、Web Server和RESTful API三種方式進行測試：

1）DICOM Server

進入cmd模式，輸入：

storescu.exe –d –aec ORTHANC localhost 4242 c:\test.dcm，能夠看到圖像上傳成功的結果：

2）Web Server

打開谷歌瀏覽器，地址欄輸入http://localhost:8042/app/explorer.html，能夠看到剛纔上傳的test.dcm文件，以下圖：

單擊Upload DICOM，拖拽test2.dcm文件到瀏覽器頁面，而後單擊Start the Upload，返回到主頁面能夠看到順利上傳的結果，以下圖：

打開目錄C:\Orthanc-0.8.5\Debug\OrthancStorage，能夠看到順利歸檔的兩個文件

3）RESTful API

進入cmd模式，輸入以下指令：

cd c:\

curl –X POST http://localhost:8042/instances –data-binary @test3.dcm

在Orthanc Explorer中能夠順利看到結果，以下圖：

【注】：與二進制安裝環境下不一樣的是，curl運行時會偶爾返回錯誤提示，出現這種狀況後重啓Orthanc.exe就能夠解決。

知識點補充：

RESTful API：

RESTful API是目前比較成熟的一套互聯網應用程序的API設計理論。REST，全稱Representational State Transfer，最先是由Roy Thomas Fielding在他2000年的博士論文中提出的。論文中的部分摘要以下：

「

This dissertation explores a junction on the frontiers of two research disciplines in computer science: software and networking. Software research has long been concerned with the categorization of software designs and the development of design methodologies, but has rarely been able to objectively evaluate the impact of various design choices on system behavior. Networking research, in contrast, is focused on the details of generic communication behavior between systems and improving the performance of particular communication techniques, often ignoring the fact that changing the interaction style of an application can have more impact on performance than the communication protocols used for that interaction. My work is motivated by the desire to understand and evaluate the architectural design of network-based application software through principled use of architectural constraints, thereby obtaining the functional, performance, and social properties desired of an architecture.

」

若是一個架構符合REST原則，就稱它爲RESTful架構。要理解RESTful結構，須要充分理解Representational State Transfer 這個詞組的含義，每一個詞表明什麼意思。該詞組中省略了主語，表現層（representational）其實指的是資源（resources）的表現層。所謂資源就是網絡上的一個實體，或者說網絡上的一個具體信息。REST從資源的角度來觀察整個網絡，分佈在各處的資源由URI肯定，而客戶端的應用經過URI來獲取資源的表示方式。所謂上網，就是互聯網上一系列「資源」的互動，一系列URI的調用。

資源是一種信息實體，能夠有多種表現形式，叫作「表現層（representation）」，例如文本能夠用txt表示，也能夠用html、xml、JSON表示，甚至可使用二進制格式；圖片能夠用JPEG、PNG等格式。URI只表明資源實體，不表明它的表現形式。有些網址最後的.html後綴名是不須要的，由於.html後綴是一種表示格式，屬於「表現層」範疇，URI只表明資源的位置。

訪問一個網站，就表明客戶端與服務器的一個互動過程。這個過程當中勢必會涉及到數據和狀態的改變。互聯網通訊協議HTTP協議，是一個無狀態協議。這意味着，全部的狀態都保存在服務器端。所以，若是客戶端想要操做服務器，必須經過某種手段，讓服務器端發生"狀態轉化"（State Transfer）。而這種轉化是創建在表現層之上的，因此就是"表現層狀態轉化"。客戶端用到的手段，只能是HTTP協議。具體來講，就是HTTP協議裏面，四個表示操做方式的動詞：GET、POST、PUT、DELETE。它們分別對應四種基本操做：GET用來獲取資源，POST用來新建資源（也能夠用於更新資源），PUT用來更新資源，DELETE用來刪除資源。得到這些表會導致這些應用程序轉變了其狀態。隨着不斷獲取資源的表示方式，客戶端應用不斷地在轉變着其狀態，所謂表述性狀態轉移（Representational State Transfer）。——這一觀點不是憑空臆造的，而是經過觀察當前Web互聯網的運做方式而抽象出來的。Roy Fielding 認爲，「設計良好的網絡應用表現爲一系列的網頁，這些網頁能夠看做的虛擬的狀態機，用戶選擇這些連接致使下一網頁傳輸到用戶端展示給使用的人，而這正表明了狀態的轉變」。

綜合上面的解釋，咱們總結一下什麼是RESTful架構：