| Rationale for Correction:Some photometric interpretations are defined primarily for use with compressed data, YBR_FULL_422 for use with (lossy) JPEG, YBR_RCT & YBR_ICT for use with JPEG 2000, and YBR_PARTIAL_420 for use with MPEG.YBR_FULL_422 has also been encountered with RLE compressed and uncompressed data (particularly in Ultrasound applications). Though there are issues with using YBR_FULL_422 (e.g., the chrominance downsampling and upsampling methods are not formally defined even though the cositing mechanism is, and different choices by sender and recipient can cause aliasing artifacts), it cannot be forbidden because it is encountered in the field. It is also included in the Ultrasound Media Application profiles. Accordingly, some clarifications and limitations are proposed. YBR_PARTIAL_422, though permitted by the Ultrasound Media Application profiles, has apparently never been used.YBR_RCT, YBR_ICT and YBR_PARTIAL_420
have problems and ambiguities if used for uncompressed data, very few, if any, recipients support such use, so it is proposed to disallow their use for uncompressed data.
Some existing color IODs explicitly constrain the permitted Photometric Interpretation values to those appropriate for the Transfer Syntax, either in the IOD or in IOD-family-specific Modules. Expand the list to recognize the use of YBR_FULL for RLE when permitted (and note if not). Apply similar constraints to VL, WSI, Ophthalmology IODs by adding a similar constraint to the corresponding Modules.The issues with the Photometric Interpretations that are to be restricted from use for uncompressed formats are as follows:
YBR_RCT:
The defined conversion takes 3xN bit data, and produces 3 components that are N, N+1 & N+1 bits respectively. This is because the B & R components need to be signed, and can exceed the range of an N-bit signed number. For instance, pure red, in 8 bit form (R=255, G=0, B=0) transforms to (Y=63, CB= -63, CR = 192) , and there is no unambiguous way to represent both -63 and 192 in single bytes, unless we explicitly define the reconstructing algorithm to use an unsigned addition with explicitly defined/accepted wraparound. This is not a problem when encoded in JPEG 2000, which unlike the rules for DICOM uncompressed data, specifically allows differing bit depths for different components.As there is no means in DICOM to specify different numbers of bits for different samples, this situation could not be handled without expanding the number of bits for all samples, which would make no sense, and which would break the specificities for many of the
SOP classes which use such color data.
YBR_ICT:
In most respects this photometric interpretation is the same as YBR_FULL, but the CB & CR components do not have the +128 offset to bring then from the signed byte range to the unsigned range. It is therefore possible to encode and decode this data within the ranges allowed by 3x8 bit data, but only by making an assumption (unstated in the standard) that the 2 ndand 3 rdcomponents should be interpreted as signed data.
YBR_PARTIAL_420:
The definition in PS3.3 C.7.6.3.1.2 does not provide sufficient information to indicate how the 4 Y values, and the CB & CR should be interleaved - e.g. as YYYYBRYYYYBR or as alternating lines of YYBRYYBR and YYYY. Neither solution is really satisfactory (especially if row or column numbers were odd) , and as there is no significant use case for this format in uncompressed form, it is proposed that the format should be disallowed rather than generating a lot of work to define the form of "cositing".[Ed.Note. Should we actually forbid uncompressed YBR_FULL_422? ... it is very rarely seen and problematic when it is.][Ed. Note. Should we more aggressively restrict the values permitted for Planar Configuration of compressed data? Also could make consistent the placement/use of the "... is irrelevant" notes in MPEG-family TS]
[Ed.Note. Should we try and make the pattern for IOD and Modality-specific Module (MFSC, VL, WSI, US, MR, Ophthalmology) restrictions on Photometric Interpretation more generally applicable? I.e., we could add it to the Image Pixel Macro definition of Photometric Interpretation.]
|