CIBC:Collab:MakeigWorrel
From NCRR Biomedical Software Development, Engineering, and Dissemination Wiki
Contents |
Project Description
The goal of this project is to support research that aims to bring MEG/EEG source localization into the epilepsy clinic. By evaluating and localizing the source of epileptic seizures one hopes the surgical procedures in which brain tissue is removed in order to stop the seizures. The project aims at using independ component analysis to split the temporal signal into independend signals and then apply a source localization algorithm to find a dipolar source in the brain.
Project Status
Exploring what components are needed for this project.
Project Progress/Development
Talked with Carsten on the modeling of the head and tried to figure out what the NeuroFEM/Curry software he currently uses cannot do in terms of modeling. It seems they have problems with modeling a set of intercranial electrodes that are mounted on a insulating plaque. The problem of course is that there is a large gap in conductivities between insulator and the surrounding tissue. As the sources are directly underneath the plaque, proper modeling is required. It seems we need a remeshing and fitting scheme here. The first thing to do is probably implement algorithms to reshape the brain/CSF interface to accommedate the shape of the electrode plaque, add options to make a hole in the mesh (holes are in effect insulators), add tools to detect actual locations of electrodes and add local refinement methods (mesh and data refinement: the underlying fiber orientations in the elements need to be interpolated)
--Jeroen
Software development
Technical Requirements for PSE
Program Infrastructure
- Resource (Memory/CPU) management
- Working interactively with large datasets requires that data can be stored in memory and on disk.
- Dividing algorithms into small reusable components will require a lot of memory if data is stored in memory to keep interactivity alive.
- Optimization between using a lot of memory and being fast or more memory and being slow. For example for a small data set you want to store eigenvalues of a tensor, for bigger datasets keeping intermediate results will cause a lot of swapping memory and could lead to running out of addressable memory space.
- Component model: Algorithms should be fairly general and exchangable. The data quality of input varies and the goals of the simulations vary as well: hence a component model would be required, with a user interface in which components can be interchanged/omitted/added.
- Automation: Automation should be available from the interface.
- Often reoccuring scenarios are doing parameter sweeps in different domains, trying different segmenation parameters, using different membrane parameters.
- Most software uses a simple list of parameters to guide the process. A similar concept would make it easier to interact with other software. For instance CardioWave uses a textfile with parameters, most Matlab oriented software in this project uses similar parameter lists.
- Parameters to controlling application: filenames, scalar values (vector and tensor value (e.g. conductivities)) and strings (e.g. membrane models)
- External Application Interface: A mechanism to run simulations at in a different process at a different computer.
- To setup a simulation the model should be able to be export in the fileformat of the simulator
- Simulation software often requires MPI, stability and hence should run as a separate program. Since simulations in the project take time interaction is not stricly needed.
- The mechanism supported should be reliable and should support to run a simulation without crashing (simulations can take days to complete)
- It would be nice to access the NeuroFEM solver directly from the Problem Solving Environment.
- Annotation: We should have the ability to gather parameters in a simple text document (or something similar) to annotate simulations. Being able to figure out what kind of parameters were used in a simulation is valuable.
- Annotation should be preferably be generated automatically or should be scriptable, this will ease the task of the scientist.
- Keeping a log of operations performed.
- Algorithmic separation:
- Store algorithms in libraries which have standard options for error reporting and informing the user (abstract methods that can be separated from actual GUI, giving feedback e.g. warnings etc to the user is important)
- When we have figured out a way of image to model that works for a lot of cases, one wants to be able to quickly rewrite the component GUI program to a full stand-alone program.
- When having a combination of mesh generation tools that work, one may consider a program that can be called under Matlab/Mathematica without GUI for certain basic tasks.
Algorithms
- Segmentation algorithms
- Mesh generation algorithms
- Mesh editing algorithms:
- creating a hole in the mesh (for insulator)
- Fitting a model of an electrode inside a mesh.
- Mesh refinement tools to add more density at places where we expect a large gradient in the electric field
Data Representation
- Import/Export of "simple" data formats: text files (for example matrices in rows and columns), data blocks of a certain data type with a small header file preferably in ascii (like nrrd). Usage of the current SCIRun native file formats requires linking against a lot of C++ classes and SCIRun infrastructure, which is an obstacle in linking against other programs.
- Import/Export of parts of datasets (Simulation data can run in Gbytes of data and storing all in memory becomes problematic)
- Support for multiple data entities attached to one mesh
- Currently SCIRun allows only one type of data on a mesh, hence a lot of duplication of pipelines mark the current networks. Models seldom have one entity attached to a mesh often one needs to think of conductivity tensors, membrane types, tissue types (segmentation), etc.
- Unstructured meshes: Hexhedral/Tetrahedral/Quadrilateral/Triangular elements: Full support for both hexahedral and tetrahedral elements ranging from segmentation to stiffness matrix generation.
- Structured meshes: MRI data/confocal data often is a regular multidimension matrix.
- Automation: representation of filenames, scalar/vector/tensor parameters is need for automating networks.
- Bundling projects: Models often consist of a collection of matrices, meshes, and parameters, bundling everything into one file/directory is useful as an organizational tool. Being able to systematically organize data of current and past simulations is something that makes life easier and will lead to a higher degree of automation and more productive scientists.
- Support for a dataset spread over multiple files and selecting part of the data.
- The newest version of CarioWave regenerates multiple files while the simulation is running. Examining a few files will allow the user to look at certain timespans of the data.
- Support for time depend data
- time scale can be irregular hence we need a kind of lookup system for actual time
- supporting time with in the geometrical objects
User Interface
- Comparison mode: One of the most useful features in SCIRun/Map3d is the dual/triple display mode to compare different datasets in displays that are locked. If we keep the SCIRun platform it would be useful to extend this to BioImage/BioTensor. What one wants to do is comparisons between datasets.
- 2D/3D widgets for marking parts of a mesh:
- Marking of locations (constraint to volume or surface or unconstraint floating in 3D volume)
- labeling widgets, e.g. different colors for stimulus electrodes and reference electrodes, adding text to widgets.
- 2D Image viewer:
- Draw/compute segmentation: automated segmentation with options for user to override segmentation made
- Overlay of different segmentations/ properties computed on the mesh/
- Annotation of slice, e.g. slice number, slice size, slice normal in physical space etc.
- Synchronized displays (e.g. sync slice number or actual z postion etc.)
- 3D data viewer:
- Transparant surfaces
- The option to switch on and off surfaces/meshes (e.g. as currently in SCIRun)
- Synchronized displays (for comparison mode)
- Display of legend, model parameters used etc in figure.
- Graph viewer (line graphics, display function in time):
- Options to draw matlab like figures, with extensive options to set units, titles, grids, scales, etc.
- The interface should allow for creating images that can be used in publications: being able to choose amount of colors, write decent title headers, have possibility to select resolution, being able to added axis, adding symbols, being able to add legends.
- The interface should allow for multiple graphs on top of each other.
- Draw time curves of data: being able to get time signals and display them in a graph
- Annotation of graph viewer: title, legend, axis names/numbers/units.
- Multiple lines in one graph with different colors
- Irregularly spaced x-axis for time data: the project probably requires adaptive time steps and thus sampling is not regular
