轉自：https://zssure.blog.csdn.net/article/details/45119841

背景：

最近項目中遇到的實際問題較多，且大多是較隱蔽的、不易被發現的錯誤。究其根源來看，還是對DICOM3.0協議中的細節掌握不夠仔細，因而導致在實際編碼過程中，常常想當然。前一篇中剖析了由于DicomClient中的AddRequest與Send函數調用邏輯錯誤導致的System.ObjectDisposedException異常，接下來要講的是關于DICOM膠片打印的問題，由于在Association Negotiation中PresentationContext協商失誤導致DICOM Print SCU在連接某些型號打印機時無法出片。

DICOM Print：

DICOM3.0協議中關于PRINT的部分主要有：第4部分的附錄H、第17部分的附錄BB，在第4部分的附錄H中主要講解的是整體DICOM Print SOP，即服務對象對；而第17部分附錄BB中給出的是一個具體的DICOM Print SCU實現過程。因此在利用dcmtk、fo-dicom或者dcm4che開源庫來實現自己的DICOM Print服務（SCU或SCP）時應該先仔細閱讀第4部分附錄H中關于該服務的詳細定義與介紹，然后再按照第17部分的附錄BB中示例的流程進行實際開發。第17部分附錄BB中給出的具體流程如下：

由圖中可見，在Association Negotiation階段并未給出詳細的步驟，而這部分恰恰是項目實際部署過程中遇到隱含問題的地方，在介紹問題之前先介紹一個DICOM Print服務中獨有的服務。。

DICOM Meta SOP Class與DICOM SOP Class：

Presentation Context：

在DICOM協議底層建立連接時，會用到Presentation Context，如下圖所示：

簡而言之PresentationContext就是連接上下文，存儲用于連接雙方進行協商的信息，具體的介紹可參閱專欄中的博文和。DICOM協議規定，在連接請求（Association Negotiation）過程中，由請求發起方設置各個Presentation Context的ID號，該ID號不具有實際意義，類似于數據庫中的主鍵Primary Key，僅用于區別各個Presentation Context，被請求端在接收到請求端發送過來的請求后，并不會修改消息中PresentationContext的ID號，因此理論上而言請求端可以自行設置各個PresentationContext的ID號，且對于各PresentationContext的ID號的排序也沒有任何要求。關于PresentationContext的詳細介紹可閱讀DICOM3.0標準第8部分的7.1.1.13。
如上圖所示每個PresentationContext包含三個部分，

• 第一部分，ID號；
• 第二部分，AbstractSyntax，這個在博文中有過介紹，要區別于隨后提到的TransferSyntax，AbstractSyntax可以簡單理解為每項服務的抽象的名稱；
• 第三部分，TransferSytanx，該部分要求每一個PresentationContext中服務端和客戶端之間**有且僅有一種**TransferSyntax用于彼此間數據交換的編碼格式。

【注】：AbstarctSyntax在DICOM3.0標準的第4部分有詳細介紹；TransferSyntax在DICOM3.0標準的第5部分有詳細介紹，此外在第8部分的附錄B中也有相關對比

DICOM UID分類：

UID，全稱為Unique Identifiers，用于區別各項事務，確保在多國家、地區、供應商，以及設備間的唯一性。
雖然UID的目的只有一個區別各項事務，確保唯一性。但是由于各自代表的領域不同、服務的對象不同、具體使用的場景不同，開源庫在具體實現時會對UID進行分類，用于標記區分各事務。下面以fo-dicom中DicomUID為例進行講解：
在DicomUID類中，定義了DicomUidType枚舉類型，

public enum DicomUidType {TransferSyntax,SOPClass,MetaSOPClass,SOPInstance,ApplicationContextName,CodingScheme,FrameOfReference,LDAP,Unknown }

由此推測DICOM協議中的UID大致分成9類，下面對于各種類型進行詳細介紹：
1）TransferSyntax,該類UID就是我們之前提到的用于標識客戶端與服務端之間消息流傳輸的各種編碼格式。
2）SOPClass?,即常見的服務對象對類型，Service-Object-Pairs Class。主要用于標記各種服務，例如DIMSE-C服務、DIMSE-N服務。
3）MetaSOPClass,是一系列SOP Class的集合，具體參見Meta SOP Class Definitions，Meta SOP Class中最常見的就是兩種具體打印服務，即Basic Grayscale Print Management Meta SOP Class和Basic Color Print Management Meta SOP Class。如下圖所示：


4）SOPInstance,用于描述現實場景中具體的“實例”，可以脫離于交互上下文、交互環境（Communication Context）而存在，例如后綴為.dcm的醫學圖像文件等等。
5）ApplicationContextName,該UID是DICOM專屬的，用于標識DICOM應用，因此ApplicationContextName類中有且只有一個對象，即

/// <summary> Application Context Name: DICOM Application Context Name [PS 3.7]</summary>public static DicomUID DICOMApplicationContextName = new DicomUID("1.2.840.10008.3.1.1.1" , "DICOM Application Context Name", DicomUidType.ApplicationContextName);

6）CodingScheme,DICOM協議中的編碼方案，可以簡單的理解為DICOM協議中各種符號含義的約定，具體可參見DICOM3.0第16部分附錄D
7）FrameOfReference,用于定位的坐標系，該坐標系是已經公開的、約定俗成的，例如腦圖譜中著名的Talairach Brain Atlas Frame of Reference，具體可查閱Wiki百科，如下圖所示：

關于FrameOfReference還可閱讀國外文獻資料，例如The MNI brain and the Talairach atlas和Bias Between MNI and Talairach Coordinates Analyzed Using the ICBM-I5 Brain Template。
8）LDAP,Lightweight Directory Access Protocol，中文稱之為“輕型目錄訪問協議”。具體可搜索資料，我也是一知半解。
9）UnKnown,其他預留擴展使用，或用戶自定義。

MetaSOPClass與SOPClass的對比：

綜上所述，之前項目的DICOM Print SCU實現中對于DICOM Print部分的PresentationContext的判斷邏輯有誤，DICOM Printer（即Print SCP）支持的服務分為Verification SOP Class、Basic Grayscale Print Management Meta SOP Class?和?Basic Color Print Management Meta SOP Class。其中Basic Grayscale Print Management Meta SOP Class?和?Basic Color Print Management Meta SOP Class是諸多SOPClass的集合，具體如上文截圖所示。
因此判斷邏輯中首先需要判別的是VerificationSOP Class、?Basic Grayscale Print Management Meta SOP Class?和?Basic Color Print Management Meta SOP Class等最頂層級別的SOPClassUID，而不需要直接判別PrinterSOPClass，原因是：

/// <summary> SOP Class: Printer SOP Class [PS 3.4] </summary>public static DicomUID PrinterSOPClass = new DicomUID ("1.2.840.10008.5.1.1.16", "Printer SOP Class" , DicomUidType.SOPClass);

PrinterSOPClass是SOPClass類型的DicomUID，屬于SOPClasses集合Basic Grayscale Print Management Meta SOP Class?或?Basic Color Print Management Meta SOP Class。此刻再倒回頭去看一下DICOM協議第17部分附錄BB中給出的示例，PrinterSOPClass只是在N-GET服務中使用，用于SCU端獲取DICOM Printer打印機的各種參數。
根據上述概念，用類圖的形式來表示各概念之間的包含關系。SOP Class和Meta SOP Class都屬于Service Class，SOP Class中包含IOD和DIMSE Service。

DICOM Print SCU 與SCP連接協商邏輯：

在之前[冷鋒的博文]中介紹過利用DCMTK工具包來簡單的模擬實現DICOM 打印的過程，但是之前并未詳細分析梳理過相關代碼，究其原因是因為身邊沒有膠片打印機。現在由于實際部署過程中遇到了上述問題——即DICOM打印過程中如何協商PresentationContext？？？。下載通過分析DCMTK庫中具體的源碼，給出其中對于DICOM 打印過程中PresentationContext協商的具體實現。

知識點補充：

下面對博文中提到的諸多概念進行簡單介紹，并給出各概念在DICOM3.0協議中的具體位置。

至此關于DICOM膠片打印服務的連接建立過程中如何協商PresentationContext的邏輯介紹就完成了。

PS：?我一直閱讀的本機DICOM3.0協議是2011版，前幾天在跟朋友溝通時發現DICOM官網已經更新到了2015a版本，因此后續的介紹中我會盡量按照最新協議來分析，或者至少給出與2011版本中對應的最新2015a版中的內容，如果在2015a中沒有找到博文中對應的內容請及時與我聯系。

作者：zssure@163.com
時間：2015-04-18

總結

以上是生活随笔為你收集整理的【转】DICOM：DICOM Print服务中PresentationContext协商之 MetaSOPClass与SOPClass对比分析！！！！！！！！的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。