Welcome!

[Bartek Grychtol]

Dear All,

Welcome, and thanks for joining the Open EIT file format discussion group. Hopefully, this will be a successful project that will make a lasting contribution to the community.

While we hope more people will still join, we would already like to start collecting ideas about the requirements of .oeit and possible solutions.

To kick off the discussion, we prepared a short of list of questions:

1. What do you think about the key concepts of our proposal (zip-file technology, mandatory standard storage in Volts and optional binary storage)?
See:  https://docs.google.com/open?id=0B8Yc4c86UHemcjBqLVNxRHFTMHVXMlNBajlXbXlaZw

2. What information about
   - the domain/subject
   - the electrodes
   - the measurement technique
   - the course of the measurement (events)
should an .oeit file provide to be self-contained for YOUR application?

3. Which of the above should be considered mandatory and which optional?

4. What additional signals should we be prepared to store (e.g. ECG, pressure)? What requirements should we have of such additional signals?

5. What tools do we need to develop (e.g web-based file validation) ?

6. How can you contribute? (Just comments is perfectly fine, but we'll also need programming/writing input at some point)


We're looking forward to your comments and a fruitful discussion.

Best wishes,

Bartek Grychtol
Pascal Gaggero
Andy Adler

[Andy Adler]

Hi Bartek,

Some initial comments:

> 4. What additional signals should we be prepared to store (e.g. ECG,
> pressure)? What requirements should we have of such additional signals?

- It's important to keep the timing/order information correct. It
should be possible to tell what order the measurements were made
in case someone wants to do Kalman or Temporal filtering later.

- It should be possible to store external labelling. Example,
for an experiment we have a control (C) and experimental (E)
parts while the EIT system is running.

In the analysis program, the user labels part of the signal
as C and E. This needs to be stored somewhere so that it
can later be used for analysis.

Thanks for the nice work.
--
Andy Adler <ad...@sce.carleton.ca> +1-613-520-2600x8785

[Pascal Olivier Gaggero]

Hi Andy,

thank you very much for starting the discussion!

It's important to keep the timing/order information correct. It
 should be possible to tell what order the measurements were made
 in case someone wants to do Kalman or Temporal filtering later. 

I suggest to store any information on a frame to frame basis. A frame being the time lapse necessary to acquire one image. Thus in the binary file where such data are stored, we could also store timestamp associated with each data set. Then if you know the sample rate you could even calculate the time associate with each individual sample.

It should be possible to store external labelling. Example,
 for an experiment we have a control (C) and experimental (E)
 parts while the EIT system is running.

I did not fully understand this; are you suggesting to store some kind of experimental protocol associated with the acquired data?

Pascal

--
Dr. Pascal Olivier Gaggero

voice: 0041 79 228 43 39

skype: rameur_1

[Pere J Riu]

Hi everyone,

thanks for starting this work. It is a topic that interested me in the past (if you like archeology, take a look at: P M Record and P J Riu 1992 Raw data interchange format for electrical impedance tomography. Clin. Phys. Physiol. Meas. 13 201 doi:10.1088/0143-0815/13/A/039 --- I am NOT suggesting to use this).

Now, some preliminary comments on the ideas that have been exposed so far.

-- Adding timestamps is essential. millisecond resolution should be enough?, or should we go further into the microsecond realm?. 

-- timestamping frames sould be easy. Timestamping individual measurements is not. The time difference between individual measurements within a frame depends a lot on the acquisition hardware/software desing, an in general cannot be calculated based on a sampling rate. But I don't think it is necessary to know.

> 1. What do you think about the key concepts of our proposal (zip-file technology, mandatory

> standard storage in Volts and optional binary storage)?

Should the "satandard" storage be in OHM instead of being in VOLT?

Regarding my availability, right now I can contribute with comments or even beta-testing more than with programming.

  Prof. Pere J Riu

  DEE-UPC

  c./ Jordi Girona, 1-3, Edifici C4, 08034 Barcelona, Spain

  tel.: +34 93 401 6768   FAX: +34 93 401 6756  pere...@upc.edu

[Pascal Olivier Gaggero]

Dear Pere,

Thank you for your comment and availability.

Should the "satandard" storage be in OHM instead of being in VOLT?

Just to better understand your suggestion  about storing the data in OHM. Did you mean each voltage measurement should be normalized by the current? If yes, which current value should we consider 1) the theoretical current amplitude or 2) a measurement of the effective current sent, which could be different for each electrode pair and be changing with time?

Pascal

[Alistair Boyle]

On Wed, Mar 28, 2012 at 5:22 AM, Pascal Olivier Gaggero <pas...@gaggero.ch> wrote:

Should the "satandard" storage be in OHM instead of being in VOLT?

Just to better understand your suggestion  about storing the data in OHM. Did you mean each voltage measurement should be normalized by the current? If yes, which current value should we consider 1) the theoretical current amplitude or 2) a measurement of the effective current sent, which could be different for each electrode pair and be changing with time?

I could see an issue with this over longer time frames where the contact impedance varies as the electrodes age. Any normalization of the data should be accessible to the consumer of the file format.


One practical aspect to consider: When we speak of text formats for interoperability it can become quite time consuming to convert back to floating point/fixed-point data over a large data set (sometimes overwhelming the actual data processing time). On the other hand, a binary format immediately runs into endianness issues. The endianness, at-least, can be addressed by selecting either big or little-endian at the outset or adding a flag to indicate which is in use. With the data stored as single, double, quad, etc. precision, variable accuracy can be addressed. (We start looking somewhat like a .mat Matlab file format at some point, but this wouldn't be a bad place to mine some common sense ideas from, being widely used, etc.) HDF5 would be another place to look for large, scalable, open-source format concepts. Specializing something based on HDF5 would allow for a somewhat trivial implementation through a wrapper layer on top of the freely available base layer of software.

http://www.hdfgroup.org/HDF5/


Finally, addressing the accuracy of measurements: this will be dependent on the equipment and the particular measurement scenario. I'd think that recording to some arbitrary equipment specific accuracy and having the equipment's best estimate of what that accuracy is, stored in the file, would address this concern while maximizing post-processing possibilities.

Alistair

[Kaufmann, Steffen]

Dear All,

 

first of all I would to thank you for work you done. I think a common EIT file format standard is overdue. In my opinion the idea of organizing the EIT data in a zip folder with XML based files is really nice, because it's on the one hand easily extendable and on the other hand easy implementable on a PC (and human readable which helps a lot during bug tracking).

 

Features which should be added are:

- Patient/proband data (like name, age, examiner, or just a number which leads to this personal information)

- Some kind of notes or free text fields should be added for comments or notes ;)

- optional encryption (easily implementable with zip) - for data privacy protection

- as already mentioned - a time reference - I think a resolution of 1 ms is totally fine, but the question is what should be referenced? A measurement or a frame? In case of equidistant sample points also a frame or frame/measurement number would be fine. With these reference also the labeling Andy mentioned is possible - as suggestion in a different file called lables.xml

 

May be there are also much more additional requirements from the clinical users? Do we have some in this discussion group?

 

According to the storage question: As I understand it, the storage allow both transfer impedances and raw data, therefore there is no need to decide for Ohms or Volts?

 

To the question how we can contribute: Me and my work group can provide programming man power, commenting and tests of the implementation.

 

Mit freundlichen Grüßen / Best regards

 

Steffen Kaufmann, MEng

 

Scientific Research Assistant
Centre of Exellence for Technology and Engineering in Medicine (TANDEM)

Building 17, Room 2-16

Luebeck University of Applied Sciences

Stephensonstrasse 3

23562 Luebeck, Germany

 

Tel. +49 (0) 451 / 300 - 5400

E-Mail: kauf...@fh-luebeck.de

http://www.fh-luebeck.de

http://tandem.medisert.de