Storing several channels into a single matrix

[gBringout]

Right now, the data coming from several channels are stored in concatenated vectors.

Even if, provided enough informations, a pre-processing step can be added to separate all channels, I would like to open the discussion to determined if it could be better to add an additional dimension to the matrices/structure to saved each channel separatly.

For me, the advantages are:

1. Better readability
2. Better understanding between a measure and the hardware
3. More flexibility to select the used channels
4. Avoid error assuming that the frequency components (after filtering) are the same on each channel

Disadvantages are:

1. Not compatible with the published dataset so far (2 datasets published)
2. One additional dimension to deal with

What do you think?

[tknopp]

Compatibility is nothing we should worry about at this time point. So this is not a disadvantage at all.

Your point is absolutely valid and in our internal software package we handle "Brukerfiles" much like you described. So a measurement file has 3 dimensions:

dim 1: time points / frequencies dim 2: receive channels dim 3: number of scans

Once we apply frequency selection (filtering) the frequency and receive channel dim have to be merged though.

The main reason to merge the dimensions in the file were to make it as easy as possible to do a reconstruction (i.e. the system matrix has two dimensions as expected in linear algebra).

So your proposal would be

measurements: numFreq x numRecChan x numScans

But what about the system matrix? Should it be

numPositions x numFreq x numRecChan

or

numPosX x numPosY x numPosZ x numFreq x numRecChan ?

The later has the disadvantage that the number of dimensions depends on the imaging dimension.

ping @hofmannmartin

[tknopp]

I am just realizing that my Julia and Python code is filters only the frequencies of the first channel.... :-)

[MandyA]

Hey there,

I like if ToDos on my list are solved overnight :D Thanks Gael for the Matlab-Code! And a lot of thanks for the initiative! It will be very helpful to have a standardized data format.

However, I have some additional thoughts about the specific format:

1.  There is a parameter numPatches and as I understand it several patches are stored consecutive in data. Is there already a possibility to store the individual positions (and sizes) of the patches?

2.  Is it planned to add methods that transform the Bruker data to MDF? If so, I could contribute our Matlab code in the institute that I wrote (it’s based on Tobis Julia Code anyway ;))

3.  I would appreciate if for the calibration group there would be a parameter that indicates if it is a measured or a hybrid system matrix (or even a modeled one).

4.  I’m uncertain about this point, but I think it might be nice to add the possibility to store the transfer function if available.

5.  In terms of sequence description: from my experience just sinusoidal signals is not enough to describe sequences. E.G. a linear shifted FOV (as done by Jürgen) cannot be described appropriately. However, I think it is quite tricky to cover all possible sequences.

6.  It would be great if not just experimental data but simulation data as well would be stored in MDF. In several cases our collaborators like to start with modeled (ideal) data. Currently, I do not see an issue with that. I was just wondering if we should give a guideline in the scanner-group how to differentiate these two cases.

Since Gael started the Matlab-Code I do not want to interfere. Gael, if you need help regarding the other Kaczmarz implementation just let me know. @Tobi, Martin, Thilo: If there is something else I can contribute just let me know. Thanks again for the initiative. I actually talked some month ago with Anselm that we should standardize our measurement and simulation data storage. I think this is the far better solution than I had in mind.

Best, Mandy

Von: Tobias Knopp [mailto:notifications@github.com] Gesendet: Dienstag, 29. Dezember 2015 00:54 An: MagneticParticleImaging/MDF MDF@noreply.github.com Betreff: Re: [MDF] Storing several channels into a single matrix (#4)

I am just realizing that my Julia and Python code is filters only the frequencies of the first channel.... :-)

— Reply to this email directly or view it on GitHubhttps://github.com/MagneticParticleImaging/MDF/issues/4#issuecomment-167680902.

[hofmannmartin]

Regarding the question of @gBringout.

In my opinion we should include the channels as separate dimension as this also makes frequency selection a lot easier.

@tknopp Adding dimensions to the system matrix on the other hand only works as long as the system matrix is measured on some sort of grid. In my opinion this could be too restrictive.

[gBringout]

I think that it is better to keep the different receiver channels coded in a additional dimension.

So: It will add some lines in each reconstruction code (the user will have then to concatenate himself if he want to reconstruct several channel simultaneously). And the number of element in this dimension will depend on the used hardware (the number of receiving channel), but this is already one big difference between scanners (2 receive channels for some FFL and 3 for 3D FFP scanner). I think it will make everything clearer

Regarding the way the position are stored, as the sampling on a Cartesian grid is not the only solution (see for example compress sensing), I would keep a single dimension for the spatial dimension of the system matrix. Another parameter should indicate how it was sampled.

So I am for: measurements: numFreq x numRecChan x numScans system matrix: numPositions x numFreq x numRecChan ?

@MandyA : could you perhaps open an issue for each of your points? (and perhaps clean the message in this thread to keep only what belongs to this discussion :) )

edit: cross post with @hofmannmartin, I haven't seen his post. I agree with him.

[tknopp]

Ok, we have agreement. I will update the Latex code and close lets close this issue once everything is in place.

Will open new issues for Mandys points.

@MandyA @gBringout: Please feel free to also improve the Latex document.

[tknopp]

I updated the specification, the julia/python code, and the data. Please review. Two things to be mentioned:

• I made the focus field dimension optional
• the SNR also has a channel dimension now

[tknopp]

@gBringout: Thanks for having a look. I reopen this issue since your matlab code has to be adapted to the new file format. Please close once you have adapted it. Thanks!

[gBringout]

Sorry for the early closing :) I have merged my code!