[pymvpa] Surface searchlight problems (alignment related)

[Mike E. Klein]

Hi Nick and list,

I’m still stuck, but perhaps getting closer to the solution. I think the
big issues are related to template/non-template space and afni/nifti
issues. I don’t know how to resolve them, but perhaps you do. Here’s what
I’ve been up to regarding the surface MVPA analysis. Apologies for the
length, but I don’t know how to concisify this.

*Part I: attempt to align T1 to epi, then align surfaces to aligned T1*

1. AFNI can do intermodal realignment, but its *realign_anat_epi.py* fails
if given nifti files (at least on my system). I’ve saved the command line
error outputs in a text file, but don’t know how relevant that is right now.
2. I made an attempt to try this approach by converting from nii to
head/brik using 3dcopy on the finalsurfts nifti file (from FreeSurfer),
running the realignment, and then converting back to nifti with
*3dAFNItoNIFTI* to input to pymvpa. These afni scripts did not fail (both
conversion and realignment), however when I checked the end result of
coregistration in MRICron, something went terribly wrong. (See the png file
*nii-afni-nii_realign* in the “take2” folder in dropbox.)
3. Because of all the problems I had above with AFNI and format conversion,
I instead turned to FSL and/or SPM to realign my anatomical to functional.
However, FSL and SPM seem to force the re-aligned anatomical to take the
voxel resolution of the EPI (3mm iso). FSL has a special menu that allows
one to specific image overall dimensions, but I couldn't suss out the
proper dimensions to enter. I got around this issue by resampling the
example epi image from 3mm to 1mm using a program called *c3d from itksnap*.
I could then use SPM to realign the anatomical (from freesurfer) to the epi
without downsampling it (and without having to convert file formats). The
results look pretty good, as viewed with MRICron (png file
*nii_SPM_1mm_realign*). That said, all of these problems left me a bit
bugged out about whether some sort of registration error has been
introduced. It seems to me that most standard tools are geared toward
registering epi images to anatomicals…going the other way is much more
unusual.
4. I ran pymvpa2-prep-afni-surf on the newly generated aligned anatomical
and this seemed to work (as viewed in AFNI/SUMA). The results certainly
look better than the prior attempt (registering directly to the epi),
however, they still don’t look great. The output images from this new
attempt are now in the dropbox sub-folder (*05-qa files
and nii_T2-under-surface_suma*). Something still looks a bit off, although
I still suspect the registration is not poor enough to fully explain the
bizarre MVPA results.
5. I re-ran the MVPA using smaller searchlights (50 voxels) and a lower
resolution surface file (16), the latter primarily to save time during
debugging. Same problem emerges: sound/silence decoding way too
posterior/superior to make sense. (See png images *sound-silence_surfaceL *and
*sound-silence_surfaceR*).


*Part II: noticing misalignment via FreeView and detailing my preprocessing
pipeline*

1. Both the lack of mvpa improvement with better registration, and the
weird afni talairach popup messages from earlier made me think that
something more sinister is going on here. I did the recommended step of
converting my epi to brik format to look at the space afni considers it to
be: answer is *Talairach*! I do not know why.
2. I then opened up the aligned surfaces and epi again,  but this time
using FreeSurfer freeview rather than afni / SUMA. And *boom*! There's the
problem (*bad_registration_freeview.png*)...these images are horribly
misaligned. And in such a way that the epi 's auditory cortex is basically
overlaid with the surface's SMG. I think that afni and suma were hiding
this ugliness from me and displaying that Talairach warning to let me know
that something was up.
3. I next want to detail what I did to my epis ahead of time, because it is
a bit atypical and perhaps sheds some light on why AFNI thinks these files
are not in scanner/native space.
     3a. Convert dicoms to nii using *DCM2NII* from the developer of
MRICron.
     3b. Align (motion correct) the multi-run time series in SPM8.
     3c. Due to the specifics of my BOLD acquisition sequences (Interleaved
Silent Steady State: http://www.ncbi.nlm.nih.gov/pubmed/16226896, the nitty
gritty of which I don’t think is relevant here), I then average together
pairs of epis with fslmaths, in order to get a single image per trial.
     3d. Since SPM introduces certain NAN values to the volumes during
alignment, I then run all the images through an FSL tool (*fslmaths*) that
converts any NAN values to zeros. (Otherwise PyMVPA fails.)
     3e. The 3d files are then concatenated to a single 4d file for MVPA
via *fslmerge*.
4. I took a couple of screenshots of the info displayed by MRICron about
these images (*MRICron_info 1 and 2*)…but nothing looks out of sorts to me.
(Neither the quaternion nor affine parameters are set to "Normalized Tal.”)
Again, I have no idea how these things could have been Talairachified by
the above steps...


*Part III: New attempts that haven’t worked with pymvpa2-prep-afni-surf*

1. First, as a sanity check, I ran an MVPA using the original (non-aligned)
FreeSurfer surfaces…while they are in register with the T1, not the T2s,
they aren’t too too far off. This did dramatically alter the decoding
results: peaks are much more anterior, although drift up into the
parietal/frontal operculum (as this registration is, of course, not quite
right).
2. I tried converting my nifti files (epi or anatomical) to afni (using
*3dcopy*) and running prep-afni-surf again. (All this file format
conversion scares the crap out of me…I would minimize this if possible.)
Aligned surface is still terribly shifted from my nii epi (see*
freeview_surfaceWafni-epi*.png). I can’t seem to load afni format with this
application, so showing the nii instead.
3. Same as 2, but I copied the afni BRIK/HEAD files, opened the head and
manually changed “TLRC” to “ORIG.” Generated surfaces creates a similar
gross misalignment between surface and volume (as viewed in FreeView).
4. Went back to the nii epi, but ran prep-afni-surf with the* -t option*
(telling the script explicitly that the epi volume is not in template
space). This code fails (after running for quite some time), reporting an
invalid input dataset. (The entire output is in
*aaa_prep-afni-surf_niiWdasht*.txt).
5. Thinking that perhaps I zigged when I was supposed to zag, I re-ran as
in 4, except used the *-T (upper case)* option to indicate that the epi *IS*
in template space! This code ran, but generated misaligned outputs similar
to above (image *freeview_surface2nii-epi-dashT*).


So I’m fairly out of ideas at this point. I’m considering re-running
FreeSurfer recon-all on the T1s that have been pre-aligned with the epi
(although I think this is not ideal for FreeSurfer). Although even in that
case I will still need to run prep-afni-surf for it’s various non-alignment
functionalities.

Once again, any help would be greatly appreciated. It would be lovely if
this effort actually churns out something workable in the end!

Best,
Mike


On Tue, Feb 10, 2015 at 3:48 AM, Nick Oosterhof <
n.n.oosterhof at googlemail.com> wrote:

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/pkg-exppsy-pymvpa/attachments/20150213/02911c69/attachment-0001.html>