|
0
|
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
|
|
25
|
67 <https://en.wikipedia.org/wiki/Zlib>`_. This is useful, because the
|
|
0
|
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>`.
|
