[pymvpa] Surface searchlight problems (alignment related)

[Nick Oosterhof]

Hi Mike,

On 09 Feb 2015, at 20:53, Mike E. Klein <michael.e.klein at gmail.com> wrote:

> - 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).

Glad to hear that :-)

> "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."
> 
> - 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. 

Absolutely.

> "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)."
> 
> - 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 would keep the anatomical high-res. If you are downsampling then you would be losing information, which could only hurt the coregistration. 

> "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)."
> 
> - Yes, I have these images, although don’t know how to interpret them. I’ve added them to the DropBox folder. Thanks.

I had a look at them, and indeed they don’t seem to be perfectly aligned. Judging alignment is a subjective process, of course, and for me personally it’s harder to tell without interactively switching on and off the functional overlay while using the anatomical as underlay.

That being said, in particular the “ec” image shows many black lines and white lines, which is suggestive of bad alignment. (by personal email I’ve sent you a pdf file with some guidelines on how alignment can be assessed visually).  

> "Could it be that example_functional_volume.nii is considered in talairach view?”
> 
> - 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. 

I’m not sure, but AFNI clearly thinks it is in Talairach space. It could be due to AFNI using a NIFTI extension to store its own attributes in the NIFTI file. You can try to convert the NIFTI file to AFNI format using 3dcopy (either 3dcopy anat.nii anat+orig or 3dcopy anat.nii anat+tlrc), then open the .HEAD file in an editor and look for the TEMPLATE_SPACE attribute. If it is set to TLRC or MNI, it could explain why AFNI thinks it is in an atlas space.

> "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 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?)

You could try ico128 for really high-res, but I don’t think that’s the issue here.

> 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).

Yes, that’s how it works.

> 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). 

I would be surprised if there was some node indices issue going on here. The NIML dset file should contain the node indices, and these are based on the searchlight output.
Also, your maps still look pretty clear, stable, focal; if there was a node index problem, it would have to be a very subtle one to get such decent looking maps.

> "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).”
> 
> - 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 :\

So far my best guess is suboptimal alignment. 
> 
> 
> - 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.

ConvertDset is for overlay files (those that give pretty colours to the nodes).
ConvertSurface is for surfaces and contain coordinates of nodes and the topology (faces)

> - 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.

You’re very welcome, and please let us know if that resolves the issue.

best,
Nick