Mercurial > hg > orthanc-book
comparison Sphinx/source/faq/transcoding.rst @ 275:2946fcd2e7fa
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). |