Mercurial > hg > orthanc-book

comparison Sphinx/source/faq/transcoding.rst @ 275:2946fcd2e7fa

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
transcoding
author Sebastien Jodogne <s.jodogne@gmail.com>
date Tue, 03 Sep 2019 13:16:46 +0200
parents
children 6cbcdb965ad3
comparison
equal deleted inserted replaced
274:c310a795c133 275:2946fcd2e7fa
1 .. _transcoding:
2
3 Transcoding of DICOM files
4 ==========================
5
6 General information
7 -------------------
8
9 As of release 1.5.7, Orthanc does not feature support for transcoding
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
16 <https://bitbucket.org/sjodogne/orthanc/src/default/TODO>`__, and for which
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
111 <https://bitbucket.org/sjodogne/orthanc/src/default/Resources/Samples/Lua/AutomatedJpeg2kCompression.lua>`__.
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).