Dicom:fo-dicom, Dcm4che14, Dcm4chee and other open source libraries continue to self-maintain

Preface

DICOM column Series Although written for many years, but still can not solve the daily problems encountered, in fact, this is precisely the programmer (Code farming) the most fun to work. Just like everyone's life, the environment is different, the events are different, the result is different naturally. The same is true of program development, with different operating systems, different software versions, and different local configurations that can lead to various problems.
"To give people to fish as a result of fishing", so the normal solution is to hope that through the column to explain, can let everyone really understand the reasons behind each problem, so as to proactively troubleshoot and solve problems. For troubleshooting and solving the problems encountered in the process, I will summarize Cheng Bowen for your reference. As mentioned above, each person's environment is different, the natural real solution is different, so it is only a reference.

Background:

DICOM related open-source libraries are many, according to the development of different languages mainstream there are three categories, based on DCMTK, Java-based Dcm4che, and C #-based fo-dicom (MDCM). Here again Dcm4chee is based on the DCM4CHE14 version, using the ejb2.x technology to develop a DICOM Archiving service framework that relies on JBoss, can be easily understood as an open-source PACs system. There are different maintenance agencies and people for each library, which can result in different versions and data format compatibility. Especially if the version of the Open source Library you are using in your own project has been upgraded, how to smooth over to the latest version, and how to patch the fixed bug to the existing version is especially critical.
Many of the open source libraries I use in my project will fork a personal private library on GitHub, and fix the bugs we find on weekdays based on the state of the country and the specifics, and pull the version of the main library to local merge at a time interval. This ensures that existing projects are running smoothly, adapting to project specificity, and compatible with major version-related patches. This post simply lists a few local fixes that can be found on my GitHub home page for more information.

Dcm4che14 Open Source Library: 1. Cdimseservice.cfind () Result return exception

Part of the source code for the Cfind () function is as follows:

//New Cammand Set, see:dicom part 7:message Exchange, 6.3.1 Command        //Set StructureCommand rqcmd = Dof.newcommand ();        RQCMD.INITCFINDRQ (Assoc.nextmsgid (), uids.studyrootqueryretrieveinformationmodelfind, priority); Dimse FINDRQ = Afact.newdimse (Pc.pcid (), rqcmd, keys);//Invoke Active association with find request DimseFUTURERSP future = Aassoc.invoke (FINDRQ);//Response to the C-find request.        //The result cannot is accessed until it has been set. line:2234        //Get The list of found objectsDimselist = Future.listpending (); Datasetvector =NewVector<dataset> ();//Process all elements         for(inti =0; I < dimselist.size ();        i++) {datasetvector.addelement (((DIMSE) dimselist.get (i)). GetDataSet ()); }returnDatasetvector;

From the code and naming rules, you can tell that Assoc.invoke should be an asynchronous request, and then look closely at the line:2234 tag line of the comment above,"The result cannot be accessed until it has been set. line:2234 ". Ideal state dimselist = future.listpending (); it should be a synchronous management with Futurerspimpl until all results are returned to get the internal data set.
Let's take a look at the futurerspimpl.listpending () function, the source code is as follows:

   //zssure:用于存储DIMSE返回结果   privatefinalnew ArrayList();   //zssure:获取返回结果   publicsynchronizedlistPending() {      return Collections.unmodifiableList(pending);         }

Where pending is what we want to get the final C-find query results, specifically for the pending operation as shown:

 //DimseListener Implementation--------------------------------- public  void  dimsereceived  (Association Assoc, Dimse Dimse) {if  (Dimse.getcommand (). ispending ()) {Pending.add (DIMSE);      } else  {set (DIMSE); }   }

This is the callback function that was called in the Dicom state machine that was previously introduced many times. The records used to process the summary c-find.
"Problem": However, there is a serious problem with local testing, and each time listpending returns a random result format. So what is causing the problem? Let's see if the listpending () function is capable of synchronizing until all the C-find results return smoothly.
The source above can see that listpending () does not appear in any synchronization operation, but the use of Java collections.unmodifiablelist , which is actually a simple refactoring method, Returns a read-only copy of pending, restricting external changes to pending, even if the synchronized keyword used by the listpending function is still not up to the purpose of waiting for all results to be returned, Because the Synchronized keyword restricts multiple threads to concurrently enter the Listpending function, the listpending function is not used in multiple threads. So the listpending () function is incorrectly designed and does not ensure that all results are returned. The true wait result return should use Futurerspimpl's IsReady function, from the judgment logic inside the dimsereceived function above, when the last result returns OK (i.e. non-pending), Futurerspimpl uses the SET function to mark ready as true, so you want to synchronize to ensure that all query results are obtained using the following method:

        // Invoke active association with find request Dimse        FutureRSP future = aassoc.invoke(findRq);        // Response to the C-FIND request.        // The result cannot be accessed until it has been set.        //zssure:2016/07/16 NIT        while(!future.isReady())        {            TimeUnit.MILLISECONDS.sleep(500);//you can do something by yourself        }        //zssure:2016/07/16 NIT end

Fo-dicom Open Source Library: 1. Transfersyntax Field Self-correcting

Prior to the introduction of transfer Syntax several times, in the Dicom medical image processing: DICOM network transmission differences between the abstract Syntax and transfer Syntax, The role of transfer syntax in network services is described in the differences between C-Store services in DICOM:dcmqrscp.exe and Storescu.exe. The JPEG lossless compression semantics mentioned in compressing DCM files and implicit VR Little Endian are described in how the Dicom:dcm4che Toolkit compresses DCM files (sequel).

Transfer Sytanx occupies an important place in the DICOM standard, both as the necessary element to the DCM file meta-information (metainformation), and the precondition of data transmission between two sides of DICOM Network service. There is also a point to note:Transfer Syntax "Scope", that is, its ability to influence the scope : The DICOM protocol specifies the file containing the header information (Files Meta information), the header information (that is, group= 0002) All elements default to explicit VR Little endian storage, the data body dataset (that is, the grouping of group>0002) element how to store the header information in the file Meta information transfer syntax to decide.

I submitted a self-check code for the fo-dicom Open Source Library transfersyntax field in the Fo-dico Private library on the GitHub home page Transfersyntax of DICOM file in Zssure GitHub. Specific analysis ideas can be found in the column of the previous blog: dicom: From the fo-dicom library to parse the dicom file extension ...

Dcm4chee2. X Open Source Storage framework:

Recently many users e-mail consulting Dcm4chee related issues, there are roughly the following categories: One is to use Dcm4chee to directly replace their existing PACS system, a kind of consulting dcm4chee is how to store and obtain images, The last category is about the problem of Chinese memory garbled in Dcm4chee. For the first two categories, I will simply express my personal views:
- first, Dcm4chee acts as a PACs. If you want to use Dcm4chee to replace your existing PACS as a transition period is possible, if you want to use long-term is not recommended. Because the current stable version of Dcm4chee is 2.X, this version relies on the JDK, the use of JBoss is very old version, there are many problems. In addition Dcm4chee is not only as image storage to design, the operation of the various functions of the module coupling heavy, so the actual operation of the maintenance process is more troublesome.
- second, for Dcm4chee storage and acquisition of images , it is recommended to download the DCM4CHEXXX Binary Toolkit directly from the official website. I recommend using the command-line tool to complete the interaction with the Dcm4chee directly through the DIMSE-C service, and I seldom use visual tools in the actual work, so we don't want to email the GUI tool with me, I really do not have ha. When you want to store data to Dcm4chee, Dcm4chee is a simple PACs that provides C-Store SCP services. You can use any C-Store SCU client to complete the upload task. If you want to get data from Dcm4chee, one is to download DCM files directly using C-get, C-move, and so on, which is obtained directly using Wado.
- third, Chinese garbled problem . This problem is not just in the Dcm4chee. This is the most common problem with MySQL database usage. Is nothing more than the various terminals (send, receive, store) the encoding format is inconsistent. Here I found a few articles 10 minutes to learn to understand and solve the MySQL garbled problem, detailed MySQL Chinese garbled problem: Three character set can be carefully read the following, according to the solution to each of their own links in the coding format. Simply cut a few pictures to indicate:

[Email protected]
Date: 2016-07-16

Dicom:fo-dicom, Dcm4che14, Dcm4chee and other open source libraries continue to self-maintain