File: dcmtk.README.Debian

package info (click to toggle)
dcmtk 3.5.4-4
  • links: PTS, VCS
  • area: main
  • in suites: squeeze
  • size: 23,784 kB
  • ctags: 22,942
  • sloc: cpp: 165,761; ansic: 46,396; sh: 3,808; perl: 3,465; makefile: 3,097
file content (202 lines) | stat: -rw-r--r-- 8,949 bytes parent folder | download | duplicates (3)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
DCMTK - The OFFIS DICOM ToolKit for Debian
==========================================

General notes:

DCMTK is a collection of libraries and applications implementing large
parts the DICOM standard. It includes software for examining,
constructing and converting DICOM image files, handling offline media,
sending and receiving images over a network connection, as well as
demonstrative image storage and worklist servers. DCMTK is is written
in a mixture of ANSI C and C++. It comes in complete source code and
is made available as "open source" software under BSD like license
terms.  For additional information about DCMTK have a look at the
OFFIS web page:

   http://dicom.offis.de/dcmtk.php.en

DCMTK has been used at numerous DICOM demonstrations to provide
central, vendor-independent image storage and worklist servers (CTNs -
Central Test Nodes).  It is used by hospitals and companies all over
the world for a wide variety of purposes ranging from being a tool for
product testing to being a building block for research projects,
prototypes and commercial products.

DCMTK optionally supports some of the DICOM security extensions and
relies on the free OpenSSL toolkit for the underlying cryptographic
routines and the TLS protocol implementation. The Debian DCMTK package
has been built with OpenSSL support enabled.

More information about using the DCMTK network applications for secure
DICOM communication can be found in

   /usr/share/docs/dcmtk/ciphers.txt
   /usr/share/docs/dcmtk/randseed.txt

DCMTK optionally supports Wietse Venema's TCP wrappers library
(libwrap) which is freely available for most Unix platforms and part
of the default installation of most recent Linux distributions.  This
library allows to enforce host-based access control via the
"/etc/hosts_deny" and "/etc/hosts_allow" configuration files. The
Debian DCMTK package has been compiled with TCP wrapper support
enabled.  See hosts_access(5) man page for details.

You can use the dcmnet applications for testing DICOM connectivity. A
brief description can be found in

   /usr/share/docs/dcmtk/testing.txt


The DCMTK dcmqrscp application implements a DICOM image
storage/query/retrieve SCP which has been designed primarily as an
independent framework for cooperative tests and demonstrations of
DICOM connectivity by medical imaging vendors. If you want to set up
dcmqrdb as a DICOM image storage server please read both the dcmqrscp
manual pages and the supplemental documentation in

   /usr/share/doc/dcmtk/dcmqrcnf.txt
   /usr/share/doc/dcmtk/dcmqrset.txt

The dcmqrscp application can be invoked as a daemon process at boot
time by setting DCMQRSCP_ENABLE=Yes in /etc/defaults/dcmqrscp. You will
have to adjust the system wide configuration file
/etc/dcmtk/dcmqrscp.cfg to suit your needs.  This configuration file
provides optional UserName/GroupName keywords in the "Global
Parameter" section (see note in dcmqrcnf.txt). Running dcmqrscp with
root privileges is strongly discouraged.  A dedicated system
user/group dcmtk/dcmtk is automatically added during the installation
of the Debian DCMTK package.  It is important to note that dcmqrscp is
primarily intended to be used as a demonstration server rather than a
real "PACS replacement". Scalability is quite limited, both in terms
of number of images/studies and in number of parallel clients. If you
want to set up a real large database, you might be better off in using
an SQL based archive (such as the Mallinckrodt CTN).


DCMTK supports the Modality Worklist Management SOP Class as a SCP, which
allows modalities to query and retrieve worklist information from hospital
information systems. An example worklist database along with a set of 
example queries can be found in 

   /usr/share/doc/dcmtk/examples/wlistdb

and

   /usr/share/doc/dcmtk/examples/wlistqry.
 
Here is a brief instruction about how to make this work (based on a post
of Thomas Wilkens in comp.protocols.dicom):

1. Use dump2dcm to convert all "*.dump" files in examples/wlistdb/OFFIS
to "*.wl" files (DICOM format):

  $ for f in *.dump; do dump2dcm "$f" "${f%.dump}".wl; done

Note that these files have to have the extension "*.wl", otherwise wlmscpfs 
will not find these files. These files represent your worklist database.
2. Use dump2dcm to convert all "*.dump" files in examples/wlistqry to
"*.dcm" files (DICOM format):

  $ for f in *.dump; do dump2dcm "$f" "${f%.dump}".dcm; done
   
These files represent possible queries that can be used to query the worklist 
database.
3. In one shell run the following command to start the worklist management SCP:

  $ wlmscpfs -v -dfp examples/wlistdb 1234

4. In another shell run the following command to send a certain query to the 
WLM SCP:

  $ findscu -v --call OFFIS localhost 1234 examples/wlistqry/wlistqry0.dcm 

Step 3 will start the worklist management SCP which will listen on port 1234
for incoming C-FIND RQ messages. The "-dfp examples/wlistdb" option
specifies that the worklist database can be found in folder "examples/wlistdb". 
Note that the worklist database can be organized in different storage areas. 
Subfolder "OFFIS" below "examples/wlistdb" is one (the only one in this case) 
storage area. In an incoming C-FIND RQ, an SCU has to tell wlmscpfs which 
storage area shall be queried; this is done by sending a certain "called AE title" 
to wlmscpfs.

Step 4 will send the query in file "examples/wlistqry/wlistqry0.dcm"
using a C-FIND-RQ message to the wlmscpfs application (which is running on
"localhost" and listening on port "1234"). Option "--call OFFIS" specifies
that the called AE title is "OFFIS" which in turn tells the wlmscpfs
application to query the storage area "OFFIS" in its worklist database.

The two programs should then dump information that shows their internal
processings (C-FIND RQ - C-FIND RSP). You can also use a different query
file in folder "examples/wlistqry" for querying the worklist database.

As the wlmscpfs is not a hospital information system, worklist entries 
must be created, updated and deleted manually. The Debian dcmtk-www
package contains a cgi-based WWW server application which provides an easy 
to use web interface for managing worklist entries from  any workstation 
in the network.  More information about the DCMTK worklist web interface can
be found in 

    /usr/share/doc/dcmtk-www/wwwapp.txt


For more information please visit the DCMTK homepage and the user forum at

    http://dicom.offis.de/dcmtk.php.en

and

   http://forum.dcmtk.org/


Debian specific notes:

The upstream sources are not packaging friendly in terms of the Unix Filesystem 
Hierarchy Standard (see e.g. http://www.pathname.com/fhs/). There is currently no 
straightforward way to install DCMTK in compliance with the FHS without kludging 
the build scripts in some way. 

Thus, the Debian DCMTK source package includes a number of patches to change the 
semantics of the --libdir and --datadir configure options in order to 
separate read-only architecture-independent data (e.g. the dicom.dic DICOM 
dictionary) from architecture-dependent object libraries. 
For backward compatibility, the original (i.e. violating FSH) behavior is 
preserved in case ./configure is invoked without --prefix option.

The Debian packages have been configured with the following options:

./configure --prefix=/usr                   \
            --exec-prefix=/usr              \
            --mandir=/usr/share/man         \
            --infodir=/usr/share/info       \
            --includedir=/usr/include/dcmtk \
            --libdir=/usr/lib               \
            --datadir=/usr/share            \
            --sysconfdir=/etc/dcmtk         \
            --with-private-tags             \
            --with-libtiff                  \
            --with-zlib                     \
            --with-libpng                   \
            --with-libxml                   \
            --with-libwrap                  \
            --with-openssl


There is currently no official support for shared libraries in DCMTK. 
We had to perfom some magic to have the DCMTK end user utilies 
linked dynamically against shared DCMTK library versions without 
forcing the utilities themselves to be compiled with -fPIC (which 
would impose some performance penalty upon them).  
In a first step we adjust config/Makefile.def to build the shared 
libraries with -fPIC. In a second step we build the shared libs 
only (i.e. without utilities). In a third step we restore the 
original state of config/Makefile.def. In a forth step we run 
`make clean' on the source tree. (This leaves the *.so libs 
untouched but forces recompilation in the next step.) 
In the last step we run `make all'. This will build both the 
utilities and the static libraries without -fPIC but links the 
utilities dynamically against the shared library versions. 


 -- Juergen Salk <juergen.salk@gmx.de> Thu, 22 Dec 2005 22:58:03 +0100