Hi all,
I'm not sure where the best place to make this request is. so I thought I'll put this here.
I often use freesurfer generated surfaces and images in other software packages (Slicer, Matlab etc) for various things. The MGZ files include the origin in the file headers, meaning that software can correctly interpret the world spaces of these images, allowing correct overlays with other results computed from the same scans. The problem is that the surface files treat the 128,128,128 voxel ( of the T1.mgz and other images) as the origin. But the world coordinates of this origin are, to my knowledge not in the surface files.
This creates the situation that to correctly interpret these surfaces in relation to other coordinates systems, basically I either need to ignore the world coordinates and do some registration, or I need to load both an mgz file (to get the origin) and surface files to learn correct world coordinates of the surfaces. Ideally it seems like this information should be included in the surface files themselves.
Hopefully my description of the problem makes some sense.
Thanks.
Luke
Luke,
A quick answer (w/o looking into it too much): does:
mris_info rh.pial
give you the info you need? what i'm not sure of is whether everything you see in that output is available in the structure that the matlab surface reader loads.
Nick
On Wed, 2012-11-07 at 09:17 -0500, Luke Bloy wrote:
Hi all,
I’m not sure where the best place to make this request is… so I thought I’ll put this here.
I often use freesurfer generated surfaces and images in other software packages (Slicer, Matlab etc) for various things. The MGZ files include the origin in the file headers, meaning that software can correctly interpret the world spaces of these images, allowing correct overlays with other results computed from the same scans. The problem is that the surface files treat the 128,128,128 voxel ( of the T1.mgz and other images) as the origin. But the world coordinates of this origin are, to my knowledge not in the surface files.
This creates the situation that to correctly interpret these surfaces in relation to other coordinates systems, basically I either need to ignore the world coordinates and do some registration, or I need to load both an mgz file (to get the origin) and surface files to learn correct world coordinates of the surfaces. Ideally it seems like this information should be included in the surface files themselves.
Hopefully my description of the problem makes some sense.
Thanks.
Luke
Freesurfer mailing list Freesurfer@nmr.mgh.harvard.edu https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
Thanks for the reply Nick,
Yes mris_info does return information I would need.
volume geometry: extent : (256, 256, 256) voxel : ( 1.0000, 1.0000, 1.0000) x_(ras) : (-1.0000, 0.0000, 0.0000) y_(ras) : ( 0.0000, 0.0000, -1.0000) z_(ras) : ( 0.0000, 1.0000, 0.0000) c_(ras) : ( 5.8612, -8.9756, -36.8004) file : ../mri/filled-pretess255.mgz
interestingly even if I move the surface file out of the subject's surf directory it still returns this info, making me think that it is in the file somewhere.
I was looking at read_surf.m last night and it doesnt seem to do anything with this info, and http://wideman-one.com/gw/brain/fs/surfacefileformats.htm doesn't mention any of this info being in the file. is there an updated spec file on the file formats?
Thanks. -Luke
On Wed, Nov 7, 2012 at 3:26 PM, Nick Schmansky nicks@nmr.mgh.harvard.eduwrote:
Luke,
A quick answer (w/o looking into it too much): does:
mris_info rh.pial
give you the info you need? what i'm not sure of is whether everything you see in that output is available in the structure that the matlab surface reader loads.
Nick
On Wed, 2012-11-07 at 09:17 -0500, Luke Bloy wrote:
Hi all,
I’m not sure where the best place to make this request is… so I thought I’ll put this here.
I often use freesurfer generated surfaces and images in other software packages (Slicer, Matlab etc) for various things. The MGZ files include the origin in the file headers, meaning that software can correctly interpret the world spaces of these images, allowing correct overlays with other results computed from the same scans. The problem is that the surface files treat the 128,128,128 voxel ( of the T1.mgz and other images) as the origin. But the world coordinates of this origin are, to my knowledge not in the surface files.
This creates the situation that to correctly interpret these surfaces in relation to other coordinates systems, basically I either need to ignore the world coordinates and do some registration, or I need to load both an mgz file (to get the origin) and surface files to learn correct world coordinates of the surfaces. Ideally it seems like this information should be included in the surface files themselves.
Hopefully my description of the problem makes some sense.
Thanks.
Luke
Freesurfer mailing list Freesurfer@nmr.mgh.harvard.edu https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
The information in this e-mail is intended only for the person to whom it is addressed. If you believe this e-mail was sent to you in error and the e-mail contains patient information, please contact the Partners Compliance HelpLine at http://www.partners.org/complianceline . If the e-mail was sent to you in error but does not contain patient information, please contact the sender and properly dispose of the e-mail.
Luke,
attached is a modified read_surf.m which reads the stuff written after the vertex and face data normally found in the surface binary-formatted file. this was reverse-engineered from the source files 'mrisurf.c' (function MRISwriteTriangularSurface) and 'transform.c' (function writeVolGeom). so the new call is:
[v,f,flags,tags]=read_surf('rh.pial');
you can ignore 'flags', and 'tags' is char array, which can be printed, like this:
sprintf('%s',tags)
giving output like:
ans =
valid = 1 # volume info valid filename = ../mri/filled-pretess127.mgz volume = 256 256 256 voxelsize = 1.000000000000000e+00 1.000000000000000e+00 1.000000000000000e+00 xras = -1.000000000000000e+00 0.000000000000000e+00 0.000000000000000e +00 yras = 0.000000000000000e+00 0.000000000000000e+00 -1.000000000000000e +00 zras = 0.000000000000000e+00 1.000000000000000e+00 0.000000000000000e +00 cras = 5.399719238281250e+00 1.800000000000000e+01 0.000000000000000e +00 mris_remove_intersection ../surf/rh.orig ......
the volume geometry will always be the first eight lines of text. unfortunately, being text, you will need to do further parsing to extract what you need. after the volume geometry info are provenance strings.
Nick
On Thu, 2012-11-08 at 08:21 -0500, Luke Bloy wrote:
Thanks for the reply Nick,
Yes mris_info does return information I would need.
volume geometry: extent : (256, 256, 256) voxel : ( 1.0000, 1.0000, 1.0000) x_(ras) : (-1.0000, 0.0000, 0.0000) y_(ras) : ( 0.0000, 0.0000, -1.0000) z_(ras) : ( 0.0000, 1.0000, 0.0000) c_(ras) : ( 5.8612, -8.9756, -36.8004) file : ../mri/filled-pretess255.mgz
interestingly even if I move the surface file out of the subject's surf directory it still returns this info, making me think that it is in the file somewhere.
I was looking at read_surf.m last night and it doesnt seem to do anything with this info, and http://wideman-one.com/gw/brain/fs/surfacefileformats.htm doesn't mention any of this info being in the file. is there an updated spec file on the file formats?
Thanks. -Luke
On Wed, Nov 7, 2012 at 3:26 PM, Nick Schmansky nicks@nmr.mgh.harvard.edu wrote: Luke,
A quick answer (w/o looking into it too much): does: mris_info rh.pial give you the info you need? what i'm not sure of is whether everything you see in that output is available in the structure that the matlab surface reader loads. Nick On Wed, 2012-11-07 at 09:17 -0500, Luke Bloy wrote: > Hi all, > > > > I’m not sure where the best place to make this request is… so I > thought I’ll put this here. > > > > I often use freesurfer generated surfaces and images in other software > packages (Slicer, Matlab etc) for various things. The MGZ files > include the origin in the file headers, meaning that software can > correctly interpret the world spaces of these images, allowing correct > overlays with other results computed from the same scans. The problem > is that the surface files treat the 128,128,128 voxel ( of the T1.mgz > and other images) as the origin. But the world coordinates of this > origin are, to my knowledge not in the surface files. > > > > This creates the situation that to correctly interpret these surfaces > in relation to other coordinates systems, basically I either need to > ignore the world coordinates and do some registration, or I need to > load both an mgz file (to get the origin) and surface files to learn > correct world coordinates of the surfaces. Ideally it seems like this > information should be included in the surface files themselves. > > > > Hopefully my description of the problem makes some sense. > > > > Thanks. > > Luke > > > > > _______________________________________________ > Freesurfer mailing list > Freesurfer@nmr.mgh.harvard.edu > https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer The information in this e-mail is intended only for the person to whom it is addressed. If you believe this e-mail was sent to you in error and the e-mail contains patient information, please contact the Partners Compliance HelpLine at http://www.partners.org/complianceline . If the e-mail was sent to you in error but does not contain patient information, please contact the sender and properly dispose of the e-mail.
freesurfer@nmr.mgh.harvard.edu
-
Luke Bloy -
Nick Schmansky