DICOM medical image processing: C-Echo and C-Store, dicomfo-dicom

DICOM medical image processing: C-Echo and C-Store, dicomfo-dicom
Background:

In the previous blog, we introduced the network transmission in DICOM, mainly referring to the original English text in DCMTK Wiki. By comparing the implementation of the dicom standard in DCMTK and fo-DICOM open source libraries, we have a more intuitive understanding of the DICOM standard. This blog post is a supplement to the previous one, because most of the examples in front of the column use the DCMTK toolkit. By analyzing the fo-dicom source code structure, refer to README of fo-dicom. the realization of C-ECHO and C-STORE service is given. The DICOM3.0 standard is introduced to help us understand the implementation.

C-ECHO fo-dicom implementation: 1) C-ECHO parameters description:

The C-ECHO, also known as Verification, is used to verify the smooth communication between the two ends of the DICOM service. Part 1 of DICOM3.0 provides parameters for the C-ECHO service, as shown in 1:

Note ]:Here we will explain how to read the DICOM3.0 standard. Take DICOM3.0 standard 7th, 8 part as an example, [7th] Chapter 9th began to explain the various services of DIMSE-C, c-STORE, C-FIND, C-GET, C-MOVE, C-ECHO (1 is what I 've captured in the C-ECHO section of this section ), among them, the first half of the main gives the parameters of various services of the DIMSE-C, here is only a list of DICOM3.0 standard requirements, the purpose is to let you know whether each service parameter is necessary (expressed by M, U, and = respectively ); the second part begins to explain the Protocol and implementation process of various DIMSE-C services (PROTOCOL and Procedures), in Protocol is given the specific DIMSE-C service of the various instructions in the format of the transmission process, this part is the real data stream that you can directly capture using the packet capture tool. Procedures provides the interaction process between SCU and SCP, which is usually used to indicate who initiated the service, who responds. When introducing Protocol, Variables Fields are usually included in the appendix, for example, appendix C and E in Part 1; [Part 1] is similar to [Part 2]. Chapter 2 describes the parameters of various ACSE services, as shown in figure 2 ), in order to A-ASSOCIATE, A-RELEASE, A-ABORT, A-P-ABORT, P-DATA; Chapter 9th gives the STRUCTURE of various services in ACSE, that is, STRUCTURE, this part is the same as the PROTOCOL in [Part 1]. It shows the data format of the specific acse pdu during transmission. This part can also be directly obtained through the packet capture tool; similarly, complicated STRUCTURE descriptions are also placed in the appendix, for example, appendix E in Part 1.

The basic implementation class of fo-dicom for DIMSE messages is DicomMessage. DicomRequest and DicomResponse are derived for requests and responses respectively, and corresponding classes are derived based on different DIMSE services. C-ECHO is the simplest of them, fo-dicom has given the specific implementation of SCP and SCU. Refer to the README. md file in fo-dicom to give the code of C-ECHO SCP and SCU, details are as follows:

2) C-ECHO code instance:

The code for C-ECHO SCP is to directly use the DicomCEchoProvider class given by fo-dicom to enable the C-ECHO SCP service by creating a DicomServer <DicomCEchoProvider> (12345) object, the parameter 12345 represents the port number of the C-ECHO service. C-ECHO SCU and C-ECHO SCP Code are as follows:

using System;using System.Collections.Generic;using System.Linq;using System.Text;using System.Threading;using System.Threading.Tasks;using Dicom;using Dicom.Network;namespace CEchoSCU{    class Program    {        static void Main(string[] args)        {            var client = new DicomClient();            client.NegotiateAsyncOps();            client.AddRequest(new DicomCEchoRequest());            client.Send("127.0.0.1", 12345, false, "SCU", "ANY-SCP");            Console.ReadLine();        }    }}

using System;using System.Collections.Generic;using System.Linq;using System.Text;using System.Threading.Tasks;using System.Threading;using Dicom;using Dicom.Network;namespace CEchoSCP{    class Program    {        static void Main(string[] args)        {            var server = new DicomServer<DicomCEchoProvider>(12345);            Console.ReadLine();        }    }}

The actual running result is as follows:

C-STORE fo-dicom implementation: 1) C-STORE parameters description:

C-STORE is the storage service, one of the most common services in the medical information system, especially in the PACS system. As with the C-ECHO service, DICOM3.0 standard section 7th also provides a list of parameters for the C-STORE service, as shown in 4:

The purpose of this parameter list is also to introduce the necessity of each parameter in the C-STORE service, the true parameter Message format is described in the subsequent C-STORE PROTOCOL, as shown in Figure 5:

Figure 5 shows only the actual message format of the C-STORE RQ, which flows from the SCU (client) of the C-STORE service to the SCP (server) of the C-SOTRE service ); the corresponding C-STORE-RSP message flows from SCP to SCU, And the DICOM3.0 standard also has a detailed introduction to the C-STORE-RSP, as shown in 6.

2) C-STORE code instance:

In the fo-dicom instruction document README. md, only scu examples of the C-STORE are given, as shown in 7:

Based on the structure analysis of the fo-dicom source code in the previous blog, it is easy to implement SCU for many DIMSE services. First, create the DicomClient entity class to represent a client, then add different requests through AddRequest to achieve various DIMSE clients, 7 in the implementation of the C-STORE SCU is:

Client. AddRequest (new DicomCStoreRequest (@ "test. dcm "));

The DicomCStoreRequest class is the derived class of DicomRequest. The code above creates a DicomCStoreRequest object by creating the directory of the DCM file, in DicomCStoreRequest, the Affected SOP Instance UID and other parameters in the preceding parameters are obtained by opening the specified DCM file.

Since fo-dicom does not provide the C-STORE scp of the thread, we first use the storescp.exe tool of dcmtkto verify the correctness of the C-STORE SCU given by fo-dicom, the test code is as follows:

• Scpuse storescp.exe and enter:Storescp.exe-d-od c :\ 12345
• SCU end uses C-STORE SCU in fo-dicomAs shown in figure 7, storescu.exe is created in the later steps.

The following result is displayed, as shown in figure 8:

At the same time, you can see the renamed test. dcm file in the C root directory, as shown in Figure 9:

We mentioned the reason for renaming the source code of the DCMTK open-source library. Generally, DCMTK is renamed to the received DCM File Based on the SOP Instance UID (-uf, default, of course, you can also set the rename method through options, such as by time (-tn), specific prefix (-fe), and so on, as shown in figure 10.

This shows that the C-STORE SCU function in fo-dicom is normal, then we try to use fo-dicom to build C-STORE SCP.

3) Build C-STORE SCP

Open the implementation of C-ECHO SCP DicomCEchoProvider. cs file, we can see that the DicomCEchoProvider class achieves the basic framework of Dicom service by deriving DicomService service class, and then completes the C-ECHO server by implementing the IDicomServiceProvider and IDicomCEchoProvider interfaces, view the DicomCEchoProvider code can be found, in fact, is to receive the A-ASSOCIATE-RQ message, identify the Abstract Syntax in the Presentation Context, according to the actual request message to determine whether to establish a connection, in addition, when receiving a C-ECHO Request initiated by the C-ECHO SCU, it will send DicomCEchoResponse confirmation information.

Since the implementation of two interface functions can complete the construction of C-ECHO SCP, then we try to complete the establishment of C-STORE SCP, modeled by DicomCEchoProvider, DicomCStoreProvider code is as follows:

using System;using System.Collections.Generic;using System.Linq;using System.Text;using System.Threading.Tasks;using Dicom;using Dicom.Log;using Dicom.Network;using System.Threading;using System.IO;namespace CStoreSCP{    class CStoreSCPProvider : DicomService, IDicomServiceProvider, IDicomCStoreProvider    {        public CStoreSCPProvider(Stream stream, Logger log) : base(stream, log) { }        public DicomCStoreResponse OnCStoreRequest(DicomCStoreRequest request)        {            return new DicomCStoreResponse(request,DicomStatus.Success);        }        public void OnCStoreRequestException(string tempFileName, Exception e)        {        }        public void OnReceiveAssociationRequest(DicomAssociation association)        {            foreach (var pc in association.PresentationContexts)            {                if (pc.AbstractSyntax == DicomUID.Verification)                    pc.SetResult(DicomPresentationContextResult.Accept);                else                {                    //pc.SetResult(DicomPresentationContextResult.RejectAbstractSyntaxNotSupported);                }                if (pc.AbstractSyntax == DicomUID.CTImageStorage)                {                    pc.SetResult(DicomPresentationContextResult.Accept);                }            }            SendAssociationAccept(association);        }        public void OnReceiveAssociationReleaseRequest()        {            SendAssociationReleaseResponse();        }        public void OnReceiveAbort(DicomAbortSource source, DicomAbortReason reason)        {        }        public void OnConnectionClosed(int errorCode)        {        }    }}

Then a C-STORE SCP application is built through var server = new DicomServer <CStoreSCPProvider> (12345); Console. ReadLine.

11is the result of running cstorescp.exefirst, and then running cstorescu.exe:

The output result of Figure 11 shows that the communication between SCP and SCU is successfully completedThe C: \ test.dcmfile we sent will be stored by cstorescp.exe.? From the analysis of the previous blog, we know that the basic framework of dicom service is put in the DicomService class in the fo-DICOM database, and the core function ProcessPDataTF for processing the P-DATA service is viewed, the following code can be seen:

var file = new DicomFile(); file.FileMetaInfo.MediaStorageSOPClassUID = pc.AbstractSyntax; file.FileMetaInfo.MediaStorageSOPInstanceUID = _dimse.Command.Get<DicomUID>(DicomTag.AffectedSOPInstanceUID); file.FileMetaInfo.TransferSyntax = pc.AcceptedTransferSyntax; file.FileMetaInfo.ImplementationClassUID = Association.RemoteImplemetationClassUID; file.FileMetaInfo.ImplementationVersionName = Association.RemoteImplementationVersion; file.FileMetaInfo.SourceApplicationEntityTitle = Association.CallingAE;_dimseStream = CreateCStoreReceiveStream(file);

Go to the CreateCStoreReceiveStream function, through the description of the function, you can know that fo-dicom on the C-STORE service by default is to create a temporary file in the system to receive the C-STORE SCU data, so we can infer that our test. the dcm file should also be in the Temporary Folder. Open the temp folder on my local machine and you can see a temporary file with the suffix tmp, as shown in 12. The file size is the same as the test. dcm used in our test. Try to modify the extension of. tmp, after modification, you can use DICOM Viewer software to open normally, so that our C-STORE SCP was successful.

DICOM data flow analysis: C-ECHO Service Data Flow Analysis: 1) Tools:

To capture the 127.0.0.1return data package, use the rawcap.exe toolkit. RawCap.exe is a console program that is convenient for capturing local loop data packets. The. pcap packet captured by the consumer.

WireShark is a powerful data packet statistical analysis tool. Of course, it can also capture network data packets (local loop data packets are not convenient ). WireShark supports many protocols, including DICOM. The following uses C-ECHO data packets as an example to briefly introduce how to use WireShark to automatically identify and parse DICOM data packets. First open the captured local C-ECHO package cecho. pcap. 13. Right-click Protocol and choose "Data Preferences…" in "Protocol Preferences ...", A protocol setting window 13 is displayed. Find the DICOM protocol in the list on the left, and select the red part in Figure 14. This part indicates that besides detecting the packets of the default port 104 of DICOM protocol, packets of other ports are also detected. This option is required because many DICOM services do not use the default port 104 of the Protocol. After the settings are complete, re-view the Protocol column, you can see the appearance of DICOM words, 15, the top of the packet with DICOM words is the local loop packet of the C-ECHO service we crawled.

2) C-ECHO Data Flow Analysis:

Using the powerful tools rawcap.exe and WireShark, we can see the captured DICOM data packets intuitively. Next I will analyze the data packets one by one according to the content in part 1 and part 3 of the DICOM standard, observe the real data packets to gain a better understanding of the DICOM protocol.

As you can see from figure 15, the top DICOM protocol contains 6 packets, which are connection established (A-ASSOCIATE RQ/A-ASSOCIATE AC), data interaction (P-DATA-TF), connection release (A-RELEASE RQ/A-RELEASE RP), which is consistent with the ACSE control flow described in section 1 of DICOM protocol.

A-ASSOCIATE RQ/A-ASSOCATE AC analysis:

Double-click the first DICOM packet, which is the real data stream of the A-ASSOCIATE RQ, as shown in 16:

According to the description of A-ASSOCIATE rq pdu in chapter 1 of DICOM protocol section 8th, we compare items one by one (DICOM protocol may refer to figure 17 ):Item 11-byte PDU-type, in the figure is 01 H, indicating that the packet represents the A-ASSOCIATE RQ;Item 2One byte is retained. The data stream is 00 H;Item 3It is the PDU-length of four bytes. In the figure, the value is 00 00 ff and the unsigned integer is exactly 255. This is the subsequent packet length of the blue part in the figure;Item 4Is the Protocol-Version of two bytes. In the figure, the value is 00 01 and the corresponding Version is 1;Item 5It is reserved in two bytes;Item 6 and item 7Is our familiar AE Title, from WireShark data streams can also be seen are ANY-SCP and ECHOSCU;8th itemsA heap of reserved bytes, which is filled with h;9th itemsIs a Variable Fields. This item is a composite item and contains multiple independent subitems. Figure 16 shows that the compound item containsApplication Context,Presentation Context(2, IDs are 1, 3 ),UserInfoThree sub-items, and UserInfo is a composite item, which containsMax PDU Length,ImplentationUID,ImplentationVersionThree sub-items. From the WireShark analysis, the Application Context subitem type is 10 H, the Presentation Context subitem type is 20 H, and the UserInfo subitem is 50 H (the nested subitem types are respectively,Max PDU Length-51H, Implentation UID-52H, Implentation Version-55H). The type of each subitem corresponds to Appendix D in section 7th and 8 of DICOM protocol. In example 19, the format of the maxpdu Length subitem is intercepted. The data packet analysis of A-ASSOCIATE AC is similar to that of A-ASSOCIATE RQ, but the data flow of A-ASSOCIATE AC is simpler. (Result 18 of the DICOM protocol for the final data domain ).

A-RELEASE RQ/A-RELEASE RP Analysis:

The format of the data packet for connection release is simple. The following figure 20 and Figure 21 respectively show the format of the connection release request and response data packet in section 8th of DICOM protocol:

Double-click the connection in WireShark to release the data packet. We can see that the data packet types of the two are 05H and 06 H respectively, which is exactly the same as the DICOM protocol in.

P-DATA-TF:

In my previous blog post (http://blog.csdn.net/zssureqh/article/details/41016091) I have analyzed,DIMSE messages (Command and Dataset) specified in DICOM protocol Part 1 are transmitted in the form of PDV through the P-DATA-TF service in ACSE Protocol Part 2. Next let's analyze the format of C-ECHO RQ and C-ECHO RSP in DIMSE message:

Double-click WireShark data packet between two, from the data flow can be concluded that one is the C-ECHO RQ message, one is the C-ECHO RSP message. First open the first, according to the analysis of the previous blog, first the packet is a P-DATA-TF PDU, so it needs to conform to the format in 23.

By analyzing the 04 H representing the P-DATA-TF type at the outermost layer, and then the PDV region filled by the DIMSE message, this Item is a composite Item, the first subitem is Item-length, where 46 H; the second subitem is Presentation-context-ID, which is 01 H. The third subitem is a composite item, which is the DIMSE message structure given in section 4th of DICOM standard, includes Message Control Header, Command, and DataSet. Here, MessageControlHeader is 03 H, indicating that it is Command data rather than DataSet, and it is the Last PDV, that is, Last Fragment. The specific relationship is shown in Figure 24:

C-STORE Service Data Flow Analysis: 1) Tools:

Rawcap.exe + WireShark is still used.

2) C-STORE Data Flow Analysis:

You can also see DICOM data packets, as shown in the analysis method in the C-ECHO, 25:

A-ASSOCIATE RQ/A-ASSOCIATE AC:

The analysis of the A-ASSOCIATE RQ/A-ASSOCIATE AC is basically similar to that of the C-ECHO, the only difference is that the C-STORE service requires a different Presentation Context to describe the Context, 26, here the C-STORE needs the CT Image Storage service, and its SOP Class UID is 1.2.840.10008.5.1.4.1.1.2.

A-RELEASE RQ/A-RELEASE RP:

Same as in the C-ECHO, this also demonstrates that the C-ECHO and C-STORE services in the blog are successfully implemented, and the connection can be released normally.

P-DATA-TF:

Here we focus on the analysis of C-STORE data packets in the P-DATA-TF service,Because transferring a DCM file requires multiple PDUS, multiple pdvs are also required. So we can learn about Message Control Header and DIMSE more vividly by analyzing C-STORE data packets..

Each packet transmitted in the same way first meets the format requirements of the P-DATA-TF, the first is the PDU type, namely 04 H; then is the retention, PDU-length, PDV composite ......, This is the same as the analysis in C-ECHO. According to the analysis of the previous blog, the C-STORE PROTOCOL process is the cstore scu to send C-STORE RQ messages to SCP, but when opening the first P-DATA packet in the figure we see is not the C-STORE RQ, but a data segment, as shown in 27.

It is similar to viewing the following P-DATA packets in turn. The last two are the last packet of the DCM file data in the C-STORE RQ (Last Fragment) And SCP sent to SCUC-STORE RSP, As shown in Figure 28:

From the value range of (bytes, 0100) in the last packet Command H, we can see that this Command is the C-STORE RSP.

You may be excited to see this, because we finally see the real data flow of the C-STORE service, but in all the DICOM corresponding packets in we did not find the C-STORE RQ packet initiated by the C-STORE SCU, soWhere is the C-STORE RQ packet??

Let's sort all the data packets of cstore. pcap by time. a large number of TCP data packets marked as [TCP segment of a reassembled PDU] appear.

Open the first TCP packet marked as [TCP segment of a reassembled PDU]. The actual internal data analysis is shown in Figure 30:

So far we successfully found the C-STORE RQ message sent by the C-STORE SCU side,The reason why WireShark is not shown in the DICOM protocol is probably because WireShark is not smart enough to identify data with multiple consecutive shards.. There are many sample images and texts in the blog post. After carefully reading this article, you should have a better understanding of the protocols in DICOM3.0. By analyzing data packets, you can learn and master the DICOM3.0 standard more intuitively, and troubleshoot DICOM network transmission errors in the future.

Note:

Explain how to read the DICOM3.0 standard again:

Take DICOM3.0 standard 7th, 8 part as an example, [7th] Chapter 9th began to explain the various services of DIMSE-C, c-STORE, C-FIND, C-GET, C-MOVE, C-ECHO (1 is what I 've captured in the C-ECHO section of this section ), among them, the first half of the main gives the parameters of various services of the DIMSE-C, here is only a list of DICOM3.0 standard requirements, the purpose is to let you know whether each service parameter is necessary (expressed by M, U, and = respectively ); the second part begins to explain the Protocol and implementation process of various DIMSE-C services (PROTOCOL and Procedures), in Protocol is given the specific DIMSE-C service of the various instructions in the format of the transmission process, this part is the real data stream that you can directly capture using the packet capture tool. Procedures provides the interaction process between SCU and SCP, which is usually used to indicate who initiated the service, who responds. When introducing Protocol, Variables Fields are usually included in the appendix, for example, appendix C and E in Part 1; [Part 1] is similar to [Part 2]. Chapter 2 describes the parameters of various ACSE services ), in order to A-ASSOCIATE, A-RELEASE, A-ABORT, A-P-ABORT, P-DATA; Chapter 9th gives the STRUCTURE of various services in ACSE, that is, STRUCTURE, this part is the same as the PROTOCOL in [Part 1]. It shows the data format of the specific acse pdu during transmission. This part can also be directly obtained through the packet capture tool; similarly, complicated STRUCTURE descriptions are also placed in the appendix, for example, appendix E in Part 1.

Instance engineering and captured data packets:

Code:Search my uploaded Resources

Data Packets:Search my uploaded Resources

Follow-up blog posts:

Use PHP Skel and DCMTK to develop web pacs applications

Using oracle to directly operate DICOM data

Application of C # asynchronous programming mode in fo-dicom

Test the three network connection modes of VMWare

Author:Zssure@163.com

Time: 2014-11-18