|
|
| (6 intermediate revisions by 3 users not shown) |
| Line 1: |
Line 1: |
| − | Presentations:
| + | <big>'''Note:''' We are migrating this content to the slicer.org domain - <font color="orange">The newer page is [https://www.slicer.org/wiki/Slicer3:Architecture/Features here]</font></big> |
| − | | |
| − | * [[Media:Slicer_3-alpha-2006-04-03.ppt|Slicer 3 Architecture Presentation 2006-04-03]]
| |
| − | | |
| − | The main goals of the slicer3 re-work are:
| |
| − | | |
| − | * Provide a clean, well-defined, flexible and functional application structure for medical image computing developers and users
| |
| − | * Learn from user and developer feedback about earlier versions of slicer as well as other packages with similar goals
| |
| − | * Maximize the re-use of code by making it easy use pieces of slicer in other environments and to plug diverse pieces of code into the slicer model
| |
| − | | |
| − | At a high level, these goals are to be implemented through:
| |
| − | | |
| − | * A data-centric approach in which the '''Data Model''' (implemented as a follow on to the MRML Tree) is implemented independent of the visualization and algorithmic components of the system
| |
| − | ** The Data Model API allows adding, deleting, reading, and modifying medical image data types (Volumes, Models, Transforms, Fiducials, etc).
| |
| − | ** The Data Model provides functionality to serialize and deserialize the contents in an XML structure
| |
| − | ** The Data Model API is structured to allow the either direct access (in the same process space with the algorithms) or through a client/server connection.
| |
| − | ** A set of Adaptor Classes will be provided to allow access to the Data Model API through ITK Image Readers/Writers, VTK Image Readers/Writers, and command line utility commands. These adaptors will support access to the data by programs that have not specifically been written to support the slicer Data Model.
| |
| − | | |
| − | * An '''Execution Model''' in which algorithmic functionality is encapsulated such that they can be used in one of several modes:
| |
| − | ** as stand-alone command line executables (for use in testing or to be called from batch scripts; these executables are also important to enable grid/distributed computing)
| |
| − | ** as shared libraries linked into a parent application (i.e. brought into the slicer application address space where the classes can be instantiated and methods invoked with data passed as pointers)
| |
| − | ** a framework to enable algorithm developers to efficiently code these execution modules will be provided using ITK
| |
| − | | |
| − | * A '''UI''' application interface that
| |
| − | ** presents a consistent and modern look and feel to end users
| |
| − | ** a 'thin' application layer that is independent of the data and execution implementation
| |
| − | ** a UI description language (XML) so that execution modules can be 'self describing' in terms of their parameters so that, for example, the UI elements can be provided through a --xml-help command line argument
| |
| − | ** a class hierarchy of reusable UI Widgets that enforce consistent look and feel and can be used in multiple modules
| |
| − | ** UI widgets that are 'aware' of the Data Model, UI, and other slicer3 elements to support high level operations (e.g. a coordinate system browser, a volume properties editor, a view controller, etc).
| |
| − | ** A 'trace' capability in the UI to support scripted tests and demos (possibly also user macros).
| |
| − | | |
| − | * A '''Visualization''' Environment customized for medical image processing (VTK based)
| |
| − | ** A framework for representing and displaying elements of the Data Model with sub-voxel accurate rendering
| |
| − | ** Ability to represent and display composite scenes with volumes, models, landmarks, and fiducials
| |
| − | ** Ability for modules to add transient display elements (e.g. glyphs and widgets) to support interaction
| |
| − | ** Cross platform high performance rendering infrastructure
| |
| − | ** a framework to support module development
| |
| − | | |
| − | * Other global features and requirements
| |
| − | ** Cross platform to at least: Windows, Linux, Mac. Solaris, SGI, AIX desirable but not critical.
| |
| − | ** As much code coverage as possible in nightly testing
| |
| − | ** Integrated with CPack for distribution and installation.
| |
