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