SimpleITK/Scope: Difference between revisions
From KitwarePublic
Jump to navigationJump to search
(Created page with '__TOC__ = Current open questions = * Internal execution mechanism ** switch statement, supported by macros ** Factory mechanism, new image types could be added at runtime ** Me…') |
Daviddoria (talk | contribs) |
(No difference)
|
Revision as of 16:00, 9 December 2011
Current open questions
- Internal execution mechanism
- switch statement, supported by macros
- Factory mechanism, new image types could be added at runtime
- Meta-programming
- Datatypes
- What to support "out of the box"?
- How easy/difficult to add new datatypes to a build?
- Compile times
- Templates radically extend CPU and memory requirements
- Library size / scope
- Custom SWIG files vs. automatically generated SWIG
- Automation for SimpleITK facade generation from ITK classes?
Suggested Areas to Cover
- IO
- Basic Filters
- Registration
- Basic Framework
- Deformable registration
- BSplines
- Demons
- Segmentation
- Region Growing
- Level Sets
- Classifiers
- Meshes ? (Not Yet)
Types
- Image pixel types supported
- int8_t
- int16_t
- int32_t
- float
- Image dimensions supported
- 3D
- Is 2D managed as a 3D image of 1 slice ?
- Performance penalty for neighborhood filters... ?
- Could be "2D" versions of 3D filters, i.e. RecursiveGaussianFilter2D. This would work on a slice-by-slice basis.
Languages
Wrapped languages will be any that SWIG supports, if someone is willing to write tests / any needed glue code.
- C++ Layer
- Python
- Lua
- Java
- ?