I would actually put the data straight onto fsaverage, smooth there, and do the FSL analysis there. You will need to put it on fsaverage eventually for group analysis, and you're better off doing that before doing the FEAT analysis. Remember to turn off temporal pre-whitening when running FEAT.
For nifti1, there is no solution to the prime number of vertices problem. The problem is fixed in nifti2, so, assuming that FSL is reading nifti2, you could write a mgh to nifti2 converter. But I would do it on fsaverage anyway
doug
On 09/26/2013 01:53 PM, Connor Lane wrote:
Hmm, that's unfortunate.
The reason I'm interested in this surface to nifti conversion is that I'm trying to incorporate surface based pre-stats smoothing into my FSL fMRI analysis stream. My strategy has been: preprocess with FSL --> map to surface space and smooth --> convert mgh surface to nifti surface and continue with FSL analysis.
Do you think the surface smoothing benefits of this kind of stream justify the trouble associated with either a) modifying the data as you suggest every time this factoring issue shows up, or b) writing an mgh <-> nifti utility that avoids the issue?
Some other possible answers I've thought of are: -After surface smoothing, map the functional data to fsaverage and then convert back to nifti (since we know there's no factoring problem with fsaverage). The drawback here is we never get to see statistics in subject-specific space. -Switch from FSL to FsFast, where surface smoothing is built in.
Or maybe I should forget about surface based smoothing altogether, and actually volumetric smoothing works just fine?
I would really appreciate hearing your overall recommendation on this.
Connor