Difference between revisions of "Documentation/Labs/DeprecatedModules"

From Slicer Wiki
Jump to: navigation, search
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".
  
= Possible approach =
+
= Action plan =
  
1) Then, a git repository named "DeprecatedModulesExtension" could combine them using the "git submodule" approach".
+
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 < DeprecatedModules

This 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)

Are the following modules used:

  • MIDASApplications
  • BatchMakeApplications