Applicability to data with large gaps between echo times

[tsalo]

I'm not sure if you'd prefer users to open usage-related issues here or post them somewhere like NeuroStars, but I figured I'd try here first. I was interested in applying ROMEO to multi-echo fMRI data, which has relatively large gaps in echo times. I have four echoes with TEs of 11.8, 28.04, 44.28, and 60.52 ms. I tested out ROMEO on my data after scaling my phase data to radians, but the results look odd to me. I wonder if perhaps the spacing between the echo times is just too large?

Here's how I called ROMEO:

romeo -m /tmp/temp/bold_v0010.nii -t [11.8,28.04,44.28,60.52] -Bvq -o /tmp/ /tmp/temp/pha_v0010.nii

The resulting unwrapped echoes mostly look like the below:

I'd appreciate any help you could provide. I should note that I'm not exactly an expert on phase data, unwrapping, or distortion correction, though.

[korbinian90]

Thanks for trying ROMEO and giving feedback!

The phase does definitely not look unwrapped. Your echo times should be fine though.
My first guess would be that the Multi-Echo phase contains a strong phase offset (or initial phase at time 0), then the 4D temporal unwrapping step does not work. In that case the second echo phase should look fine, as it is spatially unwrapped.
You can try the -i flag, which avoids temporal unwrapping.

Please report back if the -i flag solves your problem.

[tsalo]

Adding in -i does make the B0 map more interesting (see below), but now the unwrapped maps are entirely filled with the value -205953, across all four echoes. Although all of the values in both the B0 maps and the unwrapped maps in both cases were extreme and negative (~-5E6), which I wasn't really expecting.

B0 without -i

B0 with -i

[korbinian90]

Hm, that is weird. The B0 looks now only like some kind of combined magnitude.
Is it possible for you to send me this dataset (to [email protected])? I wonder what is different than from our datasets.

Otherwise you could compare your data to the example dataset in https://github.com/korbinian90/ROMEO.jl/tree/master/test/data/small.

Ah, from looking at the B0 (magnitude) image, I have an idea what could be happening. ROMEO creates by default a mask first and starts in a region of easy coherent phase and magnitude to unwrap. It could be that the white part in your image causes the problem here, either ROMEO could mask away the rest or thinks it is a perfect place to start unwrapping. If that is the case, giving ROMEO a mask as additional input or replacing the magnitude with 0 or NaN in that area should help. This should avoid that ROMEO sees the white area as good starting point for unwrapping.

I didn't have data that is rotated like this before. Maybe it would be a good idea if I create a first step in which all data of equal phase values will be cut away.

[tsalo]

Absolutely! I'm planning to post these data to OpenNeuro at some point in the future anyway, so it's totally fine.

[korbinian90]

With the help of your dataset, I found a bug in scaling Int16 datasets. I have a solution and will push a new version early next week.

Thanks for reporting the problem!

[korbinian90]

I uploaded the new release 2.0.2.
The problem should be fixed now.

[tsalo]

Thank you for your help! Just to clarify, what settings did you use? I don't have uncombined data, so I can't use ASPIRE, which I think means that I need to use the -i flag, but at a glance the unwrapped maps look better when I don't use -i. B0 looks odd to me either way.

[korbinian90]

I also didn't use the -i flag for your data. For some coil combination methods the phase offsets are large and the phase evolution not linear anymore. Then you need to use the -i flag.

I think I used the same settings as you:
pha_v0010.nii -m bold_v0010.nii -t [11.8,28.04,44.28,60.52] -Bvq

[korbinian90]

It could be that I messed up when compiling. I was in a hurry and didn't check the compiled versions. I will do that tomorrow.
The julia version (before compilation) definetily worked for your dataset (I sent you the unwrapped and B0 files per email)

[korbinian90]

I tried it today with the compiled version on your dataset. It seems to work fine.
I copied your command:
/tmp/romeo_linux_2.0.2/bin/romeo -m bold_v0010.nii -t [11.8,28.04,44.28,60.52] -Bvq -o . pha_v0010.nii

And this is the B0 map, I obtain:

If it is still not working for you, you can send me the output images you get, maybe I can guess from them what is going wrong.

[tsalo]

Thanks again! I think I was perhaps seeing what you mentioned in your email, which is that my data may not be appropriate for quantitative B0 map estimation.

I will close this, but before I do I wanted to ask, would this repo or ROMEO.jl be most appropriate to open an issue about pushing to Docker?

[korbinian90]

I haven't worked with docker yet. I would say if the compiled version should be on docker then this repository and if the Julia version should then probably ROMEO.jl
ROMEO.jl has only the Romeo algorithm without nifti and B0 creation.
RomeoApp.jl is exactly the same as the compiled version, but running in Julia and not compiled. (For compilation I used CompileMRI.jl)
MriResearchTools.jl is a collection of tools and includes Romeo as well. (Maybe not yet the B0 part)
So it depends probably on what the purpose of docker would be to decide what would make sense to put into docker.
For me it doesn't really matter where you open the issue to discuss

[tsalo]

It might be easier to push the compiled version if you're already compiling, but in most cases I'd build the Dockerfile around the uncompiled version (I guess RomeoApp.jl). I'll open the issue in this repo though. Thanks again.