ITK/Release 5/DICOM/Color: Difference between revisions
| Line 8: | Line 8: | ||
This behavior was considered ok, as long as the image was not directly loaded in viz application such as Slicer, where suddenly the image would appears with a weird color scheme. | This behavior was considered ok, as long as the image was not directly loaded in viz application such as Slicer, where suddenly the image would appears with a weird color scheme. | ||
== Notation == | |||
# JPEG refers to the subset of ITU-T T.81, ISO/IEC IS 10918-1 (lossy 8bits) | |||
# JPEG 2000 refers to ITU-T T.800, ISO/IEC IS 15444-1 | |||
== ITK 5.x == | == ITK 5.x == | ||
Revision as of 08:27, 11 October 2019
Multiple Components in DICOM
ITK 5.0
DICOM standard allow storing of image with more than one components. As of today, only 1 or 3 components are considered valid DICOM SOP Class instances (for all IODs).
By design the itk::GDCMImageIO was designed and implemented so that an input YBR_FULL image would be loaded as such (no implicit conversion to RGB was done). The main reason for that is that ITK is a processing toolkit, so quantitative analysis is supposed to be done on the best possible pixel representation. Since conversion from integer YBR_FULL to integer RGB colorspace is a lossy operation (truncation in floating point representation), the conversion has never been implemented.
This behavior was considered ok, as long as the image was not directly loaded in viz application such as Slicer, where suddenly the image would appears with a weird color scheme.
Notation
- JPEG refers to the subset of ITU-T T.81, ISO/IEC IS 10918-1 (lossy 8bits)
- JPEG 2000 refers to ITU-T T.800, ISO/IEC IS 15444-1
ITK 5.x
The behavior for YBR_FULL vs RGB color model has been discussed and it seems consensus would be to convert to RGB always. Since DICOM, JPEG and TIFF can be somewhat relates for this matter, we should strive to keep the behavior consistent.
Current behavior of ITK 5.0:
| Photometric Interpretation | JPEG | TIFF | GDCM | DCMTK |
|---|---|---|---|---|
| MONOCHROME1 | X | MONOCHROME2 (aka min-is-black) | MONOCHROME1 | ?MONOCHROME1? |
| MONOCHROME2 | MONOCHROME2 | MONOCHROME2 (aka min-is-black) | MONOCHROME2 | MONOCHROME2 |
| PALETTE_COLOR | X | RGB (??) | Converted to RGB | ?Converted to RGB? (need to check compressed LUT) |
| RGB | RGB | RGB | RGB | ?RGB? |
| HSV | ||||
| ARGB | ||||
| CMYK | ||||
| YBR_FULL | ITU 81 enforce sub-sampling | ?? | YBR_FULL | ?? |
| YBR_FULL_422 | RGB | RGB | YBR_FULL | ??Maybe RGB? |
| YBR_PARTIAL_422 | ||||
| YBR_PARTIAL_420 | ||||
| YBR_ICT | ITU 81 does not support this colorspace | ?? | RGB | no J2K plugin |
| YBR_RCT | ITU 81 does not support this colorspace | ?? | RGB | no J2K plugin |
Desired behavior of ITK 5.0:
| Photometric Interpretation | JPEG | TIFF | GDCM | DCMTK |
|---|---|---|---|---|
| MONOCHROME1 | X | MONOCHROME2 (aka min-is-black) | MONOCHROME1 | ?MONOCHROME1? |
| MONOCHROME2 | MONOCHROME2 | MONOCHROME2 (aka min-is-black) | MONOCHROME2 | MONOCHROME2 |
| PALETTE_COLOR | X | RGB | Converted to RGB | ?? |
| RGB | RGB | RGB | RGB | ?RGB? |
| HSV | ||||
| ARGB | ||||
| CMYK | ||||
| YBR_FULL | ITU 81 enforce sub-sampling | ?? | RGB | ?? |
| YBR_FULL_422 | RGB | RGB | RGB | ??Maybe RGB? |
| YBR_PARTIAL_422 | ||||
| YBR_PARTIAL_420 | ||||
| YBR_ICT | RGB | no J2K plugin | ||
| YBR_RCT | RGB | no J2K plugin |
Summary:
For Viz people it is important that:
- MONOCHROME1 (min-is-white) is converted to MONOCHROME2 (min-is-black)
- YBR_FULL / YBR_FULL_422 are converted to RGB
The requirements for quantitative analysis may be different, please list reqs here:
- ? Extract Luminance out of YBR ?
- ? Need MONOCHROME1 native support, because <fill reason ??>
- ? Is there a need to manipulated native palette data ? I doubt so
