Registration orientation issue.

[Chris Allen]

Dear Cosmo people,

I’m having some trouble with the orientation of surface projected outcomes (see figure – that blob at the bottom of the temporal lobe should be in the occipital lobe). I’m using freesurfer to construct the surfaces and FSL to conduct the fMRI analyses, with the exemption that I carry out the final stage of the registration using SPM, as doing so allows me to maintain original voxcel size (if I use flirt or mri_vol2vol the data size gets too big to handle). I’m applying cosmo to a concatenated set of cope images. The registrations look acceptable in freeview, fsleyes and spm viewer. It just goes wrong at the ‘cosmo_surficial_neighborhood’ or possibly the ‘cosmo_fmri_dataset’ stage. I have tried a few different routes to registration (spm, fls only, freesurfer bbr), all with similar results. I have also tried using ‘cosmo_fmri_reorient’, where I reoirentate the functional data to that of the freesurfer structural, but this was not successful, and while it does change the ds.a.vol.mat information the projection on the surface looks the same. I also tried ‘cosmo_fmri_reorient’ with different combinations and they did not affect the outcome. The only thing that worked was shifting everything to standard space (including the structural before I run recon -all), but these analyses aught to be run in native space.

So do you know where I might be going wrong? Does this orientation problem look in anyway failure? Any help would be very much appreciated. Thanks. Chris

[raffaele tucciarelli]

Hi, 

I do not have a solution, but this looks like a registration issue. 

The registrations look acceptable in freeview, fsleyes and spm viewer. It just goes wrong at the ‘cosmo_surficial_neighborhood’ or possibly the ‘cosmo_fmri_dataset’ stage. I have tried a few different routes to registration (spm, fls only, freesurfer bbr), all with similar results.

Are you sure you are not applying some registration by default when opening the surface and volumes in Freeview? Have you tried to open them in vb_view (workbench connectome)? Cosmomvpa does not apply any registration, so the volume and surface should be already aligned. 

Raffa

--
You received this message because you are subscribed to the Google Groups "CoSMoMVPA" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cosmomvpa+...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/cosmomvpa/87c97d95-4289-44a6-8dea-0858bc02fdd1n%40googlegroups.com.

[Chris Allen]

Thanks. Yes I’ve just downloaded workbench connectome and had a look with wb_view (so I’m not totally sure what I’m doing with wb_view) but when I overlay the functional onto the structural from freesurfer they look to align just fine (same as other programs). Cheers, Chris

[raffaele tucciarelli]

Great, thanks. 

You should also upload the surfaces (they should be in gifti format and the file name should end with .surf.gii). When you have uploaded them, you can see the outline of the surfaces on the volumes by selecting them in the "Vol/Surf Outline" section (you can see it in the picture that you sent)

Raffa

To view this discussion on the web, visit https://groups.google.com/d/msgid/cosmomvpa/af4429d9-5f12-4fa1-b326-7a73ea43c843n%40googlegroups.com.

[Chris Allen]

That’s helpful. Thanks.

However, as I’m using freesurfer surfaces I have to convert them, which I did via afni’s ConvertSurface. This allows me to load the surfaces but will not allow me to overlay them as you suggest using Vol/Surf Outline – the ‘file’ bar is empty and cannot be filed (see figure). If I look at the surface information using ‘wb_command -file-information’ some of the fields seem to have been incorrectly assigned e.g ‘Surface Type (Primary): Unknown’ and ‘Structure: CortexLeft’ (which, I think, should be CORTEX_LEFT) and ‘wb_command -set-structure’ will not allow me to change the information (it gives ‘ERROR: unrecognized structure type’ regardless of what I enter).

Sorry to bother you with these issues. If you have any suggestions, great.

I suspect these later problems are probably due to jumping between programs and are unlikely to be the cause of my primary problems with cosmo, but do let me know if you think otherwise. Is there another way to check the registration and alignment? I’ve attached figures form freeview where you can see the surfaces and volumetric data all seem to align fine (1: structural and surface, 2: epi and surface, 3 cope and surface). Here Freeview only applies the transforms (which look like they make sense) in the headers which is the same information as cosmo gets. Thanks again and sorry for the hassle. Chris

[raffaele tucciarelli]

Hi, 

thanks for the images, these are very helpful

Here Freeview only applies the transforms (which look like they make sense) in the headers which is the same information as cosmo gets.

I don't think Cosmo applies any transformation from the header (Nick can jump in here to confirm), I think you have to be sure that the surface and volume data are aligned before using Cosmo. 

Freesurfer applies a transformation by default, but vb_view does not do that, as I understand it. And you can see that the surface and volume are completely off. 

This is what I do (I have taken the script from the HCPpipelines, see link), maybe you want to try it and see it solves the problem? You should do this for each surface you want to use (in the example below, I am showing the lf.inflated surface). 

# from: https://github.com/Washington-University/HCPpipelines/blob/master/FreeSurfer/scripts/FreeSurferHiresPial.sh

# Deal with FreeSurfer c_ras offset (might be able to simplify this with FS 6.0)

# -- Corrected code using native mri_info --cras function to build the needed variables

MatrixXYZ=`mri_info --cras ${mridir}/brain.finalsurfs.mgz`

MatrixX=`echo ${MatrixXYZ} | awk '{print $1;}'`

MatrixY=`echo ${MatrixXYZ} | awk '{print $2;}'`

MatrixZ=`echo ${MatrixXYZ} | awk '{print $3;}'`

echo "1 0 0 ${MatrixX}" >  ${mridir}/c_ras.mat

echo "0 1 0 ${MatrixY}" >> ${mridir}/c_ras.mat

echo "0 0 1 ${MatrixZ}" >> ${mridir}/c_ras.mat

echo "0 0 0 1"          >> ${mridir}/c_ras.mat

# go into the current subject mri folder

cd ${pathToData}/SUB01/surf

# LEFT INFLATED

mris_convert lh.inflated lh.inflated.surf.gii

${WBDIR}/wb_command -set-structure "$surfdir"/lh.inflated.surf.gii CORTEX_LEFT

${WBDIR}/wb_command -surface-apply-affine "$surfdir"/lh.inflated.surf.gii $mridir/c_ras.mat "$surfdir"/lh.inflated.surf.gii

I hope this helps!
Raffa

To view this discussion on the web, visit https://groups.google.com/d/msgid/cosmomvpa/9b3f213d-d0d7-4207-b2a9-99bc60c74081n%40googlegroups.com.

[Nick Oosterhof]

Hi Chris and Raffaele,

On 21 Mar 2024, at 18:20, raffaele tucciarelli <rtucci...@gmail.com> wrote:

Hi, 

thanks for the images, these are very helpful

Here Freeview only applies the transforms (which look like they make sense) in the headers which is the same information as cosmo gets.

I don't think Cosmo applies any transformation from the header (Nick can jump in here to confirm), I think you have to be sure that the surface and volume data are aligned before using Cosmo. 

Indeed CoSMoMVPA does not apply any transformation when reading fMRI or surface data files. Also cosmo_fmri_reorient does not apply any transformation.

I wonder if there are more sources of transformations  that are ‘automatically’ applied by some but not all programs. I do remember when using AFNI programs, it was helpful to reset some transformation matrices to the identify matrix (this may be similar to the code fragment shared by Raffaele).  For the details, see https://github.com/PyMVPA/PyMVPA/blob/master/mvpa2/support/afni/lib_prep_afni_surf.py around line 741 (“nuke afni headers”). I do remember getting the transformations right took me quite a bit of time to figure out…

Do you have insights in whether there are extra transformations specified, for example in the header of some file? 

best,

Nick

[Chris Allen]

Thanks both. Yes the offset was the problem! I used the method Raffa suggested and my surfaces are now in the right place (see figure – surface on left is the free surfer white, incorrectly above a functional volume, and the pial surface on the left is realigned using Raffa’s method). Also it now works in cosmo with classification where it should be (occipital in figure). I’ve been struggling with this problem for a while so you help and the solution are very much appreciated. Thanks again!