Freesurfer has a coordinate displacement between their surfaces and volumes, which depends on the volume space that was used. That might be part of the picture. However, this is purely a shift, no rotation or flip, and I think is typically about half the brain size, so something else must also be going on.
Another thing that that the HCP pipelines do is that they pull some tricks to avoid downsampling the 0.7mm structural images when putting them through freesurfer. This involves a specific cropping and faking a new volume space that pretends to be 1mm isotropic. The HCP pipelines correct for this change in coordinate space, and also correct for the shift that freesurfer puts into its surface coordinates. The end result is that all of the anatomical gifti surface outputs from the HCP pipelines have raw coordinates that are already aligned with the relevant 0.7mm T1 voxel coordinates (NOT the modified volumes that it runs freesurfer on), per the nifti standard coordinate conventions (via the sform method). Thus, wb_view and wb_command do not need to apply any shifts when reading, displaying, or computing in order to align them. Hopefully this is useful information for understanding what the issue might be. Here are some relevant code snippets as to how we interpret the coordinate information in the file types in question, which might be useful to the Brainstorm developers: Note that we do not apply any of the transform matrices that are in the gifti file, because freesurfer does something strange with them: https://github.com/Washington-University/workbench/blob/master/src/Files/SurfaceFile.cxx#L263 So, we use the coordinate array exactly as it comes out of the base64/gzip encoding. Using nifti sform info: https://github.com/Washington-University/workbench/blob/master/src/FilesBase/VolumeSpace.h#L145 m_sform is just a copy of the sform fields from the nifti header (as long as sform_code is nonzero, see https://github.com/Washington-University/workbench/blob/master/src/Nifti/NiftiHeader.cxx#L220 - otherwise it constructs the equivalent sform from whatever spacing information is available) Some computation code showing direct comparison of voxel and surface coordinates: https://github.com/Washington-University/workbench/blob/master/src/Algorithms/AlgorithmVolumeToSurfaceMapping.cxx#L306 Tim On Tue, Jan 31, 2017 at 4:33 PM, K Jeffrey Eriksen <eriks...@ohsu.edu> wrote: > Hello, > > I am a very new HCP Connectome WB user trying to import nifti and gifti > files into Brainstorm (Bst) for EEG modeling. I am having a strange problem > and am looking for some direction. In the past I was able to import T1.nii > volume files and lh.pial/rh.pial files from FreeSurfer with no problem into > Brainstorm. Now I am trying to import similar files proceed by the HCP > pipeline. Let me call these HCP-T1 and HCP-cortsurf, and the original > FreeSurfer files FS-T1 and FS-cortsurf. > > When I import the FS files into Bst they can be plotted in 3D, and align > well. However, when I import the HCP-T1 and HCP-cortsurf, they do not > align. In fact, assuming the T1 is correctly displayed, the surface ends up > displaced about two head diameters worth and is also inverted L-R and > upside down. This is very odd since these same two files align perfectly > when viewed with the Connectome Workbench. > > I need to point out that the FS-cortsurf is a full 250,000 vertex file for > a particular subject, while the HCP-cortsurf is the 64,000 vertex version > using the HCP standard. > > Please provide me with some suggestions of how to begin to address this > problem. The Brainstorm support personnel are unable to help me on this. > > Thanks, > -Jeff > > _______________________________________________ > HCP-Users mailing list > HCP-Users@humanconnectome.org > http://lists.humanconnectome.org/mailman/listinfo/hcp-users > _______________________________________________ HCP-Users mailing list HCP-Users@humanconnectome.org http://lists.humanconnectome.org/mailman/listinfo/hcp-users
