Color Space Transformations
From gdcm
Contents |
Converting uncompressed to compressed syntax
| Photometric Interpretation (Uncompressed syntax) | JPEG Lossless (eg. 1.2.840.10008.1.2.4.70) | J2K Lossless (1.2.840.10008.1.2.4.90) | JPEG Lossy (eg. 1.2.840.10008.1.2.4.50) | J2K Lossy (1.2.840.10008.1.2.4.91) |
|---|---|---|---|---|
| MONOCHROME1 | MONOCHROME1 | MONOCHROME1 | MONOCHROME1 | MONOCHROME1 |
| MONOCHROME2 | MONOCHROME2 | MONOCHROME2 | MONOCHROME2 | MONOCHROME2 |
| PALETTE_COLOR | PALETTE_COLOR | PALETTE_COLOR | Convert first to RGB | Convert first to RGB |
| RGB | RGB | YBR_RCT | ?? | YBR_ICT |
| HSV | ||||
| ARGB | ||||
| CMYK | ||||
| YBR_FULL | YBR_FULL | YBR_FULL | ?? | ?? |
| YBR_FULL_422 | ||||
| YBR_PARTIAL_422 | ||||
| YBR_PARTIAL_420 | ||||
| YBR_ICT (identical to YBR_FULL) | ||||
| YBR_RCT |
When a Photometric Interpretation is specified in red, it means this is not supposed to happen (does not make any sense).
When a Photometric Interpretation is specified in silver background, it means the Photometric Interpretation is retired.
Random notes:
- YBR_PARTIAL_422: make any sense in uncompressed ?
- YBR_PARTIAL_420: make any sense in uncompressed ?
- YBR_FULL_422: make any sense in uncompressed ?
- YBR_ICT: being actually exactly YBR_FULL, cannot -hopefully- be found in uncompressed syntax
- YBR_RCT: hopefully not in uncompressed (does not make sense)
- RGB cannot be used in JPEGLossless:Non-hierarchical-1stOrderPrediction => ??
- RGB cannot be used in JPEG2000 ( Lossless Only) => YBR_RCT
Confirmation of random notes, by Marco
See:
> 1. Input is RGB, what is the output photometric interpretation when > compressed in (true) lossless jpeg (eg. 1.2.840.10008.1.2.4.70). Since the only color space transformation that is truly lossless is the conversion to YBR_RCT, which is defined only for JPEG 2000, the output here is neccessarily RGB. The transformation from RGB to YBR_FULL is always lossy in integer space due to rounding errors. Also note that, although not formally forbidden, DICOM does not specify an encoding for the following photometric interpretations in uncompressed form (e.g. ordering of sub-sampled components, handling of images with an odd number of columns etc.), so these should never "happen": YBR_FULL_422, YBR_PARTIAL_422, YBR_PARTIAL_420. Also note that YBR_RCT cannot exist in uncompressed form by definition, since this encoding requires a different bit depth for the "Y" component than for the other components. > 2. Input is YBR_FULL, what is the output photometric interpretation > when compressed in (true) lossless jpeg 2000 (1.2.840.10008.1.2.4.90). Output is YBR_FULL. > For (2), the standard mandates the use of YBR_RCT, but that does not > make any sense as my input is YBR_FULL. Absolutely right. Conversion to YBR_RCT makes sense if and only if the input is RGB, since the transformation is a lossless approximation of the RGB to YCbCr transformation and thus meant to provide a better de-coupling of color components, which would not work with YBR_FULL input (and would most probably degrade compression performance).
External links
- http://www.medicalconnections.co.uk/wiki/Photometric_Interpretations
- http://groups.google.com/group/comp.protocols.dicom/browse_thread/thread/a9e118fbbf6dcc9f
- http://groups.google.com/group/comp.protocols.dicom/browse_thread/thread/1190189387c1702c
- http://groups.google.com/group/comp.protocols.dicom/browse_thread/thread/445f452c17095486
- http://groups.google.com/group/comp.protocols.dicom/browse_thread/thread/b1138b687ece295b
Thread on comp.protocols.dicom:
