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
Great, thanks so much for the advice. Can you say a little about why pre-whitening needs to be turned off? I thought the process operated on each voxel's timeseries independently, so it wouldn't matter that the spatial relations are jumbled in the surface format. This isn't the case?
As far as writing a converter, my plan was to just modify the freesurfer tool to reshape with a remainder. E.g. The modified tool would convert between N x 1 x 1 x t surfaces and ceil(N/10) x 10 x 1 x t nifti files (with a 10 - remainder vector of 0s in each volume). Would this work? (It is a little beside the point, since I'm perfectly fine going straight to fsaverage.)
Connor
On 9/26/13 2:14 PM, "Douglas N Greve" greve@nmr.mgh.harvard.edu wrote:
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
-- Douglas N. Greve, Ph.D. MGH-NMR Center greve@nmr.mgh.harvard.edu Phone Number: 617-724-2358 Fax: 617-726-7422
Bugs: surfer.nmr.mgh.harvard.edu/fswiki/BugReporting FileDrop: https://gate.nmr.mgh.harvard.edu/filedrop2 www.nmr.mgh.harvard.edu/facility/filedrop/index.html Outgoing: ftp://surfer.nmr.mgh.harvard.edu/transfer/outgoing/flat/greve/
The information in this e-mail is intended only for the person to whom it is addressed. If you believe this e-mail was sent to you in error and the e-mail contains patient information, please contact the Partners Compliance HelpLine at http://www.partners.org/complianceline . If the e-mail was sent to you in error but does not contain patient information, please contact the sender and properly dispose of the e-mail.
On 09/26/2013 02:54 PM, Connor Lane wrote:
Great, thanks so much for the advice. Can you say a little about why pre-whitening needs to be turned off? I thought the process operated on each voxel's timeseries independently, so it wouldn't matter that the spatial relations are jumbled in the surface format. This isn't the case?
The FEAT prewhitening spatially smooths the autocorrelation function, and that will assume volumetric geometry.
As far as writing a converter, my plan was to just modify the freesurfer tool to reshape with a remainder. E.g. The modified tool would convert between N x 1 x 1 x t surfaces and ceil(N/10) x 10 x 1 x t nifti files (with a 10 - remainder vector of 0s in each volume). Would this work? (It is a little beside the point, since I'm perfectly fine going straight to fsaverage.)
Yes, that should work, but you'll have to do the bookkeeping doug
Connor
On 9/26/13 2:14 PM, "Douglas N Greve" greve@nmr.mgh.harvard.edu wrote:
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
-- Douglas N. Greve, Ph.D. MGH-NMR Center greve@nmr.mgh.harvard.edu Phone Number: 617-724-2358 Fax: 617-726-7422
Bugs: surfer.nmr.mgh.harvard.edu/fswiki/BugReporting FileDrop: https://gate.nmr.mgh.harvard.edu/filedrop2 www.nmr.mgh.harvard.edu/facility/filedrop/index.html Outgoing: ftp://surfer.nmr.mgh.harvard.edu/transfer/outgoing/flat/greve/
The information in this e-mail is intended only for the person to whom it is addressed. If you believe this e-mail was sent to you in error and the e-mail contains patient information, please contact the Partners Compliance HelpLine at http://www.partners.org/complianceline . If the e-mail was sent to you in error but does not contain patient information, please contact the sender and properly dispose of the e-mail.
freesurfer@nmr.mgh.harvard.edu
-
Connor Lane -
Douglas N Greve