Freesurfer .mgz to .niml for 3dMVM, 3dLME etc

AFNI Message Board
1

Hi,

This is a pretty basic question. I have freesurfer data for the left and right hemisphere in .mgz format. The volumetric data has already been linked etc. I would like to use SUMA to create .niml datasets so that we can use 3dMVM or 3dLME for our group analysis. Running the following errors:

@SUMA_Make_Spec_FS -sid taskBOLD_SST_S10 -use_mgz -NIFTI

failure: cannot find directory ‘orig’ or file ‘orig.mgz’ under surf
program failure: exiting…

-fspath = path to ‘surf’ and ‘orig’ directories. < I don’t have these files just the .mgz. Therefore, is there a workaround? Like I mentioned, the real purpose is to get freesurfer surface data in a usable format for 3dLME and 3dMVM.

Lastly, although 3dMVM and 3dLME are computationally expensive, would they work with 12,000 subjects as long as there is enough computing power?

Thanks,
Shana

2

Hi, Shana-

I’m not quite understanding what data you have available after running FS. Typically, there is a directory (let’s call it DDD) that contains subdirectories such as “label/”, “mri/”, “scripts/”, etc. Then, to convert everything to AFNI+SUMA, you could just run something like this:


@SUMA_Make_Spec_FS                            \
    -NIFTI                                    \
    -fspath DDD                \
    -sid    SSS

where SSS will be prefix used in naming convert files like the “SurfVol” dset. This will generate a new subdirectory in DDD called SUMA/, which will contain the AFNI+SUMA outputs.

Do you not have a main directory like DDD?

Re. “-use_mgz”: I have never used this option, so I am not exactly sure of its purpose actually… Can I ask why you want to use that? Looking at the @SUMA_Make_Spec_FS help file, under the “-NIFTI” option, which you are also using, please note the last line copied here:


-NIFTI :Produce files in exchangeable formats. With this option
           :COR volumes are no longer used and output volumes
           :and surfaces are in alignment with the original 
           :volume used to create the surface. All volumes are
            written out NIFTI format, and all surfaces are
            in GIFTI format.

            This option is incompatible with -neuro or -use_mgz

So, it looks like having -NIFTI and -use_mgz would be conflicting options

I believe that something quite close to the first command posted in this reply (“@SUMA_Make_Spec_FS …”) would make it possible to do 3dLME, etc. analysis, so perhaps that would be worth trying?

Re. 12000 subjects (!!!), wow! Ummm, I guess it would be computer-RAM dependent, I don’t know.

–pt

3

Hi Paul,

Thanks for your reply.

  1. We don’t have a directory called “DDD” with subdirectories such as “label/”, “mri/”, “scripts/”, etc. All we have are surface data files that have already been aligned to a standard mesh and linked to the volume data (separately for left and right hemispheres), which allows us to do group analyses. The end results are .mgz files for the L and R hemispheres.

  2. Thank you for clarifying those steps but I don’t know how to get around this issue without those subdirectories. Previously, we were running the group analysis on the surface with workbench (HCP). We a) merged the left and right hemispheres; b) created a large 4D file; c) ran PALM (FSL) for the group analysis. However, PALM does not allow mixed models with multiple covariates and nested random effects. Hence, we would like to use AFNI’s 3dLME command.

Is there any workaround for not having a -fspath DDD directory?

4

You can use mris_convert (part of freesurfer) to convert the MGZ files to GIFTI (.gii) and then process them in AFNI’s 3dLME.

5

Thanks for this information. I went ahead and did that but I am still having difficulty getting the group analysis to recognize the GIFTI files - any thoughts?

  1. Run conversion from .mgz to .gii
    mris_convert -f taskBOLD_nBack_scan_8_lh.mgz $FREESURFER_HOME/subjects/fsaverage/surf/lh.white S1.l.func.gii

  2. Use HCP pipeline to align to a standard mesh and merge hemispherse → dscalar.nii file

  3. Run 3dMVM which errors out:
    *+ WARNING: NO spatial transform (neither qform nor sform), in NIfTI file ‘SST_BOLD_S10_LR.dscalar.nii’
    Then it says,

** Error:
Problem with input files! Two possibilities: 1) There is a specification error
with either file path or file name. Use shell command ‘ls’ on the last column in the
data table to find out the problem. 2) At least one of the input files has different
dimensions. Run “3dinfo -header_line -prefix -same_grid -n4 *.HEAD” in the directory
where the files are stored, and pinpoint out which file(s) is the trouble maker.
Replace *.HEAD with *.nii or something similar for other file formats.

  1. 3dinfo -header specified no errors in dimensions between files

3dinfo -header_line -prefix -same_grid -n4 *.func.gii
prefix =grid? Ni Nj Nk Nv
S1.l.func.gii 1 10242 1 1 37
S2.l.func.gii 1 10242 1 1 31

  1. Just using the .func.gii files and ignoring the steps to combine the hemispheres and align to a standard mesh, still produces an error stating that the file inputs are problematic.
6

Hi Again-

It’s not clear entirely what’s going on in your pipeline. My initial idea was simply to convert your MGZ files into GIFTI files doing something like what’s described on my other blog:


mris_convert -c ./lh.thickness.fwhm10.fsaverage.mgh \
$SUBJECTS_DIR/fsaverage/surf/lh.white \
Subject01.lh.thickness.fsaverage.gii

No need to merge the hemispheres, just run two analyses. Or three if you want volume as well. I was assuming that your surfaces files were already aligned to some template. It sounds like you might be dealing with HCP data, in which case it would help to say what download you used.

Be careful that you’re actually using NIFTI and GIFTI files, as in HCP-land, files like dscalar.nii file is likely a CIFTI file. While there’s some (growing) support for CIFTI in AFNI, it would be better to split it into surfaces and volumes using the workbench tools (wb_command).

Hopefully that makes more sense.

-Peter