|
|
| (101 intermediate revisions by 22 users not shown) |
| Line 1: |
Line 1: |
| = Wish List = | | = ITK Version 4 = |
| | This work is supported by ARRA funding from the NLM. The [http://visual.nlm.nih.gov/itk/itk2010/agenda.html kick-off meeting] for this project took place from June 28-July 2 2010 in Bethesda. A beta version of the software will be available by the end of March 2011. Bug fixes will continue to be contributed to the ITK version 3 code. |
| | == Download == |
| | |
| | * [[ITK_Release_4/Download|Download]] |
| | |
| | == Release Notes == |
| | |
| | * [[ITK_Release_4/Migration Plan/Release Notes|Release Notes]] |
| | |
| | == LICENSE Change == |
| | |
| | Starting with ITKv4-Alpha-01, the ITK toolkit is distributed under the Apache 2.0 License. |
| | |
| | More details here: |
| | |
| | * [[ITK_Release_4/Licensing|Licensing]] |
| | |
| | == Revision Control == |
| | |
| | * Adopt a modern revision control system |
| | ** Move from cvs to [http://git-scm.com git] for distributed source code management |
| | ** [[ITK/Git|ITK Git Instructions]] |
| | |
| | == Code Review == |
| | |
| | * Adopt a code review system |
| | ** [http://review.source.kitware.com/p/ITK ITK Gerrit] |
| | ** Powered by [http://code.google.com/p/gerrit/ Gerrit Code Review] |
| | |
| | == Modern C++ == |
| | |
| | * [[ITK_Release_4/Modern C++|Modern C++]] |
| | |
| | * Take advantage of advances in C++ |
| | ** Target popular compilers that are compatible with the C++98 and/or C++03 standard (http://en.wikipedia.org/wiki/C%2B%2B03#Language_standard). |
| | ** Specifically remove support for Visual Studio prior to 7.1 (e.g., 6 and 7.0), Borland version 5.5, Sun Studio compilers prior to 5.9, IRIX compilers, MWORKS compilers, cygwin 1.5 (newer versions may work, but are not being targeted), and gcc prior to 3.4 |
| | |
| | == Wrapping == |
| | |
| | * Improved ITK Wrapping at the class level (WrapITK) |
| | ** [[ITK_Release_4/Wrapping|Wrapping]] |
| | ** Particularly for Python 2.x, Python 3, Java and C# |
| | |
| | == Simplify == |
| | |
| | * Addition of [[ITK_Release_4/SimpleITK|Simple ITK Layer]] |
| | |
| | == Modularize == |
| | |
| | * Refactor for [[ITK_Release_4/Modularization|Modularity]] |
| | ** ITKCore, ITKRegistrationModule, and Optional Modules |
| | |
| | == Testing Crowdsourcing == |
| | |
| | * [[ITK_Release_4/Testing_Crowdsourcing|Testing Crowdsourcing]] |
| | |
| | == Improve Software Process == |
| | |
| | * Enhanced project management tools and software processes |
| | |
| | === Data Management === |
| | |
| | * Better management for [[ITK_Release_4/Testing Data|Testing Data]] |
| | * Data Collection [[ITK_Release_4/Data Collection|MIDAS]] |
| | |
| | === Distributed Testing (cdash@home) === |
| | |
| | * Testing On Demand [[ITK_Release_4/Testing On Demand|cdash@home]] |
| | |
| | === Testing Framework === |
| | |
| | * [[ITK_Release_4/UnitTesting|New unit testing framework]] based on [http://code.google.com/p/googletest/ Google Test] |
| | ** Particularly to support module development, testing, and maintenance |
| | |
| | === Coding Style === |
| | |
| | * [[ITK_Release_4/Coding Style|Coding Style]] |
| | |
| | == Revise == |
| | |
| | === FEM === |
| | |
| | * [[Refactoring itk::FEM framework - V4]] |
| | |
| | === Level Sets === |
| | |
| | * [[Refactoring Level-Set framework - V4]] |
| | |
| | === DICOM === |
| | |
| | * Improved DICOM support |
| | ** [[ITK_Release_4/DICOM|DICOM]] |
| | ** Including communications with PACS |
| | ** Support Streaming interface |
| | ** Add filter to support Siemens MOSAIC images |
| | ** Information Object Definition verification |
| | |
| | === Image Registration Framework === |
| | |
| | * [[ITK_Release_4/Enhancing Image Registration Framework|Enhancing Image Registration Framework]] |
| | |
| | === Spatial Objects === |
|
| |
|
| == Oriented Images ==
| | * [[ITK_Release_4/SpatialObjects | Spatial Object Refactoring project page]] |
| * 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
| | === Global Code Review === |
| ** Meshes
| |
| * Suggestions
| |
| ** [[ITK_Release_4.0_Orientation_by_Kent]]
| |
| ** [[ITK_Release_4.0_Orientation_by_Torsten]]
| |
| ** [[ITK_Release_4.0_Orientation_by_Michael]]
| |
| ** [http://wiki.na-mic.org/Wiki/index.php/Complex_Image_Set Some notes on complex image acquisitions by Steve and Greg]
| |
|
| |
|
| == Image Representation ==
| | * [[ITK_Release_4/Global_Code_Review | Global Code Review]] |
| * 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 considered redundant with correct use of image regions but is not since GetLargestPossibleRegion should correspond to the image width and not its stride
| |
| * Drop the itk::Image::GetBufferPointer() method
| |
| ** This method has been many time described as a problem to implement new image layouts.
| |
| ** As expressed above, we need however to be able to use the memory held by ITK images within other libraries. This could potentially be done by making itk::Image be only a base class that has no knowledge of the memory layout and by implementing different image subclasses.
| |
| * Consider replacing ImportImageContainer by std::vector or using std::vector to implement it
| |
| ** This would give STL iterators that operate on the whole image literally for free and make it easy to use a lot of algorithms implemented in STL and BOOST
| |
|
| |
|
| == Statistics == | | == Accelerate == |
| * Complete statistics refactoring (see NAMIC sandbox)
| |
|
| |
|
| == FEM Meshes == | | === GPU === |
| * Consolidate FEM Meshes and ITK Meshes
| |
|
| |
|
| == Backward compatibility and cleanup ==
| |
| * Clean-up CMake Vars ==
| |
| ** See proposal [[ITK_CMake_Style|HERE]].
| |
| * Remove Deprecated Features
| |
| ** Functions that have been deprecated (and appropriately marked as such) for more than 3 releases should be removed.
| |
| * 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.
| |
| * Supported compilers
| |
| ** We should reconsider the list of supported compilers. ITK 4.0 might be a good time to drop, for example, MSVC 6.0 that only implements a subset of modern C++.
| |
| * Define a transition period during which developments need not be backward compatible
| |
| ** Such a period could be defined in terms of a number of "beta" releases
| |
|
| |
|
| == Image Registration ==
| | * [[ITK_Release_4/GPU Acceleration|GPU Acceleration - V4]] |
| * Set up the infrastructure to ease the implementation of modern optimization schemes for image registration | | ** With support for distributed computing in the future |
| ** 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 [http://public.kitware.com/Bug/bug_view_page.php?bug_id=3205 Bug 3205]
| |
| * Modify transforms to support a consistent API across transform types | |
| * Modify order of parameters to be consistent across transforms.
| |
| * Modify the base class for optimizers to support key optimizer API calls such as SetMaximize and SetNumberOfIterations or SetMaximumIteration
| |
|
| |
|
| == Composite Transform ==
| | * [[GPU_Acceleration_-_V4|GPU Acceleration - V4 (deprecated link)]] |
| * 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
| |
| * See Insight Journal Papers:
| |
| ** http://www.insight-journal.org/browse/publication/143
| |
| ** http://www.insight-journal.org/browse/publication/91
| |
|
| |
|
| == 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?''
| | === Numerical Libraries === |
|
| |
|
| * 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. | | * [[ITK_Release_4/Refactor Numerical Libraries|Refactor Numerical Libraries]] |
| ** 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 [[Proposals:Dropping_Support_for_Visual_Studio_6.0 |dropping support for VC 6.0]]).
| | == Release schedules == |
|
| |
|
| * Discuss whether to move to TR1. Portability might be achieved through the [http://www.boost.org/doc/libs/1_39_0/doc/html/boost_tr1.html boost TR1 wrapper library]. | | * [[ITK Release 4/ReleaseSchedules|Release Schedules]] |
|
| |
|
| * SmartPointer< T > should be implicitly convertible to SmartPointer< U > whenever T* can be implicitly converted to U*.
| | = The Team = |
| ** This might be achieved by using TR1 smart pointers instead of the ITK 3.0 smart pointer implementation. It might however then be more complex to use the default factory mechanism as with [http://www.itk.org/cgi-bin/viewcvs.cgi/Testing/Code/Common/itkFactoryTestLib.cxx?root=Insight&view=markup itkFactoryTestLib.cxx] and [http://www.itk.org/cgi-bin/viewcvs.cgi/Testing/Code/Common/itkObjectFactoryTest2.cxx?root=Insight&view=markup itkObjectFactoryTest2].
| |
|
| |
|
| == Proper resampling/consistency in IndexToPhysicalPoint, ContinuousIndexToPhysicalPoint, Point* ==
| | [[ITK_Release_4/The Team|The Team]] |
| * Refactor all the interpolators
| |
| ** See [[Proposals:Refactoring Index Point Coordinate System]]
| |
| ** See [http://www.itk.org/Bug/view.php?id=6558 ITK Bug 6558]
| |
| ** Fix bug 0005335 - transform initializer computes geometric center incorrectly
| |
|
| |
|
| == Deformable Organisms == | | = Wish List = |
|
| |
|
| * Move the framework from the IJ paper:
| | [[ITK_Release_4/Wish List|Wish List]] |
| ** http://www.insight-journal.org/browse/publication/116
| |
| ** http://hdl.handle.net/1926/228
| |
|
| |
|
| == Make as much filters as possible able to run in place == | | = Migration Plan (Developers) = |
| 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 ==
| | [[ITK_Release_4/Migration Plan|Migration Plan]] |
| 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.
| |
|
| |
|
| == Replace the current implementation of Marching Cubes and add a 4D version == | | = Migration Guide (for Users) = |
|
| |
|
| The itkBinaryMask3DMeshSource filter currently provides the closest functionality to the Marching Cubes algorithm in ITK. However the code of this filter has to be rewritten in order to match the quality standards of the rest of the toolkit. As part of this rewrite we should provide implementations for 2D (marching squares), 3D marching cubes and a 4D version that could be used for segmenting 3D+time datasets.
| | [[ITK_Release_4/Users Migration Guide|Users Migration Guide]] |
|
| |
|
| == Normalize the Binary/Label/Grayscale usage in code and in the class names == | | = Software Guide (Update) = |
| [[Proposals:Consistent_usage_of_label_and_binary_images]]
| |
|
| |
|
| == Use an image template parameter in the complex related filters ==
| | [[ITK_Release_4/Software Guide Update|Software Guide Update]] |
|
| |
|
| == Testing framework == | | = A2D2 Projects = |
| Add a decent testing framework e.g. based on BOOST.test or googletest; see [http://www.itk.org/mailman/private/insight-developers/2008-December/011421.html discussion on the itk-developers]
| |
|
| |
|
| == Code Revision Control ==
| | [[ITK_Release_4/A2D2_Projects|A2D2 Projects]] |
|
| |
|
| * Migrate to Subversion
| | = New Fields = |
|
| |
|
| == Arbitrary precision type ==
| | ITKv4 will provide improved support for |
|
| |
|
| for reconstruction and geometry processing, you might want to use arbitrary precision type. Boost has one, GMP is now LGPL.
| | * [[ITK_Release_4/Video|Video]] |
| That also could be a feature of the numerical library, and then the solvers could directly use this, if needed.
| | * [[ITK_Release_4/Microscopy|Microscopy]] |
| | * [[ITK_Release_4/Remote Sensing|Remote Sensing]] |
|
| |
|
| inspired from exct and filtered kernels in CGAL
| | = Discussion Points = |
|
| |
|
| == Exact geometrical test (point in circle => delaunay ==
| | [[ITK_Release_4/Discussion Points|Discussion Points]] |
|
| |
|
| If we cannot go for arbitrary precision types, in some case it is sufficient to support some operations to have exact geometrical predicates. This is mandatory for a robust delaunay implementation. The implementation for the point-in-circle predicate which is necessary and sufficient for exact 2D delaunay, is public domain.
| | = Outreach = |
|
| |
|
| Note that abitrary precision would allow for any exact geometrical predicates.
| | [[ITK_Release_4/Outreach|Outreach]] |
|
| |
|
| == 3rd Party Libraries == | | = New Code Contribution Process = |
|
| |
|
| * Out dated libraries
| | [[ITK_Release_4/New_Code_Contribution_Process|New Code Contribution Process]] |
| ** Many 3rd party libraries (ex libTIFF) are years out of date. One possibility is to update them to their newest official release. Another is to remove them and require developers to use their own version (i.e. USE_SYSTEM_TIFF).
| |
| * Linear algebra / numerical analysis package
| |
| ** The current linear algebra package used by ITK is VNL. It's performance and robustness is not very good, it is not actively maintained and cannot use a vendor back-end such as MKL. We should therefore discuss the alternative possibilities. Below is a list of potential linear algebra libraries:
| |
| ** Boost [http://www.boost.org/doc/libs/release/libs/numeric uBLAS] with [http://mathema.tician.de/node/391 bindings] for LAPACK
| |
| ** [http://www.mcs.anl.gov/petsc/petsc-as/ PETSc]
| |
| ** [http://home.gna.org/getfem/gmm_intro.html GMM++]
| |
| ** [http://www.cs.uiowa.edu/~dstewart/meschach/ Meschach]
| |
| ** [http://www.osl.iu.edu/research/mtl/ MTL] or [http://www.osl.iu.edu/research/mtl/mtl4/ MTL4]
| |
| ** Unify with the underlying routines of Numpy/Scipy [http://www.scipy.org]
| |
