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