request for different parameters

[MandyA]

We are currently changing our whole structure to MDF (simulation, measurement data, ...) and have some parameter requests:

• In the group tracer it might make sense to specify a diameter of the tracer. This would be helpful, if the data was acquired by simulation.
• For nearly all values that specify some array dimensionality there is a seperate parameter (e.g. numPatches, numFrames). For two values this does not hold: number of frequencies K and number of spatial points N. It would be convenient to add both as paramter to process MDF files more easily. However, for spatial points I'm uncertain if there should be a parameter in group calibration and group reconstruction, since both are completely optional. I think there is some further discussion necessary - I'll make a separate issue for that.
• for hardware development it would be usefull to save the feedback data additional to the measurement data. This would affect groups acquistion/receiver and measurement. I would like to add datasets containing the feedback signal.
• in group measurement the data is stored withouf TF correction so far, isn't it? It would be convenient to add the fields dataFDcorrected and dataTDcorrected, such that users can directly extract the data for further processing and without knowing how to correct for the TF.

[tknopp]

In the group tracer it might make sense to specify a diameter of the tracer. This would be helpful, if the data was acquired by simulation.

fine, mean value and standard deviation would make sense.

For nearly all values that specify some array dimensionality there is a seperate parameter (e.g. numPatches, numFrames). For two values this does not hold: number of frequencies K and number of spatial points N. It would be convenient to add both as paramter to process MDF files more easily. However, for spatial points I'm uncertain if there should be a parameter in group calibration and group reconstruction, since both are completely optional. I think there is some further discussion necessary - I'll make a separate issue for that.

I personally do not see an urgent need since N is just the product of size and K is the length of frequencies

The issue is always parameter inconsistency. So if two parameters are inconsistent, which is the one to rely on.

for hardware development it would be usefull to save the feedback data additional to the measurement data. This would affect groups acquistion/receiver and measurement. I would like to add datasets containing the feedback signal.

yes, in principle this is fine. Could you have a look at your format and the one from Bruker and derive a common solution?

in group measurement the data is stored withouf TF correction so far, isn't it? It would be convenient to add the fields dataFDcorrected and dataTDcorrected, such that users can directly extract the data for further processing and without knowing how to correct for the TF.

have to think about that...

[MandyA]

I personally do not see an urgent need since N is just the product of size and K is the length of frequencies

The issue is always parameter inconsistency. So if two parameters are inconsistent, which is the one to rely on.

You are right, it is possible to determine the paramters. But in a way, the same holds true for numChannels or numPatches - you just have to know which array to read. The way I see it, the specific definition of numChannels, numPatches, numAverages,... is a possibility to define the size of an array. Since now I never thought about these parameters, but implementing MDF for our simulation and experimental data shows that it would be nice to know the parameter before initializing the arrays depending on it.

[profix898]

Similar to #43, I would suggest that we add a group with more parameters of the tracer/phantom. However, I dont think that we can capture enough information on the tracer/phantom in MDF, so that it provides all the required properties/parameters for a simulation environment. At least for us, we have a separate database for all our particles/phantoms with approximately 20-25 parameters, e.g. name, material, shape, diameter/size, different distributions (of diameter/size, anisotropy, etc.). For Resovist/FeraSpin ofr example, you typically need a bi-modal distribution of diameters (plus the hydrodynamic size distribution) to properly model the tracer in simulations (or hybrid reconstruction).

So the question is: Does it make sense or do we really want to store all that in the MDF file?

[profix898]

TF should be discussed in a separate issue IMO. If I remember correctly, this is also something Berkeley mentioned when they reviewed the MDF spec. Of course, TF correction is especially important for x-space or to break the system matrix apart into different components (or to incorporate MPS data).

[profix898]

No preference regarding the feedback signals.

For the dimensions I tend to think that the extra field (e.g. numPatches, numFrames) for dimensions is useless/redundant, but on the other hand it helps to identify the MDF content at a glance. Since HDF gives you the array dimensions without actually accessing the content (dimensions are actually stored separately) there is no technical advantage of having extra fields for that, though.

[tknopp]

If I remember correctly, this is also something Berkeley mentioned when they reviewed the MDF spec

??? Is there any information about that? It would be very helpful if we could have feedback by them.

For the dimensions I tend to think that the extra field (e.g. numPatches, numFrames) for dimensions is useless/redundant, but on the other hand it helps to identify the MDF content at a glance. Since HDF gives you the array dimensions without actually accessing the content (dimensions are actually stored separately) there is no technical advantage of having extra fields for that, though.

I don't see a large issue here. We have a little redundancy but it makes implementing the MDF also a little bit easier. The only inconsistency is that we do not store numFreq. I would be fine adding this parameter to make it more consistent.

[profix898]

I would be fine adding this parameter to make it more consistent.

No objections here. As I said, having extra fields for array dimensions makes MDF also a little bit more discoverable first hand and it provides a way of validating the actual data array, esp. in cases where a field can have different size depending on use case (e.g. with/without FF patches).

[hofmannmartin]

• In the group tracer it might make sense to specify a diameter of the tracer. This would be helpful, if the data was acquired by simulation.

We would have to make this optional, since most often in experiments these parameters are unknown. Dependent on how many parameters have to be stored it could be a good idea to add a subgroup to tracer.

• For nearly all values that specify some array dimensionality there is a seperate parameter (e.g. numPatches, numFrames). For two values this does not hold: number of frequencies K and number of spatial points N. It would be convenient to add both as paramter to process MDF files more easily. However, for spatial points I'm uncertain if there should be a parameter in group calibration and group reconstruction, since both are completely optional. I think there is some further discussion necessary - I'll make a separate issue for that.

If this makes processing and implementation easier by all means lets do this +1.

[hofmannmartin]

I will open new specific issues and close this one, since it contains too many discussions on too different subjects.

• In the group tracer it might make sense to specify a diameter of the tracer. This would be helpful, if the data was acquired by simulation.

This sub issue is still open.

• for hardware development it would be usefull to save the feedback data additional to the measurement data. This would affect groups acquistion/receiver and measurement. I would like to add datasets containing the feedback signal.

This sub issue is still open.

• For nearly all values that specify some array dimensionality there is a seperate parameter (e.g. numPatches, numFrames). For two values this does not hold: number of frequencies K and number of spatial points N. It would be convenient to add both as paramter to process MDF files more easily. However, for spatial points I'm uncertain if there should be a parameter in group calibration and group reconstruction, since both are completely optional. I think there is some further discussion necessary - I'll make a separate issue for that.

This sub issue was discussed and can be considered resolved as of version v2.0.0.

• in group measurement the data is stored withouf TF correction so far, isn't it? It would be convenient to add the fields dataFDcorrected and dataTDcorrected, such that users can directly extract the data for further processing and without knowing how to correct for the TF.

This sub issue was discussed and can be considered resolved as of version v2.0.0.