Digital Imaging and Communications in Medicine (DICOM) Supplement 61: JPEG 2000 Transfer Syntaxes

1 2 3 5 Digital Imaging and Communications in Medicine (DICOM) 6 7 Supplement 61: JPEG 2000 Transfer Syntaxes 8 9 10 11 12 13 1 15 16 17 18 19 20 DICOM Standards Committee, Working Group Compression 1300 N. 17 th Street Rosslyn, Virginia 22209 USA 21 22 23 VERSION: Draft for WG 6 approval for Public Comment, version 0.05, 19 April 2001

Page 2 2 Contents 25 26 27 28 29 30 31 32 33 3 35 36 37 38 39 0 1 2 3 5 6 7 8 9 50 51 52 53 5 55 56 57 Contents...2 Open Issues for Public Comment...3 Foreword... Scope and Field of Application...5 INTRODUCTION...5 DESIGN DECISIONS...5 FORM OF THIS SUPPLEMENT...6 Section 2 Normative references...17 Section 8 Encoding of Pixel, Overlay and Waveform Data...17 8.2 NATIVE OR ENCAPSULATED FORMAT ENCODING...17 8.2.1...JPEG IMAGE COMPRESSION...18 8.2.2...Run Length Encoding Compression...19 8.2.3...JPEG-LS IMAGE COMPRESSION...20 8.2...JPEG 2000 IMAGE COMPRESSION...20 Section 10 Transfer Syntax...21 10.1 DICOM DEFAULT TRANSFER SYNTAX...22 10.2 TRANSFER SYNTAX FOR A DICOM DEFAULT OF LOSSLESS JPEG COMPRESSION 22 10.3 TRANSFER SYNTAXES FOR A DICOM DEFAULTS OF LOSSY JPEG COMPRESSION 22 10. TRANSFER SYNTAX FOR DICOM RLE COMPRESSION...23 10.5 TRANSFER SYNTAX FOR A DICOM DEFAULT OF LOSSLESS AND LOSSY (NEAR- LOSSLESS) JPEG-LS COMPRESSION...23 10.6 TRANSFER SYNTAX FOR A DICOM DEFAULT FOR JPEG 2000 COMPRESSION...23 Annex A (Normative) Transfer Syntax Specifications...2 A. TRANSFER SYNTAXES FOR ENCAPSULATION OF ENCODED PIXEL DATA...2 A..1 JPEG IMAGE COMPRESSION...28 A..2 RLE COMPRESSION...29 A..3 JPEG-LS IMAGE COMPRESSION...29 A.. JPEG 2000 IMAGE COMPRESSION...30 Annex F (Informative) Encapsulated images as part of a DICOM message...31 F.1 ENCAPSULATED JPEG ENCODED IMAGES...31 F.2 ENCAPSULATED JPEG-LS ENCODED IMAGES...35 F.3 ENCAPSULATED JPEG 2000 ENCODED IMAGES...36 Annex A Registry of DICOM unique identifiers (UID) (Normative)...38

Page 3 58 59 Open Issues for Public Comment 60 61 For the two transfer syntaxes, the first should be lossless (reversible), but should the second be: just lossy (irreversible) either (SCU decides, SCP doesn t care), i.e. lossless or lossy noting that all codecs must support both to be JPEG 2000 compliant? Should there be an ability to teminate a C-STORE in progress when sufficient information has been received (at the user s discretion), since JPEG 2000 can transmit progressively? This would be an extremely non-trivial change to that layer of the standard. Are the features from JPEG 2000 Part 1 sufficient to justify inclusion in the standard as transfer syntaxes now, or is there any reason to wait for Part 2 features (like 3D), given that consumer codecs will likely only ever support Part 1? Is it appropriate to retire the many unused JPEG (10918-1) transfer syntaxes, leaving only those that are known to have been implemented? Is the list to keep and retire correct? Which, if any, media application profiles should be added in this supplement (or should this be left to future application specific supplements)?

Page 62 63 Foreword 6 65 66 67 68 69 70 71 72 73 7 75 76 77 78 79 80 81 82 83 8 85 86 87 88 This Supplement has been prepared by the DICOM Working Group (Compression) according to the procedures of the DICOM Committee. The DICOM Standard is structured as a multi-part document using the guidelines established in the following document: - ISO/IEC Directives, 1989 Part 3: Drafting and Presentation of International Standards. This document is a Supplement to the DICOM Standard. It is an extension to PS 3.3, 3. and 3.6 of the published DICOM Standard, which consists of the following parts: PS 3.1 - Introduction and Overview PS 3.2 - Conformance PS 3.3 - Information Object Definitions PS 3. - Service Class Specifications PS 3.5 - Data Structures and Encoding PS 3.6 - Data Dictionary PS 3.7 - Message Exchange PS 3.8 - Network Communication Support for Message Exchange PS 3.9 - Point-to-Point Communication Support for Message Exchange PS 3.10 - Media Storage and File Format for Data Interchange PS 3.11 - Media Storage Application Profiles PS 3.12 - Media Formats and Physical Media for Data Interchange PS 3.13 - Print Management Point-to-Point Communication Support PS 3.1 - Grayscale Standard Display Function PS 3.15 - Security Profiles PS 3.16 - Content Mapping Resource These parts are related but independent documents.

Page 5 89 Scope and Field of Application 90 91 92 93 9 95 96 97 98 99 100 101 102 103 10 105 106 107 108 109 110 111 112 113 11 115 116 117 118 119 120 121 122 123 12 125 126 127 128 129 130 131 132 133 INTRODUCTION. Additional DICOM Transfer Syntaxes are introduced to add support for the JPEG 2000 Part 1 lossless and lossy compression schemes. When first introduced, DICOM contained support for the lossless and lossy compression processes defined in the original JPEG standard, ISO 10918-1. Though that standard supported various different processes, in practice only those based on sequential block-based Huffman entropy coding for lossy compression and predictive coding with Huffman entropy coding for lossless compression have been widely used. Given that there are both real and perceived limitations with 10918-1 JPEG, WG began to investigate alternatives, particularly those based on wavelet transformation, multi-resolution analysis and more sophisticated entropy coders than Huffman coding. Working Group set aside its effort to develop its own (medically specific) image date compression standard when the call for proposals for JPEG 2000 was announced by ISO/IEC JTC1/SC29/WG1. Since then, efforts have been directed towards developing JPEG 2000 (ISO 15-1), and ensuring that it provides features which are needed for medical imaging. The use of ISO/IEC 15-1 does not necessarily result in improved compression performance for any particular application (in terms of quantitative or qualitative measures of image fidelity, preservation of diagnostically significant information, consumption of resources such as memory or compression and decompression speed). However, JPEG 2000 offers additional features that may be important for some medical applications in which DICOM is used. These features include progressive and embedded spatial and contrast resolution, progression to lossless reconstruction, regions of interest and so on. At the present time, only the features included in Part 1 of JPEG 2000 (ISO/IEC 15-1) are included in this proposal. All JPEG 2000 implementations are required to support all features of Part 1 and accordingly this is expected to be a baseline for all available codecs. Other proposed parts of JPEG 2000 included additional features that may be of interest for medical imaging, such as alternative quantization methods (such as TCQ) and wavelet transforms in more than two dimensions (potentially useful for hyper-spectral and 3D volume data compression). If these extensions to JPEG 2000 prove viable and receive widespread support by codec implementers then they could be added as additional separate Transfer Syntaxes in DICOM. The introduction of the JPEG 2000 transfer syntaxes is in no way intended to imply that the compression schemes already incorporated in the standard, some of which are widely used, are in some way inferior. Likewise, the introduction of JPEG 2000 does not imply endorsement of the scheme for any particular clinical or diagnostic application. The standard simply makes the scheme available; it is the responsibility of individual users, vendors, regulatory agencies and professional societies to ascertain the safety and efficacy of the use of any tool for a particular clinical application. At the same time as introducing new Transfer Syntaxes, the opportunity is taken to retire those existing Transfer Syntaxes that are not in use. Also, the unused and deprecated ARGB Photometric Interpretation is also retired. DESIGN DECISIONS The approach proposed is to encapsulate JPEG 2000 bit streams in exactly the same manner as is currently used for JPEG (10918-1), JPEG-LS and RLE. This implies that: Undefined length pixel data contains one or more sequence-item-like fragments preceded by a possibly empty offset table.

Page 6 13 135 136 137 138 139 10 11 12 13 1 15 16 17 18 19 150 151 152 153 Each frame (or an entire single frame image) will be in one or more fragments. The optional JP2 file format header defined in 15-1 is not included, only the actual compressed JPEG bit stream (this is the same as for JPEG which does not include a JFIF header in the DICOM encapsulation and JPEG-LS which does not include a SPIFF header). Information that is not specified in the JPEG 2000 bit stream, such as what color component corresponds to each compressed component, is specified in the DICOM attributes, such as Photometric Interpretation (again, just like JPEG, JPEG-LS and RLE). Separate transfer syntaxes are defined for reversible and irreversible processes, in order to be able to negotiate reversible transfers. FORM OF THIS SUPPLEMENT This supplement adds new Transfer Syntaxes to support JPEG 2000, adds new Photometric Interpretations compatible with those used in JPEG 2000 encoded bit streams, and retires unused JPEG Transfer Syntaxes. Since this document proposes changes to existing Parts of DICOM, the reader should have a working understanding of the Standard. This proposed Supplement includes a number of Addenda to existing Parts of DICOM: - PS 3.3 Addendum: Information Object Definitions - PS 3.5 Addendum: Data Structures and Encoding - PS 3.6 Addendum: Data Dictionary - PS 3.11 Addendum: Media Application Profiles 15

Page 7 155 156 157 158 159 160 161 162 163 16 Changes to NEMA Standards Publication PS 3.3-2000 165 166 167 Digital Imaging and Communications in Medicine (DICOM) Part 3: Information Object Definitions

Page 8 168 169 170 171 172 173 17 175 176 177 178 179 180 181 182 183 18 185 186 187 188 189 190 191 192 193 19 195 196 197 198 199 200 201 202 203 20 205 206 207 208 209 210 211 Add JPEG 2000 Photometric Interpretations to Image Pixel Module C.7.6.3: (changes in bold, additions underscored, deletions struckthrough) C.7.6.3Image Pixel Module Table C.7-9 specified the Attributes that describe the pixel data of the image.... C.7.6.3.1 Image Pixel Attribute Descriptions C.7.6.3.1.1 Samples Per Pixel Samples per Pixel (0028,0002) is the number of separate planes in this image. One, three, and four image planes are defined. Other numbers of image planes are allowed, but their meaning is not defined by this Standard. For monochrome (gray scale) and palette color images, the number of planes is 1. For RGB and other three vector color models, the value of this attribute is 3. For ARGB and other four vector color models, the value of this attribute is. All image planes shall have the same number of Rows (0028,0010), Columns (0028,0011), Bits Allocated (0028,0100), Bits Stored (0028,0101), High Bit (0028,0102), Pixel Representation (0028,0103), and Pixel Aspect Ratio (0028,003). The data in each pixel may be represented as a Composite Pixel Code. If Samples Per Pixel is one, the Composite Pixel Code is just the n bit pixel sample, where n = Bits Allocated. If Samples Per Pixel is greater than one, Composite Pixel Code is a k bit concatenation of samples, where k = Bits Allocated multiplied by Samples Per Pixel, and with the sample representing the vector color designated first in the Photometric Interpretation name comprising the most significant bits of the Composite Pixel Code, followed in order by the samples representing the next vector colors, with the sample representing the vector color designated last in the Photometric Interpretation name comprising the least significant bits of the Composite Pixel Code. For example, for Photometric Interpretation = RGB, the most significant Bits Allocated bits contain the Red sample, the next Bits Allocated bits contain the Green sample, and the least significant Bits Allocated bits contain the Blue sample. C.7.6.3.1.2 Photometric Interpretation The value of Photometric Interpretation (0028,000) specifies the intended interpretation of the image pixel data. See PS 3.5 for restrictions imposed by compressed Transfer Syntaxes. The following values are defined. Other values are permitted but the meaning is not defined by this Standard. MONOCHROME1 = Pixel data represent a single monochrome image plane. The minimum sample value is intended to be displayed as white after any VOI gray scale transformations have been performed. See PS 3.. This value may be used only when Samples per Pixel (0028,0002) has a value of 1. MONOCHROME2 = Pixel data represent a single monochrome image plane. The minimum sample value is intended to be displayed as black after any VOI gray scale transformations have been performed. See PS 3.. This value may be used only when Samples per Pixel (0028,0002) has a value of 1. PALETTE COLOR = Pixel data describe a color image with a single sample per pixel (single image plane). The pixel value is used as an index into each of the Red, Blue, and Green Palette Color Lookup Tables (0028,1101-1103&1201-1203). This value may be used only when Samples per Pixel

Page 9 212 213 21 215 216 217 218 219 220 221 222 223 22 225 226 227 228 229 230 231 232 233 23 235 236 237 238 239 20 21 22 23 2 25 26 27 28 29 250 251 252 (0028,0002) has a value of 1. When the Photometric Interpretation is Palette Color; Red, Blue, and Green Palette Color Lookup Tables shall be present. RGB = Pixel data represent a color image described by red, green, and blue image planes. The minimum sample value for each color plane represents minimum intensity of the color. This value may be used only when Samples per Pixel (0028,0002) has a value of 3. HSV = Pixel data represent a color image described by hue, saturation, and value image planes. The minimum sample value for each HSV plane represents a minimum value of each vector. This value may be used only when Samples per Pixel (0028,0002) has a value of 3. ARGB = Pixel data represent a color image described by red, green, blue, and alpha image planes. The minimum sample value for each RGB plane represents minimum intensity of the color. The alpha plane is passed through Palette Color Lookup Tables. If the alpha pixel value is greater than 0, the red, green, and blue lookup table values override the red, green, and blue, pixel plane colors. This value may be used only when Samples per Pixel (0028,0002) has a value of. Retired. CMYK = Pixel data represent a color image described by cyan, magenta, yellow, and black image planes. The minimum sample value for each CMYK plane represents a minimum intensity of the color. This value may be used only when Samples per Pixel (0028,0002) has a value of. YBR_FULL = Pixel data represent a color image described by one luminance (Y) and two chrominance planes (C B and C R ). This photometric interpretation may be used only when Ssamples per Ppixel (0028,0002) has a value of 3. Black is represented by Y equal to zero. The absence of color is represented by both C B and C R values equal to half full scale. Note: In the case where the Bits Allocated (0028,0100) has value of 8 half full scale is 128. In the case where Bits allocated (0028,0100) has a value of 8 then the following equations convert between RGB and YC B C R Photometric Interpretation. Y = +.2990R +.5870G +.110B C B = -.1687R -.3313G +.5000B+ 128 C R = +.5000R -.187G -.0813B+ 128 Note: The above is based on CCIR Recommendation 601-2 dated 1990 YBR_FULL_22 = The same as YBR_FULL except that the C B and C R values are sampled horizontally at half the Y rate and as a result there are half as many C B and C R values as Y values. This Pphotometric Interpretation is only allowed with Planar Configuration (0028,0006) equal to 0000. Two Y values shall be stored followed by one C B and one C R value. The C B and C R values shall be sampled at the location of the first of the two Y values. For each Row of Pixels, the first C B and C R samples shall be at the location of the first Y sample. The next C B and C R samples shall be at the location of the third Y sample etc. Note: This subsampling is often referred to as cosited sampling. YBR_PARTIAL_22 = The same as YBR_FULL_22 except that: 1. black corresponds to Y = 16;

Page 10 253 25 255 256 257 258 259 260 261 262 263 26 2. Y is restricted to 220 levels (i.e. the maximum value is 235); 3. C B and C R each has a minimum value of 16;. C B and C R are restricted to 225 levels (i.e. the maximum value is 20); 5. lack of color is represented by C B and C R equal to 128. In the case where Bits Allocated (0028,0100) has value of 8 then the following equations convert between RGB and YBR_PARTIAL_22 Photometric Interpretation Y = +.2568R +.501G +.0979B+ 16 C B = -.182R -.2910G +.392B+ 128 C R = +.392R -.3678G -.071B+ 128 Note: The above is based on CCIR Recommendation 601-2 dated 1990. YBR_ICT = Irreversible Color Transformation: 266 265 Pixel data represent a color image described by one luminance (Y) and two chrominance planes (C B and C R ). This photometric interpretation may be used only when Samples per Pixel 267 (0028,0002) has a value of 3. Black is represented by Y equal to zero. The absence of color is 268 represented by both C B and C R values equal to zero. 269 270 271 272 273 27 275 276 277 278 279 280 281 282 283 28 285 286 287 288 Regardless of the value of Bits Allocated (0028,0100), the following equations convert between RGB and YC B C R Photometric Interpretation. Y = +.29900R +.58700G +.1100B C B = -.16875R-.33126G +.50000B C R = +.50000R-.1869G -. 08131B Notes: 1. The above is based on ISO/IEC 15-1 (JPEG 2000). 2. In a JPEG 2000 bitstream, DC level shifting (used if the untransformed components are unsigned) is applied before forward color transformation, and the transformed components may be signed (unlike in JPEG ISO/IEC 10918-1). 3. In JPEG 2000, spatial down-sampling of the chrominance components, if performed, is signalled in the JPEG 2000 bitstream. YBR_RCT = Reversible Color Transformation: Pixel data represent a color image described by one luminance (Y) and two chrominance planes (V and U). This photometric interpretation may be used only when Samples per Pixel (0028,0002) has a value of 3. Black is represented by Y equal to zero. The absence of color is represented by both C B and C R values equal to zero. Regardless of the value of Bits Allocated (0028,0100), the following equations convert between RGB and YBR_RCT Photometric Interpretation. Y = ( R + 2G +B) /

Page 11 289 290 291 292 293 29 295 296 297 298 299 300 301 302 303 30 305 306 307 308 309 310 311 312 313 31 315 316 317 318 319 320 321 322 323 32 C B = B - G C R = R - G The following equations convert between YBR_RCT and RGB Photometric Interpretation. G = Y (C R + C B ) / R = C R + G B = C B + G Notes: 1. The above is based on ISO/IEC 15-1 (JPEG 2000). 2. In a JPEG 2000 bitstream, DC level shifting (used if the untransformed components are unsigned) is applied before forward color transformation, and the transformed components may be signed (unlike in JPEG ISO/IEC 10918-1). 3. This photometric interpretation is a rev ersible approximation to the YUV transformation used in PAL and SECAM. C.7.6.3.1.3 Planar Configuration Planar Configuration (0028,0006) indicates whether the color pixel data are sent color-by-plane or color-by-pixel. This Attribute shall be present if Samples per Pixel (0028,0002) has a value greater than 1. It shall not be present otherwise. Enumerated Values: 000 = The sample values for the first pixel are followed by the sample values for the second pixel, etc. For RGB images, this means the order of the pixel values sent shall be R1, G1, B1, R2, G2, B2,..., etc. For HSV images, this means the order of the pixel values sent shall be H1, S1, V1, H2, S2, V2,... etc. For ARGB images, this means the order of the pixel values sent shall be A1, R1, G1, B1, A2, R2, G2, B2,... etc. For CMYK images, this means the order of the pixel values sent shall be C1, M1, Y1, K1, C2, M2, Y2, K2,... etc. 001 = Each color plane shall be sent contiguously. For RGB images, this means the order of the pixel values sent is R1, R2, R3,..., G1, G2, G3,..., B1, B2, B3, etc. For HSV images, this means the order of the pixel values sent is H1, H2, H3,..., S1, S2, S3,..., V1, V2, V3, etc. For ARGB images, this means the order of the pixel values sent is A1, A2, A3,..., R1, R2, R3,..., G1, G2, G3,... B1, B2, B3... etc. For CMYK images, this means the order of the pixel values sent is C1, C2, C3,..., M1, M2, M3,..., Y1, Y2, Y3,..., K1, K2, K3... etc. Note: Planar Configuration (0028,0006) is not meaningful when a compression transfer syntax is used that involves reorganization of sample components in the compressed bit stream. In such cases, since the Attribute is required to be sent, then an appropriate value to use may be specified in the description of the Transfer Syntax in PS 3.5, though in all likelihood the value of the Attribute will be ignored by the receiving implementation. 325 326 Add JPEG 2000 Photometric Interpretations to US Image Module C.8.5.6:

Page 12 327 328 329 330 331 332 333 33 335 336 337 338 339 30 31 32 C.8.5.6 US Image Module... C.8.5.6.1.2 Photometric Interpretation For US Images, Photometric Interpretation (0028,000) is specified to use the following Defined Terms: MONOCHROME2 PALETTE COLOR RGB ARGB (retired) YBR_FULL YBR_FULL_22 YBR_PARTIAL_22 YBR_RCT YBR_ICT Note: It is recommended that future implementations should not use ARGB photometric interpretation. See PS 3.5 for restrictions imposed by compressed Transfer Syntaxes.... C.8.5.6.1.12 Samples Per Pixel For US Images, Samples Per Pixel (0028,0002) is specified to use the following values for specific Photometric Interpretations: Table C.8-19 US SAMPLES PER PIXEL Photometric Interpretation Samples Per Pixel Value MONOCHROME2 0001H RGB 0003H YBR_FULL 0003H YBR_FULL_22 0003H YBR_PARTIAL_22 0003H YBR_RCT 3 YBR_ICT 3 PALETTE COLOR 0001H

Page 13 33 3 35 36 37 C.8.5.6.1.13 Bits Allocated For US Images, Bits Allocated (0028,0100) is specified to use the following values for specific Photometric Interpretations: Table C.8-20 US BITS ALLOCATED Photometric Interpretation Bits Allocated Value MONOCHROME2 0008H RGB 0008H YBR_FULL 0008H YBR_FULL_22 0008H YBR_PARTIAL_22 0008H YBR_RCT 8 YBR_ICT 8 PALETTE COLOR 0008H - 8 bit palette, or 0010H 16-16 bit palette 38 39 350 351 352 353 C.8.5.6.1.1 Bits Stored For US Images, Bits Stored (0028,0101) is specified to use the following values for specific Photometric Interpretations: Table C.8-21 US BITS STORED Photometric Interpretation Bits Stored Value MONOCHROME2 0008H RGB 0008H YBR_FULL 0008H YBR_FULL_22 0008H YBR_PARTIAL_22 0008H YBR_RCT 8 YBR_ICT 8 PALETTE COLOR 0008H - 8 bit palette, or 0010H 16-16 bit palette 35 355 356 357 C.8.5.6.1.15 High Bit For US Images, High Bit (0028,0102) is specified to use the following values for specific Photometric Interpretations:

Page 1 358 359 Table C.8-22 US HIGH BIT Photometric Interpretation High Bit Value MONOCHROME2 0007H RGB 0007H YBR_FULL 0007H YBR_FULL_22 0007H YBR_PARTIAL_22 0007H YBR_RCT 7 YBR_ICT 7 PALETTE COLOR 0007H - 8 bit palette, or 000FH 15-16 bit palette 360 361 362 363 36 365 C.8.5.6.1.16 Planar Configuration For US Images, Planar Configuration (0028,0006) is specified to use the following values for specific Photometric Interpretations: Table C.8-23 US PLANAR CONFIGURATION Photometric Interpretation Planar Configuration Value RGB 0000H - color-by-pixel, or 0001H - color-by-plane YBR_FULL 0001H YBR_FULL_22 0000H YBR_PARTIAL_22 0000H YBR_RCT 0 YBR_ICT 0 366 367 368 Add JPEG 2000 Photometric Interpretations to VL Image Module C.8.12.1: 369 370 C.8.12.1... VL Image Module 371 372 373 37 375 376 377 C.8.12.1.1 VL Image Module Attribute Descriptions C.8.12.1.1.1 Photometric Interpretation The Enumerated Values of Photometric Interpretation (0028,000) shall: MONOCHROME2 RGB YBR_FULL_22 YBR_RCT

Page 15 378 379 380 381 382 383 38 385 386 387 388 389 390 391 392 393 39 395 YBR_ICT C.8.12.1.1.2 Bits Allocated, Bits Stored, and High Bit The Enumerated Value of Bits Allocated (0028,0100) shall be 8; the Enumerated Value of Bits Stored (0028,0101) shall be 8; and the Enumerated Value of High Bit (0028,0102) shall be 7. C.8.12.1.1.3 Pixel Representation The Enumerated Value of Pixel Representation (0028,0103) shall be 0000H. Note: A value of 0000H signifies an unsigned integer value. C.8.12.1.1. Samples per Pixel The Enumerated Values of Samples per Pixel (0028,0002) shall be as follows: If the value of Photometric Interpretation (0028,000) is MONOCHROME2, then the Enumerated Value of Samples per Pixel (0028,0002) shall be one (1). If the value of Photometric Interpretation (0028,000) is RGB or YBR_FULL_22 or YBR_RCT or YBR_ICT, then the Enumerated Value of Samples per Pixel (0028,0002) shall be three (3). C.8.12.1.1.5 Planar Configuration If present, the Enumerated Value of Planar Configuration (0028,0006) shall be 0000H. This value shall be present if Samples per Pixel (0028,0002) has a value greater than 1.

Page 16 396 397 398 399 00 01 02 03 0 05 Changes to NEMA Standards Publication PS 3.5-2000 06 07 08 Digital Imaging and Communications in Medicine (DICOM) Part 5: Data Structures and Encoding

Page 17 09 Add JPEG 2000 to Section 2: 10 Section 2 Normative references 11 12 13 1 15 The following standards contain provisions that, through references in this text, constitute provisions of this standard. At the time of publication, the editions indicated were valid. All standards are subject to revision, and parties to agreements based on this standard are encouraged to investigate the possibilities of applying the most recent editions of the standards indicated below. 16 17 18 19 20 21 22 23 ISO/IS 10918-1 ISO/IS 10918-2 ISO/IS 195-1 ISO/IS 15-1 JPEG Standard for digital compression and encoding of continuous-tone still images. Part 1 Requirements and implementation guidelines JPEG Standard for digital compression and encoding of continuous-tone still images. Part 2 Testing Lossless and near-lossless coding of continuous tone still images (JPEG- LS) JPEG 2000 Image Coding System 2 25 Add JPEG 2000 to Section 8: 26 27 Section 8 Encoding of Pixel, Overlay and Waveform Data 28 29 30 31 32 33 3 35 36 37... 8.2 NATIVE OR ENCAPSULATED FORMAT ENCODING Pixel data conveyed in the Pixel Data Element (7FE0,0010) may be sent either in a Native (uncompressed) Format or in an Encapsulated Format (e.g. compressed) defined outside the DICOM standard. If Pixel Data is sent in a Native Format, the Value Representation OW is most often required. The Value Representation OB may also be used for Pixel Data in cases where Bits Allocated has a value less than or equal to 8, but only with Transfer Syntaxes where the Value Representation is explicitly conveyed (see Annex A). 38 39 0 Note: The DICOM default Transfer Syntax (Implicit VR Little Endian) does not explicitly convey Value Representation and therefore the VR of OB may not be used for Pixel Data when using the default Transfer Syntax.

Page 18 1 2 3 5 6 7 8 9 50 51 52 53 5 55 56 57 58 59 60 61 62 63 6 65 66 67 68 69 70 71 72 73 7 75 76 77 78 79 80 81 82 83 8 85 86 87 88 89 90 91 Native format Pixel Cells are encoded as the direct concatenation of the bits of each Pixel Cell, where the most significant bit of a Pixel Cell is immediately followed by the least significant bit of the next Pixel Cell. The number of bits of each Pixel Cell is defined by the Bits Allocated (0028,0100) Data Element Value. When a Pixel Cell crosses a word boundary in the OW case, or a byte boundary in the OB case, it shall continue to be encoded, least significant bit to most significant bit, in the next word, or byte, respectively (see Annex D). For Pixel Data encoded with the Value Representation OW, the byte ordering of the resulting 2-byte words is defined by the Little Endian or Big Endian Transfer Syntaxes negotiated at the Association Establishment (see Annex A). Notes: 1. For Pixel Data encoded with the Value Representation OB, the Pixel Data encoding is unaffected by Little Endian or Big Endian byte ordering. 2. If encoding Pixel Data with a Value for Bits Allocated (0028,0100) not equal to 16 be sure to read and understand Annex D. If sent in an Encapsulated Format (i.e. other than the Native Format) the Value Representation OB is used. The Pixel Cells are encoded according to the encoding process defined by one of the negotiated Transfer Syntaxes (see Annex A). The encapsulated pixel stream of encoded pixel data is segmented in one or more Fragments which convey their explicit length. The sequence of Fragments of the encapsulated pixel stream is terminated by a delimiter, thus allowing the support of encoding processes where the resulting length of the entire pixel stream is not known until it is entirely encoded. This Encapsulated Format supports both Single-Frame and Multi-Frame images (as defined in PS 3.3). 8.2.1 JPEG IMAGE COMPRESSION DICOM provides a mechanism for supporting the use of JPEG Image Compression through the Encapsulated Format (see PS 3.3). Annex A defines a number of Transfer Syntaxes which reference the JPEG Standard and provide a number of lossless (bit preserving) and lossy compression schemes. Note: The context where the usage of lossy compression of medical images is clinically acceptable is beyond the scope of the DICOM Standard. The policies associated with the selection of appropriate compression parameters (e.g. compression ratio) for JPEG lossy compression is also beyond the scope of this standard. In order to facilitate interoperability of implementations conforming to the DICOM Standard which elect to use one or more of the Transfer Syntaxes for JPEG Image Compression, the following policy is specified: Any implementation which conforms to the DICOM Standard and has elected to support any one of the Transfer Syntaxes for lossless JPEG Image Compression, shall support the following lossless compression: The subset (first-order horizontal prediction [Selection Value 1) of JPEG Process 1 (DPCM, non-hierarchical with Huffman coding) (see Annex F). Any implementation which conforms to the DICOM Standard and has elected to support any one of the Transfer Syntaxes for 8-bit lossy JPEG Image Compression, shall support the JPEG Baseline Compression (coding Process 1). Any implementation which conforms to the DICOM Standard and has elected to support any one of the Transfer Syntaxes for 12-bit lossy JPEG Image Compression, shall support the JPEG Compression Process. Note: The DICOM conformance statement shall differentiate whether or not the implementation is capable of simply receiving or receiving and processing JPEG encoded images (see PS 3.2). The use of the DICOM Encapsulated Format to support JPEG Compressed Pixel Data requires that the Data Elements which are related to the Pixel Data encoding (e.g. Photometric Interpretation,

Page 19 92 93 9 95 96 97 98 99 500 501 502 503 50 505 506 507 508 509 510 511 512 513 51 515 516 517 518 519 520 521 522 523 52 525 526 527 528 529 530 531 532 533 53 535 536 Samples per Pixel, Planar Configuration, Bits Allocated, Bits Stored, High Bit, Pixel Representation, Rows, Columns, etc.) shall contain values which are consistent with the characteristics of the compressed data stream. The Pixel Data characteristics included in the JPEG Interchange Format shall be used to decode the compressed data stream. Notes: 1. These requirements were formerly specified in terms of the "uncompressed pixel data from which the compressed data stream was derived". However, since the form of the "original" uncompressed data stream could vary between different implementations, this requirement is now specified in terms of consistency with what is encapsulated. When decompressing, should the characteristics explicitly specified in the compressed data stream (e.g. spatial subsampling or number of components or planar configuration) be inconsistent with those specified in the DICOM Data Elements, those explicitly specified in the compressed data stream should be used to control the decompression. The DICOM data elements, if inconsistent, can be regarded as suggestions as to the form in which an uncompressed data set might be encoded. 2. Those characteristics not explicitly specified in the compressed data stream (e.g. color space which is not specified in the JPEG Interchange Format), or implied by the definition of the compression scheme (e.g. always unsigned in JPEG), can therefore be determined from the DICOM Data Element in the enclosing data set. For example a Photometric Intepretation of "YBR FULL 22" would describe the color space that is commonly used to lossy compress images using JPEG. It is unusual to use an RGB color space for lossy compression, since no advantage is taken of correlation between the red, green and blue components (e.g. of luminance), and poor compression is achieved. 3. Should the compression process be incapable of encoding a particular form of pixel data representation (e.g. JPEG cannot encode signed integers, only unsigned integers), then ideally only the appropriate form should be "fed" into the compression process. However, for certain characteristics described in DICOM Data Elements but not explicitly described in the compressed data stream (such as Pixel Representation), then the DICOM Data Element should be considered to describe what has been compressed (e.g. the pixel data really is to be interpreted as signed if Pixel Representation so specifies).. DICOM Data Elements should not describe characteristics that are beyond the capability of the compression scheme used. For example, JPEG lossy processes are limited to 12 bits, hence the value of Bits Stored should be 12 or less. Bits Allocated is irrelevant, and is likely to be constrained by the Information Object Definition in PS 3.3 to values of 8 or 16. Also, JPEG compressed data streams are always color-by-pixel and should be specified as such (a decoder can essentially ignore this element however as the value for JPEG compressed data is already known). 8.2.2 Run Length Encoding Compression DICOM provides a mechanism for supporting the use of Run Length Encoding (RLE) Compression which is a byte oriented lossless compression scheme through the encapsulated Format (see PS 3.3 of this Standard). Annex G defines RLE Compression and its Transfer Syntax. Note: The RLE Compression algorithm described in Annex G is the compression used in the TIFF 6.0 specification known as the PackBits scheme. The use of the DICOM Encapsulated Format to support RLE Compressed Pixel Data requires that the Data Elements which are related to the Pixel Data encoding (e.g. Photometric Interpretation, Samples per Pixel, Planar Configuration, Bits Allocated, Bits Stored, High Bit, Pixel Representation, Rows, Columns, etc.) shall contain values which are consistent with the compressed data. 537 538 539 50 51 52 53 5 55 56 57 58 Notes: 1. These requirements were formerly specified in terms of the "uncompressed pixel data from which the compressed data was derived". However, since the form of the "original" uncompressed data stream could vary between different implementations, this requirement is now specified in terms of consistency with what is encapsulated. 2. Those characteristics not implied by the definition of the compression scheme (e.g. always colorby-plane in RLE), can therefore be determined from the DICOM Data Element in the enclosing data set. For example a Photometric Intepretation of "YBR FULL" would describe the color space that is commonly used to losslessly compress images using RLE. It is unusual to use an RGB color space for RLE compression, since no advantage is taken of correlation between the red, green and blue components (e.g. of luminance), and poor compression is achieved (note however that the conversion from RGB to YBR FULL is itself lossy. A new photometric interpretation may be proposed in the future which allows lossless conversion from RGB and also results in better RLE compression ratios).

Page 20 59 550 551 552 553 55 555 556 557 558 559 560 561 562 563 56 565 566 567 568 569 570 571 572 573 57 575 576 577 578 579 580 581 582 583 58 585 586 587 588 589 590 591 592 593 59 595 596 597 598 599 3. DICOM Data Elements should not describe characteristics that are beyond the capability of the compression scheme used. For example, RLE compressed data streams (using the algorithm mandated in the DICOM Standard) are always color-by-plane. 8.2.3 JPEG-LS IMAGE COMPRESSION DICOM provides a mechanism for supporting the use of JPEG-LS Image Compression through the Encapsulated Format (see PS 3.3). Annex A defines a number of Transfer Syntaxes which reference the JPEG-LS Standard and provide a number of lossless (bit preserving) and lossy (near-lossless) compression schemes. Note: The context where the usage of lossy (near-lossless) compression of medical images is clinically acceptable is beyond the scope of the DICOM Standard. The policies associated with the selection of appropriate compression parameters (e.g. compression ratio) for JPEG-LS lossy (near-lossless) compression is also beyond the scope of this standard. The use of the DICOM Encapsulated Format to support JPEG-LS Compressed Pixel Data requires that the Data Elements which are related to the Pixel Data encoding (e.g. Photometric Interpretation, Samples per Pixel, Planar Configuration, Bits Allocated, Bits Stored, High Bit, Pixel Representation, Rows, Columns, etc.) shall contain values which are consistent with the characteristics of the compressed data stream. The Pixel Data characteristics included in the JPEG-LS Interchange Format shall be used to decode the compressed data stream. Note: See also the notes in section 8.2.1. 8.2. JPEG 2000 IMAGE COMPRESSION DICOM provides a mechanism for supporting the use of JPEG 2000 Image Compression through the Encapsulated Format (see PS 3.3). Annex A defines a number of Transfer Syntaxes which reference the JPEG 2000 Standard and provide lossless (bit preserving) and lossy compression schemes. Note: The context where the usage of lossy compression of medical images is clinically acceptable is beyond the scope of the DICOM Standard. The policies associated with the selection of appropriate compression parameters (e.g. compression ratio) for JPEG 2000 lossy compression is also beyond the scope of this standard. The use of the DICOM Encapsulated Format to support JPEG 2000 Compressed Pixel Data requires that the Data Elements which are related to the Pixel Data encoding (e.g. Photometric Interpretation, Samples per Pixel, Planar Configuration, Bits Allocated, Bits Stored, High Bit, Pixel Representation, Rows, Columns, etc.) shall contain values which are consistent with the characteristics of the compressed data stream. The Pixel Data characteristics included in the JPEG 2000 bit stream shall be used to decode the compressed data stream. Note: These requirements are specified in terms of consistency with what is encapsulated, rather than in terms of the uncompressed pixel data from which the compressed data stream may have been derived. When decompressing, should the characteristics explicitly specified in the compressed data stream be inconsistent with those specified in the DICOM Data Elements, those explicitly specified in the compressed data stream should be used to control the decompression. The DICOM data elements, if inconsistent, can be regarded as suggestions as to the form in which an uncompressed data set might be encoded. The JPEG 2000 bit stream specifies whether or not a reversible or irreversible multi-component (color) transformation, if any, has been applied. If no multi-component transformation has been applied, then the components shall correspond to those specified by the DICOM Attribute Photometric Interpretation. If the JPEG 2000 reversible multi-component transformation has

Page 21 600 601 602 603 60 605 606 607 608 609 610 611 612 613 61 615 616 617 618 619 been applied then the DICOM Attribute Photometric Interpretation shall be YBR_RCT. If the JPEG 2000 irreversible multi-component transformation has been applied then the DICOM Attribute Photometric Interpretation shall be YBR_ICT. Notes: 1. For example, single component may be present, and the Photometric Interpretation may be MONOCHROME2. 2. Though it would be unusual, would not take advantage of correlation between the red, green and blue components, and would not achieve effective compression, a Photometric Interpretation of RGB could be specified as long as no multi-component transformation was specified by the JPEG 2000 bit stream. 3. Despite the application of a multi-component color transformation and its reflection in the Photometric Interpretation attribute, the color space remains undefined. There is currently no means of conveying standard color spaces either by fixed values (such as srgb) or by ICC profiles. Note in particular that the JP2 file header is not sent in the JPEG 2000 bitstream that is encapsulated in DICOM. The JPEG 2000 bitstream is capable of encoding both signed and unsigned pixel values, hence the value of Pixel Representation may be either 0 or 1 depending on what has been encoded (as specified in the SIZ marker segment in the precision and sign of component parameter). The value of Planar Configuration is irrelevant since the manner of encoding components is specified in the JPEG 2000 standard, hence it shall be set to 0. 620 621 Add JPEG 2000 default requirements to Section 10: 622 Section 10 Transfer Syntax 623 62 625 626 627 628 629 630 631 632 633 63 635 636 637 638 639 A Transfer Syntax is a set of encoding rules able to unambiguously represent one or more Abstract Syntaxes. In particular, it allows communicating Application Entities to negotiate common encoding techniques they both support (e.g., byte ordering, compression, etc.). A Transfer Syntax is an attribute of a Presentation Context, one or more of which are negotiated at the establishment of an Association between DICOM Application Entities. This Association negotiation is specified in PS 3.8 and discussed in PS 3.7. The selection of a Transfer Syntax applies to the encoding rules for the Data Set portion of a DICOM Message only. All DICOM Standard and Private Transfer Syntaxes implicitly specify a fixed encoding for the Command Set portion of a DICOM Message as Specified in PS 3.7. This part of the DICOM Standard defines standard DICOM Transfer Syntaxes and assigns a unique Transfer Syntax Name to each one. The standard DICOM Transfer Syntaxes are specified in Annex A. The DICOM notation for Transfer Syntax names is the notation used for UIDs (see Section 9). The organization responsible for the definition and registration of DICOM Transfer Syntaxes is NEMA. NEMA guarantees uniqueness for all DICOM Transfer Syntax Names. Privately defined Transfer Syntax Names may also be used; however, they will not be registered by NEMA. Organizations that define private Transfer Syntax Names shall follow the registration process defined in Section 9.2.

Page 22 60 61 62 63 6 65 66 67 68 69 650 651 652 653 65 655 656 657 658 659 660 661 662 663 66 665 666 667 668 669 670 671 672 673 67 675 676 677 678 679 680 681 682 683 68 685 686 687 688 689 10.1 DICOM DEFAULT TRANSFER SYNTAX DICOM defines a default Transfer Syntax, the DICOM Implicit VR Little Endian Transfer Syntax (UID = "1.2.80.10008.1.2"), that shall be supported by every conformant DICOM Implementation. This implies that: a) If an Application Entity issues an A-ASSOCIATE request, it shall offer the DICOM Implicit VR Little Endian Transfer Syntax in at least one of the Presentation Contexts associated with each offered Abstract Syntax. Note: Offering Abstract Syntax (AS1) in two Presentation Contexts with Transfer Syntaxes (TS1) and (TS2) is not valid, but offering AS1-TS1, AS1-TS2 and AS1-TSD is valid because the DICOM Default Little Endian Transfer Syntax (TSD) is present in at least one of the Presentation Contexts which are based on Abstract Syntax (AS1). b) If an Application Entity receives an A-ASSOCIATE indication corresponding to a request which follows the requirements specified in Section 10.1 a), every Presentation Context related to a given Abstract Syntax cannot be rejected in an A-ASSOCIATE response for the reason that none of the Transfer Syntaxes are supported. Both of these requirements, a) and b), are waived when the Application Entity sending the pixel data has only access to the pixel data in lossy compressed form. Note: In other words, every sending AE is required to be able to convert any dataset it is going to transmit into the Default Transfer Syntax, regardless of the form in which it originally received or stored the data set, except in the single case of when it received it in a lossy compressed form. In that exceptional case, the sending AE is permitted to propose only the lossy compressed Transfer Syntax appropriate to the lossy form that was received. In particular, this waiver does not apply to data sets received in a lossless compressed form, which means that any AE receiving a data set in a lossless compressed Transfer Syntax that needs to re-send the data set is required to be able to decompress it in order to support (at least) the default Transfer Syntax. 10.2 TRANSFER SYNTAX FOR A DICOM DEFAULT OF LOSSLESS JPEG COMPRESSION DICOM defines a default for lossless JPEG Image Compression, which uses a subset of coding Process 1 with a first-order prediction (Selection Value 1). It is identified by Transfer Syntax UID = "1.2.80.10008.1.2..70" and shall be supported by every DICOM implementation that chooses to support one or more of the lossless JPEG compression processes. This implies that: a) If an Application Entity issues an A-ASSOCIATE request where any offered Abstract Syntaxes is associated in one or more Presentation Context with a JPEG lossless compression Transfer Syntax, at least one of the Presentation Contexts which include this Abstract Syntax, shall include the DICOM Default Lossless JPEG Compression Transfer Syntax and the DICOM Default Transfer Syntax (uncompressed). Note: Offering Abstract Syntax (AS1) in two Presentation Contexts with Transfer Syntaxes JPEG lossless (JL1) and (JL2) is not valid, but offering AS1-JL1, AS1-JL2, AS1-TSD, and AS1-JLD is valid because the DICOM Default JPEG Lossless Transfer Syntax (JLD) and the DICOM Default Transfer Syntax (TSD) are present in at least one of the Presentation Contexts which are based on Abstract Syntax (AS1). b) If an Application Entity that supports one or more lossless JPEG Transfer Syntax receives an A-ASSOCIATE indication corresponding to a request which follows the requirements specified in Section 10.2 a), every Presentation Context related to a given Abstract Syntax cannot be rejected in an A-ASSOCIATE response for the reason that the DICOM Default lossless JPEG Transfer Syntax is not supported. 10.3 TRANSFER SYNTAXES FOR A DICOM DEFAULTS OF LOSSY JPEG COMPRESSION DICOM defines defaults for Lossy JPEG Image Compression, one for 8-bit images and the other for 12-bit images. JPEG coding Process 1 (identified by Transfer Syntax UID =

Page 23 690 691 692 693 69 695 696 697 698 699 700 701 702 703 70 705 706 707 708 709 710 711 712 713 "1.2.80.10008.1.2..50") is used for 8-bit images. JPEG coding Process (identified by Transfer Syntax UID = 1.2.80.10008.1.2..51 ) is used for 12-bit images. This implies that: a) If an Application Entity issues an A-ASSOCIATE request where any offered Abstract Syntaxes is associated in one or more Presentation Context(s) with a JPEG lossy compression Transfer Syntax, at least one of the Presentation Contexts which include this Abstract Syntax, shall include the appropriate DICOM Default Lossy JPEG Compression Transfer Syntax. Note: 1. Offering Abstract Syntax (AS1) in two Presentation Contexts with Transfer Syntaxes JPEG lossy (JL1) and (JL2) is not valid, but offering AS1-JL1, AS1-JL2 and AS1-JLD is valid because the DICOM Default JPEG Lossy Transfer Syntax (JLD) is present in at least one of the Presentation Contexts which are based on Abstract Syntax (AS1). 2. The DICOM Default Transfer Syntax (uncompressed) may be offered if the sender has access to the original pixel data in an uncompressed or lossless compressed form. b) If an Application Entity that supports one or more Lossy JPEG Transfer Syntaxes receives an A-ASSOCIATE indication corresponding to a request which follows the requirements specified in Section 10.3 a), every Presentation Context related to a given Abstract Syntax cannot be rejected in an A-ASSOCIATE response for the reason that the DICOM Default lossy JPEG Transfer Syntax is not supported. 10. TRANSFER SYNTAX FOR DICOM RLE COMPRESSION DICOM defines the RLE Compression (see Annex G). This implies that: a) If an Application Entity issues an A-ASSOCIATE request where any offered Abstract Syntaxes is associated in one or more Presentation Contexts(s) with RLE compression Transfer Syntax, at least one of the Presentation Contexts which include this Abstract Syntax, shall include the DICOM Default Transfer Syntax (uncompressed). 71 715 716 717 718 719 720 721 722 723 10.5 TRANSFER SYNTAX FOR A DICOM DEFAULT OF LOSSLESS AND LOSSY (NEAR- LOSSLESS) JPEG-LS COMPRESSION One Transfer Syntax is specified for JPEG-LS Lossless Image Compression, and one Transfer Syntax is specified for JPEG-LS Lossy (Near-Lossless) Image Compression. The JPEG-LS Lossless Transfer Syntax shall be supported as a baseline if the JPEG-LS Lossy (Near-Lossless) Transfer Syntax is supported. 10.6 TRANSFER SYNTAX FOR A DICOM DEFAULT FOR JPEG 2000 COMPRESSION One Transfer Syntax is specified for JPEG 2000 Lossless Image Compression, and one Transfer Syntax is specified for JPEG 2000 Lossy Image Compression. 72 725 726 727 728 729 730 731 732 Notes: 1. All JPEG 2000 codecs are required by ISO/IEC 15-1 to support both reversible and irreversible wavelet and multi-component transformations. The reason for specifying two separate Transfer Syntaxes in DICOM is to allow an application to request the transfer of images in a lossless manner when possible. 2. No baseline using other compression schemes is required. 3. The waiver of the requirement in Section 10.1 to support the DICOM Default Transfer Syntaxstill applies when the Application Entity sending the pixel data has only access to the pixel data in lossy compressed form.