search

MASILab / Synb0-DISCO

Distortion correction of diffusion weighted MRI without reverse phase-encoding scans or field-maps
https://my.vanderbilt.edu/masi
57 stars 28 forks source link

Using flirt instead of epi_reg and citing/distribution #38

Open Vince-LD opened 1 year ago

Vince-LD commented 1 year ago

Hello,

First of all, thank you for your work and for this amazing tool! I am preparing to release custom DWI peprocessing and a tractography pipelines on github which make use of Synb0-DISCO (for the first part). However, I had some issues with this tool on some subjects. I managed to trace the problems back to epi_reg in data_processing/prepare_input.sh. Indeed, I would get an error that indicates that it is unable to find a wm/gm contrast in BBR (sorry, I cannot recall the exact error). The thing would run and print the error for hours then suddenly skip this step. The output synthetic b0 image would be completely scrambled which messed up the topup.

I tried so many things to fix it that didn't work until I used flirt to register the T1W to the b0 image then convert_xfm to invert the resulting matrix and use it exactly like in the rest of the pipeline. I got really good results and no more errors by using this simple trick! I wanted to share that with you so maybe you could implement this solution.

Also, I see you use bet to generate a brain mask which in my opinion yields quite sub-optimal results. As said in your doc, a good brain mask is essential for the method to work. I have been playing around with different tool and found that Synthstrip is quite an amazing tool (very light and fast). Also hd-bet can work quite well and can simply be installed with pip. Maybe this could also be interesting and quite straight forward for you to implement? I know users can now easily premask their T1W but it may make things better in the case they don't use it for some reason or another.

Final question, as I am going to upload the pipeline on github, I was wondering if it would be fine package the modified version of Synb0-DISCO with it because I moved a few things around to make it run outside of a container? The other solution would be to create a few customized "input" scripts that could replaced to ones made for the container and let people directly clone this repo? What's your opinion on the matter? I am obviously going to give you full credit and link this repository in any case! 😁

Cheers, Vincent

Diffusion-MRI commented 1 year ago

Hi @Vince-LD - glad you like the tool! Hopefully I can respond to all points.

1) epi_reg and no contrast in BBR. This typically happens if you are using a T1 that has been processed in some way, in particular if it has already been processed with freesufer. Are you using raw T1, or the output from freesufer in the /mri folder? I'd also be happy to take a look at it and debug. We are very much fans of epi_reg over flirt - because it was specifically tailored towards b0 to T1 registration - and would like to be able to solve this problem.

2) bet versus synthstrip. Yes! We agree bet can be suboptimal. We have not used synthstrip but will talk with our team and see if we can substitute this in our next version.

3) yes - absolutely fine with us! This may also make it easier to implement for those unfamiliar with containers. Happy with whatever you think Is most convenient for you and others who may use the algorithms. Happy to also help if needed and make improvements within our container too.

Vince-LD commented 1 year ago

Hi @Diffusion-MRI,

Thank you for the quick response! Yes you answered all my questions.

  1. I would like to talk more about epi_reg vs flirt. Yes I was using T1 from FS because of the brain mask that looks far better than what bet can do. I don't really see what the problem would be as a preprocessed T1 should be better than a raw one? That's just my basic intuition on it so I may be completely wrong and would be glad to get some explainations. If FS is actually the problem, maybe having a small disclaimer in the doc would be a good thing. It happened only twice on a ~50 subjects dataset but I only saw it because I manually checked every preprocessed DWI after dwifslpreproc from MRtrix3 and saw that something was really wrong. I suspect this kind of "silent" error coudld happen to others especially if it's caused by FS haha. On the same subject, I know in theory epi_reg is better because it is made for b0 and T1, but from my tests, the coregistration of T1 to DWI with flirt is also really good thanks to the default algorithm they use (and it is way faster). Weird fact I found out with flirt is that T1 to DWI is better than DWI to T1. If you are interested I can share some images I have for my doc. Next week I will replicate the issue I had so you can take a look and tell me what you think about it. At the time I didn't find any solution online so if you can help it would be fantastic!

  2. That would also be great. Yesterday I showed it to a collegue who was quite impressed.

  3. Thank you! What I will do is probably just package the modified prepare_input.sh and inference_pipeline.py in my repo so people can directly download the original version from yours as the paths inside them are wrong for use outside of containers. I don't like code duplication and like that, people will still have the normal (latest) version of Synb0-DISCO and not have to make any modifications. Plus it will make very explicit what parts of the tool got changed so it will be cleaner.

PS: I just remembered that the T1 from FS I used looked quite similar to the raw T1. Also, the fast step in epi_reg ran perfectly on the data. The error looked like a contrast issue in the b0 where it could not find a wm/gm contrast strong enough to align it to the T1. I just found this thread that details the error I had at the time. I couldn't even fix it by manually giving it a wmseg...

Diffusion-MRI commented 1 year ago
  1. I'm pretty confident it is due to the T1 rather than b0. We've only seen this issue when using T1s processed from FS. I'm not sure why this happens, but it is probably due to the intensity normalization. You will probably see that the gray and white matter tissue intensities are relatively homogenous within tissue types and it is possibly this is why no boundary points can be found? It could also be because of the space the image is in? I'm not too familiar with which space the FS T1 is regridded in, but epi_reg could be looking for boundaries within a space defined by b0. Either way, my bet is if you use the raw T1 that the pipeline will work well. I'm surprised that out of 50 subjects you had successful results with a majority when using the FS T1!
  2. This is on our to-do list. No promises on how quickly it gets implemented!
  3. Sounds great. It is always good to have several options available, especially with datasets that can vary widely from site to site. I suppose the major changes will be in the prepare_input.sh, changing the epi_reg and bet commands?
Vince-LD commented 1 year ago

  1. Yes, that's why I'm quite surprise to hear it may be due to FS when it's working with 90+% of subjects haha! If all the issues you had were with FS subjects that means that your are certainly right. It is true (very annoyingly) that the FS images are not in RAS which can be very frustrating when one wants to apply a linear transformation. I found their doc a bit confusing on how to rearange the axis as well... One solution would be to force a realignment of the anatomical inputs to the b0 space before launching epi_reg. Maybe FS can do it, but I know that using MRtrix3's mrgrid FS_T1.nii.gz regrid -template FS_T1.nii.gz -strides b0.nii.gz out_T1.nii.gz can do the trick (or a command among those lines).

  2. Yes no worries, I have the v1 version of your tool so what I do is just give it an already denoised and skull stripped image to skip bet altogether (I use SynthStrip in the pipeline outside of Synb0-DISCO).

  3. Yes, basically I would only change the paths and epi_reg (maybe I won't if we fix the FS problem)...

PS: I just re-checked the strides using mrinfo input.nii.gz -strides if the orientation was different between the original T1 and FS's T1. Indeed, my original T1 is 1 2 3 while FS's output is -1 3 -2. Using FS's mri_convert FS_T1.mgz --out_orienation "RAS" T1.nii.gz works and outputs an image with a stride of 1 2 3. What could be implemented is something like:

B0_ORIENTATION=$(mri_info b0.nii.gz --orientation)
mri_convert $INPUT_T1 --out_orientation $B0_ORIENTATION reoriented_T1.nii.gz

This would use the b0 orientation and apply it to the input so we are ALWAYS in the same orientation (if we already are, it doesn't change anything so it's just like copying the input volume).