Comparative analysis of Metasopclass and sopclass of presentationcontext negotiation in dicom:dicom Print Service

Background:

Recent projects have encountered many practical problems, and most of them are more covert, not easy to find errors. The root of the problem is that the details in the DICOM3.0 protocol are not carefully mastered, leading to the actual coding process, often taken for granted. In the previous article, we analyzed the system.objectdisposedexception exception caused by addrequest and the Send function call logic error in Dicomclient . The next thing to talk about is the issue of dicom film printing, due to the presentationcontext negotiation Error in association negotiation, the DICOM print SCU is unable to chip out when connecting to certain printer models .

DICOM Print:

Part of the DICOM3.0 agreement regarding Print is mainly: Appendix BB of Appendix Hand part 17thof part 4th, in Appendix H of part 4th, the whole dicom Print SOP, i.e. the service object , and the 17th Appendix BB gives a specific dicom Print SCU implementation process. Therefore, when using the DCMTK, fo-dicom, or dcm4che open source libraries to implement your own DICOM print service (SCU or SCP), you should carefully read the detailed definition and description of the service in Appendix H of section 4, The actual development is then followed by the process of the example in Appendix BB in part 17th. The specific process given in appendix BB in the 17th part is as follows:

As can be seen from the diagram, the association negotiation stage does not give a detailed step, which is precisely where the project is actually deployed, where there is an implicit problem, before introducing a problem, introduce a unique service in the Dicom Print service.

Dicom Meta SOP Class and Dicom sop class:presentation Context:

The presentation Context is used when establishing a connection at the bottom of the Dicom protocol, as shown in:

In short, Presentationcontext is the connection context, which stores the information used to connect the two parties for negotiation, as described in the post and in the column. The DICOM protocol stipulates that, during connection requests (association negotiation), the ID number of each presentation context is set by the requesting initiator, which has no practical meaning, similar to the primary key primary key in the database. Used only to differentiate the presentation Context, the requested side does not modify the ID number of the Presentationcontext in the message after it receives the request sent by the requester. Therefore, in theory, the requester can set the ID number of each presentationcontext, and there is no requirement to sort the ID numbers of each presentationcontext. A detailed introduction to Presentationcontext can be read in part 8th of the DICOM3.0 Standard 7.1.1.13.
Each presentationcontext, as shown, contains three parts,

• first part ,ID number ;
• The second part ,Abstractsyntax, has been introduced in the blog post, to distinguish it from the later mentioned Transfersyntax,abstractsyntax can be simply understood as the abstract name of each service;
  
• The third part,Transfersytanx, requires that each of the presentationcontext between the server and the client * * has and only one * * Transfersyntax the encoding format used to exchange data between each other.
  

"Note": Abstarctsyntax is described in detail in section 4 of the DICOM3.0 standard, Transfersyntax is described in detail in part 5th of the DICOM3.0 standard, and is also relevant in Appendix B of part 8th

DICOM UID Classification:

UID, all called unique Identifiers, is used to differentiate transactions and ensure uniqueness across multiple countries, regions, vendors, and devices.
Although the purpose of the UID is only one difference between the various transactions, ensure uniqueness. However, due to the different fields of their representatives, the different objects of service, and the specific scenarios used, the open Source Library classifies the UID when it is implemented, and it is used to distinguish each transaction. The following is an example of fo-dicom in Dicomuid:
In the Dicomuid class, the Dicomuidtype enumeration type is defined.

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

It is inferred that the UID in the DICOM protocol is broadly divided into 9 classes, which are described in detail below for various types:
1) Transfersyntax, the class UID is the various encoding formats we mentioned earlier to identify the message flow between the client and the server.
2) Sopclass , which is the common type of service object, Service-object-pairs Class. Mainly used to mark various services, such as DIMSE-C services, dimse-n services.
3) Metasopclass, a set of SOP classes, see the most common in the Meta SOP Class Definitions,meta SOP Class is the two specific print services, That is, the basic grayscale print Management Meta SOP class and basic Color print Management Meta SOP class. As shown in the following:


4) Sopinstance, used to describe specific "instances" in a real-world scenario, can be separated from the interaction context, the interactive environment (communication context), such as medical image files with the suffix. DCM, and so on.
5) Applicationcontextname, the UID is exclusive to DICOM and is used to identify the dicom application, so there is only one object in the Applicationcontextname class, i.e.

 /// <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, the coding scheme in DICOM protocol can be easily understood as the conventions of various symbolic meanings in DICOM protocol, see Appendix D of DICOM3.0 part 16th
7) Frameofreference, used for positioning the coordinate system, the coordinate system is open, conventional, such as the Brain Atlas of the famous Talairach Brain Atlas Frame of Reference, specifically accessible wiki Wikipedia As shown in the following:

About Frameofreference You can also read foreign literature, such as the MNI brain and the Talairach Atlas and bias between MNI and Talairach coordinates Analyzed U Sing the icbm-i5 Brain Template.
8) LDAP, Lightweight Directory Access Protocol, Chinese is known as the "Lightweight Directory protocol." Specific searchable information, I am also smattering.
9) UnKnown, other reserved extensions used, or user-defined.

Comparison of Metasopclass and Sopclass:

In summary, the presentationcontext of the Dicom print section in the DICOM print SCU implementation of the previous project is wrong, and the services supported by Dicom Printer (that is, Print SCP) are divided into Verification SOP Class,basic grayscale print Management Meta SOP class and basic Color print Management Me Ta SOP Class. where basic grayscale print Management Meta SOP Class and basic Color print Management Meta SOP Class are many Sopcla The set of SS, as shown above.
So the first thing to distinguish in the logic of judgment is the Verificationsop class, basic grayscale Print Management Meta SOP class and basic Color Print Management Meta SOP Class , and so on the top level of sopclassuid, without the need to directly discriminate Printersopclass, because:

/// <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 is a sopclass type dicomuid, belonging to sopclasses collection Basic grayscale Print Management Meta SOP Class or Basic Color Print Management Meta SOP Class. Now go back and look at the example given in Appendix BB in part 17th of the DICOM protocol, Printersopclass is only used in the N-get service for the SCU side to obtain various parameters of the DICOM printer printer.
According to the above concepts, the inclusion relationship between the concepts is expressed in the form of a class diagram. Both the SOP class and the Meta SOP class belong to the service Class,sop class that contains the IoD and Dimse service.

DICOM Print SCU and SCP connection negotiation logic:

The process of using the DCMTK Toolkit to simply simulate DICOM printing was described in a previous [post in cold front], but no detailed analysis of the related code has been done before, because there is no film printer around. Now because of the actual deployment process encountered the above problem- that is, dicom printing process How to negotiate presentationcontext???? . Download by analyzing the specific source code in the DCMTK library, the specific implementation of presentationcontext negotiation in dicom printing process is given.

Knowledge Point Supplement:

The following is a brief introduction to the many concepts mentioned in the blog post, and gives the specific location of the concepts in the DICOM3.0 protocol.

The logical introduction of how to negotiate presentationcontext during the connection establishment of the DICOM film printing service is complete.

PS: I have been reading the native DICOM3.0 protocol is version 2011, the previous few days in communication with friends found that the DICOM official website has been updated to the 2015a version , so the following introduction I will try to follow the latest agreement to analyze, Or at least give the 2011 version of the corresponding to the latest 2015a version of the content, if not found in 2015a blog post corresponding content please contact me in time.

[Email protected]
Date: 2015-04-18

Comparative analysis of Metasopclass and sopclass of presentationcontext negotiation in dicom:dicom Print Service