Issue with Philips MRI

[Vince-LD]

Hello,

Recently I was asked to work on a dataset that contains both Siemens and Philips MRI. Until now, I've always worked with MRI acquired on Siemens machine and Synb0-DISCO has worked great. But today I wanted to try to run it on Philips data because I know it could be an issue.

I wanted to post the smoothed mean b0 image as well as the undistorted synthetic b0 because it's the first time I see something like this and wanted your opinion.

Original:

Synthetic:

The question is if you know where the weird contrast comes from and how to fix it?

[schillkg]

Could you describe what weird contrast you are seeing? It is a bit hard to tell with the contrast limits you've chosen for the bottom image. What does the final output look like? When we QA the synthetic image I am mostly concerned about the geometry of the image (does it look geometrically more similar to the T1) rather than contrast, although we do still look for obvious artifacts in the image. The algorithm shouldn't care about which scanner it came from (it was trained on both Siemens and Philips data).

[Vince-LD]

Ok so my bad, the issue is actually only with that subject.

To describe the issue I have:

• The colormaps (contrat limits) are the same with the two images I sent. However, as you can well on the bottom panel, the color is really unheaven in the synthetic and way darker than on the base image
• Also, we lose a lot more details than usual and when increasing the contrast to better see the details, it's just a blur.
• I just got the results from topup and it's horrendous!

[schillkg]

interesting. I can indeed see a low frequency drift across the image. Is there anything unusual about the T1 in any way? We have incorporated N3/N4 bias field correction into the pipeline so it would be unusual for the synthetic image to have this! We could run this on our end step by step to debug if needed. The weird blurriness/squiggles from topup do indeed usually occur when contrast between forward and reverse PE are different (in this case between forward and synthetic image).

[schillkg]

ah - we also have had this happen due to a masking failure. I almost guarantee this is the case. We use 'bet' which is admittedly not perfect. When the t1 is overly stripped, the network has no idea what to do in regions where we have incorrectly removed brain tissue and is blurry/darker than it should be. Could you skull strip the T1 then run with the flag telling the algorithm that the image is already skull stripped?

[Vince-LD]

I was talking about this in a previous issue. Bet is terrible and i'm not using it. I'm using SynthStrip (also a DL tool) that creates some amazing masks very quickly. Also, this kind of error happened me once when epi_reg was failing to corregister the b0 and T1. At the time i fixed it by using flirt but it didn't work this time. Another instance of this issue was documented in intern by a collegue who had problems with Philips data too.

Here is the stripped t1 I feed to synb0-DISCO:

[Vince-LD]

It looks like I managed to fix the issue:

• I didn't run denoising step on my T1 (probably no influence on the result)
• I didn't run mrdegibbs on my dwi before extracting the b0s and averaging them!

Synthetic image:

[Vince-LD]

Hello,

I did some more tests and in reality, it's not the mrdegibbs step that's causing the issue, it's the t1 denoising step I do before Synb0-DISCO. It seems that for that subject, the denoised T1 is an issue for the normalization step performed in normalize_T1.sh.

Here is a screen of the input:

and here is a screen of T1_norm.nii.gz:

Any idea of how to remedy this issue? I am not familiar with FS N3 correction and normalize command...

[schillkg]

what are you using for denoising? For this algorithm it would likely be beneficial to just give it the raw, original T1 that hasn't been processed in any way. You can still use the denoised T1 if you'd like for future parts of your study design, but when it comes to diffusion preprocessing the original is adequate and won't cause issues. The bias field estimation and normalization within our pipeline are chosen from Freesurfer pipeline which we've chosen because it is robust and well-validated.

[Vince-LD]

I am using DenoiseImage from ANTs. I am currently experomenting at the FS commands you use. I just used the nu_correct and then normalization. The T1_N3 looks quite bright but is still uniform while afrer normalization it's terrible. I may stop to denoise the T1 then though i'd like to understand what is happening...

[schillkg]

Hi @Vince-LD - just touching base again - was this solved by giving the pipeline the raw T1? I also see this is skull stripped, so you may want to add the --skullstripped flag as well. However, we recommend the full, non-processed T1!