Closed ejolly closed 6 years ago
My guess is that your IPython session doesn't have the right environment variables to find Freesurfer or your subjects directory. We recently pushed a change that should print more verbose information about what's happening when mri_vol2surf
fails inside of project_volume_data
but for now you should also be able to debug the problem by trying to call mri_vol2surf
with subprocess inside your IPython session (not by copying into a different terminal).
Thanks for the quick reply! I updated to the current repo version which provides a bit more error info but it's still failing. Manually calling Popen with .communicate() (rather than copying to a terminal), and passing in the command generated by project_volume_data(), actually works by itself (thanks for the tip), so I'm not quite sure why it's failing.
Here's some more info: The command generated by project_volume_data():
mri_vol2surf --mov ./tMap.nii.gz --hemi rh --surf white --reg /Applications/freesurfer/average/mni152.register.dat --projfrac-avg 0 1 0.1 --surf-fwhm 3 --o /var/folders/p1/t3qj8xj55nnc_2brmyn_ckc00000gn/T/pysurfer-v2sKSjbar.mgz
The error:
RuntimeError: mri_vol2surf command failed with output:
dyld: lazy symbol binding failed: Symbol not found: ___emutls_get_address
Referenced from: /Applications/freesurfer/bin/../lib/gcc/lib/libgomp.1.dylib
Expected in: /usr/lib/libSystem.B.dylib
dyld: Symbol not found: ___emutls_get_address
Referenced from: /Applications/freesurfer/bin/../lib/gcc/lib/libgomp.1.dylib
Expected in: /usr/lib/libSystem.B.dylib
Then the stdout from manually calling Popen with .communicate(), showing that it works:
srcvol = ./tMap.nii.gz
srcreg = /Applications/freesurfer/average/mni152.register.dat
srcregold = 0
srcwarp unspecified
surf = white
hemi = rh
ProjFrac = 0.5
thickness = thickness
reshape = 0
interp = nearest
float2int = round
GetProjMax = 0
INFO: float2int code = 0
niiRead(): NIFTI_UNITS_UNKNOWN, assuming mm
Done loading volume
INFO: This REGISTER_DAT transform is valid only for volumes between COR types with c_(r,a,s) = 0.
Input reg is register.dat
WARNING: the voxel resolution in the source volume (2,2,2) differs
from that listed in the registration file (1,1,1)
-------- original matrix -----------
0.99753 -0.00732 0.01760 0.95709;
-0.01296 -0.00926 0.99706 -17.81596;
-0.01460 -1.00094 0.00244 -18.54964;
0.00000 0.00000 0.00000 1.00000;
-------- original matrix -----------
Reading surface /Applications/freesurfer/subjects/fsaverage/surf/rh.white
Done reading source surface
Reading thickness /Applications/freesurfer/subjects/fsaverage/surf/rh.thickness
Done
Mapping Source Volume onto Source Subject Surface
1 0 0 0
using old
Done mapping volume to surface
Number of source voxels hit = 21216
Writing to /var/folders/p1/t3qj8xj55nnc_2brmyn_ckc00000gn/T/pysurfer-v2sKSjbar.mgz
Dim: 163842 1 1
It sounds like https://github.com/nipy/PySurfer/issues/171, which ended up being some issue with MacOS sandboxing some programs. I have not updated my OSX so I have no personal experience with this issue or ability to fiddle around with it. But it's interesting that just executing mri_vol2surf
from IPython works fine.
As of #132 (see also the linked original issue, #102), project_volume_data
also sources the Freesurfer setup script, which may actually be what is causing the problem. If that's the case we may want to revert #132.
@ejolly I made a PR back in June (#194) that should fix this, feel free to reopen if it doesn't work on master
When converting an fMRI volume to be projected onto a surface visualization, project_volume_data() always returns a 'mri_vol2surf command failed,' but if I literally copy and paste the command it generated into a terminal window it runs perfectly fine.
My temporary work-around has been manually calling read_scalar_data() (which I noticed is what project_volume_data() uses internally to retrieve the resulting converted file) on the file generated by mri_vol2surf and then passing the generated instance to brain.add_overlay(), which works without a problem. Not sure if something weird is happening in how the subprocess is being called within read_scalar_data?
System info (doing this all from within a jupyter notebook): OSX 10.11.6 jupyter notebook 4.3.1 pysurfer 0.7 ipython 4.1.2 python 2.7.11 conda 4.3.13