Difference between revisions of "Documentation/Labs/DeprecatedModules"
Line 1: | Line 1: | ||
This page is here to capture the list of modules we would like to bundle into a Slicer extension named "DeprecatedModules". | This page is here to capture the list of modules we would like to bundle into a Slicer extension named "DeprecatedModules". | ||
− | = | + | = Action plan = |
− | 1) | + | All these modules would be added to their own git repository: |
+ | * History should be extracted and conserved. | ||
+ | * Data should be added to Midas. | ||
+ | |||
+ | Then, two approaches: | ||
+ | |||
+ | 1) A git repository named "DeprecatedModulesExtension" could combine them using the "git submodule" approach". | ||
2) The concept of meta extension could be introduced (similar to what is down with apt-get), the extension would appear in the catalog and would simply allow to install all its dependent extensions. | 2) The concept of meta extension could be introduced (similar to what is down with apt-get), the extension would appear in the catalog and would simply allow to install all its dependent extensions. |
Revision as of 00:17, 10 April 2013
Home < Documentation < Labs < DeprecatedModulesThis page is here to capture the list of modules we would like to bundle into a Slicer extension named "DeprecatedModules".
Action plan
All these modules would be added to their own git repository:
- History should be extracted and conserved.
- Data should be added to Midas.
Then, two approaches:
1) A git repository named "DeprecatedModulesExtension" could combine them using the "git submodule" approach".
2) The concept of meta extension could be introduced (similar to what is down with apt-get), the extension would appear in the catalog and would simply allow to install all its dependent extensions.
Jc: Approach 2 is preferred.
Modules
I propose to include all the module belonging to the CLI "Legacy" category: See also http://www.slicer.org/slicerWiki/index.php/Developer_Meetings/20130226#Listing_of_Modules
- AffineRegistration (it's just a simple registration example, BRAINS registration provides all its functionality)
- BSplineDeformableRegistration (it's just a simple registration example, BRAINS registration provides all its functionality)
- BSplineToDeformationField => Needed by EMSegment; very useful in general, as the BSpline transform is not usable by external programs, but the conversion result (deformation field) can be processed and visualized in ParaView etc.
- DiffusionTensorTest
- ExpertAutomatedRegistration => Needed by TubeTK. - Can it be replaced by BRAINS?
- FiducialRegistration => Needed by SlicerIGT. It's the most effective semi-automatic rigid registration method, so don't remove without replacement (or at least don't put it in an extension that collects useless modules only)
- LinearRegistration (it's just a simple registration example, BRAINS registration provides all its functionality)
- MultiResolutionAffineRegistration
- OtsuThresholdImageFilter
- OtsuThresholdSegmentation
- ResampleScalarVolume => Essential feature (typically high-resolution data is downsampled with this filter to conserve memory and increase execution speed; e.g., for registration), don't remove without replacement (or at least don't put it in an extension that collects useless modules only)
- RigidRegistration (it's just a simple registration example, BRAINS registration provides all its functionality)
- TestGridTransformRegistration
- MRIBiasFieldCorrection => Essential feature for MRI registration, don't remove without replacement (or at least don't put it in an extension that collects useless modules only)
- There is this module that is more up to date and arguable is more easy to use: http://wiki.slicer.org/slicerWiki/index.php/Documentation/Nightly/Modules/N4ITKBiasFieldCorrection. This module remains in the main application.
Are the following modules used:
- MIDASApplications
- BatchMakeApplications