https://public.kitware.com/Wiki/api.php?action=feedcontributions&user=Mathieu&feedformat=atomKitwarePublic - User contributions [en]2024-03-29T14:44:29ZUser contributionsMediaWiki 1.38.6https://public.kitware.com/Wiki/index.php?title=ITK/Release_5/DICOM/Color&diff=63965ITK/Release 5/DICOM/Color2019-10-11T08:53:46Z<p>Mathieu: /* Data */</p>
<hr />
<div>= Multiple Components in DICOM =<br />
<br />
== ITK 5.0 ==<br />
<br />
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).<br />
<br />
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.<br />
<br />
As side note MONOCHROME1 color space is not converted to MONOCHROME2 (itk::GDCMImageIO / ITK 5.0)<br />
<br />
== Issue ==<br />
<br />
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. (original bug report from Mihail Isakov)<br />
<br />
== Notation ==<br />
<br />
# JPEG refers to the subset of ITU-T T.81, ISO/IEC IS 10918-1 (lossy 8bits)<br />
# JPEG 2000 refers to ITU-T T.800, ISO/IEC IS 15444-1<br />
<br />
== ITK 5.x ==<br />
<br />
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.<br />
<br />
Current behavior of ITK 5.0:<br />
<br />
{| border="1" style="text-align:center"<br />
|- bgcolor="#abcdef"<br />
! Photometric Interpretation !! JPEG !! TIFF !! GDCM !! DCMTK<br />
|-<br />
! MONOCHROME1 || style="background:silver" | X || style="background:orange" |MONOCHROME2 (aka min-is-black) || style="background:lime" |MONOCHROME1 || style="background:lime" |?MONOCHROME1?<br />
|- <br />
! MONOCHROME2 || style="background:lime" | MONOCHROME2 || style="background:lime" |MONOCHROME2 (aka min-is-black) || style="background:lime" |MONOCHROME2 || style="background:lime" |MONOCHROME2<br />
|-<br />
! PALETTE COLOR || style="background:silver" |X || style="background:orange" | RGB (??) || style="background:orange" | Converted to RGB || style="background:orange" | ?Converted to RGB? (need to check compressed LUT)<br />
|-<br />
! RGB || style="background:orange" |RGB || RGB|| RGB || ?RGB?<br />
|- style="background:silver"<br />
! HSV || || || || <br />
|- style="background:silver"<br />
! ARGB || || || || <br />
|- style="background:silver"<br />
! CMYK || || || || <br />
|-<br />
! YBR_FULL || style="background:silver" |ITU 81 enforce sub-sampling|| ?? || YBR_FULL || ??<br />
|-<br />
! YBR_FULL_422 || style="background:orange" |RGB || style="background:orange" |RGB || YBR_FULL || ??Maybe RGB?<br />
|- style="background:silver"<br />
! YBR_PARTIAL_422 || || || || <br />
|- style="background:silver"<br />
! YBR_PARTIAL_420 || || || || <br />
|-<br />
! YBR_ICT || style="background:silver" |ITU 81 does not support this colorspace || ?? || style="background:orange" |RGB || style="background:red" |no J2K plugin<br />
|-<br />
! YBR_RCT || style="background:silver" |ITU 81 does not support this colorspace || ?? || RGB || style="background:red" |no J2K plugin<br />
|-<br />
|}<br />
<br />
<br />
Desired behavior of ITK 5.0:<br />
<br />
{| border="1" style="text-align:center"<br />
|- bgcolor="#abcdef"<br />
! Photometric Interpretation !! JPEG !! TIFF !! GDCM !! DCMTK<br />
|-<br />
! MONOCHROME1 || style="background:silver" | X || style="background:orange" |MONOCHROME2 (aka min-is-black)|| style="background:orange" |MONOCHROME2 || style="background:orange" |MONOCHROME2<br />
|- <br />
! MONOCHROME2 || style="background:lime" | MONOCHROME2 || style="background:lime" |MONOCHROME2 (aka min-is-black)|| style="background:lime" |MONOCHROME2 || style="background:lime" |MONOCHROME2<br />
|-<br />
! PALETTE COLOR || style="background:silver" | X || style="background:orange" | RGB || style="background:orange" | Converted to RGB || style="background:orange" | RGB<br />
|-<br />
! RGB || style="background:orange" |RGB || RGB|| RGB || ?RGB?<br />
|- style="background:silver"<br />
! HSV || || || || <br />
|- style="background:silver"<br />
! ARGB || || || || <br />
|- style="background:silver"<br />
! CMYK || || || || <br />
|-<br />
! YBR_FULL || style="background:silver" |ITU 81 enforce sub-sampling|| ?? || style="background:orange" |RGB || style="background:orange" |RGB<br />
|-<br />
! YBR_FULL_422 || style="background:orange" |RGB || style="background:orange" |RGB || style="background:orange" |RGB || style="background:orange" |RGB<br />
|- style="background:silver"<br />
! YBR_PARTIAL_422 || || || || <br />
|- style="background:silver"<br />
! YBR_PARTIAL_420 || || || || <br />
|-<br />
! YBR_ICT || || || style="background:orange" |RGB || style="background:red" |no J2K plugin<br />
|-<br />
! YBR_RCT || || || RGB || style="background:red" |no J2K plugin<br />
|-<br />
|}<br />
<br />
== Discussion ==<br />
<br />
Participants:<br />
# Mathieu Malaterre<br />
# Mihail Isakov<br />
<br />
For visualization people it is important that:<br />
<br />
# MONOCHROME1 (min-is-white) is converted to MONOCHROME2 (min-is-black) <br />
# YBR_FULL / YBR_FULL_422 are converted to RGB<br />
<br />
The requirements for quantitative analysis may be different, please list reqs here:<br />
<br />
#? Extract Luminance out of YBR ?<br />
# ? Need MONOCHROME1 native support, because <fill reason ??><br />
# ? Is there a need to manipulated native palette data ? I doubt so<br />
<br />
== Data ==<br />
<br />
# JPEG 8 bits mono2<br />
# JPEG 8 bits YBR_422<br />
# JPEG 8 bits RGB<br />
# TIFF mono1 min-is-white<br />
# TIFF mono2 min-is-black<br />
# TIFF YBR_422<br />
# TIFF RGB<br />
# DICOM mono1 min-is-white<br />
# DICOM mono2 min-is-black<br />
# DICOM YBR<br />
# [https://sourceforge.net/p/gdcm/gdcmdata/ci/master/tree/US-YBR_FULL_422-EVRLE.dcm| DICOM YBR_422]<br />
# [https://sourceforge.net/p/gdcm/gdcmdata/ci/master/tree/US-GE-4AICL142.dcm| DICOM JPEG/YBR_422]<br />
# DICOM RGB<br />
# DICOM YBR_RCT<br />
# DICOM YBR_ICT<br />
<br />
== References ==<br />
<br />
* http://dicom.nema.org/medical/dicom/current/output/chtml/part03/sect_C.7.6.3.html#sect_C.7.6.3.1.2<br />
* http://gdcm.sourceforge.net/wiki/index.php/Color_Space_Transformations</div>Mathieuhttps://public.kitware.com/Wiki/index.php?title=ITK/Release_5/DICOM/Color&diff=63964ITK/Release 5/DICOM/Color2019-10-11T08:52:51Z<p>Mathieu: /* Data */</p>
<hr />
<div>= Multiple Components in DICOM =<br />
<br />
== ITK 5.0 ==<br />
<br />
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).<br />
<br />
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.<br />
<br />
As side note MONOCHROME1 color space is not converted to MONOCHROME2 (itk::GDCMImageIO / ITK 5.0)<br />
<br />
== Issue ==<br />
<br />
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. (original bug report from Mihail Isakov)<br />
<br />
== Notation ==<br />
<br />
# JPEG refers to the subset of ITU-T T.81, ISO/IEC IS 10918-1 (lossy 8bits)<br />
# JPEG 2000 refers to ITU-T T.800, ISO/IEC IS 15444-1<br />
<br />
== ITK 5.x ==<br />
<br />
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.<br />
<br />
Current behavior of ITK 5.0:<br />
<br />
{| border="1" style="text-align:center"<br />
|- bgcolor="#abcdef"<br />
! Photometric Interpretation !! JPEG !! TIFF !! GDCM !! DCMTK<br />
|-<br />
! MONOCHROME1 || style="background:silver" | X || style="background:orange" |MONOCHROME2 (aka min-is-black) || style="background:lime" |MONOCHROME1 || style="background:lime" |?MONOCHROME1?<br />
|- <br />
! MONOCHROME2 || style="background:lime" | MONOCHROME2 || style="background:lime" |MONOCHROME2 (aka min-is-black) || style="background:lime" |MONOCHROME2 || style="background:lime" |MONOCHROME2<br />
|-<br />
! PALETTE COLOR || style="background:silver" |X || style="background:orange" | RGB (??) || style="background:orange" | Converted to RGB || style="background:orange" | ?Converted to RGB? (need to check compressed LUT)<br />
|-<br />
! RGB || style="background:orange" |RGB || RGB|| RGB || ?RGB?<br />
|- style="background:silver"<br />
! HSV || || || || <br />
|- style="background:silver"<br />
! ARGB || || || || <br />
|- style="background:silver"<br />
! CMYK || || || || <br />
|-<br />
! YBR_FULL || style="background:silver" |ITU 81 enforce sub-sampling|| ?? || YBR_FULL || ??<br />
|-<br />
! YBR_FULL_422 || style="background:orange" |RGB || style="background:orange" |RGB || YBR_FULL || ??Maybe RGB?<br />
|- style="background:silver"<br />
! YBR_PARTIAL_422 || || || || <br />
|- style="background:silver"<br />
! YBR_PARTIAL_420 || || || || <br />
|-<br />
! YBR_ICT || style="background:silver" |ITU 81 does not support this colorspace || ?? || style="background:orange" |RGB || style="background:red" |no J2K plugin<br />
|-<br />
! YBR_RCT || style="background:silver" |ITU 81 does not support this colorspace || ?? || RGB || style="background:red" |no J2K plugin<br />
|-<br />
|}<br />
<br />
<br />
Desired behavior of ITK 5.0:<br />
<br />
{| border="1" style="text-align:center"<br />
|- bgcolor="#abcdef"<br />
! Photometric Interpretation !! JPEG !! TIFF !! GDCM !! DCMTK<br />
|-<br />
! MONOCHROME1 || style="background:silver" | X || style="background:orange" |MONOCHROME2 (aka min-is-black)|| style="background:orange" |MONOCHROME2 || style="background:orange" |MONOCHROME2<br />
|- <br />
! MONOCHROME2 || style="background:lime" | MONOCHROME2 || style="background:lime" |MONOCHROME2 (aka min-is-black)|| style="background:lime" |MONOCHROME2 || style="background:lime" |MONOCHROME2<br />
|-<br />
! PALETTE COLOR || style="background:silver" | X || style="background:orange" | RGB || style="background:orange" | Converted to RGB || style="background:orange" | RGB<br />
|-<br />
! RGB || style="background:orange" |RGB || RGB|| RGB || ?RGB?<br />
|- style="background:silver"<br />
! HSV || || || || <br />
|- style="background:silver"<br />
! ARGB || || || || <br />
|- style="background:silver"<br />
! CMYK || || || || <br />
|-<br />
! YBR_FULL || style="background:silver" |ITU 81 enforce sub-sampling|| ?? || style="background:orange" |RGB || style="background:orange" |RGB<br />
|-<br />
! YBR_FULL_422 || style="background:orange" |RGB || style="background:orange" |RGB || style="background:orange" |RGB || style="background:orange" |RGB<br />
|- style="background:silver"<br />
! YBR_PARTIAL_422 || || || || <br />
|- style="background:silver"<br />
! YBR_PARTIAL_420 || || || || <br />
|-<br />
! YBR_ICT || || || style="background:orange" |RGB || style="background:red" |no J2K plugin<br />
|-<br />
! YBR_RCT || || || RGB || style="background:red" |no J2K plugin<br />
|-<br />
|}<br />
<br />
== Discussion ==<br />
<br />
Participants:<br />
# Mathieu Malaterre<br />
# Mihail Isakov<br />
<br />
For visualization people it is important that:<br />
<br />
# MONOCHROME1 (min-is-white) is converted to MONOCHROME2 (min-is-black) <br />
# YBR_FULL / YBR_FULL_422 are converted to RGB<br />
<br />
The requirements for quantitative analysis may be different, please list reqs here:<br />
<br />
#? Extract Luminance out of YBR ?<br />
# ? Need MONOCHROME1 native support, because <fill reason ??><br />
# ? Is there a need to manipulated native palette data ? I doubt so<br />
<br />
== Data ==<br />
<br />
# JPEG 8 bits mono2<br />
# JPEG 8 bits YBR_422<br />
# JPEG 8 bits RGB<br />
# TIFF mono1 min-is-white<br />
# TIFF mono2 min-is-black<br />
# TIFF YBR_422<br />
# TIFF RGB<br />
# DICOM mono1 min-is-white<br />
# DICOM mono2 min-is-black<br />
# DICOM YBR<br />
# [https://sourceforge.net/p/gdcm/gdcmdata/ci/master/tree/US-YBR_FULL_422-EVRLE.dcm|DICOM YBR_422]<br />
# [https://sourceforge.net/p/gdcm/gdcmdata/ci/master/tree/US-GE-4AICL142.dcm|DICOM JPEG/YBR_422]<br />
# DICOM RGB<br />
# DICOM YBR_RCT<br />
# DICOM YBR_ICT<br />
<br />
== References ==<br />
<br />
* http://dicom.nema.org/medical/dicom/current/output/chtml/part03/sect_C.7.6.3.html#sect_C.7.6.3.1.2<br />
* http://gdcm.sourceforge.net/wiki/index.php/Color_Space_Transformations</div>Mathieuhttps://public.kitware.com/Wiki/index.php?title=ITK/Release_5/DICOM/Color&diff=63963ITK/Release 5/DICOM/Color2019-10-11T08:52:17Z<p>Mathieu: /* References */</p>
<hr />
<div>= Multiple Components in DICOM =<br />
<br />
== ITK 5.0 ==<br />
<br />
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).<br />
<br />
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.<br />
<br />
As side note MONOCHROME1 color space is not converted to MONOCHROME2 (itk::GDCMImageIO / ITK 5.0)<br />
<br />
== Issue ==<br />
<br />
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. (original bug report from Mihail Isakov)<br />
<br />
== Notation ==<br />
<br />
# JPEG refers to the subset of ITU-T T.81, ISO/IEC IS 10918-1 (lossy 8bits)<br />
# JPEG 2000 refers to ITU-T T.800, ISO/IEC IS 15444-1<br />
<br />
== ITK 5.x ==<br />
<br />
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.<br />
<br />
Current behavior of ITK 5.0:<br />
<br />
{| border="1" style="text-align:center"<br />
|- bgcolor="#abcdef"<br />
! Photometric Interpretation !! JPEG !! TIFF !! GDCM !! DCMTK<br />
|-<br />
! MONOCHROME1 || style="background:silver" | X || style="background:orange" |MONOCHROME2 (aka min-is-black) || style="background:lime" |MONOCHROME1 || style="background:lime" |?MONOCHROME1?<br />
|- <br />
! MONOCHROME2 || style="background:lime" | MONOCHROME2 || style="background:lime" |MONOCHROME2 (aka min-is-black) || style="background:lime" |MONOCHROME2 || style="background:lime" |MONOCHROME2<br />
|-<br />
! PALETTE COLOR || style="background:silver" |X || style="background:orange" | RGB (??) || style="background:orange" | Converted to RGB || style="background:orange" | ?Converted to RGB? (need to check compressed LUT)<br />
|-<br />
! RGB || style="background:orange" |RGB || RGB|| RGB || ?RGB?<br />
|- style="background:silver"<br />
! HSV || || || || <br />
|- style="background:silver"<br />
! ARGB || || || || <br />
|- style="background:silver"<br />
! CMYK || || || || <br />
|-<br />
! YBR_FULL || style="background:silver" |ITU 81 enforce sub-sampling|| ?? || YBR_FULL || ??<br />
|-<br />
! YBR_FULL_422 || style="background:orange" |RGB || style="background:orange" |RGB || YBR_FULL || ??Maybe RGB?<br />
|- style="background:silver"<br />
! YBR_PARTIAL_422 || || || || <br />
|- style="background:silver"<br />
! YBR_PARTIAL_420 || || || || <br />
|-<br />
! YBR_ICT || style="background:silver" |ITU 81 does not support this colorspace || ?? || style="background:orange" |RGB || style="background:red" |no J2K plugin<br />
|-<br />
! YBR_RCT || style="background:silver" |ITU 81 does not support this colorspace || ?? || RGB || style="background:red" |no J2K plugin<br />
|-<br />
|}<br />
<br />
<br />
Desired behavior of ITK 5.0:<br />
<br />
{| border="1" style="text-align:center"<br />
|- bgcolor="#abcdef"<br />
! Photometric Interpretation !! JPEG !! TIFF !! GDCM !! DCMTK<br />
|-<br />
! MONOCHROME1 || style="background:silver" | X || style="background:orange" |MONOCHROME2 (aka min-is-black)|| style="background:orange" |MONOCHROME2 || style="background:orange" |MONOCHROME2<br />
|- <br />
! MONOCHROME2 || style="background:lime" | MONOCHROME2 || style="background:lime" |MONOCHROME2 (aka min-is-black)|| style="background:lime" |MONOCHROME2 || style="background:lime" |MONOCHROME2<br />
|-<br />
! PALETTE COLOR || style="background:silver" | X || style="background:orange" | RGB || style="background:orange" | Converted to RGB || style="background:orange" | RGB<br />
|-<br />
! RGB || style="background:orange" |RGB || RGB|| RGB || ?RGB?<br />
|- style="background:silver"<br />
! HSV || || || || <br />
|- style="background:silver"<br />
! ARGB || || || || <br />
|- style="background:silver"<br />
! CMYK || || || || <br />
|-<br />
! YBR_FULL || style="background:silver" |ITU 81 enforce sub-sampling|| ?? || style="background:orange" |RGB || style="background:orange" |RGB<br />
|-<br />
! YBR_FULL_422 || style="background:orange" |RGB || style="background:orange" |RGB || style="background:orange" |RGB || style="background:orange" |RGB<br />
|- style="background:silver"<br />
! YBR_PARTIAL_422 || || || || <br />
|- style="background:silver"<br />
! YBR_PARTIAL_420 || || || || <br />
|-<br />
! YBR_ICT || || || style="background:orange" |RGB || style="background:red" |no J2K plugin<br />
|-<br />
! YBR_RCT || || || RGB || style="background:red" |no J2K plugin<br />
|-<br />
|}<br />
<br />
== Discussion ==<br />
<br />
Participants:<br />
# Mathieu Malaterre<br />
# Mihail Isakov<br />
<br />
For visualization people it is important that:<br />
<br />
# MONOCHROME1 (min-is-white) is converted to MONOCHROME2 (min-is-black) <br />
# YBR_FULL / YBR_FULL_422 are converted to RGB<br />
<br />
The requirements for quantitative analysis may be different, please list reqs here:<br />
<br />
#? Extract Luminance out of YBR ?<br />
# ? Need MONOCHROME1 native support, because <fill reason ??><br />
# ? Is there a need to manipulated native palette data ? I doubt so<br />
<br />
== Data ==<br />
<br />
# JPEG 8 bits mono2<br />
# JPEG 8 bits YBR_422<br />
# JPEG 8 bits RGB<br />
# TIFF mono1 min-is-white<br />
# TIFF mono2 min-is-black<br />
# TIFF YBR_422<br />
# TIFF RGB<br />
# DICOM mono1 min-is-white<br />
# DICOM mono2 min-is-black<br />
# DICOM YBR<br />
# [[https://sourceforge.net/p/gdcm/gdcmdata/ci/master/tree/US-YBR_FULL_422-EVRLE.dcm|DICOM YBR_422]]<br />
# [[https://sourceforge.net/p/gdcm/gdcmdata/ci/master/tree/US-GE-4AICL142.dcm|DICOM JPEG/YBR_422]]<br />
# DICOM RGB<br />
<br />
== References ==<br />
<br />
* http://dicom.nema.org/medical/dicom/current/output/chtml/part03/sect_C.7.6.3.html#sect_C.7.6.3.1.2<br />
* http://gdcm.sourceforge.net/wiki/index.php/Color_Space_Transformations</div>Mathieuhttps://public.kitware.com/Wiki/index.php?title=ITK/Release_5/DICOM/Color&diff=63962ITK/Release 5/DICOM/Color2019-10-11T08:43:58Z<p>Mathieu: /* ITK 5.x */</p>
<hr />
<div>= Multiple Components in DICOM =<br />
<br />
== ITK 5.0 ==<br />
<br />
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).<br />
<br />
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.<br />
<br />
As side note MONOCHROME1 color space is not converted to MONOCHROME2 (itk::GDCMImageIO / ITK 5.0)<br />
<br />
== Issue ==<br />
<br />
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. (original bug report from Mihail Isakov)<br />
<br />
== Notation ==<br />
<br />
# JPEG refers to the subset of ITU-T T.81, ISO/IEC IS 10918-1 (lossy 8bits)<br />
# JPEG 2000 refers to ITU-T T.800, ISO/IEC IS 15444-1<br />
<br />
== ITK 5.x ==<br />
<br />
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.<br />
<br />
Current behavior of ITK 5.0:<br />
<br />
{| border="1" style="text-align:center"<br />
|- bgcolor="#abcdef"<br />
! Photometric Interpretation !! JPEG !! TIFF !! GDCM !! DCMTK<br />
|-<br />
! MONOCHROME1 || style="background:silver" | X || style="background:orange" |MONOCHROME2 (aka min-is-black) || style="background:lime" |MONOCHROME1 || style="background:lime" |?MONOCHROME1?<br />
|- <br />
! MONOCHROME2 || style="background:lime" | MONOCHROME2 || style="background:lime" |MONOCHROME2 (aka min-is-black) || style="background:lime" |MONOCHROME2 || style="background:lime" |MONOCHROME2<br />
|-<br />
! PALETTE COLOR || style="background:silver" |X || style="background:orange" | RGB (??) || style="background:orange" | Converted to RGB || style="background:orange" | ?Converted to RGB? (need to check compressed LUT)<br />
|-<br />
! RGB || style="background:orange" |RGB || RGB|| RGB || ?RGB?<br />
|- style="background:silver"<br />
! HSV || || || || <br />
|- style="background:silver"<br />
! ARGB || || || || <br />
|- style="background:silver"<br />
! CMYK || || || || <br />
|-<br />
! YBR_FULL || style="background:silver" |ITU 81 enforce sub-sampling|| ?? || YBR_FULL || ??<br />
|-<br />
! YBR_FULL_422 || style="background:orange" |RGB || style="background:orange" |RGB || YBR_FULL || ??Maybe RGB?<br />
|- style="background:silver"<br />
! YBR_PARTIAL_422 || || || || <br />
|- style="background:silver"<br />
! YBR_PARTIAL_420 || || || || <br />
|-<br />
! YBR_ICT || style="background:silver" |ITU 81 does not support this colorspace || ?? || style="background:orange" |RGB || style="background:red" |no J2K plugin<br />
|-<br />
! YBR_RCT || style="background:silver" |ITU 81 does not support this colorspace || ?? || RGB || style="background:red" |no J2K plugin<br />
|-<br />
|}<br />
<br />
<br />
Desired behavior of ITK 5.0:<br />
<br />
{| border="1" style="text-align:center"<br />
|- bgcolor="#abcdef"<br />
! Photometric Interpretation !! JPEG !! TIFF !! GDCM !! DCMTK<br />
|-<br />
! MONOCHROME1 || style="background:silver" | X || style="background:orange" |MONOCHROME2 (aka min-is-black)|| style="background:orange" |MONOCHROME2 || style="background:orange" |MONOCHROME2<br />
|- <br />
! MONOCHROME2 || style="background:lime" | MONOCHROME2 || style="background:lime" |MONOCHROME2 (aka min-is-black)|| style="background:lime" |MONOCHROME2 || style="background:lime" |MONOCHROME2<br />
|-<br />
! PALETTE COLOR || style="background:silver" | X || style="background:orange" | RGB || style="background:orange" | Converted to RGB || style="background:orange" | RGB<br />
|-<br />
! RGB || style="background:orange" |RGB || RGB|| RGB || ?RGB?<br />
|- style="background:silver"<br />
! HSV || || || || <br />
|- style="background:silver"<br />
! ARGB || || || || <br />
|- style="background:silver"<br />
! CMYK || || || || <br />
|-<br />
! YBR_FULL || style="background:silver" |ITU 81 enforce sub-sampling|| ?? || style="background:orange" |RGB || style="background:orange" |RGB<br />
|-<br />
! YBR_FULL_422 || style="background:orange" |RGB || style="background:orange" |RGB || style="background:orange" |RGB || style="background:orange" |RGB<br />
|- style="background:silver"<br />
! YBR_PARTIAL_422 || || || || <br />
|- style="background:silver"<br />
! YBR_PARTIAL_420 || || || || <br />
|-<br />
! YBR_ICT || || || style="background:orange" |RGB || style="background:red" |no J2K plugin<br />
|-<br />
! YBR_RCT || || || RGB || style="background:red" |no J2K plugin<br />
|-<br />
|}<br />
<br />
== Discussion ==<br />
<br />
Participants:<br />
# Mathieu Malaterre<br />
# Mihail Isakov<br />
<br />
For visualization people it is important that:<br />
<br />
# MONOCHROME1 (min-is-white) is converted to MONOCHROME2 (min-is-black) <br />
# YBR_FULL / YBR_FULL_422 are converted to RGB<br />
<br />
The requirements for quantitative analysis may be different, please list reqs here:<br />
<br />
#? Extract Luminance out of YBR ?<br />
# ? Need MONOCHROME1 native support, because <fill reason ??><br />
# ? Is there a need to manipulated native palette data ? I doubt so<br />
<br />
== References ==<br />
<br />
* http://dicom.nema.org/medical/dicom/current/output/chtml/part03/sect_C.7.6.3.html#sect_C.7.6.3.1.2<br />
* http://gdcm.sourceforge.net/wiki/index.php/Color_Space_Transformations</div>Mathieuhttps://public.kitware.com/Wiki/index.php?title=ITK/Release_5/DICOM/Color&diff=63961ITK/Release 5/DICOM/Color2019-10-11T08:43:31Z<p>Mathieu: /* ITK 5.x */</p>
<hr />
<div>= Multiple Components in DICOM =<br />
<br />
== ITK 5.0 ==<br />
<br />
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).<br />
<br />
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.<br />
<br />
As side note MONOCHROME1 color space is not converted to MONOCHROME2 (itk::GDCMImageIO / ITK 5.0)<br />
<br />
== Issue ==<br />
<br />
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. (original bug report from Mihail Isakov)<br />
<br />
== Notation ==<br />
<br />
# JPEG refers to the subset of ITU-T T.81, ISO/IEC IS 10918-1 (lossy 8bits)<br />
# JPEG 2000 refers to ITU-T T.800, ISO/IEC IS 15444-1<br />
<br />
== ITK 5.x ==<br />
<br />
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.<br />
<br />
Current behavior of ITK 5.0:<br />
<br />
{| border="1" style="text-align:center"<br />
|- bgcolor="#abcdef"<br />
! Photometric Interpretation !! JPEG !! TIFF !! GDCM !! DCMTK<br />
|-<br />
! MONOCHROME1 || style="background:silver" | X || style="background:orange" |MONOCHROME2 (aka min-is-black) || style="background:lime" |MONOCHROME1 || style="background:lime" |?MONOCHROME1?<br />
|- <br />
! MONOCHROME2 || style="background:lime" | MONOCHROME2 || style="background:lime" |MONOCHROME2 (aka min-is-black) || style="background:lime" |MONOCHROME2 || style="background:lime" |MONOCHROME2<br />
|-<br />
! PALETTE COLOR || style="background:silver" |X || style="background:orange" | RGB (??) || style="background:orange" | Converted to RGB || style="background:orange" | ?Converted to RGB? (need to check compressed LUT)<br />
|-<br />
! RGB || style="background:orange" |RGB || RGB|| RGB || ?RGB?<br />
|- style="background:silver"<br />
! HSV || || || || <br />
|- style="background:silver"<br />
! ARGB || || || || <br />
|- style="background:silver"<br />
! CMYK || || || || <br />
|-<br />
! YBR_FULL || style="background:silver" |ITU 81 enforce sub-sampling|| ?? || YBR_FULL || ??<br />
|-<br />
! YBR_FULL_422 || style="background:orange" |RGB || style="background:orange" |RGB || YBR_FULL || ??Maybe RGB?<br />
|- style="background:silver"<br />
! YBR_PARTIAL_422 || || || || <br />
|- style="background:silver"<br />
! YBR_PARTIAL_420 || || || || <br />
|-<br />
! YBR_ICT || style="background:silver" |ITU 81 does not support this colorspace || ?? || RGB || style="background:red" |no J2K plugin<br />
|-<br />
! YBR_RCT || style="background:silver" |ITU 81 does not support this colorspace || ?? || RGB || style="background:red" |no J2K plugin<br />
|-<br />
|}<br />
<br />
<br />
Desired behavior of ITK 5.0:<br />
<br />
{| border="1" style="text-align:center"<br />
|- bgcolor="#abcdef"<br />
! Photometric Interpretation !! JPEG !! TIFF !! GDCM !! DCMTK<br />
|-<br />
! MONOCHROME1 || style="background:silver" | X || style="background:orange" |MONOCHROME2 (aka min-is-black)|| style="background:orange" |MONOCHROME2 || style="background:orange" |MONOCHROME2<br />
|- <br />
! MONOCHROME2 || style="background:lime" | MONOCHROME2 || style="background:lime" |MONOCHROME2 (aka min-is-black)|| style="background:lime" |MONOCHROME2 || style="background:lime" |MONOCHROME2<br />
|-<br />
! PALETTE COLOR || style="background:silver" | X || style="background:orange" | RGB || style="background:orange" | Converted to RGB || style="background:orange" | RGB<br />
|-<br />
! RGB || style="background:orange" |RGB || RGB|| RGB || ?RGB?<br />
|- style="background:silver"<br />
! HSV || || || || <br />
|- style="background:silver"<br />
! ARGB || || || || <br />
|- style="background:silver"<br />
! CMYK || || || || <br />
|-<br />
! YBR_FULL || style="background:silver" |ITU 81 enforce sub-sampling|| ?? || style="background:orange" |RGB || style="background:orange" |RGB<br />
|-<br />
! YBR_FULL_422 || style="background:orange" |RGB || style="background:orange" |RGB || style="background:orange" |RGB || style="background:orange" |RGB<br />
|- style="background:silver"<br />
! YBR_PARTIAL_422 || || || || <br />
|- style="background:silver"<br />
! YBR_PARTIAL_420 || || || || <br />
|-<br />
! YBR_ICT || || || RGB || style="background:red" |no J2K plugin<br />
|-<br />
! YBR_RCT || || || RGB || style="background:red" |no J2K plugin<br />
|-<br />
|}<br />
<br />
== Discussion ==<br />
<br />
Participants:<br />
# Mathieu Malaterre<br />
# Mihail Isakov<br />
<br />
For visualization people it is important that:<br />
<br />
# MONOCHROME1 (min-is-white) is converted to MONOCHROME2 (min-is-black) <br />
# YBR_FULL / YBR_FULL_422 are converted to RGB<br />
<br />
The requirements for quantitative analysis may be different, please list reqs here:<br />
<br />
#? Extract Luminance out of YBR ?<br />
# ? Need MONOCHROME1 native support, because <fill reason ??><br />
# ? Is there a need to manipulated native palette data ? I doubt so<br />
<br />
== References ==<br />
<br />
* http://dicom.nema.org/medical/dicom/current/output/chtml/part03/sect_C.7.6.3.html#sect_C.7.6.3.1.2<br />
* http://gdcm.sourceforge.net/wiki/index.php/Color_Space_Transformations</div>Mathieuhttps://public.kitware.com/Wiki/index.php?title=ITK/Release_5/DICOM/Color&diff=63960ITK/Release 5/DICOM/Color2019-10-11T08:43:03Z<p>Mathieu: /* ITK 5.x */</p>
<hr />
<div>= Multiple Components in DICOM =<br />
<br />
== ITK 5.0 ==<br />
<br />
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).<br />
<br />
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.<br />
<br />
As side note MONOCHROME1 color space is not converted to MONOCHROME2 (itk::GDCMImageIO / ITK 5.0)<br />
<br />
== Issue ==<br />
<br />
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. (original bug report from Mihail Isakov)<br />
<br />
== Notation ==<br />
<br />
# JPEG refers to the subset of ITU-T T.81, ISO/IEC IS 10918-1 (lossy 8bits)<br />
# JPEG 2000 refers to ITU-T T.800, ISO/IEC IS 15444-1<br />
<br />
== ITK 5.x ==<br />
<br />
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.<br />
<br />
Current behavior of ITK 5.0:<br />
<br />
{| border="1" style="text-align:center"<br />
|- bgcolor="#abcdef"<br />
! Photometric Interpretation !! JPEG !! TIFF !! GDCM !! DCMTK<br />
|-<br />
! MONOCHROME1 || style="background:silver" | X || style="background:orange" |MONOCHROME2 (aka min-is-black) || style="background:lime" |MONOCHROME1 || style="background:lime" |?MONOCHROME1?<br />
|- <br />
! MONOCHROME2 || style="background:lime" | MONOCHROME2 || style="background:lime" |MONOCHROME2 (aka min-is-black) || style="background:lime" |MONOCHROME2 || style="background:lime" |MONOCHROME2<br />
|-<br />
! PALETTE COLOR || style="background:silver" |X || style="background:orange" | RGB (??) || style="background:orange" | Converted to RGB || style="background:orange" | ?Converted to RGB? (need to check compressed LUT)<br />
|-<br />
! RGB || style="background:orange" |RGB || RGB|| RGB || ?RGB?<br />
|- style="background:silver"<br />
! HSV || || || || <br />
|- style="background:silver"<br />
! ARGB || || || || <br />
|- style="background:silver"<br />
! CMYK || || || || <br />
|-<br />
! YBR_FULL || style="background:silver" |ITU 81 enforce sub-sampling|| ?? || YBR_FULL || ??<br />
|-<br />
! YBR_FULL_422 || style="background:orange" |RGB || style="background:orange" |RGB || YBR_FULL || ??Maybe RGB?<br />
|- style="background:silver"<br />
! YBR_PARTIAL_422 || || || || <br />
|- style="background:silver"<br />
! YBR_PARTIAL_420 || || || || <br />
|-<br />
! YBR_ICT || style="background:silver" |ITU 81 does not support this colorspace || ?? || RGB || style="background:red" |no J2K plugin<br />
|-<br />
! YBR_RCT || style="background:silver" |ITU 81 does not support this colorspace || ?? || RGB || style="background:red" |no J2K plugin<br />
|-<br />
|}<br />
<br />
<br />
Desired behavior of ITK 5.0:<br />
<br />
{| border="1" style="text-align:center"<br />
|- bgcolor="#abcdef"<br />
! Photometric Interpretation !! JPEG !! TIFF !! GDCM !! DCMTK<br />
|-<br />
! MONOCHROME1 || style="background:silver" | X || style="background:orange" |MONOCHROME2 (aka min-is-black)|| style="background:orange" |MONOCHROME2 || style="background:orange" |MONOCHROME2<br />
|- <br />
! MONOCHROME2 || style="background:lime" | MONOCHROME2 || style="background:lime" |MONOCHROME2 (aka min-is-black)|| style="background:lime" |MONOCHROME2 || style="background:lime" |MONOCHROME2<br />
|-<br />
! PALETTE COLOR || style="background:silver" | X || style="background:orange" | RGB || style="background:orange" | Converted to RGB || style="background:orange" | RGB<br />
|-<br />
! RGB || style="background:orange" |RGB || RGB|| RGB || ?RGB?<br />
|- style="background:silver"<br />
! HSV || || || || <br />
|- style="background:silver"<br />
! ARGB || || || || <br />
|- style="background:silver"<br />
! CMYK || || || || <br />
|-<br />
! YBR_FULL || style="background:silver" |ITU 81 enforce sub-sampling|| ?? || RGB || RGB<br />
|-<br />
! YBR_FULL_422 || style="background:orange" |RGB || style="background:orange" |RGB || RGB || RGB<br />
|- style="background:silver"<br />
! YBR_PARTIAL_422 || || || || <br />
|- style="background:silver"<br />
! YBR_PARTIAL_420 || || || || <br />
|-<br />
! YBR_ICT || || || RGB || style="background:red" |no J2K plugin<br />
|-<br />
! YBR_RCT || || || RGB || style="background:red" |no J2K plugin<br />
|-<br />
|}<br />
<br />
== Discussion ==<br />
<br />
Participants:<br />
# Mathieu Malaterre<br />
# Mihail Isakov<br />
<br />
For visualization people it is important that:<br />
<br />
# MONOCHROME1 (min-is-white) is converted to MONOCHROME2 (min-is-black) <br />
# YBR_FULL / YBR_FULL_422 are converted to RGB<br />
<br />
The requirements for quantitative analysis may be different, please list reqs here:<br />
<br />
#? Extract Luminance out of YBR ?<br />
# ? Need MONOCHROME1 native support, because <fill reason ??><br />
# ? Is there a need to manipulated native palette data ? I doubt so<br />
<br />
== References ==<br />
<br />
* http://dicom.nema.org/medical/dicom/current/output/chtml/part03/sect_C.7.6.3.html#sect_C.7.6.3.1.2<br />
* http://gdcm.sourceforge.net/wiki/index.php/Color_Space_Transformations</div>Mathieuhttps://public.kitware.com/Wiki/index.php?title=ITK/Release_5/DICOM/Color&diff=63959ITK/Release 5/DICOM/Color2019-10-11T08:42:41Z<p>Mathieu: /* ITK 5.x */</p>
<hr />
<div>= Multiple Components in DICOM =<br />
<br />
== ITK 5.0 ==<br />
<br />
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).<br />
<br />
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.<br />
<br />
As side note MONOCHROME1 color space is not converted to MONOCHROME2 (itk::GDCMImageIO / ITK 5.0)<br />
<br />
== Issue ==<br />
<br />
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. (original bug report from Mihail Isakov)<br />
<br />
== Notation ==<br />
<br />
# JPEG refers to the subset of ITU-T T.81, ISO/IEC IS 10918-1 (lossy 8bits)<br />
# JPEG 2000 refers to ITU-T T.800, ISO/IEC IS 15444-1<br />
<br />
== ITK 5.x ==<br />
<br />
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.<br />
<br />
Current behavior of ITK 5.0:<br />
<br />
{| border="1" style="text-align:center"<br />
|- bgcolor="#abcdef"<br />
! Photometric Interpretation !! JPEG !! TIFF !! GDCM !! DCMTK<br />
|-<br />
! MONOCHROME1 || style="background:silver" | X || style="background:orange" |MONOCHROME2 (aka min-is-black) || style="background:lime" |MONOCHROME1 || style="background:lime" |?MONOCHROME1?<br />
|- <br />
! MONOCHROME2 || style="background:lime" | MONOCHROME2 || style="background:lime" |MONOCHROME2 (aka min-is-black) || style="background:lime" |MONOCHROME2 || style="background:lime" |MONOCHROME2<br />
|-<br />
! PALETTE COLOR || style="background:silver" |X || style="background:orange" | RGB (??) || style="background:orange" | Converted to RGB || style="background:orange" | ?Converted to RGB? (need to check compressed LUT)<br />
|-<br />
! RGB || style="background:orange" |RGB || RGB|| RGB || ?RGB?<br />
|- style="background:silver"<br />
! HSV || || || || <br />
|- style="background:silver"<br />
! ARGB || || || || <br />
|- style="background:silver"<br />
! CMYK || || || || <br />
|-<br />
! YBR_FULL || style="background:silver" |ITU 81 enforce sub-sampling|| ?? || YBR_FULL || ??<br />
|-<br />
! YBR_FULL_422 || style="background:orange" |RGB || style="background:orange" |RGB || YBR_FULL || ??Maybe RGB?<br />
|- style="background:silver"<br />
! YBR_PARTIAL_422 || || || || <br />
|- style="background:silver"<br />
! YBR_PARTIAL_420 || || || || <br />
|-<br />
! YBR_ICT || style="background:silver" |ITU 81 does not support this colorspace || ?? || RGB || style="background:red" |no J2K plugin<br />
|-<br />
! YBR_RCT || style="background:silver" |ITU 81 does not support this colorspace || ?? || RGB || style="background:red" |no J2K plugin<br />
|-<br />
|}<br />
<br />
<br />
Desired behavior of ITK 5.0:<br />
<br />
{| border="1" style="text-align:center"<br />
|- bgcolor="#abcdef"<br />
! Photometric Interpretation !! JPEG !! TIFF !! GDCM !! DCMTK<br />
|-<br />
! MONOCHROME1 || style="background:silver" | X || style="background:orange" |MONOCHROME2 (aka min-is-black)|| style="background:orange" |MONOCHROME2 || style="background:orange" |MONOCHROME2<br />
|- <br />
! MONOCHROME2 || style="background:lime" | MONOCHROME2 || style="background:lime" |MONOCHROME2 (aka min-is-black)|| style="background:lime" |MONOCHROME2 || style="background:lime" |MONOCHROME2<br />
|-<br />
! PALETTE COLOR || style="background:silver" | X || style="background:orange" | RGB || style="background:orange" | Converted to RGB || style="background:orange" | RGB<br />
|-<br />
! RGB || style="background:orange" |RGB || RGB|| RGB || ?RGB?<br />
|- style="background:silver"<br />
! HSV || || || || <br />
|- style="background:silver"<br />
! ARGB || || || || <br />
|- style="background:silver"<br />
! CMYK || || || || <br />
|-<br />
! YBR_FULL || style="background:silver" |ITU 81 enforce sub-sampling|| ?? || RGB || ??<br />
|-<br />
! YBR_FULL_422 || style="background:orange" |RGB || style="background:orange" |RGB || RGB || ??Maybe RGB?<br />
|- style="background:silver"<br />
! YBR_PARTIAL_422 || || || || <br />
|- style="background:silver"<br />
! YBR_PARTIAL_420 || || || || <br />
|-<br />
! YBR_ICT || || || RGB || style="background:red" |no J2K plugin<br />
|-<br />
! YBR_RCT || || || RGB || style="background:red" |no J2K plugin<br />
|-<br />
|}<br />
<br />
== Discussion ==<br />
<br />
Participants:<br />
# Mathieu Malaterre<br />
# Mihail Isakov<br />
<br />
For visualization people it is important that:<br />
<br />
# MONOCHROME1 (min-is-white) is converted to MONOCHROME2 (min-is-black) <br />
# YBR_FULL / YBR_FULL_422 are converted to RGB<br />
<br />
The requirements for quantitative analysis may be different, please list reqs here:<br />
<br />
#? Extract Luminance out of YBR ?<br />
# ? Need MONOCHROME1 native support, because <fill reason ??><br />
# ? Is there a need to manipulated native palette data ? I doubt so<br />
<br />
== References ==<br />
<br />
* http://dicom.nema.org/medical/dicom/current/output/chtml/part03/sect_C.7.6.3.html#sect_C.7.6.3.1.2<br />
* http://gdcm.sourceforge.net/wiki/index.php/Color_Space_Transformations</div>Mathieuhttps://public.kitware.com/Wiki/index.php?title=ITK/Release_5/DICOM/Color&diff=63958ITK/Release 5/DICOM/Color2019-10-11T08:40:49Z<p>Mathieu: /* ITK 5.x */</p>
<hr />
<div>= Multiple Components in DICOM =<br />
<br />
== ITK 5.0 ==<br />
<br />
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).<br />
<br />
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.<br />
<br />
As side note MONOCHROME1 color space is not converted to MONOCHROME2 (itk::GDCMImageIO / ITK 5.0)<br />
<br />
== Issue ==<br />
<br />
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. (original bug report from Mihail Isakov)<br />
<br />
== Notation ==<br />
<br />
# JPEG refers to the subset of ITU-T T.81, ISO/IEC IS 10918-1 (lossy 8bits)<br />
# JPEG 2000 refers to ITU-T T.800, ISO/IEC IS 15444-1<br />
<br />
== ITK 5.x ==<br />
<br />
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.<br />
<br />
Current behavior of ITK 5.0:<br />
<br />
{| border="1" style="text-align:center"<br />
|- bgcolor="#abcdef"<br />
! Photometric Interpretation !! JPEG !! TIFF !! GDCM !! DCMTK<br />
|-<br />
! MONOCHROME1 || style="background:silver" | X || style="background:orange" |MONOCHROME2 (aka min-is-black) || style="background:lime" |MONOCHROME1 || style="background:lime" |?MONOCHROME1?<br />
|- <br />
! MONOCHROME2 || style="background:lime" | MONOCHROME2 || style="background:lime" |MONOCHROME2 (aka min-is-black) || style="background:lime" |MONOCHROME2 || style="background:lime" |MONOCHROME2<br />
|-<br />
! PALETTE COLOR || style="background:silver" |X || style="background:orange" | RGB (??) || style="background:orange" | Converted to RGB || style="background:orange" | ?Converted to RGB? (need to check compressed LUT)<br />
|-<br />
! RGB || style="background:orange" |RGB || RGB|| RGB || ?RGB?<br />
|- style="background:silver"<br />
! HSV || || || || <br />
|- style="background:silver"<br />
! ARGB || || || || <br />
|- style="background:silver"<br />
! CMYK || || || || <br />
|-<br />
! YBR_FULL || style="background:silver" |ITU 81 enforce sub-sampling|| ?? || YBR_FULL || ??<br />
|-<br />
! YBR_FULL_422 || style="background:orange" |RGB || style="background:orange" |RGB || YBR_FULL || ??Maybe RGB?<br />
|- style="background:silver"<br />
! YBR_PARTIAL_422 || || || || <br />
|- style="background:silver"<br />
! YBR_PARTIAL_420 || || || || <br />
|-<br />
! YBR_ICT || style="background:silver" |ITU 81 does not support this colorspace || ?? || RGB || style="background:red" |no J2K plugin<br />
|-<br />
! YBR_RCT || style="background:silver" |ITU 81 does not support this colorspace || ?? || RGB || style="background:red" |no J2K plugin<br />
|-<br />
|}<br />
<br />
<br />
Desired behavior of ITK 5.0:<br />
<br />
{| border="1" style="text-align:center"<br />
|- bgcolor="#abcdef"<br />
! Photometric Interpretation !! JPEG !! TIFF !! GDCM !! DCMTK<br />
|-<br />
! MONOCHROME1 || style="background:silver" | X || style="background:orange" |MONOCHROME2 (aka min-is-black)|| style="background:lime" |MONOCHROME1 || style="background:lime" |?MONOCHROME1?<br />
|- <br />
! MONOCHROME2 || style="background:lime" | MONOCHROME2 || style="background:lime" |MONOCHROME2 (aka min-is-black)|| style="background:lime" |MONOCHROME2 || style="background:lime" |MONOCHROME2<br />
|-<br />
! PALETTE COLOR || style="background:silver" | X || style="background:orange" | RGB || style="background:orange" | Converted to RGB || style="background:orange" | ??<br />
|-<br />
! RGB || style="background:orange" |RGB || RGB|| RGB || ?RGB?<br />
|- style="background:silver"<br />
! HSV || || || || <br />
|- style="background:silver"<br />
! ARGB || || || || <br />
|- style="background:silver"<br />
! CMYK || || || || <br />
|-<br />
! YBR_FULL || style="background:silver" |ITU 81 enforce sub-sampling|| ?? || RGB || ??<br />
|-<br />
! YBR_FULL_422 || style="background:orange" |RGB || style="background:orange" |RGB || RGB || ??Maybe RGB?<br />
|- style="background:silver"<br />
! YBR_PARTIAL_422 || || || || <br />
|- style="background:silver"<br />
! YBR_PARTIAL_420 || || || || <br />
|-<br />
! YBR_ICT || || || RGB || style="background:red" |no J2K plugin<br />
|-<br />
! YBR_RCT || || || RGB || style="background:red" |no J2K plugin<br />
|-<br />
|}<br />
<br />
== Discussion ==<br />
<br />
Participants:<br />
# Mathieu Malaterre<br />
# Mihail Isakov<br />
<br />
For visualization people it is important that:<br />
<br />
# MONOCHROME1 (min-is-white) is converted to MONOCHROME2 (min-is-black) <br />
# YBR_FULL / YBR_FULL_422 are converted to RGB<br />
<br />
The requirements for quantitative analysis may be different, please list reqs here:<br />
<br />
#? Extract Luminance out of YBR ?<br />
# ? Need MONOCHROME1 native support, because <fill reason ??><br />
# ? Is there a need to manipulated native palette data ? I doubt so<br />
<br />
== References ==<br />
<br />
* http://dicom.nema.org/medical/dicom/current/output/chtml/part03/sect_C.7.6.3.html#sect_C.7.6.3.1.2<br />
* http://gdcm.sourceforge.net/wiki/index.php/Color_Space_Transformations</div>Mathieuhttps://public.kitware.com/Wiki/index.php?title=ITK/Release_5/DICOM/Color&diff=63957ITK/Release 5/DICOM/Color2019-10-11T08:40:01Z<p>Mathieu: /* References */</p>
<hr />
<div>= Multiple Components in DICOM =<br />
<br />
== ITK 5.0 ==<br />
<br />
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).<br />
<br />
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.<br />
<br />
As side note MONOCHROME1 color space is not converted to MONOCHROME2 (itk::GDCMImageIO / ITK 5.0)<br />
<br />
== Issue ==<br />
<br />
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. (original bug report from Mihail Isakov)<br />
<br />
== Notation ==<br />
<br />
# JPEG refers to the subset of ITU-T T.81, ISO/IEC IS 10918-1 (lossy 8bits)<br />
# JPEG 2000 refers to ITU-T T.800, ISO/IEC IS 15444-1<br />
<br />
== ITK 5.x ==<br />
<br />
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.<br />
<br />
Current behavior of ITK 5.0:<br />
<br />
{| border="1" style="text-align:center"<br />
|- bgcolor="#abcdef"<br />
! Photometric Interpretation !! JPEG !! TIFF !! GDCM !! DCMTK<br />
|-<br />
! MONOCHROME1 || style="background:silver" | X || style="background:orange" |MONOCHROME2 (aka min-is-black) || style="background:lime" |MONOCHROME1 || style="background:lime" |?MONOCHROME1?<br />
|- <br />
! MONOCHROME2 || style="background:lime" | MONOCHROME2 || style="background:lime" |MONOCHROME2 (aka min-is-black) || style="background:lime" |MONOCHROME2 || style="background:lime" |MONOCHROME2<br />
|-<br />
! PALETTE_COLOR || style="background:silver" |X || style="background:orange" | RGB (??) || style="background:orange" | Converted to RGB || style="background:orange" | ?Converted to RGB? (need to check compressed LUT)<br />
|-<br />
! RGB || style="background:orange" |RGB || RGB|| RGB || ?RGB?<br />
|- style="background:silver"<br />
! HSV || || || || <br />
|- style="background:silver"<br />
! ARGB || || || || <br />
|- style="background:silver"<br />
! CMYK || || || || <br />
|-<br />
! YBR_FULL || style="background:silver" |ITU 81 enforce sub-sampling|| ?? || YBR_FULL || ??<br />
|-<br />
! YBR_FULL_422 || style="background:orange" |RGB || style="background:orange" |RGB || YBR_FULL || ??Maybe RGB?<br />
|- style="background:silver"<br />
! YBR_PARTIAL_422 || || || || <br />
|- style="background:silver"<br />
! YBR_PARTIAL_420 || || || || <br />
|-<br />
! YBR_ICT || style="background:silver" |ITU 81 does not support this colorspace || ?? || RGB || style="background:red" |no J2K plugin<br />
|-<br />
! YBR_RCT || style="background:silver" |ITU 81 does not support this colorspace || ?? || RGB || style="background:red" |no J2K plugin<br />
|-<br />
|}<br />
<br />
<br />
Desired behavior of ITK 5.0:<br />
<br />
{| border="1" style="text-align:center"<br />
|- bgcolor="#abcdef"<br />
! Photometric Interpretation !! JPEG !! TIFF !! GDCM !! DCMTK<br />
|-<br />
! MONOCHROME1 || style="background:silver" | X || style="background:orange" |MONOCHROME2 (aka min-is-black)|| style="background:lime" |MONOCHROME1 || style="background:lime" |?MONOCHROME1?<br />
|- <br />
! MONOCHROME2 || style="background:lime" | MONOCHROME2 || style="background:lime" |MONOCHROME2 (aka min-is-black)|| style="background:lime" |MONOCHROME2 || style="background:lime" |MONOCHROME2<br />
|-<br />
! PALETTE_COLOR || style="background:silver" | X || style="background:orange" | RGB || style="background:orange" | Converted to RGB || style="background:orange" | ??<br />
|-<br />
! RGB || style="background:orange" |RGB || RGB|| RGB || ?RGB?<br />
|- style="background:silver"<br />
! HSV || || || || <br />
|- style="background:silver"<br />
! ARGB || || || || <br />
|- style="background:silver"<br />
! CMYK || || || || <br />
|-<br />
! YBR_FULL || style="background:silver" |ITU 81 enforce sub-sampling|| ?? || RGB || ??<br />
|-<br />
! YBR_FULL_422 || style="background:orange" |RGB || style="background:orange" |RGB || RGB || ??Maybe RGB?<br />
|- style="background:silver"<br />
! YBR_PARTIAL_422 || || || || <br />
|- style="background:silver"<br />
! YBR_PARTIAL_420 || || || || <br />
|-<br />
! YBR_ICT || || || RGB || style="background:red" |no J2K plugin<br />
|-<br />
! YBR_RCT || || || RGB || style="background:red" |no J2K plugin<br />
|-<br />
|}<br />
<br />
<br />
== Discussion ==<br />
<br />
Participants:<br />
# Mathieu Malaterre<br />
# Mihail Isakov<br />
<br />
For visualization people it is important that:<br />
<br />
# MONOCHROME1 (min-is-white) is converted to MONOCHROME2 (min-is-black) <br />
# YBR_FULL / YBR_FULL_422 are converted to RGB<br />
<br />
The requirements for quantitative analysis may be different, please list reqs here:<br />
<br />
#? Extract Luminance out of YBR ?<br />
# ? Need MONOCHROME1 native support, because <fill reason ??><br />
# ? Is there a need to manipulated native palette data ? I doubt so<br />
<br />
== References ==<br />
<br />
* http://dicom.nema.org/medical/dicom/current/output/chtml/part03/sect_C.7.6.3.html#sect_C.7.6.3.1.2<br />
* http://gdcm.sourceforge.net/wiki/index.php/Color_Space_Transformations</div>Mathieuhttps://public.kitware.com/Wiki/index.php?title=ITK/Release_5/DICOM/Color&diff=63956ITK/Release 5/DICOM/Color2019-10-11T08:36:34Z<p>Mathieu: /* Discussion */</p>
<hr />
<div>= Multiple Components in DICOM =<br />
<br />
== ITK 5.0 ==<br />
<br />
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).<br />
<br />
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.<br />
<br />
As side note MONOCHROME1 color space is not converted to MONOCHROME2 (itk::GDCMImageIO / ITK 5.0)<br />
<br />
== Issue ==<br />
<br />
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. (original bug report from Mihail Isakov)<br />
<br />
== Notation ==<br />
<br />
# JPEG refers to the subset of ITU-T T.81, ISO/IEC IS 10918-1 (lossy 8bits)<br />
# JPEG 2000 refers to ITU-T T.800, ISO/IEC IS 15444-1<br />
<br />
== ITK 5.x ==<br />
<br />
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.<br />
<br />
Current behavior of ITK 5.0:<br />
<br />
{| border="1" style="text-align:center"<br />
|- bgcolor="#abcdef"<br />
! Photometric Interpretation !! JPEG !! TIFF !! GDCM !! DCMTK<br />
|-<br />
! MONOCHROME1 || style="background:silver" | X || style="background:orange" |MONOCHROME2 (aka min-is-black) || style="background:lime" |MONOCHROME1 || style="background:lime" |?MONOCHROME1?<br />
|- <br />
! MONOCHROME2 || style="background:lime" | MONOCHROME2 || style="background:lime" |MONOCHROME2 (aka min-is-black) || style="background:lime" |MONOCHROME2 || style="background:lime" |MONOCHROME2<br />
|-<br />
! PALETTE_COLOR || style="background:silver" |X || style="background:orange" | RGB (??) || style="background:orange" | Converted to RGB || style="background:orange" | ?Converted to RGB? (need to check compressed LUT)<br />
|-<br />
! RGB || style="background:orange" |RGB || RGB|| RGB || ?RGB?<br />
|- style="background:silver"<br />
! HSV || || || || <br />
|- style="background:silver"<br />
! ARGB || || || || <br />
|- style="background:silver"<br />
! CMYK || || || || <br />
|-<br />
! YBR_FULL || style="background:silver" |ITU 81 enforce sub-sampling|| ?? || YBR_FULL || ??<br />
|-<br />
! YBR_FULL_422 || style="background:orange" |RGB || style="background:orange" |RGB || YBR_FULL || ??Maybe RGB?<br />
|- style="background:silver"<br />
! YBR_PARTIAL_422 || || || || <br />
|- style="background:silver"<br />
! YBR_PARTIAL_420 || || || || <br />
|-<br />
! YBR_ICT || style="background:silver" |ITU 81 does not support this colorspace || ?? || RGB || style="background:red" |no J2K plugin<br />
|-<br />
! YBR_RCT || style="background:silver" |ITU 81 does not support this colorspace || ?? || RGB || style="background:red" |no J2K plugin<br />
|-<br />
|}<br />
<br />
<br />
Desired behavior of ITK 5.0:<br />
<br />
{| border="1" style="text-align:center"<br />
|- bgcolor="#abcdef"<br />
! Photometric Interpretation !! JPEG !! TIFF !! GDCM !! DCMTK<br />
|-<br />
! MONOCHROME1 || style="background:silver" | X || style="background:orange" |MONOCHROME2 (aka min-is-black)|| style="background:lime" |MONOCHROME1 || style="background:lime" |?MONOCHROME1?<br />
|- <br />
! MONOCHROME2 || style="background:lime" | MONOCHROME2 || style="background:lime" |MONOCHROME2 (aka min-is-black)|| style="background:lime" |MONOCHROME2 || style="background:lime" |MONOCHROME2<br />
|-<br />
! PALETTE_COLOR || style="background:silver" | X || style="background:orange" | RGB || style="background:orange" | Converted to RGB || style="background:orange" | ??<br />
|-<br />
! RGB || style="background:orange" |RGB || RGB|| RGB || ?RGB?<br />
|- style="background:silver"<br />
! HSV || || || || <br />
|- style="background:silver"<br />
! ARGB || || || || <br />
|- style="background:silver"<br />
! CMYK || || || || <br />
|-<br />
! YBR_FULL || style="background:silver" |ITU 81 enforce sub-sampling|| ?? || RGB || ??<br />
|-<br />
! YBR_FULL_422 || style="background:orange" |RGB || style="background:orange" |RGB || RGB || ??Maybe RGB?<br />
|- style="background:silver"<br />
! YBR_PARTIAL_422 || || || || <br />
|- style="background:silver"<br />
! YBR_PARTIAL_420 || || || || <br />
|-<br />
! YBR_ICT || || || RGB || style="background:red" |no J2K plugin<br />
|-<br />
! YBR_RCT || || || RGB || style="background:red" |no J2K plugin<br />
|-<br />
|}<br />
<br />
<br />
== Discussion ==<br />
<br />
Participants:<br />
# Mathieu Malaterre<br />
# Mihail Isakov<br />
<br />
For visualization people it is important that:<br />
<br />
# MONOCHROME1 (min-is-white) is converted to MONOCHROME2 (min-is-black) <br />
# YBR_FULL / YBR_FULL_422 are converted to RGB<br />
<br />
The requirements for quantitative analysis may be different, please list reqs here:<br />
<br />
#? Extract Luminance out of YBR ?<br />
# ? Need MONOCHROME1 native support, because <fill reason ??><br />
# ? Is there a need to manipulated native palette data ? I doubt so<br />
<br />
== References ==<br />
<br />
* http://gdcm.sourceforge.net/wiki/index.php/Color_Space_Transformations</div>Mathieuhttps://public.kitware.com/Wiki/index.php?title=ITK/Release_5/DICOM/Color&diff=63955ITK/Release 5/DICOM/Color2019-10-11T08:34:52Z<p>Mathieu: /* ITK 5.0 */</p>
<hr />
<div>= Multiple Components in DICOM =<br />
<br />
== ITK 5.0 ==<br />
<br />
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).<br />
<br />
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.<br />
<br />
As side note MONOCHROME1 color space is not converted to MONOCHROME2 (itk::GDCMImageIO / ITK 5.0)<br />
<br />
== Issue ==<br />
<br />
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. (original bug report from Mihail Isakov)<br />
<br />
== Notation ==<br />
<br />
# JPEG refers to the subset of ITU-T T.81, ISO/IEC IS 10918-1 (lossy 8bits)<br />
# JPEG 2000 refers to ITU-T T.800, ISO/IEC IS 15444-1<br />
<br />
== ITK 5.x ==<br />
<br />
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.<br />
<br />
Current behavior of ITK 5.0:<br />
<br />
{| border="1" style="text-align:center"<br />
|- bgcolor="#abcdef"<br />
! Photometric Interpretation !! JPEG !! TIFF !! GDCM !! DCMTK<br />
|-<br />
! MONOCHROME1 || style="background:silver" | X || style="background:orange" |MONOCHROME2 (aka min-is-black) || style="background:lime" |MONOCHROME1 || style="background:lime" |?MONOCHROME1?<br />
|- <br />
! MONOCHROME2 || style="background:lime" | MONOCHROME2 || style="background:lime" |MONOCHROME2 (aka min-is-black) || style="background:lime" |MONOCHROME2 || style="background:lime" |MONOCHROME2<br />
|-<br />
! PALETTE_COLOR || style="background:silver" |X || style="background:orange" | RGB (??) || style="background:orange" | Converted to RGB || style="background:orange" | ?Converted to RGB? (need to check compressed LUT)<br />
|-<br />
! RGB || style="background:orange" |RGB || RGB|| RGB || ?RGB?<br />
|- style="background:silver"<br />
! HSV || || || || <br />
|- style="background:silver"<br />
! ARGB || || || || <br />
|- style="background:silver"<br />
! CMYK || || || || <br />
|-<br />
! YBR_FULL || style="background:silver" |ITU 81 enforce sub-sampling|| ?? || YBR_FULL || ??<br />
|-<br />
! YBR_FULL_422 || style="background:orange" |RGB || style="background:orange" |RGB || YBR_FULL || ??Maybe RGB?<br />
|- style="background:silver"<br />
! YBR_PARTIAL_422 || || || || <br />
|- style="background:silver"<br />
! YBR_PARTIAL_420 || || || || <br />
|-<br />
! YBR_ICT || style="background:silver" |ITU 81 does not support this colorspace || ?? || RGB || style="background:red" |no J2K plugin<br />
|-<br />
! YBR_RCT || style="background:silver" |ITU 81 does not support this colorspace || ?? || RGB || style="background:red" |no J2K plugin<br />
|-<br />
|}<br />
<br />
<br />
Desired behavior of ITK 5.0:<br />
<br />
{| border="1" style="text-align:center"<br />
|- bgcolor="#abcdef"<br />
! Photometric Interpretation !! JPEG !! TIFF !! GDCM !! DCMTK<br />
|-<br />
! MONOCHROME1 || style="background:silver" | X || style="background:orange" |MONOCHROME2 (aka min-is-black)|| style="background:lime" |MONOCHROME1 || style="background:lime" |?MONOCHROME1?<br />
|- <br />
! MONOCHROME2 || style="background:lime" | MONOCHROME2 || style="background:lime" |MONOCHROME2 (aka min-is-black)|| style="background:lime" |MONOCHROME2 || style="background:lime" |MONOCHROME2<br />
|-<br />
! PALETTE_COLOR || style="background:silver" | X || style="background:orange" | RGB || style="background:orange" | Converted to RGB || style="background:orange" | ??<br />
|-<br />
! RGB || style="background:orange" |RGB || RGB|| RGB || ?RGB?<br />
|- style="background:silver"<br />
! HSV || || || || <br />
|- style="background:silver"<br />
! ARGB || || || || <br />
|- style="background:silver"<br />
! CMYK || || || || <br />
|-<br />
! YBR_FULL || style="background:silver" |ITU 81 enforce sub-sampling|| ?? || RGB || ??<br />
|-<br />
! YBR_FULL_422 || style="background:orange" |RGB || style="background:orange" |RGB || RGB || ??Maybe RGB?<br />
|- style="background:silver"<br />
! YBR_PARTIAL_422 || || || || <br />
|- style="background:silver"<br />
! YBR_PARTIAL_420 || || || || <br />
|-<br />
! YBR_ICT || || || RGB || style="background:red" |no J2K plugin<br />
|-<br />
! YBR_RCT || || || RGB || style="background:red" |no J2K plugin<br />
|-<br />
|}<br />
<br />
<br />
== Discussion ==<br />
<br />
For visualization people it is important that:<br />
<br />
# MONOCHROME1 (min-is-white) is converted to MONOCHROME2 (min-is-black) <br />
# YBR_FULL / YBR_FULL_422 are converted to RGB<br />
<br />
The requirements for quantitative analysis may be different, please list reqs here:<br />
<br />
#? Extract Luminance out of YBR ?<br />
# ? Need MONOCHROME1 native support, because <fill reason ??><br />
# ? Is there a need to manipulated native palette data ? I doubt so<br />
<br />
== References ==<br />
<br />
* http://gdcm.sourceforge.net/wiki/index.php/Color_Space_Transformations</div>Mathieuhttps://public.kitware.com/Wiki/index.php?title=ITK/Release_5/DICOM/Color&diff=63954ITK/Release 5/DICOM/Color2019-10-11T08:33:44Z<p>Mathieu: /* Multiple Components in DICOM */</p>
<hr />
<div>= Multiple Components in DICOM =<br />
<br />
== ITK 5.0 ==<br />
<br />
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).<br />
<br />
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.<br />
<br />
== Issue ==<br />
<br />
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. (original bug report from Mihail Isakov)<br />
<br />
== Notation ==<br />
<br />
# JPEG refers to the subset of ITU-T T.81, ISO/IEC IS 10918-1 (lossy 8bits)<br />
# JPEG 2000 refers to ITU-T T.800, ISO/IEC IS 15444-1<br />
<br />
== ITK 5.x ==<br />
<br />
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.<br />
<br />
Current behavior of ITK 5.0:<br />
<br />
{| border="1" style="text-align:center"<br />
|- bgcolor="#abcdef"<br />
! Photometric Interpretation !! JPEG !! TIFF !! GDCM !! DCMTK<br />
|-<br />
! MONOCHROME1 || style="background:silver" | X || style="background:orange" |MONOCHROME2 (aka min-is-black) || style="background:lime" |MONOCHROME1 || style="background:lime" |?MONOCHROME1?<br />
|- <br />
! MONOCHROME2 || style="background:lime" | MONOCHROME2 || style="background:lime" |MONOCHROME2 (aka min-is-black) || style="background:lime" |MONOCHROME2 || style="background:lime" |MONOCHROME2<br />
|-<br />
! PALETTE_COLOR || style="background:silver" |X || style="background:orange" | RGB (??) || style="background:orange" | Converted to RGB || style="background:orange" | ?Converted to RGB? (need to check compressed LUT)<br />
|-<br />
! RGB || style="background:orange" |RGB || RGB|| RGB || ?RGB?<br />
|- style="background:silver"<br />
! HSV || || || || <br />
|- style="background:silver"<br />
! ARGB || || || || <br />
|- style="background:silver"<br />
! CMYK || || || || <br />
|-<br />
! YBR_FULL || style="background:silver" |ITU 81 enforce sub-sampling|| ?? || YBR_FULL || ??<br />
|-<br />
! YBR_FULL_422 || style="background:orange" |RGB || style="background:orange" |RGB || YBR_FULL || ??Maybe RGB?<br />
|- style="background:silver"<br />
! YBR_PARTIAL_422 || || || || <br />
|- style="background:silver"<br />
! YBR_PARTIAL_420 || || || || <br />
|-<br />
! YBR_ICT || style="background:silver" |ITU 81 does not support this colorspace || ?? || RGB || style="background:red" |no J2K plugin<br />
|-<br />
! YBR_RCT || style="background:silver" |ITU 81 does not support this colorspace || ?? || RGB || style="background:red" |no J2K plugin<br />
|-<br />
|}<br />
<br />
<br />
Desired behavior of ITK 5.0:<br />
<br />
{| border="1" style="text-align:center"<br />
|- bgcolor="#abcdef"<br />
! Photometric Interpretation !! JPEG !! TIFF !! GDCM !! DCMTK<br />
|-<br />
! MONOCHROME1 || style="background:silver" | X || style="background:orange" |MONOCHROME2 (aka min-is-black)|| style="background:lime" |MONOCHROME1 || style="background:lime" |?MONOCHROME1?<br />
|- <br />
! MONOCHROME2 || style="background:lime" | MONOCHROME2 || style="background:lime" |MONOCHROME2 (aka min-is-black)|| style="background:lime" |MONOCHROME2 || style="background:lime" |MONOCHROME2<br />
|-<br />
! PALETTE_COLOR || style="background:silver" | X || style="background:orange" | RGB || style="background:orange" | Converted to RGB || style="background:orange" | ??<br />
|-<br />
! RGB || style="background:orange" |RGB || RGB|| RGB || ?RGB?<br />
|- style="background:silver"<br />
! HSV || || || || <br />
|- style="background:silver"<br />
! ARGB || || || || <br />
|- style="background:silver"<br />
! CMYK || || || || <br />
|-<br />
! YBR_FULL || style="background:silver" |ITU 81 enforce sub-sampling|| ?? || RGB || ??<br />
|-<br />
! YBR_FULL_422 || style="background:orange" |RGB || style="background:orange" |RGB || RGB || ??Maybe RGB?<br />
|- style="background:silver"<br />
! YBR_PARTIAL_422 || || || || <br />
|- style="background:silver"<br />
! YBR_PARTIAL_420 || || || || <br />
|-<br />
! YBR_ICT || || || RGB || style="background:red" |no J2K plugin<br />
|-<br />
! YBR_RCT || || || RGB || style="background:red" |no J2K plugin<br />
|-<br />
|}<br />
<br />
<br />
== Discussion ==<br />
<br />
For visualization people it is important that:<br />
<br />
# MONOCHROME1 (min-is-white) is converted to MONOCHROME2 (min-is-black) <br />
# YBR_FULL / YBR_FULL_422 are converted to RGB<br />
<br />
The requirements for quantitative analysis may be different, please list reqs here:<br />
<br />
#? Extract Luminance out of YBR ?<br />
# ? Need MONOCHROME1 native support, because <fill reason ??><br />
# ? Is there a need to manipulated native palette data ? I doubt so<br />
<br />
== References ==<br />
<br />
* http://gdcm.sourceforge.net/wiki/index.php/Color_Space_Transformations</div>Mathieuhttps://public.kitware.com/Wiki/index.php?title=ITK/Release_5/DICOM/Color&diff=63953ITK/Release 5/DICOM/Color2019-10-11T08:28:24Z<p>Mathieu: /* ITK 5.x */</p>
<hr />
<div>= Multiple Components in DICOM =<br />
<br />
== ITK 5.0 ==<br />
<br />
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).<br />
<br />
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.<br />
<br />
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.<br />
<br />
== Notation ==<br />
<br />
# JPEG refers to the subset of ITU-T T.81, ISO/IEC IS 10918-1 (lossy 8bits)<br />
# JPEG 2000 refers to ITU-T T.800, ISO/IEC IS 15444-1<br />
<br />
== ITK 5.x ==<br />
<br />
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.<br />
<br />
Current behavior of ITK 5.0:<br />
<br />
{| border="1" style="text-align:center"<br />
|- bgcolor="#abcdef"<br />
! Photometric Interpretation !! JPEG !! TIFF !! GDCM !! DCMTK<br />
|-<br />
! MONOCHROME1 || style="background:silver" | X || style="background:orange" |MONOCHROME2 (aka min-is-black) || style="background:lime" |MONOCHROME1 || style="background:lime" |?MONOCHROME1?<br />
|- <br />
! MONOCHROME2 || style="background:lime" | MONOCHROME2 || style="background:lime" |MONOCHROME2 (aka min-is-black) || style="background:lime" |MONOCHROME2 || style="background:lime" |MONOCHROME2<br />
|-<br />
! PALETTE_COLOR || style="background:silver" |X || style="background:orange" | RGB (??) || style="background:orange" | Converted to RGB || style="background:orange" | ?Converted to RGB? (need to check compressed LUT)<br />
|-<br />
! RGB || style="background:orange" |RGB || RGB|| RGB || ?RGB?<br />
|- style="background:silver"<br />
! HSV || || || || <br />
|- style="background:silver"<br />
! ARGB || || || || <br />
|- style="background:silver"<br />
! CMYK || || || || <br />
|-<br />
! YBR_FULL || style="background:silver" |ITU 81 enforce sub-sampling|| ?? || YBR_FULL || ??<br />
|-<br />
! YBR_FULL_422 || style="background:orange" |RGB || style="background:orange" |RGB || YBR_FULL || ??Maybe RGB?<br />
|- style="background:silver"<br />
! YBR_PARTIAL_422 || || || || <br />
|- style="background:silver"<br />
! YBR_PARTIAL_420 || || || || <br />
|-<br />
! YBR_ICT || style="background:silver" |ITU 81 does not support this colorspace || ?? || RGB || style="background:red" |no J2K plugin<br />
|-<br />
! YBR_RCT || style="background:silver" |ITU 81 does not support this colorspace || ?? || RGB || style="background:red" |no J2K plugin<br />
|-<br />
|}<br />
<br />
<br />
Desired behavior of ITK 5.0:<br />
<br />
{| border="1" style="text-align:center"<br />
|- bgcolor="#abcdef"<br />
! Photometric Interpretation !! JPEG !! TIFF !! GDCM !! DCMTK<br />
|-<br />
! MONOCHROME1 || style="background:silver" | X || style="background:orange" |MONOCHROME2 (aka min-is-black)|| style="background:lime" |MONOCHROME1 || style="background:lime" |?MONOCHROME1?<br />
|- <br />
! MONOCHROME2 || style="background:lime" | MONOCHROME2 || style="background:lime" |MONOCHROME2 (aka min-is-black)|| style="background:lime" |MONOCHROME2 || style="background:lime" |MONOCHROME2<br />
|-<br />
! PALETTE_COLOR || style="background:silver" | X || style="background:orange" | RGB || style="background:orange" | Converted to RGB || style="background:orange" | ??<br />
|-<br />
! RGB || style="background:orange" |RGB || RGB|| RGB || ?RGB?<br />
|- style="background:silver"<br />
! HSV || || || || <br />
|- style="background:silver"<br />
! ARGB || || || || <br />
|- style="background:silver"<br />
! CMYK || || || || <br />
|-<br />
! YBR_FULL || style="background:silver" |ITU 81 enforce sub-sampling|| ?? || RGB || ??<br />
|-<br />
! YBR_FULL_422 || style="background:orange" |RGB || style="background:orange" |RGB || RGB || ??Maybe RGB?<br />
|- style="background:silver"<br />
! YBR_PARTIAL_422 || || || || <br />
|- style="background:silver"<br />
! YBR_PARTIAL_420 || || || || <br />
|-<br />
! YBR_ICT || || || RGB || style="background:red" |no J2K plugin<br />
|-<br />
! YBR_RCT || || || RGB || style="background:red" |no J2K plugin<br />
|-<br />
|}<br />
<br />
<br />
== Discussion ==<br />
<br />
For visualization people it is important that:<br />
<br />
# MONOCHROME1 (min-is-white) is converted to MONOCHROME2 (min-is-black) <br />
# YBR_FULL / YBR_FULL_422 are converted to RGB<br />
<br />
The requirements for quantitative analysis may be different, please list reqs here:<br />
<br />
#? Extract Luminance out of YBR ?<br />
# ? Need MONOCHROME1 native support, because <fill reason ??><br />
# ? Is there a need to manipulated native palette data ? I doubt so<br />
<br />
== References ==<br />
<br />
* http://gdcm.sourceforge.net/wiki/index.php/Color_Space_Transformations</div>Mathieuhttps://public.kitware.com/Wiki/index.php?title=ITK/Release_5/DICOM/Color&diff=63952ITK/Release 5/DICOM/Color2019-10-11T08:27:38Z<p>Mathieu: /* ITK 5.x */</p>
<hr />
<div>= Multiple Components in DICOM =<br />
<br />
== ITK 5.0 ==<br />
<br />
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).<br />
<br />
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.<br />
<br />
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.<br />
<br />
== Notation ==<br />
<br />
# JPEG refers to the subset of ITU-T T.81, ISO/IEC IS 10918-1 (lossy 8bits)<br />
# JPEG 2000 refers to ITU-T T.800, ISO/IEC IS 15444-1<br />
<br />
== ITK 5.x ==<br />
<br />
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.<br />
<br />
Current behavior of ITK 5.0:<br />
<br />
{| border="1" style="text-align:center"<br />
|- bgcolor="#abcdef"<br />
! Photometric Interpretation !! JPEG !! TIFF !! GDCM !! DCMTK<br />
|-<br />
! MONOCHROME1 || style="background:silver" | X || style="background:orange" |MONOCHROME2 (aka min-is-black) || style="background:lime" |MONOCHROME1 || style="background:lime" |?MONOCHROME1?<br />
|- <br />
! MONOCHROME2 || style="background:lime" | MONOCHROME2 || style="background:lime" |MONOCHROME2 (aka min-is-black) || style="background:lime" |MONOCHROME2 || style="background:lime" |MONOCHROME2<br />
|-<br />
! PALETTE_COLOR || style="background:silver" |X || style="background:orange" | RGB (??) || style="background:orange" | Converted to RGB || style="background:orange" | ?Converted to RGB? (need to check compressed LUT)<br />
|-<br />
! RGB || style="background:orange" |RGB || RGB|| RGB || ?RGB?<br />
|- style="background:silver"<br />
! HSV || || || || <br />
|- style="background:silver"<br />
! ARGB || || || || <br />
|- style="background:silver"<br />
! CMYK || || || || <br />
|-<br />
! YBR_FULL || style="background:silver" |ITU 81 enforce sub-sampling|| ?? || YBR_FULL || ??<br />
|-<br />
! YBR_FULL_422 || style="background:orange" |RGB || style="background:orange" |RGB || YBR_FULL || ??Maybe RGB?<br />
|- style="background:silver"<br />
! YBR_PARTIAL_422 || || || || <br />
|- style="background:silver"<br />
! YBR_PARTIAL_420 || || || || <br />
|-<br />
! YBR_ICT || style="background:silver" |ITU 81 does not support this colorspace || ?? || RGB || style="background:red" |no J2K plugin<br />
|-<br />
! YBR_RCT || style="background:silver" |ITU 81 does not support this colorspace || ?? || RGB || style="background:red" |no J2K plugin<br />
|-<br />
|}<br />
<br />
<br />
Desired behavior of ITK 5.0:<br />
<br />
{| border="1" style="text-align:center"<br />
|- bgcolor="#abcdef"<br />
! Photometric Interpretation !! JPEG !! TIFF !! GDCM !! DCMTK<br />
|-<br />
! MONOCHROME1 || style="background:silver" | X || style="background:orange" |MONOCHROME2 (aka min-is-black)|| style="background:lime" |MONOCHROME1 || style="background:lime" |?MONOCHROME1?<br />
|- <br />
! MONOCHROME2 || style="background:lime" | MONOCHROME2 || style="background:lime" |MONOCHROME2 (aka min-is-black)|| style="background:lime" |MONOCHROME2 || style="background:lime" |MONOCHROME2<br />
|-<br />
! PALETTE_COLOR || style="background:silver" | X || style="background:orange" | RGB || style="background:orange" | Converted to RGB || style="background:orange" | ??<br />
|-<br />
! RGB || style="background:orange" |RGB || RGB|| RGB || ?RGB?<br />
|- style="background:silver"<br />
! HSV || || || || <br />
|- style="background:silver"<br />
! ARGB || || || || <br />
|- style="background:silver"<br />
! CMYK || || || || <br />
|-<br />
! YBR_FULL || style="background:silver" |ITU 81 enforce sub-sampling|| ?? || RGB || ??<br />
|-<br />
! YBR_FULL_422 || style="background:orange" |RGB || style="background:orange" |RGB || RGB || ??Maybe RGB?<br />
|- style="background:silver"<br />
! YBR_PARTIAL_422 || || || || <br />
|- style="background:silver"<br />
! YBR_PARTIAL_420 || || || || <br />
|-<br />
! YBR_ICT || || || RGB || style="background:red" |no J2K plugin<br />
|-<br />
! YBR_RCT || || || RGB || style="background:red" |no J2K plugin<br />
|-<br />
|}<br />
<br />
<br />
Summary:<br />
<br />
For Viz people it is important that:<br />
<br />
# MONOCHROME1 (min-is-white) is converted to MONOCHROME2 (min-is-black) <br />
# YBR_FULL / YBR_FULL_422 are converted to RGB<br />
<br />
The requirements for quantitative analysis may be different, please list reqs here:<br />
<br />
#? Extract Luminance out of YBR ?<br />
# ? Need MONOCHROME1 native support, because <fill reason ??><br />
# ? Is there a need to manipulated native palette data ? I doubt so<br />
<br />
== References ==<br />
<br />
* http://gdcm.sourceforge.net/wiki/index.php/Color_Space_Transformations</div>Mathieuhttps://public.kitware.com/Wiki/index.php?title=ITK/Release_5/DICOM/Color&diff=63951ITK/Release 5/DICOM/Color2019-10-11T08:25:51Z<p>Mathieu: /* ITK 5.x */</p>
<hr />
<div>= Multiple Components in DICOM =<br />
<br />
== ITK 5.0 ==<br />
<br />
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).<br />
<br />
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.<br />
<br />
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.<br />
<br />
== ITK 5.x ==<br />
<br />
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.<br />
<br />
Current behavior of ITK 5.0:<br />
<br />
{| border="1" style="text-align:center"<br />
|- bgcolor="#abcdef"<br />
! Photometric Interpretation !! JPEG !! TIFF !! GDCM !! DCMTK<br />
|-<br />
! MONOCHROME1 || style="background:silver" | X || style="background:orange" |MONOCHROME2 (aka min-is-black) || style="background:lime" |MONOCHROME1 || style="background:lime" |?MONOCHROME1?<br />
|- <br />
! MONOCHROME2 || style="background:lime" | MONOCHROME2 || style="background:lime" |MONOCHROME2 (aka min-is-black) || style="background:lime" |MONOCHROME2 || style="background:lime" |MONOCHROME2<br />
|-<br />
! PALETTE_COLOR || style="background:silver" |X || style="background:orange" | RGB (??) || style="background:orange" | Converted to RGB || style="background:orange" | ?Converted to RGB? (need to check compressed LUT)<br />
|-<br />
! RGB || style="background:orange" |RGB || RGB|| RGB || ?RGB?<br />
|- style="background:silver"<br />
! HSV || || || || <br />
|- style="background:silver"<br />
! ARGB || || || || <br />
|- style="background:silver"<br />
! CMYK || || || || <br />
|-<br />
! YBR_FULL || style="background:silver" |ITU 81 enforce sub-sampling|| ?? || YBR_FULL || ??<br />
|-<br />
! YBR_FULL_422 || style="background:orange" |RGB || style="background:orange" |RGB || YBR_FULL || ??Maybe RGB?<br />
|- style="background:silver"<br />
! YBR_PARTIAL_422 || || || || <br />
|- style="background:silver"<br />
! YBR_PARTIAL_420 || || || || <br />
|-<br />
! YBR_ICT || style="background:silver" |ITU 81 does not support this colorspace || ?? || RGB || style="background:red" |no J2K plugin<br />
|-<br />
! YBR_RCT || style="background:silver" |ITU 81 does not support this colorspace || ?? || RGB || style="background:red" |no J2K plugin<br />
|-<br />
|}<br />
<br />
<br />
Desired behavior of ITK 5.0:<br />
<br />
{| border="1" style="text-align:center"<br />
|- bgcolor="#abcdef"<br />
! Photometric Interpretation !! JPEG !! TIFF !! GDCM !! DCMTK<br />
|-<br />
! MONOCHROME1 || style="background:silver" | X || style="background:orange" |MONOCHROME2 (aka min-is-black)|| style="background:lime" |MONOCHROME1 || style="background:lime" |?MONOCHROME1?<br />
|- <br />
! MONOCHROME2 || style="background:lime" | MONOCHROME2 || style="background:lime" |MONOCHROME2 (aka min-is-black)|| style="background:lime" |MONOCHROME2 || style="background:lime" |MONOCHROME2<br />
|-<br />
! PALETTE_COLOR || style="background:silver" | X || style="background:orange" | RGB || style="background:orange" | Converted to RGB || style="background:orange" | ??<br />
|-<br />
! RGB || style="background:orange" |RGB || RGB|| RGB || ?RGB?<br />
|- style="background:silver"<br />
! HSV || || || || <br />
|- style="background:silver"<br />
! ARGB || || || || <br />
|- style="background:silver"<br />
! CMYK || || || || <br />
|-<br />
! YBR_FULL || style="background:silver" |ITU 81 enforce sub-sampling|| ?? || RGB || ??<br />
|-<br />
! YBR_FULL_422 || style="background:orange" |RGB || style="background:orange" |RGB || RGB || ??Maybe RGB?<br />
|- style="background:silver"<br />
! YBR_PARTIAL_422 || || || || <br />
|- style="background:silver"<br />
! YBR_PARTIAL_420 || || || || <br />
|-<br />
! YBR_ICT || || || RGB || style="background:red" |no J2K plugin<br />
|-<br />
! YBR_RCT || || || RGB || style="background:red" |no J2K plugin<br />
|-<br />
|}<br />
<br />
<br />
Summary:<br />
<br />
For Viz people it is important that:<br />
<br />
# MONOCHROME1 (min-is-white) is converted to MONOCHROME2 (min-is-black) <br />
# YBR_FULL / YBR_FULL_422 are converted to RGB<br />
<br />
The requirements for quantitative analysis may be different, please list reqs here:<br />
<br />
#? Extract Luminance out of YBR ?<br />
# ? Need MONOCHROME1 native support, because <fill reason ??><br />
# ? Is there a need to manipulated native palette data ? I doubt so<br />
<br />
== References ==<br />
<br />
* http://gdcm.sourceforge.net/wiki/index.php/Color_Space_Transformations</div>Mathieuhttps://public.kitware.com/Wiki/index.php?title=ITK/Release_5/DICOM/Color&diff=63950ITK/Release 5/DICOM/Color2019-10-11T08:24:44Z<p>Mathieu: /* ITK 5.x */</p>
<hr />
<div>= Multiple Components in DICOM =<br />
<br />
== ITK 5.0 ==<br />
<br />
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).<br />
<br />
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.<br />
<br />
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.<br />
<br />
== ITK 5.x ==<br />
<br />
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.<br />
<br />
Current behavior of ITK 5.0:<br />
<br />
{| border="1" style="text-align:center"<br />
|- bgcolor="#abcdef"<br />
! Photometric Interpretation !! JPEG !! TIFF !! GDCM !! DCMTK<br />
|-<br />
! MONOCHROME1 || style="background:silver" | X || style="background:orange" |MONOCHROME2 (aka min-is-black) || style="background:lime" |MONOCHROME1 || style="background:lime" |?MONOCHROME1?<br />
|- <br />
! MONOCHROME2 || style="background:lime" | MONOCHROME2 || style="background:lime" |MONOCHROME2 (aka min-is-black) || style="background:lime" |MONOCHROME2 || style="background:lime" |MONOCHROME2<br />
|-<br />
! PALETTE_COLOR || style="background:silver" |X || style="background:orange" | RGB (??) || style="background:orange" | Converted to RGB || style="background:orange" | ?Converted to RGB? (need to check compressed LUT)<br />
|-<br />
! RGB || style="background:orange" |RGB || RGB|| RGB || ?RGB?<br />
|- style="background:silver"<br />
! HSV || || || || <br />
|- style="background:silver"<br />
! ARGB || || || || <br />
|- style="background:silver"<br />
! CMYK || || || || <br />
|-<br />
! YBR_FULL || style="background:silver" |ITU 81 enforce sub-sampling|| ?? || YBR_FULL || ??<br />
|-<br />
! YBR_FULL_422 || style="background:orange" |RGB || style="background:orange" |RGB || YBR_FULL || ??Maybe RGB?<br />
|- style="background:silver"<br />
! YBR_PARTIAL_422 || || || || <br />
|- style="background:silver"<br />
! YBR_PARTIAL_420 || || || || <br />
|-<br />
! YBR_ICT || style="background:silver" |ITU 81 does not support this colorspace || ?? || RGB || style="background:red" |no J2K plugin<br />
|-<br />
! YBR_RCT || style="background:silver" |ITU 81 does not support this colorspace || ?? || RGB || style="background:red" |no J2K plugin<br />
|-<br />
|}<br />
<br />
<br />
Desired behavior of ITK 5.0:<br />
<br />
{| border="1" style="text-align:center"<br />
|- bgcolor="#abcdef"<br />
! Photometric Interpretation !! JPEG !! TIFF !! GDCM !! DCMTK<br />
|-<br />
! MONOCHROME1 || style="background:silver" | X || style="background:orange" |MONOCHROME2 (aka min-is-black)|| style="background:lime" |MONOCHROME1 || style="background:lime" |?MONOCHROME1?<br />
|- <br />
! MONOCHROME2 || style="background:lime" | MONOCHROME2 || style="background:lime" |MONOCHROME2 (aka min-is-black)|| style="background:lime" |MONOCHROME2 || style="background:lime" |MONOCHROME2<br />
|-<br />
! PALETTE_COLOR || style="background:silver" | X || style="background:lime" | PALETTE_COLOR || style="background:orange" | Converted to RGB || style="background:orange" | ??<br />
|-<br />
! RGB || style="background:orange" |RGB || RGB|| RGB || ?RGB?<br />
|- style="background:silver"<br />
! HSV || || || || <br />
|- style="background:silver"<br />
! ARGB || || || || <br />
|- style="background:silver"<br />
! CMYK || || || || <br />
|-<br />
! YBR_FULL || style="background:silver" |ITU 81 enforce sub-sampling|| ?? || RGB || ??<br />
|-<br />
! YBR_FULL_422 || style="background:orange" |RGB || style="background:orange" |RGB || RGB || ??Maybe RGB?<br />
|- style="background:silver"<br />
! YBR_PARTIAL_422 || || || || <br />
|- style="background:silver"<br />
! YBR_PARTIAL_420 || || || || <br />
|-<br />
! YBR_ICT || || || RGB || style="background:red" |no J2K plugin<br />
|-<br />
! YBR_RCT || || || RGB || style="background:red" |no J2K plugin<br />
|-<br />
|}<br />
<br />
<br />
Summary:<br />
<br />
For Viz people it is important that:<br />
<br />
# MONOCHROME1 (min-is-white) is converted to MONOCHROME2 (min-is-black) <br />
# YBR_FULL / YBR_FULL_422 are converted to RGB<br />
<br />
The requirements for quantitative analysis may be different, please list reqs here:<br />
<br />
#? Extract Luminance out of YBR ?<br />
# ? Need MONOCHROME1 native support, because <fill reason ??><br />
<br />
== References ==<br />
<br />
* http://gdcm.sourceforge.net/wiki/index.php/Color_Space_Transformations</div>Mathieuhttps://public.kitware.com/Wiki/index.php?title=ITK/Release_5/DICOM/Color&diff=63949ITK/Release 5/DICOM/Color2019-10-11T08:23:18Z<p>Mathieu: /* ITK 5.x */</p>
<hr />
<div>= Multiple Components in DICOM =<br />
<br />
== ITK 5.0 ==<br />
<br />
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).<br />
<br />
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.<br />
<br />
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.<br />
<br />
== ITK 5.x ==<br />
<br />
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.<br />
<br />
Current behavior of ITK 5.0:<br />
<br />
{| border="1" style="text-align:center"<br />
|- bgcolor="#abcdef"<br />
! Photometric Interpretation !! JPEG !! TIFF !! GDCM !! DCMTK<br />
|-<br />
! MONOCHROME1 || style="background:silver" | X || style="background:orange" |MONOCHROME2 (aka min-is-black) || style="background:lime" |MONOCHROME1 || style="background:lime" |?MONOCHROME1?<br />
|- <br />
! MONOCHROME2 || style="background:lime" | MONOCHROME2 || style="background:lime" |MONOCHROME2 (aka min-is-black) || style="background:lime" |MONOCHROME2 || style="background:lime" |MONOCHROME2<br />
|-<br />
! PALETTE_COLOR || style="background:silver" |X || style="background:orange" | RGB (??) || style="background:orange" | Converted to RGB || style="background:orange" | ?Converted to RGB? (need to check compressed LUT)<br />
|-<br />
! RGB || style="background:orange" |RGB || RGB|| RGB || ?RGB?<br />
|- style="background:silver"<br />
! HSV || || || || <br />
|- style="background:silver"<br />
! ARGB || || || || <br />
|- style="background:silver"<br />
! CMYK || || || || <br />
|-<br />
! YBR_FULL || style="background:silver" |ITU 81 enforce sub-sampling|| ?? || YBR_FULL || ??<br />
|-<br />
! YBR_FULL_422 || style="background:orange" |RGB || style="background:orange" |RGB || YBR_FULL || ??Maybe RGB?<br />
|- style="background:silver"<br />
! YBR_PARTIAL_422 || || || || <br />
|- style="background:silver"<br />
! YBR_PARTIAL_420 || || || || <br />
|-<br />
! YBR_ICT || style="background:silver" |ITU 81 does not support this colorspace || ?? || RGB || style="background:red" |no J2K plugin<br />
|-<br />
! YBR_RCT || style="background:silver" |ITU 81 does not support this colorspace || ?? || RGB || style="background:red" |no J2K plugin<br />
|-<br />
|}<br />
<br />
<br />
Desired behavior of ITK 5.0:<br />
<br />
{| border="1" style="text-align:center"<br />
|- bgcolor="#abcdef"<br />
! Photometric Interpretation !! JPEG !! TIFF !! GDCM !! DCMTK<br />
|-<br />
! MONOCHROME1 || style="background:silver" | X || style="background:orange" |MONOCHROME2 (aka min-is-black)|| style="background:lime" |MONOCHROME1 || style="background:lime" |?MONOCHROME1?<br />
|- <br />
! MONOCHROME2 || style="background:lime" | MONOCHROME2 || style="background:lime" |MONOCHROME2 (aka min-is-black)|| style="background:lime" |MONOCHROME2 || style="background:lime" |MONOCHROME2<br />
|-<br />
! PALETTE_COLOR || style="background:silver" | X || style="background:lime" | PALETTE_COLOR || style="background:orange" | Converted to RGB || style="background:orange" | ??<br />
|-<br />
! RGB || style="background:orange" |RGB || RGB|| RGB || ?RGB?<br />
|- style="background:silver"<br />
! HSV || || || || <br />
|- style="background:silver"<br />
! ARGB || || || || <br />
|- style="background:silver"<br />
! CMYK || || || || <br />
|-<br />
! YBR_FULL || style="background:silver" |ITU 81 enforce sub-sampling|| ?? || RGB || ??<br />
|-<br />
! YBR_FULL_422 || style="background:orange" |RGB || style="background:orange" |RGB || RGB || ??Maybe RGB?<br />
|- style="background:silver"<br />
! YBR_PARTIAL_422 || || || || <br />
|- style="background:silver"<br />
! YBR_PARTIAL_420 || || || || <br />
|-<br />
! YBR_ICT || || || RGB || style="background:red" |no J2K plugin<br />
|-<br />
! YBR_RCT || || || RGB || style="background:red" |no J2K plugin<br />
|-<br />
|}<br />
<br />
<br />
Summary:<br />
<br />
For Viz people it is important that:<br />
<br />
# MONOCHROME1 (min-is-white) is converted to MONOCHROME2 (min-is-black) <br />
# YBR_FULL / YBR_FULL_422 are converted to RGB<br />
<br />
The requirements for quantitative analysis may be different, please list reqs here:<br />
<br />
#? Extract Luminance out of YBR ?<br />
# ? Need MONOCHROME1 native support, because <fill reason ??></div>Mathieuhttps://public.kitware.com/Wiki/index.php?title=ITK/Release_5/DICOM/Color&diff=63948ITK/Release 5/DICOM/Color2019-10-11T08:22:27Z<p>Mathieu: /* ITK 5.x */</p>
<hr />
<div>= Multiple Components in DICOM =<br />
<br />
== ITK 5.0 ==<br />
<br />
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).<br />
<br />
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.<br />
<br />
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.<br />
<br />
== ITK 5.x ==<br />
<br />
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.<br />
<br />
Current behavior of ITK 5.0:<br />
<br />
{| border="1" style="text-align:center"<br />
|- bgcolor="#abcdef"<br />
! Photometric Interpretation !! JPEG !! TIFF !! GDCM !! DCMTK<br />
|-<br />
! MONOCHROME1 || style="background:silver" | X || style="background:orange" |MONOCHROME2 (aka min-is-black) || style="background:lime" |MONOCHROME1 || style="background:lime" |?MONOCHROME1?<br />
|- <br />
! MONOCHROME2 || style="background:lime" | MONOCHROME2 || style="background:lime" |MONOCHROME2 (aka min-is-black) || style="background:lime" |MONOCHROME2 || style="background:lime" |MONOCHROME2<br />
|-<br />
! PALETTE_COLOR || style="background:silver" |X || style="background:orange" | RGB (??) || style="background:orange" | Converted to RGB || style="background:orange" | ?Converted to RGB? (need to check compressed LUT)<br />
|-<br />
! RGB || style="background:orange" |RGB || RGB|| RGB || ?RGB?<br />
|- style="background:silver"<br />
! HSV || || || || <br />
|- style="background:silver"<br />
! ARGB || || || || <br />
|- style="background:silver"<br />
! CMYK || || || || <br />
|-<br />
! YBR_FULL || style="background:silver" |ITK 81 enforce sub-sampling|| ?? || YBR_FULL || ??<br />
|-<br />
! YBR_FULL_422 || style="background:orange" |RGB || style="background:orange" |RGB || YBR_FULL || ??Maybe RGB?<br />
|- style="background:silver"<br />
! YBR_PARTIAL_422 || || || || <br />
|- style="background:silver"<br />
! YBR_PARTIAL_420 || || || || <br />
|-<br />
! YBR_ICT || style="background:silver" |ITU 81 does not support this colorspace || ?? || RGB || style="background:red" |no J2K plugin<br />
|-<br />
! YBR_RCT || style="background:silver" |ITU 81 does not support this colorspace || ?? || RGB || style="background:red" |no J2K plugin<br />
|-<br />
|}<br />
<br />
<br />
Desired behavior of ITK 5.0:<br />
<br />
{| border="1" style="text-align:center"<br />
|- bgcolor="#abcdef"<br />
! Photometric Interpretation !! JPEG !! TIFF !! GDCM !! DCMTK<br />
|-<br />
! MONOCHROME1 || style="background:silver" | X || style="background:orange" |MONOCHROME2 (aka min-is-black)|| style="background:lime" |MONOCHROME1 || style="background:lime" |?MONOCHROME1?<br />
|- <br />
! MONOCHROME2 || style="background:lime" | MONOCHROME2 || style="background:lime" |MONOCHROME2 (aka min-is-black)|| style="background:lime" |MONOCHROME2 || style="background:lime" |MONOCHROME2<br />
|-<br />
! PALETTE_COLOR || style="background:silver" | X || style="background:lime" | PALETTE_COLOR || style="background:orange" | Converted to RGB || style="background:orange" | ??<br />
|-<br />
! RGB || style="background:orange" |RGB || RGB|| RGB || ?RGB?<br />
|- style="background:silver"<br />
! HSV || || || || <br />
|- style="background:silver"<br />
! ARGB || || || || <br />
|- style="background:silver"<br />
! CMYK || || || || <br />
|-<br />
! YBR_FULL || style="background:silver" |ITK 81 enforce sub-sampling|| ?? || RGB || ??<br />
|-<br />
! YBR_FULL_422 || style="background:orange" |RGB || style="background:orange" |RGB || RGB || ??Maybe RGB?<br />
|- style="background:silver"<br />
! YBR_PARTIAL_422 || || || || <br />
|- style="background:silver"<br />
! YBR_PARTIAL_420 || || || || <br />
|-<br />
! YBR_ICT || || || RGB || style="background:red" |no J2K plugin<br />
|-<br />
! YBR_RCT || || || RGB || style="background:red" |no J2K plugin<br />
|-<br />
|}<br />
<br />
<br />
Summary:<br />
<br />
For Viz people it is important that:<br />
<br />
# MONOCHROME1 (min-is-white) is converted to MONOCHROME2 (min-is-black) <br />
# YBR_FULL / YBR_FULL_422 are converted to RGB<br />
<br />
The requirements for quantitative analysis may be different, please list reqs here:<br />
<br />
#? Extract Luminance out of YBR ?<br />
# ? Need MONOCHROME1 native support, because <fill reason ??></div>Mathieuhttps://public.kitware.com/Wiki/index.php?title=ITK/Release_5/DICOM/Color&diff=63947ITK/Release 5/DICOM/Color2019-10-11T08:21:24Z<p>Mathieu: /* ITK 5.x */</p>
<hr />
<div>= Multiple Components in DICOM =<br />
<br />
== ITK 5.0 ==<br />
<br />
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).<br />
<br />
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.<br />
<br />
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.<br />
<br />
== ITK 5.x ==<br />
<br />
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.<br />
<br />
Current behavior of ITK 5.0:<br />
<br />
{| border="1" style="text-align:center"<br />
|- bgcolor="#abcdef"<br />
! Photometric Interpretation !! JPEG !! TIFF !! GDCM !! DCMTK<br />
|-<br />
! MONOCHROME1 || style="background:silver" | X || style="background:orange" |MONOCHROME2 (aka min-is-black) || style="background:lime" |MONOCHROME1 || style="background:lime" |?MONOCHROME1?<br />
|- <br />
! MONOCHROME2 || style="background:lime" | MONOCHROME2 || style="background:lime" |MONOCHROME2 (aka min-is-black) || style="background:lime" |MONOCHROME2 || style="background:lime" |MONOCHROME2<br />
|-<br />
! PALETTE_COLOR || style="background:silver" |X || style="background:orange" | RGB (??) || style="background:orange" | Converted to RGB || style="background:orange" | ?Converted to RGB? (need to check compressed LUT)<br />
|-<br />
! RGB || style="background:orange" |RGB || RGB|| RGB || ?RGB?<br />
|- style="background:silver"<br />
! HSV || || || || <br />
|- style="background:silver"<br />
! ARGB || || || || <br />
|- style="background:silver"<br />
! CMYK || || || || <br />
|-<br />
! YBR_FULL || style="background:silver" |ITK 81 enforce sub-sampling|| ?? || YBR_FULL || ??<br />
|-<br />
! YBR_FULL_422 || style="background:orange" |RGB || style="background:orange" |RGB || YBR_FULL || ??Maybe RGB?<br />
|- style="background:silver"<br />
! YBR_PARTIAL_422 || || || || <br />
|- style="background:silver"<br />
! YBR_PARTIAL_420 || || || || <br />
|-<br />
! YBR_ICT || style="background:silver" |ITU 81 does not support this colorspace || ?? || RGB || style="background:red" |no J2K plugin<br />
|-<br />
! YBR_RCT || style="background:silver" |ITU 81 does not support this colorspace || ?? || RGB || style="background:red" |no J2K plugin<br />
|-<br />
|}<br />
<br />
<br />
Desired behavior of ITK 5.0:<br />
<br />
{| border="1" style="text-align:center"<br />
|- bgcolor="#abcdef"<br />
! Photometric Interpretation !! JPEG !! TIFF !! GDCM !! DCMTK<br />
|-<br />
! MONOCHROME1 || style="background:silver" | X || style="background:orange" |MONOCHROME2 (aka min-is-black)|| style="background:lime" |MONOCHROME1 || style="background:lime" |?MONOCHROME1?<br />
|- <br />
! MONOCHROME2 || style="background:lime" | MONOCHROME2 || style="background:lime" |MONOCHROME2 (aka min-is-black)|| style="background:lime" |MONOCHROME2 || style="background:lime" |MONOCHROME2<br />
|-<br />
! PALETTE_COLOR || style="background:lime" |PALETTE_COLOR || style="background:lime" | PALETTE_COLOR || style="background:orange" | Converted to RGB || style="background:orange" | ??<br />
|-<br />
! RGB || style="background:orange" |RGB || RGB|| RGB || ?RGB?<br />
|- style="background:silver"<br />
! HSV || || || || <br />
|- style="background:silver"<br />
! ARGB || || || || <br />
|- style="background:silver"<br />
! CMYK || || || || <br />
|-<br />
! YBR_FULL || style="background:silver" |ITK 81 enforce sub-sampling|| ?? || RGB || ??<br />
|-<br />
! YBR_FULL_422 || style="background:orange" |RGB || style="background:orange" |RGB || RGB || ??Maybe RGB?<br />
|- style="background:silver"<br />
! YBR_PARTIAL_422 || || || || <br />
|- style="background:silver"<br />
! YBR_PARTIAL_420 || || || || <br />
|-<br />
! YBR_ICT || || || RGB || style="background:red" |no J2K plugin<br />
|-<br />
! YBR_RCT || || || RGB || style="background:red" |no J2K plugin<br />
|-<br />
|}<br />
<br />
<br />
Summary:<br />
<br />
For Viz people it is important that:<br />
<br />
# MONOCHROME1 (min-is-white) is converted to MONOCHROME2 (min-is-black) <br />
# YBR_FULL / YBR_FULL_422 are converted to RGB<br />
<br />
The requirements for quantitative analysis may be different, please list reqs here:<br />
<br />
#? Extract Luminance out of YBR ?<br />
# ? Need MONOCHROME1 native support, because <fill reason ??></div>Mathieuhttps://public.kitware.com/Wiki/index.php?title=ITK/Release_5/DICOM/Color&diff=63946ITK/Release 5/DICOM/Color2019-10-11T08:19:37Z<p>Mathieu: /* ITK 5.x */</p>
<hr />
<div>= Multiple Components in DICOM =<br />
<br />
== ITK 5.0 ==<br />
<br />
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).<br />
<br />
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.<br />
<br />
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.<br />
<br />
== ITK 5.x ==<br />
<br />
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.<br />
<br />
Current behavior of ITK 5.0:<br />
<br />
{| border="1" style="text-align:center"<br />
|- bgcolor="#abcdef"<br />
! Photometric Interpretation !! JPEG !! TIFF !! GDCM !! DCMTK<br />
|-<br />
! MONOCHROME1 || style="background:silver" | X || style="background:orange" |MONOCHROME2 (aka min-is-black) || style="background:lime" |MONOCHROME1 || style="background:lime" |?MONOCHROME1?<br />
|- <br />
! MONOCHROME2 || style="background:lime" | MONOCHROME2 || style="background:lime" |MONOCHROME2 (aka min-is-black) || style="background:lime" |MONOCHROME2 || style="background:lime" |MONOCHROME2<br />
|-<br />
! PALETTE_COLOR || style="background:silver" |X || style="background:orange" | RGB (??) || style="background:orange" | Converted to RGB || style="background:orange" | ?Converted to RGB? (need to check compressed LUT)<br />
|-<br />
! RGB || style="background:orange" |RGB || RGB|| RGB || ?RGB?<br />
|- style="background:silver"<br />
! HSV || || || || <br />
|- style="background:silver"<br />
! ARGB || || || || <br />
|- style="background:silver"<br />
! CMYK || || || || <br />
|-<br />
! YBR_FULL || style="background:silver" |ITK 81 enforce sub-sampling|| ?? || YBR_FULL || ??<br />
|-<br />
! YBR_FULL_422 || style="background:orange" |RGB || style="background:orange" |RGB || YBR_FULL || ??Maybe RGB?<br />
|- style="background:silver"<br />
! YBR_PARTIAL_422 || || || || <br />
|- style="background:silver"<br />
! YBR_PARTIAL_420 || || || || <br />
|-<br />
! YBR_ICT || style="background:silver" |ITU 81 does not support this colorspace || ?? || RGB || style="background:red" |no J2K plugin<br />
|-<br />
! YBR_RCT || style="background:silver" |ITU 81 does not support this colorspace || ?? || RGB || style="background:red" |no J2K plugin<br />
|-<br />
|}<br />
<br />
<br />
Desired behavior of ITK 5.0:<br />
<br />
{| border="1" style="text-align:center"<br />
|- bgcolor="#abcdef"<br />
! Photometric Interpretation !! JPEG !! TIFF !! GDCM !! DCMTK<br />
|-<br />
! MONOCHROME1 || style="background:silver" | X || style="background:orange" |MONOCHROME2 (aka min-is-black)|| style="background:lime" |MONOCHROME1 || style="background:lime" |?MONOCHROME1?<br />
|- <br />
! MONOCHROME2 || style="background:lime" | MONOCHROME2 || style="background:lime" |MONOCHROME2 (aka min-is-black)|| style="background:lime" |MONOCHROME2 || style="background:lime" |MONOCHROME2<br />
|-<br />
! PALETTE_COLOR || style="background:lime" |PALETTE_COLOR || style="background:lime" | PALETTE_COLOR || style="background:orange" | Converted to RGB || style="background:orange" | ??<br />
|-<br />
! RGB || style="background:orange" |RGB || RGB|| RGB || ?RGB?<br />
|- style="background:silver"<br />
! HSV || || || || <br />
|- style="background:silver"<br />
! ARGB || || || || <br />
|- style="background:silver"<br />
! CMYK || || || || <br />
|-<br />
! YBR_FULL || style="background:silver" |ITK 81 enforce sub-sampling|| ?? || RGB || ??<br />
|-<br />
! YBR_FULL_422 || style="background:orange" |RGB || style="background:orange" |RGB || RGB || ??Maybe RGB?<br />
|- style="background:silver"<br />
! YBR_PARTIAL_422 || || || || <br />
|- style="background:silver"<br />
! YBR_PARTIAL_420 || || || || <br />
|-<br />
! YBR_ICT || || || RGB || style="background:red" |no J2K plugin<br />
|-<br />
! YBR_RCT || || || RGB || style="background:red" |no J2K plugin<br />
|-<br />
|}</div>Mathieuhttps://public.kitware.com/Wiki/index.php?title=ITK/Release_5/DICOM/Color&diff=63945ITK/Release 5/DICOM/Color2019-10-11T08:16:42Z<p>Mathieu: /* ITK 5.x */</p>
<hr />
<div>= Multiple Components in DICOM =<br />
<br />
== ITK 5.0 ==<br />
<br />
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).<br />
<br />
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.<br />
<br />
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.<br />
<br />
== ITK 5.x ==<br />
<br />
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.<br />
<br />
Current behavior of ITK 5.0:<br />
<br />
{| border="1" style="text-align:center"<br />
|- bgcolor="#abcdef"<br />
! Photometric Interpretation !! JPEG !! TIFF !! GDCM !! DCMTK<br />
|-<br />
! MONOCHROME1 || style="background:silver" | X || style="background:orange" |MONOCHROME2 || style="background:lime" |MONOCHROME1 || style="background:lime" |?MONOCHROME1?<br />
|- <br />
! MONOCHROME2 || style="background:lime" | MONOCHROME2 || style="background:lime" |MONOCHROME2 || style="background:lime" |MONOCHROME2 || style="background:lime" |MONOCHROME2<br />
|-<br />
! PALETTE_COLOR || style="background:silver" |X || style="background:orange" | RGB (??) || style="background:orange" | Converted to RGB || style="background:orange" | ?Converted to RGB? (need to check compressed LUT)<br />
|-<br />
! RGB || style="background:orange" |RGB || RGB|| RGB || ?RGB?<br />
|- style="background:silver"<br />
! HSV || || || || <br />
|- style="background:silver"<br />
! ARGB || || || || <br />
|- style="background:silver"<br />
! CMYK || || || || <br />
|-<br />
! YBR_FULL || style="background:silver" |ITK 81 enforce sub-sampling|| ?? || YBR_FULL || ??<br />
|-<br />
! YBR_FULL_422 || style="background:orange" |RGB || style="background:orange" |RGB || YBR_FULL || ??Maybe RGB?<br />
|- style="background:silver"<br />
! YBR_PARTIAL_422 || || || || <br />
|- style="background:silver"<br />
! YBR_PARTIAL_420 || || || || <br />
|-<br />
! YBR_ICT || style="background:silver" |ITU 81 does not support this colorspace || ?? || RGB || style="background:red" |no J2K plugin<br />
|-<br />
! YBR_RCT || style="background:silver" |ITU 81 does not support this colorspace || ?? || RGB || style="background:red" |no J2K plugin<br />
|-<br />
|}<br />
<br />
<br />
Desired behavior of ITK 5.0:<br />
<br />
{| border="1" style="text-align:center"<br />
|- bgcolor="#abcdef"<br />
! Photometric Interpretation !! JPEG !! TIFF !! GDCM !! DCMTK<br />
|-<br />
! MONOCHROME1 || style="background:lime" | MONOCHROME1 || style="background:orange" |MONOCHROME2 || style="background:lime" |MONOCHROME1 || style="background:lime" |?MONOCHROME1?<br />
|- <br />
! MONOCHROME2 || style="background:lime" | MONOCHROME2 || style="background:lime" |MONOCHROME2 || style="background:lime" |MONOCHROME2 || style="background:lime" |MONOCHROME2<br />
|-<br />
! PALETTE_COLOR || style="background:lime" |PALETTE_COLOR || style="background:lime" | PALETTE_COLOR || style="background:orange" | Converted to RGB || style="background:orange" | ??<br />
|-<br />
! RGB || style="background:orange" |RGB || RGB|| RGB || ?RGB?<br />
|- style="background:silver"<br />
! HSV || || || || <br />
|- style="background:silver"<br />
! ARGB || || || || <br />
|- style="background:silver"<br />
! CMYK || || || || <br />
|-<br />
! YBR_FULL || style="background:silver" |ITK 81 enforce sub-sampling|| ?? || RGB || ??<br />
|-<br />
! YBR_FULL_422 || style="background:orange" |RGB || style="background:orange" |RGB || RGB || ??Maybe RGB?<br />
|- style="background:silver"<br />
! YBR_PARTIAL_422 || || || || <br />
|- style="background:silver"<br />
! YBR_PARTIAL_420 || || || || <br />
|-<br />
! YBR_ICT || || || RGB || style="background:red" |no J2K plugin<br />
|-<br />
! YBR_RCT || || || RGB || style="background:red" |no J2K plugin<br />
|-<br />
|}</div>Mathieuhttps://public.kitware.com/Wiki/index.php?title=ITK/Release_5/DICOM/Color&diff=63944ITK/Release 5/DICOM/Color2019-10-11T08:14:12Z<p>Mathieu: /* ITK 5.x */</p>
<hr />
<div>= Multiple Components in DICOM =<br />
<br />
== ITK 5.0 ==<br />
<br />
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).<br />
<br />
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.<br />
<br />
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.<br />
<br />
== ITK 5.x ==<br />
<br />
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.<br />
<br />
Current behavior of ITK 5.0:<br />
<br />
{| border="1" style="text-align:center"<br />
|- bgcolor="#abcdef"<br />
! Photometric Interpretation !! JPEG !! TIFF !! GDCM !! DCMTK<br />
|-<br />
! MONOCHROME1 || style="background:lime" | MONOCHROME1 || style="background:orange" |MONOCHROME2 || style="background:lime" |MONOCHROME1 || style="background:lime" |?MONOCHROME1?<br />
|- <br />
! MONOCHROME2 || style="background:lime" | MONOCHROME2 || style="background:lime" |MONOCHROME2 || style="background:lime" |MONOCHROME2 || style="background:lime" |MONOCHROME2<br />
|-<br />
! PALETTE_COLOR || style="background:lime" |PALETTE_COLOR || style="background:lime" | PALETTE_COLOR || style="background:orange" | Converted to RGB || style="background:orange" | ??<br />
|-<br />
! RGB || style="background:orange" |RGB || RGB|| RGB || ?RGB?<br />
|- style="background:silver"<br />
! HSV || || || || <br />
|- style="background:silver"<br />
! ARGB || || || || <br />
|- style="background:silver"<br />
! CMYK || || || || <br />
|-<br />
! YBR_FULL || style="background:silver" |ITK 81 enforce sub-sampling|| ?? || YBR_FULL || ??<br />
|-<br />
! YBR_FULL_422 || style="background:orange" |RGB || style="background:orange" |RGB || YBR_FULL || ??Maybe RGB?<br />
|- style="background:silver"<br />
! YBR_PARTIAL_422 || || || || <br />
|- style="background:silver"<br />
! YBR_PARTIAL_420 || || || || <br />
|-<br />
! YBR_ICT || || || RGB || style="background:red" |no J2K plugin<br />
|-<br />
! YBR_RCT || || || RGB || style="background:red" |no J2K plugin<br />
|-<br />
|}<br />
<br />
<br />
Desired behavior of ITK 5.0:<br />
<br />
{| border="1" style="text-align:center"<br />
|- bgcolor="#abcdef"<br />
! Photometric Interpretation !! JPEG !! TIFF !! GDCM !! DCMTK<br />
|-<br />
! MONOCHROME1 || style="background:lime" | MONOCHROME1 || style="background:orange" |MONOCHROME2 || style="background:lime" |MONOCHROME1 || style="background:lime" |?MONOCHROME1?<br />
|- <br />
! MONOCHROME2 || style="background:lime" | MONOCHROME2 || style="background:lime" |MONOCHROME2 || style="background:lime" |MONOCHROME2 || style="background:lime" |MONOCHROME2<br />
|-<br />
! PALETTE_COLOR || style="background:lime" |PALETTE_COLOR || style="background:lime" | PALETTE_COLOR || style="background:orange" | Converted to RGB || style="background:orange" | ??<br />
|-<br />
! RGB || style="background:orange" |RGB || RGB|| RGB || ?RGB?<br />
|- style="background:silver"<br />
! HSV || || || || <br />
|- style="background:silver"<br />
! ARGB || || || || <br />
|- style="background:silver"<br />
! CMYK || || || || <br />
|-<br />
! YBR_FULL || style="background:silver" |ITK 81 enforce sub-sampling|| ?? || RGB || ??<br />
|-<br />
! YBR_FULL_422 || style="background:orange" |RGB || style="background:orange" |RGB || RGB || ??Maybe RGB?<br />
|- style="background:silver"<br />
! YBR_PARTIAL_422 || || || || <br />
|- style="background:silver"<br />
! YBR_PARTIAL_420 || || || || <br />
|-<br />
! YBR_ICT || || || RGB || style="background:red" |no J2K plugin<br />
|-<br />
! YBR_RCT || || || RGB || style="background:red" |no J2K plugin<br />
|-<br />
|}</div>Mathieuhttps://public.kitware.com/Wiki/index.php?title=ITK/Release_5/DICOM/Color&diff=63943ITK/Release 5/DICOM/Color2019-10-11T08:13:18Z<p>Mathieu: /* ITK 5.x */</p>
<hr />
<div>= Multiple Components in DICOM =<br />
<br />
== ITK 5.0 ==<br />
<br />
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).<br />
<br />
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.<br />
<br />
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.<br />
<br />
== ITK 5.x ==<br />
<br />
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.<br />
<br />
Current behavior of ITK 5.0:<br />
<br />
{| border="1" style="text-align:center"<br />
|- bgcolor="#abcdef"<br />
! Photometric Interpretation !! JPEG !! TIFF !! GDCM !! DCMTK<br />
|-<br />
! MONOCHROME1 || style="background:lime" | MONOCHROME1 || style="background:orange" |MONOCHROME2 || style="background:lime" |MONOCHROME1 || style="background:lime" |?MONOCHROME1?<br />
|- <br />
! MONOCHROME2 || style="background:lime" | MONOCHROME2 || style="background:lime" |MONOCHROME2 || style="background:lime" |MONOCHROME2 || style="background:lime" |MONOCHROME2<br />
|-<br />
! PALETTE_COLOR || style="background:lime" |PALETTE_COLOR || style="background:lime" | PALETTE_COLOR || style="background:orange" | Converted to RGB || style="background:orange" | ??<br />
|-<br />
! RGB || style="background:orange" |RGB || RGB|| RGB || ?RGB?<br />
|- style="background:silver"<br />
! HSV || || || || <br />
|- style="background:silver"<br />
! ARGB || || || || <br />
|- style="background:silver"<br />
! CMYK || || || || <br />
|-<br />
! YBR_FULL || style="background:silver" |ITK 81 enforce sub-sampling|| ?? || YBR_FULL || ??<br />
|-<br />
! YBR_FULL_422 || style="background:orange" |RGB || style="background:orange" |RGB || YBR_FULL || ??Maybe RGB?<br />
|- style="background:silver"<br />
! YBR_PARTIAL_422 || || || || <br />
|- style="background:silver"<br />
! YBR_PARTIAL_420 || || || || <br />
|-<br />
! YBR_ICT || || || RGB || style="background:red" |no J2K plugin<br />
|-<br />
! YBR_RCT || || || RGB || style="background:red" |no J2K plugin<br />
|-<br />
|}</div>Mathieuhttps://public.kitware.com/Wiki/index.php?title=ITK/Release_5/DICOM/Color&diff=63942ITK/Release 5/DICOM/Color2019-10-11T08:08:42Z<p>Mathieu: Created page with "= 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..."</p>
<hr />
<div>= Multiple Components in DICOM =<br />
<br />
== ITK 5.0 ==<br />
<br />
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).<br />
<br />
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.<br />
<br />
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.<br />
<br />
== ITK 5.x ==<br />
<br />
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.<br />
<br />
Current behavior of ITK 5.0:<br />
<br />
{| border="1" style="text-align:center"<br />
|- bgcolor="#abcdef"<br />
! Photometric Interpretation !! JPEG !! TIFF !! GDCM !! DCMTK<br />
|-<br />
! MONOCHROME1 || style="background:lime" | MONOCHROME1 || style="background:orange" |MONOCHROME2 || style="background:lime" |MONOCHROME1 || style="background:lime" |?MONOCHROME1?<br />
|- <br />
! MONOCHROME2 || style="background:lime" | MONOCHROME2 || style="background:lime" |MONOCHROME2 || style="background:lime" |MONOCHROME2 || style="background:lime" |MONOCHROME2<br />
|-<br />
! PALETTE_COLOR || style="background:lime" |PALETTE_COLOR || style="background:lime" | PALETTE_COLOR || style="background:orange" | Converted to RGB || style="background:orange" | ??<br />
|-<br />
! RGB || style="background:orange" |RGB || RGB|| RGB || ?RGB?<br />
|- style="background:silver"<br />
! HSV || || || || <br />
|- style="background:silver"<br />
! ARGB || || || || <br />
|- style="background:silver"<br />
! CMYK || || || || <br />
|-<br />
! YBR_FULL || style="background:lime" |YBR_FULL || style="background:orange" |YBR_FULL || ?? || ??<br />
|-<br />
! YBR_FULL_422 || || || || <br />
|-<br />
! YBR_PARTIAL_422 || || || || <br />
|-<br />
! YBR_PARTIAL_420 || || || || <br />
|-<br />
! YBR_ICT || || || || <br />
|-<br />
! YBR_RCT || || || || <br />
|-<br />
|}</div>Mathieuhttps://public.kitware.com/Wiki/index.php?title=ITK/Release_5/DICOM&diff=63941ITK/Release 5/DICOM2019-10-11T07:50:35Z<p>Mathieu: /* Improve the support for DICOM in ITK */</p>
<hr />
<div>'''Improving DICOM Support'''<br />
<br />
= Goals =<br />
<br />
== Improve the support for DICOM in ITK ==<br />
<br />
# [[ITK/Release_5/DICOM/Color|DICOM with more than one component]]<br />
# [[ITK/Release_5/DICOM/PixelSpacing|DICOM and Pixel Spacing]]</div>Mathieuhttps://public.kitware.com/Wiki/index.php?title=ITK/Release_5&diff=63940ITK/Release 52019-10-11T07:49:24Z<p>Mathieu: </p>
<hr />
<div>= Overview =<br />
<br />
* [[ITK/Release_5.0|Release 5.0]]<br />
<br />
= Topics =<br />
<br />
** [[ITK/Release_5/DICOM|DICOM]]</div>Mathieuhttps://public.kitware.com/Wiki/index.php?title=ITK/Release_5/DICOM&diff=63939ITK/Release 5/DICOM2019-10-11T07:48:15Z<p>Mathieu: </p>
<hr />
<div>'''Improving DICOM Support'''<br />
<br />
= Goals =<br />
<br />
== Improve the support for DICOM in ITK ==<br />
<br />
# DICOM with more than one component<br />
# DICOM and Pixel Spacing</div>Mathieuhttps://public.kitware.com/Wiki/index.php?title=ITK/Release_5/DICOM&diff=63938ITK/Release 5/DICOM2019-10-11T07:46:38Z<p>Mathieu: Created page with "= ITK ="</p>
<hr />
<div>= ITK =</div>Mathieuhttps://public.kitware.com/Wiki/index.php?title=ITK/Release_5&diff=63937ITK/Release 52019-10-11T07:46:18Z<p>Mathieu: Created page with "= Topics = DICOM"</p>
<hr />
<div>= Topics =<br />
<br />
DICOM</div>Mathieuhttps://public.kitware.com/Wiki/index.php?title=ITK/Git/Develop&diff=62137ITK/Git/Develop2017-11-30T08:24:18Z<p>Mathieu: /* Create a Topic */</p>
<hr />
<div>{{ Historical }}<br />
<br />
__NOTOC__<br />
<br />
This page documents how to develop ITK through [http://git-scm.com Git].<br />
See our [[ITK/Git|table of contents]] for more information.<br />
<br />
<i><br />
Git is an extremely powerful version control tool that supports many different "workflows" for indivudal development and collaboration.<br />
Here we document procedures used by the ITK development community.<br />
In the interest of simplicity and brevity we do '''not''' provide an explanation of why we use this approach.<br />
Furthermore, this is '''not''' a Git tutorial.<br />
Please see our [[Git/Resources|Git resource links]] for third-party documentation, such as the [http://git-scm.com/book/ ProGit Book].<br />
</i><br />
<br />
==Setup==<br />
<br />
Before you begin, perform initial setup:<br />
<br />
{| style="width: 100%" cellspacing="0" cellpadding="0"<br />
|-<br />
|width=60%|<br />
1.<br />
Register [[ITK/Git/Account#Gerrit|Gerrit access]] and possibly [[ITK/Git/Account#Git|Git push access]].<br />
|-<br />
|<br />
2.<br />
Optionally download our [[Media:GitITKCheatSheet.pdf|one page PDF desk reference]].<br />
|-<br />
|<br />
3.<br />
Follow the [[ITK/Git/Download#Clone|download instructions]] to create a local ITK clone:<br />
|-<br />
|<br />
:<code>$ git clone git://itk.org/ITK.git</code><br />
|align="center"|<br />
[[Git/Trouble#Firewall_Blocks_Port_9418|Connection refused]]?<br />
|-<br />
|<br />
4.<br />
Run the developer setup script to prepare your ITK work tree and create Git command aliases used below:<br />
|-<br />
|<br />
:<code>$ ./Utilities/SetupForDevelopment.sh</code><br />
|align="center"|<br />
[http://itk.org/gitweb?p=ITK.git;a=blob;f=Utilities/SetupForDevelopment.sh;hb=HEAD <code>SetupForDevelopment.sh</code>]<br />
<br/><br />
[http://git-scm.com/book/en/Getting-Started-First-Time-Git-Setup Pro Git: Setup]<br />
|}<br />
Note that if you answer 'y' to the question "Do you want to test push access to itk.org? [y/N]:", you will most likely receive the following error message: "Permission denied (publickey). fatal: Could not read from remote repository.". Only a few experienced contributors have push access. Having push access is not necessary to contribute to ITK.<br />
<br />
==Workflow==<br />
<br />
ITK development uses a [[Git/Workflow/Topic|branchy workflow]] based on topic branches.<br />
Our collaboration workflow consists of three main steps:<br />
<br />
{| style="width: 100%" cellspacing="0" cellpadding="0"<br />
|-<br />
|width=60%|<br />
1.<br />
Local Development<br />
|-<br />
|<br />
:* [[#Update|Update]]<br />
|-<br />
|<br />
:* [[#Create_a_Topic|Create a Topic]]<br />
|-<br />
|<br />
2.<br />
Code Review<br />
|-<br />
|<br />
:* [[#Share_a_Topic|Share a Topic]] (requires [[ITK/Git/Account#Gerrit|Gerrit access]])<br />
|align="center"|<br />
[http://code.google.com/p/gerrit/ Gerrit Code Review]<br />
|-<br />
|<br />
:* [[#Revise_a_Topic|Revise a Topic]]<br />
|-<br />
|<br />
3.<br />
Integrate Changes<br />
|-<br />
|<br />
:* [[#Merge_a_Topic|Merge a Topic]] (requires [[ITK/Git/Account#Git|Git push access]])<br />
|-<br />
|<br />
:* [[#Delete_a_Topic|Delete a Topic]]<br />
|}<br />
<br />
==Update==<br />
<br />
{| style="width: 100%"<br />
|-<br />
|width=60%|<br />
Update your local '''master''' branch:<br />
|-<br />
|<br />
:<code>$ git checkout master</code><br />
:<code>$ git pullall</code><br />
|align="center"|<br />
[http://schacon.github.com/git/git-checkout.html <code>git help checkout</code>]<br />
<br/><br />
[http://itk.org/gitweb?p=ITK.git;a=blob;f=Utilities/DevelopmentSetupScripts/SetupGitAliases.sh;hb=HEAD <code>alias.pullall</code>]<br />
<br/><br />
([http://schacon.github.com/git/git-pull.html <code>pull</code>] and<br />
[http://schacon.github.com/git/git-submodule.html <code>submodule</code>] <code>update</code>)<br />
|}<br />
<br />
==Create a Topic==<br />
<br />
All new work must be committed on topic branches.<br />
Name topics like you might name functions: concise but precise.<br />
A reader should have a general idea of the feature or fix to be developed given just the branch name.<br />
<br />
{| style="width: 100%"<br />
|-<br />
|width=60%|<br />
To start a new topic branch:<br />
|-<br />
|<br />
:<code>$ git fetch origin</code><br />
:{|<br />
|-<br />
|<br />
For new development, start the topic from <code>origin/master</code>:<br />
:<code>$ git checkout -b ''my-topic'' origin/master</code><br />
|-<br />
|<br />
For release branch fixes, start the topic from <code>origin/release</code>, and by convention use a topic name starting in "<code>release-</code>":<br />
:<code>$ git checkout -b ''my-topic'' origin/release</code><br />
|}<br />
|align="center"|<br />
[http://schacon.github.com/git/git-fetch.html <code>git help fetch</code>]<br />
<br/><br />
[http://schacon.github.com/git/git-checkout.html <code>git help checkout</code>]<br />
<br/><br />
[http://schacon.github.com/git/git-submodule.html <code>git help submodule</code>]<br />
<br/><br />
[http://git-scm.com/book/en/Git-Branching-Basic-Branching-and-Merging Pro Git: Basic Branching]<br />
|-<br />
|<br />
Edit files and create commits (repeat as needed). Add a prefix to your commit message (see below).<br />
|-<br />
|<br />
:<code>$ edit ''file1'' ''file2'' ''file3''</code><br />
:''(To add data follow [[ITK/Git/Develop/Data#Add_Data|these instructions]].)''<br />
:<code>$ git add ''file1'' ''file2'' ''file3''</code><br />
:<code>$ git commit</code><br />
|align="center"|<br />
[http://schacon.github.com/git/git-add.html <code>git help add</code>]<br />
<br/><br />
[http://schacon.github.com/git/git-commit.html <code>git help commit</code>]<br />
<br/><br />
[http://git-scm.com/book/en/Git-Basics-Recording-Changes-to-the-Repository Pro Git: Recording Changes]<br />
|-<br />
|<br />
''(If your change modifies the "<code>Modules/ThirdParty/KWSys/src/KWSys</code>" directory please contribute directly to [https://gitlab.kitware.com/utils/kwsys/blob/master/CONTRIBUTING.rst KWSys] instead.)''<br />
<br/><br />
''(If your change modifies the "<code>Modules/ThirdParty/MetaIO/src/MetaIO</code>" directory please contribute directly to [https://github.com/Kitware/MetaIO/blob/master/CONTRIBUTING.rst MetaIO] instead.)''<br />
|-<br />
|<br />
Standard prefixes for ITK commit messages :<br />
* BUG: Fix for runtime crash or incorrect result<br />
* COMP: Compiler error or warning fix<br />
* DOC: Documentation change<br />
* ENH: New functionality<br />
* PERF: Performance improvement<br />
* STYLE: No logic impact (indentation, comments)<br />
* WIP: Work In Progress not ready for merge<br />
|<br />
|}<br />
<br />
==Share a Topic==<br />
<br />
When a topic is ready for review and possible inclusion, share it by pushing to Gerrit.<br />
Be sure you have registered for [[ITK/Git/Account#Gerrit|Gerrit access]].<br />
<br />
{| style="width: 100%"<br />
|-<br />
|width=60%|<br />
Checkout the topic if it is not your current branch:<br />
|-<br />
|<br />
:<code>$ git checkout ''my-topic''</code><br />
|align="center"|<br />
[http://schacon.github.com/git/git-checkout.html <code>git help checkout</code>]<br />
|-<br />
|<br />
Check what commits will be pushed to Gerrit for review:<br />
|-<br />
|<br />
:<code>$ git prepush</code><br />
|align="center"|<br />
[http://itk.org/gitweb?p=ITK.git;a=blob;f=Utilities/DevelopmentSetupScripts/SetupGitAliases.sh;hb=HEAD <code>alias.prepush</code>]<br />
<br/><br />
([http://schacon.github.com/git/git-log.html <code>log</code>] <code>origin/master..</code>)<br />
|-<br />
|<br />
Push commits in your topic branch for review by the community:<br />
|-<br />
|<br />
:<code>$ git gerrit-push</code><br />
:''(If the topic adds data see [[ITK/Git/Develop/Data#Push|this note]].)''<br />
or if you started the topic from the release branch:<br />
:<code>$ git push gerrit HEAD:refs/for/release/''my-topic'' </code> <br />
|align="center"|<br />
[[ITK/Git/Account#Firewall_blocks_SSH_traffic|Connection refused]]?<br />
<br/><br />
[http://itk.org/gitweb?p=ITK.git;a=blob;f=Utilities/DevelopmentSetupScripts/SetupGitAliases.sh;hb=HEAD <code>alias.gerrit-push</code>]<br />
<br/><br />
([http://itk.org/gitweb?p=ITK.git;a=blob;f=Utilities/Git/git-gerrit-push;hb=HEAD <code>Utilities/Git/git-gerrit-push</code>])<br />
|}<br />
Find your change in the [http://review.source.kitware.com/p/ITK ITK Gerrit] instance and add [[ITK/Gerrit/Reviewers|reviewers]].<br />
<br />
==Revise a Topic==<br />
<br />
If a topic is approved during Gerrit review, skip to the [[#Merge_a_Topic|next step]].<br />
Otherwise, revise the topic and push it back to Gerrit for another review.<br />
<br />
{| style="width: 100%"<br />
|-<br />
|width=60%|<br />
Checkout the topic if it is not your current branch:<br />
|-<br />
|<br />
:<code>$ git checkout ''my-topic''</code><br />
|align="center"|<br />
[http://schacon.github.com/git/git-checkout.html <code>git help checkout</code>]<br />
|-<br />
|<br />
To revise the most recent commit on the topic edit files and add changes normally and then amend the commit:<br />
|-<br />
|<br />
:<code>$ git commit --amend</code><br />
|align="center"|<br />
[http://schacon.github.com/git/git-commit.html <code>git help commit</code>]<br />
<br/><br />
[http://git-scm.com/book/en/Git-Tools-Rewriting-History#Changing-the-Last-Commit Pro Git: Changing the Last Commit]<br />
|-<br />
|<br />
To revise commits further back on the topic, say the <code>3</code>rd commit back:<br />
|-<br />
|<br />
:<code>$ git rebase -i HEAD~3</code><br />
''(Substitute the correct number of commits back, as low as ''<code>1</code>''.)''<br />
<br />
Follow Git's interactive instructions.<br />
Preserve the <code>Change-Id:</code> line at the bottom of each commit message.<br />
|align="center"|<br />
[http://schacon.github.com/git/git-rebase.html <code>git help rebase</code>]<br />
<br/><br />
[http://git-scm.com/book/en/Git-Tools-Rewriting-History#Changing-Multiple-Commit-Messages Pro Git: Changing Multiple Commits]<br />
<br/><br />
[http://git-scm.com/book/en/Git-Branching-Rebasing Pro Git: Rebasing]<br />
|-<br />
|<br />
Return to the [[#Share_a_Topic|previous step]] to share the revised topic.<br />
|}<br />
<br />
==Test a Topic==<br />
<br />
When a patch is submitted, it is tested across the three major platforms<br />
before being merged and tested on many platforms and configurations on the <br />
[https://open.cdash.org/index.php?project=Insight nightly dashboard]. <br />
<br />
If tests fail on a submitted topic, see the [[#Revise_a_Topic|previous step]]<br />
on how to submit a revised version. After a topic is merged, please<br />
check the next day's nightly dashboard to ensure there are not any regressions. <br />
If there are any new warnings or errors, submit a follow-up patch as soon<br />
as possible. <br />
<br />
When a patch is submitted, MacOSX-Clang, Windows-MSVC, and Linux-GCC builds will<br />
start. Once they have finished, the build robots will make a comment on the patch<br />
with a link to their results visualized in CDash and mark the patch set as <br />
''Verified +1'' or ''Not Verified -1''. The results are submitted by the<br />
Kitware Build Robot Gerrit user. <br />
<br />
Builds can be spawned by adding the following comments to a<br />
patch set in Gerrit.<br />
{| style="width: 100%"<br />
|-<br />
|width=60%|<br />
|-<br />
|<br />
:<code>request build: all</code><br />
|align="center"|<br />
MacOSX, Linux, Windows<br />
|-<br />
|<br />
:<code>request build: osx</code><br />
|align="center"|<br />
MacOSX<br />
|-<br />
|<br />
:<code>request build: linux</code><br />
|align="center"|<br />
Linux<br />
|-<br />
|<br />
:<code>request build: windows</code><br />
|align="center"|<br />
Windows<br />
|-<br />
|<br />
:<code>request build: python</code><br />
|align="center"|<br />
Python Wrapping (Linux, MacOSX, Windows)<br />
|-<br />
|<br />
:<code>request build: power8</code><br />
|align="center"|<br />
[https://en.wikipedia.org/wiki/POWER8 POWER8]<br />
|-<br />
|<br />
:<code>request build: cpp11</code><br />
|align="center"|<br />
C++11 (Linux, MacOSX, Windows)<br />
|-<br />
|<br />
:<code>request build: cpp14</code><br />
|align="center"|<br />
C++14 (Linux, MacOSX, Windows)<br />
|-<br />
|}<br />
<br />
==Merge a Topic==<br />
'''Only authorized developers with [[ITK/Git/Account#Git|Git push access]] to <code>itk.org</code> may perform this step.'''<br />
<br />
After a feature topic has been reviewed and approved in Gerrit, merge it into the upstream repository.<br />
{| style="width: 100%"<br />
|-<br />
|width=60%|<br />
Checkout the topic if it is not your current branch:<br />
|-<br />
|<br />
:<code>$ git checkout ''my-topic''</code><br />
|align="center"|<br />
[http://schacon.github.com/git/git-checkout.html <code>git help checkout</code>]<br />
|-<br />
|<br />
Merge the topic, which is originally forked off the master branch, to master branch:<br />
|-<br />
|<br />
:<code>$ git gerrit-merge</code><br />
<br />
:''(If the merge conflicts follow the printed instructions to resolve them.)''<br />
|align="center"|<br />
[http://itk.org/gitweb?p=ITK.git;a=blob;f=Utilities/DevelopmentSetupScripts/SetupGitAliases.sh;hb=HEAD <code>alias.gerrit-merge</code>]<br />
<br/><br />
([http://schacon.github.com/git/git-push.html <code>push</code>] to [[Git/Workflow/Stage|topic stage]] and<br />
<br/><br />
<code>stage ITK merge ''my-topic''</code>)<br />
<br/><br />
[[Git/Workflow/Topic/Conflicts#Branch-to-Topic|Branch-to-Topic Conflict Resolution]]<br />
|}<br />
<br />
For bug fixes that are ready to be included in the next patch release, please email the release manager,<br />
[[User:Matt.mccormick| Matt McCormick]], for assistance.<br />
<br />
Here are the recommended steps to merge a topic to both release and master branches, assuming the topic<br />
branch is forked off the release branch:<br />
:<code>$ git checkout release</code><br />
:<code>$ git merge --no-ff ''my-topic''</code><br />
:<code>$ git push origin release</code><br />
and do:<br />
:<code>$ git checkout master</code><br />
:<code>$ git merge --no-ff release</code><br />
:<code>$ git push origin master</code><br />
to merge the release branch back to master.<br />
<br />
==Delete a Topic==<br />
<br />
After a topic has been merged upstream, delete your local branch for the topic.<br />
<br />
{| style="width: 100%"<br />
|-<br />
|width=60%|<br />
Checkout and update the '''master''' branch:<br />
|-<br />
|<br />
:<code>$ git checkout master</code><br />
:<code>$ git pullall</code><br />
|align="center"|<br />
[http://schacon.github.com/git/git-checkout.html <code>git help checkout</code>]<br />
<br/><br />
[http://itk.org/gitweb?p=ITK.git;a=blob;f=Utilities/DevelopmentSetupScripts/SetupGitAliases.sh;hb=HEAD <code>alias.pullall</code>]<br />
<br/><br />
([http://schacon.github.com/git/git-pull.html <code>pull</code>] and<br />
[http://schacon.github.com/git/git-submodule.html <code>submodule</code>] <code>update</code>)<br />
|-<br />
|<br />
Delete the local topic branch:<br />
|-<br />
|<br />
:<code>$ git branch -d ''my-topic''</code><br />
|align="center"|<br />
[http://schacon.github.com/git/git-branch.html <code>git help branch</code>]<br />
|-<br />
|<br />
The <code>branch -d</code> command works only when the topic branch has been correctly merged.<br />
Use <code>-D</code> instead of <code>-d</code> to force the deletion of an unmerged topic branch<br />
(warning - you could lose commits).<br />
|}</div>Mathieuhttps://public.kitware.com/Wiki/index.php?title=ITK/Git/Develop&diff=62136ITK/Git/Develop2017-11-30T08:22:06Z<p>Mathieu: Update link to KWSys</p>
<hr />
<div>{{ Historical }}<br />
<br />
__NOTOC__<br />
<br />
This page documents how to develop ITK through [http://git-scm.com Git].<br />
See our [[ITK/Git|table of contents]] for more information.<br />
<br />
<i><br />
Git is an extremely powerful version control tool that supports many different "workflows" for indivudal development and collaboration.<br />
Here we document procedures used by the ITK development community.<br />
In the interest of simplicity and brevity we do '''not''' provide an explanation of why we use this approach.<br />
Furthermore, this is '''not''' a Git tutorial.<br />
Please see our [[Git/Resources|Git resource links]] for third-party documentation, such as the [http://git-scm.com/book/ ProGit Book].<br />
</i><br />
<br />
==Setup==<br />
<br />
Before you begin, perform initial setup:<br />
<br />
{| style="width: 100%" cellspacing="0" cellpadding="0"<br />
|-<br />
|width=60%|<br />
1.<br />
Register [[ITK/Git/Account#Gerrit|Gerrit access]] and possibly [[ITK/Git/Account#Git|Git push access]].<br />
|-<br />
|<br />
2.<br />
Optionally download our [[Media:GitITKCheatSheet.pdf|one page PDF desk reference]].<br />
|-<br />
|<br />
3.<br />
Follow the [[ITK/Git/Download#Clone|download instructions]] to create a local ITK clone:<br />
|-<br />
|<br />
:<code>$ git clone git://itk.org/ITK.git</code><br />
|align="center"|<br />
[[Git/Trouble#Firewall_Blocks_Port_9418|Connection refused]]?<br />
|-<br />
|<br />
4.<br />
Run the developer setup script to prepare your ITK work tree and create Git command aliases used below:<br />
|-<br />
|<br />
:<code>$ ./Utilities/SetupForDevelopment.sh</code><br />
|align="center"|<br />
[http://itk.org/gitweb?p=ITK.git;a=blob;f=Utilities/SetupForDevelopment.sh;hb=HEAD <code>SetupForDevelopment.sh</code>]<br />
<br/><br />
[http://git-scm.com/book/en/Getting-Started-First-Time-Git-Setup Pro Git: Setup]<br />
|}<br />
Note that if you answer 'y' to the question "Do you want to test push access to itk.org? [y/N]:", you will most likely receive the following error message: "Permission denied (publickey). fatal: Could not read from remote repository.". Only a few experienced contributors have push access. Having push access is not necessary to contribute to ITK.<br />
<br />
==Workflow==<br />
<br />
ITK development uses a [[Git/Workflow/Topic|branchy workflow]] based on topic branches.<br />
Our collaboration workflow consists of three main steps:<br />
<br />
{| style="width: 100%" cellspacing="0" cellpadding="0"<br />
|-<br />
|width=60%|<br />
1.<br />
Local Development<br />
|-<br />
|<br />
:* [[#Update|Update]]<br />
|-<br />
|<br />
:* [[#Create_a_Topic|Create a Topic]]<br />
|-<br />
|<br />
2.<br />
Code Review<br />
|-<br />
|<br />
:* [[#Share_a_Topic|Share a Topic]] (requires [[ITK/Git/Account#Gerrit|Gerrit access]])<br />
|align="center"|<br />
[http://code.google.com/p/gerrit/ Gerrit Code Review]<br />
|-<br />
|<br />
:* [[#Revise_a_Topic|Revise a Topic]]<br />
|-<br />
|<br />
3.<br />
Integrate Changes<br />
|-<br />
|<br />
:* [[#Merge_a_Topic|Merge a Topic]] (requires [[ITK/Git/Account#Git|Git push access]])<br />
|-<br />
|<br />
:* [[#Delete_a_Topic|Delete a Topic]]<br />
|}<br />
<br />
==Update==<br />
<br />
{| style="width: 100%"<br />
|-<br />
|width=60%|<br />
Update your local '''master''' branch:<br />
|-<br />
|<br />
:<code>$ git checkout master</code><br />
:<code>$ git pullall</code><br />
|align="center"|<br />
[http://schacon.github.com/git/git-checkout.html <code>git help checkout</code>]<br />
<br/><br />
[http://itk.org/gitweb?p=ITK.git;a=blob;f=Utilities/DevelopmentSetupScripts/SetupGitAliases.sh;hb=HEAD <code>alias.pullall</code>]<br />
<br/><br />
([http://schacon.github.com/git/git-pull.html <code>pull</code>] and<br />
[http://schacon.github.com/git/git-submodule.html <code>submodule</code>] <code>update</code>)<br />
|}<br />
<br />
==Create a Topic==<br />
<br />
All new work must be committed on topic branches.<br />
Name topics like you might name functions: concise but precise.<br />
A reader should have a general idea of the feature or fix to be developed given just the branch name.<br />
<br />
{| style="width: 100%"<br />
|-<br />
|width=60%|<br />
To start a new topic branch:<br />
|-<br />
|<br />
:<code>$ git fetch origin</code><br />
:{|<br />
|-<br />
|<br />
For new development, start the topic from <code>origin/master</code>:<br />
:<code>$ git checkout -b ''my-topic'' origin/master</code><br />
|-<br />
|<br />
For release branch fixes, start the topic from <code>origin/release</code>, and by convention use a topic name starting in "<code>release-</code>":<br />
:<code>$ git checkout -b ''my-topic'' origin/release</code><br />
|}<br />
|align="center"|<br />
[http://schacon.github.com/git/git-fetch.html <code>git help fetch</code>]<br />
<br/><br />
[http://schacon.github.com/git/git-checkout.html <code>git help checkout</code>]<br />
<br/><br />
[http://schacon.github.com/git/git-submodule.html <code>git help submodule</code>]<br />
<br/><br />
[http://git-scm.com/book/en/Git-Branching-Basic-Branching-and-Merging Pro Git: Basic Branching]<br />
|-<br />
|<br />
Edit files and create commits (repeat as needed). Add a prefix to your commit message (see below).<br />
|-<br />
|<br />
:<code>$ edit ''file1'' ''file2'' ''file3''</code><br />
:''(To add data follow [[ITK/Git/Develop/Data#Add_Data|these instructions]].)''<br />
:<code>$ git add ''file1'' ''file2'' ''file3''</code><br />
:<code>$ git commit</code><br />
|align="center"|<br />
[http://schacon.github.com/git/git-add.html <code>git help add</code>]<br />
<br/><br />
[http://schacon.github.com/git/git-commit.html <code>git help commit</code>]<br />
<br/><br />
[http://git-scm.com/book/en/Git-Basics-Recording-Changes-to-the-Repository Pro Git: Recording Changes]<br />
|-<br />
|<br />
''(If your change modifies the "<code>Modules/ThirdParty/KWSys/src/KWSys</code>" directory please contribute directly to [https://gitlab.kitware.com/utils/kwsys/blob/master/CONTRIBUTING.rst KWSys] instead.)''<br />
|-<br />
|<br />
Standard prefixes for ITK commit messages :<br />
* BUG: Fix for runtime crash or incorrect result<br />
* COMP: Compiler error or warning fix<br />
* DOC: Documentation change<br />
* ENH: New functionality<br />
* PERF: Performance improvement<br />
* STYLE: No logic impact (indentation, comments)<br />
* WIP: Work In Progress not ready for merge<br />
|<br />
|}<br />
<br />
==Share a Topic==<br />
<br />
When a topic is ready for review and possible inclusion, share it by pushing to Gerrit.<br />
Be sure you have registered for [[ITK/Git/Account#Gerrit|Gerrit access]].<br />
<br />
{| style="width: 100%"<br />
|-<br />
|width=60%|<br />
Checkout the topic if it is not your current branch:<br />
|-<br />
|<br />
:<code>$ git checkout ''my-topic''</code><br />
|align="center"|<br />
[http://schacon.github.com/git/git-checkout.html <code>git help checkout</code>]<br />
|-<br />
|<br />
Check what commits will be pushed to Gerrit for review:<br />
|-<br />
|<br />
:<code>$ git prepush</code><br />
|align="center"|<br />
[http://itk.org/gitweb?p=ITK.git;a=blob;f=Utilities/DevelopmentSetupScripts/SetupGitAliases.sh;hb=HEAD <code>alias.prepush</code>]<br />
<br/><br />
([http://schacon.github.com/git/git-log.html <code>log</code>] <code>origin/master..</code>)<br />
|-<br />
|<br />
Push commits in your topic branch for review by the community:<br />
|-<br />
|<br />
:<code>$ git gerrit-push</code><br />
:''(If the topic adds data see [[ITK/Git/Develop/Data#Push|this note]].)''<br />
or if you started the topic from the release branch:<br />
:<code>$ git push gerrit HEAD:refs/for/release/''my-topic'' </code> <br />
|align="center"|<br />
[[ITK/Git/Account#Firewall_blocks_SSH_traffic|Connection refused]]?<br />
<br/><br />
[http://itk.org/gitweb?p=ITK.git;a=blob;f=Utilities/DevelopmentSetupScripts/SetupGitAliases.sh;hb=HEAD <code>alias.gerrit-push</code>]<br />
<br/><br />
([http://itk.org/gitweb?p=ITK.git;a=blob;f=Utilities/Git/git-gerrit-push;hb=HEAD <code>Utilities/Git/git-gerrit-push</code>])<br />
|}<br />
Find your change in the [http://review.source.kitware.com/p/ITK ITK Gerrit] instance and add [[ITK/Gerrit/Reviewers|reviewers]].<br />
<br />
==Revise a Topic==<br />
<br />
If a topic is approved during Gerrit review, skip to the [[#Merge_a_Topic|next step]].<br />
Otherwise, revise the topic and push it back to Gerrit for another review.<br />
<br />
{| style="width: 100%"<br />
|-<br />
|width=60%|<br />
Checkout the topic if it is not your current branch:<br />
|-<br />
|<br />
:<code>$ git checkout ''my-topic''</code><br />
|align="center"|<br />
[http://schacon.github.com/git/git-checkout.html <code>git help checkout</code>]<br />
|-<br />
|<br />
To revise the most recent commit on the topic edit files and add changes normally and then amend the commit:<br />
|-<br />
|<br />
:<code>$ git commit --amend</code><br />
|align="center"|<br />
[http://schacon.github.com/git/git-commit.html <code>git help commit</code>]<br />
<br/><br />
[http://git-scm.com/book/en/Git-Tools-Rewriting-History#Changing-the-Last-Commit Pro Git: Changing the Last Commit]<br />
|-<br />
|<br />
To revise commits further back on the topic, say the <code>3</code>rd commit back:<br />
|-<br />
|<br />
:<code>$ git rebase -i HEAD~3</code><br />
''(Substitute the correct number of commits back, as low as ''<code>1</code>''.)''<br />
<br />
Follow Git's interactive instructions.<br />
Preserve the <code>Change-Id:</code> line at the bottom of each commit message.<br />
|align="center"|<br />
[http://schacon.github.com/git/git-rebase.html <code>git help rebase</code>]<br />
<br/><br />
[http://git-scm.com/book/en/Git-Tools-Rewriting-History#Changing-Multiple-Commit-Messages Pro Git: Changing Multiple Commits]<br />
<br/><br />
[http://git-scm.com/book/en/Git-Branching-Rebasing Pro Git: Rebasing]<br />
|-<br />
|<br />
Return to the [[#Share_a_Topic|previous step]] to share the revised topic.<br />
|}<br />
<br />
==Test a Topic==<br />
<br />
When a patch is submitted, it is tested across the three major platforms<br />
before being merged and tested on many platforms and configurations on the <br />
[https://open.cdash.org/index.php?project=Insight nightly dashboard]. <br />
<br />
If tests fail on a submitted topic, see the [[#Revise_a_Topic|previous step]]<br />
on how to submit a revised version. After a topic is merged, please<br />
check the next day's nightly dashboard to ensure there are not any regressions. <br />
If there are any new warnings or errors, submit a follow-up patch as soon<br />
as possible. <br />
<br />
When a patch is submitted, MacOSX-Clang, Windows-MSVC, and Linux-GCC builds will<br />
start. Once they have finished, the build robots will make a comment on the patch<br />
with a link to their results visualized in CDash and mark the patch set as <br />
''Verified +1'' or ''Not Verified -1''. The results are submitted by the<br />
Kitware Build Robot Gerrit user. <br />
<br />
Builds can be spawned by adding the following comments to a<br />
patch set in Gerrit.<br />
{| style="width: 100%"<br />
|-<br />
|width=60%|<br />
|-<br />
|<br />
:<code>request build: all</code><br />
|align="center"|<br />
MacOSX, Linux, Windows<br />
|-<br />
|<br />
:<code>request build: osx</code><br />
|align="center"|<br />
MacOSX<br />
|-<br />
|<br />
:<code>request build: linux</code><br />
|align="center"|<br />
Linux<br />
|-<br />
|<br />
:<code>request build: windows</code><br />
|align="center"|<br />
Windows<br />
|-<br />
|<br />
:<code>request build: python</code><br />
|align="center"|<br />
Python Wrapping (Linux, MacOSX, Windows)<br />
|-<br />
|<br />
:<code>request build: power8</code><br />
|align="center"|<br />
[https://en.wikipedia.org/wiki/POWER8 POWER8]<br />
|-<br />
|<br />
:<code>request build: cpp11</code><br />
|align="center"|<br />
C++11 (Linux, MacOSX, Windows)<br />
|-<br />
|<br />
:<code>request build: cpp14</code><br />
|align="center"|<br />
C++14 (Linux, MacOSX, Windows)<br />
|-<br />
|}<br />
<br />
==Merge a Topic==<br />
'''Only authorized developers with [[ITK/Git/Account#Git|Git push access]] to <code>itk.org</code> may perform this step.'''<br />
<br />
After a feature topic has been reviewed and approved in Gerrit, merge it into the upstream repository.<br />
{| style="width: 100%"<br />
|-<br />
|width=60%|<br />
Checkout the topic if it is not your current branch:<br />
|-<br />
|<br />
:<code>$ git checkout ''my-topic''</code><br />
|align="center"|<br />
[http://schacon.github.com/git/git-checkout.html <code>git help checkout</code>]<br />
|-<br />
|<br />
Merge the topic, which is originally forked off the master branch, to master branch:<br />
|-<br />
|<br />
:<code>$ git gerrit-merge</code><br />
<br />
:''(If the merge conflicts follow the printed instructions to resolve them.)''<br />
|align="center"|<br />
[http://itk.org/gitweb?p=ITK.git;a=blob;f=Utilities/DevelopmentSetupScripts/SetupGitAliases.sh;hb=HEAD <code>alias.gerrit-merge</code>]<br />
<br/><br />
([http://schacon.github.com/git/git-push.html <code>push</code>] to [[Git/Workflow/Stage|topic stage]] and<br />
<br/><br />
<code>stage ITK merge ''my-topic''</code>)<br />
<br/><br />
[[Git/Workflow/Topic/Conflicts#Branch-to-Topic|Branch-to-Topic Conflict Resolution]]<br />
|}<br />
<br />
For bug fixes that are ready to be included in the next patch release, please email the release manager,<br />
[[User:Matt.mccormick| Matt McCormick]], for assistance.<br />
<br />
Here are the recommended steps to merge a topic to both release and master branches, assuming the topic<br />
branch is forked off the release branch:<br />
:<code>$ git checkout release</code><br />
:<code>$ git merge --no-ff ''my-topic''</code><br />
:<code>$ git push origin release</code><br />
and do:<br />
:<code>$ git checkout master</code><br />
:<code>$ git merge --no-ff release</code><br />
:<code>$ git push origin master</code><br />
to merge the release branch back to master.<br />
<br />
==Delete a Topic==<br />
<br />
After a topic has been merged upstream, delete your local branch for the topic.<br />
<br />
{| style="width: 100%"<br />
|-<br />
|width=60%|<br />
Checkout and update the '''master''' branch:<br />
|-<br />
|<br />
:<code>$ git checkout master</code><br />
:<code>$ git pullall</code><br />
|align="center"|<br />
[http://schacon.github.com/git/git-checkout.html <code>git help checkout</code>]<br />
<br/><br />
[http://itk.org/gitweb?p=ITK.git;a=blob;f=Utilities/DevelopmentSetupScripts/SetupGitAliases.sh;hb=HEAD <code>alias.pullall</code>]<br />
<br/><br />
([http://schacon.github.com/git/git-pull.html <code>pull</code>] and<br />
[http://schacon.github.com/git/git-submodule.html <code>submodule</code>] <code>update</code>)<br />
|-<br />
|<br />
Delete the local topic branch:<br />
|-<br />
|<br />
:<code>$ git branch -d ''my-topic''</code><br />
|align="center"|<br />
[http://schacon.github.com/git/git-branch.html <code>git help branch</code>]<br />
|-<br />
|<br />
The <code>branch -d</code> command works only when the topic branch has been correctly merged.<br />
Use <code>-D</code> instead of <code>-d</code> to force the deletion of an unmerged topic branch<br />
(warning - you could lose commits).<br />
|}</div>Mathieuhttps://public.kitware.com/Wiki/index.php?title=ITK/Examples/IO/ReadUnknownImageType&diff=57997ITK/Examples/IO/ReadUnknownImageType2015-07-07T09:42:59Z<p>Mathieu: /* ReadUnknownImageType.cxx */</p>
<hr />
<div>==ReadUnknownImageType.cxx==<br />
<source lang="cpp"><br />
#include "itkImage.h"<br />
#include "itkImageFileReader.h"<br />
<br />
template<typename TImageType><br />
static void ReadFile(std::string filename, typename TImageType::Pointer image);<br />
<br />
int main(int argc, char *argv[])<br />
{<br />
if(argc < 2)<br />
{<br />
std::cerr << "Required: filename" << std::endl;<br />
<br />
return EXIT_FAILURE;<br />
}<br />
std::string inputFilename = argv[1];<br />
<br />
typedef itk::ImageIOBase::IOComponentType ScalarPixelType;<br />
<br />
itk::ImageIOBase::Pointer imageIO =<br />
itk::ImageIOFactory::CreateImageIO(<br />
inputFilename.c_str(), itk::ImageIOFactory::ReadMode);<br />
if( !imageIO )<br />
{<br />
std::cerr << "Could not CreateImageIO for: " << inputFilename << std::endl;<br />
return EXIT_FAILURE;<br />
}<br />
imageIO->SetFileName(inputFilename);<br />
imageIO->ReadImageInformation();<br />
const ScalarPixelType pixelType = imageIO->GetComponentType();<br />
std::cout << "Pixel Type is " << imageIO->GetComponentTypeAsString(pixelType) // 'double'<br />
<< std::endl;<br />
const size_t numDimensions = imageIO->GetNumberOfDimensions();<br />
std::cout << "numDimensions: " << numDimensions << std::endl; // '2'<br />
<br />
std::cout << "component size: " << imageIO->GetComponentSize() << std::endl; // '8'<br />
std::cout << "pixel type (string): " << imageIO->GetPixelTypeAsString(imageIO->GetPixelType()) << std::endl; // 'vector'<br />
std::cout << "pixel type: " << imageIO->GetPixelType() << std::endl; // '5'<br />
<br />
/*<br />
switch (pixelType)<br />
{<br />
case itk::ImageIOBase::COVARIANTVECTOR:<br />
typedef itk::Image<unsigned char, 2> ImageType;<br />
ImageType::Pointer image = ImageType::New();<br />
ReadFile<ImageType>(inputFilename, image);<br />
break;<br />
<br />
typedef itk::Image<unsigned char, 2> ImageType;<br />
ImageType::Pointer image = ImageType::New();<br />
ReadFile<ImageType>(inputFilename, image);<br />
break;<br />
<br />
default:<br />
std::cerr << "Pixel Type ("<br />
<< imageIO->GetComponentTypeAsString(pixelType)<br />
<< ") not supported. Exiting." << std::endl;<br />
return -1;<br />
}<br />
*/<br />
<br />
return EXIT_SUCCESS;<br />
}<br />
<br />
template<typename TImageType><br />
void ReadFile(std::string filename, typename TImageType::Pointer image)<br />
{<br />
typedef itk::ImageFileReader<TImageType> ReaderType;<br />
typename ReaderType::Pointer reader = ReaderType::New();<br />
<br />
reader->SetFileName(filename);<br />
reader->Update();<br />
<br />
image->Graft(reader->GetOutput());<br />
}<br />
</source><br />
<br />
==CreateImages.cxx==<br />
<source lang="cpp"><br />
#include "itkImage.h"<br />
#include "itkImageFileWriter.h"<br />
#include <itkCovariantVector.h><br />
<br />
#include <string><br />
<br />
template<typename TImageType><br />
void WriteFile(typename TImageType::Pointer image, std::string filename);<br />
<br />
int main(int, char *[])<br />
{<br />
typedef itk::Image< itk::CovariantVector<double, 4> , 2> ImageType4;<br />
ImageType4::Pointer image4 = ImageType4::New();<br />
WriteFile<ImageType4>(image4, std::string("image4.mhd"));<br />
<br />
typedef itk::Image< itk::CovariantVector<double, 5> , 2> ImageType5;<br />
ImageType5::Pointer image5 = ImageType5::New();<br />
WriteFile<ImageType5>(image5, std::string("image5.mhd"));<br />
<br />
return EXIT_SUCCESS;<br />
}<br />
<br />
template<typename TImageType><br />
void WriteFile(typename TImageType::Pointer image, std::string filename)<br />
{<br />
// Create image<br />
typename TImageType::IndexType start;<br />
start[0] = 0;<br />
start[1] = 0;<br />
<br />
typename TImageType::SizeType size;<br />
size[0] = 20;<br />
size[1] = 30;<br />
<br />
typename TImageType::RegionType region;<br />
region.SetSize(size);<br />
region.SetIndex(start);<br />
<br />
image->SetRegions(region);<br />
image->Allocate();<br />
<br />
typedef typename itk::ImageFileWriter<TImageType> WriterType;<br />
typename WriterType::Pointer writer = WriterType::New();<br />
writer->SetInput(image);<br />
writer->SetFileName(filename);<br />
writer->Update();<br />
<br />
}<br />
<br />
template void WriteFile<itk::Image< itk::CovariantVector<double, 4> , 2> >(itk::Image< itk::CovariantVector<double, 4> , 2>::Pointer, std::string);<br />
template void WriteFile<itk::Image< itk::CovariantVector<double, 5> , 2> >(itk::Image< itk::CovariantVector<double, 5> , 2>::Pointer, std::string);<br />
</source><br />
<br />
{{ITKCMakeLists|{{SUBPAGENAME}}}}</div>Mathieuhttps://public.kitware.com/Wiki/index.php?title=CMake_Scripting_Of_CTest&diff=55172CMake Scripting Of CTest2014-02-27T11:31:20Z<p>Mathieu: /* ctest using git */</p>
<hr />
<div>==Testing With CTest==<br />
<br />
In [[CMake Testing With CTest|Testing With CTest]], you learned how to<br />
use CTest to perfom simple testing. That page also describes how to use<br />
CTest to submit dashboards. The typical sequence of commands that<br />
dashboard contributor will do involves:<br />
<br />
cd /location/of/binary/Directory<br />
rm -rf BinaryDirectory<br />
mkdir BinaryDirectory<br />
cd BinaryDirectory<br />
ccmake /location/of/source/Directory<br />
ctest -D Nightly<br />
<br />
This is done on a typical UNIX system. On Windows system, the<br />
contributor needs to do something similar using Windows command<br />
interpreter, using something like Cygwin, or using a scripting language<br />
such as Perl, Python, or Tcl. Unfortunately none of these solutions is<br />
portable.<br />
<br />
==CTest Scripting==<br />
<br />
CTest has a built-in scripting mode, which significantly simplifies<br />
generating dashboards. Here is example of this script:<br />
<br />
<pre><br />
SET (CTEST_SOURCE_DIRECTORY "C:/Hoffman/My Builds/CMake")<br />
SET (CTEST_BINARY_DIRECTORY "C:/Hoffman/My Builds/CMakeVSNMake71")<br />
<br />
SET (CTEST_CVS_COMMAND "C:/cygwin/bin/cvs.exe")<br />
SET (CTEST_CVS_CHECKOUT "${CTEST_CVS_COMMAND} -d:pserver:hoffman@www.cmake.org:/cvsroot/CMake co -d\"${CTEST_SOURCE_DIRECTORY}\" CMake")<br />
<br />
# which ctest command to use for running the dashboard<br />
SET (CTEST_COMMAND <br />
"C:/Program Files/CMake/bin/ctest.exe -D Nightly"<br />
)<br />
<br />
# what cmake command to use for configuring this dashboard<br />
SET (CTEST_CMAKE_COMMAND <br />
"C:/Program Files/CMake/bin/cmake.exe"<br />
)<br />
<br />
<br />
####################################################################<br />
# The values in this section are optional you can either<br />
# have them or leave them commented out<br />
####################################################################<br />
<br />
# should ctest wipe the binary tree before running<br />
SET (CTEST_START_WITH_EMPTY_BINARY_DIRECTORY TRUE)<br />
<br />
# this is the initial cache to use for the binary tree, be careful to escape<br />
# any quotes inside of this string if you use it<br />
SET (CTEST_INITIAL_CACHE "<br />
MAKECOMMAND:STRING=nmake -i<br />
CMAKE_MAKE_PROGRAM:FILEPATH=nmake<br />
CMAKE_GENERATOR:INTERNAL=NMake Makefiles<br />
BUILDNAME:STRING=Win32-nmake71<br />
SITE:STRING=VOGON.kitware<br />
CVSCOMMAND:FILEPATH=C:/cygwin/bin/cvs.exe<br />
")<br />
<br />
# set any extra environment variables to use during the execution of the script here:<br />
SET (CTEST_ENVIRONMENT<br />
)<br />
</pre><br />
<br />
=== ctest using git ===<br />
<br />
<pre><br />
set(CTEST_SOURCE_DIRECTORY "$ENV{HOME}/workspace/tmp/dashboards/libssh/source")<br />
set(CTEST_BINARY_DIRECTORY "$ENV{HOME}/workspace/tmp/dashboards/libssh/build")<br />
<br />
set(CTEST_SITE "host.libssh.org")<br />
set(CTEST_BUILD_NAME "linux-gcc-default")<br />
<br />
set(CTEST_CMAKE_GENERATOR "Unix Makefiles")<br />
set(CTEST_BUILD_CONFIGURATION "Profiling")<br />
set(CTEST_BUILD_OPTIONS "-DWITH_SSH1=ON -WITH_SFTP=ON -DWITH_SERVER=ON -DWITH_ZLIB=ON -DWITH_PCAP=ON -DWITH_GCRYPT=OFF")<br />
<br />
set(WITH_MEMCHECK TRUE)<br />
set(WITH_COVERAGE TRUE)<br />
<br />
#######################################################################<br />
<br />
ctest_empty_binary_directory(${CTEST_BINARY_DIRECTORY})<br />
<br />
find_program(CTEST_GIT_COMMAND NAMES git)<br />
find_program(CTEST_COVERAGE_COMMAND NAMES gcov)<br />
find_program(CTEST_MEMORYCHECK_COMMAND NAMES valgrind)<br />
<br />
set(CTEST_MEMORYCHECK_SUPPRESSIONS_FILE ${CTEST_SOURCE_DIRECTORY}/tests/valgrind.supp)<br />
<br />
if(NOT EXISTS "${CTEST_SOURCE_DIRECTORY}")<br />
set(CTEST_CHECKOUT_COMMAND "${CTEST_GIT_COMMAND} clone git://git.libssh.org/projects/libssh/libssh.git ${CTEST_SOURCE_DIRECTORY}")<br />
endif()<br />
<br />
set(CTEST_UPDATE_COMMAND "${CTEST_GIT_COMMAND}")<br />
<br />
set(CTEST_CONFIGURE_COMMAND "${CMAKE_COMMAND} -DCMAKE_BUILD_TYPE:STRING=${CTEST_BUILD_CONFIGURATION}")<br />
set(CTEST_CONFIGURE_COMMAND "${CTEST_CONFIGURE_COMMAND} -DWITH_TESTING:BOOL=ON ${CTEST_BUILD_OPTIONS}")<br />
set(CTEST_CONFIGURE_COMMAND "${CTEST_CONFIGURE_COMMAND} \"-G${CTEST_CMAKE_GENERATOR}\"")<br />
set(CTEST_CONFIGURE_COMMAND "${CTEST_CONFIGURE_COMMAND} \"${CTEST_SOURCE_DIRECTORY}\"")<br />
<br />
ctest_start("Nightly")<br />
ctest_update()<br />
ctest_configure()<br />
ctest_build()<br />
ctest_test()<br />
if (WITH_COVERAGE AND CTEST_COVERAGE_COMMAND)<br />
ctest_coverage()<br />
endif (WITH_COVERAGE AND CTEST_COVERAGE_COMMAND)<br />
if (WITH_MEMCHECK AND CTEST_MEMORYCHECK_COMMAND)<br />
ctest_memcheck()<br />
endif (WITH_MEMCHECK AND CTEST_MEMORYCHECK_COMMAND)<br />
ctest_submit()<br />
</pre><br />
<br />
To use SVN, just change the ''CVSCOMMAND'' line by ''SVNCOMMAND'' and give the right path to the ''svn.exe'' program. Also, don't forget to change the ''LC_MESSAGES'' environment variable to ''en_US'' in your script or directly in your system. This will force the SVN output language to english so that CTest will be able to analyse the data from SVN and submit them correctly to Dart2.<br />
<br />
<pre><br />
SET( ENV{LC_MESSAGES} "en_US" )<br />
</pre><br />
<br />
If you want also the compiler output to be ASCII only (and cope with CDash integration), simply use:<br />
<br />
<pre><br />
SET( ENV{LANG} "C" )<br />
</pre><br />
<br />
<br />
This script defined all the information CTest needs to submit CMake<br />
dashboard on Windows XP computer using NMake build system. The syntax<br />
used is the same as in CMake. Also, most commands available in CMake are<br />
available here, except things that require generator, such as<br />
TRY_COMPILE, ADD_LIBRARY, etc.<br />
<br />
The script can be run by executing:<br />
<br />
ctest -S /path/to/script.cmake<br />
<br />
or in this case:<br />
<br />
c:/Program Files/CMake/bin/ctest -S c:/Hoffman/DashboardScripts/vogon_cmake_nmake.cmake<br />
<br />
===Main Settings===<br />
<br />
Every CTest script has to contain the source and binary directory:<br />
<br />
SET (CTEST_SOURCE_DIRECTORY "$ENV{HOME}/Dashboards/My Testing/Insight")<br />
SET (CTEST_BINARY_DIRECTORY "$ENV{HOME}/Dashboards/My Testing/Insight-bin")<br />
<br />
The "$ENV{HOME}" gets replaced by the environment variable "HOME", which<br />
on most systems points to user's home directory.<br />
<br />
Second thing we need is the command that perform initial configuration<br />
of the project. For example, if the project uses CMake, then the command<br />
would be something like:<br />
<br />
SET (CTEST_CMAKE_COMMAND "/usr/local/bin/cmake")<br />
<br />
That assumes that CMake is installed in /usr/local. Similarly to setting<br />
up CMake command, we need to setup the way CTest will be called. Let say<br />
in your case you run CTest using:<br />
<br />
ctest -D Nightly<br />
<br />
Then the command in the CTest script should be:<br />
<br />
SET (CTEST_COMMAND "/usr/local/bin/ctest -D Nightly")<br />
<br />
The final important piece we need is the initial cache that CMake uses<br />
to configure the project. This should be minimal set of settings that<br />
will allow the system to test certain aspect of the project. Example<br />
initial cache would be:<br />
<br />
<pre><br />
SET (CTEST_INITIAL_CACHE "<br />
//Name of generator.<br />
CMAKE_GENERATOR:INTERNAL=Visual Studio 7<br />
<br />
//Name of the build<br />
BUILDNAME:STRING=Win32-vs70<br />
<br />
//Name of the computer/site where compile is being run<br />
SITE:STRING=DASH2.kitware<br />
<br />
//Build VTK with shared libraries.<br />
BUILD_SHARED_LIBS:BOOL=ON<br />
<br />
//Path to the CVS<br />
CVSCOMMAND:FILEPATH=C:/cygwin/bin/cvs.exe<br />
<br />
//ITK TCL and Python wrapping<br />
ITK_CSWIG_TCL:BOOL=ON<br />
ITK_CSWIG_PYTHON:BOOL=ON<br />
")<br />
</pre><br />
<br />
This will set the generator to be "Visual Studio 7", it will use shared<br />
libraries and turn on TCL and Python wrapping. Also, in the cache we can<br />
set the SITE and BUILDNAME variables, which will be used to display the<br />
testing results on the dashboard.<br />
<br />
If you do not use default generator (such as Unix Makefiles), make sure you specify one. On systems that have multimple generators, it is a good idea to specify one always, since otherwise CMake might pick the wrong one.<br />
<br />
Available generators are:<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
|- bgcolor="#abcdef"<br />
! Generator !! Description<br />
|-<br />
| Unix Makefiles<br />
| Unix style makefiles that can be processed using most Make processors except nonconforming processors such as NMake and Borland Make.<br />
|-<br />
| Borland Makefiles<br />
| Makefiles that can be processed using Borland Make processor<br />
|-<br />
| NMake Makefiles<br />
| Makefiles that can be processed using NMake Make processor<br />
|-<br />
| Visual Studio 6<br />
| Visual studio 6 project files<br />
|-<br />
| Visual Studio 7<br />
| Visual Studio 7 project files (not same as Visual Studio 7 .NET 2003<br />
|-<br />
| Visual Studio 7 .NET 2003<br />
| Visual Studio 7 .NET 2003 project files<br />
|-<br />
| Visual Studio 8 2005<br />
| Visual Studi 8 (aka Visual Studio 2005) project files.<br />
|}<br />
<br />
<br />
This is it. The CTest script can now be tested using:<br />
<br />
ctest -S /path/to/script/script.cmake -V<br />
<br />
The -V argument tells CTest to be extra verbose when doing dashboard.<br />
<br />
===More Settings===<br />
<br />
The main settings will generate dashboard for most systems. There are<br />
however issues in certain setups.<br />
<br />
Most dashboard contributors want to start dashboard and not touch those<br />
systems for months. The problem is that the binary directory of the<br />
project will grow larger and larger. Common practice therefore is to<br />
wipe out binary directory every time dashboard is run. We can achieve<br />
this in CTest script by setting:<br />
CTEST_START_WITH_EMPTY_BINARY_DIRECTORY:<br />
<br />
SET (CTEST_START_WITH_EMPTY_BINARY_DIRECTORY TRUE)<br />
<br />
Now CTest will wipe out the binary tree every time. Make sure that the<br />
source tree is not equal to binary tree.<br />
<br />
Second useful option is setting of environment in which CTest runs. Let<br />
say you have Cygwin, Borland, Visual Studio, and Intel compiler on your<br />
Windows system and you do not want to have system's global PATH pointing<br />
to various directories (Borland and Cygwin use "make", which one should<br />
be used). Now you want to do Borland dashboard. You can set environment<br />
variables using CTEST_ENVIRONMENT:<br />
<br />
SET (CTEST_ENVIRONMENT<br />
"PATH=c:/WINDOWS/system32\;c:/WINDOWS\;c:/Programs/Borland/Bcc55/Bin")<br />
<br />
Note that CTEST_ENVIRONMENT can accept multiple environment variables.<br />
For example:<br />
<br />
SET (CTEST_ENVIRONMENT<br />
"DISPLAY=:0"<br />
"GLIBCPP_FORCE_NEW=1"<br />
"CC=gcc-3.4"<br />
"CXX=g++-3.4"<br />
)<br />
<br />
Another useful thing to do is to perform extra update on external<br />
repository. For example, VTK dashboard need to update VTK data. This can<br />
be achieved using CTEST_EXTRA_UPDATES_*. This also requires the<br />
CTEST_CVS_COMMAND to be set. An example of extra update is:<br />
<br />
SET (CTEST_CVS_COMMAND "/usr/bin/cvs")<br />
SET (CTEST_EXTRA_UPDATES_1 "$ENV{HOME}/Dashboards/MyTests/VTKData" "-dAP")<br />
<br />
There can be up to ten CTEST_EXTRA_UPDATES_* settings:<br />
CTEST_EXTRA_UPDATES_1, CTEST_EXTRA_UPDATES_2, ...,<br />
CTEST_EXTRA_UPDATES_10.<br />
<br />
Extra update can also be used to update DartConfig.cmake to the latest version, to receive settings right away instead of waiting until next day. An example of those kind of settings is a nightly start time.<br />
<br />
SET (CTEST_EXTRA_UPDATES_2 "${CTEST_SOURCE_DIRECTORY}" " -dAP DartConfig.cmake")<br />
<br />
===Advanced Settings===<br />
<br />
When performing complex dashboards setups, some more CMake/CTest<br />
knowledge is needed. This section will describe solutions to some common<br />
CTest problems.<br />
<br />
====Memory Checking====<br />
<br />
Doing memory checking using Valgrind or similar product can take<br />
significant amount of time. There are two improvements the dashboard<br />
contributor can do to make dashboard more useful. First one is to submit<br />
partial results. This can be achieved by breaking down the CTest run<br />
into individual runs:<br />
<br />
SET (CTEST_COMMAND <br />
"/usr/local/bin/ctest -D NightlyStart -D NightlyUpdate -D NightlyConfigure -D NightlyBuild -D NightlyTest -D NightlySubmit"<br />
"/usr/local/bin/ctest -D NightlyMemCheck -D NightlySubmit"<br />
)<br />
<br />
The first CTest command will perform standard Nightly dashboard.<br />
The last two will perform only Memory checking and submission. This the<br />
whole dashboard submission will be there except the memory checking.<br />
Once the memory checking is completed, it will be submitted.<br />
<br />
The second thing is to add special flags to make the CTest only test<br />
subset of tests:<br />
<br />
SET (CTEST_COMMAND<br />
...<br />
"/usr/local/bin/ctest -D NightlyMemCheck -I 0,,17"<br />
"/usr/local/bin/ctest -D NightlySubmit"<br />
)<br />
<br />
The "-I 0,,17" will tell CTest to only run memory checking of every 17th<br />
test.<br />
<br />
====Initial Checkout====<br />
<br />
Let say you do not want to require the source of the project to be<br />
available. This is useful if the dashboards are performed on the<br />
temporary drive that can get erased. The following setting will checkout<br />
the source tree of CMake out of CVS repository before the testing is<br />
performed:<br />
<br />
SET (CTEST_CVS_CHECKOUT<br />
"${CTEST_CVS_COMMAND} -q -z3<br />
-d :pserver:anoncvs@www.cmake.org:/cvsroot/CMake<br />
co -d \"CMake\" -D yesterday CMake")<br />
<br />
Another useful feature is to backup source tree before performing<br />
dashboard. This way if the build fails, you can restore the old tree.<br />
This is useful when you require the source tree to be in good condition.<br />
This option has to be used in combination with CTEST_CVS_CHECKOUT. To<br />
turn this feature on, add this to CTest script:<br />
<br />
SET (CTEST_BACKUP_AND_RESTORE TRUE) <br />
<br />
====Continuous Builds (old Style) ====<br />
<br />
When setting up Continuous dashboard, the CTest has to be run<br />
periodically to check if there were any changes in the source. When the<br />
change appears, the full dashboard is tested. This can be achieved by<br />
running CTest from system scheduler or some script, or by using<br />
Continuous feature of CTest script. First of all, make sure that<br />
CTEST_COMMAND is using Continuous model:<br />
<br />
SET (CTEST_COMMAND <br />
"C:/Program Files/CMake20/bin/ctest.exe -D Continuous"<br />
)<br />
<br />
Also, if the number of tests is high, you may want to only run subset of<br />
tests:<br />
<br />
SET (CTEST_COMMAND <br />
"C:/Program Files/CMake20/bin/ctest.exe -D Continuous -I ,,3"<br />
)<br />
<br />
Now set the continuous parameters:<br />
<br />
SET (CTEST_CONTINUOUS_DURATION 600)<br />
SET (CTEST_CONTINUOUS_MINIMUM_INTERVAL 10)<br />
SET (CTEST_START_WITH_EMPTY_BINARY_DIRECTORY_ONCE 1)<br />
<br />
The CTEST_CONTINUOUS_DURATION is the duration of Continuous testing in<br />
minutes. In this case it will run Continuous dashboards for 10 hours. If<br />
it starts at 8 AM, the last continuous will be done around 6 PM. The<br />
CTEST_CONTINUOUS_MINIMUM_INTERVAL is the minimum interval between<br />
Continuous checks. In this case it will perform check every 10 minutes.<br />
CTEST_START_WITH_EMPTY_BINARY_DIRECTORY_ONCE will remove binary tree<br />
once the first Continuous is run. This way Continuous tests will take<br />
less time, since it will only rebuild modified files.<br />
<br />
====Continuous Builds (new Style) ====<br />
<br />
CTEST_CONTINUOUS_DURATION is not used in the new style scripts. Instead, you you should use something like this:<br />
<br />
while (${CTEST_ELAPSED_TIME} LESS 36000)<br />
set (START_TIME ${CTEST_ELAPSED_TIME})<br />
ctest_start (Continuous)<br />
ctest_update (RETURN_VALUE count)<br />
if (count GREATER 0)<br />
ctest_configure()<br />
....<br />
endif ()<br />
ctest_sleep( ${START_TIME} 300 ${CTEST_ELAPSED_TIME})<br />
endwhile()<br />
<br />
===Available Variables===<br />
<br />
When running CTest scripts, there are several variables available that<br />
can simplify writing CTest scripts. These variable include:<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
|- bgcolor="#abcdef"<br />
! Variable !! Description<br />
|-<br />
| CTEST_SCRIPT_DIRECTORY <br />
| Location of directory in which the CTest script is<br />
|-<br />
| CTEST_SCRIPT_NAME<br />
| Name of the CTest script<br />
|- valign="top"<br />
| CTEST_SCRIPT_ARG<br />
| The extra arguments passed to CTest -S. For example, when running:<br />
<br />
<pre><br />
ctest -S /home/scripts/mysystem.cmake,Experimental<br />
</pre><br />
<br />
then the CTEST_SCRIPT_ARG will be set to Experimental. Then this can be<br />
used inside the script:<br />
<br />
<pre><br />
SET(MODEL Nightly)<br />
IF(${CTEST_SCRIPT_ARG} MATCHES Experimental)<br />
SET(MODEL Experimental)<br />
ENDIF(${CTEST_SCRIPT_ARG} MATCHES Experimental)<br />
SET (CTEST_COMMAND<br />
"/usr/local/bin/ctest -D ${MODEL}")<br />
</pre><br />
<br />
Now we can specify Nighlty or Experimental without editing CTest script.<br />
|-<br />
|}<br />
<br />
==Setting Up Cron/Scheduler==<br />
<br />
===On Unix/MacOSX===<br />
<br />
Most Unix and Unix like systems use '''cron'''. Cron is a daemon that runs programs at specified times as described in crontab. Example of crontab is:<br />
<br />
1 22 * * * /usr/bin/ctest -S /dash/dash1.cmake -V > /dash/logs/tests.log 2>&1<br />
<br />
The part of the line:<br />
<br />
1 22 * * *<br />
<br />
specifies when to run the scheduled task. The columns correspond to minutes, hours, days, months, day of the week. This gets translated to 10:01 PM every day, every month.<br />
Another example would be:<br />
<br />
47 6 * * 7<br />
<br />
which is 6:47 AM on sunday.<br />
<br />
The end of the line:<br />
<br />
> /dash/logs/tests.log 2>&1<br />
<br />
is korn-shell (/bin/sh) syntax for sending all messages (standard output and standard error) to a file '''/dash/logs/tests.log'''. If you set different shell in your crontab, make sure to use apropriate syntax.<br />
<br />
To enable crontab, use the following command:<br />
<br />
crontab -e<br />
<br />
===On Windows / Cygwin / MinGW===<br />
<br />
The following images are generated on Windows XP Pro, but the concepts should be the same on all Windows systems. Make sure to enable password for the user, otherwise scheduled tasks will not work.<br />
<br />
1. Open "Scheduled Tasks" from Control Panel.<br />
<br />
[[Image:Sc_task_scheduler.png|left|Task Scheduler]]<br />
<br clear="all"><br />
<br />
2. Select '''Add Scheduled Task'''<br />
<br />
[[Image:Sc_start_new_scheduled_task.png|left|Task Scheduler]]<br />
<br clear="all"><br />
<br />
3. Select '''Next''' to select command.<br />
<br />
[[Image:Sc_select_browse.png|left|Task Scheduler]]<br />
<br clear="all"><br />
<br />
4. Click '''Browse...''' and select '''CTest.exe'''.<br />
<br />
[[Image:Sc_specify_command.png|left|Task Scheduler]]<br />
<br clear="all"><br />
<br />
5. Click '''Next''' and select name and repetition date. Repetition date for Nightly dashboards should be '''Daily'''.<br />
<br />
[[Image:Sc_specified_name_and_repetition.png|left|Task Scheduler]]<br />
<br clear="all"><br />
<br />
6. Click '''Next''' and select time to start the dashboard.<br />
<br />
[[Image:Sc_set_time.png|left|Task Scheduler]]<br />
<br clear="all"><br />
<br />
7. Click '''Next''' and select '''Open advanced properties...''' to fine tune the scheduled task.<br />
<br />
[[Image:Sc_open_advanced_settings.png|left|Task Scheduler]]<br />
<br clear="all"><br />
<br />
8. Select '''Next''' and type password of the user.<br />
<br />
[[Image:Sc_type_password.png|left|Task Scheduler]]<br />
<br clear="all"><br />
<br />
<br />
9. Task is created. The ''Advanced Properties'' dialog should open.<br />
<br />
[[Image:Sc_task_created.png|left|Task Scheduler]]<br />
<br clear="all"><br />
<br />
10. In advanced properties, specify full command name. This is very important that you use double quotes in case you have space in your path.<br />
<br />
"c:/Path to ctest/ctest.exe" -S c:/Path to Dashboard Scripts/dashboard_script.cmake -V<br />
<br />
[[Image:Sc_proper_command_line.png|left|Task Scheduler]]<br />
<br clear="all"><br />
<br />
<br />
11. Select '''Ok'', which will ask for password again.<br />
<br />
[[Image:Sc_finish_password.png|left|Task Scheduler]]<br />
<br clear="all"><br />
<br />
12. The new task should be created.<br />
<br />
[[Image:Sc_new_task_exists.png|left|Task Scheduler]]<br />
<br clear="all"><br />
<br />
==Conclusion==<br />
<br />
CTest scripts can significantly simplify dashboard contribution. Using<br />
simple template script with slight modification, the whole cluster of<br />
various systems can submit dashboards.<br />
<br />
{{CMake/Template/Footer}}</div>Mathieuhttps://public.kitware.com/Wiki/index.php?title=CMake_Scripting_Of_CTest&diff=55171CMake Scripting Of CTest2014-02-27T11:30:07Z<p>Mathieu: /* ctest using git */</p>
<hr />
<div>==Testing With CTest==<br />
<br />
In [[CMake Testing With CTest|Testing With CTest]], you learned how to<br />
use CTest to perfom simple testing. That page also describes how to use<br />
CTest to submit dashboards. The typical sequence of commands that<br />
dashboard contributor will do involves:<br />
<br />
cd /location/of/binary/Directory<br />
rm -rf BinaryDirectory<br />
mkdir BinaryDirectory<br />
cd BinaryDirectory<br />
ccmake /location/of/source/Directory<br />
ctest -D Nightly<br />
<br />
This is done on a typical UNIX system. On Windows system, the<br />
contributor needs to do something similar using Windows command<br />
interpreter, using something like Cygwin, or using a scripting language<br />
such as Perl, Python, or Tcl. Unfortunately none of these solutions is<br />
portable.<br />
<br />
==CTest Scripting==<br />
<br />
CTest has a built-in scripting mode, which significantly simplifies<br />
generating dashboards. Here is example of this script:<br />
<br />
<pre><br />
SET (CTEST_SOURCE_DIRECTORY "C:/Hoffman/My Builds/CMake")<br />
SET (CTEST_BINARY_DIRECTORY "C:/Hoffman/My Builds/CMakeVSNMake71")<br />
<br />
SET (CTEST_CVS_COMMAND "C:/cygwin/bin/cvs.exe")<br />
SET (CTEST_CVS_CHECKOUT "${CTEST_CVS_COMMAND} -d:pserver:hoffman@www.cmake.org:/cvsroot/CMake co -d\"${CTEST_SOURCE_DIRECTORY}\" CMake")<br />
<br />
# which ctest command to use for running the dashboard<br />
SET (CTEST_COMMAND <br />
"C:/Program Files/CMake/bin/ctest.exe -D Nightly"<br />
)<br />
<br />
# what cmake command to use for configuring this dashboard<br />
SET (CTEST_CMAKE_COMMAND <br />
"C:/Program Files/CMake/bin/cmake.exe"<br />
)<br />
<br />
<br />
####################################################################<br />
# The values in this section are optional you can either<br />
# have them or leave them commented out<br />
####################################################################<br />
<br />
# should ctest wipe the binary tree before running<br />
SET (CTEST_START_WITH_EMPTY_BINARY_DIRECTORY TRUE)<br />
<br />
# this is the initial cache to use for the binary tree, be careful to escape<br />
# any quotes inside of this string if you use it<br />
SET (CTEST_INITIAL_CACHE "<br />
MAKECOMMAND:STRING=nmake -i<br />
CMAKE_MAKE_PROGRAM:FILEPATH=nmake<br />
CMAKE_GENERATOR:INTERNAL=NMake Makefiles<br />
BUILDNAME:STRING=Win32-nmake71<br />
SITE:STRING=VOGON.kitware<br />
CVSCOMMAND:FILEPATH=C:/cygwin/bin/cvs.exe<br />
")<br />
<br />
# set any extra environment variables to use during the execution of the script here:<br />
SET (CTEST_ENVIRONMENT<br />
)<br />
</pre><br />
<br />
=== ctest using git ===<br />
<br />
<pre><br />
set(CTEST_SOURCE_DIRECTORY "$ENV{HOME}/workspace/tmp/dashboards/libssh/source")<br />
set(CTEST_BINARY_DIRECTORY "$ENV{HOME}/workspace/tmp/dashboards/libssh/build")<br />
<br />
set(CTEST_SITE "host.libssh.org")<br />
set(CTEST_BUILD_NAME "linux-gcc-default")<br />
<br />
set(CTEST_CMAKE_GENERATOR "Unix Makefiles")<br />
set(CTEST_BUILD_CONFIGURATION "Profiling")<br />
set(CTEST_BUILD_OPTIONS "-DWITH_SSH1=ON -WITH_SFTP=ON -DWITH_SERVER=ON -DWITH_ZLIB=ON -DWITH_PCAP=ON -DWITH_GCRYPT=OFF")<br />
<br />
set(WITH_MEMCHECK TRUE)<br />
set(WITH_COVERAGE TRUE)<br />
<br />
#######################################################################<br />
<br />
ctest_empty_binary_directory(${CTEST_BINARY_DIRECTORY})<br />
<br />
find_program(CTEST_GIT_COMMAND NAMES git)<br />
find_program(CTEST_COVERAGE_COMMAND NAMES gcov)<br />
find_program(CTEST_MEMORYCHECK_COMMAND NAMES valgrind)<br />
<br />
set(CTEST_MEMORYCHECK_SUPPRESSIONS_FILE ${CTEST_SOURCE_DIRECTORY}/tests/valgrind.supp)<br />
<br />
if(NOT EXISTS "${CTEST_SOURCE_DIRECTORY}")<br />
set(CTEST_CHECKOUT_COMMAND "${CTEST_GIT_COMMAND} clone git://git.libssh.org/projects/libssh/libssh.git ${CTEST_SOURCE_DIRECTORY}")<br />
endif()<br />
<br />
set(CTEST_UPDATE_COMMAND "${CTEST_GIT_COMMAND}")<br />
<br />
set(CTEST_CONFIGURE_COMMAND "${CMAKE_COMMAND} -DCMAKE_BUILD_TYPE:STRING=${CTEST_BUILD_CONFIGURATION}")<br />
set(CTEST_CONFIGURE_COMMAND "${CTEST_CONFIGURE_COMMAND} -DWITH_TESTING:BOOL=ON ${CTEST_BUILD_OPTIONS}")<br />
set(CTEST_CONFIGURE_COMMAND "${CTEST_CONFIGURE_COMMAND} \"-G${CTEST_CMAKE_GENERATOR}\"")<br />
set(CTEST_CONFIGURE_COMMAND "${CTEST_CONFIGURE_COMMAND} \"${CTEST_SOURCE_DIRECTORY}\"")<br />
<br />
ctest_start("Nightly")<br />
ctest_update()<br />
ctest_configure()<br />
ctest_build()<br />
ctest_test()<br />
if (WITH_COVERAGE AND CTEST_COVERAGE_COMMAND)<br />
ctest_coverage()<br />
endif (WITH_COVERAGE AND CTEST_COVERAGE_COMMAND)<br />
if (WITH_MEMCHECK AND CTEST_MEMORYCHECK_COMMAND)<br />
ctest_memcheck()<br />
endif (WITH_MEMCHECK AND CTEST_MEMORYCHECK_COMMAND)<br />
ctest_submit()<br />
</pre><br />
<br />
To use SVN, just change the ''CVSCOMMAND'' line by ''SVNCOMMAND'' and give the right path to the ''svn.exe'' program. Also, don't forget to change the ''LC_MESSAGES'' environment variable to ''en_US'' in your script or directly in your system. This will force the SVN output language to english so that CTest will be able to analyse the data from SVN and submit them correctly to Dart2.<br />
<br />
<pre><br />
SET( ENV{LC_MESSAGES} "en_US" )<br />
</pre><br />
<br />
This script defined all the information CTest needs to submit CMake<br />
dashboard on Windows XP computer using NMake build system. The syntax<br />
used is the same as in CMake. Also, most commands available in CMake are<br />
available here, except things that require generator, such as<br />
TRY_COMPILE, ADD_LIBRARY, etc.<br />
<br />
The script can be run by executing:<br />
<br />
ctest -S /path/to/script.cmake<br />
<br />
or in this case:<br />
<br />
c:/Program Files/CMake/bin/ctest -S c:/Hoffman/DashboardScripts/vogon_cmake_nmake.cmake<br />
<br />
===Main Settings===<br />
<br />
Every CTest script has to contain the source and binary directory:<br />
<br />
SET (CTEST_SOURCE_DIRECTORY "$ENV{HOME}/Dashboards/My Testing/Insight")<br />
SET (CTEST_BINARY_DIRECTORY "$ENV{HOME}/Dashboards/My Testing/Insight-bin")<br />
<br />
The "$ENV{HOME}" gets replaced by the environment variable "HOME", which<br />
on most systems points to user's home directory.<br />
<br />
Second thing we need is the command that perform initial configuration<br />
of the project. For example, if the project uses CMake, then the command<br />
would be something like:<br />
<br />
SET (CTEST_CMAKE_COMMAND "/usr/local/bin/cmake")<br />
<br />
That assumes that CMake is installed in /usr/local. Similarly to setting<br />
up CMake command, we need to setup the way CTest will be called. Let say<br />
in your case you run CTest using:<br />
<br />
ctest -D Nightly<br />
<br />
Then the command in the CTest script should be:<br />
<br />
SET (CTEST_COMMAND "/usr/local/bin/ctest -D Nightly")<br />
<br />
The final important piece we need is the initial cache that CMake uses<br />
to configure the project. This should be minimal set of settings that<br />
will allow the system to test certain aspect of the project. Example<br />
initial cache would be:<br />
<br />
<pre><br />
SET (CTEST_INITIAL_CACHE "<br />
//Name of generator.<br />
CMAKE_GENERATOR:INTERNAL=Visual Studio 7<br />
<br />
//Name of the build<br />
BUILDNAME:STRING=Win32-vs70<br />
<br />
//Name of the computer/site where compile is being run<br />
SITE:STRING=DASH2.kitware<br />
<br />
//Build VTK with shared libraries.<br />
BUILD_SHARED_LIBS:BOOL=ON<br />
<br />
//Path to the CVS<br />
CVSCOMMAND:FILEPATH=C:/cygwin/bin/cvs.exe<br />
<br />
//ITK TCL and Python wrapping<br />
ITK_CSWIG_TCL:BOOL=ON<br />
ITK_CSWIG_PYTHON:BOOL=ON<br />
")<br />
</pre><br />
<br />
This will set the generator to be "Visual Studio 7", it will use shared<br />
libraries and turn on TCL and Python wrapping. Also, in the cache we can<br />
set the SITE and BUILDNAME variables, which will be used to display the<br />
testing results on the dashboard.<br />
<br />
If you do not use default generator (such as Unix Makefiles), make sure you specify one. On systems that have multimple generators, it is a good idea to specify one always, since otherwise CMake might pick the wrong one.<br />
<br />
Available generators are:<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
|- bgcolor="#abcdef"<br />
! Generator !! Description<br />
|-<br />
| Unix Makefiles<br />
| Unix style makefiles that can be processed using most Make processors except nonconforming processors such as NMake and Borland Make.<br />
|-<br />
| Borland Makefiles<br />
| Makefiles that can be processed using Borland Make processor<br />
|-<br />
| NMake Makefiles<br />
| Makefiles that can be processed using NMake Make processor<br />
|-<br />
| Visual Studio 6<br />
| Visual studio 6 project files<br />
|-<br />
| Visual Studio 7<br />
| Visual Studio 7 project files (not same as Visual Studio 7 .NET 2003<br />
|-<br />
| Visual Studio 7 .NET 2003<br />
| Visual Studio 7 .NET 2003 project files<br />
|-<br />
| Visual Studio 8 2005<br />
| Visual Studi 8 (aka Visual Studio 2005) project files.<br />
|}<br />
<br />
<br />
This is it. The CTest script can now be tested using:<br />
<br />
ctest -S /path/to/script/script.cmake -V<br />
<br />
The -V argument tells CTest to be extra verbose when doing dashboard.<br />
<br />
===More Settings===<br />
<br />
The main settings will generate dashboard for most systems. There are<br />
however issues in certain setups.<br />
<br />
Most dashboard contributors want to start dashboard and not touch those<br />
systems for months. The problem is that the binary directory of the<br />
project will grow larger and larger. Common practice therefore is to<br />
wipe out binary directory every time dashboard is run. We can achieve<br />
this in CTest script by setting:<br />
CTEST_START_WITH_EMPTY_BINARY_DIRECTORY:<br />
<br />
SET (CTEST_START_WITH_EMPTY_BINARY_DIRECTORY TRUE)<br />
<br />
Now CTest will wipe out the binary tree every time. Make sure that the<br />
source tree is not equal to binary tree.<br />
<br />
Second useful option is setting of environment in which CTest runs. Let<br />
say you have Cygwin, Borland, Visual Studio, and Intel compiler on your<br />
Windows system and you do not want to have system's global PATH pointing<br />
to various directories (Borland and Cygwin use "make", which one should<br />
be used). Now you want to do Borland dashboard. You can set environment<br />
variables using CTEST_ENVIRONMENT:<br />
<br />
SET (CTEST_ENVIRONMENT<br />
"PATH=c:/WINDOWS/system32\;c:/WINDOWS\;c:/Programs/Borland/Bcc55/Bin")<br />
<br />
Note that CTEST_ENVIRONMENT can accept multiple environment variables.<br />
For example:<br />
<br />
SET (CTEST_ENVIRONMENT<br />
"DISPLAY=:0"<br />
"GLIBCPP_FORCE_NEW=1"<br />
"CC=gcc-3.4"<br />
"CXX=g++-3.4"<br />
)<br />
<br />
Another useful thing to do is to perform extra update on external<br />
repository. For example, VTK dashboard need to update VTK data. This can<br />
be achieved using CTEST_EXTRA_UPDATES_*. This also requires the<br />
CTEST_CVS_COMMAND to be set. An example of extra update is:<br />
<br />
SET (CTEST_CVS_COMMAND "/usr/bin/cvs")<br />
SET (CTEST_EXTRA_UPDATES_1 "$ENV{HOME}/Dashboards/MyTests/VTKData" "-dAP")<br />
<br />
There can be up to ten CTEST_EXTRA_UPDATES_* settings:<br />
CTEST_EXTRA_UPDATES_1, CTEST_EXTRA_UPDATES_2, ...,<br />
CTEST_EXTRA_UPDATES_10.<br />
<br />
Extra update can also be used to update DartConfig.cmake to the latest version, to receive settings right away instead of waiting until next day. An example of those kind of settings is a nightly start time.<br />
<br />
SET (CTEST_EXTRA_UPDATES_2 "${CTEST_SOURCE_DIRECTORY}" " -dAP DartConfig.cmake")<br />
<br />
===Advanced Settings===<br />
<br />
When performing complex dashboards setups, some more CMake/CTest<br />
knowledge is needed. This section will describe solutions to some common<br />
CTest problems.<br />
<br />
====Memory Checking====<br />
<br />
Doing memory checking using Valgrind or similar product can take<br />
significant amount of time. There are two improvements the dashboard<br />
contributor can do to make dashboard more useful. First one is to submit<br />
partial results. This can be achieved by breaking down the CTest run<br />
into individual runs:<br />
<br />
SET (CTEST_COMMAND <br />
"/usr/local/bin/ctest -D NightlyStart -D NightlyUpdate -D NightlyConfigure -D NightlyBuild -D NightlyTest -D NightlySubmit"<br />
"/usr/local/bin/ctest -D NightlyMemCheck -D NightlySubmit"<br />
)<br />
<br />
The first CTest command will perform standard Nightly dashboard.<br />
The last two will perform only Memory checking and submission. This the<br />
whole dashboard submission will be there except the memory checking.<br />
Once the memory checking is completed, it will be submitted.<br />
<br />
The second thing is to add special flags to make the CTest only test<br />
subset of tests:<br />
<br />
SET (CTEST_COMMAND<br />
...<br />
"/usr/local/bin/ctest -D NightlyMemCheck -I 0,,17"<br />
"/usr/local/bin/ctest -D NightlySubmit"<br />
)<br />
<br />
The "-I 0,,17" will tell CTest to only run memory checking of every 17th<br />
test.<br />
<br />
====Initial Checkout====<br />
<br />
Let say you do not want to require the source of the project to be<br />
available. This is useful if the dashboards are performed on the<br />
temporary drive that can get erased. The following setting will checkout<br />
the source tree of CMake out of CVS repository before the testing is<br />
performed:<br />
<br />
SET (CTEST_CVS_CHECKOUT<br />
"${CTEST_CVS_COMMAND} -q -z3<br />
-d :pserver:anoncvs@www.cmake.org:/cvsroot/CMake<br />
co -d \"CMake\" -D yesterday CMake")<br />
<br />
Another useful feature is to backup source tree before performing<br />
dashboard. This way if the build fails, you can restore the old tree.<br />
This is useful when you require the source tree to be in good condition.<br />
This option has to be used in combination with CTEST_CVS_CHECKOUT. To<br />
turn this feature on, add this to CTest script:<br />
<br />
SET (CTEST_BACKUP_AND_RESTORE TRUE) <br />
<br />
====Continuous Builds (old Style) ====<br />
<br />
When setting up Continuous dashboard, the CTest has to be run<br />
periodically to check if there were any changes in the source. When the<br />
change appears, the full dashboard is tested. This can be achieved by<br />
running CTest from system scheduler or some script, or by using<br />
Continuous feature of CTest script. First of all, make sure that<br />
CTEST_COMMAND is using Continuous model:<br />
<br />
SET (CTEST_COMMAND <br />
"C:/Program Files/CMake20/bin/ctest.exe -D Continuous"<br />
)<br />
<br />
Also, if the number of tests is high, you may want to only run subset of<br />
tests:<br />
<br />
SET (CTEST_COMMAND <br />
"C:/Program Files/CMake20/bin/ctest.exe -D Continuous -I ,,3"<br />
)<br />
<br />
Now set the continuous parameters:<br />
<br />
SET (CTEST_CONTINUOUS_DURATION 600)<br />
SET (CTEST_CONTINUOUS_MINIMUM_INTERVAL 10)<br />
SET (CTEST_START_WITH_EMPTY_BINARY_DIRECTORY_ONCE 1)<br />
<br />
The CTEST_CONTINUOUS_DURATION is the duration of Continuous testing in<br />
minutes. In this case it will run Continuous dashboards for 10 hours. If<br />
it starts at 8 AM, the last continuous will be done around 6 PM. The<br />
CTEST_CONTINUOUS_MINIMUM_INTERVAL is the minimum interval between<br />
Continuous checks. In this case it will perform check every 10 minutes.<br />
CTEST_START_WITH_EMPTY_BINARY_DIRECTORY_ONCE will remove binary tree<br />
once the first Continuous is run. This way Continuous tests will take<br />
less time, since it will only rebuild modified files.<br />
<br />
====Continuous Builds (new Style) ====<br />
<br />
CTEST_CONTINUOUS_DURATION is not used in the new style scripts. Instead, you you should use something like this:<br />
<br />
while (${CTEST_ELAPSED_TIME} LESS 36000)<br />
set (START_TIME ${CTEST_ELAPSED_TIME})<br />
ctest_start (Continuous)<br />
ctest_update (RETURN_VALUE count)<br />
if (count GREATER 0)<br />
ctest_configure()<br />
....<br />
endif ()<br />
ctest_sleep( ${START_TIME} 300 ${CTEST_ELAPSED_TIME})<br />
endwhile()<br />
<br />
===Available Variables===<br />
<br />
When running CTest scripts, there are several variables available that<br />
can simplify writing CTest scripts. These variable include:<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
|- bgcolor="#abcdef"<br />
! Variable !! Description<br />
|-<br />
| CTEST_SCRIPT_DIRECTORY <br />
| Location of directory in which the CTest script is<br />
|-<br />
| CTEST_SCRIPT_NAME<br />
| Name of the CTest script<br />
|- valign="top"<br />
| CTEST_SCRIPT_ARG<br />
| The extra arguments passed to CTest -S. For example, when running:<br />
<br />
<pre><br />
ctest -S /home/scripts/mysystem.cmake,Experimental<br />
</pre><br />
<br />
then the CTEST_SCRIPT_ARG will be set to Experimental. Then this can be<br />
used inside the script:<br />
<br />
<pre><br />
SET(MODEL Nightly)<br />
IF(${CTEST_SCRIPT_ARG} MATCHES Experimental)<br />
SET(MODEL Experimental)<br />
ENDIF(${CTEST_SCRIPT_ARG} MATCHES Experimental)<br />
SET (CTEST_COMMAND<br />
"/usr/local/bin/ctest -D ${MODEL}")<br />
</pre><br />
<br />
Now we can specify Nighlty or Experimental without editing CTest script.<br />
|-<br />
|}<br />
<br />
==Setting Up Cron/Scheduler==<br />
<br />
===On Unix/MacOSX===<br />
<br />
Most Unix and Unix like systems use '''cron'''. Cron is a daemon that runs programs at specified times as described in crontab. Example of crontab is:<br />
<br />
1 22 * * * /usr/bin/ctest -S /dash/dash1.cmake -V > /dash/logs/tests.log 2>&1<br />
<br />
The part of the line:<br />
<br />
1 22 * * *<br />
<br />
specifies when to run the scheduled task. The columns correspond to minutes, hours, days, months, day of the week. This gets translated to 10:01 PM every day, every month.<br />
Another example would be:<br />
<br />
47 6 * * 7<br />
<br />
which is 6:47 AM on sunday.<br />
<br />
The end of the line:<br />
<br />
> /dash/logs/tests.log 2>&1<br />
<br />
is korn-shell (/bin/sh) syntax for sending all messages (standard output and standard error) to a file '''/dash/logs/tests.log'''. If you set different shell in your crontab, make sure to use apropriate syntax.<br />
<br />
To enable crontab, use the following command:<br />
<br />
crontab -e<br />
<br />
===On Windows / Cygwin / MinGW===<br />
<br />
The following images are generated on Windows XP Pro, but the concepts should be the same on all Windows systems. Make sure to enable password for the user, otherwise scheduled tasks will not work.<br />
<br />
1. Open "Scheduled Tasks" from Control Panel.<br />
<br />
[[Image:Sc_task_scheduler.png|left|Task Scheduler]]<br />
<br clear="all"><br />
<br />
2. Select '''Add Scheduled Task'''<br />
<br />
[[Image:Sc_start_new_scheduled_task.png|left|Task Scheduler]]<br />
<br clear="all"><br />
<br />
3. Select '''Next''' to select command.<br />
<br />
[[Image:Sc_select_browse.png|left|Task Scheduler]]<br />
<br clear="all"><br />
<br />
4. Click '''Browse...''' and select '''CTest.exe'''.<br />
<br />
[[Image:Sc_specify_command.png|left|Task Scheduler]]<br />
<br clear="all"><br />
<br />
5. Click '''Next''' and select name and repetition date. Repetition date for Nightly dashboards should be '''Daily'''.<br />
<br />
[[Image:Sc_specified_name_and_repetition.png|left|Task Scheduler]]<br />
<br clear="all"><br />
<br />
6. Click '''Next''' and select time to start the dashboard.<br />
<br />
[[Image:Sc_set_time.png|left|Task Scheduler]]<br />
<br clear="all"><br />
<br />
7. Click '''Next''' and select '''Open advanced properties...''' to fine tune the scheduled task.<br />
<br />
[[Image:Sc_open_advanced_settings.png|left|Task Scheduler]]<br />
<br clear="all"><br />
<br />
8. Select '''Next''' and type password of the user.<br />
<br />
[[Image:Sc_type_password.png|left|Task Scheduler]]<br />
<br clear="all"><br />
<br />
<br />
9. Task is created. The ''Advanced Properties'' dialog should open.<br />
<br />
[[Image:Sc_task_created.png|left|Task Scheduler]]<br />
<br clear="all"><br />
<br />
10. In advanced properties, specify full command name. This is very important that you use double quotes in case you have space in your path.<br />
<br />
"c:/Path to ctest/ctest.exe" -S c:/Path to Dashboard Scripts/dashboard_script.cmake -V<br />
<br />
[[Image:Sc_proper_command_line.png|left|Task Scheduler]]<br />
<br clear="all"><br />
<br />
<br />
11. Select '''Ok'', which will ask for password again.<br />
<br />
[[Image:Sc_finish_password.png|left|Task Scheduler]]<br />
<br clear="all"><br />
<br />
12. The new task should be created.<br />
<br />
[[Image:Sc_new_task_exists.png|left|Task Scheduler]]<br />
<br clear="all"><br />
<br />
==Conclusion==<br />
<br />
CTest scripts can significantly simplify dashboard contribution. Using<br />
simple template script with slight modification, the whole cluster of<br />
various systems can submit dashboards.<br />
<br />
{{CMake/Template/Footer}}</div>Mathieuhttps://public.kitware.com/Wiki/index.php?title=VTK/FAQ&diff=44801VTK/FAQ2012-01-13T17:17:13Z<p>Mathieu: mpeg2 was removed basically</p>
<hr />
<div>== General information and availability ==<br />
<br />
=== What is the Visualization Toolkit? ===<br />
<br />
The '''Visualization ToolKit (vtk)''' is a software system for 3D Computer<br />
Graphics and Visualization.<br />
<br />
VTK includes a textbook published by Kitware Inc. ([http://www.kitware.com/products/vtktextbook.html The Visualization<br />
Toolkit, An Object-Oriented Approach to 3D Graphics]),<br />
a C++ class library, and Tcl, Python and Java implementations based on<br />
the class library.<br />
<br />
For more information, see http://www.vtk.org and http://www.kitware.com.<br />
<br />
=== What is the current release? ===<br />
<br />
The current release of vtk is 5.4.0 (released on 2009-3-26). This release for download available from:<br />
<br />
http://www.vtk.org/VTK/resources/software.html<br />
<br />
Nightly development releases are available at:<br />
<br />
http://www.vtk.org/files/nightly<br />
<br />
=== Can I contribute code or bug fixes? ===<br />
<br />
We encourage people to contribute bug fixes as well as new contributions<br />
to the code. We will try to incorporate these into future releases so<br />
that the entire user community will benefit from them.<br />
<br />
See http://www.vtk.org/contribute.php for information on contributing to<br />
VTK.<br />
<br />
For some ideas take a look at some of the entries in the "Changes to the<br />
VTK API" FAQ section, for example: <br />
[[VTK_FAQ#Roadmap:_What_changes_are_being_considered_for_VTK|What changes are being considered for VTK]]<br />
<br />
We now have a bug tracker that allow keeping track of any bug you could find. See [http://www.vtk.org/Bug BugTracker].<br />
You'll need an email to report a bug.<br />
To improve the chance of a bug being fixed, do not hesisitate to add as many details as possible, a demo sample code + sample data is always a good idea.<br />
Providing a patch almost guarantees that your patch will be incorporated into VTK.<br />
<br />
=== Can I contribute money? ===<br />
<br />
Please don't send money. Not that we think you're going to send in<br />
unsolicited money. But if you were thinking about it, stop. It would<br />
just complicate our lives and make for all sorts of tax problems.<br />
<br />
(Note: if you are a company or funding institution, and would like to fund<br />
features or development, please contact Kitware http://www.kitware.com .)<br />
<br />
=== Is there a mailing list or Usenet newsgroup for VTK? ===<br />
<br />
There is a mailing list: vtkusers@vtk.org<br />
<br />
To subscribe or unsubscribe to the mailing list, go to:<br />
http://www.vtk.org/mailman/listinfo/vtkusers<br />
<br />
To search the list archives go to: http://www.kitware.com/search.html<br />
<br />
There is also a newsgroup that mirrors the mailinglist. At this point it<br />
seems that mirror is down. Mail to the mailinglist used to be posted the<br />
newsgroup, but posts on the newsgroup were not sent to the mailinglist.<br />
The newsgroup was located at:<br />
news://scully.esat.kuleuven.ac.be/vtk.mailinglist<br />
<br />
http://www.gmane.org is a bidirectional mail-to-news gateway that carries the vtkusers mailing list. Its located here: news://news.gmane.org/gmane.comp.lib.vtk.user or here: http://news.gmane.org/gmane.comp.lib.vtk.user. vtkusers mails have been archived since April 2002 and they never expire. You can read and send mails to the vtkusers list but sent mail will bounce back without having subscribed to the list first.<br />
<br />
=== Is the VTK mailing list archived anywhere? ===<br />
<br />
The mailing list is archived at:<br />
http://www.vtk.org/pipermail/vtkusers/<br />
<br />
You can search the archive at: http://www.kitware.com/search.html<br />
<br />
=== Are answers for the exercises in the VTK book available? ===<br />
<br />
Not anymore.<br />
<br />
The answers to the exercises of the textbook used to be maintained by<br />
Martin Stoufer (kudos), and will be made available by Kitware in the<br />
near future.<br />
<br />
=== Is VTK regression tested on a regular basis? Can I help? ===<br />
<br />
Yes, it is.<br />
<br />
You can view the current regression test results at:<br />
http://public.kitware.com/dashboard.php?name=vtk<br />
<br />
VTK uses Dart to perform builds, run tests, and generate dashboards. You<br />
can find more information about Dart at: http://public.kitware.com/Dart/<br />
<br />
You can help improve the quality of VTK by supplying the authors with<br />
Tcl scripts that can be used as or turned into regression tests. A good<br />
regression test will:<br />
<br />
# Cover code that is not already covered.<br />
# Illustrate a bug that is occuring now or that has occurred in the past.<br />
# Use data that is on the 2nd Edition book CDROM or use "small" data files or use no data at all.<br />
# Optionally, produce an interesting result. <br />
<br />
Currently almost all regression tests are written in Tcl.<br />
<br />
Please send your Tcl regression tests to:<br />
mailto:wlorens1@mail.nycap.rr.com<br />
<br />
Bill will evaluate them for applicability and integrate them into the<br />
nightly test process.<br />
<br />
=== What's the best way to learn VTK? ===<br />
<br />
There are six things you might want to try:<br />
<br />
# Purchase the book [http://www.kitware.com/products/vtktextbook.html The Visualization Toolkit] from Kitware Inc.<br />
# Purchase the book [http://www.kitware.com/products/vtkguide.html VTK Users Guide] from Kitware Inc. <br />
# Check out some of the material at [[VTK Courses, Classes, Presentations]].<br />
# [http://www.vtk.org/get-software.php Download the source code and/or binaries] (available on Windows) and [[VTK/Examples|look at the examples]] (there are hundreds). <br />
# To learn the innards of VTK, you can attend a [http://www.kitware.com/products/proftrain.html#VTKCourse VTK course] or [http://www.kitware.com/products/proftrain.html sponsor a VTK course at your site] through Kitware. http://www.kitware.com/products/index.html<br />
# Buy Bill a beer and get him talking about VTK<br />
<br />
=== How should I ask questions on the mailing lists? ===<br />
<br />
The best online resource for this question is Eric S. Raymond's<br />
excellent guide on the topic titled [[http://www.catb.org/~esr/faqs/smart-questions.html How to ask questions the smart way]]. [[http://www.mikeash.com/getting_answers.html Getting Answers]] is a good starting point too.<br />
<br />
Please do read it and follow his advice. Thanks!<br />
<br />
Please also remember the following when you post your messages to the<br />
VTK mailing lists.<br />
<br />
* Mention the version of VTK you are using and the version of the compiler or scripting language you are using.<br />
<br />
* Mention your platform, OS and their versions.<br />
<br />
* Include hardware details if relevant.<br />
<br />
* Include all relevant error messages (appropriately trimmed of course).<br />
<br />
* The lists have a very large number of subscribers (in the thousands), so please keep messages to the point.<br />
<br />
* Avoid HTML emails.<br />
<br />
* Use a sensible and descriptive subject line.<br />
<br />
* Do NOT post large data files or images to the list. Instead put them in your web page and mention the URLs.<br />
<br />
* Quote the messages you reply to appropriately. Remove unnecessary details.<br />
<br />
When asking a question or reporting a problem try to include a small<br />
example program that demonstrates the problem. Make sure that this<br />
example program is as small as you can make it, simple (and uses VTK<br />
alone), complete and demonstrates the problem adequately. Doing this<br />
will go a *long way* towards getting a quick and meaningful response.<br />
<br />
Sometimes you might not get any acceptable response. This happens<br />
bacause the others think the question has either been already answered<br />
elsewhere (the archives, FAQ and google are your friends), or believe<br />
that you have not done enough homework to warrant their attention, or<br />
they don't know the answer or simply don't have the time to answer.<br />
Please do be patient and understanding. Most questions are answered by<br />
people volunteering their time to help you.<br />
<br />
Happy posting!<br />
<br />
=== How NOT to go about a programming assignment ===<br />
<br />
This is really a link you should read before posting to the mailing list. <br />
[This article is an attempt to show these irrational attitudes in an ironical way, <br />
intending to make our students aware of bad habits without admonishing them.]<br />
<br />
http://www.di.uniovi.es/~cernuda/noprog_ENG.html<br />
<br />
=== Accessing VTK CVS from behind a firewall ===<br />
<br />
Use the sourceforge project:<br />
<br />
http://cvsgrab.sourceforge.net/<br />
<br />
Just download the script and type something like:<br />
<br />
cvsgrab -rootUrl http://public.kitware.com/cgi-bin/cvsweb.cgi/ -packagePath VTK -destDir . <br />
-proxyUser xxx -proxyPassword xxx -proxyHost xxx -proxyPort xx<br />
<br />
(Thanks to Ingo H. de Boer)<br />
<br />
Also cvsgrab support the following option to access a particular branch:<br />
<br />
-tag <version tag> [optional] The version tag of the files to download<br />
<br />
For example to get the latest 4.4 branch:<br />
<br />
cvsgrab -rootUrl http://public.kitware.com/cgi-bin/cvsweb.cgi/ -packagePath VTK -destDir . <br />
-proxyUser xxx -proxyPassword xxx -proxyHost xxx -proxyPort xxx<br />
-tag release-4-4<br />
<br />
=== Where can I obtain test and sample datasets? ===<br />
<br />
See [[VTK Datasets|this page]] for details on downloading datasets that VTK can read.<br />
<br />
== Language bindings ==<br />
<br />
=== Are there bindings to languages other than Tcl? ===<br />
<br />
Aside from C++ (which it's written in) and Tcl, vtk is also bound into<br />
Java as of JDK 1.1 and Python 1.5, 1.6 and 2.X. All of the<br />
Tcl/Java/Python wrapper code is generated from some LEX and YACC code<br />
that parses our classes and extracts the required information to<br />
generate the wrapper code.<br />
<br />
=== What version of Tcl/Tk should I use with VTK? ===<br />
<br />
Currently we recommend that you use Tcl/Tk 8.2.3 with VTK. This is the<br />
best-supported version combination at this time.<br />
<br />
VTK has also been tested with Tcl/Tk 8.3.2 and works well.<br />
<br />
Tcl/Tk 8.3.4 has been tested to a limited extent but seems to have more<br />
memory leaks that Tcl 8.3.2 has.<br />
<br />
Tcl/Tk 8.4.x seems to work well with VTK too, but you might have to<br />
change a couple of configuration settings depending on the version of<br />
VTK you are using. Check the [[VTK_FAQ#Does_VTK_support_Tcl.2FTk_8.4_.3F|Does VTK support Tcl/Tk 8.4?]].<br />
<br />
=== Where can I find Python 2.x binaries? ===<br />
<br />
All of the Python binaries available on the kitware site are built for<br />
Python 1.5.2. This includes the official release VTK3.2 and the nightly<br />
builds (as at 2001-07-16).<br />
<br />
For Python 2.x binaries, you will have to compile your own from source.<br />
It is worth checking the mailing list archives for comments by others<br />
who have been through this process.<br />
<br />
There are some user-contributed binaries available at other sites. Check<br />
the mailing list archives for possible leads. Some win32 binaries for<br />
Python 2.1 are available at;<br />
<br />
http://basic.netmeg.net/godzilla/<br />
<br />
YMMV...<br />
<br />
=== Why do I get the Python error -- ValueError: method requires a VTK object? ===<br />
<br />
You just built VTK with Python support and everything went smoothly.<br />
After you install everything and try running a Python-VTK script you get<br />
a traceback with this error:<br />
<br />
ValueError: method requires a VTK object.<br />
<br />
This error occurs if you have two copies of the VTK libraries on your<br />
system. These copies need not be in your linkers path. The VTK libraries<br />
are usually built with an rpath flag (under *nix). This is necessary to<br />
be able to test the build in place. When you install VTK into another<br />
directory in your linkers path and then run a Python script the Python<br />
modules remember the old path and load the libraries in the build<br />
directory as well. This triggers the above error since the object you<br />
passed the method was instantiated from the other copy.<br />
<br />
So how do you fix it? The easiest solution is to simply delete the copy<br />
of the libraries inside your build directory or move the build directory<br />
to another place. For example, if you build the libraries in VTK/bin<br />
then move VTK/bin to VTK/bin1 or remove all the VTK/bin/*.so files. The<br />
error should no longer occur.<br />
<br />
Another way to fix the error is to turn the CMAKE_SKIP_RPATH boolean to<br />
ON in your CMakeCache.txt file and then rebuild VTK. You shouldn't have<br />
to rebuild all of VTK, just delete the libraries (*.so files) and then<br />
re-run cmake and make. The only trouble with this approach is that you<br />
cannot have BUILD_TESTING to ON when you do this.<br />
<br />
Alternatively, starting with recent VTK CVS versions (post Dec. 6, 2002)<br />
and with VTK versions greater than 4.1 (i.e. 4.2 and beyond) there is a<br />
special VTK-Python interpreter built as part of VTK called 'vtkpython'<br />
that should eliminate this problem. Simply use vtkpython in place of the<br />
usual python interpreter when you use VTK-Python scripts and the problem<br />
should not occur. This is because vtkpython uses the libraries inside<br />
the build directory.<br />
<br />
2002 by Prabhu Ramachandran<br />
<br />
=== Does VTK support Tcl/Tk 8.4 ? ===<br />
<br />
Short answer: yes, but it might require some adjustments, depending on<br />
the VTK and CMake versions you are using.<br />
<br />
# The VTK 4.x CVS nightly/development distribution supports Tcl/Tk 8.4 as long as you use a release version of CMake > 1.4.5. Since VTK 4.2 will require CMake 1.6, the next release version will support Tcl/Tk 8.4.<br />
# The VTK 4.0 release distribution does not support Tcl/Tk 8.4 out-of-the-box.<br />
<br />
In either cases, the following solutions will adress the problem. This<br />
basically involves setting two definition symbols that will make Tcl/Tk<br />
8.4 backward compatible with previous versions of Tcl/Tk (i.e. discard<br />
the "const correctness" and Tk_PhotoPutBlock compositing rule features) :<br />
<br />
a) Edit your C/C++ flags:<br />
<br />
Run your favorite CMake cache editor (i.e. CMakeSetup, or ccmake),<br />
display the advanced values and add the USE_NON_CONST and<br />
USE_COMPOSITELESS_PHOTO_PUT_BLOCK definition symbols to the end of any<br />
of the following CMake variables (if they exist): CMAKE_CXX_FLAGS,<br />
CMAKE_C_FLAGS.<br />
<br />
Example: On Unix your CMAKE_CXX_FLAGS will probably look like:<br />
<br />
-g -O2 -DUSE_NON_CONST -DUSE_COMPOSITELESS_PHOTO_PUT_BLOCK<br />
<br />
On Windows (Microsoft MSDev nmake mode):<br />
<br />
/W3 /Zm1000 /GX /GR /YX /DUSE_NON_CONST /DUSE_COMPOSITELESS_PHOTO_PUT_BLOCK<br />
<br />
b) or a more intrusive solution:<br />
<br />
Edit the top VTK/CMakeList.txt file and the following lines add '''at the<br />
top''' of this file:<br />
<br />
ADD_DEFINITIONS(<br />
-DUSE_NON_CONST<br />
-DUSE_COMPOSITELESS_PHOTO_PUT_BLOCK<br />
)<br />
<br />
<br />
=== When I try to run my program with Java-wrapped VTK, why do I get "java.lang.NoClassDefFoundError: vtk/vtkSomeClassName"? ===<br />
The file '''vtk.jar''' is not in your CLASSPATH in your execution environment.<br />
<br />
<br />
=== When I try to run my program with Java-wrapped VTK, why do I get "java.lang.UnsatisfiedLinkError: no vtkSomeLibraryName"? ===<br />
Some or all of the library (e.g., dll) files cannot be found. Make sure the files exist and that the PATH environment variable of your execution environment points to them.<br />
<br />
<br />
=== When I try to run my program with Java-wrapped VTK, why do I get Exception in thread "main" java.lang.UnsatisfiedLinkError: GetOutput_2 at vtk.vtkPolyDataAlgorithm.GetOutput_2(Native Method) ? ===<br />
<br />
== Using VTK ==<br />
<br />
=== The C++ compiler cannot convert some pointer type to another pointer type in my little program ===<br />
<br />
For instance, the C++ compiler cannot convert a <b><tt>vtkDataSet *</tt></b> type to a <b><tt>vtkImageData *</tt></b> type.<br />
<br />
It means the compiler does not know the relationship between a <b><tt>vtkDataSet</tt></b> and a <b><tt>vtkImageData</tt></b>. This relationship is actually inheritance: <b><tt>vtkImageData</tt></b> is a subclass of <b><tt>vtkDataSet</tt></b>. The only way for the compiler to know this relationship is to include the header file of the subclass, that is:<br />
<br />
#include "vtkImageData.h"<br />
<br />
If you wonder why the compiler did not complain about an unknown type, it is because somewhere (probably in a filter header file) there is a forward class declaration, like:<br />
<br />
class vtkImageData;<br />
<br />
=== Accessing a pointer in Python ===<br />
<br />
If you use VTK code with Python and need to pass some VTK data onto them, there are 2 approaches to wrap your code:<br />
# first, you can use the VTK wrapper (already used for the wrapping of VTK code)<br />
# you can use SWIG, which results in a light-weight module.<br />
<br />
In the second case, you will need to convert some VTK data, say a vtkPolyData, to a void pointer (no, it is not sufficient to just pass the object). For that, you can use the __this__ member variable in Python for the VTK data - see mailing archives:<br />
<br />
* [http://public.kitware.com/pipermail/vtkusers/2003-October/070054.html vtk, Python and SWIG - 'state of the union']<br />
<br />
=== What object/filter should I use to do ??? ===<br />
<br />
Frequently when starting out with a large visualization system people<br />
are not sure what object to use to achieve a desired effect.<br />
<br />
The most up-to-date information can be found in the VTK User's Guide<br />
(http://www.kitware.com/products/vtkguide.html).<br />
<br />
Alternative sources for information are the appendix of the book which<br />
has nice one line descriptions of what the different objects do and the<br />
VTK man pages (http://www.vtk.org/doc/nightly/html/classes.html).<br />
<br />
Additionally, the VTK man pages feature a "Related" section that provide<br />
links from each class to all the examples or tests using that class<br />
(http://www.vtk.org/doc/nightly/html/pages.html). This information is<br />
also provided in each class man page under the "Tests" or "Examples"<br />
sub-section.<br />
<br />
Some useful books are listed at http://www.vtk.org/buy-books.php<br />
<br />
=== What 3D file formats can VTK import and export? ===<br />
<br />
The following table identifies the file formats that VTK can read and<br />
write. Importer and Exporter classes move full scene information into or<br />
out of VTK. Reader and Writer classes move just geometry.<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
|- bgcolor="#abcdef"<br />
! File Format !! Read !! Write<br />
|-<br />
| 3D Studio || vtk3DSImporter || <br />
|-<br />
| AVS "UCD" format || vtkAVSucdReader || <br />
|-<br />
| Movie BYU || vtkBYUReader || vtkBYUWriter<br />
|-<br />
| Renderman || || vtkRIBExporter<br />
|-<br />
| Open Inventor 2.0 || || vtkIVExporter/vtkIVWriter<br />
|-<br />
| CAD STL || vtkSTLReader || vtkSTLWriter<br />
|-<br />
| Fluent GAMBIT ASCII || vtkGAMBITReader || <br />
|-<br />
| Unigraphics Facet Files || vtkUGFacetReader || <br />
|-<br />
| Marching Cubes || vtkMCubesReader || vtkMCubesWriter<br />
|-<br />
| Wavefront OBJ || || vtkOBJExporter<br />
|-<br />
| VRML 2.0 || || vtkVRMLExporter<br />
|-<br />
| VTK Structured Grid &dagger; || vtkStructuredGridReader || vtkStructuredWriter<br />
|-<br />
| VTK Poly Data &dagger; || vtkPolyDataReader || vtkPolyDataWriter<br />
|-<br />
| PLOT3D || vtkPLOT3DReader || <br />
|-<br />
| CGM || || vtkCGMWriter<br />
|-<br />
| OBJ || vtkOBJReader || <br />
|-<br />
| Particle || vtkParticleReader || <br />
|-<br />
| PDB || vtkPDBReader || <br />
|-<br />
| PLY || vtkPLYReader || vtkPLYWriter<br />
|-<br />
| Gaussian || vtkGaussianCubeReader || <br />
|-<br />
| Facet || vtkFacetReader || vtkFacetWriter<br />
|-<br />
| XYZ || vtkXYZMolReader || <br />
|-<br />
| Ensight &Dagger; || vtkGenericEnSightReader || <br />
|}<br />
<br />
&dagger; See the books [http://www.kitware.com/products/vtktextbook.html The<br />
Visualization Toolkit, An Object-Oriented Approach to 3D Graphics] or<br />
[http://www.kitware.com/products/vtkguide.html the User's Guide] for details<br />
about structured grid and poly data file formats.<br />
<br />
&Dagger; The class vtkGenericEnSightReader allows the user to read an EnSight<br />
data set without a priori knowledge of what type of EnSight data set it<br />
is (among vtkEnSight6BinaryReader, vtkEnSight6Reader,<br />
vtkEnSightGoldBinaryReader, vtkEnSightGoldReader,<br />
vtkEnSightMasterServerReader, vtkEnSightReader).<br />
<br />
For any other file format you may want to search for a converter to a<br />
known VTK file format, more info on:<br />
http://www.tech-edv.co.at/lunix/UTILlinks.html<br />
<br />
=== Why can't I find vtktcl (vtktcl.c)? ===<br />
<br />
In versions of VTK prior to 4.0 VTK Tcl scripts would require a:<br />
<br />
catch {load vtktcl} <br />
<br />
so that they could be executed directly from wish. In VTK 4.0 the<br />
correct mechanism is to use:<br />
<br />
package require vtk<br />
<br />
For people using versions earlier than 4.0, vtktcl is a shared library<br />
that is built only on the PC. Most examples used the "catch" notation so<br />
that they will work on UNIX and on the PC. On UNIX you must use the vtk<br />
executable/shell which should be in vtk/tcl/vtk.<br />
<br />
=== Why does this filter not produce any output? eg. GetPoints()==0 ===<br />
<br />
This is a very common question for VTK users. VTK uses a pipeline mechanism for rendering, which has multiple benefits, including the fact that filters that aren't used don't get called. This means that when you call a function such as x->GetOutput()->GetPoints() this will return 0 if the filter has not yet been executed. Just call x->Update() beforehand to make the pipeline update everything up to that point and it should work. -timh<br />
<br />
=== Problems with vtkDecimate and vtkDecimatePro ===<br />
<br />
''vtkDecimate'' and ''vtkDecimatePro'' have been tested fairly heavily so<br />
all known bugs have been removed. However, there are three situations<br />
where you can encounter weird behavior:<br />
<br />
# The mesh is not all triangles. Solution: use ''vtkTriangleFilter'' to triangulate polygons.<br />
# The mesh consists of independent triangles (i.e., not joined at vertices - no decimation occurs). Solution: use ''vtkCleanPolyData'' to link triangles.<br />
# Bad triangles are present: e.g., triangles with duplicate vertices such as (1,2,1) or (100,100,112), or (57,57,57), and so on. Solution: use ''vtkCleanPolyData''.<br />
<br />
=== How can I read DICOM files ? ===<br />
<br />
Starting with VTK 4.4, you can use the [http://www.vtk.org/doc/nightly/html/classvtkDICOMImageReader.html vtkDICOMImageReader class] to read DICOM files. Note however that DICOM is a huge protocol, and vtkDICOMImageReader is not able to read every DICOM file out there. If it does not meet your needs, we suggest you look for an existing converter before coding your own. Some of them are listed in the [http://www.dclunie.com/medical-image-faq/html/part8.html The Medical Image Format FAQ (Part 8)].<br />
<br />
==== GDCM ====<br />
<br />
For a more elaborate DICOM library that supports more image format, you might try [http://gdcm.sourceforge.net GDCM].<br />
Specifically: [http://gdcm.sourceforge.net/html/classvtkGDCMImageReader.html vtkGDCMImageReader] & [http://gdcm.sourceforge.net/html/classvtkGDCMImageWriter.html vtkGDCMImageWriter]<br />
<br />
Grassroots DiCoM is a C++ library for DICOM medical files. It is automatically wrapped to python/C#/Java (using swig). It supports RAW,JPEG (lossy/lossless),J2K,JPEG-LS,RLE and deflated. It also comes with DICOM Part 3,6 & 7 of the standard as XML files.<br />
<br />
If GDCM is too complex to integrate in your environment you can also consider simply using the command line converter: [http://apps.sourceforge.net/mediawiki/gdcm/index.php?title=Gdcmconv gdcmconv] to convert an unsupported DICOM file into something that vtkDICOMImageReader, can support. Typically you would want:<br />
<br />
gdcmconv --raw compressed_input.dcom uncompressed_output.dcom<br />
<br />
==== dicom2 ====<br />
<br />
Sebastien BARRE wrote a free DICOM converter, named dicom2, that can be<br />
used to convert medical images to raw format. This tool is a command<br />
line program and does not provide any GUI at the moment.<br />
http://dicom2.barre.nom.fr/<br />
<br />
There is a special section dedicated to the VTK:<br />
http://dicom2.barre.nom.fr/how-to.html, then "Convert to raw (vtk)"<br />
<br />
The following page also provide links to several other DICOM converters:<br />
http://www.barre.nom.fr/medical/samples/index.html#links<br />
<br />
==== vtkVolume16Reader ====<br />
<br />
When searching the vtkusers mailing list a lot of posts are still using vtkVolume16Reader to read in DICOM file. It will works in the following case:<br />
* You know the dimension (cols & rows) of your image<br />
* You know the spacing of your image<br />
* You know the pixel type (pixel type & #components) of your image<br />
* You know Pixel Data (7fe0,0010) is the last element in the image<br />
* You know Pixel Data (7fe0,0010) was sent in uncompressed format (not encapsulated)<br />
<br />
All those requirements are a stronger set of requirements than vtkDICOMImageReader, therefore it is encourage to use vtkDICOMImageReader instead.<br />
<br />
==== The spacing in my DICOM files are wrong ====<br />
<br />
Image Position (Patient) (0020,0032) is the only attribute that can be relied on to determine the "reconstruction interval" or "space between the center of slices".<br />
<br />
If the distance between Image Position (Patient) (0020,0032) of two parallel slices along the normal to Image Orientation (Patient) (0020,0037) is not the same as whatever happens to be in the DICOM Spacing Between Slices (0018,0088) attribute, then (0018,0088) is incorrect, without question<br />
<br />
This is a known bug in some scanners.<br />
<br />
When Slice Thickness (0018,0050) + Spacing Between Slices (0018,0088) equals the computed reconstruction interval, then chances are the modality implementor has made the obvious mistake of misinterpreting the definition of<br />
(0018,0088) to mean the distance between edges (gap) rather than the distance between centers.<br />
<br />
Further, one should never use Slice Location (0020,1041) either, an optional and purely annotative attribute, though chances are that the distance between the Slice Location (0020,1041) values of two slices will match the distance along the<br />
normal to the orientation derived from the position.<br />
<br />
The GDCM library simply discard any information present in the (0018,0088) tag and instead recompute the spacing by computing the distance in between two consecutive slices (along the normal).<br />
<br />
GDCM 1.x:<br />
typedef std::vector<gdcm::File *> FileList;<br />
FileList l;<br />
gdcm::SerieHelper sh;<br />
sh.OrderFileList(l); // calls ImagePositionPatientOrdering()<br />
zspacing = sh.GetZSpacing();<br />
<br />
GDCM 2.x:<br />
IPPSorter ipp;<br />
ipp.Sort( filenames );<br />
zspacing = ipp.GetZSpacing();<br />
<br />
=== How to handle large data sets in VTK ===<br />
<br />
One of the challenges in VTK is to efficiently handle large datasets. By<br />
default VTK is tuned towards smaller datasets. For large datasets there<br />
are a couple of changes you can make that should yield a much smaller<br />
memory footprint (less swapping) and also improve rendering performance.<br />
The solution is to:<br />
<br />
# Use ReleaseDataFlag,<br />
# Turn on ImmediateModeRendering<br />
# Use triangle strips via vtkStripper<br />
# Use a different filter or mapper<br />
<br />
Each of these will be discussed below.<br />
<br />
==== Using ReleaseDataFlag ====<br />
<br />
By default VTK keeps a copy of all intermediate results between filters<br />
in a pipeline. For a pipeline with five filters this can result in<br />
having six copies of the data in memory at once. This can be controlled<br />
using ReleaseDataFlag and GlobalReleaseDataFlag. If ReleaseDataFlag is<br />
set to one on a data object, then once a filter has finished using that<br />
data object, it will release its memory. Likewise, if<br />
GlobalReleaseDataFlag is set on ANY data object, all data objects will<br />
release their memory once their dependent filter has finished executing.<br />
For example in Tcl and C++<br />
<br />
# Tcl<br />
vtkPolyDataReader reader<br />
[reader GetOutput] ReleaseDataFlagOn<br />
<br />
// C++<br />
vtkPolyDataReader *reader = vtkPolyDataReader::New();<br />
reader->GetOutput()->ReleaseDataFlagOn();<br />
<br />
or<br />
<br />
// C++<br />
vtkPolyDataReader *reader = vtkPolyDataReader::New();<br />
reader->GetOutput()->GlobalReleaseDataFlagOn();<br />
<br />
While turning on the ReleaseDataFlag will reduce your memory footprint,<br />
the disadvantage is that none of the intermediate results are kept in<br />
memory. So if you interactively change a parameter of a filter (such as<br />
the isosurface value), all the filters will have to re-execute to<br />
produce the new result. When the intermediate results are stored in<br />
memory, only the downstream filters would have to re-execute.<br />
<br />
One hint for good interactive performance. If only one stage of the<br />
pipeline can have its parameters changed interactively (such as the<br />
target reduction in a decimation filter), only retain the data just<br />
prior to that step (which is the default) and turn ReleaseDataFlag on<br />
for all other steps.<br />
<br />
==== Use ImmediateModeRendering ====<br />
<br />
By default, VTK uses OpenGL display lists which results in another copy<br />
of the data being stored in memory. For most large datasets you will be<br />
better off saving memory by not using display lists. You can turn off<br />
display lists by turning on ImmediateModeRendering. This can be<br />
controlled on a mapper by mapper basis using ImmediateModeRendering, or<br />
globally for all mappers in a process by using<br />
GlobalImmediateModeRendering. For example:<br />
<br />
# Tcl<br />
vtkPolyDataMapper mapper<br />
mapper ImmediateModeRenderingOn<br />
<br />
// C++<br />
vtkPolyDataMapper *mapper = vtkPolyDataMapper::New();<br />
mapper->ImmediateModeRenderingOn();<br />
<br />
or<br />
<br />
// C++<br />
vtkPolyDataMapper *mapper = vtkPolyDataMapper::New();<br />
mapper->GlobalImmediateModeRenderingOn();<br />
<br />
The disadvantage to using ImmediateModeRendering is that if memory is<br />
not a problem, your rendering rates will typically be slower with<br />
ImmediateModeRendering turned on.<br />
<br />
==== Use triangle strips via vtkStripper. ====<br />
<br />
Most filters in VTK produce independent triangles or polygons which are<br />
not the most compact or efficient to render. To create triangle strips<br />
from polydata you can first use vtkTriangleFilter to convert any<br />
polygons to triangles (not required if you only have triangles to start<br />
with) then run it through a vtkStipper to convert the triangles into<br />
triangle strips. For example in C++<br />
<br />
vtkPolyDataReader *reader = vtkPolyDataReader::New();<br />
reader->SetFileName("yourdatafile.vtk");<br />
reader->GetOutput()->ReleaseDataFlagOn();<br />
<br />
vtkTriangleFilter *tris = vtkTriangleFilter::New();<br />
tris->SetInput(reader->GetOutput());<br />
tris->GetOutput()->ReleaseDataFlagOn();<br />
<br />
vtkStripper *strip = vtkStripper::New();<br />
strip->SetInput(tris->GetOutput());<br />
strip->GetOutput()->ReleaseDataFlagOn();<br />
<br />
vtkPolyDataMapper *mapper = vtkPolyDataMapper::New();<br />
mapper->ImmediateModeRenderingOn();<br />
mapper->SetInput(tris->GetOutput());<br />
<br />
The only disadvantage to using triangle strips is that they require time<br />
to compute, so if your data is changing every time you render, it could<br />
actually be slower.<br />
<br />
==== Use a different filter or mapper ====<br />
<br />
This is a tough issue. In VTK there are typically a couple of ways to<br />
solve any problem. For example an image can be rendered as a polygon for<br />
each pixel, or it can be rendered as a single polygon with a texture map<br />
on it. For almost all cases the second approach will be much faster than<br />
the first event though VTK supports both. There isn't a single good<br />
answer for how to find the best approach. If you suspect that it is<br />
running more slowly than it should, try posting to the mailing list or<br />
looking for other ways to achieve the same result.<br />
<br />
=== VTK is slow, what is wrong? ===<br />
<br />
We have heard people say that VTK is really slow. In many of these<br />
cases, changing a few parameters can make a huge difference in performance.<br />
<br />
If you find that VTK is slower than other visualization systems running<br />
the same problem first take a look at the FAQ section dealing with large<br />
data: [[VTK_FAQ#How_to_handle_large_data_sets_in_VTK|How to handle large data sets in VTK]]. Many of its suggestions<br />
will improve VTK's performance significantly for many datasets.<br />
<br />
If you still find VTK slow, please let us know and send us an example<br />
(to mailto:kitware@kitware.com). In the past there<br />
have been some filters that simply were not written to be fast. When we<br />
come across one of these we frequently can make minor changes to the<br />
filter that will make it run much more quickly. In fact many changes in<br />
the past couple years have been this type of performance improvement.<br />
<br />
=== Is VTK thread-safe ? ===<br />
<br />
The short answer is no.<br />
<br />
Many VTK sources and filters cache information and will not perform as<br />
expected when used in multiple threads. When writing a multithreaded<br />
filter, the developer has to be very careful about how she accesses data.<br />
<br />
For example, GetXXX() methods which return a pointer should only be used<br />
to read. If the pointer returned by these methods are used to change<br />
data in multiple threads (without mutex locks), the result will most<br />
probably be wrong and unpredictable. In many cases, there are<br />
alternative methods which copy the data referred by the pointer. For<br />
example:<br />
<br />
float* vtkDataArray::GetTuple(const vtkIdType i);<br />
<br />
is thread-safe only for reading whereas:<br />
<br />
void vtkDataArray::GetTuple (const vtkIdType i, float * tuple);<br />
<br />
copies the requested tuple and is thread safe even if tuple is modified<br />
afterwards (as long as the same pointer is not passed as the argument<br />
tuple simultaneously by different threads).<br />
<br />
Unfortunately, only very few methods are clearly marked as<br />
thread-(un)safe and, in many situations, the developer has to dig into<br />
the source code to figure out whether an accessor is thread safe or not.<br />
<br />
''vtkDataSet'' and most of it's sub-classes are well documented and almost<br />
all methods are marked thread-safe or not thread-safe. This might be a<br />
good place to start. Most of the filters in imaging and some filters in<br />
graphics (like ''vtkStreamer'') are good examples of how a multi-threaded<br />
filter can be written in VTK.<br />
<br />
However, if you are not interested in developing multithreaded filters<br />
but want to process some data in parallel using the same (or similar)<br />
pipeline, your job is much easier. To do this, create a different copy<br />
of the pipeline on each thread and execute them in parallel on a<br />
different piece of the data. This is best accomplished by using<br />
''vtkThreadedController'' (instead of ''vtkMultiThreader''). See the<br />
documentation of ''vtkMultiProcessController'' and ''vtkThreadedController''<br />
and the examples in the parallel directory for details on how this can<br />
be done.<br />
<br />
Also, note that most of the OpenGL libraries are not thread-safe.<br />
Therefore, if you are rendering to multiple render windows from<br />
different threads, you are likely to get in trouble, even if you have<br />
mutex locks around the render calls.<br />
<br />
=== Can I use STL with VTK? ===<br />
<br />
As of VTK version 4.2, you can use the STL.<br />
However, see the [[VTK Coding Standards]] for limitations.<br />
Here's an example (from vtkInterpolateVelocityField):<br />
<br />
In the .h file (the PIMPL) forward declare<br />
<br />
class vtkInterpolatedVelocityFieldDataSetsType;<br />
//<br />
class VTK_COMMON_EXPORT vtkInterpolatedVelocityField : public vtkFunctionSet<br />
{<br />
private:<br />
vtkInterpolatedVelocityFieldDataSetsType* DataSets;<br />
};<br />
<br />
In the .cxx file define the class (here deriving from the STL vector<br />
container)<br />
<br />
# include <vtkstd/vector><br />
typedef vtkstd::vector< vtkSmartPointer<vtkDataSet> > DataSetsTypeBase;<br />
class vtkInterpolatedVelocityFieldDataSetsType: public DataSetsTypeBase<br />
{};<br />
<br />
In the .cxx file construct and destruct the class:<br />
<br />
vtkInterpolatedVelocityField::vtkInterpolatedVelocityField()<br />
{<br />
this->DataSets = new vtkInterpolatedVelocityFieldDataSetsType;<br />
}<br />
vtkInterpolatedVelocityField::~vtkInterpolatedVelocityField()<br />
{<br />
delete this->DataSets;<br />
}<br />
<br />
And in the .cxx file use the container as you would any STL container:<br />
<br />
for ( DataSetsTypeBase::iterator i = this->DataSets->begin();<br />
i != this->DataSets->end(); ++i)<br />
{<br />
ds = i->GetPointer();<br />
....<br />
}<br />
<br />
=== What image file formats can VTK read and write? ===<br />
<br />
The following table identifies the image file formats that VTK can read<br />
and write.<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
|- bgcolor="#abcdef"<br />
! Image File !! Read !! Write<br />
|-<br />
| AVI || || vtkAVIWriter<br />
|-<br />
| Bitmap || vtkBMPReader || vtkBMPWriter<br />
|-<br />
| Digital Elevation Model (DEM) || vtkDEMReader || <br />
|-<br />
| DICOM || vtkDICOMImageReader || <br />
|-<br />
| GE Signal || vtkGESignaReader || <br />
|-<br />
| JPEG || vtkJPEGReader || vtkJPEGWriter<br />
|-<br />
| FFMPEG || || vtkFFMPEGWriter<br />
|-<br />
| MINC (1.1) || vtkMINCImageReader || vtkMINCImageWriter<br />
|-<br />
| Binary UNC meta image data || vtkMetaImageReader || vtkMetaImageWriter<br />
|-<br />
| PNG || vtkPNGReader || vtkPNGWriter<br />
|-<br />
| PNM || vtkPNMReader || vtkPNMWriter<br />
|-<br />
| PostScript || || vtkPostScriptWriter <br />
|-<br />
| SLC || vtkSLCReader || <br />
|-<br />
| TIFF || vtkTIFFReader || vtkTIFFWriter<br />
|-<br />
| RAW files &dagger; || vtkImageReader, vtkVolumeReader || <br />
|}<br />
<br />
&dagger; A typical example of use is:<br />
<br />
# Image pipeline<br />
reader = vtkImageReader()<br />
reader.SetDataByteOrderToBigEndian()<br />
reader.SetDataExtent(0,511,0,511,0,511)<br />
reader.SetFilePrefix("Ser397")<br />
reader.SetFilePattern("%s/I.%03d")<br />
reader.SetDataScalarTypeToUnsignedShort()<br />
reader.SetHeaderSize(5432)<br />
<br />
=== Printing an object. ===<br />
<br />
Sometimes when debugging you need to print an object to a string, either<br />
for logging purposes, or in the case of windows applications, to a window.<br />
<br />
Here is a way to do this:<br />
<br />
std::ostringstream os;<br />
//<br />
// "SomeVTKObject" could be, for example, <br />
// declared somewhere as: vtkCamera *SomeVTKObject;<br />
//<br />
SomeVTKObject->Print(os);<br />
vtkstd::string str = os.str();<br />
//<br />
// Process the string as you want<br />
<br />
=== Writing a simple CMakeLists.txt. ===<br />
<br />
If you get something that looks like:<br />
<br />
undefined reference to<br />
`__imp___ZN13vtkTIFFReader3NewEv'<br />
collect2: ld returned 1 exit status <br />
<br />
You certainly forgot to pass in a library to your executable. The easisest way is to use CMakeLists.txt file.<br />
<br />
For example the minimal project is:<br />
<br />
FIND_PACKAGE(VTK)<br />
IF (VTK_FOUND)<br />
INCLUDE (${VTK_USE_FILE})<br />
ENDIF (VTK_FOUND)<br />
ADD_EXECUTABLE(tiff tiff.cxx )<br />
TARGET_LINK_LIBRARIES (tiff<br />
vtkRendering<br />
)<br />
<br />
Since vtkRendering is link against all other vtk lib. Except if you are building VTK with Hybrid or Parallel in that case you need to explicitely specify which library you want to link against.<br />
<br />
=== Testing for VTK within a configure script ===<br />
<br />
VTK uses CMake as build tool but if you VTK-based application wants to use autoconf and/or automake, then you will find very useful an M4 macro file which detects from your configure script the presence/absence of VTK on the user system. VTK won't add such file into the official distribution but you can always write your own, as I did.<br />
Look in [[VTK_Autoconf]] page for more info.<br />
<br />
=== How do I get my C++ code editor to do VTK-style indentation? ===<br />
<br />
If you are writing code with VTK, you may want to follow the [[VTK Coding Standards]]. This is particularly important if you plan to contribute back to VTK. Most C++ code editors will help you with indenting, but the indenting may differ significantly from that prescribed by the [[VTK Coding Standards]]. Fortunately, most editors have enough options to allow you to change the indention enough to get at least close to the VTK-style indentation.<br />
<br />
Below is a list of C++ editors and some suggestions on getting the indentation VTK compliant. If you use a popular editor that is not listed here, please feel free to contribute.<br />
<br />
==== Microsoft Visual C++ .NET indentation ====<br />
<br />
Under the "Tools" menu, select "Options". Go to the options under "Text Editor" and then "C/C++". Click the "Tabs" options. Set "Indenting" to "Smart", "Indent Size" to 2, and select "Insert spaces". Click the "Formatting" options enable "Indent braces".<br />
<br />
This will make most of the indentation correct. However, it will indent all of the braces. In VTK classes, most of the braces are indented, but those starting a class, method, or function are typically flush left. You will have to correct this on your own.<br />
<br />
==== Emacs indentation ====<br />
<br />
Place the [[Elisp Code for VTK-Style C Indentation]] in your .emacs file.<br />
<br />
==== Vim indentation ====<br />
<br />
[[user talk:Andy|Andy Cedilnik]] has some information on following the VTK coding guidelines using vim. You may place the following in your <code>~/.vimrc</code> file<br />
set tabstop=2 " Tabs are two characters<br />
set shiftwidth=2 " Indents are two charactes too<br />
set expandtab " Do not use tabs<br />
set cinoptions={1s,:0,l1,g0,c0,(0,(s,m1<br />
"Keep tabs in makefiles as they are significant:<br />
:autocmd BufRead,BufNewFile [Mm]akefile :set noexpandtab<br />
<br />
=== How to display transparent objects? ===<br />
(keywords: alpha, correct, depth, geometry, object, opacity, opaque, order, ordering, peel, peeling, sorting, translucent, transparent.)<br />
<br />
When opaque geometry is rendered, there is no need to sort it because the depth buffer (or z-buffer) is used and the sorting is done automatically by keeping the geometry closest to the viewpoint at<br />
a given pixel. (It is easy because it is a MAX/MIN calculation, not a real sorting).<br />
<br />
With translucent geometry the final color of a pixel is the contribution of all the geometry primitives visible through the pixel. The color of the pixel is the result of <b>a</b> blending operation between the colors of all visible primitives. Blending operations themselves are usually order-dependent (ie not commutative). That's why depth sorting is required. There are two ways to fix the ordering in VTK:<br />
<br />
*1. Append all your polygonal geometry with [http://www.vtk.org/doc/nightly/html/classvtkAppendPolyData.html vtkAppendPolyData] and pass it to [http://www.vtk.org/doc/nightly/html/classvtkDepthSortPolyData.html vtkDepthSortPolyData]. See this tcl [http://public.kitware.com/cgi-bin/viewcvs.cgi/*checkout*/Hybrid/Testing/Tcl/depthSort.tcl?root=VTK&content-type=text/plain example]. Depth sorting is done per centroid of geometry primitives, not per pixel. For this reason it is not exact but it solves <b>most</b> of the ordering and gives result usually good enough.<br />
* 2. If the graphics card supports it, use "[[VTK/Depth_Peeling | depth peeling]]". It performs per pixel sorting (better result) but it is really slow.<br />
<br />
=== What's the deal with SetInput() vs. SetInputConnection()? ===<br />
(keywords: SetInput, SetInputConnection, vtkAlgorithm, algorithm, pipeline, source)<br />
<br />
In the transition from VTK 4 to VTK 5, the VTK pipeline executive was completely cleaned up and redesigned. The fundamental idea behind the new pipeline is that the "pipeline" should consist of a chain of "algorithm" objects.<br />
The algorithms are connected together with the familiar b->SetInputConnection(a->GetOutputPort()) methods.<br />
<br />
So how is this different from SetInput()/GetOutput()? The difference between an "OutputPort" and an "Output" is as follows:<br />
<br />
* OutputPort (''vtkAlgorithmOutput''): A trivial object that says "I am output port N of algorithm X" (usually N = 0).<br />
* Output (''subclass of vtkDataObject''): A container for data produced by any VTK code.<br />
<br />
The "OutputPort" method does not presuppose anything about what data (if any) will pass along the pipeline. It could simply signify that algorithm "a" must execute before algorithm "b". This provides enormous flexibility. Trust the VTK designers here, it's better to do things this way than to have the user grab the actual data object from the output of one algorithm and shove it into the input of another.<br />
<br />
However, any newcomer to VTK will quickly notice that the use of SetInputConnection() is not universal. The reason is this: only vtkAlgorithm objects can have a SetInputConnection() or GetOutputPort() method. Some objects that can take inputs are not derived from vtkAlgorithm. For example vtkImageActor is a vtkProp3D and therefore it cannot be a vtkAlgorithm (VTK never uses multiple inheritance). This is a case of an old VTK object that doesn't "fit" the new VTK 5 pipeline. However, the VTK developers did not want to throw away such useful classes when the pipeline was redesigned. Instead, such classes are still served by the backwards-compatible SetInput() method.<br />
<br />
So, use SetInputConnection() whenever you can, but if there is no SetInputConnection(), then go ahead and use SetInput(). There is nothing wrong with doing so. The new pipeline is backwards compatible with the old pipeline methods.<br />
<br />
== Platform-specific questions ==<br />
<br />
=== What platforms does vtk run on? ===<br />
<br />
VTK should compile and run on most versions of Unix, Linux, Windows, and Mac OS X. It has been tested on Suns, SGIs, HPs, Alphas, RS6000s and many Windows and Mac workstations.<br />
<br />
=== What Graphics Cards work with VTK ===<br />
<br />
VTK uses OpenGL to perform almost all of its rendering and some graphics cards/drivers have better support for OpenGL than others. This is not a listing of what cards perform well. It is a listing of what cards actually produce correct results. Here is a list of cards and their status roughly in best to worst order.<br />
<br />
* Any Nvidia desktop card on Windows -- 100% compatible<br /> <br />
* Any ATI desktop cards on Windows -- 100% compatible<br /><br />
* Mesa -- most releases pass all VTK tests<br /><br />
* Microsoft Software OpenGL -- passes all VTK tests but does have a couple bugs<br /><br />
* Mac graphics cards -- these usually pass all VTK tests. Older cards may have some issues, for example, the ATI Rage 128 Pro does not support textures larger than 1024x1024.<br /><br />
* Non-linux UNIX cards (Sun HP SGI) -- These generally work<br /><br />
* Any Nvidia card under linux -- these usually pass all VTK tests but have some issues<br /><br />
* Any ATI card under linux -- these usually pass all VTK tests but have some issues<br /><br />
* Nvidia laptop graphics cards under Windows -- known to have some issues, newer cards pass all tests<br /><br />
* ATI laptop graphics cards under Windows -- known to have some issues, newer cards pass all tests (e.g. [http://public.kitware.com/pipermail/vtkusers/2004-August/075966.html ATI Mobility Radeon 9600])<br /><br />
* Intel Extreme Graphics -- fails some VTK tests<br /><br />
<br />
=== How do I build the examples on the PC running Windows? ===<br />
<br />
Since building the C++ examples on the PC isn't all that easy, here are<br />
some instructions from Jack McInerney.<br />
<br />
Steps for creating a VTK C++ project 8/14/96<br />
<br />
This is based on what I learned creating a project to run the Mace<br />
example. These steps allowed me to successfully built and run this example.<br />
<br />
# Create a console project (File, New, then select Console application).<br />
# Add the files of interest to the project. (e.g., Mace.cxx)<br />
# Under Build, select Update all Dependencies. A long list of .hh files will show up under dependencies<br /> For this to work, Visual C++ needs to know where to look to find the include files. In my case they are at C:\VTK\VTK12SRC\INCLUDE. To tell Visual C++ to look there, go to Tools, Options. Select the tab Directories. Under the list for Include files add: C:\VTK\VTK12SRC\INCLUDE<br />
# Compile the file Mace.cxx. This will lead to many warnings about data possibly lost as double variables are converted to float variables. These can be gotten rid of by going to Build, Settings, and select the C++ tab. Under the General catagory, set Warning Level to 1* (instead of 3).<br />
# Before linking, some additional settings must be modified. Go to Build, Settings, and select the Link tab. In the General catagory, add the libraries opengl32.lib and glaux.lib to the Object/Library Modules. Put a space between each file name. Then select the C++ tab and the Category: Code Generation. Under Use Run-Time Library, select Debug Multithreaded DLL. Select OK to exit the dialog box. The above libraries are available from Microsoft's Web site at: http://www.microsoft.com/softlib/mslfiles/Opengl95.exe or ftp://ftp.microsoft.com/softlib/mslfiles/Opengl95.exe <br /> This is a self extracting archive which contains these files. Simply place them in your windows system directory.<br />
# Link the code by selecting Build, Build MaceProject.exe. I still get one warning when I do this, but it appears to be harmless<br /><br />
<br />
When you go to run the program, it will bomb out unless it can find 2<br />
DLLs: Opengl32.dll and Glu32.dll. These need to be located either in the<br />
project directory or the C:\WINDOWS directory. These files are supplied<br />
on the vtk CD-ROM (in the vtk\bin directory).<br />
<br />
=== How do I build the Java examples on the PC running Windows? ===<br />
One common issue building the examples is missing one or all of vtkPanel, vtkCanvas and AxesActor<br />
classes. For whatever reason these are not in the vtk.jar (at least for 4.2.2).<br />
But you can get them from the source distribution (just unzip the source and extract<br />
these needed .java files, and point your Java-compiler to them).<br />
<br />
Another common issue appears to be class loading dependency errors. Make sure the<br />
directory with the .dll files is in your classpath when you run (default location<br />
is C:\Program Files\vtk42\bin\). Yet this still seems insufficient for some of the<br />
libraries. One possible solution is to copy the Java awt.dll to this directory as<br />
well.<br />
<br />
=== 64-bit System Issues ===<br />
<br />
vtk builds on 64 bit systems, that is, systems where sizeof(void*) is 64 bits. However, parts of the vtk codebase are not 64 bit clean and so runtime problems are likely if that code is used.<br />
<br />
===== General =====<br />
VTK binary files are not compatible between 32-bit and 64-bit systems. For portability, use the default file type, ASCII, for vtkPolyDataWriter, etc. You may be able to write a binary file on a 64-bit system and read it back in.<br />
<br />
===== Mac OS X Specific =====<br />
Mac OS X 10.3 and earlier have no support for 64 bit. On Mac OS X 10.4, VTK cannot be built as 64 bit because it requires Carbon, Cocoa, or X11, none of which are available to 64 bit processes. On Mac OS X 10.5, Cocoa is available to 64 bit processes, but Carbon is not. VTK is known to work reasonably with 64 bit Cocoa.<br />
<br />
===== Windows Specific =====<br />
todo<br />
<br />
=== What size swap space should I use on a PC? ===<br />
<br />
Building vtk on the PC requires a significant amount of memory (at least<br />
when using Visual C++)... but the final product is nice and compact. To<br />
build vtk on the PC, we recommend setting the min/max swap space to at<br />
least 400MB/500MB (depending on how much RAM you have... the sum of RAM<br />
and swap space should be roughly 500+ MB).<br />
<br />
=== Are there any benchmarks of VTK and/or the hardware it runs on? ===<br />
<br />
Take a look at the "Simple Sphere Benchmark":<br />
<br />
http://www.barre.nom.fr/vtk/bench.html<br />
<br />
It is not a "real world" benchmark, but provide synthetic results<br />
comparing different hardware running VTK:<br />
<br />
http://purl.oclc.org/NET/rriv/vtk/sphere-bench<br />
<br />
=== Why is XtString undefined when using VTK+Python on Unix? ===<br />
<br />
This is a side effect of dynamic linking on (some?) Unix systems. It<br />
appears often on Linux with the Mesa libraries at least. The solution is<br />
to make sure your Mesa libraries are linked with the Xt library. One way<br />
to do this is to add "-lXt" to MESA_LIB in your user.make file.<br />
<br />
=== How do I get the Python bindings to work when building VTK with Borland C++? ===<br />
<br />
If you've built VTK with the freely downloadable Borland C++ 5.5 (or its<br />
commercial counterpart) and you're using the Python binaries from<br />
http://www.python.org/, you'll note that when you try to run a VTK<br />
Python example you get something similar to the following error message:<br />
<br />
from vtkCommonPython import * <br />
ImportError: dynamic module does not define init function<br />
(initvtkCommonPython)<br />
<br />
This is because BCC32 prepends an underscore ("_") to all exported<br />
functions, so (in this case) the vtkCommonPython.dll contains a symbol<br />
_initvtkCommonPython which Python does not find. All kits (e.g.<br />
Rendering, Filtering, Patented) will suffer from this problem.<br />
<br />
The solution is to create Borland module definition in the VTK binary<br />
(output) directory, in my case VTK/bin. You have to do this for all kits<br />
that you are planning to use in Python. Each .def file must have the<br />
same basename as the DLL, e.g. "vtkCommonPython.def" for<br />
vtkCommonPython.dll and it must be present at VTK link time. The def<br />
file contains an export alias, e.g.:<br />
<br />
EXPORTS<br />
initvtkCommonPython=_initvtkCommonPython<br />
<br />
The Borland compiler will create an underscore-less alias in the DLL<br />
file and Python will be able to load it as a module.<br />
<br />
=== How do I build Python bindings on AIX? ===<br />
<br />
There is a problem with dynamic loading on AIX. Old AIX did not have<br />
dlopen/dlsym, but they used load mechanism. Python still reflects this.<br />
VTK is however not compatible with the old load mechanism.<br />
<br />
The following patch to Python 2.2.2 makes python use dlopen/dlsym on AIX<br />
5 or greater.<br />
<br />
http://www.vtk.org/files/misc/python_aix.diff<br />
<br />
=== How to build VTK for offscreen rendering? ===<br />
<br />
<b>[this section is obsolete. Mangle Mesa is not supported anymore in VTK>=5.2]</b> (not sure about 5.0)<br />
<br />
Struggled a few hours to get VTK to do offscreen rendering. I use it to<br />
batch process medical images. Without actually producing output on the<br />
screen, I still print resulting images in a report to easily review the<br />
results of an experiment.<br />
<br />
Here is how I solved this problem for VTK version 4.2.2.<br />
<br />
1. Download Mesa-4.0.4 source<br />
<br />
Modify Mesa-4.0.4/Make-config in the 'linux:' target the following vars:<br />
<br />
GL_LIB = libVTKMesaGL.so<br />
GLU_LIB = libVTKMesaGLU.so<br />
GLUT_LIB = libVTKMesaglut.so<br />
GLW_LIB = libVTKMesaGLw.so<br />
OSMESA_LIB = libOSVTKMesa.so<br />
<br />
In Mesa 6.2.1 you need to edit Mesa/configs/default instead:<br />
<br />
# Library names (base name)<br />
GL_LIB = VTKMesaGL<br />
GLU_LIB = VTKMesaGLU<br />
GLUT_LIB = VTKMesaglut<br />
GLW_LIB = VTKMesaGLw<br />
OSMESA_LIB = VTKMesaOSMesa<br />
<br />
<br />
And then export this env var:<br />
<br />
export CFLAGS="-O -g -ansi -pedantic -fPIC -ffast-math-DUSE_MGL_NAMESPACE -D_POSIX_SOURCE -D_POSIX_C_SOURCE=199309L-D_SVID_SOURCE -D_BSD_SOURCE -DUSE_XSHM -DPTHREADS -I/usr/X11R6/include"<br />
<br />
then<br />
<br />
For Mesa 4.0.4<br />
<br />
make -f Makefile.X11 linux <br />
cp Mesa-4.0.4/lib/* /data/usr/mesa404/lib/<br />
<br />
in Mesa 6.2.1:<br />
<br />
make linux-x86<br />
make install<br />
(I generally use /opt/VTKMesa/*)<br />
<br />
I use 'VTKMesa' name extension to avoid conflicts with my RH9.0 libs<br />
(especially OSMesa lib in XFree!). I'm using shared libraries, because<br />
that allows me to use dynamic libs from VTK and not the vtk program<br />
itself without explicitly having to load VTKMesaGL with my app. I copied<br />
the 'VTKMesa' libs in /data/usr/mesa404/lib/, but any odd place probably<br />
will work. Avoid /usr/lib /usr/local/lib for now.<br />
<br />
2. Follow normal instructions to get a proper working vtk, then<br />
<br />
ccmake <br />
<br />
with the following options:<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
| VTK_USE_MANGLED_MESA || ON<br />
|-<br />
| MANGLED_MESA_INCLUDE_DIR || /data/usr/mesa404/include<br />
|-<br />
| MANGLED_MESA_LIBRARY || /data/usr/mesa404/lib/libVTKMesaGL.so<br />
|-<br />
| MANGLED_OSMESA_INCLUDE_DIR || /data/usr/mesa404/include<br />
|-<br />
| MANGLED_OSMESA_LIBRARY || /data/usr/mesa404/lib/libVTKMesaOSMesa.so<br />
|-<br />
| OPENGL_xmesa_INCLUDE_DIR || /data/usr/mesa404/include<br />
|}<br />
<br />
test using /data/prog/VTK-4.2.2/Examples/MangledMesa/Tcl scripts<br />
<br />
<br />
If you're doing things on UNIX, you should also look at [[VTK Classes]]. It has links to RenderWindow objects that are probably easier to use than rebuilding VTK with Mesa.<br />
<br />
=== How to get keyboard events working on Mac OS X? ===<br />
<br />
On Mac OS X, there are (at least) two kinds of executables:<br />
* [http://developer.apple.com/documentation/MacOSX/Conceptual/BPInternational/Articles/InternatSupport.html#//apple_ref/doc/uid/20000278-73764 Application Bundles]<br />
* plain UNIX executables<br />
<br />
For a program to be able to display a graphical interface (that is, display windows that allow mouse and keyboard interaction) it really should be an Application Bundle. If a plain UNIX executable tries, there will be various bugs, such as keyboard and mouse events not working reliably.<br />
<br />
Many, but not all, of the example VTK applications are built as plain UNIX executables, and thus have these problems. This is [http://www.vtk.org/Bug/bug.php?op=show&bugid=2025 VTK bug 2025].<br />
<br />
When you build your own VTK application, it is best to make it in the form of an Application Bundle. With CMake 2.0.5 or later, simply add the following to your CMakeLists.txt file:<br />
<br />
IF(APPLE)<br />
SET(EXECUTABLE_FLAG MACOSX_BUNDLE)<br />
ENDIF(APPLE)<br />
<br />
If for some reason you cannot build as an Application Bundle (perhaps because your app needs command line parameters) you might be able to avoid the above problems by adding an [http://developer.apple.com/documentation/MacOSX/Conceptual/BPRuntimeConfig/Articles/ConfigFiles.html#//apple_ref/doc/uid/20002091-SW1 __info_plist section] to your Mach-O executable. If you succeed, please post to the VTK list.<br />
<br />
=== Can VTK be built as a Universal Binary on Mac OS X? ===<br />
<br />
For VTK 5.0.4 and older, the short answer is "no".<br />
<br />
For VTK CVS the short answer is "mostly". You need to set CMAKE_OSX_ARCHITECTURES to the architectures you want and CMAKE_OSX_SYSROOT to a Mac OS X SDK that supports Universal builds. The usual settings are:<br />
<br />
CMAKE_OSX_ARCHITECTURES=ppc;i386 <br />
CMAKE_OSX_SYSROOT=/Developer/SDKs/MacOSX10.4u.sdk <br />
<br />
This will result in a Universal build. However, there may be runtime bugs due to VTK's use of TRY_RUN. Work is being done to improve this situation.<br />
<br />
=== How can I stop Java Swing or AWT components from flashing or bouncing between values? ===<br />
<br />
While not strictly a VTK problem, this comes up fairly often when using Java-wrapped VTK. Try the following two JRE arguments to stop the Swing/AWT components flashing:<br />
-Dsun.java2d.ddoffscreen=false -Dsun.java2d.gdiblit=false<br />
Note that these are classified as "unsupported properties," so may not work on all platform or installations (in particular, ddoffscreen refers to DirectDraw and, as such, is specific to Windows).<br />
<br />
=== How can a user process access more than 2 GB of ram in 32-bit Windows? ===<br />
<br />
By default on Windows, the most memory that a user process can access is 2 GB, no matter how much RAM you have installed in your system. With Windows XP Professional you can make it possible for a process to use up to 3 GB of memory by doing two things:<br />
<br />
1) Modify the boot parameters in boot.ini (on my 32 bit WinXP Pro machine, it's in: "C:\boot.ini") to tell the operating system that you want user processes to have access to up to 3GB of RAM (This is a really important file, and if you don't know what you are doing, stop reading this and go back to work!). This is done by adding the /3GB flag to the line of the file that tells the boot loader where the operating system is. My boot.ini file looks like:<br />
<br />
[boot loader]<br />
timeout=30<br />
default=multi(0)disk(0)rdisk(0)partition(1)\WINDOWS<br />
[operating systems]<br />
multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Microsoft Windows XP Professional" /3GB<br />
<br />
This is a very bad file to make mistakes on, so don't - it may be very difficult to repair your computer to boot if you mess up this file. There is a nice description of this in the Microsoft article <br />
[http://www.microsoft.com/whdc/system/platform/server/PAE/PAEmem.mspx Memory Support and Windows Operating Systems].<br />
<br />
2) The other thing that you need to do is make your executable LARGEADDRESSAWARE. Assuming that you have a Windows binary that you want to try this on, you can use the 'editbin' utility that comes with Visual Studio to change the setting of one bit (the IMAGE_FILE_LARGE_ADDRESS_AWARE bit) in the image header of the executable. For a program 'prog.exe' you can make the change by<br />
<br />
editbin /LARGEADDRESSAWARE prog.exe<br />
<br />
Of course, depending on how your program handles memory you might find that it crashes when you try to use the extra memory, but that's a separate issue. If you are compiling your program with a version of Visual Studio you should be able to find the switch to make your program /LARGEADDRESSAWARE.<br />
<br />
=== Shared builds of VTK and debugging QVTKWidget using Visual Studio ===<br />
<br />
Assuming that you have built a shared build of VTK and you may or may<br />
not have a set it up such that there is a path to the release version<br />
of VTK in your PATH statement.<br />
<br />
Then if you debug a project that is using QVTKWidget, you will come<br />
across a problem in that if you are debugging a debug version; the<br />
application depends upon the debug version of QVTK.dll which will<br />
depend upon QtGui4d.dll (among others) and load it. But, because the<br />
release version of QVTK.dll is in the path, QtGiu4.dll will also be<br />
loaded preventing the application from running. You will get a<br />
"QWidget: Must construct a QApplication before a QPaintDevice"<br />
message.<br />
<br />
The solution to this problem is to set the path to the correct build<br />
of VTK on the "'''Debugging'''" properties of your project. Right click on<br />
your project, bring up the properties dialog, and select "'''Debugging'''"<br />
from the list on the left. There should be an "'''Environment'''" line. You<br />
can add variables here using key=value pairs.<br />
For example, add the following line:<br />
PATH=<Path To VTK>\bin\$(OutDir);%PATH%<br />
You can then add the same line to other configurations, such as the release one, by selecting<br />
them from the top left drop down box labelled '''Configuration'''.<br />
<br />
$(OutDir) will be set by Visual Studio to either Debug or Release,<br />
depending upon what configuration you have selected. Make sure <br />
that ;%PATH% is appended so that Qt and other files can be appended <br />
to the PATH statement.<br />
<br />
<br />
== Changes to the VTK API ==<br />
<br />
=== What is the policy on Changes to the API ===<br />
<br />
Between patch releases maintain the API unless there is a really strong reason not to. <br />
<br />
Between regular releases maintain backwards compatibility to the API with prior releases of VTK when doing so does not increase the complexity or readability of the current VTK or when the benefits of breaking the API are negligible.<br />
<br />
Clearly these statements have a lot of wiggle room. For example in vtkLightKit BackLight and Headlight were used and released. Now BackLight and HeadLight might make more sense and probably will be easier for non-native English speakers, but is it worth breaking the API for it, probably not. Another factor is how long the API has been around and how widely used it is. These all indicate how painful it will be to change the API which is half of the cost/benefit decision.<br />
<br />
=== Change to vtkIdList::IsId() ===<br />
<br />
vtkIdList::IsId(int id) used to return a 0 or 1 to indicate whether the<br />
specified id is in the list. Now it returns -1 if the id is not in the<br />
list; or a non-negative number indicating the position in the list.<br />
<br />
=== Changes vtkEdgeTable ===<br />
<br />
vtkEdgeTable had two changes. The constructor now takes no arguments,<br />
and you use InitEdgeInsertion() to tell the class how many points are in<br />
the dataset. Also, IsEdge(p1,p2) now returns a -1 if the edge (defined<br />
by points p1,p2) is not defined. otherwise a non-negative integer value<br />
is returned.<br />
<br />
These changes were made to support the association of attributes with<br />
edges.<br />
<br />
=== Changes between VTK 4.2 and VTK 4.4 (and how to update) ===<br />
<br />
We have removed the CVS date, revision, and the language from the<br />
copyright on all the files. This information wasn't being used much and<br />
it created extra work for developers. For example you edit vtkObject.h<br />
rebuild all of VTK, check in you change, then you must rebuild all of<br />
VTK again because commiting the header file causes it to be changed by<br />
CVS (because the revision number changed) This change will also make it<br />
easier to compare different branches of VTK since these revision number<br />
differences will no longer show up. The CVS revision number is still in<br />
the cxx file in the RevisionMacro. You don't need to make any changes to<br />
your code for this.<br />
<br />
The DataArray classes now use a templated intermediate class to share<br />
their implementation. Again there is no need for you to make changes to<br />
your code.<br />
<br />
Legacy code has been removed. Specifically none of the old style<br />
callbacks are supported and observers should be used instead. So where<br />
you used a filter->SetStartMethod(myFunc) you should do a<br />
filter->AddObserver(vtkCommand::StartEvent,myCommand) Usually this will<br />
require you to create a small class for the observer.<br />
vtkImageOpenClose3D.cxx has an example of using an observer and there<br />
are a few other examples in VTK. If you switch to using Observers your<br />
code should also work with versions of VTK from 3.2 or later since the<br />
Observers have been in VTK since VTK 3.2.<br />
<br />
Many functions that previously took or returned float now take or return<br />
double. To change your code to work with VTK 4.4 or later you can just<br />
replace float with double for the appropriate calls and variables. If<br />
you want your code to work with both old and new versions of VTK you can<br />
use vtkFloatingPointType which is defined to be double in VTK 4.4 and<br />
later and it is float in vtk 4.2.5. In versions of VTK prior to 4.2.5<br />
you can use something like:<br />
<br />
#ifndef vtkFloatingPointType<br />
#define vtkFloatingPointType vtkFloatingPointType<br />
typedef float vtkFloatingPointType;<br />
#endif<br />
<br />
at the beginning of your code. That will set it to the correct value for<br />
all versions of VTK old and new.<br />
<br />
=== Use of New() and Delete() now enforced (vs. new & delete) ===<br />
<br />
Constructors and destructors in VTK are now protected. This means you<br />
can no longer use little "new" or "delete" to create VTK instances.<br />
You'll have to use the methods ::New() and ::Delete() (as has been<br />
standard practice for some time).<br />
<br />
The reason for this is to enforce the use of New() and Delete(). Not<br />
using New() and Delete() can lead to bad mojo, mainly reference counting<br />
problems or not taking advantage of special procedures incorporated into<br />
the New() method (e.g., selecting the appropriate hardware interface<br />
during instance creation time).<br />
<br />
If you've used New() and Delete() in your code, these changes will not<br />
affect you at all. If you're using little "new" or "delete", your code<br />
will no longer and compile and you'll have to switch to New() and Delete().<br />
<br />
=== Changes between VTK 4.4 and VTK 4.6 ===<br />
<br />
Collection Changes<br />
<br />
Collections have had some small changes (originally started by Chris<br />
Volpe) to better support reentrant iteration. Specifically all the<br />
collection have an InitTraversal(sit) and GetNextFoobar(sit) methods.<br />
(where Foobar is what the collection contains, for example<br />
GetNextActor(sit)) The argument to both of these methods is a<br />
vtkCollectionSimpleIterator. Most of the collection use in VTK has been<br />
modified to use these new methods. The advantage is that these new<br />
methods support having the same collection be iterated through in a<br />
reentrant safe manner. In the past this was not true and led to a number<br />
of problems. In the future for C++ class development please use this<br />
approach to iterating through a collection. These changes are fully<br />
backwards compatible and no old APIs were harmed in the making of these<br />
changes. So in summary, for the future, where you would have written:<br />
<br />
for (actors->InitTraversal();<br />
(actor = actors->GetNextActor());)<br />
<br />
you would now have:<br />
<br />
vtkCollectionSimpleIterator actorIt;<br />
for (actors->InitTraversal(actorIt);<br />
(actor = actors->GetNextActor(actorIt));)<br />
<br />
=== Changes in VTK between 3.2 and 4.0 ===<br />
<br />
* Changes to vtkDataSetAttributes, vtkFieldData and vtkDataArray: All attributes (scalars, vectors...) are now stored in the field data as vtkDataArray's. vtkDataSetAttributes became a sub-class of vtkFieldData. For backwards compatibility, the interface which allows setting/getting the attributes the old way (by passing in a sub-class of vtkAttributeData such as vtkScalars) is still supported but it will be removed in the future. Therefore, the developers should use the new interface which requires passing in a vtkDataArray to set an attribute. vtkAttributeData and it's sub-classes (vtkScalars, vtkVectors...) will be deprectated in the near future; developers should use vtkDataArray and it's sub-classes instead. We are in the process of removing the use of these classes from vtk filters.<br />
<br />
* Subclasses of vtkAttributeData (vtkScalars, vtkVectors, vtkNormals, vtkTCoords, vtkTensors) were removed. As of VTK 4.0, vtkDataArray and it's sub-classes should be used to represent attributes and fields. Detailed description of the changes and utilities for upgrading from 3.2 to 4.0 can be found in the package: http://www.vtk.org/files/misc/Upgrading.zip<br />
<br />
* Added special methods to data arrays to replace methods like<br />
<br />
tc SetTCoord i x y 0<br />
<br />
or<br />
<br />
vc SetVector i vx vy vz<br />
<br />
in interpreted languages (Tcl, Python, Java). Use:<br />
<br />
tc SetTuple2 i x y<br />
<br />
or<br />
<br />
vc SetTuple3 i vx vy vz<br />
<br />
* Improved support for parallel visualization: vtkMultiProcessController and it's sub-classes have been re-structured and mostly re-written. The functionality of vtkMultiProcessController have been re-distributed between vtkMultiProcessController and vtkCommunicator. vtkCommunicator is responsible of sending/receiving messages whereas vtkMultiProcessController (and it's subclasses) is responsible of program flow/control (for example processing rmi's). New classes have been added to the Parallel directory. These include vtkCommunicator, vtkMPIGroup, vtkMPICommunicator, vtkSharedMemoryCommunicator, vtkMPIEventLog... There is now a tcl interpreter which supports parallel scripts. It is called pvtk and can be build on Windows and Unix. Examples for both Tcl and C++ can be found in the examples directories.<br />
<br />
* vtkSocketCommunicator and vtkSocketController have been added. These support message passing via BSD sockets. Best used together with input-output ports.<br />
<br />
* Since it was causing very long compile times (it essentially includes every vtk header file) and it was hard to maintain (you had to add a line whenever you added a class to VTK) vtk.h was removed. You will have to identify the header files needed by your application and include them one by one.<br />
<br />
* vtkIterativeClosestPointTransform has been added. This class is an implementation of the ICP algorithm. It matches two surfaces using the iterative closest point (ICP) algorithm. The core of the algorithm is to match each vertex in one surface with the closest surface point on the other, then apply the transformation that modify one surface to best match the other (in a least square sense).<br />
<br />
* The SetFileName, SaveImageAsPPM and related methods in vtkRenderWindow have been removed. vtkWindowToImageFilter combined with any of the image writers provides greater functionality.<br />
<br />
* Support for reading and writing PGM and JPEG images has been included.<br />
<br />
* Methods with parameters of the form "type param[n]" are wrapped. Previously, these methods were only wrapped if the array was declared 'const'. The python wrappers will allow values to be returned in the array.<br />
<br />
* The directory structure was completely reorganized. There are now subdirectories for Common (core common classes) Filtering (superclasses for filtering operations) Imaging (filters and sources that produce images or structured points) Graphics (filters or sources that produce data types other than ImageData and StructuredPoints) IO (file IO classes that do not require Rendering support) Rendering (all actors mappers annotation and rendering classes) Hybrid (typically filters and sources that require support from Rendering or both Imaging and Graphics) Parallel (parallel visualization support classes) Patented (patented classes) Examples (documented examples) Wrapping (support for the language wrappers). In many directories you will see a Testing subdirectory. The Testing subdirectories contain tests used to validate VTKs operation. Some tests may be useful as examples but they are not well documented.<br />
<br />
* The Build process for VTK now uses CMake (found at www.cmake.org) This replaces pcmaker on windows and configure on UNIX. This resolves some longstanding problems and limitation we were having with pcmaker and configure, and unifies the build process into one place.<br />
<br />
=== Changes to VTK between 4.0 and 4.2 ===<br />
<br />
* Use of macros to support serialization, standardize the New method, and provide the Superclass typedef.<br />
<br />
* Subclassing of VTK classes in the python wrappers (virtual method hooks are not provided).<br />
<br />
* vtkImageWindow, vtkImager, vtkTkImageWindowWidget and their subclasses have been removed to reduce duplicated code and enable interation in ImageWindows. Now people should use vtkRenderer and vtkRenderWindow instead. vtkImageViewer still works as a turn key image viewing class although it now uses vtkRenderWindow and vtkRenderer internally instead of vtkImageWindow and vtkImager.<br />
<br />
* New class: vtkBandedPolyDataContourFilter. Creates solid colored bands (like you find on maps) of scalar value.<br />
<br />
* Event processing: Several new events to VTK were added (see vtkCommand.h). Also event processing can now be prioritized and aborted. This allows applications to manage who processes which events, and terminates the processing of a particular event if desired.<br />
<br />
* 3D Widgets: A new class vtkInteractorObserver was added to observe events on vtkRenderWindowInteractor. Using the new event processing infrastructure, multiple 3D widgets (subclasses of vtkInteractorObserver) can be used simultaneously to process interactions. Several new 3D widgets have been added including:<br />
** vtkLineWidget<br />
** vtkPlaneWidget<br />
** vtkImagePlaneWidget<br />
** vtkBoxWidget<br />
** vtkSphereWidget<br />
<br />
* Besides providing a representation, widgets also provide auxiliary functionality such as providing transforms, implicit functions, plane normals, sphere radius and center, etc.<br />
<br />
* New class: vtkInstantiator provides a means by which one can create an instance of a VTK class using only the name of the class as a string.<br />
<br />
* New class: vtkXMLParser provides a wrapper around the Expat XML parsing library. A new parser can be written by subclassing from vtkXMLParser and providing a few simple virtual method implementations.<br />
<br />
* TIFF reader is now implemented using libtiff, which makes it capable of reading almost all available TIFF formats. The libtiff is also available internally as vtktiff.<br />
<br />
* New method (all sub-classes of vtkObject): Added a virtual function called NewInstance to vtkTypeMacro. NewInstance creates and returns an object of the same type as the current one. It does not copy any properties. The returned pointer is of the same type as the pointer the method was invoked with. This method should replace all the MakeObject methods scattered through VTK.<br />
<br />
* vtkSetObject macro is depricated for use inside the VTK. It is still a valid construct in projects that use VTK. Instead use vtkCxxSetObjectMacro which does the same thing.<br />
<br />
* vtkPLOT3DReader have been improved. It now supports:<br />
** multigrid (each block is one output)<br />
** ascii<br />
** fortran-style byte counts<br />
** little/big endian<br />
** i-blanking (partial)<br />
<br />
* A new vtkTextProperty class has been created, and duplicated text API s have been obsoleted accordingly. Check the<br />
[[VTK_FAQ#Text_properties_in_VTK_4.2|Text properties in VTK 4.2]] FAQ entry for a full description of the change.<br />
<br />
=== How do I upgrade my existing C++ code from 3.2 to 4.x? ===<br />
<br />
This is (a corrected version of) an email that was posted to vtkusers.<br />
Please feel free to correct or add anything.<br />
<br />
{| cellspacing="3" <br />
|- valign="top"<br />
|width="55%" bgcolor="#f0f0ff" style="border:1px solid #ffc9c9;padding:1em;padding-top:0.5em;"|<br />
<br />
I've just ported my medium-sized (40K lines) application from vtk3.2 to<br />
vtk4.x. I thought I would share my experiences with you, in case there<br />
were people out there contemplating it but a bit scared.<br />
<br />
One source of information for upgrading code is:<br />
<br />
http://www.vtk.org/files/misc/Upgrading.zip<br />
<br />
I'm using VC++6 + MFC on Win2K and was unable/unwilling to run the<br />
script in the zip file.<br />
<br />
So,<br />
<br />
I switched all my include directories to the new VTK ones and<br />
recompiled. 337 errors, not unexpectedly. Most concerned vtkScalars and<br />
vtkTCoords which have both been removed. Where I was using single value<br />
scalars, like this:<br />
<br />
vtkScalars *scalars = vtkScalars::New();<br />
scalars->SetNumberOfScalars(N_POINTS);<br />
...<br />
polydata->GetPointData()->SetScalars(scalars);<br />
...<br />
scalars->SetScalar(i,2.3);<br />
...<br />
<br />
I replaced with:<br />
<br />
vtkFloatArray *scalars = vtkFloatArray::New();<br />
scalars->SetNumberOfComponents(1);<br />
scalars->SetNumberOfTuples(N_POINTS);<br />
...<br />
polydata->GetPointData()->SetScalars(scalars);<br />
...<br />
scalars->SetTuple1(i,2.3);<br />
...<br />
<br />
OK so far, far fewer errors.<br />
<br />
Where I had 2D texture coordinates:<br />
<br />
vtkTCoords *tcoords = vtkTCoords::New();<br />
tcoords->SetNumberOfTCoords(N);<br />
...<br />
float p[3];<br />
p[0]=x; p[1]=y;<br />
tcoords->SetTCoord(i,p);<br />
...<br />
<br />
I replaced with:<br />
<br />
vtkFloatArray *tcoords = vtkFloatArray::New();<br />
tcoords->SetNumberOfComponents(2);<br />
tcoords->SetNumberOfTuples(N);<br />
...<br />
float p[2];<br />
p[0]=x; p[1]=y;<br />
tcoords->SetTuple(i,p);<br />
....<br />
<br />
All well and good, still fewer errors. Make sure you call<br />
SetNumberOfComponents *before* SetNumberOfTuples else you'll get<br />
problems (I did!).<br />
<br />
Where I was creating 0-255 image data and had been using:<br />
<br />
vtkScalars* scalars = vtkScalars::New();<br />
scalars->SetDataTypeToUnsignedChar();<br />
...<br />
<br />
I replaced with:<br />
<br />
vtkUnsignedCharArray *scalars = vtkUnsignedCharArray::New()<br />
...<br />
<br />
Going well!<br />
<br />
When creating RGB images, I had been using:<br />
<br />
vtkScalars *scalars = vtkScalars::New();<br />
scalars->SetDataTypeToUnsignedChar();<br />
scalars->SetNumberOfComponents(3);<br />
scalars->SetNumberOfScalars(X*Y);<br />
...<br />
scalars->SetActiveComponent(0);<br />
scalars->SetScalar(i,val1);<br />
scalars->SetActiveComponent(1);<br />
scalars->SetScalar(i,val2);<br />
scalars->SetActiveComponent(2);<br />
scalars->SetScalar(i,val3);<br />
...<br />
<br />
I replaced with:<br />
<br />
vtkUnsignedCharArray *scalars = vtkUnsignedCharArray::New()<br />
scalars->SetNumberOfComponents(3);<br />
scalars->SetNumberOfTuples(X*Y);<br />
...<br />
scalars->SetComponent(i,0,val1);<br />
scalars->SetComponent(i,1,val2);<br />
scalars->SetComponent(i,2,val3);<br />
...<br />
<br />
My remaining errors concerned vtkWin32OffscreenRenderWindow that has<br />
been removed. Where I had been using:<br />
<br />
vtkWin32OffscreenRenderWindow *offscreen = vtkWin32OffscreenRenderWindow::New();<br />
...<br />
<br />
I replaced with:<br />
<br />
vtkWin32OpenGLRenderWindow *offscreen = vtkWin32OpenGLRenderWindow::New();<br />
offscreen->SetOffScreenRendering(1);<br />
...<br />
<br />
All done. I'd had to throw in some #include "vtkFloatArray.h" and things<br />
like that of course. Zero compile errors.<br />
<br />
Had to remember to link against the new vtk lib files, so I removed<br />
<br />
vtkdll.lib <br />
<br />
and added<br />
<br />
vtkCommon.lib<br />
vtkGraphics.lib<br />
<br />
etc.<br />
<br />
Zero link errors. My program is up and running again, no apparant<br />
problems. Plus now I can use all the new features of vtk4. (And I'm sure<br />
it's faster but maybe that's my imagination.)<br />
<br />
All this took me about three hours.<br />
<br />
Bye!<br />
<br />
Tim.<br />
|}<br />
<br />
=== What is the release schedule for VTK ===<br />
<br />
VTK has a formal release every eight to sixteen months. VTK 4.0 was cut in December 2001 and released in March 2002. VTK 4.2 was releaseed in February 2003. VTK 4.4 (which was an interim release) was released at the end of 2003. VTK 5.0 was released in January 2006, 5.0.1 in July 2006, 5.0.2 in September 2006, 5.0.3 in March 2007, and 5.0.4 in January 2008.<br />
<br />
=== Roadmap: What changes are being considered for VTK ===<br />
<br />
This is a list of changes that are being considered for inclusion into<br />
VTK. Some of these changes will happen while other changes we would like<br />
to see happen but may not due to funding or time issues. For each change<br />
we try to list what the change is, when we hope to complete it, if it is<br />
actively being developed. Detailed discussion on changes is limited to<br />
the vtk-developers mailing list.<br />
<br />
# Modify existing image filters to use the new vtkImageIterator etc. Most simple filters have been modified to use ithe iterator in VTK 4.2. It would be nice to have some sort of efficient neighborhood iterators but so far we haven't come up with any.<br />
# Rework the polydata and unstructured grid structures (vtkMesh ??). Related ideas include:<br />
#* Make UnstructuredGrid more compact by removing the cell point count from the vtkCellArray. This will reduce the storage required by each cell by 4 bytes.<br />
#* Make vtkPolyData an empty subclass of vtkUnstructuredGrid. There are a number of good reasons for this but it is a tricky task and backwards compatibility needs to be maintained.<br />
# More parallel support, including parallel compositing algorithms<br />
# Algorithms like LIC (http://www-courses.cs.uiuc.edu/~cs419/lic.pdf), maybe a couple terrain-decimation algorithms<br />
# Further integration of STL and other important C++ constructs (like templates)<br />
<br />
VTK 4.4 (intermediate release, end of 2003)<br />
<br />
* convert APIs to double (done)<br />
* remove old callbacks (done)<br />
* blanking<br />
* ref count observers (done)<br />
* switch collections to use iterators (done)<br />
* improve copyright (done)<br />
<br />
VTK 5.0 (major release, early 2005)<br />
<br />
* new pipeline mechanism (see [[Media:Pipeline.pdf|Pipeline.pdf]])<br />
* time support<br />
* true AMR support<br />
<br />
=== Changes to Interactors ===<br />
<br />
The Interactors have been updated to use the Command/Observer events of<br />
vtk. The vtkRenderWindowInteractor now has ivars for all the event<br />
information. There is a new class called<br />
vtkGenericRenderWindowInteractor that can be used to set up the bindings<br />
from other languages like python, Java or TCl.<br />
<br />
A new class vtkInteractorObserver was also added. It has a<br />
SetInteractor() method. It observes the keypress and delete events<br />
invoked by the render window interactor. The keypress activation value<br />
for a widget is now 'i' (although this can be programmed).<br />
vtkInteractorObserver has the state ivar Enabled. All subclasses must<br />
have the SetEnabled(int) method. Convenience methods like On(), Off(),<br />
EnabledOn(), and EnabledOff() are available. The state of the interactor<br />
observer is obtained using GetEnabled(). The SetEnabled(1) method adds<br />
observers to watch the interactor (appropriate to the particular<br />
interactor observer) ; SetEnabled(0) removes the observers . There are<br />
two new events: EnableEvent and DisableEvent which are invoked by the<br />
SetEnabled() method.<br />
<br />
The events also support the idea of priority now. When you add an<br />
observer, you can specify a priority from 0 to 1. Higher values will be<br />
called back first. An observer can also tell the object not to call any<br />
more observers. This way you can handle an event, and stop further<br />
processing. In this way you can add handlers to InteractorStyles without<br />
sub-classing and from wrapped languages.<br />
<br />
For more information see: vtkGenericRenderWindowInteractor,<br />
vtkRenderWindowInteractor, vtkInteractorObserver.<br />
<br />
=== Header files and vtkSetObjectMacro ===<br />
<br />
On some platforms such as MS Visual Studio .NET, compiler is not capable<br />
of handling too big input files. Some VTK files with all includes do<br />
become big enough to overwhelm the compiler. The solution is to minimize<br />
the amount of includes. This especially goes for header files, because<br />
they propagate to other files. Every class header file should include<br />
only the parent class header file. If there is no other alternative, you<br />
should put a comment next to include file explaining why the file has to<br />
be included.<br />
<br />
The related issue is with vtkSetObjectMacro. This file calles some<br />
methods on an argument class, which implies that the argument class<br />
header file has to be included. The result is bloat on the header files.<br />
The solution is to not use vtkSetObjectMacro but vtkCxxSetObjectMacro.<br />
The difference is that vtkCxxSetObjectMacro goes in the Cxx file and not<br />
in the header file.<br />
<br />
Example: Instead of<br />
<br />
#include "vtkBar.h"<br />
class vtkFoo : public vtkObject<br />
{ ...<br />
vtkSetObjectMacro(Bar, vtkBar);<br />
...<br />
};<br />
<br />
Do:<br />
<br />
class vtkBar;<br />
class vtkFoo : public vtkObject<br />
{<br />
...<br />
virtual void SetBar(vtkBar*);<br />
...<br />
};<br />
<br />
and add the following line to vtkFoo.cxx<br />
<br />
vtkCxxSetObjectMacro(vtkFoo,Bar,vtkBar);<br />
<br />
=== Text properties in VTK 4.2 ===<br />
<br />
A new<br />
[http://public.kitware.com/VTK/doc/nightly/html/classvtkTextProperty.html vtkTextProperty]<br />
class has been added to VTK 4.2.<br />
<br />
This class factorizes text attributes that used to be spread out and<br />
duplicated in many different classes (mostly 2D actors and text<br />
mappers). Among those attributes, font family, font size,<br />
bold/italic/shadow properties, horizontal and vertical justification,<br />
line spacing and offset have been retained, whereas new attributes like<br />
color and opacity have been introduced.<br />
<br />
We tried to make sure that you can use a vtkTextProperty to modify text<br />
properties in the same way a vtkProperty can be used to modify the<br />
surface properties of a geometric object. In that regard, you should be<br />
able to share a vtkTextProperty between different actors or assign the<br />
same vtkTextProperty to an actor that offers multiple vtkTextProperty<br />
attributes ([http://www.vtk.org/doc/nightly/html/classvtkXYPlotActor.html vtkXYPlot]<br />
for example).<br />
<br />
Here is a quick example:<br />
<br />
vtkTextActor *actor0 = vtkTextActor::New();<br />
actor0->GetTextProperty()->SetItalic(1);<br />
//<br />
vtkTextProperty *tprop = vtkTextProperty::New();<br />
tprop->SetBold(1);<br />
//<br />
vtkTextActor *actor1 = vtkTextActor::New();<br />
actor1->SetTextProperty(tprop);<br />
//<br />
vtkTextActor *actor2 = vtkTextActor::New();<br />
actor2->SetTextProperty(tprop);<br />
<br />
*Backward compatibility issues*:<br />
<br />
1) Color and Opacity:<br />
<br />
The text color and text opacity settings are now controlled by the<br />
vtkTextProperty Color and Opacity attributes instead of the<br />
corresponding actor's color and opacity attributes. In the following<br />
example, those settings were controlled by the attributes of the<br />
vtkProperty2D attached to the vtkActor2D (vtkTextActor). The<br />
vtkTextProperty attributes should be used instead:<br />
<br />
vtkTextActor *actor = vtkActor::New();<br />
actor->GetProperty()->SetColor(...);<br />
actor->GetProperty()->SetOpacity(...);<br />
<br />
becomes:<br />
<br />
actor->GetTextProperty()->SetColor(...);<br />
actor->GetTextProperty()->SetOpacity(...);<br />
<br />
To make migration easier for a while, we have set the vtkTextProperty<br />
default color to ''(-1.0, -1.0, -1.0)'' and the default opacity to ''-1.0''.<br />
These "magic" values are checked by the underlying text mappers at<br />
rendering time. If they are found, the color and opacity of the 2D<br />
actor's vtkProperty2D are used, just as it was in VTK 4.1.<br />
<br />
2) API (i.e. SetBold(), SetItalic(), etc)<br />
<br />
Most of the VTK classes involving text used to provide their own text<br />
attributes like Bold, Italic, Shadow, FontFamily. Thus, each of those<br />
classes would duplicate the vtkTextMapper API through methods like<br />
SetItalic(), SetBold(), SetFontFamily(), etc.<br />
<br />
Moreover, if one class had different text elements (say, for example,<br />
the title and the labels of a scalar bar), there was no way to modify<br />
the text properties of these elements separately.<br />
<br />
The vtkTextProperty class has been created to address both issues, by<br />
obsoleting those duplicated attributes and methods and providing a<br />
unified way to access text properties, and by allowing each class to<br />
associate different vtkTextProperty to different text elements.<br />
<br />
Migrating your code basically involves using the old API on your actor's<br />
vtkTextProperty instead of the actor itself. For example:<br />
<br />
actor->SetBold(1);<br />
<br />
becomes:<br />
<br />
actor->GetTextProperty()->SetBold(1);<br />
<br />
When a class provides different vtkTextProperty for different text<br />
elements, the TextProperty attribute is usually prefixed with that<br />
element type. Example: AxisTitleTextProperty, or AxisLabelTextProperty.<br />
This allows you to set different aspect for each text elements. If you<br />
want to use the same properties, you can either set the same values on<br />
each vtkTextProperty, or make both vtkTextProperty point to the same<br />
vtkTextProperty object. Example:<br />
<br />
actor->GetAxisLabelTextProperty()->SetBold(1);<br />
actor->GetAxisTitleTextProperty()->SetBold(1);<br />
<br />
or:<br />
<br />
vtkTextProperty *tprop = vtkTextProperty::New();<br />
tprop->SetBold(1);<br />
actor->SetAxisLabelTextProperty(tprop);<br />
actor->SetAxisTitleTextProperty(tprop);<br />
<br />
or:<br />
<br />
actor->SetAxisLabelTextProperty(actor->GetAxisTitleTextProperty());<br />
actor->GetAxisTitleTextProperty()->SetBold(1);<br />
<br />
The following list specifies the name of the text properties used in the<br />
VTK classes involving text.<br />
<br />
[http://www.vtk.org/doc/nightly/html/classvtkTextMapper.html vtkTextMapper]:<br />
* you can still use the vtkTextMapper + vtkActor2D combination, but we would advise you to use a single vtkTextActor instead, this will give you maximum flexibility.<br />
* has 1 text prop: TextProperty, but although you have access to it, do not twwak it unless you are using vtkTextMapper with a vtkActor2D. In all other cases, use the text prop provided by the actor (see below).<br />
<br />
[http://www.vtk.org/doc/nightly/html/classvtkTextActor.html vtkTextActor]:<br />
* has 1 text prop: TextProperty. <br />
<br />
[http://www.vtk.org/doc/nightly/html/classvtkLabeledDataMapper.html vtkLabeledDataMapper]:<br />
* has 1 text prop: LabelTextProperty. <br />
<br />
[http://www.vtk.org/doc/nightly/html/classvtkCaptionActor2D.html vtkCaptionActor2D]:<br />
* has 1 text prop: CaptionTextProperty. <br />
<br />
[http://www.vtk.org/doc/nightly/html/classvtkLegendBoxActor.html vtkLegendBoxActor]:<br />
* has 1 text prop: EntryTextProperty.<br />
<br />
[http://www.vtk.org/doc/nightly/html/classvtkAxisActor2D.html vtkAxisActor2D],<br />
[http://www.vtk.org/doc/nightly/html/classvtkParallelCoordinatesActor.html vtkParallelCoordinatesActor], and<br />
[http://www.vtk.org/doc/nightly/html/classvtkScalarBarActor.html vtkScalarBarActor]:<br />
* have 2 text props: TitleTextProperty, LabelTextProperty.<br />
<br />
[http://www.vtk.org/doc/nightly/html/classvtkXYPlotActor.html vtkXYPlotActor]:<br />
* has 3 text prop: TitleTextProperty (plot title), AxisTitleTextProperty, AxisLabelTextProperty (title and labels of all axes)<br />
* the legend box text prop (i.e. entry text prop) can be retrieved through actor->GetLegendBoxActor()->GetEntryTextProperty()<br />
* the X (or Y) axis text props (i.e. title and label text props) can be retrieved through actor->GetX/YAxisActor2D->GetTitle/LabelTextProperty(), and will override the corresponding AxisTitleTextProperty or AxisLabelTextProperty props as long as they remain untouched. <br />
<br />
[http://www.vtk.org/doc/nightly/html/classvtkCubeAxesActor2D.html vtkCubeAxesActor2D]:<br />
* has 2 text props: AxisTitleTextProperty, AxisLabelTextProperty (title and label of all axes)<br />
* the X (Y or Z) axis text props (i.e. title and label text props) can be retrieved through actor->GetX/Y/ZAxisActor2D->GetTitle/LabelTextProperty(), and will override the corresponding AxisTitleTextProperty or AxisLabelTextProperty props as long as they remain untouched.<br />
<br />
=== Forward declaration in VTK 4.x ===<br />
<br />
Since VTK 4.x all classes have been carefully inspected to only include the necessesary headers, and do what is called 'forward declaration' for all other needed classes. Thus, when you compile your projects using a filter that takes as input a dataset and you are passing an imagedata: you need to explicitely include imagedata within your implementation file. This is true for all data types.<br />
<br />
For example, if you get this error:<br />
<br />
no matching function for call to `vtkContourFilter::SetInput(vtkImageData*)'<br />
VTK/Filtering/vtkDataSetToPolyDataFilter.h:44:<br />
candidates are: virtual void vtkDataSetToPolyDataFilter::SetInput(vtkDataSet*)<br />
<br />
This means you need to add in your code : #include "vtkImageData.h"<br />
<br />
=== Using Volume Rendering in VTK ===<br />
<br />
I recently updated my VTK CVS version. And my c++ code that use to work fine are now complaining about:<br />
<br />
undefined reference to `vtkUnstructuredGridAlgorithm::SetInput(vtkDataObject*)'<br />
undefined reference to `vtkUnstructuredGridAlgorithm::GetOutput()' <br />
<br />
There is now a new subfolder and a new option to enable building the VolumeRendering library. You have to turn VTK_USE_VOLUMERENDERING to ON in order to use it. Also make sure that your executable is linking properly to this new library:<br />
<br />
ADD_EXECUTABLE(foo foo.cxx)<br />
TARGET_LINK_LIBRARIES(foo vtkVolumeRendering)<br />
<br />
=== API Changes in VTK 5.2 ===<br />
<br />
==== <tt>vtkProp::RenderTranslucentGeometry()</tt> is gone ====<br />
<br />
<tt>vtkProp::RenderTranslucentGeometry()</tt> is gone and has been broken down into 3 methods:<br />
* <tt>HasTranslucentPolygonalGeometry()</tt><br />
* <tt>RenderTranslucentPolygonalGeometry()</tt><br />
* <tt>RenderVolumetricGeometry()</tt><br />
<br />
Here is what to change in a vtkProp subclass:<br />
* If <tt>RenderTranslucentGeometry()</tt> was used to render translucent polygonal geometry only, override <tt>HasTranslucentPolygonalGeometry()</tt> and <tt>RenderTranslucentPolygonalGeometry()</tt>. <b>Just renaming <tt>RenderTranslucentGeometry()</tt> as <tt>RenderTranslucentPolygonalGeometry()</tt> is not enough!</b><br />
* If <tt>RenderTranslucentGeometry()</tt> was used to render translucent volumetric geometry only, override <tt>RenderVolumetricGeometry()</tt>. In this case, just renaming <tt>RenderTranslucentGeometry()</tt> as <tt>RenderVolumetricGeometry()</tt> is OK.<br />
* If <tt>RenderTranslucentGeometry()</tt> was used to render translucent polygonal geometry and translucent volumetric geometry, override all 3 methods.<br />
<br />
The reason of this change is that <tt>HasTranslucentPolygonalGeometry()</tt> is used to decide if an expensive initialization of the new rendering algorithm of translucent polygonal geometry (depth peeling) is necessary. <tt>RenderTranslucentPolygonalGeometry()</tt> is called multiple times during the rendering of the translucent polygonal geometry of the scene. <tt>RenderVolumetricGeometry()</tt> is called in an additional pass, after depth peeling. For this reason, <b><tt>RenderTranslucentGeometry()</tt> cannot just be marked as deprecated but had to be removed from the API</b>.<br />
<br />
<br />
<br />
==== <tt>vtkImagePlaneWidget</tt> has action names changed ====<br />
from:<br />
enum<br />
{<br />
CURSOR_ACTION = 0,<br />
SLICE_MOTION_ACTION = 1,<br />
WINDOW_LEVEL_ACTION = 2<br />
};<br />
to:<br />
enum<br />
{<br />
VTK_CURSOR_ACTION = 0,<br />
VTK_SLICE_MOTION_ACTION = 1,<br />
VTK_WINDOW_LEVEL_ACTION = 2<br />
};<br />
<br />
==== <tt>GetOutput()</tt> now returns <tt>vtkDataObject</tt> for some algorithms ====<br />
<br />
The following algorithms now work on <tt>vtkGraph</tt> as well as <tt>vtkDataSet</tt>, so no <tt>GetOutput()</tt> longer returns <tt>vtkDataSet</tt>. To obtain the dataset, use <tt>vtkDataSet::SafeDownCast(filter->GetOutput())</tt><br />
* <tt>vtkArrayCalculator</tt><br />
* <tt>vtkAssignAttribute</tt><br />
* <tt>vtkProgrammableFilter</tt><br />
<br />
=== API Changes in VTK 5.4 ===<br />
* empty right now.<br />
=== API Changes in VTK 5.5 ===<br />
<br />
* vtkStreamTracer<br />
Changed<br />
enum Units <br />
{ <br />
TIME_UNIT, <br />
LENGTH_UNIT, <br />
CELL_LENGTH_UNIT <br />
}<br />
to<br />
enum Units<br />
{ <br />
LENGTH_UNIT = 1, <br />
CELL_LENGTH_UNIT = 2 <br />
}<br />
<br />
<br />
Changed<br />
* OUT_OF_TIME = 4<br />
to<br />
* OUT_OF_LENGTH = 4<br />
in enum ''ReasonForTermination''<br />
<br />
<br />
Changed<br />
* LastUsedTimeStep<br />
to<br />
* LastUsedStepSize<br />
<br />
<br />
Changed<br />
* MaximumPropagation<br />
* MaximumIntegrationStep<br />
* MinimumIntegrationStep<br />
* InitialIntegrationStep <br />
from type ''IntervalInformation'' to type ''double''.<br />
<br />
<br />
Added a member variable to the class<br />
* int IntegrationStepUnit<br />
<br />
<br />
The following APIs were '''removed''' from the class:<br />
* void SetMaximumProgration(int unit, double max)<br />
* void SetMaximumProgrationUnit(int unit)<br />
* int GetMaximumPropagationUnit()<br />
* void SetMaximumPropagationUnitToTimeUnit()<br />
* void SetMaximumPropagationUnitToLengthUnit()<br />
* void SetMaximumPropagationUnitToCellLengthUnit()<br />
* void SetMinimumIntegrationStep(int unit, double step)<br />
* void SetMinimumIntegrationStepUnit(int unit)<br />
* int GetMinimumIntegrationStepUnit()<br />
* void SetMinimumIntegrationStepUnitToTimeUnit()<br />
* void SetMinimumIntegrationStepUnitToLengthUnit()<br />
* void SetMinimumIntegrationStepUnitToCellLengthUnit()<br />
* void SetMaximumIntegrationStep(int unit, double step)<br />
* void SetMaximumIntegrationStepUnit(int unit)<br />
* int GetMaximumIntegrationStepUnit()<br />
* void SetMaximumIntegrationStepUnitToTimeUnit()<br />
* void SetMaximumIntegrationStepUnitToLengthUnit()<br />
* void SetMaximumIntegrationStepUnitToCellLengthUnit()<br />
* void SetInitialIntegrationStep(int unit, double step)<br />
* void SetInitialIntegrationStepUnit(int unit)<br />
* int GetInitialIntegrationStepUnit()<br />
* void SetInitialIntegrationStepUnitToTimeUnit()<br />
* void SetInitialIntegrationStepUnitToLengthUnit()<br />
* void SetInitialIntegrationStepUnitToCellLengthUnit()<br />
* void SetIntervalInformation(int unit, double interval, IntervalInformation& currentValues)<br />
* void SetIntervalInformation(int unit,IntervalInformation& currentValues)<br />
* void ConvertIntervals(double& step, double& minStep, double& maxStep, int direction, double cellLength, double speed)<br />
* static double ConvertToTime(IntervalInformation& interval, double cellLength, double speed)<br />
* static double ConvertToLength(IntervalInformation& interval, double cellLength, double speed)<br />
* static double ConvertToCellLength(IntervalInformation& interval, double cellLength, double speed)<br />
* static double ConvertToUnit(IntervalInformation& interval, int unit, double cellLength, double speed)<br />
<br />
<br />
The following APIs were added to the class:<br />
* int GetIntegrationStepUnit()<br />
* void SetIntegrationStepUnit(int unit)<br />
* void ConvertIntervals(double& step, double& minStep, double& maxStep, int direction, double cellLength)<br />
* static double ConvertToLength(double interval, int unit, double cellLength)<br />
* static double ConvertToLength(IntervalInformation& interval, double cellLength)<br />
<br />
<br />
* vtkInterpolatedVelocityField<br />
Added a new member variable and two associated functions:<br />
* bool NormalizeVector<br />
* vtkSetMacro(NormalizeVector, bool)<br />
* vtkGetMacro(NormalizeVector, bool)<br />
<br />
== OpenGL requirements ==<br />
<br />
=== Terminology ===<br />
<br />
* a software component using OpenGL (like VTK) <b>requires</b> some minimal version of OpenGL and some minimal set of OpenGL extensions at runtime. At compile time, it <b>requires</b> an OpenGL header file (<tt>gl.h</tt>) compatible with some minimal version of the OpenGL API.<br />
* an OpenGL implementation (software (like Mesa) or hardware (combination of a graphic card and its driver) ) <b>supports</b> some OpenGL versions and a set of extensions.<br />
<br />
=== How do I check which OpenGL versions or extensions are supported by my graphic card or OpenGL implementation? ===<br />
<br />
==== Linux/Unix ====<br />
<br />
Two ways:<br />
<br />
* General method<br />
<pre><br />
$ glxinfo<br />
</pre><br />
<br />
* vendor specific tool<br />
<br />
if you have an nVidia card and nvidia-settings installed on it, run it and go to the OpenGL/GLX Information item under the X Screen 0 item.<br />
<br />
==== Windows ====<br />
<br />
You can download and use GLview http://www.realtech-vr.com/glview<br />
<br />
==== Mac OS X ====<br />
<br />
With Xcode installed, Macintosh HD->Developer->Applications->Graphic Tools->OpenGL Driver Monitor.app->Monitors->Renderer Info-><name of the OpenGL driver>->OpenGL Extensions<br />
<br />
=== VTK 5.0 ===<br />
<br />
==== What is the minimal OpenGL version of the API required to compile VTK5.0? ====<br />
<br />
The <tt>gl.h</tt> file provided by your compiler/system/SDK has to define at least the OpenGL 1.1 API.<br />
<br />
(Note: the functions and macros defined in higher OpenGL API versions or in other OpenGL extensions are provided by <tt>glext.h</tt>, <tt>glxext.h</tt> and <tt>wglext.h</tt>. Those 3 files are official files taken from http://opengl.org/registry/ and already part of the VTK source tree).<br />
<br />
==== What is the minimal OpenGL version required by VTK5.0 at runtime? ====<br />
<br />
All the VTK classes using OpenGL require an OpenGL implementation (software or hardware) >=1.1 except for <tt>vtkVolumeTextureMapper3D</tt>.<br />
<br />
If you want to use <tt>vtkVolumeTextureMapper3D</tt>, the following extensions or OpenGL versions are required (at runtime):<br />
* extension <tt>GL_EXT_texture3D</tt> or OpenGL>=1.2<br />
and<br />
* extension <tt>GL_ARB_multitexture</tt> or OpenGL>=1.3<br />
and either:<br />
* extensions <tt>GL_ARB_fragment_program</tt> and <tt>GL_ARB_vertex_program</tt><br />
or:<br />
* extensions <tt>GL_NV_texture_shader2</tt> and <tt>GL_NV_register_combiners</tt> and <tt>GL_NV_register_combiners2</tt><br />
<br />
=== VTK 5.2 ===<br />
<br />
==== What is the minimal OpenGL version of the API required to compile VTK5.2? ====<br />
<br />
Same answer than for VTK 5.0.<br />
<br />
==== What is the minimal OpenGL version required by VTK5.2 at runtime? ====<br />
<br />
All the VTK classes using OpenGL require an OpenGL implementation (software or hardware) >=1.1 except for <tt>vtkVolumeTextureMapper3D</tt>, <tt>vtkHAVSVolumeMapper</tt>,<br />
<tt>vtkGLSLShaderProgram</tt>, depth peeling and some hardware offscreen rendering using framebuffer objects (FBO).<br />
<br />
If you want to use <tt>vtkVolumeTextureMapper3D</tt>, the following extensions or OpenGL versions are required (at runtime):<br />
* extension <tt>GL_EXT_texture3D</tt> or OpenGL>=1.2<br />
and<br />
* extension <tt>GL_ARB_multitexture</tt> or OpenGL>=1.3<br />
and either:<br />
* extensions <tt>GL_ARB_fragment_program</tt> and <tt>GL_ARB_vertex_program</tt><br />
or:<br />
* extensions <tt>GL_NV_texture_shader2</tt> and <tt>GL_NV_register_combiners</tt> and <tt>GL_NV_register_combiners2</tt><br />
<br />
If you want to use <tt>vtkHAVSVolumeMapper</tt>, the following extensions or OpenGL versions are required (at runtime):<br />
* OpenGL>=1.3<br />
* <tt>GL_ARB_draw_buffers</tt> or OpenGL>=2.0<br />
* <tt>GL_ARB_fragment_program</tt><br />
* <tt>GL_ARB_vertex_program</tt><br />
* <tt>GL_EXT_framebuffer_object</tt><br />
* either <tt>GL_ARB_texture_float</tt> or <tt>GL_ATI_texture_float</tt><br />
<br />
The following extension or OpenGL version is used by <tt>vtkHAVSVolumeMapper</tt> if provided (at runtime), but it is optional:<br />
* <tt>GL_ARB_vertex_buffer_object</tt> or OpenGL>=1.5<br />
<br />
If you want to use <tt>vtkGLSLShaderProgram</tt>, the following extensions or OpenGL versions are required (at runtime):<br />
* OpenGL>=1.3<br />
* <tt>GL_ARB_shading_language_100</tt> or OpenGL>=2.0,<br />
* <tt>GL_ARB_shader_objects</tt> or OpenGL>=2.0<br />
* <tt>GL_ARB_vertex_shader</tt> or OpenGL>=2.0<br />
* <tt>GL_ARB_fragment_shader</tt> or OpenGL>=2.0.<br />
<br />
Depth peeling ( see [[VTK/Depth_Peeling | VTK Depth Peeling]] for more information) requires (at runtime):<br />
* <tt>GL_ARB_depth_texture</tt> or OpenGL>=1.4<br />
* <tt>GL_ARB_shadow</tt> or OpenGL>=1.4<br />
* <tt>GL_EXT_shadow_funcs</tt> or OpenGL>=1.5<br />
* <tt>GL_ARB_vertex_shader</tt> or OpenGL>=2.0<br />
* <tt>GL_ARB_fragment_shader</tt> or OpenGL>=2.0<br />
* <tt>GL_ARB_shader_objects</tt> or OpenGL>=2.0<br />
* <tt>GL_ARB_occlusion_query</tt> or OpenGL>=1.5<br />
* <tt>GL_ARB_multitexture</tt> or OpenGL>=1.3<br />
* <tt>GL_ARB_texture_rectangle</tt><br />
* <tt>GL_SGIS_texture_edge_clamp</tt> or <tt>GL_EXT_texture_edge_clamp</tt> or OpenGL>=1.2<br />
<br />
Hardware-based offscreen rendering using framebuffer object (FBO) will be used as the default offscreen method if the following extensions or OpenGL version are available (at runtime):<br />
* <tt>GL_EXT_framebuffer_object</tt><br />
and either <br />
* <tt>GL_ARB_texture_non_power_of_two</tt> or OpenGL>=2.0<br />
or<br />
* <tt>GL_ARB_texture_rectangle</tt><br />
In addition, if the the framebuffer needs a stencil buffer, extension <tt>GL_EXT_packed_depth_stencil</tt> is required. Even if all those extensions are supported, the chosen FBO format might<br />
not be supported by the card; in this case, this method of offscreen rendering is not used.<br />
<br />
== Miscellaneous questions ==<br />
<br />
=== Can't you split up the data file? ===<br />
<br />
The data is now in one file that is about 15 Megabytes. This is smaller<br />
than the original data files VTK used and we hope that this size is not<br />
a problem for people anymore. If it is please let us know.<br />
<br />
=== Do you have any shared library tips? ===<br />
<br />
VTK version 4.0 and later supports both shared and static libraries on<br />
most all platforms. For development we typically use shared libraries<br />
since they are faster to link when making small changes. You can control<br />
how VTK builds by setting the BUILD_SHARED_LIBS option in CMake.<br />
<br />
== Legal issues ==<br />
<br />
=== Is VTK FDA-Approved ? ===<br />
<br />
Given the fact that VTK is a software toolkit, it cannot be the<br />
subject of FDA approval as a medical device. We have discussed<br />
this topic in several occasions and received advice from FDA<br />
representatives, that can be summarized as follow:<br />
<br />
<br />
VTK is to be considered as an off-the-shelf (OTS) product that<br />
is used for supporting a higher level medical application/product.<br />
The developer of such application/product will be responsible for<br />
performing the validation processes described in FDA published<br />
guidelines for the development of software-related medical devices.<br />
<br />
For mode details see the page [[FDA Guidelines for Software Development]]<br />
<br />
=== What are the legal issues? ===<br />
<br />
The Visualization Toolkit software is provided under the following<br />
copyright. We think it's pretty reasonable. We do restrict the<br />
distribution of modified code. This is primarily a revision control<br />
issue. We don't want a bunch of renegade vtks running around without us<br />
having some idea why the changes were made and giving us a chance to<br />
incorporate them into the general release.<br />
<br />
The text of the VTK copyright is available [http://www.vtk.org/copyright.php here].<br />
<br />
=== What is the deal with the patents ===<br />
<br />
As the copyright mentions there are some patents used in VTK. If you use<br />
any code in the Patented/ directory for commercial application you<br />
should contact the patent holder and obtain a license.<br />
<br />
As of VTK4.0 the following classes are known to use algorithms patented<br />
by General Electric Company: vtkDecimate, vtkMarchingCubes,<br />
vtkMarchingSquares, vtkDividingCubes, vtkSliceCubes and vtkSweptSurface.<br />
The GE contact is:<br />
<br />
Carl B. Horton<br />
Sr. Counsel, Intellectual Property<br />
3000 N. Grandview Blvd., W-710<br />
Waukesha, WI 53188<br />
Phone: (262) 513-4022<br />
E-Mail: mailto:Carl.Horton@med.ge.com<br />
<br />
As of VTK4.0 the following classes are known to use algorithms patented<br />
by Kitware, Inc.: vtkGridSynchronizedTemplates3D,<br />
vtkKitwareContourFilter.h, vtkSynchronizedTemplates2D, and<br />
vtkSynchronizedTemplates3D. The Kitware contact is:<br />
<br />
Ken Martin<br />
Kitware<br />
28 Corporate Drive, Suite 204,<br />
Clifton Park, NY 12065<br />
Phone:1-518-371-3971<br />
E-Mail: mailto:kitware@kitware.com<br />
<br />
=== Can VTK be used as part of a project distributed under a GPL License ? ===<br />
<br />
==== Short Answer ====<br />
<br />
Yes, it is fine to take VTK code and to include it in a project that is distributed under a GPL license.<br />
<br />
==== Long Answer ====<br />
<br />
===== Terms =====<br />
<br />
Let's call project X the larger project that:<br />
<br />
# Will include source code from VTK (in part or as a whole)<br />
# Will be distributed under GPL license<br />
<br />
Note in particular that:<br />
<br />
# The copyright notices in VTK files must be kept.<br />
# If VTK files are modified by the developers of project X, that fact must be clearly indicated.<br />
# Only the modifications of VTK files made by the developers of project X will be covered by a GPL license. The original VTK code remains covered by the VTK license.<br />
# The collection of copyrighted works (project X in this case), that includes VTK (in part or as a whole) and their software will be covered by a GPL license.<br />
<br />
===== Details =====<br />
<br />
As the [http://www.vtk.org/copyright.php VTK license] is a variation of the [http://www.opensource.org/licenses/bsd-license.php Modified BSD license], to which only the following term has been added:<br />
<br />
Modified source versions must be plainly marked as such, <br />
and must not be misrepresented as being the original software.<br />
<br />
and that the Modified BSD license is itself compatible with the GPL <br />
<br />
http://www.gnu.org/philosophy/license-list.html (Modified BSD license)<br />
<br />
Then the VTK license is also compatible with the GPL license. Since the terms of the GPL license do not preclude the additional term of the VTK license from being followed.<br />
<br />
NOTE: The licenses are only '''one way compatible'''.<br />
<br />
* You can use VTK code inside a GPL licensed project.<br />
* You '''can not''' use GPL licensed code inside VTK.<br />
<br />
That is the reason why there are no GPL third party libraries in VTK. Having GPL third party libraries in VTK would prevent closed source projects from being built against VTK.<br />
<br />
== Common problems and their solutions ==<br />
* There are some problems may that arise while building VTK that have very straight forward solutions. [[VTK/BuildingProblems|Here]] they are.<br />
* There are some problems that arise frequently that have very straight forward solutions. [[VTK/CommonProblems|Here]] they are.<br />
<br />
{{VTK/Template/Footer}}</div>Mathieuhttps://public.kitware.com/Wiki/index.php?title=VTK/Remove_VTK_4_Compatibility&diff=43605VTK/Remove VTK 4 Compatibility2011-10-04T13:54:37Z<p>Mathieu: /* Remove the RequestDataObject pass */</p>
<hr />
<div>== Summary ==<br />
One of the main goals of the pipeline re-architecture between VTK 4 and 5 was to move the execution logic from data and process objects to a new set of classes called executives. However, we made certain compromises in order to maintain backwards compatibility with algorithms developed for VTK 4. The most important and damaging of these was keeping the data object as a conduit of meta-data during pipeline passes. <br />
<br />
In the old pipeline, algorithms produced meta-data and requests by setting the on the output/input. Something like:<br />
<br />
<source lang="cpp"><br />
void ExecuteInformation()<br />
{<br />
this->GetOutput()->SetWholeExtent(...);<br />
}<br />
</source><br />
<br />
In VTK 5, the right way of doing this is<br />
<br />
<source lang="cpp"><br />
int RequestInformation(vtkInformation*, vtkInformationVector**, vtkInformationVector* outputVector)<br />
{<br />
outputVector->GetInformationObject(0)->Set(WHOLE_EXTENT(), ...);<br />
}<br />
</source><br />
<br />
However, the old version still works thanks to the compatibility layer. The code to maintain the backwards compatibility leads to several major problems:<br />
<br />
# Maintainability of executives and data objects: The executive and data object classes need to contain code to copy meta-data between information objects and data objects at the appropriate times. This code is confusing and hard to maintain as we continue to improve the executives.<br />
# Subtle bugs that are very hard to debug: When data objects are used as meta-data storage, do we copy the meta-data when copying the data object? The answer is sometimes. This is hard to explain because it requires a good understanding of the pipeline (specially streaming and parallel execution) but believe me it is a major pain.<br />
# Circular dependencies: Data objects are still part of the execution. Therefore, they need to know about executives and algorithms. This creates unnecessary circular dependencies among classes and among objects.<br />
<br />
We propose to remove this compatibility layer. It has been a long time since VTK 5 was released. Algorithm and application developers had plenty of time to transition their code to the new pipeline and if they have not transitioned, it means that they are not taking advantage of any new functionality.<br />
<br />
== Proposed Changes ==<br />
<br />
=== Removal of the backward compatibility layer ===<br />
<br />
This means that there will be no longer vtkSource/vtkProcessObject to subclass from and that all methods to set/get meta-data on vtkDataObject will be removed. All algorithms will have to use the information objects to propagate meta-data and requests.<br />
<br />
=== Removal of data object's dependency on algorithm and executive ===<br />
<br />
Once we make the change above, data object no longer needs to know about algorithms and executives. This is very nice because now we can break Filtering into a DataModel and an ExecutionModel kit (see [[VTK/Modularization_Proposal]]). However, it has a big impact on backwards compatibility. Since data objects can no longer know about their producers, the following cannot be:<br />
<br />
<source lang="cpp"><br />
filter->SetInput(source->GetOutput());<br />
</source><br />
<br />
It is hard to quantify but there are probably quite a few applications that use SetInput() instead of SetInputConnection(). Note that the following can still work<br />
<br />
<source lang="cpp"><br />
filter->SetInput(data_object);<br />
</source><br />
<br />
as long as it is not expected to connect the filter to the data_object's producer. I propose that we remove SetInput() and add a new method (SetInputDataObject?) that has the effect of setting a data object as input without connecting the filter to its producer. This would avoid any problems that may come from changing the behavior of SetInput().<br />
<br />
'''Comment by Lorensen:''' My main concern with the whole proposal is the removal of ''filter->SetInput(data_object);''. It seems that the proposal is to rename it to ''SetInputDataObject''. Why not just leave it be? Developers have had no time to take this change into account. I do agree that ''filter->SetInput(source->GetOutput())'' should be removed since the ''SetInputConnection()'' has been recommended for years.<br />
<br />
<br />
Even though this may have a significant impact on backwards compatibility, I think that it is a change worth making. It will clean up things tremendously and allow us to move forward with data object - algorithm - pipeline in the future (see the Big Picture below). By the way, it would be easy to write a Perl/Python/whatever script to move most of the existing code forward; specially when fixing SetInput(...->GetOutput()).<br />
<br />
===Remove the RequestDataObject pass ===<br />
<br />
Now that data object is not used to pass meta-data, there is no need for an algorithm to have its input or output before RequestData. We should remove the RequestDataObject pass (which happens before even RequestInformation) and add the automatic output creation capability to the RequestData pass. For the most part, this is a backwards compatible changes. Things that would break:<br />
<br />
* An algorithm can not longer access its input or output in a pass before RequestData<br />
* GetOutput() would return null before Update() is called<br />
<br />
These are small changes that may require some rearranging of existing code but not significant changes. The main advantage is that algorithms, specially readers, no longer need to do a lot of work to figure out their output type before they get to fully execute.<br />
<br />
===Update() ===<br />
<br />
* Update() currently returns void, while it could returns the status of the executive<br />
* Write() should really be called Update() (in Writer object)</div>Mathieuhttps://public.kitware.com/Wiki/index.php?title=VTK/GSoC_2011&diff=38535VTK/GSoC 20112011-03-19T15:20:49Z<p>Mathieu: /* Project: Implementing SVG/EPS Backend for 2D API */</p>
<hr />
<div>Project ideas for the Google Summer of Code 2011<br />
<br />
== Guidelines ==<br />
<br />
=== Students ===<br />
<br />
These ideas were contributed by developers and users of [http://www.vtk.org/ VTK] and [http://www.paraview.org/ ParaView]. If you wish to submit a proposal based on these ideas you may wish to contact the developers to find out more about the idea you are looking at, get to know the developers your proposal will be reviewed by and receive feedback on your ideas.<br />
<br />
The Google Summer of Code program is competitive, and accepted students will usually have thoroughly researched the technologies of their proposed project, been in frequent contact with potential mentors and possibly have submitted a patch or two to fix bugs in the project they intend to work. Kitware makes extensive use of mailing lists, and this would be your best point of initial contact for any of the proposed projects you would like to apply for. The mailing lists can be found on the project pages linked to in the preceding paragraph. Please see [[GSoC proposal guidelines]] for further guidelines on writing your proposal.<br />
<br />
=== Adding Ideas ===<br />
<br />
When adding a new idea to this page, please try to include the following information:<br />
<br />
* A brief explanation of the idea.<br />
* Expected results/feature additions.<br />
* Any prerequisites for working on the project.<br />
* Links to any further information, discussions, bug reports etc.<br />
* Any special mailing lists if not the standard mailing list for the VTK.<br />
* Your name and email address for contact (if willing to mentor, or nominated mentor).<br />
<br />
If you are not a developer for the project concerned, please contact a developer about the idea before adding it here.<br />
<br />
== Project Ideas ==<br />
<br />
[http://www.vtk.org/ Project page], [http://www.vtk.org/vtk/help/mailing.html mailing lists], [http://www.cdash.org/CDash/index.php?project=VTK dashboard].<br />
<br />
=== Project: New 2D Charts ===<br />
<br />
'''Brief explanation:''' Implementation and augmentation of features in the existing 2D charts. Also exposure of these charts in the ParaView user interface. Additional features could also be added to existing charts such as error bars, mapping of more properties, enhanced interactivity features and/or performance improvements.<br />
<br />
'''Expected results:''' New chart types, improved interactivity with existing chart types and additional exposure in the ParaView GUI.<br />
<br />
'''Prerequisites:''' Experience in C++, some experience with VTK/OpenGL ideally, but not necessary.<br />
<br />
'''Mentor:''' Marcus Hanwell (marcus dot hanwell at kitware dot com).<br />
<br />
=== Project: Chemistry Visualization ===<br />
<br />
'''Brief explanation:''' Addition of new data types, mappers and visualizations for chemistry visualization. VTK has already been used in several open source chemistry applications, but lacks specialized support for this area. Features such as marching cubes, GPU accelerated volume rendering and glyph mappers could be leveraged here, along with BSD licensed projects such as OpenQube to read in a wider range of inputs. A CML reader could also improve general chemistry I/O. This could also make use of existing work in infovis and 2D charting to display numerical output.<br />
<br />
'''Expected results:''' Support for standard chemical representations, advanced visualization techniques of electronic structure using volume rendering, surfaces, contours etc. <br />
<br />
'''Prerequisites:''' Experience in C++, some experience with VTK/OpenGL ideally, but not necessary.<br />
<br />
'''Mentor:''' Marcus Hanwell (marcus dot hanwell at kitware dot com).<br />
<br />
=== Project: Volume Rendering in WebGL ===<br />
<br />
'''Brief explanation:''' Write an initial implementation of ray-cast volume rendering functionality in WebGL. This should allow web developers to use this library to perform volume rendering in the browser. The student should explore each technology and work on shader programs which emulate behavior implemented in the C++ VTK library. <br />
<br />
'''Expected results:''' A Javascript library that takes a 3D image data as input and produces interactive volume rendering in the browser. The student should evaluate performance and accuracy of implementations WebGL compared to the existing C++ implementation.<br />
<br />
'''Prerequisites:''' Familiarity with OpenGL and Javascript, some experience with CMake and C++ preferred.<br />
<br />
'''Mentor:''' Jeff Baumes (jeff.baumes at kitware dot com).<br />
<br />
=== Project: Protovis in C++ ===<br />
<br />
'''Brief explanation:''' [http://www.protovis.org Protovis] is a Javascript library that uses SVG to do information visualization in the browser. Its compact, expressive language allows developers to build complex visualizations. We would like the similar capabilities in the C++ VTK library for use in C++ applications that would scale to larger data. This effort has started in January 2010, but there are still many capabilities not offered in the C++ API. The accepted student would work to replicate several complex Protovis examples in C++, and implement new features in VTK that are missing to allow those examples to work in C++. This project relies heavily on C++ libraries such as the boost::lambda library for inline lambda functions in order to write compact visualization descriptions.<br />
<br />
'''Expected results:''' The student should provide C++ examples using VTK that emulate behavior in corresponding Protovis examples, and patches to VTK that allow the new features these examples require. Depending on the interest of mentor and student, this may involve animation support, advanced interaction techniques, new mark types, performance enhancements, or other features.<br />
<br />
'''Prerequisites:''' Some experience with CMake and C++, boost and template programming a plus. Javascript experience preferred but not necessary.<br />
<br />
'''Mentor:''' Jeff Baumes (jeff.baumes at kitware dot com).<br />
<br />
=== Project: Implement Select Algorithms from IEEE VisWeek 2010 in VTK ===<br />
<br />
'''Brief explanation:''' [http://vis.computer.org/VisWeek2010/ VisWeek] is the premier forum for visualization advances in science and engineering for academia, government, and industry. This event brings together researchers and practitioners with a shared interest in techniques, tools, and technology. During the conference, researchers present papers on advances in scientific visualization and informatics. Many of these algorithms introduce new algorithms but not necessarily release the implementations in a form usable by the larger community. Since VTK has become the ubiquitous open-source toolkit for visualization, implementing these algorithms in the VTK framework would make them available to a large group of users. The accepted student would work to implement several select algorithms from VisWeek 2009 in C++ as new VTK algorithms. <br />
<br />
'''Expected results:''' Implementation of several leading algorithms from VisWeek 2010 in VTK. The student should also implement examples and tests that will run as part of VTK's testing system (using CMake/CTest).<br />
<br />
'''Prerequisites:''' Experience in visualization algorithms and/or GPU programming. Experience in C++. Some experience with VTK is preferred but not necessary.<br />
<br />
'''Mentor:''' Berk Geveci (berk.geveci at kitware dot com).<br />
<br />
=== Project: AMR Volume Rendering in VTK ===<br />
<br />
'''Brief explanation:''' Adaptive Mesh Refinement (AMR) has become popular in the numerical solution of shock physics, plasma physics and astrophysics problems. AMR uses a set of overlapping rectilinear grids to discretize the domain of problems that involve feature of largely varying scales. For example, in astrophysics the problem domain include whole galaxies but the mesh has to resolve individual stars. VTK has introduced native support for AMR meshes a few years ago and most of VTK's algorithms work well with this mesh type. One important algorithm that is missing and that is widely used by the AMR community is [http://en.wikipedia.org/wiki/Volume_rendering volume rendering]. The accepted student will work to implement AMR volume rendering in VTK using existing building blocks include software and GPU-based volume rendering algorithms for rectilinear grids.<br />
<br />
'''Expected results:''' Implementation of AMR volume rendering in VTK. The student should also implement examples and tests that will run as part of VTK's testing system (using CMake/CTest).<br />
<br />
'''Prerequisites:''' Some experience in volume rendering and/or VTK is preferred but not necessary. Experience in C++.<br />
<br />
'''Mentor:''' Berk Geveci (berk.geveci at kitware dot com).<br />
<br />
=== Project: Implementing SVG/EPS Backend for 2D API ===<br />
<br />
'''Brief explanation:''' VTK has a new, abstracted 2D API. It currently only has one backend (OpenGL), with a very early proof of concept using Qt. The project would involve adding an SVG/EPS backend, implementing support classes print quality output. This would ideally lead to the possibility of producing publication quality charts using an SVG/EPS (or similar) output backend without the need for any graphical environment.<br />
<br />
'''Expected results:''' A new backend, focused on producing publication quality output using SVG/EPS. Ideally a second interactive backend that does not require any graphical environment (headless web server etc), along with additional tests and documentation of the new feature.<br />
<br />
'''Prerequisites:''' Experience in C++. Some experience with VTK, SVG and/or EPS ideally, but not necessary.<br />
<br />
'''Mentor:''' Marcus Hanwell (marcus dot hanwell at kitware dot com).<br />
<br />
=== Project: iPhone/iPod/iPad/Android Support for ParaView Web ===<br />
<br />
'''Brief explanation:''' We have been working on developing a Web visualization framework based on ParaView. This framework has two major components: a) a Javascript API and b) Flash-based interactive 3D visualization "applet". The Flash-based applet was designed to provide interactive frame rates by keeping a persistent connection (over http) for each user session. Unfortunately, due to lack of Flash support, this applet cannot function on the widely popular iPhone/iPod Touch and the upcoming iPad. Furthermore, the Flash applet was designed for desktop use and we are not sure how well it will work on an Android device. The accepted student will extend the ParaView Web framework to support iPod/iPhone/iPad and/or Android.<br />
[http://www.paraview.org/ ParaView, [http://www.paraview.org/paraview/help/mailing.html mailing lists], [http://www.cdash.org/CDash/index.php?project=ParaView3 dashboard].<br />
<br />
'''Expected results:''' Interactive ParaView Web visualization applet/library for iPod/iPhone/iPad and/or Android. Example application(s) and regression tests. Note that this applet/library does not have to be a Web applet. It is OK to provide a library for stand-alone application development as long as the communication can happen over http.<br />
<br />
'''Prerequisites:''' Experience in iPod/iPhone development and/or experience in Android development.<br />
<br />
'''Mentor:''' Utkarsh Ayachit (utkarsh dot ayachit at kitware.com)</div>Mathieuhttps://public.kitware.com/Wiki/index.php?title=VTK/GSoC_2011&diff=38534VTK/GSoC 20112011-03-19T15:20:36Z<p>Mathieu: /* Project: Chemistry Visualization */</p>
<hr />
<div>Project ideas for the Google Summer of Code 2011<br />
<br />
== Guidelines ==<br />
<br />
=== Students ===<br />
<br />
These ideas were contributed by developers and users of [http://www.vtk.org/ VTK] and [http://www.paraview.org/ ParaView]. If you wish to submit a proposal based on these ideas you may wish to contact the developers to find out more about the idea you are looking at, get to know the developers your proposal will be reviewed by and receive feedback on your ideas.<br />
<br />
The Google Summer of Code program is competitive, and accepted students will usually have thoroughly researched the technologies of their proposed project, been in frequent contact with potential mentors and possibly have submitted a patch or two to fix bugs in the project they intend to work. Kitware makes extensive use of mailing lists, and this would be your best point of initial contact for any of the proposed projects you would like to apply for. The mailing lists can be found on the project pages linked to in the preceding paragraph. Please see [[GSoC proposal guidelines]] for further guidelines on writing your proposal.<br />
<br />
=== Adding Ideas ===<br />
<br />
When adding a new idea to this page, please try to include the following information:<br />
<br />
* A brief explanation of the idea.<br />
* Expected results/feature additions.<br />
* Any prerequisites for working on the project.<br />
* Links to any further information, discussions, bug reports etc.<br />
* Any special mailing lists if not the standard mailing list for the VTK.<br />
* Your name and email address for contact (if willing to mentor, or nominated mentor).<br />
<br />
If you are not a developer for the project concerned, please contact a developer about the idea before adding it here.<br />
<br />
== Project Ideas ==<br />
<br />
[http://www.vtk.org/ Project page], [http://www.vtk.org/vtk/help/mailing.html mailing lists], [http://www.cdash.org/CDash/index.php?project=VTK dashboard].<br />
<br />
=== Project: New 2D Charts ===<br />
<br />
'''Brief explanation:''' Implementation and augmentation of features in the existing 2D charts. Also exposure of these charts in the ParaView user interface. Additional features could also be added to existing charts such as error bars, mapping of more properties, enhanced interactivity features and/or performance improvements.<br />
<br />
'''Expected results:''' New chart types, improved interactivity with existing chart types and additional exposure in the ParaView GUI.<br />
<br />
'''Prerequisites:''' Experience in C++, some experience with VTK/OpenGL ideally, but not necessary.<br />
<br />
'''Mentor:''' Marcus Hanwell (marcus dot hanwell at kitware dot com).<br />
<br />
=== Project: Chemistry Visualization ===<br />
<br />
'''Brief explanation:''' Addition of new data types, mappers and visualizations for chemistry visualization. VTK has already been used in several open source chemistry applications, but lacks specialized support for this area. Features such as marching cubes, GPU accelerated volume rendering and glyph mappers could be leveraged here, along with BSD licensed projects such as OpenQube to read in a wider range of inputs. A CML reader could also improve general chemistry I/O. This could also make use of existing work in infovis and 2D charting to display numerical output.<br />
<br />
'''Expected results:''' Support for standard chemical representations, advanced visualization techniques of electronic structure using volume rendering, surfaces, contours etc. <br />
<br />
'''Prerequisites:''' Experience in C++, some experience with VTK/OpenGL ideally, but not necessary.<br />
<br />
'''Mentor:''' Marcus Hanwell (marcus dot hanwell at kitware dot com).<br />
<br />
=== Project: Volume Rendering in WebGL ===<br />
<br />
'''Brief explanation:''' Write an initial implementation of ray-cast volume rendering functionality in WebGL. This should allow web developers to use this library to perform volume rendering in the browser. The student should explore each technology and work on shader programs which emulate behavior implemented in the C++ VTK library. <br />
<br />
'''Expected results:''' A Javascript library that takes a 3D image data as input and produces interactive volume rendering in the browser. The student should evaluate performance and accuracy of implementations WebGL compared to the existing C++ implementation.<br />
<br />
'''Prerequisites:''' Familiarity with OpenGL and Javascript, some experience with CMake and C++ preferred.<br />
<br />
'''Mentor:''' Jeff Baumes (jeff.baumes at kitware dot com).<br />
<br />
=== Project: Protovis in C++ ===<br />
<br />
'''Brief explanation:''' [http://www.protovis.org Protovis] is a Javascript library that uses SVG to do information visualization in the browser. Its compact, expressive language allows developers to build complex visualizations. We would like the similar capabilities in the C++ VTK library for use in C++ applications that would scale to larger data. This effort has started in January 2010, but there are still many capabilities not offered in the C++ API. The accepted student would work to replicate several complex Protovis examples in C++, and implement new features in VTK that are missing to allow those examples to work in C++. This project relies heavily on C++ libraries such as the boost::lambda library for inline lambda functions in order to write compact visualization descriptions.<br />
<br />
'''Expected results:''' The student should provide C++ examples using VTK that emulate behavior in corresponding Protovis examples, and patches to VTK that allow the new features these examples require. Depending on the interest of mentor and student, this may involve animation support, advanced interaction techniques, new mark types, performance enhancements, or other features.<br />
<br />
'''Prerequisites:''' Some experience with CMake and C++, boost and template programming a plus. Javascript experience preferred but not necessary.<br />
<br />
'''Mentor:''' Jeff Baumes (jeff.baumes at kitware dot com).<br />
<br />
=== Project: Implement Select Algorithms from IEEE VisWeek 2010 in VTK ===<br />
<br />
'''Brief explanation:''' [http://vis.computer.org/VisWeek2010/ VisWeek] is the premier forum for visualization advances in science and engineering for academia, government, and industry. This event brings together researchers and practitioners with a shared interest in techniques, tools, and technology. During the conference, researchers present papers on advances in scientific visualization and informatics. Many of these algorithms introduce new algorithms but not necessarily release the implementations in a form usable by the larger community. Since VTK has become the ubiquitous open-source toolkit for visualization, implementing these algorithms in the VTK framework would make them available to a large group of users. The accepted student would work to implement several select algorithms from VisWeek 2009 in C++ as new VTK algorithms. <br />
<br />
'''Expected results:''' Implementation of several leading algorithms from VisWeek 2010 in VTK. The student should also implement examples and tests that will run as part of VTK's testing system (using CMake/CTest).<br />
<br />
'''Prerequisites:''' Experience in visualization algorithms and/or GPU programming. Experience in C++. Some experience with VTK is preferred but not necessary.<br />
<br />
'''Mentor:''' Berk Geveci (berk.geveci at kitware dot com).<br />
<br />
=== Project: AMR Volume Rendering in VTK ===<br />
<br />
'''Brief explanation:''' Adaptive Mesh Refinement (AMR) has become popular in the numerical solution of shock physics, plasma physics and astrophysics problems. AMR uses a set of overlapping rectilinear grids to discretize the domain of problems that involve feature of largely varying scales. For example, in astrophysics the problem domain include whole galaxies but the mesh has to resolve individual stars. VTK has introduced native support for AMR meshes a few years ago and most of VTK's algorithms work well with this mesh type. One important algorithm that is missing and that is widely used by the AMR community is [http://en.wikipedia.org/wiki/Volume_rendering volume rendering]. The accepted student will work to implement AMR volume rendering in VTK using existing building blocks include software and GPU-based volume rendering algorithms for rectilinear grids.<br />
<br />
'''Expected results:''' Implementation of AMR volume rendering in VTK. The student should also implement examples and tests that will run as part of VTK's testing system (using CMake/CTest).<br />
<br />
'''Prerequisites:''' Some experience in volume rendering and/or VTK is preferred but not necessary. Experience in C++.<br />
<br />
'''Mentor:''' Berk Geveci (berk.geveci at kitware dot com).<br />
<br />
=== Project: Implementing SVG/EPS Backend for 2D API ===<br />
<br />
'''Brief explanation:''' VTK has a new, abstracted 2D API. It currently only has one backend (OpenGL), with a very early proof of concept using Qt. The project would involve adding an SVG/EPS backend, implementing support classes print quality output. This would ideally lead to the possibility of producing publication quality charts using an SVG/EPS (or similar) output backend without the need for any graphical environment.<br />
<br />
'''Expected results:''' A new backend, focused on producing publication quality output using SVG/EPS. Ideally a second interactive backend that does not require any graphical environment (headless web server etc), along with additional tests and documentation of the new feature.<br />
<br />
'''Prerequisites:''' Experience in C++. Some experience with VTK, SVG and/or EPS ideally, but not necessary.<br />
<br />
'''Mentor:''' Marcus Hanwelll (marcus dot hanwell at kitware dot com).<br />
<br />
=== Project: iPhone/iPod/iPad/Android Support for ParaView Web ===<br />
<br />
'''Brief explanation:''' We have been working on developing a Web visualization framework based on ParaView. This framework has two major components: a) a Javascript API and b) Flash-based interactive 3D visualization "applet". The Flash-based applet was designed to provide interactive frame rates by keeping a persistent connection (over http) for each user session. Unfortunately, due to lack of Flash support, this applet cannot function on the widely popular iPhone/iPod Touch and the upcoming iPad. Furthermore, the Flash applet was designed for desktop use and we are not sure how well it will work on an Android device. The accepted student will extend the ParaView Web framework to support iPod/iPhone/iPad and/or Android.<br />
[http://www.paraview.org/ ParaView, [http://www.paraview.org/paraview/help/mailing.html mailing lists], [http://www.cdash.org/CDash/index.php?project=ParaView3 dashboard].<br />
<br />
'''Expected results:''' Interactive ParaView Web visualization applet/library for iPod/iPhone/iPad and/or Android. Example application(s) and regression tests. Note that this applet/library does not have to be a Web applet. It is OK to provide a library for stand-alone application development as long as the communication can happen over http.<br />
<br />
'''Prerequisites:''' Experience in iPod/iPhone development and/or experience in Android development.<br />
<br />
'''Mentor:''' Utkarsh Ayachit (utkarsh dot ayachit at kitware.com)</div>Mathieuhttps://public.kitware.com/Wiki/index.php?title=VTK/GSoC_2011&diff=38533VTK/GSoC 20112011-03-19T15:20:23Z<p>Mathieu: /* Project: New 2D Charts */</p>
<hr />
<div>Project ideas for the Google Summer of Code 2011<br />
<br />
== Guidelines ==<br />
<br />
=== Students ===<br />
<br />
These ideas were contributed by developers and users of [http://www.vtk.org/ VTK] and [http://www.paraview.org/ ParaView]. If you wish to submit a proposal based on these ideas you may wish to contact the developers to find out more about the idea you are looking at, get to know the developers your proposal will be reviewed by and receive feedback on your ideas.<br />
<br />
The Google Summer of Code program is competitive, and accepted students will usually have thoroughly researched the technologies of their proposed project, been in frequent contact with potential mentors and possibly have submitted a patch or two to fix bugs in the project they intend to work. Kitware makes extensive use of mailing lists, and this would be your best point of initial contact for any of the proposed projects you would like to apply for. The mailing lists can be found on the project pages linked to in the preceding paragraph. Please see [[GSoC proposal guidelines]] for further guidelines on writing your proposal.<br />
<br />
=== Adding Ideas ===<br />
<br />
When adding a new idea to this page, please try to include the following information:<br />
<br />
* A brief explanation of the idea.<br />
* Expected results/feature additions.<br />
* Any prerequisites for working on the project.<br />
* Links to any further information, discussions, bug reports etc.<br />
* Any special mailing lists if not the standard mailing list for the VTK.<br />
* Your name and email address for contact (if willing to mentor, or nominated mentor).<br />
<br />
If you are not a developer for the project concerned, please contact a developer about the idea before adding it here.<br />
<br />
== Project Ideas ==<br />
<br />
[http://www.vtk.org/ Project page], [http://www.vtk.org/vtk/help/mailing.html mailing lists], [http://www.cdash.org/CDash/index.php?project=VTK dashboard].<br />
<br />
=== Project: New 2D Charts ===<br />
<br />
'''Brief explanation:''' Implementation and augmentation of features in the existing 2D charts. Also exposure of these charts in the ParaView user interface. Additional features could also be added to existing charts such as error bars, mapping of more properties, enhanced interactivity features and/or performance improvements.<br />
<br />
'''Expected results:''' New chart types, improved interactivity with existing chart types and additional exposure in the ParaView GUI.<br />
<br />
'''Prerequisites:''' Experience in C++, some experience with VTK/OpenGL ideally, but not necessary.<br />
<br />
'''Mentor:''' Marcus Hanwell (marcus dot hanwell at kitware dot com).<br />
<br />
=== Project: Chemistry Visualization ===<br />
<br />
'''Brief explanation:''' Addition of new data types, mappers and visualizations for chemistry visualization. VTK has already been used in several open source chemistry applications, but lacks specialized support for this area. Features such as marching cubes, GPU accelerated volume rendering and glyph mappers could be leveraged here, along with BSD licensed projects such as OpenQube to read in a wider range of inputs. A CML reader could also improve general chemistry I/O. This could also make use of existing work in infovis and 2D charting to display numerical output.<br />
<br />
'''Expected results:''' Support for standard chemical representations, advanced visualization techniques of electronic structure using volume rendering, surfaces, contours etc. <br />
<br />
'''Prerequisites:''' Experience in C++, some experience with VTK/OpenGL ideally, but not necessary.<br />
<br />
'''Mentor:''' Marcus Hanwelll (marcus dot hanwell at kitware dot com).<br />
<br />
=== Project: Volume Rendering in WebGL ===<br />
<br />
'''Brief explanation:''' Write an initial implementation of ray-cast volume rendering functionality in WebGL. This should allow web developers to use this library to perform volume rendering in the browser. The student should explore each technology and work on shader programs which emulate behavior implemented in the C++ VTK library. <br />
<br />
'''Expected results:''' A Javascript library that takes a 3D image data as input and produces interactive volume rendering in the browser. The student should evaluate performance and accuracy of implementations WebGL compared to the existing C++ implementation.<br />
<br />
'''Prerequisites:''' Familiarity with OpenGL and Javascript, some experience with CMake and C++ preferred.<br />
<br />
'''Mentor:''' Jeff Baumes (jeff.baumes at kitware dot com).<br />
<br />
=== Project: Protovis in C++ ===<br />
<br />
'''Brief explanation:''' [http://www.protovis.org Protovis] is a Javascript library that uses SVG to do information visualization in the browser. Its compact, expressive language allows developers to build complex visualizations. We would like the similar capabilities in the C++ VTK library for use in C++ applications that would scale to larger data. This effort has started in January 2010, but there are still many capabilities not offered in the C++ API. The accepted student would work to replicate several complex Protovis examples in C++, and implement new features in VTK that are missing to allow those examples to work in C++. This project relies heavily on C++ libraries such as the boost::lambda library for inline lambda functions in order to write compact visualization descriptions.<br />
<br />
'''Expected results:''' The student should provide C++ examples using VTK that emulate behavior in corresponding Protovis examples, and patches to VTK that allow the new features these examples require. Depending on the interest of mentor and student, this may involve animation support, advanced interaction techniques, new mark types, performance enhancements, or other features.<br />
<br />
'''Prerequisites:''' Some experience with CMake and C++, boost and template programming a plus. Javascript experience preferred but not necessary.<br />
<br />
'''Mentor:''' Jeff Baumes (jeff.baumes at kitware dot com).<br />
<br />
=== Project: Implement Select Algorithms from IEEE VisWeek 2010 in VTK ===<br />
<br />
'''Brief explanation:''' [http://vis.computer.org/VisWeek2010/ VisWeek] is the premier forum for visualization advances in science and engineering for academia, government, and industry. This event brings together researchers and practitioners with a shared interest in techniques, tools, and technology. During the conference, researchers present papers on advances in scientific visualization and informatics. Many of these algorithms introduce new algorithms but not necessarily release the implementations in a form usable by the larger community. Since VTK has become the ubiquitous open-source toolkit for visualization, implementing these algorithms in the VTK framework would make them available to a large group of users. The accepted student would work to implement several select algorithms from VisWeek 2009 in C++ as new VTK algorithms. <br />
<br />
'''Expected results:''' Implementation of several leading algorithms from VisWeek 2010 in VTK. The student should also implement examples and tests that will run as part of VTK's testing system (using CMake/CTest).<br />
<br />
'''Prerequisites:''' Experience in visualization algorithms and/or GPU programming. Experience in C++. Some experience with VTK is preferred but not necessary.<br />
<br />
'''Mentor:''' Berk Geveci (berk.geveci at kitware dot com).<br />
<br />
=== Project: AMR Volume Rendering in VTK ===<br />
<br />
'''Brief explanation:''' Adaptive Mesh Refinement (AMR) has become popular in the numerical solution of shock physics, plasma physics and astrophysics problems. AMR uses a set of overlapping rectilinear grids to discretize the domain of problems that involve feature of largely varying scales. For example, in astrophysics the problem domain include whole galaxies but the mesh has to resolve individual stars. VTK has introduced native support for AMR meshes a few years ago and most of VTK's algorithms work well with this mesh type. One important algorithm that is missing and that is widely used by the AMR community is [http://en.wikipedia.org/wiki/Volume_rendering volume rendering]. The accepted student will work to implement AMR volume rendering in VTK using existing building blocks include software and GPU-based volume rendering algorithms for rectilinear grids.<br />
<br />
'''Expected results:''' Implementation of AMR volume rendering in VTK. The student should also implement examples and tests that will run as part of VTK's testing system (using CMake/CTest).<br />
<br />
'''Prerequisites:''' Some experience in volume rendering and/or VTK is preferred but not necessary. Experience in C++.<br />
<br />
'''Mentor:''' Berk Geveci (berk.geveci at kitware dot com).<br />
<br />
=== Project: Implementing SVG/EPS Backend for 2D API ===<br />
<br />
'''Brief explanation:''' VTK has a new, abstracted 2D API. It currently only has one backend (OpenGL), with a very early proof of concept using Qt. The project would involve adding an SVG/EPS backend, implementing support classes print quality output. This would ideally lead to the possibility of producing publication quality charts using an SVG/EPS (or similar) output backend without the need for any graphical environment.<br />
<br />
'''Expected results:''' A new backend, focused on producing publication quality output using SVG/EPS. Ideally a second interactive backend that does not require any graphical environment (headless web server etc), along with additional tests and documentation of the new feature.<br />
<br />
'''Prerequisites:''' Experience in C++. Some experience with VTK, SVG and/or EPS ideally, but not necessary.<br />
<br />
'''Mentor:''' Marcus Hanwelll (marcus dot hanwell at kitware dot com).<br />
<br />
=== Project: iPhone/iPod/iPad/Android Support for ParaView Web ===<br />
<br />
'''Brief explanation:''' We have been working on developing a Web visualization framework based on ParaView. This framework has two major components: a) a Javascript API and b) Flash-based interactive 3D visualization "applet". The Flash-based applet was designed to provide interactive frame rates by keeping a persistent connection (over http) for each user session. Unfortunately, due to lack of Flash support, this applet cannot function on the widely popular iPhone/iPod Touch and the upcoming iPad. Furthermore, the Flash applet was designed for desktop use and we are not sure how well it will work on an Android device. The accepted student will extend the ParaView Web framework to support iPod/iPhone/iPad and/or Android.<br />
[http://www.paraview.org/ ParaView, [http://www.paraview.org/paraview/help/mailing.html mailing lists], [http://www.cdash.org/CDash/index.php?project=ParaView3 dashboard].<br />
<br />
'''Expected results:''' Interactive ParaView Web visualization applet/library for iPod/iPhone/iPad and/or Android. Example application(s) and regression tests. Note that this applet/library does not have to be a Web applet. It is OK to provide a library for stand-alone application development as long as the communication can happen over http.<br />
<br />
'''Prerequisites:''' Experience in iPod/iPhone development and/or experience in Android development.<br />
<br />
'''Mentor:''' Utkarsh Ayachit (utkarsh dot ayachit at kitware.com)</div>Mathieuhttps://public.kitware.com/Wiki/index.php?title=VTK/Image_Rendering_Classes&diff=37238VTK/Image Rendering Classes2011-02-04T09:35:56Z<p>Mathieu: /* Using DrawPixels instead of Texture */</p>
<hr />
<div>__NOTOC__<br />
The display of slices of 3D images in VTK is currently much more difficult and much less flexible than it should be. A typical pipeline for displaying an oblique reformat of an image will consist of vtkImageReslice, vtkImageMapToColors, and vtkImageActor, and most VTK novices (in fact even most experts) will have great difficulty sorting through the many settings of these filters to achieve the desired result.<br />
<br />
The primary goal of this project is to provide a 3D image mapper that will take care of all the details so that VTK users can display reformats with ease. In order for this to be done, the vtkImageActor must be replaced with a new image prop class that has SetMapper() and SetProperty() methods like those of vtkActor and vtkVolume.<br />
<br />
== Proposal ==<br />
<br />
[[Image:ImageOblique.png|right|300px|thumb|Oblique view with dark blue background.]]<br />
I propose a new prop class called vtkImage that will be the image-display equivalent of vtkActor and vtkVolume. This class will have a property class and at least two mapper classes.<br />
<br />
* vtkImage<br />
** vtkImageActor (subclass)<br />
* vtkImageProperty<br />
* vtkImageMapper3D<br />
** vtkImageResliceMapper (subclass)<br />
** vtkImageSliceMapper (subclass)<br />
<br />
In addition to the new classes, the vtkInteractorStyleImage will be modified so that it has a "3D mode" for interacting with 3D images. <br />
<br />
=== vtkImage ===<br />
<br />
[[Image:ImageSagittal.png|right|300px|thumb|Sagittal view with dark blue background.]]<br />
Unlike vtkImageActor, the vtkImage class will have a very simple interface. Its only methods will be SetMapper() and SetProperty() method, plus the inherited vtkProp3D methods for controlling position, orientation, and visibility.<br />
<br />
The existing vtkLODProp3D class will be modified so that it can make an LOD from a vtkImageProperty and vtkImageMapper3D. This will allow vtkImage to be part of an LOD, which was impossible with vtkImageActor. In addition, the VTK pickers will be modified to use vtkImage in place of vtkImageActor (note that vtkImageActor will still be supported, since it will be a subclass).<br />
<br />
By using alpha-blending (translucency), different images can be blended together at render time. They will be blended in the order in which they were added to the renderer. Potentially, each image could be assigned a layer number.<br />
<br />
=== vtkImageProperty ===<br />
<br />
The property will control the image display parameters.<br />
* SetInterpolationType(int type)<br />
* SetScalarRange(double range[2])<br />
* SetLookupTable(vtkScalarsToColors *table)<br />
* UseLookupTableScalarRangeOn() - default Off<br />
* SetOpacity(double opacity)<br />
* ShadeOff() - default On<br />
<br />
Interpolation types will be Nearest, Linear, and Cubic. There will be no methods for setting window/level, only a method for setting the range.<br />
<br />
The lookup table is optional. If no lookup table is given, then the range will still be applied: single-component data will be displayed as greyscale, and multi-component data will be displayed as color. If a lookup table is provided, the VectorMode of the lookup table can be used to control how multi-component data will be displayed, i.e. by component, by magnitude, or as colors.<br />
<br />
The Shade parameter sets whether lighting is used. Methods could also be provided for Ambient, Diffuse, Specular, and Color but I'm not sure how useful they would be.<br />
<br />
=== vtkImageMapper3D ===<br />
<br />
This is the base class for 3D image mappers. It has SetInput() and SetInputConnection() methods, and inherits abstract mapper methods for setting clipping planes.<br />
<br />
=== vtkImageResliceMapper ===<br />
<br />
A mapper for oblique reformats. The default behaviour of this mapper is to follow the camera, i.e. to always display the slice that intersects the camera focal point and is perpendicular to the view plane normal. Having the slice follow the camera makes it very easy to modify VTK interactor styles to work with this mapper.<br />
<br />
The interface methods are as follows:<br />
* UseFocalPointAsSlicePointOff() - default is On<br />
* UseViewPlaneNormalAsSliceNormalOff() - default is On<br />
* SetSlicePoint(double point[3])<br />
* SetSliceNormal(double normal[3])<br />
<br />
Internally, this mapper uses vtkImageReslice to reslice the image, and creates a 2D texture as large as the portion of the viewport covered by the image. This texture is then composited into the VTK scene.<br />
<br />
=== vtkImageSliceMapper ===<br />
<br />
A mapper that can only do x, y, or z slices. It will also be the ideal mapper for displaying 2D images, since it will directly map its input to a texture and will therefore be more efficient than the reslice mapper.<br />
<br />
This interface is intentionally similar to that of vtkImageActor. Once this mapper is finished, vtkImageActor will use it internally.<br />
* SetSliceNumber(int slice)<br />
* GetSliceNumberMin()<br />
* GetSliceNumberMax()<br />
* SetOrientationToX()<br />
* SetOrientationToY()<br />
* SetOrientationToZ()<br />
* SetOrientationToAutomatic()<br />
* UseDisplayExtentOn() - default is Off<br />
* SetDisplayExtent(int extent[6])<br />
<br />
Unlike vtkImageActor, this mapper will be able to do cubic interpolation.<br />
<br />
=== vtkInteractorStyleImage ===<br />
<br />
This interactor style will be modified so that it can be used for 3D image reslicing. The following methods will be added:<br />
* SetInteractionModeToImage2D()<br />
* SetInteractionModeToImage3D()<br />
* SetImageOrientation(double horizontal[3], double vertical[3]);<br />
<br />
When the mode is set to 3D, the following bindings will be present:<br />
* Shift-LeftButton - rotate the camera, i.e. do oblique slicing<br />
* Shift-RightButton - move the focal point in and out, i.e. scroll through slices<br />
<br />
In both the 2D and 3D modes, the following new key bindings will be present:<br />
* X - sagittal view<br />
* Y - coronal view<br />
* Z - axial view<br />
These keys will change the position and the view-up of the camera. Exactly what view orientations will create the desired ax/cor/sag views will depend on the coordinate system used for the image data. Because of this, the direction cosines for the X, Y, and Z orientations can be set manually with the following methods:<br />
* SetXViewLeftToRight(double vector[3])<br />
* SetXViewUp(double vector[3])<br />
* ditto for Y and Z<br />
<br />
A note on window/level: vtkInteractorStyleImage will now automatically find the property object of the image that is being displayed and modify it. Because of this, the user will no longer have to add window/level observers to the interactor style in order to make window/level possible.<br />
<br />
== Wish List ==<br />
<br />
=== Shader programs for compositing ===<br />
<br />
Anyone who uses Photoshop or The Gimp will be familiar with the concept of "layers" and the myriad ways that layers can be composited. It would be very nice if custom fragment shaders could be used to do the same thing with images in VTK. Some of the existing infrastructure for the VTK painters could probably be used for this.<br />
<br />
Likelihood: so-so.<br />
<br />
=== 12-bit display ===<br />
<br />
In the medical field, 10-bit and 12-bit greyscale displays are sometimes used. To support these displays, there could be an option to scale the intensity to [0,4095] instead of the usual [0,255]. One problem is that the way to achieve 12-bit display will vary from vendor to vendor.<br />
<br />
Likelihood: high if someone is willing to test.<br />
<br />
=== Projections ===<br />
<br />
It is very common to use "thick slice" averaging to clean up noisy images, or to use MIP slabs when viewing blood vessels. In both of the mappers described above, it would be easy to use vtkImageProjection to achieve this.<br />
<br />
Likelihood: sure thing.<br />
<br />
=== N-Up views ===<br />
<br />
Likewise, it would be easy to take multiple slices of the input image, and reformat them to an NxM grid on a single texture. This would be tricky for picking and getting pixel values, since the portion of the viewport that would typically contain just one image would contain a grid of images instead.<br />
<br />
Likelihood: high.<br />
<br />
=== An image mapper for geometry ===<br />
<br />
It sounds kind of silly, but it could be useful. For example, a FEM could be sliced and displayed as an image. Or a 3D surface contour could be sliced and displayed as an image overlay. The main idea would be to take advantage of the image compositing: there would be no need for the user to make sure that the cutter was set up right and that all the correct depth offset were applied. Instead, the user could just pop the geometry into an image mapper, and the overlay would be perfect every time.<br />
<br />
Likelihood: so-so.<br />
<br />
=== Efficiency ===<br />
<br />
The image mappers are designed to achieve the highest quality result, and although they will probably be fast enough to suit almost anyone, they will definitely slow down if displayed in a very large window or if several images are being composited. Hence, it would be nice to have some built-in LOD behaviour similar to the volume mappers. The most obvious speed-up would be to have vtkImageReslice sample the image at a lower resolution, and then have the texture re-interpolate to full resolution. A full-resolution and quarter-resolution texture would always be allocated on the GPU, but only the desired texture would be updated and rendered according to the desired LOD. The interactive rendering would be four times as fast as the high-quality rendering.<br />
<br />
Likelihood: so-so.<br />
<br />
=== GPU acceleration ===<br />
<br />
Efficiency could also be improved by using 3D texture maps, but I'm not sure if this would be worthwhile. From a quality perspective, 16-bit textures would have to be used for medical images. Special fragment programs would be needed for cubic or other high-order interpolation. Lots of GPU memory would be required, particularly since the only time that such high speed would be needed is if multiple images are being composited. Also, it would be tricky to get it to work correctly with pipeline streaming. The mapper would have to be smart enough to know what parts of the 3D texture would be needed, so that the correct UpdateExtent could be set on the pipeline and the correct SubTexture loaded onto the GPU. Unless that was done, the whole texture would have to be uploaded on each execution.<br />
<br />
Overall, the current CPU-based implementation is already very fast. A GPU-based image mapper would be unlikely to improve the user experience significantly.<br />
<br />
Likelihood: low.<br />
<br />
=== Using DrawPixels instead of Texture ===<br />
<br />
The reslice mapper could have an option to render via glDrawPixels. The advantage would be higher performance on non-accelerated system (i.e. Mesa) and minimal use of GPU memory on accelerated systems. The disadvantage in this mode is that the image would have to be re-uploaded to the GPU on every render. This would be particularly bad for performance when interacting with blended images, since both images would have to be uploaded on each render, instead of just the image that had changed.<br />
<br />
Likelihood: so-so.<br />
<br />
=== Color Spaces other than RGB(A) ===<br />
<br />
Already vtkScalarsToColors has a VectorMode setting to<br />
say what it does with multi-component input. It would be nice to<br />
add a vector mode called "INDEPENDENT" where each<br />
component is mapped through a separate color table, and then<br />
the results are summed and clamped. There would be a method<br />
where you could add multiple child color tables to the main color<br />
table, each of which would map a different component.<br />
<br />
Another possibility is to just write a vtkScalarsToColors<br />
subclass that does -eg- YBR to RGB conversion.<br />
<br />
Likelihood: so-so.</div>Mathieuhttps://public.kitware.com/Wiki/index.php?title=ITK/Release_4/DICOM/Meeting_IOWA_2010&diff=34657ITK/Release 4/DICOM/Meeting IOWA 20102010-11-18T17:33:28Z<p>Mathieu: </p>
<hr />
<div>== Slides ==<br />
<br />
Slides [[Media:DICOMStatusITKv4.pdf|PDF]], [[Media:DICOMStatusITKv4.odp|ODP]]<br />
<br />
== Comments ==<br />
<br />
Make sure that during AAssociation we propose the compressed TS so that we retrieve compressed file<br />
if the SCP decide to do so<br />
<br />
Make sure that we can handle private transfer syntax (at least we have the API for).<br />
<br />
Make sure we can c-echo/c-find/c-store/c-move in the same connection (association)<br />
<br />
Need to document what dicom conformance is and that is the sole information to decide<br />
to do a patientroot query or a studyroot query<br />
<br />
Make sure to check the Extended negociation vs the old one (odd numbering thingy)<br />
<br />
Make sure we can generate an itk::Image directly from the query.<br />
<br />
Potential speed up when pipeline is a push pipeline and can start processing as image are retrieved.<br />
<br />
Make sure that we support something like:<br />
movescu example.com 104 +P 104<br />
<br />
Make it simple for user to derive from a series<br />
<br />
Make sure utf-8 is supported<br />
<br />
Flexible anonymizer for institutions restrictions<br />
* ftp://medical.nema.org/medical/dicom/supps/sup142_12.pdf<br />
<br />
JPEG-LS and such should be second class citizen and split along scanlines.<br />
<br />
------------------------------------<br />
<br />
Open questions: mosaic should support ImageFactory ?<br />
<br />
------------------------------------<br />
<br />
Hans wanted a MetaDataDict with variant type.</div>Mathieuhttps://public.kitware.com/Wiki/index.php?title=ITK/Release_4/DICOM/Meeting_IOWA_2010&diff=34656ITK/Release 4/DICOM/Meeting IOWA 20102010-11-18T17:33:14Z<p>Mathieu: </p>
<hr />
<div>== Slides ===<br />
<br />
Slides [[Media:DICOMStatusITKv4.pdf|PDF]], [[Media:DICOMStatusITKv4.odp|ODP]])<br />
<br />
== Comments ==<br />
<br />
Make sure that during AAssociation we propose the compressed TS so that we retrieve compressed file<br />
if the SCP decide to do so<br />
<br />
Make sure that we can handle private transfer syntax (at least we have the API for).<br />
<br />
Make sure we can c-echo/c-find/c-store/c-move in the same connection (association)<br />
<br />
Need to document what dicom conformance is and that is the sole information to decide<br />
to do a patientroot query or a studyroot query<br />
<br />
Make sure to check the Extended negociation vs the old one (odd numbering thingy)<br />
<br />
Make sure we can generate an itk::Image directly from the query.<br />
<br />
Potential speed up when pipeline is a push pipeline and can start processing as image are retrieved.<br />
<br />
Make sure that we support something like:<br />
movescu example.com 104 +P 104<br />
<br />
Make it simple for user to derive from a series<br />
<br />
Make sure utf-8 is supported<br />
<br />
Flexible anonymizer for institutions restrictions<br />
* ftp://medical.nema.org/medical/dicom/supps/sup142_12.pdf<br />
<br />
JPEG-LS and such should be second class citizen and split along scanlines.<br />
<br />
------------------------------------<br />
<br />
Open questions: mosaic should support ImageFactory ?<br />
<br />
------------------------------------<br />
<br />
Hans wanted a MetaDataDict with variant type.</div>Mathieuhttps://public.kitware.com/Wiki/index.php?title=ITK/Release_4/DICOM/Meeting_IOWA_2010&diff=34349ITK/Release 4/DICOM/Meeting IOWA 20102010-11-16T22:39:45Z<p>Mathieu: </p>
<hr />
<div>Make sure that during AAssociation we propose the compressed TS so that we retrieve compressed file<br />
if the SCP decide to do so<br />
<br />
Make sure that we can handle private transfer syntax (at least we have the API for).<br />
<br />
Make sure we can c-echo/c-find/c-store/c-move in the same connection (association)<br />
<br />
Need to document what dicom conformance is and that is the sole information to decide<br />
to do a patientroot query or a studyroot query<br />
<br />
Make sure to check the Extended negociation vs the old one (odd numbering thingy)<br />
<br />
Make sure we can generate an itk::Image directly from the query.<br />
<br />
Potential speed up when pipeline is a push pipeline and can start processing as image are retrieved.<br />
<br />
Make sure that we support something like:<br />
movescu example.com 104 +P 104<br />
<br />
Make it simple for user to derive from a series<br />
<br />
Make sure utf-8 is supported<br />
<br />
Flexible anonymizer for institutions restrictions<br />
* ftp://medical.nema.org/medical/dicom/supps/sup142_12.pdf<br />
<br />
JPEG-LS and such should be second class citizen and split along scanlines.<br />
<br />
------------------------------------<br />
<br />
Open questions: mosaic should support ImageFactory ?<br />
<br />
------------------------------------<br />
<br />
Hans wanted a MetaDataDict with variant type.</div>Mathieuhttps://public.kitware.com/Wiki/index.php?title=ITK/Release_4/DICOM/Meeting_IOWA_2010&diff=34232ITK/Release 4/DICOM/Meeting IOWA 20102010-11-14T17:13:45Z<p>Mathieu: Created page with "Make sure that during AAssociation we propose the compressed TS so that we retrieve compressed file if the SCP decide to do so Make sure that we can handle private transfer synt..."</p>
<hr />
<div>Make sure that during AAssociation we propose the compressed TS so that we retrieve compressed file<br />
if the SCP decide to do so<br />
<br />
Make sure that we can handle private transfer syntax (at least we have the API for).<br />
<br />
Make sure we can c-echo/c-find/c-store/c-move in the same connection (association)<br />
<br />
Need to document what dicom conformance is and that is the sole information to decide<br />
to do a patientroot query or a studyroot query<br />
<br />
Make sure to check the Extended negociation vs the old one (odd numbering thingy)<br />
<br />
Make sure we can generate an itk::Image directly from the query.<br />
<br />
Potential speed up when pipeline is a push pipeline and can start processing as image are retrieved.<br />
<br />
Make sure that we support something like:<br />
movescu example.com 104 +P 104<br />
<br />
Make it simple for user to derive from a series<br />
<br />
Make sure utf-8 is supported<br />
<br />
Flexible anonymizer for institutions restrictions<br />
<br />
JPEG-LS and such should be second class citizen and split along scanlines.<br />
<br />
------------------------------------<br />
<br />
Open questions: mosaic should support ImageFactory ?<br />
<br />
------------------------------------<br />
<br />
Hans wanted a MetaDataDict with variant type.</div>Mathieuhttps://public.kitware.com/Wiki/index.php?title=ITK/Release_4/DICOM&diff=34231ITK/Release 4/DICOM2010-11-14T17:13:22Z<p>Mathieu: /* TCons */</p>
<hr />
<div>'''Improving DICOM Support'''<br />
<br />
= Goals =<br />
<br />
* Improve the support for DICOM needs by the ITK community<br />
** DICOM communication layer (PACS connection)<br />
** type checking<br />
** minimum DICOM skeleton generation<br />
<br />
= Discussions =<br />
<br />
== [[ITKv4_DICOM_Communications_Discussion | Communications Discussions]] ==<br />
== how to test against PACS automatically ? ==<br />
<br />
( thanks to steve piepper)<br />
I had a chance to ask Lawrence Tarbox of Washington University your question<br />
about dicom testing. Lawrence is a participant in CTK and a long-time dicom<br />
standards participant too (he's actually working on the hosted application<br />
specification, which we should ultimately be compatible with).<br />
<br />
For PACS-like testing, he pointed to two well established efforts, linked<br />
below. Lawrence knows people involved in these and thinks they might be<br />
receptive to seeing integration with ctest and cdash if you want to pursue<br />
that. In any case I think we can learn a lot from these efforts.<br />
<br />
http://www.ihe.net/Connectathon/ (look for the MESA test suite)<br />
<br />
http://www.dvtk.org/<br />
<br />
=== Contestants ===<br />
<br />
* http://www.na-mic.org/Wiki/index.php/CTSC:ARRA:Mockup<br />
* http://www.dicomserver.co.uk/<br />
<br />
Seting up a dcm4che server:<br />
* http://www.osirix-viewer.com/PACS.html<br />
<br />
=== design proposal ===<br />
<br />
[[ITK Release 4/DICOM/MetaData]]<br />
<br />
= TCons =<br />
<br />
* [[ITK_Release_4/DICOM/Tcon_2010_10_11|TCon 2010/10/11]], [[ITK_Release_4/DICOM/Minutes_2010_10_11| Minutes 2010_10_11]]<br />
<br />
= Meeting =<br />
<br />
* [[ITK_Release_4/DICOM/Meeting_IOWA_2010|Meeting Iowa]]</div>Mathieuhttps://public.kitware.com/Wiki/index.php?title=ITK_Release_4/Software_Guide_Update&diff=34077ITK Release 4/Software Guide Update2010-11-10T19:41:21Z<p>Mathieu: /* DICOM */</p>
<hr />
<div>= Software Guide Update =<br />
<br />
This page is intended to coordinate the effort of updating the ITK Software Guide<br />
<br />
== Revision of Existing Content ==<br />
<br />
* Statistics Chapter must be revised to match the new framework<br />
* IO Chapter<br />
** should list new ImageIO classes<br />
** Streaming must be described : how to use it.<br />
<br />
* Describe how memory management works -- Most people want to use a minimal amount of memory, but by default, and following the examples uses tremendously more memory.<br />
<br />
* Describe the pipeline behavior with more pictures<br />
<br />
* The software guide should use its "soap box" more effectively in promoting best practices.<br />
<br />
* A chapter on how to write the "Hello Gaussian Smoothing World" program, including timing, memory probes, and testing should be written.<br />
<br />
== Addition of New Content ==<br />
<br />
The following chapters will be added to the ITK Software Guide<br />
<br />
=== FEM ===<br />
<br />
* New FEM framework<br />
<br />
=== Refactored Image Registration ===<br />
<br />
* New capabilities<br />
* Improving users experience<br />
<br />
=== Modularization ===<br />
<br />
* How to use modules<br />
* Selecting modules<br />
* Managing dependencies<br />
* Creating a new module<br />
* Searching for the module that contains a given class<br />
<br />
<br />
=== Level Sets ===<br />
<br />
* Generalized Level Sets<br />
<br />
=== DICOM ===<br />
<br />
* GDCM 2.0<br />
* Private Tags<br />
* MR Protocol (GE, Siemens)<br />
* DICOM Query / Retrieve<br />
* RTSTRUCT<br />
* MOSAIC<br />
<br />
=== Simple ITK ===<br />
<br />
* Should Simply ITK have its own book, customized to a different audience ?</div>Mathieuhttps://public.kitware.com/Wiki/index.php?title=ITK/Fall_v4_2010_Meeting&diff=33996ITK/Fall v4 2010 Meeting2010-11-09T13:30:13Z<p>Mathieu: /* Morning */</p>
<hr />
<div>The ITKv4 Fall meeting is set. <br />
<br />
*'''Dates: November 8-10, 2010''' <br />
*'''City: Iowa City, IA'''<br />
*'''Location: Hotel Vetro'''<br />
<br />
We will meet all day on Monday November 8 and Tuesday November 9. A half day finishing around 1pm is scheduled for Wednesday November 10. <br />
<br />
<br />
== Travel Information ==<br />
The closest airport to Iowa City is the '''Cedar Rapids / Eastern Iowa Airport (CID)'''<br />
which is about 20 minutes from the hotel. <br />
<br />
===Airport Shuttle Services===<br />
The easiest way to get from the airport to<br />
Iowa City is via one of the shuttle services: <br />
* [http://www.crshuttle.com/ Airport Shuttle Service] (Phone: 1-800-725-8460)<br />
* [http://www.limosbyexpress.com/ Airport Express] (Phone: 319-626-5466)<br />
Both are the same price and easiest to book before travel. The cost is roughly $60 round trip.<br />
<br />
===Rental Cars===<br />
Rental cars are also available from the Airport. The following companies have desks at the airport<br />
* Avis<br />
** [http://www.avis.com/ Website] <br />
** Toll-Free Phone : 1-800-331-1212<br />
** Local Phone : (319) 366-6418<br />
* Hertz<br />
** [http://www.hertz.com/ Website] <br />
**Toll-Free Phone : 1-800-654-3131<br />
**Local Phone : (319) 365-9184<br />
* National and Alamo<br />
** [http://www.nationalcar.com/ Website]<br />
**Toll-Free Phone : 1-888-826-6890<br />
**Local Phone : (319) 363-0249<br />
*Enterprise<br />
**[http://www.enterprise.com/car_rental/home.do Website]<br />
**Local Phone : (319) 366-5522<br />
<br />
<br />
If you have any questions regarding travel, feel free to contact Joe Ekdahl either via e-mail(joe-ekdahl@uiowa.edu) or phone (319-384-3026).<br />
<br />
== Hotel Information ==<br />
We reserved a block of hotel rooms at Hotel Vetro at a rate of $139. The group code to get this rate is '''ITK-V4'''. These rooms will be held at this rate until October 22.<br />
* '''[http://www.hotelvetro.com/ Hotel Vetro]'''<br />
**Phone: 800-592-0355<br />
**Address: 201 South Linn Street, Iowa City, Iowa 52240<br />
<br />
<br />
Other hotels that are close to the conference site, University of Iowa, and downtown include:<br />
*'''[http://www.Sheraton.com/IowaCity Sheraton hotel]'''<br />
**Phone: 319-337-4058<br />
**Address: 210 South Dubuque St, Iowa City, IA 52240<br />
*'''[http://imu.uiowa.edu/iowahouse/ Iowa House Hotel]'''<br />
**Phone: 319-335-3513<br />
**Address: 125 North Madison St, Iowa City, IA 52242<br />
<br />
== Registration Information ==<br />
[https://www.continuetolearn.uiowa.edu/UIConferences/ Registration is now open for the ITKv4 Fall Meeting.] <br />
# Goto the '''ITK-v4 Fall Design Meeting''' <br />
# Select the '''Register Now''' link<br />
# Select the '''Create an Account'''<br />
This will take you through the registration process. There will be $125 fee for registration. We are also planning on a dinner Monday dinner that is optional and will be $10.<br />
<br />
== Meeting Room ==<br />
We will be meeting in the '''Plaza 1''' room.<br />
<br />
== Meeting Agenda ==<br />
<br />
<br />
<span style="color:#FF0000"> '''THE AGENDA HAS BEEN MODIFIED'''</span><br />
<br />
=== Essential Topics ===<br />
<br />
* '''Modularization''' (Bill Hoffman)<br />
** Testing strategy<br />
* '''Simple ITK''' (Dan Blezek, Bill Hoffman)<br />
** Its Wrapping (Alex Gouaillard, Gaetan Lehmann)<br />
* '''DICOM''' (Dan Blezek, Mathieu Malaterre)<br />
* '''GPU Acceleration''' (Won Ki)<br />
** Pipeline Refactoring (Jim Miller)<br />
<br />
===Monday November 8===<br />
<br />
==== Morning ====<br />
* 8:00am - 8:30am '''Breakfast'''<br />
* 8:30am - 9:00am '''Welcome''' (Terry Yoo)<br />
* 9:00am - 9:30am '''Status of the Toolkit''' (Hans Johnson, ISC President)<br />
* 9:30am - 10:00am '''Integration Plan - Software Process''' (Luis Ibanez, Bill Hoffman, Marcus Hanwell)<br />
** Coordinating Topic Branches<br />
** Coordinating Code Reviews<br />
* 10:00am - 10:30am '''Break'''<br />
* 10:30am - 12:00pm '''Modularization''' (Bill Hoffman)<br />
** Prototype (Bill Hoffman)<br />
** Dependencies (Bill Hoffman)<br />
** Suggested Partition (Xiaoxiao Liu, Luis Ibanez)<br />
** Documentation of independent modules (Luis Ibanez)<br />
<br />
==== Afternoon ====<br />
<br />
* 1:00pm - 3:00pm '''Simple ITK''' (Dan Blezek, Bill Hoffman) ([[Media:SimpleITK_Status-2010-11-10.pdf|Slides]])<br />
** Review Survey (Jesus Caban - [[Media:simpleITK-R2.pdf|Slides]], Gabe Hart - [[Media:SimpleITKSurveyReport.pdf|Slides]])<br />
** Design Discussion (Dan Blezek, Bill Hoffman)<br />
** Its Wrapping (Alex Gouaillard, Bill Hoffman)<br />
* 3:00pm - 3:30pm '''Break'''<br />
* 3:30pm - 5:30pm '''GPU Acceleration''' (Won-Ki)<br />
** Design Plan<br />
** Pipeline Refactoring (Jim Miller)<br />
*** How other classes need to be modified<br />
<br />
==== Dinner ====<br />
<br />
* 6:30pm - 1206 Plaza Towers<br />
<br />
===Tuesday November 9===<br />
<br />
==== Morning ====<br />
<br />
* 8:00am - 8:30am '''Breakfast'''<br />
* 8:30am - 9:30am '''ITKv4 - Planning''' (Luis, Hans)(Slides [[Media:ITKv4-TransitionPlanProposal-Nov-2010.odp|ODP]],[[Media:ITKv4-TransitionPlanProposal-Nov-2010.ppt|PPT]],[[Media:ITKv4-TransitionPlanProposal-Nov-2010.pdf|PDF]])<br />
** What to do for ITKv4-Alpha-03<br />
*** Windows 64 - Integers<br />
* 9:30am - 10:30am '''DICOM''' (Dan Blezek, Mathieu Malaterre) (Slides [[Media:DICOMStatusITKv4.pdf|PDF]], [[Media:DICOMStatusITKv4.odp|ODP]])<br />
* 10:30am - 11:00am '''Break'''<br />
* 11:00am - 12:00am '''Spatial Objects''' (Sean Megason, Arnaud Gelas, Luis Ibanez)<br />
<br />
==== Afternoon ====<br />
<br />
* 12:00pm-1:00pm '''Lunch'''<br />
<br />
* 1:00pm - 1:45pm '''Filters Refactoring''' (Brad Lowekamp)<br />
* 1:45pm - 2:30pm '''Registration Framework Refactoring''' (Brian Avants)<br />
* 2:30pm - 3:15pm '''Level Sets Framework Refactoring''' (Arnaud Gelas)<br />
<br />
* 3:15pm - 3:45pm '''Break'''<br />
<br />
* 3:45pm - 4:30pm '''FEM Refactoring''' (Vince Magnotta) ([[Media:ITK-FEM-Update-2010-November.ppt|Slides]])<br />
* 4:30pm - 5:15pm '''Video / Time series support''' (Patrick Reynolds, Patrick Cheng)<br />
<br />
===Wednesday November 10===<br />
<br />
==== Morning ====<br />
<br />
* 8:00am - 8:30am '''Breakfast'''<br />
* 8:30am - 10:30 '''Git/Gerrit Workshop''' (Marcus Hanwell)<br />
** Hands-on practical exercises on Git/Gerrit<br />
** Discussion about software process and improvements<br />
* 10:30am - 11:00am '''Break'''<br />
* 11:00am - 11:30am '''Migration Guide''' (Gabe Hart, Hans Johnson)<br />
** Online System<br />
** Workflow ([[Media:MigrationGuideFull.pdf|Slides]])<br />
*** User Driven Perspective<br />
*** Developer Workflow<br />
*** Automation<br />
* 11:30am - 12:00pm '''Testing Framework''' CDash@Home (Zach Mullen)<br />
** '''Testing Data''' (Git / MIDAS) (Zach Mullen,Patrick Reynolds)<br />
<br />
* 12-1pm '''Lunch'''<br />
<br />
==== Afternoon ====<br />
<br />
* 1:00pm - 1:30pm '''Doxygen''' crowdsourcing fixes (Luis Ibanez, Arnaud Gelas)<br />
* 1:30pm - 2:00pm '''Software Guide Update''' (Luis Ibanez)<br />
** New generation of Examples<br />
** Use the Wiki like VTK ?<br />
* 2pm Adjurn<br />
<br />
==== Unallocated Topics ====<br />
** Partition & assignment of tasks to groups proportional to funding.<br />
* 10:00am - 10:30am Coding Style (KWStyle/Gerrit) (Brad Lowekamp, Hans Johnson)</div>Mathieuhttps://public.kitware.com/Wiki/index.php?title=File:DICOMStatusITKv4.odp&diff=33995File:DICOMStatusITKv4.odp2010-11-09T13:29:26Z<p>Mathieu: </p>
<hr />
<div></div>Mathieuhttps://public.kitware.com/Wiki/index.php?title=File:DICOMStatusITKv4.pdf&diff=33994File:DICOMStatusITKv4.pdf2010-11-09T13:28:32Z<p>Mathieu: uploaded a new version of &quot;File:DICOMStatusITKv4.pdf&quot;</p>
<hr />
<div></div>Mathieuhttps://public.kitware.com/Wiki/index.php?title=ITK/Fall_v4_2010_Meeting&diff=33957ITK/Fall v4 2010 Meeting2010-11-08T19:52:31Z<p>Mathieu: /* Morning */</p>
<hr />
<div>The ITKv4 Fall meeting is set. <br />
<br />
*'''Dates: November 8-10, 2010''' <br />
*'''City: Iowa City, IA'''<br />
*'''Location: Hotel Vetro'''<br />
<br />
We will meet all day on Monday November 8 and Tuesday November 9. A half day finishing around 1pm is scheduled for Wednesday November 10. <br />
<br />
<br />
== Travel Information ==<br />
The closest airport to Iowa City is the '''Cedar Rapids / Eastern Iowa Airport (CID)'''<br />
which is about 20 minutes from the hotel. <br />
<br />
===Airport Shuttle Services===<br />
The easiest way to get from the airport to<br />
Iowa City is via one of the shuttle services: <br />
* [http://www.crshuttle.com/ Airport Shuttle Service] (Phone: 1-800-725-8460)<br />
* [http://www.limosbyexpress.com/ Airport Express] (Phone: 319-626-5466)<br />
Both are the same price and easiest to book before travel. The cost is roughly $60 round trip.<br />
<br />
===Rental Cars===<br />
Rental cars are also available from the Airport. The following companies have desks at the airport<br />
* Avis<br />
** [http://www.avis.com/ Website] <br />
** Toll-Free Phone : 1-800-331-1212<br />
** Local Phone : (319) 366-6418<br />
* Hertz<br />
** [http://www.hertz.com/ Website] <br />
**Toll-Free Phone : 1-800-654-3131<br />
**Local Phone : (319) 365-9184<br />
* National and Alamo<br />
** [http://www.nationalcar.com/ Website]<br />
**Toll-Free Phone : 1-888-826-6890<br />
**Local Phone : (319) 363-0249<br />
*Enterprise<br />
**[http://www.enterprise.com/car_rental/home.do Website]<br />
**Local Phone : (319) 366-5522<br />
<br />
<br />
If you have any questions regarding travel, feel free to contact Joe Ekdahl either via e-mail(joe-ekdahl@uiowa.edu) or phone (319-384-3026).<br />
<br />
== Hotel Information ==<br />
We reserved a block of hotel rooms at Hotel Vetro at a rate of $139. The group code to get this rate is '''ITK-V4'''. These rooms will be held at this rate until October 22.<br />
* '''[http://www.hotelvetro.com/ Hotel Vetro]'''<br />
**Phone: 800-592-0355<br />
**Address: 201 South Linn Street, Iowa City, Iowa 52240<br />
<br />
<br />
Other hotels that are close to the conference site, University of Iowa, and downtown include:<br />
*'''[http://www.Sheraton.com/IowaCity Sheraton hotel]'''<br />
**Phone: 319-337-4058<br />
**Address: 210 South Dubuque St, Iowa City, IA 52240<br />
*'''[http://imu.uiowa.edu/iowahouse/ Iowa House Hotel]'''<br />
**Phone: 319-335-3513<br />
**Address: 125 North Madison St, Iowa City, IA 52242<br />
<br />
== Registration Information ==<br />
[https://www.continuetolearn.uiowa.edu/UIConferences/ Registration is now open for the ITKv4 Fall Meeting.] <br />
# Goto the '''ITK-v4 Fall Design Meeting''' <br />
# Select the '''Register Now''' link<br />
# Select the '''Create an Account'''<br />
This will take you through the registration process. There will be $125 fee for registration. We are also planning on a dinner Monday dinner that is optional and will be $10.<br />
<br />
== Meeting Room ==<br />
We will be meeting in the '''Plaza 1''' room.<br />
<br />
== Meeting Agenda ==<br />
<br />
<br />
<span style="color:#FF0000"> '''THE AGENDA HAS BEEN MODIFIED'''</span><br />
<br />
=== Essential Topics ===<br />
<br />
* '''Modularization''' (Bill Hoffman)<br />
** Testing strategy<br />
* '''Simple ITK''' (Dan Blezek, Bill Hoffman)<br />
** Its Wrapping (Alex Gouaillard, Gaetan Lehmann)<br />
* '''DICOM''' (Dan Blezek, Mathieu Malaterre)<br />
* '''GPU Acceleration''' (Won Ki)<br />
** Pipeline Refactoring (Jim Miller)<br />
<br />
===Monday November 8===<br />
<br />
==== Morning ====<br />
* 8:00am - 8:30am '''Breakfast'''<br />
* 8:30am - 9:00am '''Welcome''' (Terry Yoo)<br />
* 9:00am - 9:30am '''Status of the Toolkit''' (Hans Johnson, ISC President)<br />
* 9:30am - 10:00am '''Integration Plan - Software Process''' (Luis Ibanez, Bill Hoffman, Marcus Hanwell)<br />
** Coordinating Topic Branches<br />
** Coordinating Code Reviews<br />
* 10:00am - 10:30am '''Break'''<br />
* 10:30am - 12:00pm '''Modularization''' (Bill Hoffman)<br />
** Prototype (Bill Hoffman)<br />
** Dependencies (Bill Hoffman)<br />
** Suggested Partition (Xiaoxiao Liu, Luis Ibanez)<br />
** Documentation of independent modules (Luis Ibanez)<br />
<br />
==== Afternoon ====<br />
<br />
* 1:00pm - 3:00pm '''Simple ITK''' (Dan Blezek, Bill Hoffman) ([[Media:SimpleITK_Status-2010-11-10.pdf|Slides]])<br />
** Review Survey (Jesus Caban - [[Media:simpleITK-R2.pdf|Slides]], Gabe Hart - [[Media:SimpleITKSurveyReport.pdf|Slides]])<br />
** Design Discussion (Dan Blezek, Bill Hoffman)<br />
** Its Wrapping (Alex Gouaillard, Bill Hoffman)<br />
* 3:00pm - 3:30pm '''Break'''<br />
* 3:30pm - 5:30pm '''GPU Acceleration''' (Won-Ki)<br />
** Design Plan<br />
** Pipeline Refactoring (Jim Miller)<br />
*** How other classes need to be modified<br />
<br />
==== Dinner ====<br />
<br />
* 6:30pm - 1206 Plaza Towers<br />
<br />
===Tuesday November 9===<br />
<br />
==== Morning ====<br />
<br />
* 8:00am - 8:30am '''Breakfast'''<br />
* 8:30am - 9:30am '''Wrapping''' (Gaetan Lehmann, Alex Gouaillard)<br />
* 9:30am - 10:30am '''DICOM''' (Dan Blezek, Mathieu Malaterre) ([[Media:DICOMStatusITKv4.pdf|Slides]])<br />
* 10:30am - 11:00am '''Break'''<br />
* 11:00am - 12:00am '''Spatial Objects''' (Sean Megason, Arnaud Gelas, Luis Ibanez)<br />
<br />
==== Afternoon ====<br />
<br />
* 12:00pm-1:00pm '''Lunch'''<br />
<br />
* 1:00pm - 1:45pm '''Filters Refactoring''' (Brad Lowekamp)<br />
* 1:45pm - 2:30pm '''Registration Framework Refactoring''' (Brian Avants)<br />
* 2:30pm - 3:15pm '''Level Sets Framework Refactoring''' (Arnaud Gelas)<br />
<br />
* 3:15pm - 3:45pm '''Break'''<br />
<br />
* 3:45pm - 4:30pm '''FEM Refactoring''' (Vince Magnotta)<br />
* 4:30pm - 5:15pm '''Video / Time series support''' (Patrick Reynolds, Patrick Cheng)<br />
<br />
===Wednesday November 10===<br />
<br />
==== Morning ====<br />
<br />
* 8:00am - 8:30am '''Breakfast'''<br />
* 8:30am - 10:30 '''Git/Gerrit Workshop''' (Marcus Hanwell)<br />
** Hands-on practical exercises on Git/Gerrit<br />
** Discussion about software process and improvements<br />
* 10:30am - 11:00am '''Break'''<br />
* 11:00am - 11:30am '''Migration Guide''' (Gabe Hart, Hans Johnson)<br />
** Online System<br />
** Workflow ([[Media:MigrationGuideFull.pdf|Slides]])<br />
*** User Driven Perspective<br />
*** Developer Workflow<br />
*** Automation<br />
* 11:30am - 12:00pm '''Testing Framework''' CDash@Home (Zach Mullen)<br />
** '''Testing Data''' (Git / MIDAS) (Zach Mullen,Patrick Reynolds)<br />
<br />
* 12-1pm '''Lunch'''<br />
<br />
==== Afternoon ====<br />
<br />
* 1:00pm - 1:30pm '''Doxygen''' crowdsourcing fixes (Luis Ibanez, Arnaud Gelas)<br />
* 1:30pm - 2:00pm '''Software Guide Update''' (Luis Ibanez)<br />
** New generation of Examples<br />
** Use the Wiki like VTK ?<br />
* 2pm Adjurn<br />
<br />
==== Unallocated Topics ====<br />
<br />
* 1:00pm - 1:30pm Windows 64 (Luis, Hans)<br />
** Integer types<br />
** stdint.h, c99 lib<br />
** size_t<br />
<br />
** Partition & assignment of tasks to groups proportional to funding.<br />
* 10:00am - 10:30am Coding Style (KWStyle/Gerrit) (Brad Lowekamp, Hans Johnson)</div>Mathieu