ITK/Release 5/DICOM/Color: Difference between revisions

From KitwarePublic
< ITK‎ | Release 5‎ | DICOM
Jump to navigationJump to search
Line 36: Line 36:
|-
|-
! YBR_FULL_422 || style="background:orange" |RGB || style="background:orange" |RGB || YBR_FULL || ??Maybe RGB?
! YBR_FULL_422 || style="background:orange" |RGB || style="background:orange" |RGB || YBR_FULL || ??Maybe RGB?
|- style="background:silver"
! YBR_PARTIAL_422 ||  ||  ||  ||
|- style="background:silver"
! YBR_PARTIAL_420 ||  ||  ||  ||
|-
! YBR_ICT ||  ||  || RGB || style="background:red" |no J2K plugin
|-
! YBR_RCT ||  ||  || RGB || style="background:red" |no J2K plugin
|-
|}
Desired behavior of ITK 5.0:
{| border="1" style="text-align:center"
|- bgcolor="#abcdef"
! Photometric Interpretation !! JPEG !! TIFF !! GDCM !! DCMTK
|-
! MONOCHROME1 || style="background:lime" | MONOCHROME1 || style="background:orange" |MONOCHROME2 || style="background:lime" |MONOCHROME1 || style="background:lime" |?MONOCHROME1?
|- 
! MONOCHROME2 || style="background:lime" | MONOCHROME2 || style="background:lime" |MONOCHROME2 || style="background:lime" |MONOCHROME2 || style="background:lime" |MONOCHROME2
|-
! PALETTE_COLOR ||  style="background:lime" |PALETTE_COLOR || style="background:lime" | PALETTE_COLOR || style="background:orange" | Converted to RGB || style="background:orange" | ??
|-
! RGB || style="background:orange" |RGB || RGB|| RGB || ?RGB?
|- style="background:silver"
! HSV ||  ||  ||  ||
|- style="background:silver"
! ARGB ||  ||  || ||
|- style="background:silver"
! CMYK ||  ||  ||  ||
|-
! YBR_FULL || style="background:silver" |ITK 81 enforce sub-sampling|| ?? || RGB || ??
|-
! YBR_FULL_422 || style="background:orange" |RGB || style="background:orange" |RGB || RGB || ??Maybe RGB?
|- style="background:silver"
|- style="background:silver"
! YBR_PARTIAL_422 ||  ||  ||  ||  
! YBR_PARTIAL_422 ||  ||  ||  ||  

Revision as of 08:14, 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.

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 MONOCHROME1 MONOCHROME2 MONOCHROME1 ?MONOCHROME1?
MONOCHROME2 MONOCHROME2 MONOCHROME2 MONOCHROME2 MONOCHROME2
PALETTE_COLOR PALETTE_COLOR PALETTE_COLOR Converted to RGB ??
RGB RGB RGB RGB ?RGB?
HSV
ARGB
CMYK
YBR_FULL ITK 81 enforce sub-sampling ?? YBR_FULL ??
YBR_FULL_422 RGB RGB YBR_FULL ??Maybe RGB?
YBR_PARTIAL_422
YBR_PARTIAL_420
YBR_ICT RGB no J2K plugin
YBR_RCT RGB no J2K plugin


Desired behavior of ITK 5.0:

Photometric Interpretation JPEG TIFF GDCM DCMTK
MONOCHROME1 MONOCHROME1 MONOCHROME2 MONOCHROME1 ?MONOCHROME1?
MONOCHROME2 MONOCHROME2 MONOCHROME2 MONOCHROME2 MONOCHROME2
PALETTE_COLOR PALETTE_COLOR PALETTE_COLOR Converted to RGB ??
RGB RGB RGB RGB ?RGB?
HSV
ARGB
CMYK
YBR_FULL ITK 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