Synb0-DISCO
Synb0-DISCO copied to clipboard
Topup failed following the generation of undistorted b0 through the synb0 docker
Hello,
I ran the synb0-DISCO docker through singularity using the following command on an b0 image (since I only had single PE directional diffusion images).
singularity run -e -B INPUTS:/INPUTS -B OUTPUTS:/OUTPUTS -B /opt/local/freesurfer-7.1.0/license.txt:/extra/freesurfer/license.txt synb0_latest.sif
Attached is the screenshot of b0 before and after topup. As you can see, topup results didn't look good. Do you have any suggestions on how I could improve the results?
Appreciate your help!
Jayashree
<img width="1013" alt=
"Screen Shot 2020-12-18 at 9 29 37 AM" src="https://user-images.githubusercontent.com/44578765/102632514-d5f9c780-4114-11eb-955c-940dc3346578.png">
Hello Jayashree,
It may be possible that the PE of your scan does not match your acqparams.txt file. If this is not the case, could you provide a screenshot of the generated synthetic b0 as well? It should be in your outputs directory as b0_u.nii.gz.
Thanks, Colin
Hi Colin,
You were right. Once I corrected the values in acqparams.txt, the issue went away. Thank you for your help!
Jayashree
Hi Colin,
I've another question about the b0 output from the docker. As you can see in the below screenshots, the output b0 images (both original and undistorted) are blurred compared to the input b0 image (2nd image). Do you know why this occurs? I'm concerned if this'll impact the eddy pipeline results.


Thanks,
Jayashree
Hello Jayashree,
The smoothing is intentional. The generation of the synthetic b0 is done at 2.5 iso, and since most DWI acquisition are acquired at higher resolutions, the synthetic b0 will be blurry compared to the input b0. The pipeline smooths the input b0 slightly before topup is applied. As we tested the generalizability of this pipeline, we found that it works well for most data and haven't had any issues when applying topup or eddy.
Best, Colin
What is the resolution of your DWI?
It is 1.5mm iso, acquired at 3T.
This matches some of the data we used to test the generalizability of the model, so I don't think you should have any issues.
Hi Colin,
You were right. Once I corrected the values in acqparams.txt, the issue went away. Thank you for your help!
Jayashree
Just out of curiosity, because I'm struggling with our acqparams-file right now as well: could you paste the parameters that worked for you?
Our data was acquired in A>>P, therefore our first line is 0 -1 0 0.0702, but with the second line I'm not sure if I'm supposed to put 0 -1 0 0.000 (as in the github-synb0-readme) or more of a inverse of line 1 (for example 0 +1 0 0.0702) as the FSL-Guide suggests.
Since there's only a limited amount of possibilities I will be using a trial-and-error approach until it looks about right, but any help would be appreciated :)
Best, Johannes
Hi Johannes,
I followed the github-synb0-readme because I do not have reverse PE direction diffusion images. The synthetic b0 that is generated by the docker from the input b0 and the T1 image you provide, so I think you need to provide 0 -1 0 0.000 for the second b0 that's generated.
The FSL guide assumes that you have both PE (AP/PA) direction images in the example they provide.
Hope this helps!
Jayashree
This matches some of the data we used to test the generalizability of the model, so I don't think you should have any issues.
Thanks for confirming, Colin!
Jayashree
Hi Johannes,
I followed the github-synb0-readme because I do not have reverse PE direction diffusion images. The synthetic b0 that is generated by the docker from the input b0 and the T1 image you provide, so I think you need to provide 0 -1 0 0.000 for the second b0 that's generated.
The FSL guide assumes that you have both PE (AP/PA) direction images in the example they provide.
Hope this helps!
Jayashree
Hi Jayashree,
Thanks for the quick reply, it helps a lot. Can I use the same acqparams.txt for running eddy afterwards? Or do I have to provide a different file in order to address the artificial synthethic b0?
Best, Johannes
Nevermind, I just saw how in the Readme it is suggested to use the same file.
I'm still not convinced that I'm doing everything right, this would be my preprocessed DWI after EDDY-correction. Does this look about right ? (Top row post eddy, bottom row raw dwi)
Thanks for your help!
All the best, Johannes
Hello Johannes,
Can you also share images of 1) the raw b0, 2) b0_all volume 1 and volume 2, and 3) b0_all_topup volume1 and volume 2? Also it may help if you share some of the details about the acquisition such as the PE and voxel resolution.
Colin
Hey Colin,
Thanks so much for helping me out here.
This is the raw b0:
Here's b0_all (with 0 -1 0 0.0000 as the second line of the acqparams.txt, left volume 1, right 2)
Here's b0_all_topup, left volume 1, right 2.
The second volume does look good, are there any extra steps that I'm missing before I can put it in EDDY? If not, this might be more of a EDDY-issue, maybe I messed up the index-file there.
Our data is in A>>P, voxel size is 2mm³. It was acquiered on a SIEMENS Skyra 3T Scanner. I did anonymize it using DicomCleaner, but the relevant DICOM-Tags remained unchanged (our raw data had some german umlaut in the sequence name that caused a python exception).
Thanks so much in advance! If there's anything else I should provide, let me know.
Best, Johannes
So it looks like something is wrong with output of topup. Volume 1 in b0_all_topup definitely looks distorted in some way. Can you include the output of fslhd? It may be an issue with the b0's NIFTI header.
This is the output of fslhd on the b0 I use as input:
sizeof_hdr 348
data_type UINT16
dim0 3
dim1 122
dim2 122
dim3 65
dim4 1
dim5 1
dim6 1
dim7 1
vox_units mm
time_units s
datatype 512
nbyper 2
bitpix 16
pixdim0 -1.000000
pixdim1 2.000000
pixdim2 2.000000
pixdim3 2.000000
pixdim4 0.000000
pixdim5 0.000000
pixdim6 0.000000
pixdim7 0.000000
vox_offset 352
cal_max 0.000000
cal_min 0.000000
scl_slope 1.000000
scl_inter 0.000000
phase_dim 0
freq_dim 0
slice_dim 0
slice_name Unknown
slice_code 0
slice_start 0
slice_end 0
slice_duration 0.000000
toffset 0.000000
intent Unknown
intent_code 0
intent_name
intent_p1 0.000000
intent_p2 0.000000
intent_p3 0.000000
qform_name Scanner Anat
qform_code 1
qto_xyz:1 -2.000000 0.000000 -0.000000 110.498787
qto_xyz:2 0.000000 -2.000000 -0.000000 107.622009
qto_xyz:3 0.000000 0.000000 -2.000000 39.771152
qto_xyz:4 0.000000 0.000000 0.000000 1.000000
qform_xorient Right-to-Left
qform_yorient Anterior-to-Posterior
qform_zorient Superior-to-Inferior
sform_name Scanner Anat
sform_code 1
sto_xyz:1 -2.000000 -0.000000 0.000000 110.498787
sto_xyz:2 -0.000000 -2.000000 0.000000 107.622009
sto_xyz:3 0.000000 0.000000 -2.000000 39.771152
sto_xyz:4 0.000000 0.000000 0.000000 1.000000
sform_xorient Right-to-Left
sform_yorient Anterior-to-Posterior
sform_zorient Superior-to-Inferior
file_type NIFTI-1+
file_code 1
descrip MRtrix version: 3.0.2
aux_file
Here's fslhd of the b0_all_topup:
sizeof_hdr 348
data_type FLOAT32
dim0 4
dim1 122
dim2 122
dim3 65
dim4 2
dim5 1
dim6 1
dim7 1
vox_units mm
time_units s
datatype 16
nbyper 4
bitpix 32
pixdim0 -1.000000
pixdim1 2.000000
pixdim2 2.000000
pixdim3 2.000000
pixdim4 1.000000
pixdim5 0.000000
pixdim6 0.000000
pixdim7 0.000000
vox_offset 352
cal_max 0.000000
cal_min 0.000000
scl_slope 1.000000
scl_inter 0.000000
phase_dim 0
freq_dim 0
slice_dim 0
slice_name Unknown
slice_code 0
slice_start 0
slice_end 0
slice_duration 0.000000
toffset 0.000000
intent Unknown
intent_code 0
intent_name
intent_p1 0.000000
intent_p2 0.000000
intent_p3 0.000000
qform_name Scanner Anat
qform_code 1
qto_xyz:1 -2.000000 0.000000 -0.000000 110.498787
qto_xyz:2 0.000000 -2.000000 -0.000000 107.622009
qto_xyz:3 0.000000 0.000000 -2.000000 39.771152
qto_xyz:4 0.000000 0.000000 0.000000 1.000000
qform_xorient Right-to-Left
qform_yorient Anterior-to-Posterior
qform_zorient Superior-to-Inferior
sform_name Scanner Anat
sform_code 1
sto_xyz:1 -2.000000 -0.000000 0.000000 110.498787
sto_xyz:2 -0.000000 -2.000000 0.000000 107.622009
sto_xyz:3 0.000000 0.000000 -2.000000 39.771152
sto_xyz:4 0.000000 0.000000 0.000000 1.000000
sform_xorient Right-to-Left
sform_yorient Anterior-to-Posterior
sform_zorient Superior-to-Inferior
file_type NIFTI-1+
file_code 1
descrip 6.0.1
aux_file
Thanks! Johannes
I can't find anything obviously wrong in the header info. If you are able to share your data, could you provide a way for me to grab the b0 and T1? I'll try looking in to the issue and figure out what is going on.
Thank you so much! I have to check with my Professor if it's ok to send out an anonymized version, I'll let you know tomorrow.
Best, Johannes
Hi Colin,
I tried to do topup as a part of the synb0 and also outside the script (including more b0) to test the topup results. I observed the following,
-
The topup results from doing outside the script seemed to have some distortions (outside the brain). Although it may not impact the microstructure in the later analysis, I'm curious how there is a difference between both the methods.
-
The two outputs when placed one above the other, the topup results done outside seemed to have moved. Do you think this may be due to the addition of b0s to 'b0_all' output from synb0?
I'd like to understand if I need to run topup differently (when doing outside synb0) apart from changing the acqparams.txt file according to the number of b0s included?
Here are screen shots of topup results obtained through synb0 and outside the docker. Second image (sagittal view) has some distortion in inferior side, outside the brain.


Thanks again for your continuous support!
Best, Jayashree
Hello Jayashree,
I want to make sure I understand correctly. You are comparing the results from topup run with your b0 and the synthetic b0 within the synb0 pipeline to topup results you ran outside of the pipeline using the same b0 and synthetic b0 while adding another b0?
I would suggest first running topup exactly how our pipeline would run it with only the b0 and the synthetic b0 to first make sure there isn't something else strange happening. I don't think a version issue would cause a huge difference, but it may be that you are using a newer version of FSL than our container. The exact topup command in our pipeline looks like this:
topup -v --imain=/OUTPUTS/b0_all.nii.gz --datain=/INPUTS/acqparams.txt --config=b02b0.cnf --iout=/OUTPUTS/b0_all_topup.nii.gz --out=/OUTPUTS/topup --subsamp=1,1,1,1,1,1,1,1,1 --miter=10,10,10,10,10,20,20,30,30 --lambda=0.00033,0.000067,0.0000067,0.000001,0.00000033,0.000000033,0.0000000033,0.000000000033,0.00000000000067
If the results of running this outside match those from container and then if you run it exactly this way with an additional b0, we should know if the the additional b0 is introducing these distortions outside of the brain volume.
Let me know if I am misunderstanding something, Colin
Hi Colin,
Yes, you understood the comparison correctly. The FSL version I use to run topup is 6.0.3. Does that match with the container's FSL version?
I did the comparison you mentioned "running topup exactly how our pipeline would run it with only the b0 and the synthetic b0" using the command you provided. It mostly looked the same except for very minor shift in the space in the command line run topup result. This explains the result differences I got earlier.
Anyway, I'm also wondering if there are significant advantages to running topup by adding more b0s, such as improving the signal loss in diffusion images that follows the added b0. Please let me know your thoughts.
Thanks,
Jayashree
I believe our container uses FSL 5.0.10, but I don't think there will be any significant differences in the topup or eddy methods between versions.
I have not looked in to the advantages of including more b0s vs only using two of different PE directions. We might guess that adding more b0s which are not different in PE direction from the two b0s already included may not help with susceptibility correction, but they may improve movement correction. I don't see a reason not to include as many as you have.
Best, Colin
Hi Colin,
Now that I've used this pipeline to correct for distortion, I wanted to do a preliminary analysis comparing the single and two PE direction scans through a parameter such as mean squared error to see the actual difference between them (like you have done in the paper). I was wondering what tool/program you used to calculate MSE from the diffusion time-series. Did you sample a set of volumes or used the entire diffusion time-series to calculate MSE?
Thanks again for your inputs!
Jayashree
In the paper, MSE was calculated for FA not the diffusion signal itself. The FA calculation and MSE were done with in house MATLAB code written by the primary author.
Best, Colin
So, if I have the mean FA values for a particular region of interests for two image datasets, then can I calculate the MSE between the mean values?
Thanks,
Jayashree
The error was calculated voxel-wise within the brain volume. If you want to separate by region, I would first calculate the squared error and then use whatever masks you like to decide where to average.
Got it. Thank you!
Hi Johannes,
I got very similar outputs as your outputs. At first, I think they look OK, but Colin pointed out that your b0_all_topup volume 1 is a bit distorted. I wonder whether you fixed this problem? My acqparams.txt is 0 1 0 0.17748 0 1 0 0 Should I use -1 in the second row instead? Any help would be appreciated!
raw distorted b0
b0_all_topup volume 1 (some gray signals around eyeballs along sagittal direction)
b0_all_topup volume 2