Mercurial > hg > orthanc-book

comparison Sphinx/source/dicom-guide.rst @ 427:71281b540ca1

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
updating old documentation about transcoding
author Sebastien Jodogne <s.jodogne@gmail.com>
date Fri, 22 May 2020 10:10:21 +0200
parents e0b4b88446a8
children c3e73c00ef48
comparison
equal deleted inserted replaced
422:b8b9b108a697 427:71281b540ca1
110 110
111 In practice, few imaging devices in hospitals (besides the `PACS 111 In practice, few imaging devices in hospitals (besides the `PACS
112 <https://en.wikipedia.org/wiki/Picture_archiving_and_communication_system>`__ 112 <https://en.wikipedia.org/wiki/Picture_archiving_and_communication_system>`__
113 itself) support image compression. As a consequence, to ensure best 113 itself) support image compression. As a consequence, to ensure best
114 portability, the pixel data of most DICOM files circulating in 114 portability, the pixel data of most DICOM files circulating in
115 hospitals is **uncompressed**. In other words, the image is encoded as 115 hospitals is generally **uncompressed**. In other words, the image is
116 a raw buffer, with a given width, height, pixel type (integer or 116 encoded as a raw buffer, with a given width, height, pixel type
117 float), `color depth <https://en.wikipedia.org/wiki/Color_depth>`__ 117 (integer or float), `color depth
118 (most often 8, 10, 12 bpp - *bits per pixel*) and photometric 118 <https://en.wikipedia.org/wiki/Color_depth>`__ (most often 8, 10, 12
119 interpretation (most often grayscale or RGB). The transfer syntax that 119 bpp - *bits per pixel*) and photometric interpretation (most often
120 is associated with such uncompressed images can either be `little 120 grayscale or RGB). The transfer syntax that is associated with such
121 endian <https://fr.wikipedia.org/wiki/Endianness>`__ (the most common 121 uncompressed images can either be `little endian
122 case) or big endian. 122 <https://fr.wikipedia.org/wiki/Endianness>`__ (the most common case)
123 or big endian (retired in recent versions of the DICOM standard).
124
125 The process of converting one DICOM instance from some transfer syntax
126 to another one is referred to as **transcoding**. The topic of
127 transcoding is covered in a :ref:`separate FAQ entry <transcoding>`.
123 128
124 A DICOM image can be **multi-frame**, meaning that it encodes an array 129 A DICOM image can be **multi-frame**, meaning that it encodes an array
125 of different image frames. This is for instance used to encode 130 of different image frames. This is for instance used to encode
126 uncompressed video sequences, that are often referred to as **cine** 131 uncompressed video sequences, that are often referred to as **cine**
127 or **2D+t** images (e.g. for `ultrasound imaging 132 or **2D+t** images (e.g. for `ultrasound imaging
573 server. The DICOM standard features an alternative mechanism called 578 server. The DICOM standard features an alternative mechanism called
574 :ref:`DICOM C-Get <dicom-get>` that has been introduced in Orthanc 579 :ref:`DICOM C-Get <dicom-get>` that has been introduced in Orthanc
575 1.7.0 (see below). 580 1.7.0 (see below).
576 581
577 *Note 2:* As :ref:`written above <dicom-pixel-data>`, the Orthanc 582 *Note 2:* As :ref:`written above <dicom-pixel-data>`, the Orthanc
578 engine is quite generic and is compatible with virtually any image 583 engine is quite generic and is compatible with many image compression
579 compression algorithm (aka. transfer syntax). In particular, during 584 algorithms (aka. transfer syntax). In particular, during the
580 the :ref:`negotiation of a presentation context 585 :ref:`negotiation of a presentation context
581 <dicom-protocol-overview>`, Orthanc reports by default that it is 586 <dicom-protocol-overview>`, Orthanc reports by default that it is
582 compatible with the JPEG 2000 encoding. This leads some PACS engines 587 compatible with the JPEG 2000 encoding. This leads some PACS engines
583 to compress their images before sending them to Orthanc, so as to 588 to compress their images before sending them to Orthanc, so as to
584 reduce the network bandwidth. Unfortunately, because many medical 589 reduce the network bandwidth. Unfortunately, because many medical
585 image analysis software are not compatible with such an image 590 image analysis software are not compatible with such an image
586 compression, the JPEG 2000 image that is received by Orthanc might be 591 compression, the JPEG 2000 image that is received by Orthanc might not
587 unusable by such software. You might therefore have to **disable 592 be usable by such software. Check out the :ref:`FAQ about DICOM
588 transfer syntaxes** by setting the ``*TransferSyntaxAccepted`` options 593 transcoding <transcoding>` for more information about converting
589 to ``false`` in the :ref:`configuration file of Orthanc 594 between transfer syntaxes over the DICOM protocol.
590 <configuration>` (by default, all the transfer syntaxes are enabled).
591 595
592 596
593 .. _dicom-get: 597 .. _dicom-get:
594 598
595 C-Get: Retrieve with one single SCP 599 C-Get: Retrieve with one single SCP