|
275
|
1 .. _transcoding:
|
|
|
2
|
|
|
3 Transcoding of DICOM files
|
|
|
4 ==========================
|
|
|
5
|
|
411
|
6 .. contents::
|
|
|
7
|
|
|
8
|
|
|
9 Work-in-progress
|
|
|
10 ----------------
|
|
|
11
|
|
|
12 Forthcoming Orthanc 1.7.0 will feature transcoding. The information in
|
|
|
13 the sections below will thus soon become invalid!
|
|
|
14
|
|
|
15 To be documented for Orthanc 1.7.0:
|
|
|
16
|
|
|
17 * Explanation of DICOM protocol (transparent transcoding from
|
|
|
18 compressed transfer syntaxes to uncompressed transfer syntaxes).
|
|
|
19
|
|
|
20 * ``TranscodingEnabled`` global configuration option
|
|
|
21
|
|
|
22 * ``AllowTranscoding`` in ``DicomModalities`` configuration option
|
|
|
23
|
|
|
24 * ``/instances/.../modify`` route: ``Transcode`` option
|
|
|
25
|
|
|
26
|
|
275
|
27 General information
|
|
|
28 -------------------
|
|
|
29
|
|
392
|
30 As of release 1.6.1, Orthanc does not feature support for transcoding
|
|
275
|
31 DICOM instances yet. In other words, the Orthanc core never changes
|
|
|
32 the :ref:`transfer syntax <dicom-pixel-data>` of some DICOM instance
|
|
|
33 when it has to send it to another modality using the DICOM protocol.
|
|
|
34
|
|
|
35 Adding support for transcoding is one of the features that is pending
|
|
|
36 on `our roadmap
|
|
360
|
37 <https://hg.orthanc-server.com/orthanc/file/default/TODO>`__, and for which
|
|
275
|
38 we are looking for industrial sponsors.
|
|
|
39
|
|
|
40
|
|
|
41 Motivation for transcoding
|
|
|
42 --------------------------
|
|
|
43
|
|
|
44 Let's consider the following basic workflow, in which some imaging
|
|
|
45 workstation must access a medical image that originates from a PACS
|
|
|
46 and that is served through an Orthanc proxy:
|
|
|
47
|
|
|
48 .. image:: ../images/Transcoding1.svg
|
|
|
49 :align: center
|
|
|
50 :width: 700px
|
|
|
51
|
|
|
52 This is quite a common situation, e.g. in university hospitals where
|
|
|
53 researchers must access medical images without having authorization to
|
|
|
54 log in the clinical PACS. It is also common if the main PACS restricts
|
|
|
55 the number of workstations that can directly be connected to it, or if
|
|
|
56 Orthanc acts as gateway through Internet.
|
|
|
57
|
|
|
58 The problem is that the software running on workstations might not be
|
|
|
59 able to display some DICOM transfer syntaxes. This is especially true
|
|
|
60 in research software, that is often limited to uncompressed transfer
|
|
|
61 syntaxes. For instance, let's consider the following scenario where a
|
|
|
62 workstation wants to access an image from the PACS:
|
|
|
63
|
|
|
64 .. image:: ../images/Transcoding2.svg
|
|
|
65 :align: center
|
|
|
66 :width: 700px
|
|
|
67
|
|
|
68 A typical PACS system will decide, when requested to export an image
|
|
|
69 using DICOM C-Store, to compress the image in order to reduce the
|
|
|
70 network bandwidth and the storage requirements. Orthanc is fine with
|
|
|
71 it: As a vendor neutral archive, Orthanc can basically
|
|
|
72 receive/store/transmit any DICOM transfer syntax. Unfortunately, this
|
|
|
73 might not be the case of the target workstation, that is often limited
|
|
|
74 to some selected transfer syntaxes. As a consequence, the workstation
|
|
|
75 will complain about not being to read the DICOM file (in the situation
|
|
|
76 depicted above, because the PACS has decided to send the DICOM image
|
|
|
77 using the JPEG2k transfer syntax).
|
|
|
78
|
|
|
79
|
|
|
80 Solutions
|
|
|
81 ---------
|
|
|
82
|
|
|
83 There are basically 4 solutions to this issue. The first one, as
|
|
|
84 stated above, would be to **implement transcoding in Orthanc**. Feel
|
|
|
85 free to `get in touch with us
|
|
|
86 <https://www.orthanc-server.com/orthanc-pro.php>`__ if you want to
|
|
|
87 sponsor this development.
|
|
|
88
|
|
|
89 The second solution consists in making Orthanc **refuse to accept the
|
|
|
90 transfer syntaxes** that are not supported by the workstation. This
|
|
|
91 is depicted in the following diagram:
|
|
|
92
|
|
|
93 .. image:: ../images/Transcoding3.svg
|
|
|
94 :align: center
|
|
|
95 :width: 700px
|
|
|
96
|
|
|
97 .. highlight:: json
|
|
|
98
|
|
|
99 If Orthanc tells the PACS that is doesn't accept, say, DICOM JPEG2k,
|
|
|
100 the source PACS will be aware of this, and will transcode the DICOM
|
|
|
101 file before it is sent to Orthanc. This is the role of the following
|
|
|
102 :ref:`configuration options <configuration>` that specifies which
|
|
|
103 transfer syntaxes are accepted by Orthanc::
|
|
|
104
|
|
|
105 {
|
|
|
106 "DeflatedTransferSyntaxAccepted" : true,
|
|
|
107 "JpegTransferSyntaxAccepted" : true,
|
|
|
108 "Jpeg2000TransferSyntaxAccepted" : true,
|
|
|
109 "JpegLosslessTransferSyntaxAccepted" : true,
|
|
|
110 "JpipTransferSyntaxAccepted" : true,
|
|
|
111 "Mpeg2TransferSyntaxAccepted" : true,
|
|
|
112 "RleTransferSyntaxAccepted" : true,
|
|
|
113 "UnknownSopClassAccepted" : false
|
|
|
114 }
|
|
|
115
|
|
|
116 If all of those options are set to ``false``, Orthanc will only
|
|
|
117 receive uncompressed transfer syntaxes (obviously provided that the
|
|
|
118 source PACS supports DICOM transcoding).
|
|
|
119
|
|
|
120 The third solution consists in **applying an external conversion
|
|
|
121 tool** to every DICOM image that is received by Orthanc. The standard
|
|
|
122 command-line tools ``gdcmconv`` from `GDCM
|
|
|
123 <http://gdcm.sourceforge.net/html/gdcmconv.html>`__ or ``dcmconv``
|
|
|
124 from `DCMTK <https://support.dcmtk.org/docs/dcmconv.html>`__ can be
|
|
|
125 used to change the transfer syntax of a given DICOM file. These tools
|
|
|
126 can be invoked from a :ref:`Lua script <lua>` (check out
|
|
|
127 ``OnStoredInstance()`` callback) or from an :ref:`Orthanc plugin
|
|
|
128 <creating-plugins>` (check out
|
|
|
129 ``OrthancPluginRegisterOnStoredInstanceCallback()`` function). A
|
|
|
130 sample Lua script that converts every incoming DICOM file to the
|
|
|
131 JPEG2k transfer syntax is `part of the Orthanc sources
|
|
360
|
132 <https://hg.orthanc-server.com/orthanc/file/default/Resources/Samples/Lua/AutomatedJpeg2kCompression.lua>`__.
|
|
275
|
133
|
|
|
134
|
|
|
135 Finally, as a fourth solution, it is possible to **combine two Orthanc
|
|
|
136 servers**, the first one being configured to accept any transfer
|
|
|
137 syntax, and the second one being responsible to serve the DICOM files
|
|
|
138 after conversion to uncompressed transfer syntax (which should be
|
|
|
139 compatible with any workstation):
|
|
|
140
|
|
|
141 .. image:: ../images/Transcoding4.svg
|
|
|
142 :align: center
|
|
|
143 :width: 700px
|
|
|
144
|
|
|
145 In this solution, a plugin or an external script continuously monitors
|
|
|
146 the content of the first Orthanc server thanks to its :ref:`REST API
|
|
|
147 <rest>`. Whenever a DICOM instance is received by the first Orthanc,
|
|
|
148 the plugin/script uses external conversion tools to convert the
|
|
|
149 instance to an uncompressed transfer syntax, then forward it to a
|
|
|
150 second Orthanc server. In other words, the first Orthanc server acts
|
|
|
151 as a transient buffer for decompression. Contrarily to the third
|
|
|
152 solution, this solution has the advantage of better scalability (as
|
|
|
153 decompression implemented in a Lua callback blocks Orthanc as long as
|
|
|
154 the Lua script has not returned).
|
