Mercurial > hg > orthanc-book
diff Sphinx/source/faq/features.rst @ 0:901e8961f46e
initial commit
author | Sebastien Jodogne <s.jodogne@gmail.com> |
---|---|
date | Fri, 22 Apr 2016 12:57:38 +0200 |
parents | |
children | 669ea65ba7fb |
line wrap: on
line diff
--- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/Sphinx/source/faq/features.rst Fri Apr 22 12:57:38 2016 +0200 @@ -0,0 +1,75 @@ +Terminology of advanced features +================================ + +.. _peers: + +Peers +----- + +An "Orthanc peer" is another instance of Orthanc, possibly running on +a remote computer. + +Contrarily to a "modality", it is possible to communicate with a peer +through the **HTTP/HTTPS protocol** (i.e. through the REST API of +Orthanc), and not through the DICOM protocol. This implies a much +easier configuration: It is only required to know the URL, the +username and the password to communicate with an Orthanc peer. This +contrasts with DICOM query/retrieve, that is quite complex and that +involves a lot of pitfalls (cf. the FAQ entry about :ref:`troubleshooting +DICOM communications <dicom>`) that can be bypassed if using HTTP. + +Furthermore, as HTTP(S) communications are generally not blocked by +firewalls (contrarily to the DICOM protocol that is inherently an +Intranet protocol and that often requires the setup of VPN tunnels), +it is much easier to setup communications of medical images through +the Internet with Orthanc peers. + + +.. _recycling: + +Recycling/Protection +-------------------- + +Because of its focus on low-end computers, Orthanc implements **disk +space recycling**: The patient that has been stored for the longest +time inside Orthanc can be automatically deleted when the disk space +used by Orthanc grows above a threshold, or when the number of stored +patients grows above a threshold. This feature enables the automated +control of the disk space dedicated to Orthanc. + +Recycling is controlled by the ``MaximumStorageSize`` and the +``MaximumPatientCount`` options in the :ref:`Orthanc configuration +file <configuration>`. + +It is possible to prevent important data from being automatically +recycled. This mechanism is called **protection**. Each patient can be +individually protected against recycling by using the +``Unprotected/Protected`` switch that is available from Orthanc +Explorer. + +Note that protection is only available at the patient level. It +protects all the studies/series/instances of the patient against +recycling. The rationale is that we think it is important to keep +available all the data related to one patient. Unwillingly losing a +study/series that is part of the same patient might lead to a loss in +consistency with respect to the medical history of this patient. + + +.. _compression: + +Compression +----------- + +If your disk space is limited, besides :ref:`recycling`, you should +also consider using **disk space compression**. When compression is +enabled, Orthanc compresses the incoming DICOM instances on-the-fly +before writing them to the filesystem, using `zlib +<http://en.wikipedia.org/wiki/Zlib>`_. This is useful, because the +images are often stored as raw, uncompressed arrays in DICOM +instances: The size of a typical DICOM instance can hopefully be +divided by a factor 2 through lossless compression. This compression +process is transparent to the user, as Orthanc automatically +decompresses the file before sending it back to the external world. + +Compression is controlled by the ``StorageCompression`` option in the +:ref:`Orthanc configuration file <configuration>`.