Mercurial > hg > orthanc-book
changeset 329:117be48706ba
merge
author | Sebastien Jodogne <s.jodogne@gmail.com> |
---|---|
date | Thu, 05 Mar 2020 09:55:00 +0100 |
parents | d39237f67df6 (current diff) ce27545e58e6 (diff) |
children | dc9accc64768 |
files | Sphinx/source/users/storage-commitment.rst |
diffstat | 5 files changed, 83 insertions(+), 28 deletions(-) [+] |
line wrap: on
line diff
--- a/Sphinx/source/_templates/layout.html Thu Mar 05 09:54:44 2020 +0100 +++ b/Sphinx/source/_templates/layout.html Thu Mar 05 09:55:00 2020 +0100 @@ -25,4 +25,14 @@ </p> </div> </footer> + +<!-- Google Analytics --> +<script> + (function(i,s,o,g,r,a,m){i['GoogleAnalyticsObject']=r;i[r]=i[r]||function(){ + (i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new Date();a=s.createElement(o), + m=s.getElementsByTagName(o)[0];a.async=1;a.src=g;m.parentNode.insertBefore(a,m) + })(window,document,'script','//www.google-analytics.com/analytics.js','ga'); + ga('create', 'UA-33455438-2', 'orthanc-server.com'); + ga('send', 'pageview'); +</script> {% endblock %}
--- a/Sphinx/source/_templates/layout.html.analytics Thu Mar 05 09:54:44 2020 +0100 +++ b/Sphinx/source/_templates/layout.html.analytics Thu Mar 05 09:55:00 2020 +0100 @@ -17,7 +17,7 @@ </p> <p> - © Copyright 2015-2020, University Hospital of Liège and Osimis, Belgium<br/> + © Copyright 2015-2020, University Hospital of Liège and Osimis, Belgium, and the Orthanc community<br/> The Orthanc Book is licensed under <a href="http://creativecommons.org/licenses/by-sa/4.0/" target="_blank">Creative Commons CC-BY-SA 4.0</a>.<br/>
--- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/Sphinx/source/_templates/layout.html.no-analytics Thu Mar 05 09:55:00 2020 +0100 @@ -0,0 +1,28 @@ +{# Import the theme's layout. #} +{% extends "!layout.html" %} + +{# Custom CSS overrides #} +{% set bootswatch_css_custom = ['_static/orthanc.css'] %} + + +{% block footer %} +<footer class="footer"> + <div class="container"> + <p class="pull-right"> + <a href="#">Back to top</a> + {% if theme_source_link_position == "footer" %} + <br/> + {% include "sourcelink.html" %} + {% endif %} + </p> + <p> + + © Copyright 2015-2020, University Hospital of Liège and Osimis, Belgium, and the Orthanc community<br/> + The Orthanc Book is licensed under + <a href="http://creativecommons.org/licenses/by-sa/4.0/" target="_blank">Creative + Commons CC-BY-SA 4.0</a>.<br/> + {% trans sphinx_version=sphinx_version|e %}Created using <a href="http://sphinx-doc.org/">Sphinx</a> {{ sphinx_version }}.{% endtrans %}<br/> + </p> + </div> +</footer> +{% endblock %}
--- a/Sphinx/source/plugins/dicomweb.rst Thu Mar 05 09:54:44 2020 +0100 +++ b/Sphinx/source/plugins/dicomweb.rst Thu Mar 05 09:55:00 2020 +0100 @@ -275,7 +275,7 @@ } } -Two important options can be provided for individual remote DICOMweb servers: +Three important options can be provided for individual remote DICOMweb servers: * ``HasDelete`` can be set to ``true`` to indicate that the HTTP DELETE method can be used to delete remote studies/series/instances. @@ -289,11 +289,26 @@ this option to ``true`` is the best choice to reduce memory consumption. However, it must be set to ``false`` if the remote DICOMweb server is Orthanc <= 1.5.6, as chunked transfer encoding is - only supported starting with Orthanc 1.5.8. Beware setting ``ChunkedTransfers`` - to ``true`` utilizes all CPU resources which results in extremely low throughput - as of version 1.0 of the DICOMweb plugin (see - `issue 156 <https://bitbucket.org/sjodogne/orthanc/issues/156/>`__ for status). + only supported starting with Orthanc 1.5.7. Beware setting + ``ChunkedTransfers`` to ``true`` in Orthanc 1.5.7 and 1.5.8 utilizes + one CPU at 100%, which results in very low throughput: This issue is + resolved in Orthanc 1.6.0 (cf. `issue 156 + <https://bitbucket.org/sjodogne/orthanc/issues/156/>`__ for full + explanation). +* ``HasWadoRsUniversalTransferSyntax`` (new in DICOMweb 1.1) must be + set to ``false`` if the remote DICOMweb server does not support the + value ``transfer-syntax=*`` in the ``Accept`` HTTP header for + WADO-RS requests. This option is notably needed if the remote + DICOMweb server is Orthanc equipped with DICOMweb plugin <= 1.0. On + the other hand, setting this option to ``true`` prevents the remote + DICOMweb server from transcoding to uncompressed transfer syntaxes, + which gives `much better performance + <https://groups.google.com/d/msg/orthanc-users/w1Ekrsc6-U8/T2a_DoQ5CwAJ>`__. + The implicit value of this parameter was ``false`` in DICOMweb + plugin <= 1.0, and its default value is ``true`` since DICOMweb + plugin 1.1. + You'll have to convert the JSON array into a JSON object to set these options:: @@ -306,7 +321,8 @@ "Username" : "username", "Password" : "password", "HasDelete" : true, - "ChunkedTransfers" : true // Set to "false" if "sample" is Orthanc <= 1.5.6 + "ChunkedTransfers" : true, // Set to "false" if "sample" is Orthanc <= 1.5.6 + "HasWadoRsUniversalTransferSyntax" : true // Set to "false" if "sample" is Orthanc DICOMweb plugin <= 1.0 } } }
--- a/Sphinx/source/users/storage-commitment.rst Thu Mar 05 09:54:44 2020 +0100 +++ b/Sphinx/source/users/storage-commitment.rst Thu Mar 05 09:55:00 2020 +0100 @@ -11,20 +11,20 @@ ------------ Starting with **release 1.6.0**, Orthanc implements DICOM storage -commitment, both as an SCP and as a SCU. +commitment, both as SCP and as SCU (i.e. both as a server and as a +client). Storage commitment is a feature of the DICOM standard by which an imaging modality "A" asks a remote imaging modality "B", whether "B" -accepts responsibility for having stored the images "A" has sent to -it. +accepts responsibility for having stored a set of DICOM instances. Typically, a storage commitment request is issued by "A" after "A" has sent images to "B" using the :ref:`DICOM C-STORE command <dicom-store>`. If "B" answers that all the images have been properly received, the modality "A" has the guarantee that the C-STORE commands -ran fine, and thus "A" might decide to remove the images from its -database. If "B" answers that there was an error, "A" might decide to -send the images again. +ran fine, and thus "A" could decide to remove the images from its +local database. If "B" answers that there was an error, "A" could +decide to send the images again. For more technical information, one may refer to the storage commitment `Information Object Definition @@ -71,29 +71,28 @@ The list of the DICOM modalities from which Orthanc accepts incoming storage commitment requests is specified in the :ref:`configuration -file of Orthanc <configuration>`, by the ``DicomModalities`` +file of Orthanc <configuration>`, through the ``DicomModalities`` option. It is possible to disable storage commitment for selected modalities by setting their dedicated Boolean permission flag ``AllowStorageCommitment`` to ``false``. -As can be seen, the storage commitment SCP of Orthanc also takes -advantage of the :ref:`jobs engine <jobs>` that is embedded within -Orthanc. Whenever Orthanc receives a storage commitment request, it -internally creates a job with a dedicated type (namely -``StorageCommitmentScp``). :ref:`This job can be controlled +As can be seen in the figure above, the storage commitment SCP of +Orthanc takes advantage of the :ref:`jobs engine <jobs>` that is +embedded within Orthanc. Whenever Orthanc receives a storage +commitment request, it internally creates a job with a dedicated type +(namely ``StorageCommitmentScp``). :ref:`This job can be controlled <jobs-monitoring>` using the REST API of Orthanc, just like any other job. As a consequence, an external software is able to monitor, cancel or pause incoming storage commitment requests, by inspecting the list of jobs whose type is ``StorageCommitmentScp``. - Sample usage ^^^^^^^^^^^^ In this section, we show how to query the storage commitment SCP of Orthanc from the command-line tool ``stgcmtscu``. This free and -open-source tool originates from the `dcm4che project +open-source tool is part of the `dcm4che project <https://www.dcm4che.org/>`__ and simulates a basic storage commitment SCU. @@ -143,11 +142,12 @@ As can be seen, the SOP class/instance UIDs of ``/tmp/DummyCT.dcm`` are reported by the Orthanc SCP in the ``FailedSOPSequence`` field, which indicates the fact that Orthanc has not stored this instance -yet. The ``FailureReason`` 274 corresponds to status 0x0112, namely -"No such object instance". +yet. The ``FailureReason`` 274 corresponds to `status 0x0112 +<http://dicom.nema.org/medical/dicom/current/output/chtml/part03/sect_C.14.html#sect_C.14.1.1>`__, +namely *"No such object instance"*. -Fourthly, let's upload the sample file, then execute ``stgcmtscu`` a -second time:: +Fourthly, let's upload the sample file to Orthanc, then execute +``stgcmtscu`` for a second time:: $ storescu localhost 4242 /tmp/DummyCT.dcm $ /home/jodogne/Downloads/dcm4che-5.20.0/bin/stgcmtscu -b STGCMTSCU:11114 -c ORTHANC@localhost:4242 /tmp/DummyCT.dcm @@ -184,9 +184,10 @@ function of the `plugin SDK <http://sdk.orthanc-server.com/>`__. Importantly, this primitive frees the plugin developer from manually -creating the Orthanc jobs. One job is automatically created for each -incoming storage commitment request by the Orthanc core, allowing the -developer to focus only on the processing of the queried instances. +creating the Orthanc jobs. One job is transparently created by the +Orthanc core for each incoming storage commitment request, allowing +the plugin developer to focus only on the processing of the queried +instances. Note that a `sample plugin <https://bitbucket.org/sjodogne/orthanc/src/storage-commitment/Plugins/Samples/StorageCommitmentScp/>`__