Simulated diffusion directions perpendicular to input streamlines

[ppruc]

Hi everyone,

i am currently trying to simulate diffusion data for an experiment using Fiberfox. After inputting a tractogram and setting the simulation parameters, i am able to obtain my diffusion data. However, when running my analysis, I realised that some of the FODs are perpendicular to the input fibers? This effect is also present when looking at the raw diffusion glyphs. I am unsure what the problem is, as I've tested different simulation settings and tractograms. Bvals and bvecs are set to the HCP protocol.

Hopefully it is just a problem with my settings, but would be grateful for insights whats going wrong here !

Cheers Philip

[peterneher]

Hi Philip,

I'm a bit rusty with my physics, so probably you have your reasons to do it, but is there a specific reason you are not using a single shot EPI sequence? Not sure if this is the reason, though.

To look a bit more into this, could you send me some sample data that I can use to reproduce the issue?

Best, Peter

[ppruc]

Hi Peter,

thanks for the fast reply!

I've also tried simulating a single-shot EPI sequence, however, with the same result. The reason why we chose a conventional spin echo sequence was to keep the experiment as simple as possible and avoid any sequence-induced artifacts. From my understanding, this means we're reading single k-space samples instead of entire k-space lines, which should mean that parameters like dwell time and T2inhom become less influential on the simulation result.

I've sent you some files for simulating a single edge in which I encountered the problem. If you need anything else to reproduce the issue, please reach out!

Cheers Philip

[peterneher]

Hi Philipp,

If you want to avoid any sequence-induced artifacts, simply disable "Simulate signal relaxation" box. Then, only the diffusion models are used, but not k-space acquisition is simulated.

I tested your sample data and the results look fine to me:

However, you did not model the signal afterwards with MITK, right? MITK Automatically applies the image rotation matrix to the individual gradient vectors when initializing the image. I implemented this because some data that I encountered simply required this. So if I disable this and then reconstruct ODFs with your simulated data in MITK, the orientations are indeed like you described. Other toolkits like MRtrix do not apply the image rotation matrix to the gradients, hence the resulting ODFs will be wrong for the images that require this gradient rotation.

You can see this in the "Preprocessing Perspective" --> "Preprocessing View" --> bottom of "Gradients" tab. There you can inspect the gradients how they are stored in the file on disk ("Original Gradients") and how they are used in MITK ("Working Gradients").

Simple solution: change the x and y sign of the gradients in your resulting bvecs file. In general, gradient direction flips are something that occur quite often with different datasets. Always annoying and to watch for carefully.

Let me know if this solved your problem!

[peterneher]

In the same view where you can inspect the gradients, you can also flip them.

[ppruc]

Thanks Peter, flipping the bvecs x coordinates did the trick! FODs are now aligned with the streamlines !

[peterneher]

Nice! Don't hesitate to ask if you have any further questions.

[Lestropie]

While I've not looked at the raw data myself, my expectation is that this is a manifestation of the infamous bvec format issue of having to flip the first axis specifically for radiological / right-handed images. This was noted with respect to MITK here, with more extensive explanation of the issue here.

It's probably the case that MITK's internal handling of this format between read / write is consistent, but that handling will be inconsistent with FSL (& MRtrix3). Any thoughts on whether this is something that might be resolved, over and above the availability of user controls to perform such flipping manually?

Also since it was posted here:

If you want to avoid any sequence-induced artifacts, simply disable "Simulate signal relaxation" box. Then, only the diffusion models are used, but not k-space acquisition is simulated.

On seeing this I thought that it may also disable compartment-specific relaxation effects. If this applies strictly to effects across the acquisition of k-space, perhaps the name of the option could be more targeted. Do you know off the top of your head if there might be any other unexpected effect caused by using "conventional spin echo" as an alternative mechanism for achieving the same thing?

[peterneher]

Thx for the links! You are right, it would be great if this could be aligned between MITK and the other tools. Unfortunately, if I am being realistic, I will probably not get around to doing this. This issue is probably anchored firmly in many parts of MITK diffusion and will require major digging and refactoring. Maybe I can push for this in the context of some related MITK project at some point.