Transfer Syntax is the language used in DICOM to describe the DICOM file format and the network transfer methods. 3 main variables are contained in the Transfer Syntax:

VR: Implicit/Explicit
Endianism: Little-Endian/BigEndian
Pixel Data Compression

For DICOM Files, the Transfer Syntax is stored in the File Meta Header, and for networking it is negotiated between the SCU & SCP. For more information about how the negotiation happens and how to control the network transfer using Transfer Syntax can be found here.

Here is a summary of the most common DICOM Transfer syntaxes:

Uncompressed

Implicit VR Little-endian

Value : 1.2.840.10008.1.2
Description: This is the only mandatory DICOM transfer syntax, but as the VR is implicit (requiring all applications to have an up to date dictionary to make sense of the data) it is also the worst, and others should be used wherever possible. No other transfer syntaxes use implicit VR.

Explicit VR Little-endian

Value : 1.2.840.10008.1.2.1
Description : Explicit Value Representation must be included for each single DICOM tag. This transfer syntax is more often used since each data element has it’s own explicit value type declaration.

Explicit VR Big-endian

Value : 1.2.840.10008.1.2.2
Description : This is identical to Explicit VR little endian, apart from the fact that big-endian byte ordering is used. It is very little used nowadays, and no other transfer syntaxes use big-endian form.

NOTE: All the compressed syntaxes below use explicit VR little endian.

Lossless Compressed

Lossless methods are truly lossless, and the output is guaranteed to match the input exactly, and therefore there is no concept of quality…..the degree of compression depends only on the method used, and the nature of the image (noise compresses badly!)

JPEG Lossless

Values : 1.2.840.10008.1.2.4.57
Description : This is utterly unrelated to the “JPEG” methods listed above, despite the name! It is actually a very simple Pulse Code Modulation scheme, where each pixel is “Predicted” based on previous pixels, and then the much smaller “difference” is stored, after being compressed using Huffman coding.

JPEG Lossless First Order

Value : 1.2.840.10008.1.2.4.70
Description : Identical to the main JPEG lossless above, but with a constrained value for the predictor, giving a slightly simplified algorithm, with slightly greater speed, but slightly less compression on most images (2-5% typically)

RLE Lossless

Value : 1.2.840.10008.1.2.5
Description : The simplest form of compression technique which is widely supported by most bitmap file formats such as TIFF, BMP, and PCX. The content of the information greatly affects its efficiency in compressing the information, and whilst it is useful for images with large areas of zeros, it is almost useless for images such as radiographs where adjacent pixels rarely have exactly the same value.

JPEG 2000 (Lossless)

Value : 1.2.840.10008.1.2.4.90
Description : Like JPEG lossless, the use of the name JPEG is confusing, as it bears no resemblance to other “JPEG” compression methods. JPEG 2000 (J2K) is a wavelet based algorithm with the advantage over all the multitude of proprietary wavelets of being standardised and interoperable. In lossless mode (as required for this transfer syntax) the degree of compression is course determined by the image itself, but it typically performs about 10% better than JPEG lossless. It is however a much more complicated algorithm, giving significantly slower performance, and unless space or bandwidth are very constrained (e.g. as they may be for teleradiology), the speed penalty is unlikely to make this a popular choice.

JPEG-LS (Lossless)

Value : 1.2.840.10008.1.2.4.80
Description : Like JPEG lossless and 2000, the use of the name JPEG is confusing, as it bears little resemblance to other “JPEG” compression methods. JPEG-LS is totally different compression mechanism again! It is a much more “modern” algorithm, combing the best features of others, but it is supposedly much more efficient than JPEG 2000. Despite being included in the DICOM standard for over a decade, its actual real world use is almost non-existent in PACS.

Lossy Compressed

JPEG Baseline

Value : 1.2.840.10008.1.2.4.50
Description : This provides a DICOM wrapper around “standard” JPEG content, which is equivalent to external JPEG files (though of course still as full DICOM content, rather than than industry standard JFIF header). Note that it is always lossy, irrespective of the quality factor used - so even an image compressed with “100% quality” is still not identical to the original. It is limited to 8 bits per sample.

JPEG Extended

Value : 1.2.840.10008.1.2.4.51
Description : This is equivalent to JPEG baseline as above, but with extension to allow up to 12 bits per sample, allowing use with modalities which require “re-windowing” such as CT. Unlike baseline, this format is not used much (if at all) outside DICOM.

JPEG 2000 (lossy)

Value : 1.2.840.10008.1.2.4.91
Description : This is a variation on the JPEG 2000 lossless listed above, but permitting the image to be lossy (infact,m it is legal for it also to be lossless using this transfer syntax). In general, the same issues apply to this as to the lossless variation, but it does have a place in teleradiology etc. for two reasons:
- It can (with suitable software) be used incrementally, so that a rough image is shown initially, improving as more data is received
- For a given amount of data, the image is said to be better than using the best alternative lossy method (standard JPEG), but some people do have concerns about artifacts looking more “believable” (and therefore dangerous) than with JPEG, where they are easily noticeable as “blockiness”.

JPEG-LS (Lossy)

Value : 1.2.840.10008.1.2.4.81
Description : This is the same basic scheme as JPEG-LS as above, and has the same benefits and drawbacks (including very limited support in the real world), but it achieves greater compression by allowing a small (but defined) discrepancy between the original value and the value obtained after decompression.

MPEG Transfer Syntaxes

Unlike the other transfer syntaxes, the MPEG transfer syntaxes treat the video “as a whole” rather than as a series of individually compressed frames. Due to the DICOM fragment rules, they are limited to 4 GBytes in total, as only 1 single fragment is permitted.

MPEG-2

Values : 1.2.840.10008.1.2.4.100 & 1.2.840.10008.1.2.4.101
Description: The .100 syntax etc.uses the basic “Main Profile @ Main Level” (MP@ML) specification, but the .101 syntax allows the higher quality “Main Profile @ High Level” (MP@HL) MPEG rules - as defined in the MPEG 2 specification.

MPEG-4

Value : 1.2.840.10008.1.2.4.102 & 1.2.840.10008.1.2.4.103
Description : These use the “MPEG-4 AVC/H.264 High Profile / Level 4.1” specification - the difference between them being that the .103 syntax explicitly requires blueray (BD) compatibility.

Special Transfer Syntaxes

Deflate

Value : 1.2.840.10008.1.2.1.99
Description: Unlike all other DICOM transfer syntaxes, the deflate transfer syntaxes compress the whole of the DICOM data (tags, lengths, VR etc.) rather than just the pixel data - this is done using the standard “deflate” mechanism as used in gzip etc.) It is therefore most suitable for non-pixel objects such as structured reports, presentation states etc.

JPIP

Value : 1.2.840.10008.1.2.4.94
Description : This uses the “progressive” features of JPEG 2000, by leaving the pixel data out of the main object completely, replacing instead by a URL (in element 0028,7FE0) which points to a site from which the pixel data may be obtained using the JPIP protocol - this allows only the scaling and quality required to be fetched. It is only really suitable for PACS to workstation use and should never be used for writing images to removable media such as CDs!

JPIP-Deflate

Value : 1.2.840.10008.1.2.4.95
Description : This combines the features of JPIP (removing the pixel data) and then deflate - compressing the resulting reduced data. We have never seen it used in the real world!