Mercurial > hg > orthanc-book

comparison Sphinx/source/faq/features.rst @ 0:901e8961f46e

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
initial commit
author Sebastien Jodogne <s.jodogne@gmail.com>
date Fri, 22 Apr 2016 12:57:38 +0200
parents
children 669ea65ba7fb
comparison
equal deleted inserted replaced
-1:000000000000 0:901e8961f46e
1 Terminology of advanced features
2 ================================
3
4 .. _peers:
5
6 Peers
7 -----
8
9 An "Orthanc peer" is another instance of Orthanc, possibly running on
10 a remote computer.
11
12 Contrarily to a "modality", it is possible to communicate with a peer
13 through the **HTTP/HTTPS protocol** (i.e. through the REST API of
14 Orthanc), and not through the DICOM protocol. This implies a much
15 easier configuration: It is only required to know the URL, the
16 username and the password to communicate with an Orthanc peer. This
17 contrasts with DICOM query/retrieve, that is quite complex and that
18 involves a lot of pitfalls (cf. the FAQ entry about :ref:`troubleshooting
19 DICOM communications <dicom>`) that can be bypassed if using HTTP.
20
21 Furthermore, as HTTP(S) communications are generally not blocked by
22 firewalls (contrarily to the DICOM protocol that is inherently an
23 Intranet protocol and that often requires the setup of VPN tunnels),
24 it is much easier to setup communications of medical images through
25 the Internet with Orthanc peers.
26
27
28 .. _recycling:
29
30 Recycling/Protection
31 --------------------
32
33 Because of its focus on low-end computers, Orthanc implements **disk
34 space recycling**: The patient that has been stored for the longest
35 time inside Orthanc can be automatically deleted when the disk space
36 used by Orthanc grows above a threshold, or when the number of stored
37 patients grows above a threshold. This feature enables the automated
38 control of the disk space dedicated to Orthanc.
39
40 Recycling is controlled by the ``MaximumStorageSize`` and the
41 ``MaximumPatientCount`` options in the :ref:`Orthanc configuration
42 file <configuration>`.
43
44 It is possible to prevent important data from being automatically
45 recycled. This mechanism is called **protection**. Each patient can be
46 individually protected against recycling by using the
47 ``Unprotected/Protected`` switch that is available from Orthanc
48 Explorer.
49
50 Note that protection is only available at the patient level. It
51 protects all the studies/series/instances of the patient against
52 recycling. The rationale is that we think it is important to keep
53 available all the data related to one patient. Unwillingly losing a
54 study/series that is part of the same patient might lead to a loss in
55 consistency with respect to the medical history of this patient.
56
57
58 .. _compression:
59
60 Compression
61 -----------
62
63 If your disk space is limited, besides :ref:`recycling`, you should
64 also consider using **disk space compression**. When compression is
65 enabled, Orthanc compresses the incoming DICOM instances on-the-fly
66 before writing them to the filesystem, using `zlib
67 <http://en.wikipedia.org/wiki/Zlib>`_. This is useful, because the
68 images are often stored as raw, uncompressed arrays in DICOM
69 instances: The size of a typical DICOM instance can hopefully be
70 divided by a factor 2 through lossless compression. This compression
71 process is transparent to the user, as Orthanc automatically
72 decompresses the file before sending it back to the external world.
73
74 Compression is controlled by the ``StorageCompression`` option in the
75 :ref:`Orthanc configuration file <configuration>`.