Small variation in b-values interpreted as unique shells

[cookpa]

Hi,

I'm trying to run NODDI on some data acquired using a Human Connectome Project Lifespan protocol. It has three shells at b=(5, 1500, 3000) s / mm^2. The bvals file output from the HCP pre-processing pipelines contain the estimated actual b-values that were applied. These vary by +/- 15 s / mm^2 from the nominal value.

So when the scanner might be told to produce measurements at b=

5
1500
3000
1500
3000

You might get b=

5
1495
3010
1500
2995

I've set all the b=5 values to 0, otherwise NODDI fails. My question is about the other values. Should I be concerned about this when running NODDI within AMICO? When I run, it says I have 14 shells.

Also, the fluctuation varies between scans, so a b-value of 3000 in one might be 2995 or 3005 in another scan. Would it be advisable to set the b-values to their nominal values?

Thanks

[daducci]

Hi Philip,

glad you're giving AMICO a try!

Indeed you're right, in your case AMICO would recognize many more shells than expected, as each different b-value will be considered as a new shell. In principle there should not be any issue with the fitting; however, usually the b0 might not be recognized and also the generation/rotation of the lookup tables will take way more time than required, slowing down the entire process for nothing. Related to this, last week we were asked for the same feature and we implemented a routine to round the b-values up to a certain threshold.

You have two choices:

1. Manually round your scheme file to the "teoretical" b-values (e.g. 1495 -> 1500, 1510 -> 1500 etc);

2. I could implement this feature in the code and you could give it a try. In this case, which version are you using (MATLAB or Python)?

What do you think?

[cookpa]

I'm using Matlab.

I can easily change my own b-values, but if you want someone to test new code I am happy do that.

On Oct 20, 2015, at 4:26 PM, Alessandro Daducci notifications@github.com wrote:

Hi Philips,

glad your giving AMICO a try!

Indeed you're right, in your case AMICO would recognize many more shells than expected, as each different b-value will be considered as a new shell. In principle there should not be any issue with the fitting; however, usually the b0 might not be recognized and also the generation/rotation of the lookup table will take way more time than required, slowing down the entire process for noting. Related to this, last week we were asked for the same feature and we implemented a routine to round the b-values up to a certain threshold.

You have two choices:

1. Manually round your scheme file to the "teoretical" b-values (e.g. 1495 -> 1500, 1510 -> 1500 etc);

2. I could implement this feature in the code and you could give it a try. In this case, which version are you using (MATLAB or Python)?

What do you think?

�
Reply to this email directly or view it on GitHub.

[daducci]

It's only because I don't have much data here; the code works well with the dataset I have, but there might be some issues with your data..

If you could round up your b-values in the scheme file, re-run the fitting and confirm you have reasonable estimates, that would be already very helpful. The code should recognize that you have indeed 2 shells only and print out the number of b0.

Meanwhile, I will include this modification into the code by tomorrow, so in case the fitting is ok in your case, you can use the new version for any other dataset you have, ok?

[cookpa]

Sure, I'll try it both ways and let you know

On Oct 20, 2015, at 4:49 PM, Alessandro Daducci notifications@github.com wrote:

It's only because I don't have much data here; the code works well with the dataset I have, but there might be some issues with your data..

If you could round up your b-values in the scheme file, re-run the fitting and confirm you have reasonable estimates, that would be already very helpful. The code should recognize that you have indeed 2 shells only and print out the number of b0.

Meanwhile, I will include this modification into the code by tomorrow, so in case the fitting is ok in your case, you can use the new version for any other dataset you have, ok?

�
Reply to this email directly or view it on GitHub.

[daducci]

Hi Philip,

I added the script AMICO_fsl2scheme with the last commit (5df02dd). The aim is to kind of "mimic" the fsl2scheme in Camino, i.e. creating a scheme file from a pair bvals/bvecs, but with an optional rounding of the b-values. Its usage is as follows:

AMICO_fsl2scheme( bvalsFilename, bvecsFilename, schemeFilename, bStep )

where:

• bvalsFilename, bvecsFilename and schemeFilename are the filenames of the bvals/bvecs files, as well as the output scheme;
• bStep is the threshold for the b-value rounding.

To use it, here is a code snipped around the part where some example data is loaded into AMICO:

% Setup the filenames in AMICO.
AMICO_SetSubject( 'my_study', 'my_subject' );
CONFIG.dwiFilename    = fullfile( CONFIG.DATA_path, 'my_data.nii' );
CONFIG.maskFilename   = fullfile( CONFIG.DATA_path, 'my_mask.nii' );
CONFIG.schemeFilename = fullfile( CONFIG.DATA_path, 'my_data.scheme' );

% Prepare the scheme file from bvals/bvecs files.
% In this case, I assume they are stored into the same folder as the data,
% with names 'bvals' and 'bvecs'
AMICO_fsl2scheme( fullfile( CONFIG.DATA_path, 'bvals' ), fullfile( CONFIG.DATA_path, 'bvecs' ), CONFIG.schemeFilename, 50 )

% Load the data.
AMICO_LoadData

The scheme file will be filled up with b-values rounded according to the formula:

bvals = round(bvals/bStep) * bStep;

(in this example I set bStep = 50).

Please let me know if this solution actually helps in your case.

[cookpa]

I think it will work for me but perhaps not for a general use case.

The rounding might be different across shells, particularly for the low b-value measurements. The HCP use 5 instead of 0, but I've seen people use 50 or 75, the idea is that these are more reproducible than b=0 because it's hard to get the diffusion weighting to actually decay to exactly 0. So a b-value of 50 might need rounding to 0, while a b-value of 4950 would more sensibly be rounded up up to 5000.

For the other shells, the an additional disadvantage of rounding is that it forces the output b-values to be an integer multiple of bStep, which limits the values you can use for bStep.

I think it might be most flexible to allow the user to specify the nominal shells, eg b = (0,1500,3000), and then have the program set each b-value to the nearest option. You can warn if the difference is large, say above 50 or 5% of the nominal b-value.

Does this sound sensible? I can implement this inside fsl2scheme and test, and issue a pull request if you like.

On Oct 21, 2015, at 6:47 PM, Alessandro Daducci notifications@github.com wrote:

Hi Philip,

I added the script AMICO_fsl2scheme with the last commit (5df02dd). The aim is to kind of "mimic" the fsl2scheme in Camino, i.e. creating a scheme file from a pair bvals/bvecs, but with an optional rounding of the b-values. Its usage is as follows:

AMICO_fsl2scheme( bvalsFilename, bvecsFilename, schemeFilename, bStep )
where:

� bvalsFilename, bvecsFilename and schemeFilename are the filenames of the bvals/bvecs files, as well as the output scheme;
� bStep is the threshold for the b-value rounding.
To use it, here is a code snipped around the part where some example data is loaded into AMICO:

% Setup the filenames in AMICO.

AMICO_SetSubject(
'my_study', 'my_subject'
);
CONFIG.dwiFilename =
fullfile( CONFIG.DATA_path, 'my_data.nii'
);
CONFIG.maskFilename =
fullfile( CONFIG.DATA_path, 'my_mask.nii'
);
CONFIG.schemeFilename =
fullfile( CONFIG.DATA_path, 'my_data.scheme'
);

% Prepare the scheme file from bvals/bvecs files.
% In this case, I assume they are stored into the same folder as the data,
% with names 'bvals' and 'bvecs'

AMICO_fsl2scheme(
fullfile( CONFIG.DATA_path, 'bvals' ), fullfile( CONFIG.DATA_path, 'bvecs' ), CONFIG.schemeFilename, 50
)

% Load the data.

AMICO_LoadData

The scheme file will be filled up with b-values rounded according to the formula:

bvals = round(bvals/bStep) * bStep;

(in this example I set bStep = 50).

Please let me know if this solution actually helps in your case.

�
Reply to this email directly or view it on GitHub.

[daducci]

It sounds like a very nice idea indeed! We could use the parameter bStep to perform either one of the following options:

• if bStep is a scalar, we round the b-values as it is implemented now, or
• if bStep is an array, interpret these values as the nominal shells as you suggested.
  I like it!

I could do this but, if you like, you could implement it and submit a PR as you said: this way you will appear as a contributor! I also like the idea of multiple people contributing to a project.