https://public.kitware.com/Wiki/api.php?action=feedcontributions&user=Stnava&feedformat=atomKitwarePublic - User contributions [en]2024-03-29T09:44:49ZUser contributionsMediaWiki 1.38.6https://public.kitware.com/Wiki/index.php?title=ITK/Release_4/Why_Switch_to_ITKv4&diff=44633ITK/Release 4/Why Switch to ITKv42011-12-21T18:13:29Z<p>Stnava: /* New Registration Framework */</p>
<hr />
<div>=== Modularization ===<br />
<br />
* '''Easier to find what you are looking for.'''<br />
* '''Easier to understand how to use the toolkit.'''<br />
* Build only the parts of the toolkit that you need.<br />
* Extend bridging of the toolkit to other toolkit and libraries.<br />
* Makes it '''easy to associate''' and build auxiliary '''community projects''' with an [[ITK_Release_4/Modularization/Add an external module (external module)| External module]].<br />
* Find the quality control per module by performing code coverage tests per module.<br />
<br />
=== New Finite Element Registration Framework ===<br />
<br />
* Better conformity with the rest of the toolkit<br />
* Improved IO of objects and results<br />
<br />
=== New Registration Framework ===<br />
<br />
*New unified and fully multi-threaded optimization and registration framework<br />
*Unified framework supports sparse and dense metric computation<br />
*Unified framework supports low and high dimensional mapping<br />
*Improved multi-threaded metrics for rigid, affine and deformable registration<br />
*New metrics support sparse or dense sampling<br />
*Metrics for landmark or label guided registration<br />
*Automatic parameter scale estimation for registration<br />
*Automatic step-size selection for gradient-based registration optimizers<br />
*Composite transforms and composite transform optimization<br />
*Displacement field and diffeomorphic velocity field-based transforms<br />
*Better support for multi-threading in optimizers and metrics<br />
*Additional evolutionary optimizers<br />
*Improved B-Spline registration approach available and bug fixes to old framework<br />
*Accurately transform and reorient covariant tensors and vectors<br />
<br />
=== New LevelSets Segmentation Framework ===<br />
<br />
* Powerful, '''modular architecture'''<br />
** Now you, too, can fully understand how level sets are implemented!<br />
** Easy to extend and customize<br />
* Simultaneously evolve multiple level sets on an image<br />
* '''Faster'''<br />
** Limit evolution to a domain<br />
** Three different sparse representations available, Whitaker, Shi, Malcolm<br />
** Design avoids duplication of calculations in many ways<br />
* Easy conversion from BinaryMask or LabelMap to a level set.<br />
<br />
=== SimpleITK ===<br />
<br />
* Easy to use<br />
** [[ITK_Release_4/Why_Switch_to_ITKv4/SimplifiedITK | Illustrations of ITK, WrappedITK, and SimpleITK]]<br />
* Rapid development<br />
* Interactive processing<br />
<br />
=== Software Process ===<br />
<br />
* Fast, distributed, powerful version control: '''Git'''<br />
* Better support for making '''contributions'''<br />
** Low barrier to entry<br />
** Well defined contribution process<br />
** Use powerful tools, Git branches, '''Gerrit reviews'''<br />
** Get code into the toolkit '''quicker'''<br />
** Get '''higher quality''' code in with more reviews and platform testing<br />
* Forget SETI@home, give the aliens a reason to visit by improving ITK with ''CDash@home''!<br />
* Know when/if your bug will be addressed with the scrum process in the JIRA issue tracker<br />
* Flexible management of testing data<br />
<br />
=== WrapITK ===<br />
<br />
* Tight incorporation of the outstanding, formerly third party [http://code.google.com/p/wrapitk WrapITK] project.<br />
* [http://numpy.scipy.org Numpy] integration.<br />
<br />
=== "You can do it!" ===<br />
<br />
* [http://ij.itk.org/itkfaq/ Migration Guide]<br />
* [[ITK/Release_4/Removed_or_renamed_classes|ITKv4 Removed or renamed classes|]]<br />
* The insight-users mailing list is there for you.<br />
* Transition is easier with ITKV3_COMPATIBILITY configuration option.<br />
* Many deprecated classes are still available.<br />
* The list of other improvements and new features are legion, '''don't miss out!'''</div>Stnavahttps://public.kitware.com/Wiki/index.php?title=ITK/Release_4/Why_Switch_to_ITKv4&diff=44632ITK/Release 4/Why Switch to ITKv42011-12-21T18:11:32Z<p>Stnava: /* New Registration Framework */</p>
<hr />
<div>=== Modularization ===<br />
<br />
* '''Easier to find what you are looking for.'''<br />
* '''Easier to understand how to use the toolkit.'''<br />
* Build only the parts of the toolkit that you need.<br />
* Extend bridging of the toolkit to other toolkit and libraries.<br />
* Makes it '''easy to associate''' and build auxiliary '''community projects''' with an [[ITK_Release_4/Modularization/Add an external module (external module)| External module]].<br />
* Find the quality control per module by performing code coverage tests per module.<br />
<br />
=== New Finite Element Registration Framework ===<br />
<br />
* Better conformity with the rest of the toolkit<br />
* Improved IO of objects and results<br />
<br />
=== New Registration Framework ===<br />
<br />
*New unified and fully multi-threaded optimization and registration framework<br />
*Unified framework supports rigid, affine, dense and composite<br />
registration (e.g. Demons registration initialized by affine<br />
transform)<br />
*Improved multi-threaded metrics for rigid, affine and deformable registration<br />
*New metrics support sparse or dense sampling<br />
*Metrics for landmark or label guided registration<br />
*Automatic parameter scale estimation for registration<br />
*Automatic step-size selection for gradient-based registration optimizers<br />
*Composite transforms and composite transform optimization<br />
*Displacement field and diffeomorphic velocity field-based transforms<br />
*Better support for multi-threading in multiple components of<br />
registration and optimization hierarchy<br />
*Additional evolutionary optimizers<br />
*Improved B-Spline registration approach available and bug fixes to old framework<br />
*Accurately transform and reorient covariant tensors and vectors<br />
<br />
=== New LevelSets Segmentation Framework ===<br />
<br />
* Powerful, '''modular architecture'''<br />
** Now you, too, can fully understand how level sets are implemented!<br />
** Easy to extend and customize<br />
* Simultaneously evolve multiple level sets on an image<br />
* '''Faster'''<br />
** Limit evolution to a domain<br />
** Three different sparse representations available, Whitaker, Shi, Malcolm<br />
** Design avoids duplication of calculations in many ways<br />
* Easy conversion from BinaryMask or LabelMap to a level set.<br />
<br />
=== SimpleITK ===<br />
<br />
* Easy to use<br />
** [[ITK_Release_4/Why_Switch_to_ITKv4/SimplifiedITK | Illustrations of ITK, WrappedITK, and SimpleITK]]<br />
* Rapid development<br />
* Interactive processing<br />
<br />
=== Software Process ===<br />
<br />
* Fast, distributed, powerful version control: '''Git'''<br />
* Better support for making '''contributions'''<br />
** Low barrier to entry<br />
** Well defined contribution process<br />
** Use powerful tools, Git branches, '''Gerrit reviews'''<br />
** Get code into the toolkit '''quicker'''<br />
** Get '''higher quality''' code in with more reviews and platform testing<br />
* Forget SETI@home, give the aliens a reason to visit by improving ITK with ''CDash@home''!<br />
* Know when/if your bug will be addressed with the scrum process in the JIRA issue tracker<br />
* Flexible management of testing data<br />
<br />
=== WrapITK ===<br />
<br />
* Tight incorporation of the outstanding, formerly third party [http://code.google.com/p/wrapitk WrapITK] project.<br />
* [http://numpy.scipy.org Numpy] integration.<br />
<br />
=== "You can do it!" ===<br />
<br />
* [http://ij.itk.org/itkfaq/ Migration Guide]<br />
* [[ITK/Release_4/Removed_or_renamed_classes|ITKv4 Removed or renamed classes|]]<br />
* The insight-users mailing list is there for you.<br />
* Transition is easier with ITKV3_COMPATIBILITY configuration option.<br />
* Many deprecated classes are still available.<br />
* The list of other improvements and new features are legion, '''don't miss out!'''</div>Stnavahttps://public.kitware.com/Wiki/index.php?title=ITK/Release_4&diff=43470ITK/Release 42011-09-21T20:50:42Z<p>Stnava: /* Ongoing Efforts */</p>
<hr />
<div>= Overview =<br />
<br />
* [[ITK_Release_4.0]]<br />
<br />
= Dashboard of ITKv4 Efforts =<br />
<br />
== Completed Efforts ==<br />
Defined as having examples, tests, migration guide, and documentation; as well as being accepted through gerrit<br />
<br />
* Modernizing ITK's Software Process<br />
** [[ITK_Release_4/Testing_Data]]<br />
** [[ITK_Release_4/Testing_On_Demand]]<br />
** [[ITK_Release_4/UnitTesting]]<br />
* Managing Contributions<br />
** [[ITK_Release_4/Modularization]]<br />
** [[ITK_Release_4/New_Code_Contribution_Process]]<br />
<br />
== Ongoing Efforts ==<br />
Defined as having completed design with work underway. High likelihood of completion by Dec 31, 2011.<br />
<br />
* [[ITK_Release_4/DICOM]]<br />
* [[ITK_Release_4/Wrapping]]<br />
* [[ITK_Release_4/SimpleITK]]<br />
* [[ITK_Release_4/Refactoring_Level_Set_Framework]]<br />
* [[ITK_Release_4/Migration_Plan]]<br />
* [[ITK_Release_4/Refactor_Numerical_Libraries]]<br />
* [[ITK_Release_4/Why Switch to ITKv4]]<br />
* [[ITK_Release_4/Outreach]]<br />
* [[ITK_Release_4/Refactoring_FEM_Framework]]<br />
* [[ITK_Release_4/Enhancing_Image_Registration_Framework]]<br />
<br />
== Demonstrations/Discussions ==<br />
Defined as low likelihood of completion, e.g., limited to being a concept demonstration by Dec 31, 2011.<br />
<br />
* [[ITK_Release_4/Coding_Style]]<br />
* [[ITK_Release_4/SpatialObjects]]<br />
* [[ITK_Release_4/GPU_Acceleration]]<br />
* [[ITK_Release_4/Global_Code_Review]]<br />
<br />
= A2D2s =<br />
{| border="1"<br />
|- bgcolor="#abcdef"<br />
! A2D2 !! Discussion !! Ongoing !! Committed to Gerrit !! Completed !! Notes<br />
|-<br />
| [[ITK_Release_4/A2D2_Projects|Lesion Sizing Toolkit]] || X || X || X || X ||<br />
|-<br />
| [[ITK_Release_4/A2D2_Projects/SCORE|SCORE]] || X || X || || ||<br />
|-<br />
| [[ITK_Release_4/A2D2_Projects/SCORE++|SCORE++]] || X || X || || ||<br />
|-<br />
| [[ITK_Release_4/A2D2_Projects/Video Bridge|Video Bridge]] || X || X || || || [[ITK_Release_4/Outreach/Conferences/CVPR_2011 | CVPR Demonstration]]<br />
|-<br />
| [[ITK_Release_4/A2D2_Projects/Registration Parameter Tuning |Registration Parameter Tuning]] || X || X || || ||<br />
|-<br />
| [[ITK_Release_4/A2D2_Projects/VideoGrabber |VideoGrabber]] || || || || ||<br />
|-<br />
| [[ITK_Release_4/A2D2_Projects/Deconvolution Algorithms|Deconvolution Algorithms]] || || || || ||<br />
|-<br />
| [[ITK_Release_4/A2D2_Projects/Microstructure for Cancer Studies|Microstructure for Cancer Studies]] || || || || ||<br />
|-<br />
| [[ITK_Release_4/A2D2_Projects/Large Histology Segmentation and Visualization|Large Histology Segmentation and Visualization]] || || || || ||<br />
|-<br />
| [[ITK_Release_4/A2D2_Projects/Physics-Based Non-rigid Registration|3D Real-time Physics-based Non-rigid Registration for Image-guided Neurosurgery]] || || || || ||<br />
|}</div>Stnavahttps://public.kitware.com/Wiki/index.php?title=ITK/Release_4&diff=43469ITK/Release 42011-09-21T20:50:27Z<p>Stnava: /* Demonstrations/Discussions */</p>
<hr />
<div>= Overview =<br />
<br />
* [[ITK_Release_4.0]]<br />
<br />
= Dashboard of ITKv4 Efforts =<br />
<br />
== Completed Efforts ==<br />
Defined as having examples, tests, migration guide, and documentation; as well as being accepted through gerrit<br />
<br />
* Modernizing ITK's Software Process<br />
** [[ITK_Release_4/Testing_Data]]<br />
** [[ITK_Release_4/Testing_On_Demand]]<br />
** [[ITK_Release_4/UnitTesting]]<br />
* Managing Contributions<br />
** [[ITK_Release_4/Modularization]]<br />
** [[ITK_Release_4/New_Code_Contribution_Process]]<br />
<br />
== Ongoing Efforts ==<br />
Defined as having completed design with work underway. High likelihood of completion by Dec 31, 2011.<br />
<br />
* [[ITK_Release_4/DICOM]]<br />
* [[ITK_Release_4/Wrapping]]<br />
* [[ITK_Release_4/SimpleITK]]<br />
* [[ITK_Release_4/Refactoring_Level_Set_Framework]]<br />
* [[ITK_Release_4/Migration_Plan]]<br />
* [[ITK_Release_4/Refactor_Numerical_Libraries]]<br />
* [[ITK_Release_4/Why Switch to ITKv4]]<br />
* [[ITK_Release_4/Outreach]]<br />
* [[ITK_Release_4/Refactoring_FEM_Framework]]<br />
<br />
== Demonstrations/Discussions ==<br />
Defined as low likelihood of completion, e.g., limited to being a concept demonstration by Dec 31, 2011.<br />
<br />
* [[ITK_Release_4/Coding_Style]]<br />
* [[ITK_Release_4/SpatialObjects]]<br />
* [[ITK_Release_4/GPU_Acceleration]]<br />
* [[ITK_Release_4/Global_Code_Review]]<br />
<br />
= A2D2s =<br />
{| border="1"<br />
|- bgcolor="#abcdef"<br />
! A2D2 !! Discussion !! Ongoing !! Committed to Gerrit !! Completed !! Notes<br />
|-<br />
| [[ITK_Release_4/A2D2_Projects|Lesion Sizing Toolkit]] || X || X || X || X ||<br />
|-<br />
| [[ITK_Release_4/A2D2_Projects/SCORE|SCORE]] || X || X || || ||<br />
|-<br />
| [[ITK_Release_4/A2D2_Projects/SCORE++|SCORE++]] || X || X || || ||<br />
|-<br />
| [[ITK_Release_4/A2D2_Projects/Video Bridge|Video Bridge]] || X || X || || || [[ITK_Release_4/Outreach/Conferences/CVPR_2011 | CVPR Demonstration]]<br />
|-<br />
| [[ITK_Release_4/A2D2_Projects/Registration Parameter Tuning |Registration Parameter Tuning]] || X || X || || ||<br />
|-<br />
| [[ITK_Release_4/A2D2_Projects/VideoGrabber |VideoGrabber]] || || || || ||<br />
|-<br />
| [[ITK_Release_4/A2D2_Projects/Deconvolution Algorithms|Deconvolution Algorithms]] || || || || ||<br />
|-<br />
| [[ITK_Release_4/A2D2_Projects/Microstructure for Cancer Studies|Microstructure for Cancer Studies]] || || || || ||<br />
|-<br />
| [[ITK_Release_4/A2D2_Projects/Large Histology Segmentation and Visualization|Large Histology Segmentation and Visualization]] || || || || ||<br />
|-<br />
| [[ITK_Release_4/A2D2_Projects/Physics-Based Non-rigid Registration|3D Real-time Physics-based Non-rigid Registration for Image-guided Neurosurgery]] || || || || ||<br />
|}</div>Stnavahttps://public.kitware.com/Wiki/index.php?title=ITK/Release_4/Migration_Plan/Release_Notes&diff=40138ITK/Release 4/Migration Plan/Release Notes2011-05-25T15:55:16Z<p>Stnava: /* Image Registration Refactoring */</p>
<hr />
<div>__TOC__<br />
<br />
'''Release Notes'''<br />
<br />
This page captures release notes for the intermediate releases of ITKv4<br />
<br />
= ITK 3-20 Git =<br />
<br />
This release is simply a Git tag that is equivalent to the stable release of ITK 3.2<br />
<br />
= ITKv4 Alphas =<br />
<br />
== ITKv4 Alpha-01 ==<br />
<br />
The main changes made in this release are<br />
<br />
=== Removal support for Deprecated Compilers ===<br />
<br />
Code that was intended to provide support for several outdated compilers was removed. The compilers that are no longer supported in ITKv4 are<br />
<br />
* Borland 5.5<br />
* Visual Studio 6.0<br />
* Visual Studio 7.0<br />
* SGI CC compilers<br />
* Sun CC 5.6 <br />
* Metrowerks<br />
<br />
<br />
Note: The minimum version of the Sun CC complier that is supported is '''Version 12''' as described in http://public.kitware.com/Bug/view.php?id=11076<br />
<br />
=== Statistics Framework Updated ===<br />
<br />
The original statistics framework was removed and replaced with the one that was refactored in 2007. <br />
<br />
Details on the refactoring process are available at<br />
<br />
[[Proposals:Refactoring Statistics Framework 2007|Refactoring Statistics Framework 2007]]<br />
<br />
and a guide on how to migrate to the new framework is available at<br />
<br />
[[Proposals:Refactoring Statistics Framework 2007 Migration Users Guide | Migration Users Guide ]]<br />
<br />
=== Consolidated Morphology ===<br />
<br />
The Consolidated Morphology classes that were in the ITK/Code/Review directory were moved into the standard ITK directories.<br />
<br />
These classes were contributed in the Insight Journal paper<br />
<br />
* "Consolidated morphology"<br />
** by Lehmann G., Beare R., INRA<br />
** http://hdl.handle.net/1926/308<br />
** http://www.insight-journal.org/browse/publication/124<br />
<br />
<br />
=== Multi-Threaded Image Registration Metrics Updated ===<br />
<br />
The multi-threaded image registration metrics that were in the Review directory were moved into the standard ITK directories. <br />
<br />
Details about the features of these metrics are available at<br />
<br />
http://www.na-mic.org/Wiki/index.php/ITK_Registration_Optimization<br />
<br />
and has been described in the Insight Journal paper<br />
<br />
"Optimizing ITK’s Registration Methods for Multi-processor, Shared-Memory Systems"<br />
http://hdl.handle.net/1926/566<br />
http://www.insight-journal.org/browse/publication/172<br />
<br />
With this change, the metric <br />
<br />
* Mean Squares<br />
* Mattes Mutual Information<br />
<br />
will now use the number of threads that you assign them. This will be, by default, equal to the number of cores in your computer.<br />
<br />
=== Centered Pixel Consistency Enforced ===<br />
<br />
* The changes that were made to enforce the consistency of pixel coordinates computation are now permanent. <br />
* The code intended for backward compatibility (with the state in which ITK was computing coordinates inconsistently) has been removed.<br />
<br />
=== Remove all Deprecated code ===<br />
<br />
* Source code that was labeled as '''deprecated''' was removed.<br />
<br />
=== Some CMake Options Removed ===<br />
<br />
The following CMake configuration options were removed<br />
<br />
* ITK_USE_REVIEW_STATISTICS<br />
* ITK_USE_OPTIMIZED_REGISTRATION_METHODS<br />
* ITK_USE_CONSOLIDATED_MORPHOLOGY<br />
* ITK_USE_DEPRECATED_LEVELSET_INTERPOLATION<br />
* ITK_USE_CENTERED_PIXEL_COORDINATES_CONSISTENTLY<br />
* ITK_USE_DEPRECATED_FAST_MARCHING<br />
<br />
== ITKv4 Alpha-02 ==<br />
<br />
=== Adopted Uncrusty ===<br />
<br />
The source code was processed using [http://uncrustify.sourceforge.net/ Uncrustify] in order to reformat the coding style according to the following proposal <br />
<br />
http://www.itk.org/Wiki/ITKv4_StyleChangeProposal<br />
<br />
<br />
=== Updated openjpeg ===<br />
<br />
The openjpeg library in the '''ITK/Utilities''' directory was updated to the openjpeg-v2 version of July 2010.<br />
<br />
=== Updated jpeg ===<br />
<br />
* The jpeg library in the '''ITK/Utilities/itkjpeg''' directory was updated to the jpeg version 8b. <br />
** ITK 3.x use to ship a patch 6b (released in 1998) to provide both lossy jpeg and lossless jpeg. <br />
** This library (jpeg 6b) is now within the utilities of gdcm itself.<br />
* This update allows ITK to use system installed ijg and take advantages of the latest updates of this lib.<br />
<br />
* http://www.ijg.org/<br />
<br />
=== Updated to GDCM 2.0 ===<br />
<br />
* GDCM, the library that provides DICOM support in ITK was updated to GDCM 2.0.16<br />
* Release notes of GDCM 2.0.16 can be found at<br />
** http://sourceforge.net/apps/mediawiki/gdcm/index.php?title=GDCM_Release_2.0#GDCM_2.0.16_.282010.2F08.2F18.29<br />
<br />
=== Added JPEG2000ImageIO ===<br />
<br />
An ImageIO class specialized on managing JPEG2000 files was added from the Insight Journal paper<br />
<br />
* "Support for Streaming the JPEG2000 File Format"<br />
* http://hdl.handle.net/10380/3187<br />
* http://www.insight-journal.org/browse/publication/741<br />
<br />
=== Changed the License to Apache 2.0 ===<br />
<br />
* The license was changed from BSD to Apache 2.0<br />
<br />
=== Removed Patented Code ===<br />
<br />
* In order to abide by the terms of the Apache 2.0 license, patented source code was removed.<br />
<br />
=== Moved QuadEdgeMesh out of Review ===<br />
<br />
* The QuadEdgeMesh and associated filters were moved out of the Review directory<br />
<br />
=== CMake ===<br />
<br />
* FLAGS: The flag that controlled TEMPLATE METAPROGRAMMING for LOOP UNROLLING was removed<br />
* Changed all CMakeLists.txt files to use lowercase commands<br />
<br />
=== Statistics Framework ===<br />
<br />
* MeasurementVectorTraits from the statistics package by migrating the GetLength and SetLength functions to NumericTraits.<br />
<br />
== ITKv4 Alpha-03 ==<br />
<br />
* VNL was updated in the Utilities directory.<br />
<br />
== ITKv4 Alpha-04 ==<br />
<br />
* Fixed the problem that prevented Windows 64 bits machines to manage image larger than 4 Gb.<br />
<br />
== ITKv4 Alpha-05 ==<br />
<br />
* Introduced Real Time Stamps<br />
* Introduced GPU support infrastructure<br />
<br />
== ITKv4 Alpha-06 ==<br />
<br />
* Modularization<br />
<br />
== ITKv4 Alpha-07 ==<br />
<br />
* Suppressed Warnings from Third Party libraries<br />
<br />
= ITKv4 Beta =<br />
<br />
* The Release will take place on June 15 2011<br />
<br />
== Modularization ==<br />
<br />
* ITK Has been modularized<br />
** External modules are now supported<br />
<br />
== LevelSet Refactoring ==<br />
<br />
== DICOM Updates ==<br />
<br />
== Image Registration Refactoring ==<br />
The ITK Registration framework is ready for integration with ITKv4. <br />
<br />
* efficient implementation of dense transforms w/composite tx framework<br />
* multithreaded framework with multiresolution optimization<br />
* demons & x-corr metrics, preferably also reworked MI metric (shreyas, with michael's help)<br />
* regularized optimizer (e.g. gaussian smoothing)<br />
* multivariate registration tools<br />
* dti warping & metric<br />
* parameter initializers<br />
* basic composite example<br />
* composite affine example<br />
* composite affine + deformable example<br />
* fix to the regular step gradient descent optimizer<br />
<br />
== FEM Refactoring ==<br />
The ITK FEM framework is ready for integration with ITKv4. <br />
* This will take place the week of June 6. <br />
* The changes to the FEM framework are hosted on [https://github.com/kiranhs/ITKv4FEM-Kiran github]<br />
* Additional testing data for the framework is also hosted on github [https://github.com/vmagnotta/ITKV4FEM-ModularData ITKV4FEM-ModularData]<br />
<br />
<br />
===Solver===<br />
*Derive from '''ProcessObject''' and template over '''dimension'''<br />
**template <unsigned int VDimension = 3> class ITK_EXPORT Solver1 : public ProcessObject<br />
*Remove all I/O from Solver<br />
*Use SetInput() and GetOutput() methods to set the FE problem and to get the deformed mesh<br />
*Update() method will execute the Solver<br />
*Retain the following methods<br />
**SetLinearSystemWrapper()<br />
**GetLinearSystemWrapper()<br />
**GetElementAtPoint()<br />
**GetDeformationEnergy()<br />
**SetTimeStep()<br />
**GetSolution()<br />
<br />
===FEMObject===<br />
A new object type was added, '''itk::fem::FEMObject''', that is used to define the FEM problem. The class derives from '''DataObject''' and is templated over dimension.<br />
<br />
*template <unsigned int VDimension = 3> class ITK_EXPORT FEMObject : public DataObject <br />
*Class Methods<br />
**GetNumberOfDegreesOfFreedom()<br />
**GetNumberOfMultiFreedomConstraints()<br />
**GetNumberOfNodes<br />
**GetNumberOfElements<br />
**GetNumberOfLoads(void)<br />
**GetNumberOfMaterials(void)<br />
**AddNextElement(Element::Pointer e)<br />
**InsertElement(Element::Pointer e, ElementIdentifier index)<br />
**AddNextNode(Node::Pointer e)<br />
**InsertNode(Node::Pointer e, NodeIdentifier index)<br />
**AddNextMaterial(Material::Pointer mat)<br />
**InsertMaterial(Material::Pointer e, MaterialIdentifier index)<br />
**AddNextLoad(Load::Pointer ld)<br />
**InsertLoad(Load::Pointer ld, LoadIdentifier index)<br />
**GetElement(ElementIdentifier index)<br />
**GetElementWithGlobalNumber(int globalNumber)<br />
**GetNode(NodeIdentifier index)<br />
**GetNodeWithGlobalNumber(int globalNumber)<br />
**GetMaterial(MaterialIdentifier index)<br />
**GetMaterialWithGlobalNumber(int globalNumber)<br />
**GetLoad(LoadIdentifier index)<br />
**GetLoadWithGlobalNumber(int globalNumber)<br />
**RenumberNodeContainer()<br />
**FinalizeMesh()<br />
<br />
===FEMSpatialObject===<br />
This class provides a spatial object wrapper around the FEMObject. This class facilities the I/O which is now supported by the MetaIO library.<br />
<br />
===Using FEM Framework===<br />
<br />
const unsigned int Dimension = 3;<br />
typedef itk::SpatialObject<Dimension> SpatialObjectType;<br />
typedef SpatialObjectType::Pointer SpatialObjectPointer;<br />
<br />
// Read the FEM Problem<br />
typedef itk::SpatialObjectReader<Dimension> SpatialObjectReaderType;<br />
typedef SpatialObjectReaderType::Pointer SpatialObjectReaderPointer;<br />
SpatialObjectReaderPointer SpatialReader = SpatialObjectReaderType::New();<br />
SpatialReader->SetFileName( argv[1] );<br />
SpatialReader->Update();<br />
<br />
typedef itk::FEMObjectSpatialObject<Dimension> FEMObjectSpatialObjectType;<br />
typedef FEMObjectSpatialObjectType::Pointer FEMObjectSpatialObjectPointer;<br />
FEMObjectSpatialObjectType::Pointer femSO = <br />
dynamic_cast<FEMObjectSpatialObjectType*>((*(children->begin())).GetPointer());<br />
femSO->GetFEMObject()->FinalizeMesh();<br />
<br />
<br />
// Solve FEM Problem<br />
typedef itk::fem::Solver1<Dimension> Solver3DType;<br />
Solver3DType::Pointer solver = Solver3DType::New();<br />
solver->SetInput( femSO->GetFEMObject() );<br />
solver->Update( );<br />
<br />
<br />
// Write the solution - (i.e. deformed mesh)<br />
FEMObjectSpatialObjectType::Pointer femSODef = FEMObjectSpatialObjectType::New();<br />
femSODef->SetFEMObject(solver->GetOutput());<br />
<br />
typedef itk::SpatialObjectWriter<Dimension> SpatialObjectWriterType;<br />
typedef SpatialObjectWriterType::Pointer SpatialObjectWriterPointer;<br />
SpatialObjectWriterPointer SpatialWriter = SpatialObjectWriterType::New();<br />
SpatialWriter->SetInput(femSODef);<br />
SpatialWriter->SetFileName( argv[2] );<br />
SpatialWriter->Update();<br />
<br />
===Ongoing Work===<br />
*Update FEM Registration<br />
*Further code cleanup and testing<br />
<br />
== Simple ITK ==<br />
SimpleITK has been progressing. Highlights include:<br />
<br />
* [http://www.itk.org/Wiki/ITK_Release_4/Outreach/Conferences/MICCAI_2011/SimpleITK MICCAI 2011 tutorial accepted]<br />
* Infrastructure created to easily add new ITK filters (usually ~5 minutes)<br />
* BasicFilters mostly completed, Algorithms in progress<br />
** Initial Registration framework in place<br />
* Support for Python, Java, Ruby, Tcl, Lua<br />
** C# and R support in beta<br />
* [http://www.cdash.org/CDash/index.php?project=Insight#ITKv4_SimpleITK Dashboard]<br />
* [http://erie.nlm.nih.gov/~blowek1/SimpleITK/annotated.html Doxygen documentation]<br />
<br />
== GPU Support ==<br />
<br />
== Revising ==<br />
<br />
* The Review directory will be fully processed<br />
** Files in this directory will be assimilated or removed</div>Stnavahttps://public.kitware.com/Wiki/index.php?title=ITK/Summer_v4_2011_Meeting&diff=38964ITK/Summer v4 2011 Meeting2011-04-11T20:45:04Z<p>Stnava: /* University of Pennsylvanian */</p>
<hr />
<div>ITKv4 Summer Meeting<br />
<br />
*'''Dates: June 28-29, 2011''' <br />
*'''City: Chapel Hill, NC'''<br />
*'''Location: TBD<br />
<br />
== Travel / Hotel Information ==<br />
<br />
Since the meeting starts at 8 am on June 28th,<br />
we recommend people to arrange their hotel accommodation for the previous night!<br />
<br />
== Registration Information ==<br />
<br />
<br />
== Meeting Room ==<br />
<br />
<br />
== Meeting Agenda ==<br />
<br />
=== Must See Topics ===<br />
<br />
* BETA Release<br />
* GPU<br />
* Modularization<br />
* SimpleITK<br />
* DICOM<br />
* Registration Refactoring<br />
* LevelSet Refactoring<br />
<br />
<br />
=== Tuesday June 28th ===<br />
<br />
<br />
==== Morning A ====<br />
<br />
<br />
==== Afternoon A ====<br />
<br />
<br />
=== Wednesday June 29th ===<br />
<br />
<br />
==== Morning B ====<br />
<br />
<br />
==== Afternoon B ====<br />
<br />
== Attendees ==<br />
<br />
Please add your name to the list below if you are planning to attend.<br />
<br />
=== Kitware ===<br />
* Luis Ibanez<br />
* Xiaoxiao Liu<br />
* Gabe Hart<br />
* Stephen Aylward<br />
* Bill Hoffman<br />
<br />
=== University of Iowa ===<br />
* Vincent Magnotta<br />
* Hans Johnson<br />
<br />
=== University of Pennsylvania ===<br />
*Brian Avants<br />
*James C. Gee<br />
*Nick Tustison<br />
<br />
=== Harvard University ===<br />
* Arnaud Gelas<br />
<br />
=== Ohio State University ===<br />
=== Cosmo ===<br />
=== GE ===<br />
* Jim Miller<br />
<br />
=== Mayo Clinic ===<br />
* Dan Blezek<br />
<br />
=== University of North Carolina ===<br />
* Cory Quammen<br />
* Marc Niethammer<br />
<br />
=== National Library of Medicine ===<br />
<br />
=== Georgetown University / CNMC ===<br />
* Ziv Yaniv</div>Stnavahttps://public.kitware.com/Wiki/index.php?title=ITK/Summer_v4_2011_Meeting&diff=38963ITK/Summer v4 2011 Meeting2011-04-11T20:44:35Z<p>Stnava: /* University of Pennsylvanian */</p>
<hr />
<div>ITKv4 Summer Meeting<br />
<br />
*'''Dates: June 28-29, 2011''' <br />
*'''City: Chapel Hill, NC'''<br />
*'''Location: TBD<br />
<br />
== Travel / Hotel Information ==<br />
<br />
Since the meeting starts at 8 am on June 28th,<br />
we recommend people to arrange their hotel accommodation for the previous night!<br />
<br />
== Registration Information ==<br />
<br />
<br />
== Meeting Room ==<br />
<br />
<br />
== Meeting Agenda ==<br />
<br />
=== Must See Topics ===<br />
<br />
* BETA Release<br />
* GPU<br />
* Modularization<br />
* SimpleITK<br />
* DICOM<br />
* Registration Refactoring<br />
* LevelSet Refactoring<br />
<br />
<br />
=== Tuesday June 28th ===<br />
<br />
<br />
==== Morning A ====<br />
<br />
<br />
==== Afternoon A ====<br />
<br />
<br />
=== Wednesday June 29th ===<br />
<br />
<br />
==== Morning B ====<br />
<br />
<br />
==== Afternoon B ====<br />
<br />
== Attendees ==<br />
<br />
Please add your name to the list below if you are planning to attend.<br />
<br />
=== Kitware ===<br />
* Luis Ibanez<br />
* Xiaoxiao Liu<br />
* Gabe Hart<br />
* Stephen Aylward<br />
* Bill Hoffman<br />
<br />
=== University of Iowa ===<br />
* Vincent Magnotta<br />
* Hans Johnson<br />
<br />
=== University of Pennsylvanian ===<br />
<br />
Brian Avants<br />
<br />
James C. Gee<br />
<br />
Nick Tustison<br />
<br />
=== Harvard University ===<br />
* Arnaud Gelas<br />
<br />
=== Ohio State University ===<br />
=== Cosmo ===<br />
=== GE ===<br />
* Jim Miller<br />
<br />
=== Mayo Clinic ===<br />
* Dan Blezek<br />
<br />
=== University of North Carolina ===<br />
* Cory Quammen<br />
* Marc Niethammer<br />
<br />
=== National Library of Medicine ===<br />
<br />
=== Georgetown University / CNMC ===<br />
* Ziv Yaniv</div>Stnavahttps://public.kitware.com/Wiki/index.php?title=ITK/Release_4/Enhancing_Image_Registration_Framework/Tcon_2010-11-23&diff=34880ITK/Release 4/Enhancing Image Registration Framework/Tcon 2010-11-232010-11-23T22:49:15Z<p>Stnava: </p>
<hr />
<div>Topic notes:<br />
<br />
''' How do we develop a design document?<br />
'''<br />
<br />
E.g. http://www.itk.org/Wiki/Proposals:Refactoring_Statistics_Framework_2007_Class_Manifesto <br />
but dont use tables. Do use the class diagrams. <br />
<br />
Is there a different method? maybe latex ....<br />
<br />
''' CompositeTransform ( Michael Stauffer, Nick )<br />
'''<br />
<br />
Mike will push later today. <br />
<br />
''' CompositeTransform I/O<br />
'''<br />
<br />
We are currently leaning toward writing a list of files. why? because you write out a deformation field as nii.gz , an affine as .mat or .txt and a velocity field as .mhd. and it may be easily edited to build concatenated files. problems: windows, etc. also, sometimes headers are in separate files than the binary data they describe. <br />
<br />
Tricky design issues --- composite transform file names. Do we pass full file names for each transform? <br />
<br />
Invoke a special I/O object for composite transforms?<br />
<br />
Currently, a transform has 2 arrays of doubles. Then the I/O writer will save in either txt or binary. Do we add a string or array of strings with each transform to the transform factory? Most transforms would not use this. The composite transform would populate it. <br />
<br />
Do we need a ImageTransformIOFactory? <br />
<br />
Should possibly add GetDefaultTransformFileType to transform base. Enumerates: BinaryType, TextType, ImageType. <br />
<br />
''' DeformationFieldTransform <br />
'''<br />
<br />
Current deformation field transform only transforms point. Still needs to implement jacobian and other elements that are ultimately needed. This is ok for now. The rest will happen later. <br />
<br />
''' DeformationFieldTransform I/O<br />
''' <br />
<br />
See composite transform notes above. <br />
<br />
''' How to remove transforms we dont want anymore?<br />
'''<br />
<br />
Document? Mark classes as deprecated? How do we avoid breaking somebody's application? <br />
<br />
Good solution: create a module for classes that we want to eliminate. Xiaoxiao stuff. E.g. all centered transforms.<br />
<br />
Also: create core registration module that is tested most deeply and that we highly recommend. <br />
<br />
''' BSpline refactoring + Bug? ( Nick )<br />
'''<br />
<br />
Line 721 bspline transform txx --- Luis says "Wow". We decide we should get rid of the bulk transform b/c it is inconsistent with the rest of the toolkit. CompositeTransform will replace this functionality. Need to discuss / publicize this change with NAMIC, Hans Johnson, Elastix.<br />
<br />
First, we'll put the current preliminary composite transform in through gerrit.<br />
<br />
''' Transform base class refactoring<br />
'''<br />
<br />
Enum type that identifies output file type <br />
<br />
SpatialJacobian <br />
<br />
SpatialHessian and/or Hessian<br />
<br />
Eliminate transform vector functions? Kind of. Implement the methods polymorphically then call the polymorphic methods from the TransformVector / TransformTensor function.<br />
<br />
''' Metric base class refactoring<br />
'''<br />
<br />
Remove multi-threading stuff except SetNumberOfThreads. Luis will go over. <br />
<br />
''' Reorientation standards/approaches.<br />
'''<br />
<br />
Separate reorientation filters ?<br />
<br />
Add a template parameter that takes a reorienting functor. Identity default. <br />
<br />
It appears to be standard throughout the toolkit that reorientation is performed. as far as we know.</div>Stnavahttps://public.kitware.com/Wiki/index.php?title=ITK/Release_4/Enhancing_Image_Registration_Framework/Tcon_2010-11-23&diff=34879ITK/Release 4/Enhancing Image Registration Framework/Tcon 2010-11-232010-11-23T22:44:15Z<p>Stnava: </p>
<hr />
<div>Topic notes:<br />
<br />
''' How to distribute / manage a design document<br />
'''<br />
<br />
E.g. http://www.itk.org/Wiki/Proposals:Refactoring_Statistics_Framework_2007_Class_Manifesto <br />
but dont use tables. use the class diagrams. <br />
<br />
Is there a different method? maybe latex ....<br />
<br />
''' CompositeTransform ( Michael Stauffer, Nick )<br />
'''<br />
Mike will push later today. <br />
<br />
''' CompositeTransform I/O<br />
'''<br />
We are currently leaning toward writing a list of files. why? because you write out a deformation field as nii.gz , an affine as .mat or .txt and a velocity field as .mhd. and it may be easily edited to build concatenated files. problems: windows, etc. also, sometimes headers are in separate files than the binary data they describe. <br />
<br />
another tricky thing --- composite transform file names. do we pass prefixes? do we pass the names for all the transforms (too much work)? <br />
<br />
invoke a special I/O object for composite transforms?<br />
<br />
currently, a transform has 2 arrays of doubles. then the I/O writer will save in either txt or binary. do we add a string or array of strings with each transform to the transform factory? most transforms would not use this. composite transform would populate it. <br />
<br />
need ImageTransformIOFactory? <br />
<br />
add GetDefaultTransformFileExtension to transform base? alternatively, BinaryType, TextType, ImageType enumerators. <br />
<br />
''' DeformationFieldTransform <br />
'''<br />
current deformation field transform only transforms point. still needs to implement jacobian and other elements that are ultimately needed. this is ok for now. the rest will happen later. <br />
<br />
''' DeformationFieldTransform I/O<br />
''' <br />
see composite transform notes above. <br />
<br />
''' How to remove transforms we dont want anymore?<br />
'''<br />
Document? Mark classes as deprecated? How do we avoid breaking somebody's application? <br />
<br />
Good solution: create a module for classes that we want to eliminate. Xiaoxiao stuff. E.g. all centered transforms.<br />
<br />
Also: create core registration module that is tested most deeply and that we highly recommend. <br />
<br />
''' BSpline refactoring + Bug? ( Nick )<br />
'''<br />
line 721 bspline transform txx --- Luis says "Wow". we decide we should get rid of the bulk transform b/c it is inconsistent with the rest of the toolkit. CompositeTransform will replace this functionality. Need to discuss / publicize this change with NAMIC, Hans Johnson, Elastix.<br />
<br />
first, we'll put the current preliminary composite transform in through gerrit.<br />
<br />
''' Transform base class refactoring<br />
'''<br />
Enum type that identifies output file type <br />
<br />
SpatialJacobian <br />
<br />
SpatialHessian and/or Hessian<br />
<br />
Eliminate transform vector functions? Kind of. Implement the methods polymorphically then call the polymorphic methods from the TransformVector / TransformTensor function.<br />
<br />
''' Metric base class refactoring<br />
'''<br />
Remove multi-threading stuff except SetNumberOfThreads.<br />
<br />
''' Reorientation standards/approaches.<br />
'''<br />
separate reorientation filter ?<br />
<br />
it appears to be standard throughout the toolkit that reorientation is performed. as far as we know.</div>Stnavahttps://public.kitware.com/Wiki/index.php?title=ITK/Release_4/Enhancing_Image_Registration_Framework/Tcon_2010-11-23&diff=34878ITK/Release 4/Enhancing Image Registration Framework/Tcon 2010-11-232010-11-23T22:42:27Z<p>Stnava: Created page with "Topic notes: ''' How to distribute / manage a design document ''' E.g. http://www.itk.org/Wiki/Proposals:Refactoring_Statistics_Framework_2007_Class_Manifesto but dont use tab..."</p>
<hr />
<div>Topic notes:<br />
<br />
''' How to distribute / manage a design document<br />
'''<br />
E.g. http://www.itk.org/Wiki/Proposals:Refactoring_Statistics_Framework_2007_Class_Manifesto <br />
but dont use tables. use the class diagrams. <br />
<br />
Is there a different method? maybe latex ....<br />
<br />
''' CompositeTransform ( Michael Stauffer, Nick )<br />
'''<br />
Mike will push later today. <br />
<br />
''' CompositeTransform I/O<br />
'''<br />
We are currently leaning toward writing a list of files. why? because you write out a deformation field as nii.gz , an affine as .mat or .txt and a velocity field as .mhd. and it may be easily edited to build concatenated files. problems: windows, etc. also, sometimes headers are in separate files than the binary data they describe. <br />
<br />
another tricky thing --- composite transform file names. do we pass prefixes? do we pass the names for all the transforms (too much work)? <br />
<br />
invoke a special I/O object for composite transforms?<br />
<br />
currently, a transform has 2 arrays of doubles. then the I/O writer will save in either txt or binary. do we add a string or array of strings with each transform to the transform factory? most transforms would not use this. composite transform would populate it. <br />
<br />
need ImageTransformIOFactory? <br />
<br />
add GetDefaultTransformFileExtension to transform base? alternatively, BinaryType, TextType, ImageType enumerators. <br />
<br />
''' DeformationFieldTransform <br />
'''<br />
current deformation field transform only transforms point. still needs to implement jacobian and other elements that are ultimately needed. this is ok for now. the rest will happen later. <br />
<br />
''' DeformationFieldTransform I/O<br />
''' <br />
see composite transform notes above. <br />
<br />
''' How to remove transforms we dont want anymore?<br />
'''<br />
Document? Mark classes as deprecated? How do we avoid breaking somebody's application? <br />
<br />
Good solution: create a module for classes that we want to eliminate. Xiaoxiao stuff. E.g. all centered transforms.<br />
<br />
Also: create core registration module that is tested most deeply and that we highly recommend. <br />
<br />
''' BSpline refactoring + Bug? ( Nick )<br />
'''<br />
line 721 bspline transform txx --- Luis says "Wow". we decide we should get rid of the bulk transform b/c it is inconsistent with the rest of the toolkit. CompositeTransform will replace this functionality. Need to discuss / publicize this change with NAMIC, Hans Johnson, Elastix.<br />
<br />
first, we'll put the current preliminary composite transform in through gerrit.<br />
<br />
''' Transform base class refactoring<br />
'''<br />
Enum type that identifies output file type <br />
<br />
SpatialJacobian <br />
<br />
SpatialHessian and/or Hessian<br />
<br />
Eliminate transform vector functions? Kind of. Implement the methods polymorphically then call the polymorphic methods from the TransformVector / TransformTensor function.<br />
<br />
''' Metric base class refactoring<br />
'''<br />
Remove multi-threading stuff except SetNumberOfThreads.<br />
<br />
''' Reorientation standards/approaches.<br />
'''<br />
separate reorientation filter ?<br />
<br />
it appears to be standard throughout the toolkit that reorientation is performed. as far as we know.</div>Stnavahttps://public.kitware.com/Wiki/index.php?title=ITK/Release_4/Enhancing_Image_Registration_Framework&diff=34874ITK/Release 4/Enhancing Image Registration Framework2010-11-23T21:42:00Z<p>Stnava: /* Tcons */</p>
<hr />
<div>'''Enhancing Image Registration Framework'''<br />
<br />
= Goals =<br />
<br />
* Review v4 registration plans and progress.<br />
<br />
* Catalog target use cases.<br />
<br />
* Discuss design changes in core itk to support these enhancements. <br />
<br />
* Wishlist items beyond standard use cases, e.g. projective transform (itkPerspective3DTransform).<br />
<br />
= Discussion Items =<br />
<br />
* Separate sampling (interpolation strategy) and metric computation <br />
<br />
* Separate computation of derivative components via chain rule.<br />
<br />
* Enable registration of generalized data-types.<br />
<br />
* Multiple metrics and/or multiple optimizers?<br />
<br />
* Add feature based registration techniques (SIFT (patented?), SURF, etc)<br />
<br />
<br />
[[Proposals:Refactoring of optimization framework|Refactoring of optimization framework]]<br />
<br />
[[Proposal for Revised Framework]]<br />
<br />
[http://www.itk.org/Wiki/ITK_Release_4/Wish_List#Image_Registration Wish List for ITKv4 ]<br />
<br />
= Related Groups (A2D2) =<br />
<br />
# BWH: Score++<br />
#* Sean Megason and Julian Jomier<br />
# Georgetown: Automated parameter tuning<br />
#* Ziv Yaniv, Andinet Enquobahrie<br />
# Utah: Score<br />
#* Marcel Prastawa, Julien Jomier, G. Gerig, J. Fillon-Robin<br />
# Utah: Time-Varying Shape Modeling<br />
#* T. Fletcher, J. Cater, R. MacLeod, C. McGann, S. Callahan<br />
# William+mary*: Non-Rigid Registration for Image Guided Neurosurgery<br />
#* N. Chrisochoides et al.<br />
<br />
Notes:<br />
<br />
(a) #3, #4, and #5 should be consulted during the actual refactoring of the registration framework.<br />
(b) #1, #2, and #3 should be involved with the design of a web-based parameter estimation, comparison.<br />
<br />
= Tcons =<br />
<br />
(Add one page for every tcon).<br />
<br />
* [[ITK_Release_4/Enhancing Image Registration Framework/Tcon 2010-09-07|Tcon 2010-09-07]]<br />
<br />
* [[ITK_Release_4/Enhancing Image Registration Framework/Tcon 2010-11-03|Tcon 2010-11-03]]<br />
<br />
* [[ITK_Release_4/Enhancing Image Registration Framework/Tcon 2010-11-23|Tcon 2010-11-23]]</div>Stnavahttps://public.kitware.com/Wiki/index.php?title=ITK/Release_4/Enhancing_Image_Registration_Framework/Tcon_2010-11-03&diff=33601ITK/Release 4/Enhancing Image Registration Framework/Tcon 2010-11-032010-11-03T20:58:22Z<p>Stnava: </p>
<hr />
<div>Discussion items<br />
<br />
Numerics - wrap everything so it's "easy" to switch something else in, e.g. eigen. the current framework somewhat follows this style but it's not consistent everywhere. e.g. direct use of vnl svd. <br />
<br />
Numerics - some places in the toolkit explicitly invert matrices rather than using linear solvers from vnl and/or itpack. <br />
<br />
Numerics - itpack appears to still live inside the FEM part of ITK and could use some additional wrappers to make the tools more widely available to the rest of the toolkit. <br />
<br />
Registration - we should benchmark itk v3.20 and itkv4 as it is today. <br />
<br />
Registration - we need a public location (on midas or nitrc) where we systematically assemble the data and publish registration benchmark results e.g. using Gang Song's system. <br />
<br />
Registration - we want to expose the voxel-wise value of the metric derivative s.t. we can have a dense field for use in dense registration. <br />
<br />
Registration - we need to allow symmetric / unbiased registration which will necessitate a parallel metric hierarchy or some relatively small changes to the current hierarchy. <br />
<br />
Registration - Brad discovered a bug which he will send to the list and record in Mantis.<br />
<br />
Registration - will meet sunday night in iowa to get started on refactoring.</div>Stnavahttps://public.kitware.com/Wiki/index.php?title=ITK/Release_4/Enhancing_Image_Registration_Framework/Tcon_2010-11-03&diff=33599ITK/Release 4/Enhancing Image Registration Framework/Tcon 2010-11-032010-11-03T20:57:21Z<p>Stnava: Created page with "Discussion items Numerics - wrap everything so it's "easy" to switch something else in, e.g. eigen. the current framework somewhat follows this style but it's not consistent e..."</p>
<hr />
<div>Discussion items<br />
<br />
Numerics - wrap everything so it's "easy" to switch something else in, e.g. eigen. the current framework somewhat follows this style but it's not consistent everywhere. e.g. direct use of vnl svd. <br />
<br />
Numerics - some places in the toolkit explicitly invert matrices rather than using linear solvers from vnl and/or itpack. <br />
<br />
Numerics - itpack appears to still live inside the FEM part of ITK and could use some additional wrappers to make the tools more widely available to the rest of the toolkit. <br />
<br />
Registration - we should benchmark itk v3.20 and itkv4 as it is today. <br />
<br />
Registration - we need a public location (on midas or nitrc) where we systematically assemble the data and publish registration benchmark results e.g. using Gang Song's system. <br />
<br />
Registration - we want to expose the voxel-wise value of the metric derivative s.t. we can have a dense field for use in dense registration. <br />
<br />
Registration - we need to allow symmetric / unbiased registration which will necessitate a parallel metric hierarchy or some relatively small changes to the current hierarchy. <br />
<br />
Registration - Brad discovered a bug which he will send to the list and record in Mantis.</div>Stnavahttps://public.kitware.com/Wiki/index.php?title=ITK/Release_4/Enhancing_Image_Registration_Framework&diff=33598ITK/Release 4/Enhancing Image Registration Framework2010-11-03T20:48:32Z<p>Stnava: /* Tcons */</p>
<hr />
<div>'''Enhancing Image Registration Framework'''<br />
<br />
= Goals =<br />
<br />
* Review v4 registration plans and progress.<br />
<br />
* Catalog target use cases.<br />
<br />
* Discuss design changes in core itk to support these enhancements. <br />
<br />
* Wishlist items beyond standard use cases, e.g. projective transform (itkPerspective3DTransform).<br />
<br />
= Discussion Items =<br />
<br />
* Separate sampling (interpolation strategy) and metric computation <br />
<br />
* Separate computation of derivative components via chain rule.<br />
<br />
* Enable registration of generalized data-types.<br />
<br />
* Multiple metrics and/or multiple optimizers?<br />
<br />
* Add feature based registration techniques (SIFT (patented?), SURF, etc)<br />
<br />
<br />
[[Proposals:Refactoring of optimization framework|Refactoring of optimization framework]]<br />
<br />
[[Proposal for Revised Framework]]<br />
<br />
[http://www.itk.org/Wiki/ITK_Release_4/Wish_List#Image_Registration Wish List for ITKv4 ]<br />
<br />
= Tcons =<br />
<br />
(Add one page for every tcon).<br />
<br />
* [[ITK_Release_4/Enhancing Image Registration Framework/Tcon 2010-09-07|Tcon 2010-09-07]]<br />
<br />
* [[ITK_Release_4/Enhancing Image Registration Framework/Tcon 2010-11-03|Tcon 2010-11-03]]</div>Stnavahttps://public.kitware.com/Wiki/index.php?title=Proposal_for_Revised_Framework&diff=30243Proposal for Revised Framework2010-09-14T15:33:06Z<p>Stnava: </p>
<hr />
<div>Let us suppose we want to perform a registration with the new framework. <br />
<br />
There are a few key ingredients we need:<br />
<br />
1. itkComposeTransform class , derived from itkTransform ( look at vtkGeneralTransform , functions as a pipeline i.e. if you change one transform then the composition is updated) <br />
<br />
2. itkDeformationFieldTransform class , derived from itkTransform (add Trait IsInvertible , throw exception )<br />
<br />
3. itkTransformImageFilter --- takes itkTransform as input<br />
<br />
4. itkCreateComposedTransformFilter --- figure out details later<br />
<br />
Hans: in itkV4 we need to read/write composed mappings with a standardized I/O for transformations. <br />
<br />
Then , pseudocode for a registration is: <br />
<br />
1. Set up a multi-resolution optimization over the TransformImageFilter <br />
<br />
--- note that we can control the resolution of the TransformImageFilter output.<br />
<br />
2. For each transform within itkComposeTransform <br />
<br />
--- Optimize: the metric(s) associated with that transform for n iterations or convergence <br />
<br />
3. go to next level <br />
<br />
In the case of a symmetric registration, pseudocode : <br />
<br />
1. Set up a multi-resolution optimization over the TransformImageFilter1 and TransformImageFilter2<br />
<br />
--- we usually would set up these filter symmetrically i.e. both have (affine,deformation) maps within and we optimize each pair together<br />
<br />
2. For each transform pair taken from ComposeTransform1 and ComposeTransform2<br />
<br />
--- Optimize: the metric(s) associated with that transform for n iterations or convergence <br />
<br />
3. go to next level <br />
<br />
For the Optimize step:<br />
<br />
for each transform within ComposeTransform : <br />
<br />
--- compute the update to the transform given its associated metric(s)<br />
<br />
--- the update may be one-sided (asymmetric) or two-sided (symmetric) <br />
<br />
--- note: the metrics do not need access to the transform. they only access outputs of ComposeTransform objects.<br />
<br />
<br />
Finally, note that this framework is general for other objects (Meshes) but, to support this, we may <br />
need generalized iterators (e.g. random iterator over meshes looks the same as random iterator over images).<br />
<br />
<br />
Metrics in ITK should have consistent maximum/minimum metric values along with the optimizers.</div>Stnavahttps://public.kitware.com/Wiki/index.php?title=Proposal_for_Revised_Framework&diff=30239Proposal for Revised Framework2010-09-14T15:26:58Z<p>Stnava: </p>
<hr />
<div>Let us suppose we want to perform a registration with the new framework. <br />
<br />
There are a few key ingredients we need:<br />
<br />
1. itkComposeTransform class , derived from itkTransform ( look at vtkGeneralTransform , functions as a pipeline i.e. if you change one transform then the composition is updated) <br />
<br />
2. itkDeformationFieldTransform class , derived from itkTransform (add Trait IsInvertible , throw exception )<br />
<br />
3. itkTransformImageFilter --- takes itkTransform as input<br />
<br />
4. itkCreateComposedTransformFilter --- figure out details later<br />
<br />
Hans: in itkV4 we need to read/write composed mappings with a standardized I/O for transformations. <br />
<br />
Then , pseudocode for a registration is: <br />
<br />
1. Set up a multi-resolution optimization over the TransformImageFilter <br />
<br />
--- note that we can control the resolution of the TransformImageFilter output.<br />
<br />
2. For each transform within itkComposeTransform <br />
<br />
--- Optimize: the metric(s) associated with that transform for n iterations or convergence <br />
<br />
3. go to next level <br />
<br />
In the case of a symmetric registration, pseudocode : <br />
<br />
1. Set up a multi-resolution optimization over the TransformImageFilter1 and TransformImageFilter2<br />
<br />
--- we usually would set up these filter symmetrically i.e. both have (affine,deformation) maps within and we optimize each pair together<br />
<br />
2. For each transform pair taken from ComposeTransform1 and ComposeTransform2<br />
<br />
--- Optimize: the metric(s) associated with that transform for n iterations or convergence <br />
<br />
3. go to next level <br />
<br />
For the Optimize step:<br />
<br />
for each transform within ComposeTransform : <br />
<br />
--- compute the update to the transform given its associated metric(s)<br />
<br />
--- the update may be one-sided (asymmetric) or two-sided (symmetric) <br />
<br />
--- note: the metrics do not need access to the transform. they only access outputs of ComposeTransform objects.<br />
<br />
<br />
Finally, note that this framework is general for other objects (Meshes) but, to support this, we may <br />
need generalized iterators (e.g. random iterator over meshes looks the same as random iterator over images).</div>Stnavahttps://public.kitware.com/Wiki/index.php?title=Proposal_for_Revised_Framework&diff=30238Proposal for Revised Framework2010-09-14T15:25:45Z<p>Stnava: </p>
<hr />
<div>Let us suppose we want to perform a registration with the new framework. <br />
<br />
There are a few key ingredients we need:<br />
<br />
1. itkComposeTransform class , derived from itkTransform ( look at vtkGeneralTransform , functions as a pipeline i.e. if you change one transform then the composition is updated) <br />
<br />
2. itkDeformationFieldTransform class , derived from itkTransform (add Trait IsInvertible , throw exception )<br />
<br />
3. itkTransformImageFilter --- takes itkTransform as input<br />
<br />
4. itkCreateComposedTransformFilter --- figure out details later<br />
<br />
Hans: in itkV4 we need to read/write composed mappings ....<br />
<br />
Then , pseudocode for a registration is: <br />
<br />
1. Set up a multi-resolution optimization over the TransformImageFilter <br />
<br />
--- note that we can control the resolution of the TransformImageFilter output.<br />
<br />
2. For each transform within itkComposeTransform <br />
<br />
--- Optimize: the metric(s) associated with that transform for n iterations or convergence <br />
<br />
3. go to next level <br />
<br />
In the case of a symmetric registration, pseudocode : <br />
<br />
1. Set up a multi-resolution optimization over the TransformImageFilter1 and TransformImageFilter2<br />
<br />
--- we usually would set up these filter symmetrically i.e. both have (affine,deformation) maps within and we optimize each pair together<br />
<br />
2. For each transform pair taken from ComposeTransform1 and ComposeTransform2<br />
<br />
--- Optimize: the metric(s) associated with that transform for n iterations or convergence <br />
<br />
3. go to next level <br />
<br />
For the Optimize step:<br />
<br />
for each transform within ComposeTransform : <br />
<br />
--- compute the update to the transform given its associated metric(s)<br />
<br />
--- the update may be one-sided (asymmetric) or two-sided (symmetric) <br />
<br />
--- note: the metrics do not need access to the transform. they only access outputs of ComposeTransform objects.<br />
<br />
<br />
Finally, note that this framework is general for other objects (Meshes) but, to support this, we may <br />
need generalized iterators (e.g. random iterator over meshes looks the same as random iterator over images).</div>Stnavahttps://public.kitware.com/Wiki/index.php?title=Proposal_for_Revised_Framework&diff=30237Proposal for Revised Framework2010-09-14T15:22:22Z<p>Stnava: </p>
<hr />
<div>Let us suppose we want to perform a registration with the new framework. <br />
<br />
There are a few key ingredients we need:<br />
<br />
1. itkComposeTransform class , derived from itkTransform ( look at vtkGeneralTransform , functions as a pipeline i.e. if you change one transform then the composition is updated) <br />
<br />
2. itkDeformationFieldTransform class , derived from itkTransform (add Trait IsInvertible , throw exception )<br />
<br />
3. itkTransformImageFilter --- takes itkTransform as input<br />
<br />
4. itkCreateComposedTransformFilter --- figure out details later<br />
<br />
Then , pseudocode for a registration is: <br />
<br />
1. Set up a multi-resolution optimization over the TransformImageFilter <br />
<br />
--- note that we can control the resolution of the TransformImageFilter output.<br />
<br />
2. For each transform within itkComposeTransform <br />
<br />
--- Optimize: the metric(s) associated with that transform for n iterations or convergence <br />
<br />
3. go to next level <br />
<br />
In the case of a symmetric registration, pseudocode : <br />
<br />
1. Set up a multi-resolution optimization over the TransformImageFilter1 and TransformImageFilter2<br />
<br />
--- we usually would set up these filter symmetrically i.e. both have (affine,deformation) maps within and we optimize each pair together<br />
<br />
2. For each transform pair taken from ComposeTransform1 and ComposeTransform2<br />
<br />
--- Optimize: the metric(s) associated with that transform for n iterations or convergence <br />
<br />
3. go to next level <br />
<br />
For the Optimize step:<br />
<br />
for each transform within ComposeTransform : <br />
<br />
--- compute the update to the transform given its associated metric(s)<br />
<br />
--- the update may be one-sided (asymmetric) or two-sided (symmetric) <br />
<br />
--- note: the metrics do not need access to the transform. they only access outputs of ComposeTransform objects.<br />
<br />
<br />
Finally, note that this framework is general for other objects (Meshes) but, to support this, we may <br />
need generalized iterators (e.g. random iterator over meshes looks the same as random iterator over images).</div>Stnavahttps://public.kitware.com/Wiki/index.php?title=Proposal_for_Revised_Framework&diff=30234Proposal for Revised Framework2010-09-14T15:20:26Z<p>Stnava: </p>
<hr />
<div>Let us suppose we want to perform a registration with the new framework. <br />
<br />
There are a few key ingredients we need:<br />
<br />
1. itkComposeTransform class , derived from itkTransform ( look at vtkGeneralTransform , functions as a pipeline i.e. if you change one transform then the composition is updated) <br />
<br />
2. itkDeformationFieldTransform class , derived from itkTransform (add Trait IsInvertible , throw exception )<br />
<br />
3. itkTransformImageFilter --- takes itkTransform as input<br />
<br />
Then , pseudocode for a registration is: <br />
<br />
1. Set up a multi-resolution optimization over the TransformImageFilter <br />
<br />
--- note that we can control the resolution of the TransformImageFilter output.<br />
<br />
2. For each transform within itkComposeTransform <br />
<br />
--- Optimize: the metric(s) associated with that transform for n iterations or convergence <br />
<br />
3. go to next level <br />
<br />
In the case of a symmetric registration, pseudocode : <br />
<br />
1. Set up a multi-resolution optimization over the TransformImageFilter1 and TransformImageFilter2<br />
<br />
--- we usually would set up these filter symmetrically i.e. both have (affine,deformation) maps within and we optimize each pair together<br />
<br />
2. For each transform pair taken from ComposeTransform1 and ComposeTransform2<br />
<br />
--- Optimize: the metric(s) associated with that transform for n iterations or convergence <br />
<br />
3. go to next level <br />
<br />
For the Optimize step:<br />
<br />
for each transform within ComposeTransform : <br />
<br />
--- compute the update to the transform given its associated metric(s)<br />
<br />
--- the update may be one-sided (asymmetric) or two-sided (symmetric) <br />
<br />
--- note: the metrics do not need access to the transform. they only access outputs of ComposeTransform objects.<br />
<br />
<br />
Finally, note that this framework is general for other objects (Meshes) but, to support this, we may <br />
need generalized iterators (e.g. random iterator over meshes looks the same as random iterator over images).</div>Stnavahttps://public.kitware.com/Wiki/index.php?title=Proposal_for_Revised_Framework&diff=30233Proposal for Revised Framework2010-09-14T15:19:43Z<p>Stnava: </p>
<hr />
<div>Let us suppose we want to perform a registration with the new framework. <br />
<br />
There are a few key ingredients we need:<br />
<br />
1. itkComposeTransform class , derived from itkTransform<br />
<br />
2. itkDeformationFieldTransform class , derived from itkTransform (add Trait IsInvertible , throw exception )<br />
<br />
3. itkTransformImageFilter --- takes itkTransform as input<br />
<br />
Then , pseudocode for a registration is: <br />
<br />
1. Set up a multi-resolution optimization over the TransformImageFilter <br />
<br />
--- note that we can control the resolution of the TransformImageFilter output.<br />
<br />
2. For each transform within itkComposeTransform <br />
<br />
--- Optimize: the metric(s) associated with that transform for n iterations or convergence <br />
<br />
3. go to next level <br />
<br />
In the case of a symmetric registration, pseudocode : <br />
<br />
1. Set up a multi-resolution optimization over the TransformImageFilter1 and TransformImageFilter2<br />
<br />
--- we usually would set up these filter symmetrically i.e. both have (affine,deformation) maps within and we optimize each pair together<br />
<br />
2. For each transform pair taken from ComposeTransform1 and ComposeTransform2<br />
<br />
--- Optimize: the metric(s) associated with that transform for n iterations or convergence <br />
<br />
3. go to next level <br />
<br />
For the Optimize step:<br />
<br />
for each transform within ComposeTransform : <br />
<br />
--- compute the update to the transform given its associated metric(s)<br />
<br />
--- the update may be one-sided (asymmetric) or two-sided (symmetric) <br />
<br />
--- note: the metrics do not need access to the transform. they only access outputs of ComposeTransform objects.<br />
<br />
<br />
Finally, note that this framework is general for other objects (Meshes) but, to support this, we may <br />
need generalized iterators (e.g. random iterator over meshes looks the same as random iterator over images).</div>Stnavahttps://public.kitware.com/Wiki/index.php?title=Proposal_for_Revised_Framework&diff=30220Proposal for Revised Framework2010-09-14T14:54:47Z<p>Stnava: </p>
<hr />
<div>Let us suppose we want to perform a registration with the new framework. <br />
<br />
There are a few key ingredients we need:<br />
<br />
1. itkComposeTransform class , derived from itkTransform<br />
<br />
2. itkDeformationFieldTransform class , derived from itkTransform<br />
<br />
3. itkTransformImageFilter --- takes itkTransform as input<br />
<br />
Then , pseudocode for a registration is: <br />
<br />
1. Set up a multi-resolution optimization over the TransformImageFilter <br />
<br />
--- note that we can control the resolution of the TransformImageFilter output.<br />
<br />
2. For each transform within itkComposeTransform <br />
<br />
--- Optimize: the metric(s) associated with that transform for n iterations or convergence <br />
<br />
3. go to next level <br />
<br />
In the case of a symmetric registration, pseudocode : <br />
<br />
1. Set up a multi-resolution optimization over the TransformImageFilter1 and TransformImageFilter2<br />
<br />
--- we usually would set up these filter symmetrically i.e. both have (affine,deformation) maps within and we optimize each pair together<br />
<br />
2. For each transform pair taken from ComposeTransform1 and ComposeTransform2<br />
<br />
--- Optimize: the metric(s) associated with that transform for n iterations or convergence <br />
<br />
3. go to next level <br />
<br />
For the Optimize step:<br />
<br />
for each transform within ComposeTransform : <br />
<br />
--- compute the update to the transform given its associated metric(s)<br />
<br />
--- the update may be one-sided (asymmetric) or two-sided (symmetric) <br />
<br />
--- note: the metrics do not need access to the transform. they only access outputs of ComposeTransform objects.<br />
<br />
<br />
Finally, note that this framework is general for other objects (Meshes) but, to support this, we may <br />
need generalized iterators (e.g. random iterator over meshes looks the same as random iterator over images).</div>Stnavahttps://public.kitware.com/Wiki/index.php?title=Proposal_for_Revised_Framework&diff=30219Proposal for Revised Framework2010-09-14T14:53:43Z<p>Stnava: </p>
<hr />
<div>Let us suppose we want to perform a registration with the new framework. <br />
<br />
There are a few key ingredients we need:<br />
<br />
1. itkComposeTransform class , derived from itkTransform<br />
<br />
2. itkDeformationFieldTransform class , derived from itkTransform<br />
<br />
3. itkTransformImageFilter --- takes itkTransform as input<br />
<br />
Then , pseudocode for a registration is: <br />
<br />
1. Set up a multi-resolution optimization over the TransformImageFilter <br />
<br />
2. For each transform within itkComposeTransform <br />
<br />
--- Optimize: the metric(s) associated with that transform for n iterations or convergence <br />
<br />
3. go to next level <br />
<br />
In the case of a symmetric registration, pseudocode : <br />
<br />
1. Set up a multi-resolution optimization over the TransformImageFilter1 and TransformImageFilter2<br />
<br />
--- we usually would set up these filter symmetrically i.e. both have (affine,deformation) maps within and we optimize each pair together<br />
<br />
2. For each transform pair taken from ComposeTransform1 and ComposeTransform2<br />
<br />
--- Optimize: the metric(s) associated with that transform for n iterations or convergence <br />
<br />
3. go to next level <br />
<br />
For the Optimize step:<br />
<br />
for each transform within ComposeTransform : <br />
<br />
--- compute the update to the transform given its associated metric(s)<br />
<br />
--- the update may be one-sided (asymmetric) or two-sided (symmetric) <br />
<br />
--- note: the metrics do not need access to the transform. they only access outputs of ComposeTransform objects.<br />
<br />
<br />
Finally, note that this framework is general for other objects (Meshes) but, to support this, we may <br />
need generalized iterators (e.g. random iterator over meshes looks the same as random iterator over images).</div>Stnavahttps://public.kitware.com/Wiki/index.php?title=Proposal_for_Revised_Framework&diff=30218Proposal for Revised Framework2010-09-14T14:52:39Z<p>Stnava: </p>
<hr />
<div>Let us suppose we want to perform a registration with the new framework. <br />
<br />
There are a few key ingredients we need:<br />
<br />
1. itkComposeTransform class , derived from itkTransform<br />
<br />
2. itkDeformationFieldTransform class , derived from itkTransform<br />
<br />
3. itkTransformImageFilter --- takes itkTransform as input<br />
<br />
Then , pseudocode for a registration is: <br />
<br />
1. Set up a multi-resolution optimization over the TransformImageFilter <br />
<br />
2. For each transform within itkComposeTransform <br />
<br />
--- Optimize: the metric(s) associated with that transform for n iterations or convergence <br />
<br />
3. go to next level <br />
<br />
In the case of a symmetric registration, pseudocode : <br />
<br />
1. Set up a multi-resolution optimization over the TransformImageFilter1 and TransformImageFilter2<br />
<br />
--- we usually would set up these filter symmetrically i.e. both have (affine,deformation) maps within and we optimize each pair together<br />
<br />
2. For each transform pair taken from ComposeTransform1 and ComposeTransform2<br />
<br />
--- Optimize: the metric(s) associated with that transform for n iterations or convergence <br />
<br />
3. go to next level <br />
<br />
For the Optimize step:<br />
<br />
for each transform within ComposeTransform : <br />
<br />
--- compute the update to the transform given its associated metric(s)<br />
<br />
--- the update may be one-sided (asymmetric) or two-sided (symmetric) <br />
<br />
--- note: the metrics do not need access to the transform. they only access outputs of ComposeTransform objects.</div>Stnavahttps://public.kitware.com/Wiki/index.php?title=Proposal_for_Revised_Framework&diff=30206Proposal for Revised Framework2010-09-14T14:39:07Z<p>Stnava: </p>
<hr />
<div><br />
Let us suppose we want to perform a registration with the new framework. <br />
<br />
There are a few key ingredients we need:<br />
<br />
1. itkComposeTransform class , derived from itkTransform<br />
<br />
2. itkDeformationFieldTransform class , derived from itkTransform<br />
<br />
3. itkTransformImageFilter --- takes itkTransform as input<br />
<br />
Then , pseudocode for a registration is: <br />
<br />
1. Set up a multi-resolution optimization over the TransformImageFilter <br />
<br />
2. For each transform within itkComposeTransform <br />
<br />
--- Optimize: the metric(s) associated with that transform for n iterations or convergence <br />
<br />
3. go to next level <br />
<br />
For the Optimize step:</div>Stnavahttps://public.kitware.com/Wiki/index.php?title=Proposal_for_Revised_Framework&diff=30205Proposal for Revised Framework2010-09-14T14:37:11Z<p>Stnava: </p>
<hr />
<div><br />
Let us suppose we want to perform a registration with the new framework. <br />
<br />
There are a few key ingredients we need:<br />
<br />
1. itkComposeTransform class , derived from itkTransform<br />
<br />
2. itkTransformImageFilter --- takes itkTransform as input<br />
<br />
3. Set up a multi-resolution optimization over the TransformImageFilter <br />
<br />
4. For each transform within itkComposeTransform <br />
<br />
--- optimize the metric(s) associated with that transform for n iterations or convergence <br />
<br />
5. go to next level</div>Stnavahttps://public.kitware.com/Wiki/index.php?title=Proposal_for_Revised_Framework&diff=30203Proposal for Revised Framework2010-09-14T14:34:51Z<p>Stnava: Created page with "= PseudoCode ="</p>
<hr />
<div>= PseudoCode =</div>Stnavahttps://public.kitware.com/Wiki/index.php?title=ITK/Release_4/Enhancing_Image_Registration_Framework/Tcon_2010-09-07&diff=29997ITK/Release 4/Enhancing Image Registration Framework/Tcon 2010-09-072010-09-07T17:32:12Z<p>Stnava: /* Technical Topics */</p>
<hr />
<div>= Attendees =<br />
<br />
* Cory Quammen<br />
* Gabe Hart<br />
* Nick Tustison<br />
* Andy <br />
* Brian Avants<br />
* Luis Ibanez<br />
<br />
= Technical Topics =<br />
<br />
* Transform hierarchy<br />
** How to compose multiple transforms into a single<br />
*** ResampleImageFilter only deals with itk::Transform<br />
*** WarpImageFilter only deals with a deformation field<br />
*** A new filter is needed, that takes as input a collection of Transforms and deformation fields and apply them concatenated.<br />
* Potential Names (for this new class)<br />
** WarpImageMultiTransformFilter<br />
** ConcatenatedMappingImageTransformFilter<br />
* See the Gaussian down-sampling as another Transformation<br />
** Avoid storing the entire pyramid in memory (saving memory consumption).<br />
* Generalize the representation of an image by using a Sparse representation of the image.<br />
** Introduce an image sampling class that generates a Sparse image from an image.<br />
** Then pass this Sparse Image type to the Metrics.<br />
** Both for the Fixed and Moving images ?<br />
* How to consolidate a "smart" sampling to allow for<br />
** Dense sampling<br />
** Sparse sampling<br />
** Hide it in the iterator ?<br />
** Implement a Random iterator for Meshes (random point access) ?<br />
** Unify the representation of Meshes and Images ? (use SpatialObjects? )<br />
<br />
* Projective transforms for CV community<br />
** http://ibia.umit.at/ResearchGroup/Phil/web/Simple2D3DRegistrationFramework.html<br />
<br />
* Maximize MI( I(x) , J(T(x)) ) by gradient methods: <br />
** \partial Metric / \partial Image \partial Image / \partial Transform \partial Transform / \partial x <br />
<br />
== Use Cases ==<br />
<br />
* Be able to transform meshes (stored in VTK files) through a combination of<br />
** Affine Transforms<br />
** Deformation Field<br />
** Without having to do more than one interpolation (e.g. via concatenation of Transform).<br />
* Be able to transform Images through a combination of<br />
** Affine Transforms<br />
** Deformation Field<br />
** Without having to do more than one interpolation (e.g. via concatenation of Transform).<br />
* Perform '''symmetric''' registration (affine and deformable)(un-biased)<br />
** Registration in which Fixed and Moving images can be exchanged and the result of the registration will be the same.<br />
** Implementation: Extract the interpolation from the Metric.<br />
** Every metric must compute the derivative of the Metric with respect to both <br />
*** The space of the Fixed Image <br />
*** The space of the Moving Image<br />
** Use an intermediate space to which both images are registered<br />
** Then two transforms are computed: from the central space to each one of the two images.<br />
* Fit Intensity Models to images<br />
** E.g. Fitting a Gaussian (PSF) model to a microscopy image<br />
** Parametric image model<br />
** Some parameters from the Optimization space will correspond to the image parametric model.<br />
* Geometrical-Model to Image Registration<br />
* Better support for multiplicity (working together in a common registration problem).<br />
** Multiple Optimizers ?<br />
** Multiple Metrics ?<br />
* Parameter Mask<br />
** Selecting a subset of parameters from a larger set.<br />
*** E.g. In a 3D affine transform enable first only the translation parameters<br />
** Is this related to "bounding" some (or all?) elements in the parameter array ?</div>Stnavahttps://public.kitware.com/Wiki/index.php?title=ITK/Release_4/Enhancing_Image_Registration_Framework/Tcon_2010-09-07&diff=29996ITK/Release 4/Enhancing Image Registration Framework/Tcon 2010-09-072010-09-07T17:31:37Z<p>Stnava: /* Technical Topics */</p>
<hr />
<div>= Attendees =<br />
<br />
* Cory Quammen<br />
* Gabe Hart<br />
* Nick Tustison<br />
* Andy <br />
* Brian Avants<br />
* Luis Ibanez<br />
<br />
= Technical Topics =<br />
<br />
* Transform hierarchy<br />
** How to compose multiple transforms into a single<br />
*** ResampleImageFilter only deals with itk::Transform<br />
*** WarpImageFilter only deals with a deformation field<br />
*** A new filter is needed, that takes as input a collection of Transforms and deformation fields and apply them concatenated.<br />
* Potential Names (for this new class)<br />
** WarpImageMultiTransformFilter<br />
** ConcatenatedTransformImageTransformFilter<br />
* See the Gaussian down-sampling as another Transformation<br />
** Avoid storing the entire pyramid in memory (saving memory consumption).<br />
* Generalize the representation of an image by using a Sparse representation of the image.<br />
** Introduce an image sampling class that generates a Sparse image from an image.<br />
** Then pass this Sparse Image type to the Metrics.<br />
** Both for the Fixed and Moving images ?<br />
* How to consolidate a "smart" sampling to allow for<br />
** Dense sampling<br />
** Sparse sampling<br />
** Hide it in the iterator ?<br />
** Implement a Random iterator for Meshes (random point access) ?<br />
** Unify the representation of Meshes and Images ? (use SpatialObjects? )<br />
<br />
* Projective transforms for CV community<br />
** http://ibia.umit.at/ResearchGroup/Phil/web/Simple2D3DRegistrationFramework.html<br />
<br />
* Maximize MI( I(x) , J(T(x)) ) by gradient methods: <br />
** \partial Metric / \partial Image \partial Image / \partial Transform \partial Transform / \partial x <br />
<br />
== Use Cases ==<br />
<br />
* Be able to transform meshes (stored in VTK files) through a combination of<br />
** Affine Transforms<br />
** Deformation Field<br />
** Without having to do more than one interpolation (e.g. via concatenation of Transform).<br />
* Be able to transform Images through a combination of<br />
** Affine Transforms<br />
** Deformation Field<br />
** Without having to do more than one interpolation (e.g. via concatenation of Transform).<br />
* Perform '''symmetric''' registration (affine and deformable)(un-biased)<br />
** Registration in which Fixed and Moving images can be exchanged and the result of the registration will be the same.<br />
** Implementation: Extract the interpolation from the Metric.<br />
** Every metric must compute the derivative of the Metric with respect to both <br />
*** The space of the Fixed Image <br />
*** The space of the Moving Image<br />
** Use an intermediate space to which both images are registered<br />
** Then two transforms are computed: from the central space to each one of the two images.<br />
* Fit Intensity Models to images<br />
** E.g. Fitting a Gaussian (PSF) model to a microscopy image<br />
** Parametric image model<br />
** Some parameters from the Optimization space will correspond to the image parametric model.<br />
* Geometrical-Model to Image Registration<br />
* Better support for multiplicity (working together in a common registration problem).<br />
** Multiple Optimizers ?<br />
** Multiple Metrics ?<br />
* Parameter Mask<br />
** Selecting a subset of parameters from a larger set.<br />
*** E.g. In a 3D affine transform enable first only the translation parameters<br />
** Is this related to "bounding" some (or all?) elements in the parameter array ?</div>Stnavahttps://public.kitware.com/Wiki/index.php?title=ITK/Release_4/Enhancing_Image_Registration_Framework/Tcon_2010-09-07&diff=29995ITK/Release 4/Enhancing Image Registration Framework/Tcon 2010-09-072010-09-07T17:31:06Z<p>Stnava: /* Technical Topics */</p>
<hr />
<div>= Attendees =<br />
<br />
* Cory Quammen<br />
* Gabe Hart<br />
* Nick Tustison<br />
* Andy <br />
* Brian Avants<br />
* Luis Ibanez<br />
<br />
= Technical Topics =<br />
<br />
* Transform hierarchy<br />
** How to compose multiple transforms into a single<br />
*** ResampleImageFilter only deals with itk::Transform<br />
*** WrapImageFilter only deals with a deformation field<br />
*** A new filter is needed, that takes as input a collection of Transforms and deformation fields and apply them concatenated.<br />
* Potential Names (for this new class)<br />
** WarpImageMultiTransformFilter<br />
** ConcatenatedTransformImageTransformFilter<br />
* See the Gaussian down-sampling as another Transformation<br />
** Avoid storing the entire pyramid in memory (saving memory consumption).<br />
* Generalize the representation of an image by using a Sparse representation of the image.<br />
** Introduce an image sampling class that generates a Sparse image from an image.<br />
** Then pass this Sparse Image type to the Metrics.<br />
** Both for the Fixed and Moving images ?<br />
* How to consolidate a "smart" sampling to allow for<br />
** Dense sampling<br />
** Sparse sampling<br />
** Hide it in the iterator ?<br />
** Implement a Random iterator for Meshes (random point access) ?<br />
** Unify the representation of Meshes and Images ? (use SpatialObjects? )<br />
<br />
* Projective transforms for CV community<br />
** http://ibia.umit.at/ResearchGroup/Phil/web/Simple2D3DRegistrationFramework.html<br />
<br />
* Maximize MI( I(x) , J(T(x)) ) by gradient methods: <br />
** \partial Metric / \partial Image \partial Image / \partial Transform \partial Transform / \partial x <br />
<br />
== Use Cases ==<br />
<br />
* Be able to transform meshes (stored in VTK files) through a combination of<br />
** Affine Transforms<br />
** Deformation Field<br />
** Without having to do more than one interpolation (e.g. via concatenation of Transform).<br />
* Be able to transform Images through a combination of<br />
** Affine Transforms<br />
** Deformation Field<br />
** Without having to do more than one interpolation (e.g. via concatenation of Transform).<br />
* Perform '''symmetric''' registration (affine and deformable)(un-biased)<br />
** Registration in which Fixed and Moving images can be exchanged and the result of the registration will be the same.<br />
** Implementation: Extract the interpolation from the Metric.<br />
** Every metric must compute the derivative of the Metric with respect to both <br />
*** The space of the Fixed Image <br />
*** The space of the Moving Image<br />
** Use an intermediate space to which both images are registered<br />
** Then two transforms are computed: from the central space to each one of the two images.<br />
* Fit Intensity Models to images<br />
** E.g. Fitting a Gaussian (PSF) model to a microscopy image<br />
** Parametric image model<br />
** Some parameters from the Optimization space will correspond to the image parametric model.<br />
* Geometrical-Model to Image Registration<br />
* Better support for multiplicity (working together in a common registration problem).<br />
** Multiple Optimizers ?<br />
** Multiple Metrics ?<br />
* Parameter Mask<br />
** Selecting a subset of parameters from a larger set.<br />
*** E.g. In a 3D affine transform enable first only the translation parameters<br />
** Is this related to "bounding" some (or all?) elements in the parameter array ?</div>Stnavahttps://public.kitware.com/Wiki/index.php?title=ITK/Release_4/Enhancing_Image_Registration_Framework&diff=29994ITK/Release 4/Enhancing Image Registration Framework2010-09-07T17:29:33Z<p>Stnava: /* Discussion Items */</p>
<hr />
<div>'''Enhancing Image Registration Framework'''<br />
<br />
= Goals =<br />
<br />
* Review v4 registration plans and progress.<br />
<br />
* Catalog target use cases.<br />
<br />
* Discuss design changes in core itk to support these enhancements. <br />
<br />
* Wishlist items beyond standard use cases, e.g. projective transform (itkPerspective3DTransform).<br />
<br />
= Discussion Items =<br />
<br />
* Separate sampling (interpolation strategy) and metric computation <br />
<br />
* Separate computation of derivative components via chain rule.<br />
<br />
* Enable registration of generalized data-types.<br />
<br />
* Multiple metrics and/or multiple optimizers?<br />
<br />
* Add feature based registration techniques (SIFT (patented?), SURF, etc)<br />
<br />
<br />
[[Proposals:Refactoring of optimization framework|Refactoring of optimization framework]]<br />
<br />
[http://www.itk.org/Wiki/ITK_Release_4/Wish_List#Image_Registration Wish List for ITKv4 ]<br />
<br />
= Tcons =<br />
<br />
(Add one page for every tcon).<br />
<br />
* [[ITK_Release_4/Enhancing Image Registration Framework/Tcon 2010-09-07|Tcon 2010-09-07]]</div>Stnavahttps://public.kitware.com/Wiki/index.php?title=ITK/Release_4/Enhancing_Image_Registration_Framework&diff=29993ITK/Release 4/Enhancing Image Registration Framework2010-09-07T17:28:34Z<p>Stnava: /* Discussion Items */</p>
<hr />
<div>'''Enhancing Image Registration Framework'''<br />
<br />
= Goals =<br />
<br />
* Review v4 registration plans and progress.<br />
<br />
* Catalog target use cases.<br />
<br />
* Discuss design changes in core itk to support these enhancements. <br />
<br />
* Wishlist items beyond standard use cases, e.g. projective transform (itkPerspective3DTransform).<br />
<br />
= Discussion Items =<br />
<br />
* Separate sampling (interpolation strategy) and metric computation <br />
<br />
* Separate computation of derivative components via chain rule.<br />
<br />
* Add feature based registration techniques (SIFT (patented?), SURF, etc)<br />
<br />
[[Proposals:Refactoring of optimization framework|Refactoring of optimization framework]]<br />
<br />
[http://www.itk.org/Wiki/ITK_Release_4/Wish_List#Image_Registration Wish List for ITKv4 ]<br />
<br />
= Tcons =<br />
<br />
(Add one page for every tcon).<br />
<br />
* [[ITK_Release_4/Enhancing Image Registration Framework/Tcon 2010-09-07|Tcon 2010-09-07]]</div>Stnavahttps://public.kitware.com/Wiki/index.php?title=ITK/Release_4/Enhancing_Image_Registration_Framework&diff=29992ITK/Release 4/Enhancing Image Registration Framework2010-09-07T17:28:07Z<p>Stnava: /* Discussions */</p>
<hr />
<div>'''Enhancing Image Registration Framework'''<br />
<br />
= Goals =<br />
<br />
* Review v4 registration plans and progress.<br />
<br />
* Catalog target use cases.<br />
<br />
* Discuss design changes in core itk to support these enhancements. <br />
<br />
* Wishlist items beyond standard use cases, e.g. projective transform (itkPerspective3DTransform).<br />
<br />
= Discussion Items =<br />
<br />
* Separate sampling (interpolation strategy) and metric computation <br />
<br />
* Separate computation of derivative components via chain rule.<br />
<br />
# e.g. Maximize MI( I(x) , J(T(x)) ) by gradient methods: <br />
#<br />
# \partial Metric / \partial Image \partial Image / \partial Transform \partial Transform / \partial x <br />
<br />
* Add feature based registration techniques (SIFT (patented?), SURF, etc)<br />
<br />
[[Proposals:Refactoring of optimization framework|Refactoring of optimization framework]]<br />
<br />
[http://www.itk.org/Wiki/ITK_Release_4/Wish_List#Image_Registration Wish List for ITKv4 ]<br />
<br />
= Tcons =<br />
<br />
(Add one page for every tcon).<br />
<br />
* [[ITK_Release_4/Enhancing Image Registration Framework/Tcon 2010-09-07|Tcon 2010-09-07]]</div>Stnavahttps://public.kitware.com/Wiki/index.php?title=ITK/Release_4/Enhancing_Image_Registration_Framework&diff=29990ITK/Release 4/Enhancing Image Registration Framework2010-09-07T17:27:00Z<p>Stnava: /* Discussions */</p>
<hr />
<div>'''Enhancing Image Registration Framework'''<br />
<br />
= Goals =<br />
<br />
* Review v4 registration plans and progress.<br />
<br />
* Catalog target use cases.<br />
<br />
* Discuss design changes in core itk to support these enhancements. <br />
<br />
* Wishlist items beyond standard use cases, e.g. projective transform (itkPerspective3DTransform).<br />
<br />
= Discussions =<br />
<br />
* Separate sampling and metric computation <br />
<br />
* Separate computation of derivative components : <br />
<br />
e.g. Maximize MI( I(x) , J(T(x)) ) by gradient methods: <br />
<br />
\partial Metric / \partial Image \partial Image / \partial Transform \partial Transform / \partial x <br />
<br />
* Add feature based registration techniques (SIFT (patented?), SURF, etc)<br />
<br />
[[Proposals:Refactoring of optimization framework|Refactoring of optimization framework]]<br />
<br />
[http://www.itk.org/Wiki/ITK_Release_4/Wish_List#Image_Registration Wish List for ITKv4 ]<br />
<br />
http://ibia.umit.at/ResearchGroup/Phil/web/Simple2D3DRegistrationFramework.html<br />
<br />
= Tcons =<br />
<br />
(Add one page for every tcon).<br />
<br />
* [[ITK_Release_4/Enhancing Image Registration Framework/Tcon 2010-09-07|Tcon 2010-09-07]]</div>Stnavahttps://public.kitware.com/Wiki/index.php?title=ITK/Release_4/Enhancing_Image_Registration_Framework&diff=29989ITK/Release 4/Enhancing Image Registration Framework2010-09-07T17:26:34Z<p>Stnava: /* Goals */</p>
<hr />
<div>'''Enhancing Image Registration Framework'''<br />
<br />
= Goals =<br />
<br />
* Review v4 registration plans and progress.<br />
<br />
* Catalog target use cases.<br />
<br />
* Discuss design changes in core itk to support these enhancements. <br />
<br />
* Wishlist items beyond standard use cases, e.g. projective transform (itkPerspective3DTransform).<br />
<br />
= Discussions =<br />
<br />
* Separate sampling and metric computation <br />
<br />
* Separate computation of derivative components : <br />
<br />
e.g. Maximize MI( I(x) , J(T(x)) ) by gradient methods: <br />
<br />
\partial Metric / \partial Image \partial Image / \partial Transform \partial Transform / \partial x <br />
<br />
* Add feature based registration techniques (SIFT (patented?), SURF, etc)<br />
<br />
[[Proposals:Refactoring of optimization framework|Refactoring of optimization framework]]<br />
<br />
[http://www.itk.org/Wiki/ITK_Release_4/Wish_List#Image_Registration Wish List for ITKv4 ]<br />
<br />
= Tcons =<br />
<br />
(Add one page for every tcon).<br />
<br />
* [[ITK_Release_4/Enhancing Image Registration Framework/Tcon 2010-09-07|Tcon 2010-09-07]]</div>Stnavahttps://public.kitware.com/Wiki/index.php?title=ITK/Release_4/Enhancing_Image_Registration_Framework&diff=29945ITK/Release 4/Enhancing Image Registration Framework2010-09-07T14:43:55Z<p>Stnava: /* Goals */</p>
<hr />
<div>'''Enhancing Image Registration Framework'''<br />
<br />
= Goals =<br />
<br />
* Review v4 registration plans and progress.<br />
<br />
* Catalog target use cases.<br />
<br />
* Discuss strategies for integrating code from external contributors.<br />
<br />
* Wishlist items beyond standard use cases, e.g. projective transform (itkPerspective3DTransform)<br />
<br />
http://ibia.umit.at/ResearchGroup/Phil/web/Simple2D3DRegistrationFramework.html<br />
<br />
= Discussions =<br />
<br />
* Separate sampling and metric computation <br />
<br />
* Separate computation of derivative components : <br />
<br />
e.g. Maximize MI( I(x) , J(T(x)) ) by gradient methods: <br />
<br />
\partial Metric / \partial Image \partial Image / \partial Transform \partial Transform / \partial x <br />
<br />
* Add feature based registration techniques (SIFT (patented?), SURF, etc)<br />
<br />
[[Proposals:Refactoring of optimization framework|Refactoring of optimization framework]]<br />
<br />
[http://www.itk.org/Wiki/ITK_Release_4/Wish_List#Image_Registration Wish List for ITKv4 ]<br />
<br />
= Tcons =<br />
<br />
(Add one page for every tcon).<br />
<br />
* [[ITK_Release_4/Enhancing Image Registration Framework/Tcon 2010-09-07|Tcon 2010-09-07]]</div>Stnavahttps://public.kitware.com/Wiki/index.php?title=ITK/Release_4/Enhancing_Image_Registration_Framework&diff=29910ITK/Release 4/Enhancing Image Registration Framework2010-09-07T13:04:51Z<p>Stnava: /* Discussions */</p>
<hr />
<div>'''Enhancing Image Registration Framework'''<br />
<br />
= Goals =<br />
<br />
* Review v4 registration plans and progress.<br />
<br />
* Catalog target use cases.<br />
<br />
* Discuss strategies for integrating code from external contributors.<br />
<br />
* Wishlist items beyond standard use cases, e.g. projective transforms.<br />
<br />
http://ibia.umit.at/ResearchGroup/Phil/web/Simple2D3DRegistrationFramework.html<br />
<br />
= Discussions =<br />
<br />
* Separate sampling and metric computation <br />
<br />
* Separate computation of derivative components : <br />
<br />
e.g. Maximize MI( I(x) , J(T(x)) ) by gradient methods: <br />
<br />
\partial Metric / \partial Image \partial Image / \partial Transform \partial Transform / \partial x <br />
<br />
* Add feature based registration techniques (SIFT (patented?), SURF, etc)<br />
<br />
= Tcons =<br />
<br />
(Add one page for every tcon).</div>Stnavahttps://public.kitware.com/Wiki/index.php?title=ITK/Release_4/Enhancing_Image_Registration_Framework&diff=29909ITK/Release 4/Enhancing Image Registration Framework2010-09-07T12:52:18Z<p>Stnava: /* Goals */</p>
<hr />
<div>'''Enhancing Image Registration Framework'''<br />
<br />
= Goals =<br />
<br />
* Review v4 registration plans and progress.<br />
<br />
* Catalog target use cases.<br />
<br />
* Discuss strategies for integrating code from external contributors.<br />
<br />
* Wishlist items beyond standard use cases, e.g. projective transforms.<br />
<br />
http://ibia.umit.at/ResearchGroup/Phil/web/Simple2D3DRegistrationFramework.html<br />
<br />
= Discussions =<br />
* Add feature based registration techniques (SIFT (patented?), SURF, etc)<br />
<br />
= Tcons =<br />
<br />
(Add one page for every tcon).</div>Stnavahttps://public.kitware.com/Wiki/index.php?title=ITK/Release_4/Enhancing_Image_Registration_Framework&diff=29908ITK/Release 4/Enhancing Image Registration Framework2010-09-07T12:46:16Z<p>Stnava: /* Goals */</p>
<hr />
<div>'''Enhancing Image Registration Framework'''<br />
<br />
= Goals =<br />
<br />
* Review v4 registration plans and progress.<br />
<br />
* Discuss strategies for integrating code from external contributors.<br />
<br />
* Wishlist items e.g. projective transforms.<br />
<br />
= Discussions =<br />
* Add feature based registration techniques (SIFT (patented?), SURF, etc)<br />
<br />
= Tcons =<br />
<br />
(Add one page for every tcon).</div>Stnavahttps://public.kitware.com/Wiki/index.php?title=Minutes_080310&diff=26423Minutes 0803102010-08-03T17:55:35Z<p>Stnava: /* Attendees */</p>
<hr />
<div>== Attendees ==<br />
<br />
* Terry Yoo<br />
* Brad Lowekamp<br />
* Daniel Blezek<br />
* Bill Lorensen<br />
* Jim Miller<br />
* Alex Gouaillard<br />
* Sean Megason<br />
* Arnaud Gelas<br />
* Gaetan Lehmann<br />
* Brad King<br />
* Gabe Hart<br />
* Luis Ibanez<br />
* Brian Avants<br />
<br />
== Technical Topics ==<br />
<br />
* Brad K. described initial Git workflow to be adopted for ITK<br />
** Quick mention of Gerrit (code review tool)<br />
** Explanation of the "rebase" workflow that we are initially using.<br />
** Current ITK Git Workflow is identical to VTK<br />
*** Developers can only push to the "master" branch of the public repository.<br />
*** Explanation of the "fast-forward" concept<br />
**** [http://book.git-scm.com/3_basic_branching_and_merging.html from Git book]<br />
**** [http://www.kernel.org/pub/software/scm/git/docs/git-rebase.html and from Git man page]<br />
* Suggested release Alpha-01 for August 7th.<br />
* Discussed whether to include KWStyle as a commit hook or not.<br />
<br />
== Action Items ==<br />
<br />
* Luis to put together a Wiki page to coordinate the intermediate Alpha releases <br />
** Developers can volunteer to sign up to help with each one of those topics<br />
* Luis to patch fixes for Sun CC compiler that were posted to the Slicer mailing list<br />
** Coordinate with Brad King to move those fixes to ITK 3.20 (in Git).</div>Stnavahttps://public.kitware.com/Wiki/index.php?title=Minutes_072010&diff=26422Minutes 0720102010-08-03T17:55:05Z<p>Stnava: /* Attendees */</p>
<hr />
<div>== Attendees ==<br />
<br />
* Bill Lorensen<br />
* Jim Miller<br />
* Hans Johnson<br />
* Dan Blezek<br />
* Cory Quamenn<br />
* Gabe Hart<br />
* Gaetan Lehmann<br />
* Vincent Magnotta<br />
* John Galeotti<br />
* Brad Davis<br />
* Arnaud Gelas<br />
* Alex Gouaillard<br />
* Mathieu Malaterre<br />
* Philip Cook<br />
* Ziv Yaniv<br />
* Luis Ibanez<br />
* Brian Avants<br />
<br />
== Technical Topics ==<br />
<br />
* Migration to Git (expected by the end of July)<br />
** Collateral modifications<br />
*** KWStyle as commit hook<br />
*** ITK Dashboard transition to Git<br />
* ITK Sandbox in Github ? (limited interest...)<br />
* Adapting KWStyle to Git, for commit hooks<br />
** KWSTyle itself migrated to Git<br />
** Added Boost library for regular expressions<br />
* Uncrustify & ITK Style Fixes<br />
** Hans proposed updates to the ITK Coding Style<br />
** Consensus on adopting uncrustify and adapting KWStyle<br />
* CPPCheck<br />
** Long run time...<br />
** Doing on pieces of the toolkit ?<br />
** Comparing with Coverity (Brad to report)<br />
* cpd : Code Duplication<br />
** Arnaud: will try and report back<br />
* Report on SimpleITK<br />
* Report on Wrapping<br />
* Report on Modularization<br />
** Using Ryppl as a tool<br />
** Use it for Boost, ITK and VTK..<br />
* Start on DICOM ?<br />
<br />
== Action Items ==</div>Stnavahttps://public.kitware.com/Wiki/index.php?title=Minutes_071310&diff=26420Minutes 0713102010-08-03T17:54:38Z<p>Stnava: /* Attendees */</p>
<hr />
<div>== Attendees ==<br />
<br />
* Jim Miller<br />
* Dan Blezek<br />
* Brak Lowekamp<br />
* Bill Lorensen<br />
* Brad King<br />
* Dave Cole<br />
* Bill Hoffman<br />
* Marcus Hanwell<br />
* Stephen Aylward<br />
* Gabe Hart<br />
* Luis Ibanez<br />
* Gaëtan Lehmann<br />
* Alexandre Gouaillard<br />
* Ziv Yaniv<br />
* Brian Avants<br />
* (Please add your name here if we missed you in the list...)<br />
<br />
== Technical Topics ==<br />
<br />
* Transition Plan<br />
* Software Process Infrastructure<br />
** Gerrit : Code Review system<br />
<br />
== Action Items ==</div>Stnavahttps://public.kitware.com/Wiki/index.php?title=ITK&diff=24748ITK2010-07-06T17:16:00Z<p>Stnava: /* ITK Version 4 */</p>
<hr />
<div>= ITK Version 4 =<br />
This section was added to inform the ITK community of the pending changes to the ITK toolkit that will be taking place over the next 6 months. This work is supported by ARRA funding from the NLM. The kick-off meeting for this project took place from [http://visual.nlm.nih.gov/itk/itk2010/agenda.html June 28-July 2 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. <br />
<br />
*Move from cvs to git for distributed source code management<br />
*Remove support for the following compilers that have known incompatibilities with c++03 (http://en.wikipedia.org/wiki/C%2B%2B03#Language_standard)<br />
**Visual Studio version 6<br />
**Visual Studio version 7<br />
**Borland version 5.5<br />
**Sun Studio compilers<br />
** IRIX compilers<br />
** MWORKS compilers<br />
** gcc 2.96 compilers (and perhaps some very early 3.0 series compilers)<br />
*Improved ITK Wrapping<br />
*Addition of simple ITK layer<br />
*Enhanced modularity<br />
*[[Refactoring itk::FEM framework - V4]]<br />
*Improved DICOM support<br />
*Add streaming for video<br />
*Enhanced image registration framework<br />
<br />
== ITK Version 4 -- Discussion Points ==<br />
<br />
*Strings are std::strings: Filenames should be std::strings, not const char* _arg <br />
** Set character string. Creates member Set"name"() (e.g., SetFilename(char *)). The macro assumes that the class member (name) is declared a type std::string. */ <br />
<br />
* Threading model modifications: <br />
# Thread pools? <br />
# Hierarchal thread handlers? <br />
# Can threads deal with pushing data across hardware units with inconsistent memory models (i.e. 4 core SMP + GPU#1 + GPU#2) <br />
<br />
* Need Explicit Transition Documentation: <br />
# To facilitate transition from ITK3 to ITK4, a set of migration documents and tools will be beneficial to researchers who will be migrating to their tools to ITK4. As we adapt the reference applications to the changes occurring in ITK4, we will document the necessary source code changes to use the new version of ITK4. When possible, we will write a set of scripting tools that transform ITK3 to ITK4, or identify old code that has become invalidated, and suggest alternative options. We will deliver this documentation both as a standalone document and as an online WIKI-based web resource. <br />
<br />
*Transforms: <br />
# Need ability to deal with concatenated physical space mappings (Rigid-»Affine-»BSpline-»Displacement-»Rigid-» etc) <br />
# Better protocols for reading/writing/ transforms including the ambiguous way that compound (i.e. not concatenated) transforms are represented. <br />
<br />
*Image Physical Space/Domain: <br />
# There is a need an image layer that does NOT have a physical space representation <br />
## ImageBase-»DigitalImage-»ContinuousImage-»[Image(the current interpretation)|GeoSpatialImage|Other physical space] <br />
## Most PixelWise filters will be defined over the DigitalImage layer to explicitly identify them as not dealing with physical space <br />
## Digital to Continuous conversion API is consistent (TransformIndexToPhysical & PhysicalToIndexTransform), but may be adaptable to address the needs of our expanding user base <br />
## The current "Image" designator is explicitly defined as an (LPS anatomical, East|North|Altitude) with Direction cosigns, spacing, origin and appropriate <br />
## Units: A designation that can hint to the application level how to interpret physical space. Perhaps the filters would just verify that units are the same. (default being non-existing and therefore the same). <br />
<br />
*Platform support (a platform is a [Hardware, OS, Compiler, Compiler options] )<br />
<br />
# Reduce build burden -- Explicit Templates & Pre-compiled headers: <br />
## Under the assumption that the scope of the simple & wrapping frameworks will define a large swath of instantiations that almost all applications also need. By defining and pre-compling those common (perhaps driven by the wrapping choices) tools, compiling the application layers will be significantly faster. This should reduce the burden on application developers by shifting build time costs away form the time of building the applications. <br />
## We do have to be careful to limit this (or provide options to limit this) so that the default build does not take 10 hours. <br />
## This does imply that the compiler MUST support explicit instantiation of templates <br />
## ---- As a side note, perhaps we also need to investigate pre-compiled header support for compilers to lower the development burden <br />
# An explicit deprecation cycle for ALL compilers <br />
## It is CRUCIAL that we define upfront a MINIMUM time frame for how long each version of ITK4 we commit to supporting all platforms. It is expected that these dates will shift into the future, but not earlier.<br />
### Windows 7, Visual Studio 2010 will be supported at least until Jan 1, 2017 <br />
### Windows XP, Visual Studio Express 8 will be supported at least until Jan 1, 2015 <br />
### Linux gcc version 4 (greater than 4.0.1) will be supported at least until Jan 1, 2012 <br />
# Compilers need to be compliant with the C++03 standards. http://en.wikipedia.org/wiki/C%2B%2B <br />
<br />
*IO interface changes:<br />
# Transforms components "Can be written", but there is insufficient information to un-ambiguously derive the intent and appropriate use of those transform parameters. In particular, the parameters for BSpline are written to disk in two components, and the BSpline parameters are linearly written, but the implied grid for those parameters is not specified in the output file. As a use case, the BSpline transform type SHOULD be able to be instantiated from just the information in the file. <br />
# Are there IO factory simplifications that could be done? i.e. remove separatedFactories for each type <br />
<br />
*Meta Data Dictionary: <br />
# MetaData Dictionary items need "Traits" to help identify the "social status" of the element (such as ITK_SUPPORTED_PUBLIC, ITK_SUPPORTED_PRIVATE, UNSUPPORTED_PRIVATE, UNSUPPORTED_PUBLIC). <br />
# The first contribution of the Iowa ITK development team was to introduce the “MetaDataDictionary” storage mechanism to all ITK Objects that could contain arbitrary key-value pairs of data. The MetaDataDictionary was not part of the original ITK framework definition, and has therefore not been consistently implemented throughout the ITK toolkit. We propose to revisit the implementation of the MetaDataDictionary to improve and simplify the ABI so that it is easier to use. In particular, the Encapsulate() and Expose() functions can now be simplified when using standards-compliant C++ compilers, and new features for describing a dynamically created dictionary at run time will be introduced. A common use of the MetaDataDictionary has been to temporally append features that were missing in the initial ITK framework. In many cases, the use of the MetaDataDictionary was subsequently followed by addition of formal support of the feature to ITK, and this lead to redundancy of information that was not always kept synchronized. Additionally, as new developers adopted the MetaDataDictionary for different uses, they each created inconsistent definitions for similar uses of the dictionary. We will review the internal ITK uses of the MetaDataDictionary, remove uses that are now redundant with formal accepted functionality, and consolidate similar uses of the Dictionary. The MetaDataDictionary is most commonly used to pass additional information to or from the Input/Output mechanisms. We will define a protocol so that data object histories can be tracked through consistent instrumentation of ITK process objects to tag output objects. We will review the Input/Output and develop a standard practices guideline for how to map the extra data to and from ITK in a consistent way. Wherever possible, we will use tags and definitions consistent with the dictionaries specified in the DICOM standard. <br />
<br />
* ITK Orientation <br />
# Instrument the itk::ImageIO methods to record spatial image orientation in the MetaDataDictionary prior to it’s inclusion as a formal feature. This solution allowed representation of which of 48 possible 3D orientations the image was in. This was represented symbolically by 3 letter combinations, based on permuting (A)nterior/(Posterier), (I)nferior/(S)uperior, (L)eft/(R)ight. For example RAS meant that the voxels are oriented Right-to-Left, Anterior-to-Posterior, Superior to Inferior, corresponding to Row/Column/Slice. This method of specifying orientation is useful but very limited; many anatomical scanners allow scanning at oblique angles with respect to anatomy. So after long discussion in the ITK developer community, a more general method was developed, which represented the orientation as a direction cosine matrix (DCM). The direction cosines specify a general 3D rotation of the image voxels with respect to the anatomy being scanned. The long experience with brain imaging research at Iowa will inform our implementation of these changes. However, we also recognize and highly value the expertise of the other members of the ITK developer community, and the implementation will be guided by the consensus judgment of the community as a whole. We will enhance the code infrastructure of ITK with respect to issues of position and orientation of images. Deliverables will comprise both changes to the core ITK library code, and extensive regression tests to verify correct operation with the rest of the ITK Library. There are three ways in which the handling of orientation in ITK needs to be improved:<br />
# Currently the size of the direction cosines is linked to the number of dimensions in the image – for a 2D Image, they comprise a 2x2 DCM, for a 3D Image 3x3, etc. Conceptually, the use of the current orientation description is most suited for describing images with exactly 3 spatial dimensions. We believe this needs to be changed and generalized to accommodate describing data sets within a higher dimensional space, or with respect measurement direction that is different from scanning direction. First, any 2D scan of anatomy will have an implied third axes, parallel to the direction of image acquisition. In particular, 2D DICOM slice images always report the three-dimensional image position of the scan with respect to the patient. At present, when ITK reads a single 2D DICOM image, there is no way to preserve it’s relationship to 3D-space. Finally, the orientation of a measurement frame with respect to sub-volumes is necessary to properly represent complex acquisition types (such as diffusion weighted imaging). Similarly, 2D Images can have a three-dimensional image origin with a well-defined anatomical meaning. Discarding that when reading the image is a loss of information. In both cases (orientation and origin) it will be necessary to enforce backwards compatibility. This will be achieved in two ways: by adding new class methods that are explicitly three-dimensional, and by careful testing of all ITK classes to ensure their continued correct operation. <br />
<br />
*Need more FFT adaptors, and a slight refactoring of FFT adaptor base to meet several platform<br />
<br />
# It would be nice to have a compliant FFT built in with reasonable performance (vnl does not work) <br />
# Mac Accelerate framework, Intel MLK, <br />
<br />
* Need adaptors for some subsets of (SVD/LAPACK/BLAS) numerics: <br />
# Should be able to take advantage of the Mac Acclerate, Intel MLK, Atlas or others with minimal end user configuration <br />
<br />
*Remove NeuralNetwork<br />
# The current implementation in ITK requires that the network architecture and Input/Output routines be completely defined at compile-time. This severely limits the utility of the current implementation. The Input/Output mechanism of the current Neural Network currently only supports a proprietary network file format. This limits the ability to analyze the networks with complex external tools such as Matlab Neural Network toolkit. <br />
<br />
* Coding style, and enforcement: <br />
# There should be some system somewhere that is compliant with the ITK coding style. It would be preferable if the primary development editors (VS, vim, emacs) could all be configured to support the style consistently. <br />
# The uncrustify program MAY allow a conduit for helping new developers format to be KWSTYLE compliant. <br />
<br />
* All process object outputs should be available as data objects (including native types)<br />
# There are times when a filter computes a value that is used as input into later stages of the pipeline, there needs to be a way to easily link filters and have the pipeline work properly even when the linkage is a simple integer. <br />
<br />
* Should the default behavior of all filters be to release their input data <br />
# This may address the complaint that ITK has unacceptable memory usage. <br />
<br />
* All class objects that end in "2" as a mechanism to fix bugs, and not break backwards compatibility should be removed. <br />
<br />
* itk_hashtable.h should be investigated to determine if a more standard implementation could replace the existing version. The current version has many different implementations for dealing with different compiler bases.<br />
<br />
= ITK 10th Anniversary =<br />
<br />
== Join us to Celebrate ==<br />
* [[ITK 10th Anniversary Activities| ITK 10th Anniversary Activities]]<br />
<br />
=== Dashboard Fests ===<br />
* [[ITK 10th Anniversary Activities/Dashboard Fest 2.0 | Dashboard Fest 2.0 ]]<br />
* [[ITK 10th Anniversary Activities/Dashboard Fest 1.0 | Dashboard Fest 1.0 ]]<br />
<br />
=== Adopt-A-Bug 2.0 ===<br />
* [[ITK 10th Anniversary Activities/Adopt-A-Bug 2.0 | Adopt-A-Bug 2.0 ]]<br />
<br />
for historical reference:<br />
* [[ITK 10th Anniversary Activities/Adopt-A-Bug 1.0 | Adopt-A-Bug 1.0 ]]<br />
<br />
=== Share your ITK anecdotes ===<br />
* [[ITK 10th Anniversary Activities/ITK Stories and anecdotes |ITK Stories and anecdotes]]<br />
<br />
=== ITK CVS History ===<br />
<br />
* [[ITK 10th Anniversary Activities/ITK CVS History |ITK CVS History]]<br />
<br />
= The Insight Segmentation and Registration Toolkit =<br />
<br />
The National Library of Medicine '''Insight Segmentation and Registration Toolkit''' (ITK) is an open-source software system for medical image processing in two, three and more dimensions. <br />
<br />
This is the ''ITK Wiki'', a collaborative hypertext database of information, documentation and resources.<br />
<br />
== Users ==<br />
<br />
* [[ITK FAQ|Frequently Asked Questions (FAQ)]]<br />
* [[ITK About|About the Insight Toolkit]]<br />
* [[ITK License Information| License Information]]<br />
* [[ITK Insight Applications|Insight Applications]]<br />
* [[ITK Getting Started|Getting Started with ITK]]<br />
<br />
* [[ITK Resources|ITK Resources]]<br />
** [[ITK Documentation|Documentation]]<br />
** [[ITK Tutorials|Tutorials]]<br />
** [[ITK Best of the List|Best of the List]]<br />
** [[ITK Related Software|Related Software]]<br />
** [[ITK Third Party Applications|Third Party Applications]]<br />
* [[2006 Survey Summary]]<br />
* [[ITK Upcomings Events|ITK Upcoming Events]]<br />
* [[ITK Procedure for Contributing New Classes and Algorithms|Procedure for Contributing New Classes and Algorithms to ITK]]<br />
<br />
== Releases ==<br />
<br />
* Most Recent Release<br />
** [[ITK Release 3.18|What is new in release 3.18]] [[ITK Release 3.18 Changed From Previous |What changed since 3.16]]<br />
<br />
* Next Recent Releases<br />
** [[ITK Release 3.16|What is new in release 3.16]] [[ITK Release 3.16 Changed From Previous |What changed since 3.14]]<br />
** [[ITK Release 3.14|What is new in release 3.14]] [[ITK Release 3.14 Changed From Previous |What changed since 3.12]]<br />
** [[ITK Release 3.12|What is new in release 3.12]] [[ITK Release 3.12 Changed From Previous |What changed since 3.10]]<br />
* [[ITK Past Releases| Past Releases]]<br />
* [[ITK Release Schedule|Schedule of upcoming releases]]<br />
* [[ITK Release 4.0|Release 4.0 wish list]]<br />
<br />
== Software Engineering and Development ==<br />
<br />
* [[ITK Coding Style Guide|Style Guide]]<br />
* [[ITK Configuring and Building|Configuring and Building]]<br />
** [[ITK Scripting|Scripting]]<br />
** [[ITK MS Free Tool|MS Free Tool]]<br />
<br />
== Academic Corner ==<br />
<br />
* [[ITK Course Ware|Course Ware]]<br />
* [[ITK File Formats|File Formats]]<br />
* [[ITK Image Registration|Image Registration Topics]]<br />
* [[ITK Image Segmentation|Image Segmentation Topics]]<br />
<br />
== Professional Corner ==<br />
<br />
* [[ITK Job Opportunities|Job Opportunities]]<br />
* [[FDA Guidelines for Software Developement]]<br />
<br />
== Open Society ==<br />
<br />
* [[ITK Patent Bazaar|Patented Algoritms]]<br />
* [[ITK Open Access Science|Open Access Science]]<br />
* [[ITK The Insight Journal|The Insight Journal]]<br />
* [[ITK The Insight Conference|The Insight Conference]]<br />
<br />
== Developers Corner ==<br />
<br />
=== Community Coordination ===<br />
<br />
* [[ITK in Second Life|In Second Life]]<br />
* [[Telephone Conference Agendas and Minutes]]<br />
* [[ITK Oversight Committee|Oversight Committee]]<br />
* [[ITK Working Groups|Working Groups]]<br />
<br />
=== Policies and Procedures ===<br />
<br />
* [[ITK Policies and Procedures]]<br />
** [[ITK Policy and Procedure for Adding Dashboards|Adding Dashboard Submissions]]<br />
** [[Build Instructions for Developers]]<br />
** [[ITK Procedure for Contributing New Classes and Algorithms|Procedure for Contributing New Classes and Algorithms]]<br />
** [[ITK Procedure for Contributing Bug Fixes|Procedure for Contributing Bug Fixes]]<br />
** [[ITK Procedure for Adding a Test|Procedure for Adding a Test]]<br />
** [[ITK Rules for CVS Contributors|Rules for CVS Contributors]]<br />
<br />
=== Statistics ===<br />
<br />
* [http://www.ohloh.net/projects/3240?p=Insight+Toolkit ITK in Ohloh]<br />
* [[ITK Code Coverage per Developer|Code Coverage per Developer]]<br />
* [http://public.kitware.com/pub/itk/InsightStatCVS/index.html StatCVS ITK Statistics (Generated:2009-11-05)]<br />
* [http://www.itk.org/Testing/StatCVS/ ITK CVS Statistics (Generated: 2/28/08)]<br />
* [[ITK Code Swarms]]<br />
<br />
{{ITK/Template/Footer}}</div>Stnava