Main concepts and general OEIT file structure

[Pascal Olivier Gaggero]

Dear all,

We (Bartek, Hervé, Andy and I) would now like to propose writing a
"whitepaper" with a more detailed description and examples.
To this end, we'd like to begin a structured discussion to form a consensus
in this group as follows:

1)      Main concepts, general OEIT file structure (reproduced from the
various abstracts below)
2)      A simple configuration file example
3)      An advanced configuration file example
4)      Patient metadata
5)      Electrode metadata

 

We have so far three abstracts proposing OEIT and presenting some general
concepts:
https://docs.google.com/file/d/0B8Yc4c86UHemNVMwWTQtZGtINEU/edit?usp=sharing

So far, this is the proposed structure of an OEIT file:

This folder / file structure is stored in a single ZIP archive. The folders are organized as follow:

·         “version.txt” stores the OEIT file version, e.g. 1.0.0

·         “Header” stores file-invariant files, e.g. patient and electrode information

·         “raw” stores manufacturer's raw EIT data (i.e. also in a proprietary format).

·         “eit” folder stores the manufacturer-independent EIT data. This folder is
subdivided into subfolders: 1) “data” that stores the binary information,
2) “config” which stores XML-formatted file describing configuration and 3)
“log” that stores XML-formatted events. In the “data” folder the binary
files with the extension .sframes are stored, see below. Inside each file
many frame are stored and each individual frame store an index pointing
toward a corresponding configuration file. The frames are stored in each
binary file in chronological acquisition order. The manifest file, stored
into the “eit” folder, describes how the frames are stored into the binary
files. The main purpose of the manifest file is to allow quicker browsing
of large data files.

·         “userData” stores every other filer and folder, e.g. screen shots, analysis results,…

·         “auxiliary[nn]” stores data stream that are not synchronal with the one stored into “eit”. The data stored in this folder follows the same standards as for the “eit” folder




The configuration file(s) describes the way the data were acquired and
provides enough information for correct interpretation and image
reconstruction. The basic idea behind the architecture of those
configuration files is that complex data acquisition scheme have complex
description file whereas simple acquisition scheme are easier to describe.
The XML format has been selected to avoid formatting and charset issue
associated with standard plain text file. Moreover XML format allows more
flexibility for future format improvement and new features.





The main data are stored into binary format to optimized storage size and
performance. The number and size of each file inside the eit/data folder is
selected to optimize file handling performances or to organize the data in
a logical way. This organization is described into the manifest file. The
manifest file is an XML-formatted file, which describes how frames are
stored and enables to find a particular frame without the need to read all
binary files. Each binary file is sub divided into data blocks. Each data
block follows the same scheme: 1) timestamps uint64, 2) reference to the
configuration file identification number [c_file_id] uint16 and 3) binary
eit data, see Figure above. The content and organization of the binary eit
data is given in the configuration file by the content of the binary and
measurements tags.



Let's make sure we're all happy with this general structure. We can then
move on to the finer details.

We are looking forward for your comments,


Bartek, Hervé, Andy and Pascal

[Andy Adler]

Hi Pascal,

Thanks for writing up this framework description.

My interest would be to use OEIT as a neutral file format so that

EIDORS can convert "legacy" files into OEIT, which can then be

processed. 

In many cases, older file formats don't make a lot of meta information

explicit. (no record of the stimulation protocols, gain, etc.)

In this case, there should be a standard way of recording "I don't know"

into the OEIT files.

Thanks

--
Andy Adler <ad...@sce.carleton.ca> +1-613-520-2600x8785

On 26 February 2013 05:21, Pascal Olivier Gaggero <pas...@gaggero.ch> wrote:

a

--
You received this message because you are subscribed to the Google Groups "Open EIT Format" group.
To unsubscribe from this group and stop receiving emails from it, send an email to open-eit-form...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[yvo.g...@draeger.com]

Hi pascal,

 

i doubt that a zipped sub-folder-archieve in it will be very practical if one will analyze a series of eit-files (ie multiple subsequent eit-files for a peep-ramping of one patient).

currently i tend to analyse file-sets of 10-20 eit-files each a few minutes long at ones. unzipping and switching the folders for each piece sounds at least to me a bit impractical

in my opinion all necessary information should be stored in one file from which one can direct read and switch to the next and so on.

 

but may be i understood it wrong.

 

 

 

[Bartek Grychtol]

Dear Yvo,

From the user's point of view, there should be absolutely no difference between a series of manufacturer-specific .eit files and a series of OEIT files.
It's only the file parser that will handle the zip directories.
That being said, OEIT (as proposed at the moment) also has that advantage, that the 20 separate recordings could all be stored in one OEIT file (provided, of course, that the user is happy with the size of the resulting file).

Best wishes,

Bartek

 

 

 

--

[Andy Adler]

Hi Yvo,

It is definitely worth thinking about the container format. The format
should be invisible to the application. This can be done, as is shown by
the new microsoft formats (docx is just a zip file).

The disadvantage is a small increase in the complexity of the data writing
software.

However, the advantages are significant. For me the biggest advantage
is the improved flexibility. If you read new data, it can be added to the
format without changing the original material.

Are their other disadvantages of the zip format that we're not aware of?

--
Andy Adler <ad...@sce.carleton.ca> +1-613-520-2600x8785

[Pascal Olivier Gaggero]

Dear Yvo,

thank you very much for your comments, I think it is very much up to the user how he is organizing the information storage inside the OEIT file(s). In your case, you could choose to make an acquisition of, for example, 10 sequences that would produce 10 oeit files. Then in a second phase you could have a script which aggregate all the data in one single OEIT file with an additional signal, in your case the peep parameter. Additional signals will be discussed soon on the forum as well. Alternatively you could also have stored the EIT data along with the PEEP value directly in the same file while doing the acquisition.

Does this answer you question?

regards from Switzerland!

Pascal

2013/2/28 <yvo.g...@draeger.com>

 

 

 

--

You received this message because you are subscribed to the Google Groups "Open EIT Format" group.
To unsubscribe from this group and stop receiving emails from it, send an email to open-eit-form...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
Dr. Pascal Olivier Gaggero

voice: 0041 79 228 43 39

skype: rameur_1

[Pascal Olivier Gaggero]

Dear Andy,

The complexity of writing encoder/decoder for EIT as far as the zip-encoding/decoding is concerned, should not be that complicated because zip encoder/decoder are available in many coding languages (c#, java, matlab, embedded platforms....)

I would also be interested to know if someone is aware of any drawbacks.

Pascal

2013/2/28 Andy Adler <ad...@sce.carleton.ca>

--