<div dir="ltr">Hi Nick,<div><br></div><div>- Thanks so much for your quick/thorough response! I just wanted to prepend my reply by saying that I did not mean (in any way!) to be critical of these PyMVPA tools. In fact, just the opposite: I’m incredibly grateful for them (2/3 of my just-completed PhD relied heavily on them). The frustration I’ve been feeling is self-directed for not being able to understand these processes more quickly and thoroughly. Reading and understanding source code comes unfortunately unnaturally to me, despite considerable effort…</div><div><br></div><div>I’ll respond point by point, without copying all of my original text. Once again, I appreciate all the time you’ve spent on these issues!</div><div><br></div><div><br></div><div><i>"Please note that the mySub/example_functional_volume.nii file is the one that is used for coregistration with the anatomical (and with the surfaces). If the EPI image is of poor quality, then coregistration may be poor as well. Also, typically the “-e” volume should be the same as the one used as reference for motion correction."</i></div><div><i><br></i></div><div>- You’re right that this could be the source of a small error…it looks like the example_functional vols I used are from the middle of the time series, whereas motion correction in SPM is done to match the very first volume. They all look aligned to my eye, but best to keep this consistent. </div><div><i><br></i></div><div><i><br>"As an alternative, if you have coregistered an anatomical image to an EPI image yourself and are confident that the coregistration is good, you can also specify the anatomical volume with the “-a” option (and leave out the “-e” option)."<br></i></div><div><br></div><div>- I can try this as well. Do you think it’s better to coregister the anatomical to the EPI, while keeping its high-rez sampling (1mm iso)? Or to put it in the identical 3mm coordinates as the functional data? I’m not sure if this has a bearing on what happens regarding the surface transformations.</div><div><br></div><div><br></div><div><i>"Indeed. Surfaces from different participants almost always have a different number of vertices, and also the topology (which defines which vertices make up triangles) varies. The resampling ensures that surfaces from different participants have the same number of nodes, the same topology, and also that corresponding nodes are more or less (within the limits of surface-based coregistration across participants) at the same spatial location.”</i></div><div><br></div><div>- OK, thanks for confirming. </div><div><br></div><div><br></div><div><br></div><div><i>"I agree, the alignment is decent but not awesome. Did you use a recent version of PyMVPA? If so, there should be a couple of QA images generated using AFNI’s @AddEdge script; these are the *_ec* and *_ee* files. Can you maybe post / DropBox those so that we can see how the alignment looks there (between EPI and anatomical)."</i><br></div><div><br></div><div>- Yes, I have these images, although don’t know how to interpret them. I’ve added them to the DropBox folder. Thanks.</div><div><br></div><div><br></div><div><br></div><div><i>"Could it be that example_functional_volume.nii is considered in talairach view?”<br></i></div><div><i><br></i></div><div>- Hmmmm… I’m not sure I understand. The volume in question is still in the participants’ native space. Something about linking AFNI with the SUMA surface forces this message. But I had thought that both the functional volume and the SUMA surface are in the same (native) space, so I don’t get where Talairach is creeping in here. </div><div><br></div><div><br></div><div><br></div><div><i>"Indeed, that does not seem what you want. This could be caused by bad coregistration. Another option worth trying (although it does not explain the lack of a peak in A1) is a smaller radius (fewer voxels), to restrict the size of the searchlight.”</i></div><div><br></div><div>- I can try this as well (maybe together with the alternative surf->vol registrations from above). That said, I worry that there’s something worse going on here than small errors in coregistration (the decoding peaks are quite distal from A1). Could there be some sort of vertex mismatch between the suma surface (mh_ico32_al.spec) and the MVPA DSET? (Perhaps I should use a different resolution than 32 for the “lowres_ld” parameter?) I noticed that if I load a higher rez spec file (64 or 128) with the MVPA dset (32), the decoding vertices all get “pushed” to the anterior of the image (I assume because those are where the lower-numbered vertices live), while the posterior of the image is blank (presumably because those nodes have higher-numbered indices than exist in the DSET file). I don’t know how it could have possibly happened, but I wonder if some sort of similar translation could have happened, even when the spec file and dset file match in resolution (32). </div><div><br></div><div><br></div><div><i>"You mean that coregistration seems poor between surfaces and the SurfVol_al2exp+orig volume? That’s weird, because that coregistration should be just as good as the original coregistration between the input (FreeSurfer’s anatomical file and surface file, e.g. the stuff in the SUMA directory).”</i><br></div><div><br></div><div>- No…I mean that the A1 region of the transformed surfaces (in functional space) is suspiciously close to the SMG region of the non-transformed anatomical image (that the original FreeSurfer surfaces were created from). This probably means nothing, but gave me pause :\</div><div><br></div><div><br></div><div><i>"That’s a whole other issue, and there is little literature about doing this. I wrote functionality to do this in two ways:</i></div><i>1) the SPM way, i.e. computing residuals from the group mean and use those to estimate the smoothness. An experimental implementation is in PyMVPA/mvpa2/support/afni/afni_surface_alphasim.py<br>2) Threshold-Free Cluster Enhancement (or any other statistic such as cluster size) using GNU Octave / Matlab. An example is here: <a href="http://cosmomvpa.org/contents_demo.html#demo-surface-tfce" target="_blank">http://cosmomvpa.org/contents_demo.html#demo-surface-tfce</a>. Note that this requires (at the moment) NIML .dset files stored in *ASCII* format, which is not the default when using niml.write."</i><div><br></div><div>- Thanks…this gives me some leads on how to do the group analysis. </div><div><br></div><div><br></div><div><i>"That’s a bit surprising. Did you use ConvertDset, or another program? Have you tried just writing them in ACSII format? If this remains an issue, it may be good if you could make an offending dataset available.”</i></div><div><br></div><div>- I believe I used a FreeSurfer tool for this (mris_convert). But I can try again with ConvertDset…I hadn’t seen this AFNI program before (but I had seen ConvertSurface), not sure what the differences in functionality are between the latter two. I can also try what you’re suggesting and writing directly in ASCII. I, once again, suspect that there’s no actual bug here and that instead I’m doing something subtly moronic. </div><div><br></div><div><br></div><div><i>"So in summary, my first hunch is that coregistration between the functional data and the surfaces is not optimal. Can you try to use an anatomical file as input for pymvpa2-pre-afni-surf with the “-a” option after you’ve verified that the anatomical file is properly co-registered with the EPI image?</i></div><i>Please let me know how it goes, I hope we can get your surface-based analysis to work.”</i><div><br></div><div>- Using a co-registered anatomical for the prep-afni-surf will be my first approach. (Although please advise on the resolution/voxel size I should use!) And thank you again for all of this assistance…I can’t overemphasize how much I appreciate it.</div><div><br></div><div>Best,</div><div>Mike<br><div><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Feb 9, 2015 at 10:10 AM, Nick Oosterhof <span dir="ltr"><<a href="mailto:n.n.oosterhof@googlemail.com" target="_blank">n.n.oosterhof@googlemail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Hello Mike,<br>
<span class=""><br>
On 08 Feb 2015, at 20:58, Mike E. Klein <<a href="mailto:michaeleklein@gmail.com">michaeleklein@gmail.com</a>> wrote:<br>
<br>
> I am attempting to do a surface-informed MVPA analysis and am approaching the “screw it, I’ll stick with my volumetric results” decision point<br>
<br>
</span>I’m sorry to hear that. I wrote most surface-based functionality in PyMVPA, so let’s see and try to resolve this.<br>
<br>
> • 3. pymvpa2-pre-afni-surf run to:<br>
<span class="">> • a. resamples the surfaces to standard topologies (with different resolutions) using MapIcosehedron<br>
> • b. aligns surfaces to a reference functional volume,<br>
> • c. merges left and right hemispheres into single surface files.<br>
> • I did this with pymvpa2-prep-afni-surf -e mySub/example_functional_volume.nii -d surfer/mySub/surf/ -r mySub/new_suma_surfaces/<br>
> • example_functional_volume.nii is taken from my 4D time series.<br>
<br>
</span>Please note that the mySub/example_functional_volume.nii file is the one that is used for coregistration with the anatomical (and with the surfaces). If the EPI image is of poor quality, then coregistration may be poor as well. Also, typically the “-e” volume should be the same as the one used as reference for motion correction.<br>
<br>
As an alternative, if you have coregistered an anatomical image to an EPI image yourself and are confident that the coregistration is good, you can also specify the anatomical volume with the “-a” option (and leave out the “-e” option).<br>
<span class=""><br>
> I visually verified that the entire time series was in good alignment with the example.<br>
> • Step 3a vs. Step 3b is a point of a confusion for me. I think I am being thrown off by the phrase “standard topologies.” We are projecting the anatomically-extracted surface into the functional space so that the functional data does not need to be transformed/interpolated (unintentionally smoothed). If that is the case, then how are “standard topologies” involved? (When I hear standard, I think “standard space” like MNI152, etc.) Is the idea that the -shape- of the surface sheet isn’t altered in this “resampl[ing],” but instead just the specific locations (and numbering schemes) for the vertices/edges? This is the only explanation that makes sense to me.<br>
<br>
</span>Indeed. Surfaces from different participants almost always have a different number of vertices, and also the topology (which defines which vertices make up triangles) varies. The resampling ensures that surfaces from different participants have the same number of nodes, the same topology, and also that corresponding nodes are more or less (within the limits of surface-based coregistration across participants) at the same spatial location.<br>
<br>
> • 4. Visually check the alignment of one of the new suma surfaces (e.g. mh_ico32_al.spec) with the example functional volume using AFNI/SUMA. I am doing this by running:<br>
<span class="">> • afni -niml &<br>
> • suma -spec mh_ico32_al.spec -sv example_functional_volume.nii &<br>
> • (I’m showing this with both a T2 and a T1 image registered the example functional in the T2’s 3mm space, as it’s easier to see.) These images are shown in two of the screenshots.<br>
> • pressing “t” in SUMA to link together AFNI and SUMA<br>
> • This, to me, looks OK, but not great. There is clearly much correspondence between the surfaces and the volume, although the STG/HG area (on right) looks particularly bad to me.<br>
<br>
</span>I agree, the alignment is decent but not awesome. Did you use a recent version of PyMVPA? If so, there should be a couple of QA images generated using AFNI’s @AddEdge script; these are the *_ec* and *_ee* files. Can you maybe post / DropBox those so that we can see how the alignment looks there (between EPI and anatomical).<br>
<br>
> • Separately, I get a warning message about a force switch from the original view to talairach view. I’m not sure why this would be, as all of these volumes and surfaces should be in the functional space…<br>
<br>
Could it be that example_functional_volume.nii is considered in talairach view?<br>
<br>
> • 5. Run the PyMVPA surface searchlight script.<br>
<span class="">> • I’m doing this as a sanity check: decoding sound vs. silence.<br>
> • I’m using the merged (m) hemisphere option and I’m using what I think are essentially default settings:<br>
> • highres_ld = 128<br>
> • pial_surf_fn = os.path.join(surfpath, "ico%d_%sh.pial_al.asc % (highres_ld, hemi))<br>
> • white_surf_fn = os.path.join(surfpath, "ico%d_%sh.smoothwm_al.asc” % (highres_ld, hemi))<br>
> • lowres_ld = 32 # 16, 32 or 64 is reasonable. 4 and 8 are really fast<br>
> • source_surf_fn = os.path.join(surfpath, "ico%d_%sh.intermediate_al.asc % (lowres_ld, hemi))<br>
> • radius = 123<br>
> • qe = disc_surface_queryengine(radius, epi_fn, white_surf_fn, pial_surf_fn, source_surf_fn, nproc=4)<br>
> • clf = LinearCSVMC()<br>
> • cv = CrossValidation(clf, NFoldPartitioner(), errorfx=lambda p, t: np.mean(p == t), enable_ca=['stats’])<br>
<br>
</span>That all looks fine to me.<br>
<br>
> • 6. I’m then checking the results with AFNI/SUMA.<br>
<span class="">> • While I do get very high (almost 100% decoding) in certain regions for sound/silence, the peaks are not along the STG/HG as they should be. Instead they are considerably posterior and superior (the SMG and surrounding). This doesn’t pass the smell test, as is also at odds with my volumetric results, which show maximal decoding in and around A1.<br>
<br>
</span>Indeed, that does not seem what you want. This could be caused by bad coregistration. Another option worth trying (although it does not explain the lack of a peak in A1) is a smaller radius (fewer voxels), to restrict the size of the searchlight.<br>
<br>
> • A stray thought, but if I display the suma surfaces over my anatomical in its native space, the surface-HG region fits over the native anatomical IPL region.<br>
<br>
You mean that coregistration seems poor between surfaces and the SurfVol_al2exp+orig volume? That’s weird, because that coregistration should be just as good as the original coregistration between the input (FreeSurfer’s anatomical file and surface file, e.g. the stuff in the SUMA directory).<br>
<br>
> • And, of course, even if I had all of the issues ironed out, I’m at a loss for how to treat the DSET surface MVPA files in a group analysis. In volume space, I’ve run my information maps through SPM.<br>
<br>
That’s a whole other issue, and there is little literature about doing this. I wrote functionality to do this in two ways:<br>
1) the SPM way, i.e. computing residuals from the group mean and use those to estimate the smoothness. An experimental implementation is in PyMVPA/mvpa2/support/afni/afni_surface_alphasim.py<br>
2) Threshold-Free Cluster Enhancement (or any other statistic such as cluster size) using GNU Octave / Matlab. An example is here: <a href="http://cosmomvpa.org/contents_demo.html#demo-surface-tfce" target="_blank">http://cosmomvpa.org/contents_demo.html#demo-surface-tfce</a>. Note that this requires (at the moment) NIML .dset files stored in *ASCII* format, which is not the default when using niml.write.<br>
<span class=""><br>
> At present, I can’t even get these searchlight result files to load in FreeSurfer’s FreeView (even if I convert file formats to something like GII).<br>
<br>
</span>That’s a bit surprising. Did you use ConvertDset, or another program? Have you tried just writing them in ACSII format? If this remains an issue, it may be good if you could make an offending dataset available.<br>
<br>
So in summary, my first hunch is that coregistration between the functional data and the surfaces is not optimal. Can you try to use an anatomical file as input for pymvpa2-pre-afni-surf with the “-a” option after you’ve verified that the anatomical file is properly co-registered with the EPI image?<br>
<br>
Please let me know how it goes, I hope we can get your surface-based analysis to work.<br>
<br>
best,<br>
Nick<br>
<br>
</blockquote></div><br></div></div></div></div>