ITK/Release 4 Planning

Wish List

Oriented Images

• Support ND image in N+1 dimension
  • 2D image can have an origin specified in 3D, thus a series of 2D images is not always Z-aligned
• All images are oriented - remove concept of an un-oriented image
• Check use of orientation throughout ITK
• Support re-orientation of ND oriented images
  • Using anything other than 3D images won't compile with itkOrientedImageFilter

• • Spatial Objects
  • Meshes
• Suggestions
  • ITK_Release_4.0_Orientation_by_Kent
  • ITK_Release_4.0_Orientation_by_Torsten
  • ITK_Release_4.0_Orientation_by_Michael

Image Representation

• Allow the use of strides that are not equal to the image width
  • Would ease the collaboration of ITK with opencv
  • Would allow the use of sse operations
  • Might be redundant with correct use of image regions

Statistics

• Complete statistics refactoring (see NAMIC sandbox)

FEM Meshes

• Consolidate FEM Meshes and ITK Meshes

Clean-up CMake Vars

• See proposal HERE.

Remove Deprecated Features

• Functions that have been deprecated (and appropriately marked as such) for more than 3 releases should be removed.

Image Registration

• Set up the infrastructure to ease the implementation of modern optimization schemes for image registration
  • Requires Hessian or pseudo-Hessians of the cost function
  • Requires several types of update rules (additive, compositional, inverse compositional, etc.)
  • References: "Lucas-Kanade 20 years on" by Baker et al.; "Homography-based 2D Visual Tracking and Servoing" by Benhimane and Malis, "Groupwise Geometric and Photometric Direct Image Registration" by Bartoli; etc.
• Clean up the use of parameter scaling in the optimizers
  • One possibility would be that the optimizers only perform unscaled minimization. It would then be up to a cost function wrapper to do the rescaling and potentially return the opposite of the cost function. This is similar to how vnl optimizers are used in ITK
• Optimizers should return the best visited value
  • See Bug 3205
• Modify transforms to support a consistent API across transform types
• Modify order of parameters to be consistent across transforms.

Architecture

• Implement a pure virtual base class for each API to support instantiation of templated filters at run-time with different dimensions.

• Add interfaces to the algorithms that turn incomplete initialization into compile time error for "linear" environments or enable some kind of validation instead of throwing an exception in "dynamic" environments. In both cases, the entry points to doing real work of the algorithm should then be guarded by assertions regarding the required parameters, not exceptions - since ending up there without proper initialization would always be a programming error.
  • As a "linear" environments I define an implementations where the parameters and the input to an algorithm are completely determined by the program. In this case, an error in initialization (by missing a SetXXX method) usually is a programming error. Adding an initialization method or constructor that takes all required parameters would enable the developer to move this error from run-time to compile-time.
  • As a "dynamic" environments I imagine e.g. a GUI program, where the user can set the parameters to an algorithm dynamically. Here, a missing SetXXX is not a programming error, but a user error. However, since more than one parameter might be missing, exceptions are not a good way to report the problem. Instead, it should be possible to call some validation function that reports all the missing parameters to the user.

• Allow partial template specialization, (which would imply dropping support for VC 6.0).

Proper resampling/consistency in IndexToPhysicalPoint, ContinuousIndexToPhysicalPoint, Point*

• Refactor all the interpolators
  • See Proposals:Refactoring Index Point Coordinate System
  • See ITK Bug 6558
  • Fix bug 0005335 - transform initializer computes geometric center incorrectly

Composite Transform

• Define a composite transform which can contain any number of transforms, composed.
• Only expose the parameters of the last transform for optimization (default)
• Used in multivariate atlas formation (DTI reg with T1 reg with atlas)
• Remove all of the Centered transforms
• Modify the base class for optimizers to support key optimizer API calls such as SetMaximize and SetNumberOfIterations or SetMaximumIteration