ITK/Release 4 Planning

From KitwarePublic
Jump to navigationJump to search

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

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

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
  • 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.

Can you explain a bit more?

  • 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.

Proper resampling/consistency in IndexToPhysicalPoint, ContinuousIndexToPhysicalPoint, Point*

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

Make as much filters as possible able to run in place

In place computation is a great way to avoid running out of memory when updating a pipeline. We should review all the existing filters to find the filters which could be implemented that way, and use InPlaceImageFilter has their base class. Also, a global setting to control the default in place/not in place behavior would be great.

Make the boundary conditions usage consistent across the toolkit

At the moment, some filters let the user provide a boundary condition, some don't but use one internally, and some just don't use them at all. This should be consistent in the toolkit, and if it make sense, it should be changeable by the user. Boundary conditions also make some filters hard to enhance with much more efficient algorithms - see BoxMeanImageFilter for an example.

Set the default options values to provide the highest result quality

Some filters have default options values to produce quick transforms rather than high quality transforms. This is the case for the distance map filters, which produced squared results and don't use image spacing by default. This behavior is desirable in some conditions, but shouldn't be the default one.

Normalize the Binary/Label/Grayscale usage in code and in the class names

Proposals:Consistent_usage_of_label_and_binary_images

Drop the itk::Image::GetBufferPointer() method

This method has been many time described as a problem to implement new image layouts.

Use an image template parameter in the complex related filters

Testing framework

Add a decent testing framework e.g. based on BOOST.test or googletest; see discussion on the itk-developers

= Code Revision Control

  • Migrate to subversion
Retrieved from "https://public.kitware.com/Wiki/index.php?title=ITK/Release_4_Planning&oldid=14889"