The last three blog posts in this series I talked about network, addressing issues and incompatible filetypes. This post deals with incompatible Transfer Syntaxes (compression etc.) that could be proposed by a DICOM device initiating a DICOM connection.
In the last post I explained that a device proposes a list of items called a Presentation Context, which includes the file type (Abstract Syntax or SOP Class in DICOM terms) to be exchanged and the proposed encoding or Transfer Syntax of these files. These transfer syntaxes are a different representation of the data, the information content is still the same. Think about it as sending a file either in its original size, or, send it as a “zipped” file, in either case, the content is identical.
There are three parameters that can change in the Transfer Syntax:
1) The byte order,
2) Whether or not the data exchange includes the data type (or Value Representation) for each data element, and
3) Whether the data is compressed.
When a particular transfer syntax is not supported by the device it will typically give back and error with the text “Transfer Syntax” not supported or the more generic message “Presentation Context” not supported.
· Byte order issues – The byte order can be either Little Endian (LE), or Big Endian (BE), which defines whether the data is encoded for each word with its least significant byte first (LE) or most significant byte first (BE). As an analogy, some languages are written and read from right to left (Arabic, Hebrew), instead of left to right, it is a matter of knowing how to read the data (otherwise the data would be reversed). BE is usually associated with a UNIX based operating system using a Motorola CPU architecture, which means that you’ll see them only in relatively old images as most devices are now based on Intel/Windows architecture.
Almost all PACS systems will support both LE and BE because they need to support these old formats, you’ll rarely see a BE modality. However, due to its limited support, I strongly suggest that you configure a system to ONLY support LE to prevent compatibility issues. I have seen a systems that claim to support BE, but do not display them correctly. Note that LE is the default transfer syntax, meaning that every system is supposed to be supporting LE.
· Value Representation (VR) support issues – Each data element in the DICOM header can either specify for each individual element in its data type (Explicit VR) or leave it out (Implicit VR), which leaves it up to the software to support a data dictionary to determine its data type. Despite the fact that the Implicit VR is the default Transfer Syntax, I strongly suggest setting all of your devices to only send and/or accept the Explicit VR. The reason being that when archiving DICOM files on a CD, the Explicit VR is the required encoding, therefore you’ll reduce the chance that someone might just copy that file to a CD without doing the Implicit to Explicit VR conversion. In addition, many vendors include private data elements in the DICOM header and by requiring explicit VR, you will at least know the data type of those data elements, so you could potentially manage and interpret them.
· Compression issues – Compression support has become important as new image files and studies are starting to get very large (notably the mammo breast tomosynthesis) thus taxing the communication and storage infrastructure. There are many compression versions defined in the DICOM standard, last time I counted there were 35! In practice, most PACS systems might support only a handful, e.g. about 5-10. The JPEG for still images and MPEG for video are the most popular, and lately the JPEG2000 (Wavelet) compression is supported as well. If your PACS has not been upgraded lately, it might not support Wavelet, which will cause a rejection when a device wants to use the wavelet encoding for information exchange. This could be a problem as some of the senders might not be able to decompress the data upon request. Some devices support a proprietary compression which obviously only will be supported by devices from the same vendor. Note that compressed images are not allowed on the most popular CD format, which sometimes creates issues if this rule is not followed. When a lossy compression syntax is used (lossy means non-reversible instead of the lossless compression which is reversible), the creator of this file is required to change its Unique Identifier (UID), i.e. another copy if the image, which sometimes causes issues as some systems are confused about supporting two versions of the same object, i.e. the original and the lossy compressed. The creator of the lossy compressed image is also required to upgrade the header with a “compression flag” preventing the image from being lossy compressed again in the future as this will create major image artifacts.
Transfer syntax issues together with file type issues are the major causes that a connection cannot be established. The good news is that it should be a consistent error, i.e. unless there is a software upgrade, or the user selects another object and/or transfer syntax, it should keep on working when its initial installation is successful. Detection of these issues can be done by looking at the log files at the sender and/or destination, or, if there is limited access to those files, using a DICOM sniffer such as Wireshark. It is important to recognize if a connection fails due to the initial negotiation of the file type and transfer syntax, or if it is during the actual data exchange, which we are going to discuss in the next post.
Additional resources regarding this topic can be found in the DICOM textbook, and additional skills to troubleshoot these issues can be learned in our DICOM/PACS training classes, either on-line or face-to-face.