The difference of C-Store service between DICOM:dcmqrscp.exe and Storescu.exe

background:

The column has written about the Dcmqrscp.exe and Storescu.exe Toolkit, but did not delve into the difference between the two. Dcmqrscp.exe tool is a mini version of PACs, can respond to C-find, C-move, C-get, C-Store and other DIMSE services, While the Storescu.exe tool is a c-store service user, you can see that both toolkits provide c-store SCU services. A question from Bo friends a few days ago made it possible to re-examine the differences between the two in realizing C-Store SCU services. Through the source code analysis found that the root of the problem in the presentation context of the construction of different ways, the following through a concrete example of the problem, and finally give a lame solution.

questions raised by Bo friends:

At first, the simple guess is "wrong parameter set", but the weekend back on their own computer to try a variety of parameter combinations did not solve the problem, so decided to start from the source code to find the source of the problem. The following is a simple record of the entire process of error troubleshooting, according to the idea of easy-to-use, from the Toolkit official document configuration instructions, multi-kit practical testing and source code analysis three aspects to elaborate.

DCMTK Toolkit Configuration official Documentation:Dcmqrscp.exe Tools:

The specific configuration of the Dcmqrscp.exe tool has been described in detail in the post dicom medical image processing: DCMTK Wiki-based learning PACs debugging, since the local test data are in the non-compressed format supported by the DICOM standard, i.e. 1.2.840.10008.1.2.1,little Endian Explicit, so the settings for DCM file transfer semantics (Transfer Syntax) were not involved. And the Bo friend y317215133y Encounter most of the problems and transfer syntax related, so need to re-learn the official website on the transmission semantics of the description.

Dcmqrscp.exe Toolkit The main configuration parameters for transfer syntax transmission semantics (see http://support.dcmtk.org/docs/dcmqrscp.html for details. ）：

Notice the two parts of the rectangle box mark in the observation, the meaning of the interior is mostly repeated, then why is it divided into two parts? and prefixed with prefer and propose, respectively? What do the incoming Association and outgoing association represent respectively? Because Dcmqrscp.exe acts as a minipacs, Dimse services include both the SCU side and the SCP side, for example, in C-move services, Dcmqrscp.exe Tools also act as C-move SCP and C-Store SCU two roles. This can be guessed that the transmission semantics are divided into two parts of the reason should be corresponding to the SCP and the SCU side respectively. To verify this idea, let's continue to look at the parameter configurations of other tools.

Storescu.exe Tools:

About the use of Storescu.exe tools read two previous posts Dicom medical image processing: Storescp.exe and Storescu.exe source analysis, learning C-Store request and DICOM Medical graphics processing: Storescp.exe and Storescu.exe sources Code Analysis, Learning C-Store request (continued), here we only focus on the Storescu.exe Toolkit parameter configuration, browse the official website document (http://support.dcmtk.org/docs/storescu.html) to get the following results:

By basically validating the conjecture in the previous section, propose and prefer are used to control the transport semantics on both the SCU and SCP, so there are only parameters in the Storescu.exe tool configuration that are prefixed with propose. To determine our conjecture, continue to look at the configuration of the Storescp.exe tool.

Storescp.exe Tools:

Do not wordy, directly post Storescp.exe the official configuration instructions (http://support.dcmtk.org/docs/storescp.html) as shown in:

Because Storescp.exe serves as the SCP role in the DIMSE service, there are only prefer-prefixed parameters in its configuration, which validates our guess.

problem local test:

So now you can recall the question raised by Bo friend Y317215133y at the beginning of the blog post. It opens the Dcmqrscp.exe as a PACS server, and the system uses the Movescu.exe tool to simultaneously query and download uncompressed little Endian Explicit and JPEG lossless compression two data from the Dcmqrscp.exe service side.

First, according to the above analysis, we know that the configuration parameters of the Dcmqrscp.exe and Movescu.exe kits include both prefer and propose. Take C-move service as an example to analyze the roles played by two tools in the implementation process, such as the following table:

toolkit	c-move	c-store
dcmqrscp.exe	SCP	SCU
movescu.exe	SCU	< Span style= "COLOR: #0000ff" > SCP

Therefore, from the parameter configuration, we want to query and download to both compressed and uncompressed two kinds of data, we should configure the C-move sub-service C-Store each end. If so, the approximate configuration process is the following table:

C-Store SCP

Movescu.exe +xa, which means that the C-Store SCP service opened by the Movescu.exe tool allows the receiver to store various types of data

C-Store SCU

Dcmqrscp.exe–xs, adding-xs to indicate that the C-Store SCU service that is turned on in the Dcmqrscp.exe Toolkit allows the data to be read and sent in JPEG lossless compression dcmqrscp.exe-x=, adding-x= to indicate that the C-Store SCU service that is turned on in the Dcmqrscp.exe Toolkit allows data to be read and sent in the default uncompressed format Note: The parameter configuration for transport semantics (Transfer Syntax) in the toolkit is single-choice, and cannot be done by setting multiple parameters to complete any combination of transmission semantics, such as if-xs,-x= is turned on at the same time,-xs overrides the-x= setting in order of precedence. Causes the-XS setting to be invalid.

local tests for default uncompressed data:

Enter the command line mode, the following command to open the server,

Dcmqrscp.exe–d–c d:\DcmScuScp\dcmqrscp.cfg

The client uses the study level query to download the data, with the following directives:

movescu.exe-d-S-AEC acme_store-aet acme1-aem ACME1--port 12345-od d:\ localhost 11110-k queryretrievelevel=study- K studyinstanceuid=1.3.6.1.4.1.30071.6.116521528759.4534135570203453

The parameters in the Movescu.exe directive are specific values, such as Acme_sotre, ACME1, Refer to the Dcmqrscp.cfg configuration file of the previous blog post, the specific can read post Dicom medical image processing: DCMTK wiki data Learning PACs debugging. The actual running result diagram is as follows:

As can be seen from the output of Dcmqrscp.exe and Movescu.exe, the use of studyinstanceuid= 1.3.6.1.4.1.30071.6.116521528759.4534135570203453 query obtains two sets of data, in which the traditional non-compressed data, that is, the transmission semantics of Little Endian Explicit, has been successfully saved to D:\ (as shown), and another set of JPEG lossless compression data transfer fails with a specific hint error as shown in the White box.

Local testing of JPEG lossless compression data:

According to previous analysis, to download JPEG lossless lossless compression data, it is necessary to c-store the SCU and SCP to open the corresponding transport semantics, that is, JPEG lossless TS. The previous section has explained that Dcmqrscp.exe serves as the SCU role in the C-Store service, and Movescu.exe acts as an SCP role. Re-set the SCU and SCP as follows:

Enter the following command to open the Dcmqrscp.exe server,

Dcmqrscp.exe–d–c D:\dcmscuscp\dcmqrscp.cfg –xs

Enter the following command to re-open the Movescu.exe client,

movescu.exe-d-S-AEC acme_store-aet acme1-aem ACME1--port 12345-od d:\ localhost 11110-k queryretrievelevel=study- K studyinstanceuid=1.3.6.1.4.1.30071.6.116521528759.4534135570203453+xs

The actual test results are basically similar to non-compressed data, such as:

After modifying the transmission semantics, this time in the D packing directory only see JPEG ll lossless compression data (such as),

Comparing the output error of the Dcmqrscp.exe server two times, it can be found that Movescu can only download uncompressed data when both the C-Store SCU and SCP are individually set for the JPEG lossless transmission semantics, for JPEG Lossless compressed data service-side hints cannot be converted to little Endian explicit semantics by JPEG Lossless, non-hierarchical, 1st Order prediction Semantics , and after the JPEG Lossless semantics parameters are set individually, Dcmqrscp.exe server prompts for uncompressed data cannot be converted from little Endian explicit semantics to JPEG Lossless, non-hierarchical , 1st Order prediction Semantics . -This also appeared in the previous article Bo friends encountered practical problems.

Problem Analysis:traced to:

Let us from the root of the repeated, Movescu query has patient, Study, series three levels, what is the case will be queried at the same time the target data and contain two types of compression and non-compression respectively? The patient level can contain multiple study checks, and each check usually corresponds to a different image device, so there is a high probability that a query at the patient level will occur, such as an example given by blog post such as:

Above we have been using the study level of query, then will not be the query level problems? By uploading two sets of compressed and uncompressed data tests for the same two sets of patient again, I can clearly say that the problem is not caused by the query level. is the service-side Dcmqrscp.exe? Or the client Movescu.exe?

start with the test data construct:

It occurred to me that at first, in order to reproduce the problem in the blog post, the test data was constructed by manually modifying two images in the same sereis under the same study and then storing it to the Dcmqrscp.exe server by two times Storescu.exe. Two times the Storescu.exe tool also uses the transfer semantics parameter settings when submitting data in different formats, so let's look back:

To construct non-compressed data:

Service side:dcmqrscp.exe–d–c d:\dcmscuscp\dcmqrscp.cfg

Client:storescu.exe-d localhost 11110-aec acme_store-aet ACME1 c:\test.dcm

The local test results are as follows and the test data upload is completed successfully

constructing JPEG Lossless lossless compression data:

Service side:dcmqrscp.exe–d–c d:\dcmscuscp\dcmqrscp.cfg

Client:storescu.exe-d localhost 11110-aec acme_store-aet ACME1 c:\testLS.dcm–xs

As input, we find that we are familiar with errors that cannot be translated from JPEG Lossless, non-hierarchical, 1st Order prediction semantics to Little Endian explicit semantics , such as:

According to the previous analysis, it should be the server configuration is wrong, dcmqrscp.exe in the C-Store SCP need to open +XS

Re-open server:dcmqrscp.exe–d–c d:\dcmscuscp\dcmqrscp.cfg+xs

Client:storescu.exe-d localhost 11110-aec acme_store-aet ACME1 c:\testLS.dcm–xs

use Storescp.exe to troubleshoot:

When the test data is constructed, it is considered impossible to solve the problem of Bo friends, only different services can be opened separately to achieve simultaneous download of compressed and non-compressed data to the local. This is because the entire process of constructing test data has been clearly understood and mastered in the toolkit about transport semantics, but no problem has been found. The use of source debugging has not combed out any clue, the problem is so terminated?

To think about it, Dcmqrscp.exe is a minipacs server, the function is more complex, in debugging the source code is not convenient, then can use the previous Introduction C-Store blog, using Storescp.exe and Storescu.exe two toolkit to debug to see the specific transmission semantics settings?

The input instruction opens the C-Store SCP server separately:

storescp.exe–d 11110–od \ +xa, where you use the +XA setting to allow any transport semantics for the client directly

Enter the command to open the C-Store SCU client:

storescu.exe–d localhost 11110 c:\test.dcm

stroescu.exe–d localhost 11110 c:\testls.dcm–xs

storescu.exe–d localhost 11110 c:\test.dcm–xs

In the actual testing process found that the service order Storescu.exe on the-XS switch, can simultaneously achieve non-compression and JPEG lossless lossless compression two sets of data

Storescu.exe and Dcmqrscp.exe source code comparison analysis:

Now that you have verified that the Storescu.exe tool can upload uncompressed and compressed data to the server at the same time, the problem should appear inside the Dcmqrscp.exe tool. When implementing the C-move functionality, the Dcmqrscp.exe tool needs to provide the C-Store SCU service, so it is possible to speculate that the C-Store SCU service may be turned on differently, resulting in an issue where blog post cannot transmit both format data at the same time.

Find the code in the Storescu.exe tool and the Dcmqrscp.exe tool, respectively, about opening the C-Store SCU service, and see the main information about presentation Context Settings section (Introduction to Presentationcontext can be referred to post dicom medical image processing: DICOM network transmission)

You can see the robustness of the settings for Presentationcontext in the Storescu.exe Toolkit, for example, when the-xs parameter is added, the addstoragepresentationcontexts function of Storescu.exe adds two kinds of pre Sentationcontext, which contains jpeglossless compressed transport semantics (that is, preferredtransfersyntax in), One is that it does not contain jpeglossless compression transport semantics (fallbacksyntaxes), and of course there is one of the two semantics, namely Combinedsyntaxes.

The sub operation (C-Store SCU), which is opened by Movecallback, is Dcmqrscp.exe, although presentationcontext arrays are constructed according to the-XS option when Transfersyntax is added. Contains the following four transport semantics (such as), but not for Uid_jpegprocess14sv1transfersyntax and uid_ when adding presentationcontext Littleendianexplicittransfersyntax is added separately, so that when the-XS switch is turned on, ctimagestorage corresponding presentationcontext can only accept Uid_ Jpegprocess14sv1transfersyntax lossless compression transmission semantics.

To verify the above guess, We use the command line redirection tool to write the debug information of the Dcmqrscp.exe and Storescu.exe in conjunction with the construction of the test data to the file, compare the Dcmqrscp.exe and Movescu.exe tools to query the debug information of the downloaded data, and look at the C-Store The Presentationcontext for the SCU service is different, as shown in the details:

If we find the root of the problem here, then where is the corresponding basis? The previous blog post also mentions the specific details of the establishment of DICOM Association in Appendix D to part 7th of the DICOM3.0 Standard, in which there is a passage:

As we can see, for the same service is Presentationcontext mentioned in the Abstractsyntax, that is, the ctimagestorage in this blog, in order to achieve a variety of transmission semantics, It is necessary to construct presentationcontext for each semantics separately, if it is possible to achieve the purpose of simultaneously compatible with multiple transport semantics.

Modify the attempt:

Now that we have found the source of the problem, it is time to give a concrete solution, and the most appropriate modification should be to modify the corresponding addallstoragepresentationcontexts function in the Dcmqrscp.exe Toolkit ( The specific code in the dcmqrcbm.cc file of 516 lines ), when adding presentationcontext, according to the transport semantics of the state to add Presentationcontext, The specific add code can be modeled after the Addstoragepresentationcontexts function in the Storescu.exe Toolkit ( specific code in the storescu.cc file 1167 lines ) within 1263-1280 line.

Because of the time relationship here, I don't specifically introduce the process of modification, in order to demonstrate this blog post analysis, here is a simple method. Of course, the method because of the wide impact, modified after the entire DCMTK library has an impact, so it is not recommended. The simple approach is to directly modify the Dimse_sendmessage function in dimse.cc, as shown in:

Since the expected transport semantics (propose) does not match the actual transfer semantics (Transfersyntax UID) of the specific file, the file cannot be sent, then the Dimse_ In the SendMessage function, when the mismatch between the two is detected by default, the original transport semantics of the DCM file is sent, it is important to note that at this point the movescu.exe side needs to turn on the +xa service, allowing all transmission semantics to be received. After modifying the above code, recompile the Dcmnet project, generate the Dcmnet.lib file, you can download the two transmission semantics at the same time, is my native test results:

Finally, remember to change the back after the restoration. The best way to do this is to modify the code in the Dcmqrscp.exe project and not modify the underlying file (dimse.cc) code of the DCMTK library.

(End of this article)

[email protected]

Date: 2015-01-17

The difference of C-Store service between DICOM:dcmqrscp.exe and Storescu.exe