Transfer Syntax and Byte Ordering
For Implicit VR Little Endian transfer syntax, the pixel data attribute's (7fe0,0010) VR are specified as being OW (independent of what the bits allocated and bits stored attributes are set to). To reduce confusion, the toolkit sets the VR of pixel data for the other non-encapsulated transfer syntaxes to OW.
When retrieving or setting bulk data, the toolkit assumes that the OW, OL, OV, OF and OD data are encoded in the host system's native endian format as defined by DICOM. The following example describes how 8-bit pixel data are encoded in an OW buffer for both big and little endian formats:
The DICOM standard specifies that the first pixel byte should be set to the least significant byte of the OW value. The next pixel byte should be set to the most significant byte of the OW value. This implies that on big endian machines, 8-bit pixel data is byte-swapped from the OB encoding method.
Encapsulated Pixel Data, Compression/Decompression
The toolkit supports the DICOM encapsulated transfer syntaxes. It also provides support for the actual compression and decompression of encapsulated data. The method for compression and decompression (JPEG, RLE, etc.) of encapsulated pixel data is specified in part 5 of the DICOM standard.
Encapsulated pixel data can be handled using the getEncapsulatedFrame() and
addEncapsulatedFrame() methods of the MCattributeSet class. These methods get or set the stream of compressed pixel data for one frame of pixel data. The toolkit will automatically decode or encode the encapsulated pixel data sequence, including the Basic Offset Table depending on the value of the CREATE_OFFSET_TABLE
setting.
The toolkit supplies several implementations of compressors and decompressors supporting multiple transfer syntaxes. Compression/decompression can be enabled/disabled using the setDefaultCompression() method of the MCattributeSet class, which will register/unregister the default compression/decompression callbacks. When registered, the compression/decompression is utilized any time addEncapsulatedFrame() and getEncapsulatedFrame() functions are called, and the transfer syntax (MCtransferSyntax) of a message has been set to one of the following values:
DICOM Transfer Syntaxes Supported | MCtransferSyntax |
---|---|
JPEG Baseline | JPEG_BASELINE |
JPEG Extended (Process 2 & 4) | JPEG_EXTENDED_2_4 |
JPEG Lossless Non-Hierarchical Process 14 | JPEG_LOSSLESS_HIER_14 |
JPEG 2000 | JPEG_2000 |
JPEG 2000 Lossless Only | JPEG_2000_LOSSLESS_ONLY |
RLE | RLE |
The primary method for compressing/decompressing objects with the Merge DICOM toolkit is the duplicate() method of the MCattributeSet class. The method can convert between different compressed transfer syntaxes, or it can be used to compress an uncompressed message, or to decompress a compressed message.
For the JPEG Baseline, JPEG Extended (Process 2 & 4), JPEG Lossless Non-Hierarchical Process 14, JPEG 2000, and JPEG 2000 Lossless Only transfer syntaxes, Merge DICOM utilizes the Pegasus Imaging libraries from Accusoft Corporation to do compression and decompression. The RLE transfer syntax is supported directly in Merge DICOM Toolkit.
There are limits on the performance of the Pegasus libraries, unless fully licensed. JPEG Baseline, JPEG Extended (Process 2 & 4), and JPEG Lossless Non-Hierarchical Process 14 can be compressed or decompressed at a maximum rate of 3 images (or frames) per second. For JPEG 2000 Lossless and Lossy, a dialog will be displayed each time the compressor or decompressor is used.
NOTE: Full licenses can be acquired from Accusoft (www.accusoft.com) and configured in Merge DICOM to remove these limitations. The licenses can be configured in the mergecom.pro configuration file.
JPEG and JPEG 2000 compression and decompression are only available on platforms that the Pegasus libraries support. Currently these are 32- and 64-bit Windows on x86, 32-bit Solaris on SPARC, 32-bit Solaris on x86, 32- and 64-bit Linux on x86 and 32-bit Android on ARM7.
The MCtransferSyntax.JPEG_BASELINE
transfer syntax is UID 1.2.840.10008.1.2.4.50, JPEG Baseline (Process 1): Default Transfer Syntax for Lossy JPEG 8 Bit Image Compression, and uses Pegasus libraries 6420/6520. Table 1 details the photometric interpretations and bit depths supported by the standard compressor and decompressor for this transfer syntax. When lossy compressing RGB data, the standard compressor by default compresses the data into YBR_FULL_422
format. The compressor can also compress in YBR_FULL
format if the COMPRESSION_RGB_TRANSFORM_FORMAT
configuration option is set to YBR_FULL
. The Photometric Interpretation tag must be changed by the application after compressing RGB
data. Similarly, the Photometric Interpretation tag should be changed back to RGB
before decompressing YBR_FULL
or YBR_FULL_422
data.
JPEG Baseline | Photometric Interpretation | MONOCHROME1 MONOCHROME2 | RGB | YBR_FULL_422 |
---|---|---|---|
Bits Stored | 8 | 8 | 8 |
Bits Allocated | 8 | 8 | 8 |
Samples Per Pixel | 1 | 3 | 3 |
JPEG_BASELINE
decompression is supported on the Android platform. The Pegasus library for JPEG_BASELINE
compression (6420) is not available on the Android platform.
The MCtransferSyntax.JPEG_EXTENDED_2_4
transfer syntax is UID 1.2.840.10008.1.2.4.51, JPEG Extended (Process 2 & 4): Default Transfer Syntax for Lossy JPEG 12 Bit Image Compression (Process 4 only), and uses Pegasus libraries 6420/6520. Table 2 details the photometric interpretations and bit depths supported by the standard compressor and decompressor for this transfer syntax. When lossy compressing RG
data, the standard compressor by default compresses the data into YBR_FULL_422
format. The compressor can also compress in YBR_FULL
format if the COMPRESSION_RGB_TRANSFORM_FORMAT
configuration option is set to YBR_FULL
. The Photometric Interpretation tag must be changed by the application after compressing RGB
data. Similarly, the Photometric Interpretation tag should be changed back to RGB before decompressing YBR_FULL
or YBR_FULL_422
data.
JPEG Extended (Process 2 & 4) | Photometric Interpretation | MONOCHROME1 MONOCHROME2 | RGB | YBR_FULL_422 | |
---|---|---|---|---|---|
Bits Stored | 8 | 10 | 12 | 8 | 8 |
Bits Allocated | 8 | 16 | 16 | 8 | 8 |
Samples Per Pixel | 1 | 1 | 1 | 3 | 3 |
JPEG_EXTENDED_2_4
decompression is supported on the Android platform. The Pegasus library for JPEG_EXTENDED_2_4
compression (6420) is not available on the Android platform.
The MCtransferSyntax.JPEG_LOSSLESS_70
transfer syntax is UID 1.2.840.10008.1.2.4.70, JPEG Lossless, Non-Hierarchical, First-Order Prediction (Process 14 [Selection Value 1]): Default Transfer Syntax for Lossless JPEG Image Compression, and uses Pegasus libraries 6220/6320. Table 3 details the photometric interpretations and bit depths supported by the standard compressor and decompressor for this transfer syntax. The standard compressor does not do a color transformation to RGB
data when compressing with JPEG_LOSSLESS_70
. The Photometric Interpretation tag should be left as RGB
in this case.
JPEG Lossless Non-Hierarchical Process 14 | Photometric Interpretation | MONOCHROME1 MONOCHROME2 | RGB YBR_FULL | PALETTE COLOR | |
---|---|---|---|---|---|
Bits Stored | 2 to 16 | 8 | 1 to 16 | ||
Bits Allocated | 8 or 16 | 8 | 8 or 16 | ||
Samples Per Pixel | 1 | 3 | 1 | ||
JPEG_LOSSLESS_70
decompression is supported on the Android platform. The Pegasus library for JPEG_LOSSLESS_70
compression (6220) is not available on the Android platform.
The MCtransferSyntax.JPEG_2000
transfer syntax is UID 1.2.840.10008.1.2.4.91, JPEG 2000 Image Compression, and uses Pegasus libraries 6820/6920 for lossy or lossless. Table 4 details the photometric interpretations and bit depths supported by the standard compressor and decompressor for this transfer syntax.
JPEG 2000 (When used for Lossy) | Photometric Interpretation | MONOCHROME1 MONOCHROME2 | YBR_ICT | RGB | YBR_FULL | ||
---|---|---|---|---|---|---|---|
Bits Stored | 8 | 10 | 12 | 16 | 8 | 8 | 8 |
Bits Allocated | 8 | 16 | 16 | 16 | 8 | 8 | 8 |
Samples per Pixel | 1 | 1 | 1 | 1 | 3 | 3 | 3 |
JPEG_2000
decompression is supported on the Android platform. The Pegasus library for JPEG_2000
compression (6820) is not available on the Android platform.
The MCtransferSyntax.JPEG_2000_LOSSLESS_ONLY
transfer syntax is UID 1.2.840.10008.1.2.4.90, JPEG 2000 Image Compression (Lossless Only), and uses Pegasus libraries 6820/6920 for lossless. Table 5 details the photometric interpretations and bit depths supported by the standard compressor and decompressor for this transfer syntax.
JPEG 2000 Lossless | Photometric Interpretation | MONOCHROME1 MONOCHROME2 | YBR_RCT YBR_FULL | RGB | PALETTE COLOR | ||
---|---|---|---|---|---|---|---|
Bits Stored | 8 | 10 | 12 | 16 | 8 | 8 | 1 to 16 |
Bits Allocated | 8 | 16 | 16 | 16 | 8 | 8 | 8 or 16 |
Samples per Pixel | 1 | 1 | 1 | 1 | 3 | 3 | 1 |
JPEG_2000_LOSSLESS_ONLY
decompression is supported on the Android platform. The Pegasus library for JPEG_2000_LOSSLESS_ONLY
compression (6820) is not available on the Android platform.
When using the standard compressor, all data need to be right justified, i.e. bit 0 contains data, but the highest bits may not. RGB and YBR must be non-planar (R1G1B1, R2G2B2, ... or Y1Y2B1R1, Y3Y4B3R3,...)
MCtransferSyntax.JPEG_2000
and MCtransferSyntax.JPEG_2000_LOSSLESS_ONLY
will cause an irreversible and reversible color transformation, respectively, when compressing RGB data. The Photometric Interpretation MUST be changed from RGB to:
MCtransferSyntax.JPEG_2000
is used with COMPRESSION_WHEN_J2K_USE_LOSSY = Yes
(Lossy color transform for lossy compression)
MCtransferSyntax.JPEG_2000_LOSSLESS_ONLY
or MCtransferSyntax.JPEG_2000
with COMPRESSION_WHEN_J2K_USE_LOSSY = No
(Lossless color transform for lossless compression).Similarly, on the decompression end, the Photometric Interpretation should be changed back to RGB
, but the Lossy Image Compression attribute should indicate it has been lossy compressed.
Alternative Value Storage
The MCvalueStorageProvider interface is the template for classes that will provide application storage for bulk attribute values. Instances implementing this interface may be registered with the library using the
registerValueStorageProvider() method of
the MCapplication
class. The library considers this interface a provider for 'containers' for specific attribute's values instead of storing the values internally. A container is represented by the MCvalueStorage interface.
A server (SCP) application can register a MCvalueStorageProvider object that will be called by the toolkit whenever a storage for the specified attribute's value is needed. The toolkit then calls repetitively the methods of the provided
storage object as the attribute�s value arrives on an association during a readMessage
call on the association object. By the time the readMessage
method returns, the attribute value will already have been handled by the value storage object. In this scenario the value storage object could be used by the server to treat this large block of OB/OW/OF data (usually pixel data) specially (e.g. store in a frame buffer, filter through decompression hardware, write to disk... ) without any overhead introduced by the toolkit.
A client (SCU) application can register a MCvalueStorageProvider object that will provide the value storage for an attribute as the attribute�s value is transmitted over an association during a sendRequest() or sendResponse() call on the association object. During either of these calls, the attribute value will be supplied by the value storage object. The MCattributeContainer class can also be used by the client to specially manage OB/OW/OL/OV/OF/OD data (e.g., read from a frame buffer, filter through compression hardware or software, read from disk... ) without any overhead introduced by the toolkit.