Difference between revisions of "ITK Registration Optimization/2007-06-27-tcon"
From NAMIC Wiki
Line 1: | Line 1: | ||
= NAMIC Programmers' Weeks = | = NAMIC Programmers' Weeks = | ||
+ | |||
+ | [[ITK_Registration_Optimization]]/[[ITK_Registration_Optimization/Events | Events]] | ||
=== Meeting Notes === | === Meeting Notes === |
Revision as of 16:51, 3 July 2007
Home < ITK Registration Optimization < 2007-06-27-tconNAMIC Programmers' Weeks
ITK_Registration_Optimization/ Events
Meeting Notes
- Jim Miller says: It should be possible to have the classes default to running in a single thread. Additionally, we can provide the old API to access that single-threaded case. Only if the user manually specifies "RunMultiThreaded" will the multi-threaded instances (and their specialized API) be used. Using a bool member var to track if the multi-threaded version is being used or not, we should be able to warn users when threaded and non-threaded methods are being mixed.
- Jim Millier says: ITK's threader class is a bit obscure. It would be good to have a helper class (or macros) that simplify the standard use case of wanting to run a member function as multi-threaded.
- It should be possible to setup the threads once, and to call them later. In that manner, creating and running the threads becomes decoupled - the cost of creating a thread can be limited to an initialization function.
- During the break-out session and subsequent discussions, the need for helper classes that provide common registration solutions became apparent. People use ITK's examples as those "helper classes" - but they aren't really intended to be or well suited for that task. We have helper classes in BWHITKOptimization/Code/Utilities. We should use them whenever possible.
- Everyone wants the slicer modules "yesterday."
- BatchMake/CMake integration is going to be a huge topic. Interest is building. We need to solidify the goals and niche of this effort
- Luis' recent work saved us. His broadening of the focus and thorough testing of all parts revealed many bugs and addresses the needs of the community more than the initial focus of the project.
- We have given CVS access to a few people in Polina's group. We may hear from them soon. Their particular interest was the helper classes we've made for rigid, affine, and b-spline registration. This suggests that we need to increase our use and documentation of those classes.
- Ron wants this work to be integrated into the NAMIC kit.
FUTURE WORK
- API of itkThreader class: Add a helper class (or macros) that simplifies running a member function multi-threaded.
- Backward compatibility: Modify the classes to be backward compatible with ITK. We will be able to contribute our code to ITK and thereby make it s part of NAMIC kit.
- Complete the IJ submissions.
- General Slicer Modules: Convert the general slicer modules to use our rigid, affine, and b-spline helper classes in Code/Utilties
- EMSegmenter Registration Module: Integrate the optimized registration classes the EMSegmenter. This should be done using the rigid, affine, and b-spline helper classes in Code/Utilities.