Dear FSL experts,

The registration issue has been solved, and I was able to run MELODIC with filtered_func_data (in standard space),
followed by dual-regression/randomise.
It seems the problem was caused by the input to the "initial structural image" in the registration phase.
Taking that away, and just using the "main structural image" seemed to fix the issue.

For anyone interested, the input to the "main structural image" was a sagittal MP-RAGE image, processed
through FreeSurfer, and with the non-brain tissue removed using FSL BET.
The input to the "initial structural image" was the same image as the above, but with the non-brain tissue intact.
I am assuming that was a mistake?

Thanks for your time, sorry to bother you for this trivial problem

Sincerely
Luigi






--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------




Dear FSL experts,

It seems that the problem is due to very poor registration 
of example_func to highres, but mainly example_func to standard.
For a lot of the subjects, the registration is completely off/massively displaced (i.e. does
not cover the brain at all), and for others, the brain gets flipped
over 90 - 180 degrees.

The registration parameters I used were:
Initial structural images: Normal search - 3 DOF
Main structural images: Normal search - BBR
Standard space: Normal search - 12 DOF - Nonlinear, warp resolution (mm) = 10

I tested with different parameters, and it seems that
turning full search on for all three steps and 6DOF for initial structural image
improves registration for only some of the bad ones

Looking at the indivdual subject's report.html files, it looks like
for the massive registration displacement, the issue occurs on the registration from example_func to initial_highres.
For the flipped brain images,it seems to occur on the registration from highres to standard. 

The MPRAGE structural images used all look ok, and I double checked
that the headers and actual orientations are the same and correct 
(also for the fmri images).

Is there a way to sort out the "bad" registration cases?

Thanks again for your help!

Sincerely
Luigi


---------------
Hi Mark,

Thanks for the reply. I attempted to run the whole data set through the melodic GUI, resampling
the images to 4mm. There was a GUI_ica folder for each subject, but the final g-ICA wasn't made,
because two of the 4D fMRI images had more volumes than the rest of the dataset. I removed the
"excess" volumes using fslroi, and then ran those two only through the melodic GUI, and then
ran the whole dataset using the melodic command line.
However, at the end stage, the following error message came up:

An exception has been thrown
Runtime error:- detected by Newmat: process fails to converge
MatrixType = Diag   # Rows = 4100; # Cols = 4100; lower BW = 0; upper BW = 0
Trace: Evalue(tql2).

I rummaged through the FSL mailing list, and one possible error seems to be that one
of the inputs is different from the rest (e.g. one inpu only being a 3D file). However, I 
was able to run the command line melodic on the native space filtered_func_data (through FEAT) for
the same dataset previously (creating a g-ICA map), and I checked that all the dimensions for the fMRI were the same using fslinfo (I think).
I read in an earlier post that turning off the variance normalise option, which I did using the command
line melodic, but that didn't help.
Is there something I'm missing?
I am rerunning the melodic GUI with the whole dataset, using the two 4D fMRI images after cutting out the
volumes.

Thanks again for the help!

Sincerely
Luigi




Hi,

The first case isn't right.
Running flirt with just the -in and -reg options is asking it to perform a registration (i.e. figure out what transformation aligns the images).  If you use a 4D input image it will _not_ use all the timepoints, but just pick the first one, since it is not designed to do motion correction.

Instead, you should run motion correction first, then register using the example_func (a 3D image which is the target of the motion correction).  This can be registered to the highres or standard (and FEAT/MELODIC does this all for you).

The second case is the kind of thing you want to do but there is a problem with the call.  You should not include the matrix reg/example_func2highres.mat if you are already including the warp (since the warp contains this information already).  Also, if you want to keep the size down then you want to use a lower-resolution standard-space image, which you should have within a MELODIC run (try looking in reg_standard) and then you will find the size much better (e.g. the difference between using a 2mm and 3mm standard-space image is roughly a factor of 3, and between 2mm and 4mm is a factor of 8).  Nonetheless, with 164 scans the size of the image will inevitably be big.  So you should make sure that you have a suitable machine for running such analyses.

All the best,
	Mark

On 21 Aug 2013, at 15:50, Luigi Angelo Maglanoc <[log in to unmask]> wrote:

> Dear Christian,
> 
> Thanks for the fast reply. I was suspecting that would be the problem.
> Is the correct way to transform the functional data to standard space:
> 
> flirt -in filtered_func_data -ref reg/standard -out filtered_func_data2std
> when doing it with the above, the output is 1.3M, whereas the original is 35M?
> 
> or is it
> applywarp --ref=reg/standard --in=filtered_func_data --out=filtered_func_data2std --warp=reg/highres2standard_warp --premat=reg/example_func2highres.mat --interp=spline
> The issue with the second method is that the output takes up 672M.
> There are 164 scans, which amounts to approx. 110G, which is much more than the
> available capacity.
> 
> Thanks again in advance.
> 
> Sincerely
> Luigi