Difference between revisions of "Documentation/4.2/Developers/Tutorials/PortingCLIToITKv4"
(Created page with ' # "My filter doesn't run". The API to ThreadedGenerateData() changed in ITKv4 (use of a defined type ThreadIdType). This can result in your implementation of ThreadedGenerateD…') |
(Prepend documentation/versioncheck template. See http://na-mic.org/Mantis/view.php?id=2887) |
||
| (12 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
| + | <noinclude>{{documentation/versioncheck}}</noinclude> | ||
| + | == Introduction == | ||
| − | + | Many CLIs are essentially ITK programs. Porting to ITKv4 usually just involves recompilation. | |
| − | + | ||
| + | ITKv4 is the result of an effort to retool ITK after 10 years of continuous development. Preserving APIs was concern. But there were circumstances where the APIs changed or were eliminated. Porting CLIs that utilized these components will require a bit more work. The [http://itk.org/migrationv4/index.php?action=news&newsid=2&newslang=en ITKv4 Migration Guide] is a valuable reference to track known issues and the suggested remediations. | ||
| + | |||
| + | == ITKv4 Resources == | ||
| + | |||
| + | [http://www.itk.org/Wiki/ITK/Getting_Started Getting started with ITKv4] - has general information on ITKv4 | ||
| + | |||
| + | [http://itk.org/migrationv4/index.php?action=news&newsid=2&newslang=en ITKv4 Migration Guide] - has a migration guide that explains API changes. | ||
| + | |||
| + | == Known issues in porting CLIs == | ||
| + | |||
| + | === My filter doesn't run. === | ||
| + | The API to ThreadedGenerateData() changed in ITKv4. | ||
| + | |||
| + | ITKv3 version of ThreadedGenerateData() | ||
| + | |||
| + | virtual void ThreadedGenerateData(const OutputImageRegionType& outputRegionForThread, int threadId ); | ||
| + | |||
| + | ITKv4 version of ThreadedGenerateData() | ||
| + | |||
| + | virtual void ThreadedGenerateData(const OutputImageRegionType & outputRegionForThread, ThreadIdType threadId); | ||
| + | |||
| + | Note the use of ThreadIdType. | ||
| + | |||
| + | If you have written a mulit-threaded filter, you need to update the signature of the method. Your ITKv3 version of the method may be defining a new function instead of overriding the version called by the pipeline. ITKv4 attempts to emit a run-time exception but there are circumstances where the exception cannot be thrown. Specifically, if your filter is a subclass of a filter that does implement ThreadedGenerateData(), then ITKv4's attempt to inform of the issue is circumvented. | ||
| + | |||
| + | If your filter is not executing in ITKv4, check the declaration of ThreadedGenerateData(). | ||
| + | |||
| + | === DICOM/GDCM === | ||
| + | ITKv4 updated the version of GDM used to version 2. GDCM version 2 has many API changes from version 1. If your CLI used GDCM directly, you will need to port your CLI to ITKv4. If you used ITK abstractions to access DICOM, then the changes to GDCM will not affect your CLI. | ||
| + | |||
| + | === Differences in test baselines for algorithms that use RecursiveGaussian filters === | ||
| + | |||
| + | A correction was made to how the sigma/spacing/scales are computed for the RecursiveGaussian filters. For more details, see [http://itk.org/gitweb?p=ITK.git;a=commit;h=b54b8f664c377310c2ff8b3c4e6f704c819490f6 the commit]. | ||
Latest revision as of 07:44, 14 June 2013
Home < Documentation < 4.2 < Developers < Tutorials < PortingCLIToITKv4
|
For the latest Slicer documentation, visit the read-the-docs. |
Contents
Introduction
Many CLIs are essentially ITK programs. Porting to ITKv4 usually just involves recompilation.
ITKv4 is the result of an effort to retool ITK after 10 years of continuous development. Preserving APIs was concern. But there were circumstances where the APIs changed or were eliminated. Porting CLIs that utilized these components will require a bit more work. The ITKv4 Migration Guide is a valuable reference to track known issues and the suggested remediations.
ITKv4 Resources
Getting started with ITKv4 - has general information on ITKv4
ITKv4 Migration Guide - has a migration guide that explains API changes.
Known issues in porting CLIs
My filter doesn't run.
The API to ThreadedGenerateData() changed in ITKv4.
ITKv3 version of ThreadedGenerateData()
virtual void ThreadedGenerateData(const OutputImageRegionType& outputRegionForThread, int threadId );
ITKv4 version of ThreadedGenerateData()
virtual void ThreadedGenerateData(const OutputImageRegionType & outputRegionForThread, ThreadIdType threadId);
Note the use of ThreadIdType.
If you have written a mulit-threaded filter, you need to update the signature of the method. Your ITKv3 version of the method may be defining a new function instead of overriding the version called by the pipeline. ITKv4 attempts to emit a run-time exception but there are circumstances where the exception cannot be thrown. Specifically, if your filter is a subclass of a filter that does implement ThreadedGenerateData(), then ITKv4's attempt to inform of the issue is circumvented.
If your filter is not executing in ITKv4, check the declaration of ThreadedGenerateData().
DICOM/GDCM
ITKv4 updated the version of GDM used to version 2. GDCM version 2 has many API changes from version 1. If your CLI used GDCM directly, you will need to port your CLI to ITKv4. If you used ITK abstractions to access DICOM, then the changes to GDCM will not affect your CLI.
Differences in test baselines for algorithms that use RecursiveGaussian filters
A correction was made to how the sigma/spacing/scales are computed for the RecursiveGaussian filters. For more details, see the commit.
