EIDORS: Electrical Impedance Tomography and Diffuse Optical Tomography Reconstruction Software

Hosted by

News

• 15 July 2009:
  The EIT-ventilation colourmap from Draegerwerk AG & Co. KGaA has been contributed to EIDORS for free commercial and non-commercial use.

• 25−26 June 2009:
  Preliminary work to integrate the TOAST software with EIDORS. Work by Andy Adler, Martin Schweiger, Bill Lionheart and Simon Arridge to get a preliminary version of EIDORS and TOAST forward solvers working together.

• 20−24 June 2009:
  EIDORS codefest in Whaley Bridge (UK). Bill Lionheart, Andy Adler, Andrea Borsic and Bartek Grychol got together to work on many different issues from conformal mapping and Total variation regularization integrating new data formats.

• 23 July 2008:
  Blobby the EIDORS walrus is releasing version 3.3 (www.eidors.org). This version incorporates many changes, bug fixes and code speedups. Since v3.3RC1, we have added the Sheffield MKI backprojection algorithm (thanks to David Barber and Brian Brown), added tutorials and made several small bug fixes. New features since v3.3 include: a) interfaces to FEM generation (distmesh, netgen) and dual model solvers, b) new algorithms (total variation, electrode movement solver, temporal solvers), c) a data repository with in vivo and simulated data and models, d) faster algorithms with better caching, and e) improved graphics and extensive tutorials.

• 16 June 2008:
  EIDORS tutorial as part of the EIT Conference 2008

• 13 June 2008:
  Blobby the walrus has decided to release the first release candidate of EIDORS v3.3 (EIDORS-v3.3RC1) on Friday, the 13th.

  This version incorporates many changes, bug fixes and code speedups since v3.2 (Aug, 2007). New features include: a) interfaces to FEM generation (distmesh, netgen) and dual model solvers, b) new algorithms (total varia- tion, electrode movement solver, temporal solvers), c) a data repository with in vivo and simulated data and models, d) faster algorithms with better caching, and e) improved graphics and extensive tutorials.

• 4 Mar 2008:
  New code to generally handle reconstructions with coarse and fine inverse models. This will take care of: 1) reconstructions on nodes rather than elements, 2) reconstructions to a raster output (such as GREIT), and 3) 2½D reconstructions.

• 22 Feb 2008:
  Andy Adler, Bill Lionheart, Andrea Borsic met with Nick Polydorides at MIT for the week. We made progress on a number of fronts including reintegrating Nick's 2D version of his code and validating it against Andy's. We made a start in incorporating MCMC methods in EIDORS and worked on boundary shape. Validation of 3D codes against each other showed a bug that had crept in to the forward solver in algroithms/n_polydorides which caused an error of relative size 1e-5 under some circumstances. We also had the great pleasure of meeting Gilbert Strang who introduced us to distmesh, which we are now planning to include in EIDORS.

• 24 Sep 2007:
  Tutorials to create netgen FEM models and simulation of moving objects in fine and coarse netgen meshes.

• 30 Aug 2007:
  Blobby the walrus would like to announce version 3.2 of EIDORS.

  EIDORS Version 3.2 is a significant improvement on the previous versions. The number and quality of tutorials has been increased. Bugs that have been reported have been (mostly) fixed, and the software carefully tested. Like always, EIDORS aims to facilitate using, testing, and development of reconstruction algorithms and models for EIT and other soft field tomography technologies.

  New features include
  − New algorithms (Temporal reconstruction, Electrode movement)
  − Repository for contributed data
  − Faster algorithms (better CGLS, Jacobian code)
  − Extensive tutorial: http://eidors3d.sourceforge.net/tutorial/
  − Improved links to netgen to generate finite element models

  EIDORS version 3.2 is available for download here: http://prdownloads.sf.net/eidors3d/eidors-v3.2.zip. As always, users are encouraged to report and bugs to the EIDORS maintainers.

• 24 Aug 2007:
  Andy Adler

  EIDORS v3.2 development. EIDORS has progressed significantly from the 3.1 release, and yet there has not been a new release. The only thing stopping us is a few bug fixes and a few remaining features. The following list is the fixes/features added preparing for 3.2.
  −Caching added to the m_3d_fields function in Nick Polydorides' code.
  −EIDORS is released under GPL 2 and 3. (ie It may be copied under the GPL 2 or GPL 3 terms)
  −Data repository formed for groups wishing to conribute data
  −Moved and renamed files
  −Fixed almost all the bugs in the bug list (with a few bugs posponed to v3.3)
  −New electrode movement code
  −Rewrote time solver
  −Lots more tutorials
  −Fixed caching bugs and added new priority scheme for cache

• 27 Aug 2006:
  Andy Adler & Bill Lionheart

  EIDORS Tutorial. About 40 of us got together at Kyung Hee University, Korea to review the capabilities of the latest version of EIDORS. Later we got to play with the EIT systems developed by Eung-Je Woo and his students at the Impedance Imaging Research Center.

• 22 Aug 2006:
  Andy Adler & Bill Lionheart

  Blobby the walrus would like to announce version 3.1 of EIDORS.

  EIDORS version 3.1 contains a considerable number of new features to facilitate using, testing, and development of reconstruction algorithms and models for EIT and other soft field tomography technologies.

  New features include
  − New algorithms (Total Variation, Kalman filtering)
  − Improved Matlab graphics
  − Faster algorithms (better CGLS, Jacobian code)
  − Extensive tutorial: http://eidors3d.sourceforge.net/tutorial/
  − Many more usage examples.
  − Improved links to netgen to generate finite element models
  − Bug fixes

  EIDORS version 3.1 is available for download here: http://prdownloads.sf.net/eidors3d/eidors-v3.1.zip. As always, users are encouraged to report and bugs to the EIDORS maintainers.

• 17 Aug 2006:
  Andy Adler

  An online tutorial has been written. You can access it here

• 28 July 2006:
  Andy Adler & Bill Lionheart

  There will be an EIDORS tutorial on 27 August in Seoul, Korea as part of the 7th EIT conference. The tutorial will be at Kyung Hee University (bus transportation provided from COEX conference centre)

• 28 June 2006:
  Andy Adler

  Modified EIDORS web pages for changes to SourceForge.net's cvs servers.

• 23 Jan 2006: EIDORS V3.1RC1 Released
  Andy Adler

  Blobby the walrus would like to announce the release of EIDORS-3.1RC1. This is the first release candidate for EIDORS 3.1. Users are encouraged to report and bugs to the EIDORS maintainers.

  EIDORS version 3.1 contains a considerable number of new features to facilitate writing of reconstruction algorithms and models for EIT and other soft field tomography technologies. New features include
  − New algorithms (Total Variation, Kalman filtering)
  − Faster algorithms (better CGLS, Jacobian code)
  − Many more usage examples.
  − Improved links to netgen to generate models

  As always, if your favourite feature is absent, or your least favourite bug is present, please make your comments to the authors

• 29 Nov−9 Dec 2005: Workshop on EIDORS software, Manchester, UK
  Andy Adler & Bill Lionheart

  The following software has been implemented

  • New (faster) Jacobian Calculator by Manuch Soleimani
  • Total Variation based image reconstruction from code by Andrea Borsic
  • Modification (and generalization) of EIDORS methods to allow more generic regularization, and data for Kalman filtering
  • Kalman filtering for difference EIT
  • Improved software to integrate Netgen with EIDORS
  • Detailed FEM model of ball moving in a vortex in a tank. (See animated image)
  • New inverse algorithms
    −Truncated iteration (Morozov criterion)
    −CGLS (with efficient sparse matrix handling)
    −Coarse / Dense mesh solver (thank to David Stephenson)

• 31 Oct 2005: EIDORS V3.0 Released.
  Andy Adler

• 30 Oct 2005: Modifications to allow EIDORS to be used with octave. Some bugs remain with octave optimization functions, and with sparse solver code; however, it is expected that these issues will be dealt with soon.
  Andy Adler

• 24 Oct 2005: Sample phantom data for cylindrical tank with 2D and 3D stimulations patterns contributed. examples/phantom_16elec_*
  Camille Gomez

• 19 Oct 2005: The EIDORS project authors, as well as their pet Walrus, would like to announce release of EIDORS-3.0RC1. This is the first release candidate for EIDORS 3.0. Users are encouraged to report and bugs to the EIDORS maintainers.

  EIDORS version 3.0 contains a considerable number of new features to facilitate writing of reconstruction algorithms and models for EIT and other soft field tomography technologies. Features include
  − Multiple algorithm support.
  − "Pluggable" code base to facilitate user modifications
  − Automatic caching to improve performance
  − Many more usage examples.
  − Sample data and mesh generators
  − Integrated test code
  − Improved 3D graphics

  The EIDORS authors hope to provide a software infrastructure that will assist technology development and practical applications of these technologies. To quote the authors of perl, "We aim to make easy things easy and hard things possible".

  Andy Adler

• 18 Oct 2005: Algorithms and code to illustrate Cheating with EIDORS. The goal is to illustrate potential pitfalls of this kind of numeric software, and to encourage people to avoid them.
  Andy Adler

• 14 Sept 2005: Algorithms from EIDORS2D from Marko Vauhkonen have been included in the algorithms/mv_2001 directory.
  Andy Adler

• 2 Sept 2005: 3D data from tank measurements contributed by Andrew Wilkinson and Bill Randall at U. Cape Town using their high speed Electrical Resistance Tomography equipment.

• 6 June 2005: Paper on EIDORS for VI EIT Conference (London, UK)
  Andy Adler, Bill Lionheart

  Our paper on EIDORS is available here

• 23 Feb 2005: Caching interface for EIDORS
  Andy Adler

  After thinking about how to implement caching for a while, I've finally implemented one approach. The idea is that each object must be 'hashed' to get an ID. If we calculate the image for data we've already seen, then we must be able to detect that fact.

  Some issues are:
  − We can't simply keep a pointer to previous variables. For example, the Jacobian is used many times. Each time it normally calculated for a homogeneous background, but the actual variable representing the background is different.
  − Cross-platform cross version support. We need to support (Unix + Windows) × (Matlab v6 + v7 + octave). Windows makes it difficult to 'shell' out to a helper program. The various software packages make Mex type functions a compatibility issue.
  − Matlab Mex file limitations make it difficult to get pointers to the raw data storage for variables.

  Design: The following design was chosen. In the eidors object constructor eidors_obj.m, and obj_id is calculated for each variable by saving it to disk, and then running the file through the SHA1 hash, and deleting the file. The mex file matrix_id.cpp is used to calculate the SHA1. Because the Matlab V6 file format puts a comment header with the save time in the first 125 bytes, it is necessary to begin the hash after that point.

  Questions:
  − Should the saved files be deleted? If not, it may be a nice way to improve overall performance. If files are kept, we need to user selected EIDORS_TMPDIR in which to put the files.
  − Not all cached data is useful. For example each measured data set will end up in the cache as currently implemented. One advantage of the current implementation, however, is the way that it can 'remember' if it has seen previous data without actually storing that data. This would allow user selection of which variables to cache.

• 23 Nov. 2004: Bill Lionheart
  Umer Zeeshan Ijaz <umer@cheju.ac.kr> from Korea has kindly contributed some code to help us find our electrodes in a netgen mesh.
  I have uploaded the code to the cvs on sf.net http://eidors3d.sourceforge.net/
  You should be able to see it on the browse cvs link (sometimes there is a delay) in the subdirectory meshing/netgen/ElectrodeInfo
  Several others have been working on the same problem and your contributions to automated electrode numbering are very welcome.

• 26 July 2004: Design of a caching interface for EIDORS
  Andy Adler

  Here are some references of other efforts that use a caching architecture for Matlab projects:

  • Kevin P. Murphy, Fast manipulation of multi-dimensional arrays in Matlab www.ai.mit.edu/~murphyk/Papers/fastmult.pdf
  • Of hash functions and rand by Xelax mathforum.org/epigone/comp.soft-sys.matlab/flomglumskem

• 13 July 2004: EIDORS Developers strategic meeting.
  UMIST: Bill Lionheart (chair) (WL), Nick Polydorides (NP), David Stephenson (DS), John Davidson (JD), Sharon Mohanna (SM), UCL: Lior Horesh (LH), Richard Bayford (AB), U.OTTAWA: Andy Adler (AA), Yednek Asfaw (YA), Brad Graham (BG),

  Minutes:

  1. Everyone introduced themselves
  2. It was agreed by all that the code circulated for this meeting that was not yet released would be treated as confidential, as the authors needed a chance to publish papers on their work first. When ready the authors can contribute it to the eidors3d source tree on sourceforge.net either themselves or via one one of those registered as developers.
  3. Current work in EIT and with EIDORS software was discussed.
  4. Standard file formats.
     (AA) As we develop project we have a chance to set a standard.
     (RB) Kevin Boon suggested standard data format in Ankara. Confidential medical data, patient owns it. Community has to be seen to respect medical data (eg name prognosis.). Phantom data not an issue. Cant just send a data file. Issue about type of system. Collection protocol, dynamic range, data scaling. Electrode placement within error. In real data another level, may need to preprocess to data. Do we want EIDORS to be a teaching tool or a more advanced tool. Reverse is to say what syntax EIDORS needs.
     (RB) Image format. SPN, statistical parametric modelling. What is output format. VTK? 30 Images different freq. Need for comparison of data.
     (AA) Symantic difficulty, cond on vertices, elements, mapping to cut planes. So what is image? Rasterizing.
     (NP) Test set for others to compare. Dist with EIDORS.
     (RB) OT, see Martin Schweiger's web site at UCL. There is lots of error checking in TOAST. This can be an issue when trying to adapt the code to a different application.
     (AA) Defining a new standard would raise political issues. On the other hand, simply saying that "this is what you need to work with EIDORS" is easier.
     Action: AA -- consult OT people (HD). Check with RB for head, JLD for Process Tomography.
     Models meshes -- standard file formats. Can we use standard ones? Iges, EDS, Universal File Format, SLT (parametric surface). Mesh quality factors.
     
  5. (AA) API and plugable algorithms.
     Want to easily plug in new idea and compare with named reference algorithms. API written so this is easy but also safe.
     (RB) Grid algorithms, multiple self contained program, moduarity.
     
  6. CVS version on source forge.
     Octave compatible using if statements to bypass matlab graphics. Matlab OO. Not well written. Use structures instead
     − data - measurements, units, time, comment, electrode positions, current pattern
     − fwd_model - FEM, electrode posn. and models, excitation / meas. patterns, electrode models
     − inv_model - hyperparameters, pointers to code
     − image - image data, pointers to fwd_model, inv_model
     Basic Methods:
     − fwd_solve, inv_solve, jacobian, etc.
     − methods call alg. specific
     − 'centralized' caching to avoid repeat calcs Demo_real modified on CVS tree to do this.
     Discussion on packing un packing
     AA explained the "copy on write" issue in matlab. If you assign one big array to another it does not make a copy until you assign to the old one. Care is needed to avoid meemory bloat.
     DS and LH wondered whether this structure is appropriate for computationally intensive problems.
     Action LH and DS to look at AA's structures and see how it would suit their problems.
     (WL) Are we prepared to make big changes now, such as changes to variable names. Yes, as long as we carry the main users with us. Proposed major changes will be discussed on eidors-3d listserv.
     
  7. Research Issues (RB) Cross continent funding? Grid computing -- no real applications? "e-science community"
     Action: AA to check on Canadian position. RB To check on Grid stuff. Large computing, para'l computing.
     (AA) Testabilty big deal in software eng. Not much work on numerical algorithms. Inverse problems and medical imaging.
     (RB) Design for testability
     (BG) Has MS in CS , code inspection at RMC s/w for nuclear inspection.
     (WL) Testing of of IP software, so that one transparently avoids any cheating, whether or not intended, seems to be an interesting issue.
     (RB) VLSI, scalability testing. TOAST experience suggests problem we might encounter when code grows. Do we need built in test methods in EIDORS as it grows?
     (AA) This is a great multidisciplinary collaboration. We need good testing now.
     Repositary for standard data and Meshes, as well as standard algorithms.
     
  8. (RB) Suggested giving EIDORS a higher profile on eit.org.uk to encourage contributions. (WL) Suggested that we consolodate changes with the main groups actively developing EIDORS first.
     
  9. AOB: The meeting thanked the AG coordinators, the video conferencing went well apart from a loss of audio.
     
  10. It was agreed to schedule a meeting in about two months with London and Dartmouth both joining us over AG as well. Action: HD, RB, AA, WL to check availability of their AG nodes.
      
  
  
• 4 July 2004:
  A. Adler

  EIDORS code now works with Octave as well as Matlab. Note that this is only for the numerical code; graphics are not supported. Also, since octave does not support some of the Cholesky and CG solvers, the solutions may be numerically less stable.
  
  

• 24 June 2004: Idea
  A. Adler

  EIDORS needs a logo. Should we have a blurry blob? On the other hand, it also has to look 3D? And, it also has to look OK when compressed really small.

  If you have some thing you'd like to contribute, Bill Lionheart

  
  

• 23 June 2004: Discussion
  W.R.B. Lionheart, A. Adler

  In order to further EIDORS development, we developed the following desirata for EIDORS software.

  • API design
    EIDORS needs a clean, well-encapsulated and easy to understand API. We do not feel that an object oriented API is particularly useful because: 1) the Matlab OO design is somewhat of a "hack" 2) such an OO interface would make portability to other languages less easy

  • Language portability
    EIDORS is primarily aimed at MATLAB. We would like to EIDORS to support Octave and Scilab, as far as possible. Currently, Octave and Scilab have the features needed by EIDORS (sparse matrices, 3D matrix support, etc.)

    In the core, it should be possible to have portability. However, Matlab graphics features are not supported in these languages. Our idea is therefore to separate the graphics functions from the core code. Graphics code would therefore be permitted to be language specific.

    Another desirable feature would be to support approaches to enhance execution speed: ie. C functions, multiprocessor support, etc. This is dealt with under plug-in algorithms

  • Platform portability
    EIDORS is intended to work on all platforms with support Matlab/Scilab/Octave. This means Unix/Windows/Mac OSX. In order to do this, we have the following rules:
    − No spaces in file names
    − The path separator is '/'
    − File names are lower case letters and numbers with optional underscores

  • Plugin algorithms
    Many users will want to use EIDORS infrastructure to test their own ideas. EIDORS should support plugging in such new algorithms or techniques.

    It is not obvious to us at this point exactly what features need to be added. Thus is is likely that some refactoring of the code will be required as we learn more about users needs. Please contact the authors with suggestions.

  • Reference algorithms
    One of the main goals of EIDORS is to allow people to compare their new fangled algorithms to those implemented by others. Unfortunately, the typical approach in this field has been to compare the new fangled to badly implement versions of others. Ideally, EIDORS will make it easy to do the comparison correctly, if desired.

    EIDORS should therefore offer: 1) use of the latest and greatest algorithms, and 2) use of specific algorithms corresponding to specific papers

  • Simple and transparent code-base
    EIDORS code is primarily aimed at numerical researchers. This means EIDORS should be:
    − simple. Code should be sufficiently small for an interested person to learn quite quickly
    − command line based. Code should expose it's capabilities and internal structure for inclusion into other algorithms. Graphic interface contributions will be accepted, but will be placed outside of the core.
    − modifiable. Many users will want to modify EIDORS to try their own ideas. This should be reasonably easy to do.
    −

  • Encourage contributions
    We want to find ways to encourage people to contibute:
    • Bug fixes
    • Sample data and meshes
    • Demo code and help files
    • new reconstruction algorithms
      also inproved forward solver (with higher order elements, BEM-FEM, etc.) modifications to algorithms (e.g. anisotropic conductivity)
    • and meta-algorithms (e.g. erroneous electrode detection techniques)
    • visualization (e.g. code to export to graphics packages such as mayavi)

  • Define subdirectories cleanly
    In order to separate algorithms and details.

  • File format
    It would be nice to define a EIT data file format that would facilitate interchange of data. We would be interested in receiving any suggestions about what such a data format would include.

    Things to include in the data file are
    − Time and date of each data measurement
    − Electrode locations / shape & size / contact impedance
    − Current & measurement patterns
    − The data itself
    − Sampling intervals
    − Description

    It would be convenient to put data into a structure.

  • Licence
    The licence for EIDORS is the GPL. Therefore, there are no problems with the following uses of EIDORS:
    • Selling EIT equipment with EIDORS on board, as long as the source code is available.
    • Using EIDORS with proprietary software like Matlab
    The following uses of EIDORS are barred by the GPL
    • Compiling EIDORS or a derived work and selling a system wihout access to both EIDORS and the software it is linked to.
    • Rewriting EIDORS in a different language and distributing it not under the GPL (eg. without source code)
    We are currently thinking about the scenario in which an EIT vendor provides EIDORS (including source) along with a proprietary add-on, such as a GUI. Email us if you have opinions on this issue.