What a transfer syntax is
A transfer syntax defines how a DICOM object is encoded: byte order, whether each element carries its Value Representation (explicit or implicit VR), and how the pixel data is compressed. Each one has a UID. When two systems connect, they negotiate which transfer syntaxes they both accept. A DICOM file records its own in Transfer Syntax UID (0002,0010).
This list covers the syntaxes in common clinical use. The DICOM standard (PS3.5 and PS3.6) defines more, including many retired JPEG processes not shown here.
Uncompressed
| UID | Name | Compression | Migration notes |
|---|---|---|---|
| 1.2.840.10008.1.2 | Implicit VR Little Endian | Uncompressed | The default transfer syntax. Every DICOM application must support it, so it is the safe fallback when two systems cannot agree on anything else. VRs are not stored in the data, so the receiver has to know them from its dictionary; private tags it does not know can end up typed as UN. |
| 1.2.840.10008.1.2.1 | Explicit VR Little Endian | Uncompressed | The most common uncompressed encoding in modern systems, and the encoding of every DICOM file's meta header. Preferred over Implicit VR because the VR travels with each element, which preserves private tags more reliably. |
| 1.2.840.10008.1.2.1.98 | Encapsulated Uncompressed Explicit VR Little Endian | Uncompressed | A newer syntax that stores uncompressed pixel data in fragments, like compressed data. Useful for very large multi-frame objects. Support in older PACS is limited; check conformance statements before relying on it. |
| 1.2.840.10008.1.2.1.99 | Deflated Explicit VR Little Endian | Lossless | Compresses the whole dataset with deflate (zip). Used mainly for non-image objects such as structured reports. Rarely supported for images. |
| 1.2.840.10008.1.2.2 | Explicit VR Big Endian | Uncompressed Retired | Retired from the standard, but still found in old archives. Convert to Explicit VR Little Endian during migration; many current systems will not accept it. |
JPEG
| UID | Name | Compression | Migration notes |
|---|---|---|---|
| 1.2.840.10008.1.2.4.50 | JPEG Baseline (Process 1) | Lossy | 8-bit lossy JPEG. Common for ultrasound, endoscopy, secondary captures and whole-slide images. Already lossy, so keep it as it is: re-encoding only adds loss. |
| 1.2.840.10008.1.2.4.51 | JPEG Extended (Process 2 and 4) | Lossy | Lossy JPEG with up to 12 bits per sample. Seen in some older CT and MR archives. Decoder support varies; test samples in the target viewer. |
| 1.2.840.10008.1.2.4.57 | JPEG Lossless, Non-Hierarchical (Process 14) | Lossless | Lossless JPEG with selectable predictor. Less common than the first-order prediction variant below. |
| 1.2.840.10008.1.2.4.70 | JPEG Lossless, Non-Hierarchical, First-Order Prediction (Process 14 [Selection Value 1]) | Lossless | The default lossless JPEG syntax and one of the most widely supported compressed syntaxes in PACS archives. A frequent choice for lossless storage of CT, MR and CR. |
JPEG-LS
| UID | Name | Compression | Migration notes |
|---|---|---|---|
| 1.2.840.10008.1.2.4.80 | JPEG-LS Lossless Image Compression | Lossless | Fast lossless compression with good ratios. Well supported by some archives and not at all by others; a common source of rejected transfers between vendors. |
| 1.2.840.10008.1.2.4.81 | JPEG-LS Lossy (Near-Lossless) Image Compression | Lossy | Near-lossless: each pixel stays within a set error bound. Still lossy for clinical and legal purposes. |
JPEG 2000
| UID | Name | Compression | Migration notes |
|---|---|---|---|
| 1.2.840.10008.1.2.4.90 | JPEG 2000 Image Compression (Lossless Only) | Lossless | Widely used for lossless archive storage. Decoding is CPU-heavy, which matters when transcoding large archives. |
| 1.2.840.10008.1.2.4.91 | JPEG 2000 Image Compression | Lossy or lossless | Allows lossy or lossless JPEG 2000; the UID alone does not tell you which. Check Lossy Image Compression (0028,2110) in each object. |
| 1.2.840.10008.1.2.4.92 | JPEG 2000 Part 2 Multi-component Image Compression (Lossless Only) | Lossless | Part 2 extensions for multi-component data. Rare in clinical archives. |
| 1.2.840.10008.1.2.4.93 | JPEG 2000 Part 2 Multi-component Image Compression | Lossy or lossless | Lossy or lossless Part 2. Rare in clinical archives. |
High-Throughput JPEG 2000 (HTJ2K)
| UID | Name | Compression | Migration notes |
|---|---|---|---|
| 1.2.840.10008.1.2.4.201 | High-Throughput JPEG 2000 Image Compression (Lossless Only) | Lossless | A recent addition to the standard: JPEG 2000 compression ratios with much faster encoding and decoding. Adoption is growing, especially in cloud services, but many installed PACS do not support it yet. |
| 1.2.840.10008.1.2.4.202 | High-Throughput JPEG 2000 with RPCL Options Image Compression (Lossless Only) | Lossless | Lossless HTJ2K with a progression order that supports progressive display at increasing resolution. |
| 1.2.840.10008.1.2.4.203 | High-Throughput JPEG 2000 Image Compression | Lossy or lossless | Lossy or lossless HTJ2K. As with .4.91, check Lossy Image Compression (0028,2110) per object. |
JPEG XL
| UID | Name | Compression | Migration notes |
|---|---|---|---|
| 1.2.840.10008.1.2.4.110 | JPEG XL Lossless | Lossless | One of the newest additions to the standard. Strong lossless compression, but very few PACS or viewers support it yet. Do not choose it as an archive format until both ends of every workflow can read it. |
| 1.2.840.10008.1.2.4.111 | JPEG XL JPEG Recompression | Lossy | Repackages existing JPEG Baseline data more compactly, and the original JPEG can be recovered exactly. The image itself is still the original lossy JPEG. Very limited support so far. |
| 1.2.840.10008.1.2.4.112 | JPEG XL | Lossy or lossless | Lossy or lossless JPEG XL. Check Lossy Image Compression (0028,2110) per object. Very limited support so far. |
Other
| UID | Name | Compression | Migration notes |
|---|---|---|---|
| 1.2.840.10008.1.2.5 | RLE Lossless | Lossless | Simple run-length compression. Low ratios on most medical images, but broadly supported. Seen with some ultrasound and secondary capture. |
Video
| UID | Name | Compression | Migration notes |
|---|---|---|---|
| 1.2.840.10008.1.2.4.100 | MPEG2 Main Profile / Main Level | Video (lossy) | Video for endoscopy, surgery and similar. Lossy. Many PACS store it but cannot display it. |
| 1.2.840.10008.1.2.4.102 | MPEG-4 AVC/H.264 High Profile / Level 4.1 | Video (lossy) | The most common DICOM video syntax. Lossy. Large files; plan throughput and storage separately from still images. |
| 1.2.840.10008.1.2.4.107 | HEVC/H.265 Main Profile / Level 5.1 | Video (lossy) | Higher-efficiency video. Lossy. Limited support in older archives. |
Transfer syntaxes in a migration
- Read both conformance statements. List which syntaxes the source holds and which the target accepts. Mismatches are among the most common causes of rejected objects.
- Transcode losslessly, or not at all. When the target doesn't accept the source's compression, decode and send uncompressed or in a lossless syntax the target accepts. Converting lossless data to lossy should be a written decision, never a default.
- Lossy stays lossy. Data that was stored lossy cannot be made lossless. Keep it in its original syntax where the target allows it, so it isn't degraded further.
- Plan for size changes. Decompressing for a target that only accepts uncompressed data can multiply storage and transfer time. Measure it on a sample before quoting a timeline.
- Check the result visually. Transcoding errors in color space or bit depth pass count checks but show up on screen. Include transcoded studies in the visual sample.