July 31, 2000
DICOM CORRECTION PACKET 8
This package contains Correction Proposals CP 174, CP 182, CP 183, CP 189, CP 190, CP 191, CP 193, CP 194, CP 196, CP 197, CP 198, CP 200, CP 203 and CP 204
File: cpack 008.doc
DICOM Correction Item
Abstract: Add support for JPEG-LS Transfer Syntaxes
Type of Change Proposal:
Addition
Name of Document:
Part 5: Data Structures and Encoding,
Part 6: Data Dictionary / Version Number:
PS 3.5-1999,
PS 3.6-1999
Rationale for change:
The state of the art in lossless compression has improved considerably since the original JPEG processes were proposed and incorporated in DICOM.
The JPEG working group has created a new standard, ISO 14495-1 (JPEG-LS) that defines a state of the art predictive scheme using a very effective statistical modeller with low complexity entropy coding and a run length escape mechanism. Experiments with large sets of medical images indicate a mean compression ratio of 3.81 for JPEG-LS in lossless mode compared with 3.06 for JPEG lossless mode with Huffman encoding choosing the best predictor for each image, or 2.80 for selection value 1 (the most commonly used in DICOM).
Using JPEG-LS could result in considerable savings in transfer time or media space compared with the current DICOM transfer syntaxes. The JPEG-LS process is also extremely simple and fast compared to existing JPEG lossless. Several source code implementations are available freely on the Internet. No license fees are required to use the JPEG-LS standard.
Since the bit stream syntax of JPEG-LS is almost identical to JPEG, the same encapsulation mechanism can be used in DICOM without any change.
JPEG-LS also offers a so-called “near-lossless” mode that allows one to constrain the absolute error for pixels to a fixed value. This is a totally different approach to lossy compression compared to the DCT or wavelet based schemes, and may have interesting medical applications for visually lossless compression. It is still lossy, however.
Accordingly, two new transfer syntaxes are proposed for JPEG-LS in DICOM, one for lossless compression and another for lossy (near-lossless) compression.
Note especially that the JPEG-LS is added without requiring an implementation to support a “base-line” of existing JPEG lossless encoding, since:
a) this is an unnecessary burden on implementers (especially since existing JPEG lossless is rarely, if ever, used on the network in practice),
b) a baseline of uncompressed is always available on the network, guaranteeing interoperability at this level, and
c) baselines are not applicable for media since transfer syntaxes are fully specified in the media application profile.
However, the lossless mode of JPEG-LS is required to be supported as a baseline when the loss
Correction wording:
Item: Amend PS 3.5 Section 2 Normative references:
ISO/IS 10918-1JPEG Standard for digital compression and encoding of continuous-tone still images. Part 1Requirements and implementation guidelines
ISO/IS 10918-2DRAFT: JPEG Standard for digital compression and encoding of continuous-tone still images. Part 2Testing
ISO/IS 14495-1Lossless and near-lossless coding of continuous tone still images (JPEG-LS)
Item: Add to PS 3.5 Section 8.2.3:
8.2.3JPEG-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 implies that the Data Elements which are related to the Native Format Pixel Data encoding (e.g. Bits Allocated, Bits Stored, High Bit, Pixel Representation, Rows, Columns, etc.) shall contain values which are consistent with the characteristics of the uncompressed pixel data from which the compressed Data Stream was derived. The Pixel Data characteristics included in the JPEG-LS Interchange Format shall be used to decode the compressed data stream.
Item: Add to PS 3.5 Section 10.5:
10.5Transfer 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.
Item: Amend PS 3.5 Section A.4:
A.4Transfer syntaxes for encapsulation of encoded pixel data
…
c)The encoding of the Data Elements of the Data Set shall be as follows according to their Value Representations:
…
All items containing an encoded fragment shall be made of an even number of bytes greater or equal to two. The last fragment of a frame may be padded, if necessary, to meet the sequence item format requirements of the DICOM Standard.
Notes:1. Any necessary padding may be added in the JPEG or JPEG-LS compressed data stream as per ISO 10918-1 and ISO 14495-1 such that the End of Image (EOI) marker ends on an even byte boundary, or may be appended after the EOI marker, depending on the implementation.
2. ISO 10918-1 and ISO 14495-1 defines the ability to add any number of padding bytes FFH before any marker (all of which also begin with FFH). It is strongly recommended that FFH padding bytes not be added before the Start of Image (SOI) marker.
Item: Add to PS 3.5 Section A.4.3:
A.4.3JPEG-LS image compression
The International Standards Organization ISO/IEC JTC1 has developed an International Standard, ISO/IS-14495-1 (JPEG-LS Part 1), for digital compression and coding of continuous-tone still images. (See Annex F for further details.)
A DICOM Transfer Syntax for JPEG-LS Image Compression shall be identified by a UID value, appropriate to its JPEG-LS coding process.
Two Transfer Syntaxes are specified for JPEG-LS:
- A Transfer Syntax with a UID of1.2.840.10008.1.2.4.80, which specifies the use of the lossless mode of JPEG-LS. In this mode the absolute error between the source and reconstructed images will be zero.
- A Transfer Syntax with a UID of1.2.840.10008.1.2.4.81, which specifies the use of the near-lossless mode of JPEG-LS. In this mode, the absolute error between the source and reconstructed images will be constrained to a finite value that is conveyed in the compressed bit stream. Note that this process can, at the discretion of the encoder, be used to compress images with an error constrained to a value of zero, resulting in no loss of information.
If the object allows multi-frame images in the pixel data field, then each frame shall be encoded separately. Each fragment shall contain encoded data from a single-frame image.
For all images, including all frames of a multi-frame image, the JPEG-LS Interchange Format shall be used (all parameter specifications shall be included).
Item: Add to PS 3.5 Section F.2:
F.2Encapsulated JPEG-LS encoded images
The International Standards Organization (ISO/IEC JTC1/SC2/WG10) has prepared an International Standard, ISO/IS-14495-1 (JPEG-LS Part 1), for the digital compression and coding of continuous-tone still images. This standard is known as the JPEG-LS Standard.
Part 1 of the JPEG-LS Standard sets out requirements and implementation guidelines for the coded representation of compressed image data to be interchanged between applications. The processes and representations are intended to be generic in order to support the broad range of applications for color and grayscale still images for the purpose of communications and storage within computer systems.
The JPEG-LS Standard specifies a single lossy (near-lossless) code process that can achieve lossless compression by constraining the absolute error value during encoding to zero. The lossless and lossy (near-lossless) coding is based on a predictive scheme with statistical modeling, in which differences between pixels and their surround are computed and their context modeled prior to coding, with a run-length escape mechanism. This scheme achieves consistently better compression in lossless mode than the lossless processes of JPEG defined in ISO 10918-1, with less complexity.
Though a different coding process from those specified in ISO 10918-1 is used, the syntax of the encoded bit stream is closely related.
A single JPEG-LS process is used for bit depths up to 16 bits.
Inclusion of a JPEG-LS coded image in a DICOM message is facilitated by the use of specific Transfer Syntaxes that are defined in Annex A.
Item: Add to PS 3.6 Registry of DICOM unique identifiers (UID)
Table A-1
UID VALUES
1.2.840.10008.1.2.4.80 / JPEG-LS Lossless Image Compression / Transfer Syntax / PS 3.5
1.2.840.10008.1.2.4.81 / JPEG-LS Lossy (Near-Lossless) Image Compression / Transfer Syntax / PS 3.5
DICOM Correction Item
Correction Number CP-182Log Summary: Clarification of use of AE Titles by C-Move service
Type of Modification
Clarification / Name of Standard
PS 3.4-1999 w/ Supplements
Rationale for Correction
In section C.1.4 “Service Definition”, description of semantics of C-MOVE service states that the SCP of the Query/Retrieve SOP Class serves as an SCU of Storage SOP Class. This implies or could be interpreted as both roles (SCP of the Query/Retrieve SOP Class and SCU of Storage SOP Class) are played by the same Application Entity - per definition in section 3.9, an Application Entity may perform different roles on different associations.
Additionally, according to the Annex C “DICOM Addressing” of Part 8, one DICOM Application Name (which is used as the Application Entity Title) identifies a unique service or application on a specific system in the network. Since C-MOVE is considered a one service, this effectively imposes a requirement that SCP of the Query/Retrieve SOP Class and SCU of Storage SOP Class must use the same Application Entity Title and to be implemented as single application.
This appears to be an unnecessary restriction since in many implementations better performance and effectiveness may be achieved by separating to roles so they are played by different applications/processes on the same or different systems.
Sections of documents affected
PS 3.4: Sections H.4.12.2.1.3, H.4.9.2.2.2
Correction Wording:
Modify behavior descriptions as follows
Update Section C.1.4 of Part 4 as follows:
C.1.4Service Definition
b) A C-MOVE service conveys the following semantics:
—The SCU supplies Unique Key values to identify an entity at the level of the retrieval. The SCP of the C-MOVE initiates C-STORE sub-operations for the corresponding storage SOP Instances identified by Unique Key values. These C-STORE sub-operations occur on a different Association than the C-MOVE service. The SCP role of the Query/Retrieve SOP Class and serves asthe SCU roleof the Storage SOP Classmay be performed by different applications which may or may not reside on the same system. Initiation mechanism of C-STORE sub-operations is outside of the scope of DICOM standard.
Note:This does not imply that they use the same AE Title. See C.6.1.2.2.2, C.6.2.2.2.2 and C.6.3.2.2.2 for the requirements to the C-MOVE SCP conformance.
DICOM Correction Item
Correction Number CP-183Log Summary: Correct Pixel Ordering Description in the RT Beams Module
Type of Modification
Clarification / Name of Standard
PS 3.3-1999 w/ Supplements
Rationale for Correction
In the attribute descriptions for Compensator Transmission Data (300A,00EB) and Compensator Thickness Data (300A,00EC), order of pixels is described as follows: “The order of pixels sent is left to right, top to bottom (upper left pixel, followed by the remainder of row 1, followed by the remainder of the columns)”. This may be interpreted incorrectly. This shall be worded unambiguously, in a same way as elsewhere in the standard.
Sections of documents affected
PS 3.3-1999 (Information Object Definitions), Section C.8.8.14 (RT Beams Module)
Correction Wording:
In DICOM PS 3.3-1999, Section C.8.8.14 (RT Beams Module), Table C.8-46 (RT Beams Module Attributes), phrase in parentheses should be replaced in the description of the following attributes:
>Compensator Transmission Data(300A,00EB)1CA data stream of the pixel samples which comprise the compensator, expressed as broad-beam transmission values (between 0 and 1) along a ray line passing through the pixel, at the beam energy specified by the Nominal Beam Energy (300A,0114) of the first Control Point of the Control Point Sequence (300A,0111). The order of pixels sent is left to right, top to bottom (upper left pixel, followed by the remainder of row 1, followed by the remainder of the columnsThe order of pixels sent for each overlay is left to right, top to bottom, i.e., the upper left pixel is sent first followed by the remainder of the first row , followed by the first pixel of the 2nd row, then the remainder of the 2nd row and so on) when viewed from the radiation source. Required if Compensator Sequence (300A,00E3) is sent and Material ID (300A,00E1) is zero-length.
>Compensator Thickness Data(300A,00EC)1CA data stream of the pixel samples which comprise the compensator, expressed as thicknesses (in mm) parallel to radiation beam axis. The order of pixels sent is left to right, top to bottom (upper left pixel, followed by the remainder of row 1, followed by the remainder of the columnsThe order of pixels sent for each overlay is left to right, top to bottom, i.e., the upper left pixel is sent first followed by the remainder of the first row , followed by the first pixel of the 2nd row, then the remainder of the 2nd row and so on) when viewed from the radiation source. Required if Compensator Sequence (300A,00E3) is sent and Material ID (300A,00E1) is non-zero length.
DICOM Correction Item
Correction Number CP-189Log Summary: Clarification in standard that data elements of undefined length are allowed for Unknown (UN) Value Representation.
Type of Modification
clarification / Name of Standard
PS 3.5- 1999
Rationale for Correction:
There is an inconsistency in the standard regarding VRs of Unknown (UN). Section 6.2.2 indicates the length field of a VR of UN may contain the value of unknown length. However, the note at the end of Section 7.1.1 does not include UN as a VR that can be of undefined length. This CP simply seeks to clarify this.
Sections of documents affected
PS 3.5, Section 7.1.1
Correction Wording:
Modify note in section 7.1.1 to be consistent with note in section 6.2.2
7.1.1DATA ELEMENT FIELDS
A Data Element is made up of fields. Three fields are common to all three Data Element structures; these are the Data Element Tag, Value Length, and Value Field. A fourth field, Value Representation, is only present in the two Explicit VR Data Element structures. The Data Element structures are defined in Sections 7.1.2. and 7.1.3. The definitions of the fields are:
Data Element Tag:An ordered pair of 16-bit unsigned integers representing the Group Number followed by Element Number.
Value Representation:A two-byte character string containing the VR of the Data Element. The VR for a given Data Element Tag shall be as defined by the Data Dictionary as specified in PS 3.6. The two character VR shall be encoded using characters from the DICOM default character set.
Value Length:Either:
a 16 or 32-bit (dependent on VR and whether VR is explicit or implicit) unsigned integer containing the Explicit Length of the Value Field as the number of bytes (even) that make up the Value. It does not include the length of the Data Element Tag, Value Representation, and Value Length Fields.
a 32-bit Length Field set to Undefined Length (FFFFFFFFH). Undefined Lengths may be used for Data Elements having the Value Representation (VR) Sequence of Items (SQ) and Unknown (UN). For Data Elements with Value Representation OW or OB Undefined Length may be used depending on the negotiated Transfer Syntax (see Section 10 and Annex A).
Note:The decoder of a Data Set should support both Explicit and Undefined Lengths for VRs of SQand UN and, when applicable, for VRs of OW and OB.
DICOM Correction Item
Correction Number 190Log Summary: Allow case insensitive matching for Queries of PN value representations
Type of Modification / Name of Standard
PS 3.4 - 1999
Rationale for Correction
One of the common “problems” with the query SOP classes is that the standard specifies that all matching of keys is case sensative. It is often desirable to have case insensative matches available especially for person name fields and since user interfaces commonly allow both upper and lower case input for the SCU and it is unknown in what case the SCP has data stored.
Sections of documents affected
PS 3.4 – 1999 Sections C.2, C.4, C.5, C.6
Correction Wording:
Amend PS 3.4-1999 Section C.2.2.2.1 and C.2.2.2.4 to change case sensitive rules for PN attributes.
C.2.2.2.1Single Value Matching
If the value specified for a Key Attribute in a request is non-zero length and if it is:
a);not a date or time, contains no wild card characters
b);a date or time, contains a single date or time with no "-"
then single value matching shall be performed. Only entities with values which match exactly the value specified in the request shall match. This matching is case-sensitive, except for Attributes with an PN Value Representation (e.g., Patient Name (0010,0010)) in which case it is implementation dependent and shall be specified in the conformance statement.
...
C.2.2.2.4Wild Card Matching
If the Attribute is not a date, time, signed long, signed short, unsigned short, unsigned long, floating point single, floating point double, other byte string, other word string, unknown, attribute tag, decimal string, integer string, age string or UID and the value specified in the request contains any occurrence of an "*" or a "?", then "*" shall match any sequence of characters (including a zero length value) and "?" shall match any single character. This matching is case sensitive, except for Attributes with an PN Value Representation (e.g., Patient Name (0010,0010)) in which case it is implementation dependent and shall be specified in the conformance statement. See PS 3.5 for Value Representations.
Notes:1.Wild card matching on a value of "*" is equivalent to universal matching.
- The wild card matching method specified by DICOM might not be supported by some non-DICOM multi-byte character text processors.
Amend PS 3.4-1999 Section C.6.1.2.2.1 to add case-insensitive matching conformance requirements.
C.6.1.2.2.1C-FIND SCP Conformance
An implementation which conforms to one of the SOP Classes of the Patient Root SOP Class Group shall support queries against the Query/Retrieve Information Model described in Section C.6.1.1 using the C-FIND SCP Behavior described in Section C.4.1.3.