Difference between revisions of "2008 Winter Project Week:PythonSupport"
From NAMIC Wiki
| Line 29: | Line 29: | ||
* define what aspects will end up in the next release | * define what aspects will end up in the next release | ||
* solve issues (building issues, threading issues, etc) | * solve issues (building issues, threading issues, etc) | ||
| + | * propose a way of making Python scripting and Python modules independent of Numpy (etc..) support (so one can have the former without the latter in case there are issues with the dependencies or one wants to keep Slicer leaner) | ||
* propose a working set of Python command line modules (interact with Sonia's breakout session on Tuesday?) to be included in the next release. | * propose a working set of Python command line modules (interact with Sonia's breakout session on Tuesday?) to be included in the next release. | ||
</div> | </div> | ||
Revision as of 11:16, 13 December 2007
Home < 2008 Winter Project Week:PythonSupport Return to 2008_Winter_Project_Week |
Key Investigators
- Mario Negri Institute: Luca Antiga
- UCSD: Bryan Smith
Objective
Python has a great potential in Slicer3. Its uses span:
- Python command line modules (advantages: easy to write, access to Python libraries, don't need a compiler to write new modules)
- matplotlib and scipy Python modules (they provide a matlab-like processing environment for images directly within Slicer).
- Python as Slicer's scripting language (for automating task and programmatically access modules - this is Dan's new baby!)
Approach, Plan
In the project week, we plan to
- consolidate Python support in Slicer3 from a design point of view (eg. can we allow Python command line modules to modify the MRML scene in a thread-safe way? ) (can we provide a Python equivalent to ScriptedModules?)
- define what aspects will end up in the next release
- solve issues (building issues, threading issues, etc)
- propose a way of making Python scripting and Python modules independent of Numpy (etc..) support (so one can have the former without the latter in case there are issues with the dependencies or one wants to keep Slicer leaner)
- propose a working set of Python command line modules (interact with Sonia's breakout session on Tuesday?) to be included in the next release.
Progress
June 2007 Project Week
These are the results of the MIT project week (largely Dan's work)
- Implemented Python Modules
- Add search for Python in ModuleFactory
- Can put .py files in the CommandLine Module path
- Execute Python within Slicer
- Full access to VTK, vtkTEEM, vtkITK, etc.
- If the Python module provides an XML description, and an Execute function, will be added as a CommandLine Module
- Add search for Python in ModuleFactory
- ToDo
- Check-in (needs USE_PYTHON guards)
- Progress reporting
- Simplify the API
- Automate command line parsing using XML description
Later on, after the meeting
- command line parsing has been completed (in a very simple way, without needing access to XML)
- API has been simplified
