ITK/Release 4 Planning: Difference between revisions

From KitwarePublic
< ITK
Jump to navigationJump to search
No edit summary
Line 31: Line 31:
== Proper resampling/consistency in IndexToPhysicalPoint, ContinuousIndexToPhysicalPoint, Point* ==
== Proper resampling/consistency in IndexToPhysicalPoint, ContinuousIndexToPhysicalPoint, Point* ==
* Refactor all the interpolators
* Refactor all the interpolators
** See [[Proposals:Refactoring Index Point Coordinate System]]
** See [http://www.itk.org/Bug/view.php?id=6558 ITK Bug 6558]

Revision as of 07:48, 7 August 2008

Wish List

Oriented Images

  • Support ND oriented images
    • Using anything other than 3D images won't compile
  • 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
    • Spatial Objects
    • Meshes

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

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.

Proper resampling/consistency in IndexToPhysicalPoint, ContinuousIndexToPhysicalPoint, Point*