[Freesurfer] mri_surf2surf to fsaverageX introduces offset
Dear Freesurfers, I tried to map a single subject surface to fsaverageX (for the sake of demonstration lets take fsaverage6). I did the following: mri_surf2surf --hemi lh --srcsubject $s --sval-xyz white --trgsubject fsaverage6 --tval-xyz --tval ./lh.white.ico6 This produces a surface that seems systematically shifted (see figure). Also the newly generated surface does not contain valid geomery information (see mris_info print of lh.white and lh.white.ico6). Is there a way to fix this? Another question: is there a reason why mris_decimate is not included in the freesurfer-Darwin-snowleopard-i686-stable-pub-v5.3.0 build Any help is very much appreciated. Best, Franz mris_info $s/surf/lh.white > SURFACE INFO > type: MRIS_TRIANGULAR_SURFACE=MRIS_ICO_SURFACE > num vertices: 118611 > num faces : 237218 > num strips : 0 > surface area: 77595.6 > AvgVtxArea 0.654202 > AvgVtxDist 0.885026 > StdVtxDist 0.251941 > ctr : (-33.3535, -11.9536, 42.7693) > vertex locs : surfaceRAS > talairch.xfm: > 1.045 -0.093 -0.014 1.081; > 0.099 1.095 0.070 -4.263; > 0.010 -0.083 1.290 -41.092; > 0.000 0.000 0.000 1.000; > surfaceRAS to talaraiched surfaceRAS: > 1.045 -0.093 -0.014 1.177; > 0.099 1.095 0.070 13.377; > 0.010 -0.083 1.290 -49.756; > 0.000 0.000 0.000 1.000; > talairached surfaceRAS to surfaceRAS: > 0.949 0.081 0.006 -1.900; > -0.085 0.902 -0.050 -14.449; > -0.013 0.058 0.772 37.650; > 0.000 0.000 0.000 1.000; > volume geometry: > extent : (256, 256, 256) > voxel : ( 1., 1., 1.) > x_(ras) : (-1., -0., 0.) > y_(ras) : (-0., 0., -1.) > z_(ras) : ( 0., 1., -0.) > c_(ras) : ( 0.0989, 0.9660, 0.9027) > ... mris_info lh.white.ico6 > SURFACE INFO > type: MRIS_TRIANGULAR_SURFACE=MRIS_ICO_SURFACE > num vertices: 40962 > num faces : 81920 > num strips : 0 > surface area: 75477.4 > AvgVtxArea 1.842620 > AvgVtxDist 1.573724 > StdVtxDist 0.523314 > ctr : (-33.3983, -12.0872, 42.7743) > vertex locs : surfaceRAS > volume geometry info is either not contained or not valid. > ... <>___ 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.
Re: [Freesurfer] mri_surf2surf to fsaverageX introduces offset
Dear Freesurfers, sorry for the bump, but my message seems to have gone unnoticed. Thanks so much for any ideas. Franz Am 22.08.2013 um 13:37 schrieb Franz Liem: > Dear Freesurfers, > > I tried to map a single subject surface to fsaverageX (for the sake of > demonstration lets take fsaverage6). I did the following: > mri_surf2surf --hemi lh --srcsubject $s --sval-xyz white --trgsubject > fsaverage6 --tval-xyz --tval ./lh.white.ico6 > This produces a surface that seems systematically shifted (see figure). Also > the newly generated surface does not contain valid geomery information (see > mris_info print of lh.white and lh.white.ico6). Is there a way to fix this? > > Another question: is there a reason why mris_decimate is not included in the > freesurfer-Darwin-snowleopard-i686-stable-pub-v5.3.0 build > > Any help is very much appreciated. > Best, Franz > > > mris_info $s/surf/lh.white >> SURFACE INFO >> type: MRIS_TRIANGULAR_SURFACE=MRIS_ICO_SURFACE >> num vertices: 118611 >> num faces : 237218 >> num strips : 0 >> surface area: 77595.6 >> AvgVtxArea 0.654202 >> AvgVtxDist 0.885026 >> StdVtxDist 0.251941 >> ctr : (-33.3535, -11.9536, 42.7693) >> vertex locs : surfaceRAS >> talairch.xfm: >> 1.045 -0.093 -0.014 1.081; >> 0.099 1.095 0.070 -4.263; >> 0.010 -0.083 1.290 -41.092; >> 0.000 0.000 0.000 1.000; >> surfaceRAS to talaraiched surfaceRAS: >> 1.045 -0.093 -0.014 1.177; >> 0.099 1.095 0.070 13.377; >> 0.010 -0.083 1.290 -49.756; >> 0.000 0.000 0.000 1.000; >> talairached surfaceRAS to surfaceRAS: >> 0.949 0.081 0.006 -1.900; >> -0.085 0.902 -0.050 -14.449; >> -0.013 0.058 0.772 37.650; >> 0.000 0.000 0.000 1.000; >> volume geometry: >> extent : (256, 256, 256) >> voxel : ( 1., 1., 1.) >> x_(ras) : (-1., -0., 0.) >> y_(ras) : (-0., 0., -1.) >> z_(ras) : ( 0., 1., -0.) >> c_(ras) : ( 0.0989, 0.9660, 0.9027) >> ... > > > > mris_info lh.white.ico6 >> SURFACE INFO >> type: MRIS_TRIANGULAR_SURFACE=MRIS_ICO_SURFACE >> num vertices: 40962 >> num faces : 81920 >> num strips : 0 >> surface area: 75477.4 >> AvgVtxArea 1.842620 >> AvgVtxDist 1.573724 >> StdVtxDist 0.523314 >> ctr : (-33.3983, -12.0872, 42.7743) >> vertex locs : surfaceRAS >> volume geometry info is either not contained or not valid. >> ... > > ___ > 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 mailing list Freesurfer@nmr.mgh.harvard.edu https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
Re: [Freesurfer] mri_surf2surf to fsaverageX introduces offset
Hi Doug, thanks a lot. I am using Darwin-snowleopard and centos6_x86_64. What I am trying to do is to use the white surface as seed for probtrackx. Therefore, I would like to reduce the number of vertices and at the same time bring the surfaces into a common space (so that vertex x is meaning the same thing in all subjects, while respecting the individual coordinates). I think my command did this but did not take the c_ras offset into account. Is there a better way to do this. Thank you very much, Franz Am 29.08.2013 um 20:54 schrieb Douglas N Greve: > > Hi Franz, I just programmed a fix into mri_surf2surf. What platform do > you use? > > As for the shift, you would not expect them to line up. In fact, that > command line does not make a lot of sense. What it is doing is mapping > the xyz coordinates in the native space to a new tesselation. The xyz > coorindates don't change at all. It is surprising that they are as close > as they are. What are you trying to do? > > doug > > > On 08/29/2013 07:41 AM, Franz Liem wrote: >> Dear Freesurfers, >> >> sorry for the bump, but my message seems to have gone unnoticed. >> Thanks so much for any ideas. >> Franz >> >> Am 22.08.2013 um 13:37 schrieb Franz Liem: >> >>> Dear Freesurfers, >>> >>> I tried to map a single subject surface to fsaverageX (for the sake of >>> demonstration lets take fsaverage6). I did the following: >>> mri_surf2surf --hemi lh --srcsubject $s --sval-xyz white --trgsubject >>> fsaverage6 --tval-xyz --tval ./lh.white.ico6 >>> This produces a surface that seems systematically shifted (see figure). >>> Also the newly generated surface does not contain valid geomery information >>> (see mris_info print of lh.white and lh.white.ico6). Is there a way to fix >>> this? >>> >>> Another question: is there a reason why mris_decimate is not included in >>> the freesurfer-Darwin-snowleopard-i686-stable-pub-v5.3.0 build >>> >>> Any help is very much appreciated. >>> Best, Franz >>> >>> >>> mris_info $s/surf/lh.white >>>> SURFACE INFO >>>> type: MRIS_TRIANGULAR_SURFACE=MRIS_ICO_SURFACE >>>> num vertices: 118611 >>>> num faces : 237218 >>>> num strips : 0 >>>> surface area: 77595.6 >>>> AvgVtxArea 0.654202 >>>> AvgVtxDist 0.885026 >>>> StdVtxDist 0.251941 >>>> ctr : (-33.3535, -11.9536, 42.7693) >>>> vertex locs : surfaceRAS >>>> talairch.xfm: >>>> 1.045 -0.093 -0.014 1.081; >>>> 0.099 1.095 0.070 -4.263; >>>> 0.010 -0.083 1.290 -41.092; >>>> 0.000 0.000 0.000 1.000; >>>> surfaceRAS to talaraiched surfaceRAS: >>>> 1.045 -0.093 -0.014 1.177; >>>> 0.099 1.095 0.070 13.377; >>>> 0.010 -0.083 1.290 -49.756; >>>> 0.000 0.000 0.000 1.000; >>>> talairached surfaceRAS to surfaceRAS: >>>> 0.949 0.081 0.006 -1.900; >>>> -0.085 0.902 -0.050 -14.449; >>>> -0.013 0.058 0.772 37.650; >>>> 0.000 0.000 0.000 1.000; >>>> volume geometry: >>>> extent : (256, 256, 256) >>>> voxel : ( 1., 1., 1.) >>>> x_(ras) : (-1., -0., 0.) >>>> y_(ras) : (-0., 0., -1.) >>>> z_(ras) : ( 0., 1., -0.) >>>> c_(ras) : ( 0.0989, 0.9660, 0.9027) >>>> ... >>> >>> >>> mris_info lh.white.ico6 >>>> SURFACE INFO >>>> type: MRIS_TRIANGULAR_SURFACE=MRIS_ICO_SURFACE >>>> num vertices: 40962 >>>> num faces : 81920 >>>> num strips : 0 >>>> surface area: 75477.4 >>>> AvgVtxArea 1.842620 >>>> AvgVtxDist 1.573724 >>>> StdVtxDist 0.523314 >>>> ctr : (-33.3983, -12.0872, 42.7743) >>>> vertex locs : surfaceRAS >>>> volume geometry info is either not contained or not valid. >>>> ... >>> ___ >>> 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 >>> addresse
Re: [Freesurfer] mri_surf2surf to fsaverageX introduces offset
Hi again, just a clarification. The two surfaces in the image are single subject surfaces (the original lh.white and the transformed lh.white.ico6), not fsaverage6 surfs. Best, Franz Am 30.08.2013 um 09:51 schrieb Franz Liem: > Hi Doug, > > thanks a lot. > I am using Darwin-snowleopard and centos6_x86_64. > > What I am trying to do is to use the white surface as seed for probtrackx. > Therefore, I would like to reduce the number of vertices and at the same time > bring the surfaces into a common space (so that vertex x is meaning the same > thing in all subjects, while respecting the individual coordinates). I think > my command did this but did not take the c_ras offset into account. > Is there a better way to do this. > > Thank you very much, > Franz > > Am 29.08.2013 um 20:54 schrieb Douglas N Greve: > >> >> Hi Franz, I just programmed a fix into mri_surf2surf. What platform do >> you use? >> >> As for the shift, you would not expect them to line up. In fact, that >> command line does not make a lot of sense. What it is doing is mapping >> the xyz coordinates in the native space to a new tesselation. The xyz >> coorindates don't change at all. It is surprising that they are as close >> as they are. What are you trying to do? >> >> doug >> >> >> On 08/29/2013 07:41 AM, Franz Liem wrote: >>> Dear Freesurfers, >>> >>> sorry for the bump, but my message seems to have gone unnoticed. >>> Thanks so much for any ideas. >>> Franz >>> >>> Am 22.08.2013 um 13:37 schrieb Franz Liem: >>> >>>> Dear Freesurfers, >>>> >>>> I tried to map a single subject surface to fsaverageX (for the sake of >>>> demonstration lets take fsaverage6). I did the following: >>>> mri_surf2surf --hemi lh --srcsubject $s --sval-xyz white --trgsubject >>>> fsaverage6 --tval-xyz --tval ./lh.white.ico6 >>>> This produces a surface that seems systematically shifted (see figure). >>>> Also the newly generated surface does not contain valid geomery >>>> information (see mris_info print of lh.white and lh.white.ico6). Is there >>>> a way to fix this? >>>> >>>> Another question: is there a reason why mris_decimate is not included in >>>> the freesurfer-Darwin-snowleopard-i686-stable-pub-v5.3.0 build >>>> >>>> Any help is very much appreciated. >>>> Best, Franz >>>> >>>> >>>> mris_info $s/surf/lh.white >>>>> SURFACE INFO >>>>> type: MRIS_TRIANGULAR_SURFACE=MRIS_ICO_SURFACE >>>>> num vertices: 118611 >>>>> num faces : 237218 >>>>> num strips : 0 >>>>> surface area: 77595.6 >>>>> AvgVtxArea 0.654202 >>>>> AvgVtxDist 0.885026 >>>>> StdVtxDist 0.251941 >>>>> ctr : (-33.3535, -11.9536, 42.7693) >>>>> vertex locs : surfaceRAS >>>>> talairch.xfm: >>>>> 1.045 -0.093 -0.014 1.081; >>>>> 0.099 1.095 0.070 -4.263; >>>>> 0.010 -0.083 1.290 -41.092; >>>>> 0.000 0.000 0.000 1.000; >>>>> surfaceRAS to talaraiched surfaceRAS: >>>>> 1.045 -0.093 -0.014 1.177; >>>>> 0.099 1.095 0.070 13.377; >>>>> 0.010 -0.083 1.290 -49.756; >>>>> 0.000 0.000 0.000 1.000; >>>>> talairached surfaceRAS to surfaceRAS: >>>>> 0.949 0.081 0.006 -1.900; >>>>> -0.085 0.902 -0.050 -14.449; >>>>> -0.013 0.058 0.772 37.650; >>>>> 0.000 0.000 0.000 1.000; >>>>> volume geometry: >>>>> extent : (256, 256, 256) >>>>> voxel : ( 1., 1., 1.) >>>>> x_(ras) : (-1., -0., 0.) >>>>> y_(ras) : (-0., 0., -1.) >>>>> z_(ras) : ( 0., 1., -0.) >>>>> c_(ras) : ( 0.0989, 0.9660, 0.9027) >>>>> ... >>>> >>>> >>>> mris_info lh.white.ico6 >>>>> SURFACE INFO >>>>> type: MRIS_TRIANGULAR_SURFACE=MRIS_ICO_SURFACE >>>>> num vertices: 40962 >>>>> num faces : 81920 >>>>> num strips : 0 >>>>> surface area: 75477.4 >>>>> AvgVtxArea 1.842620 >>>>> Av
Re: [Freesurfer] mri_surf2surf to fsaverageX introduces offset
Dear Doug, thank you so much, the fix works great. The problem now is that when I mris_convert the newly generated surface to .gii the volume geometry is lost again and the offset reintroduced. Is there a way to fix this? I have tried to give mri_surf2surf a register.dat that would correct for the c_ras offset, but that did not work. Thanks, Franz Am 30.08.2013 um 17:41 schrieb Douglas N Greve: > > Sorry, I'm answering your emails in reverse order. Your command should > do what youwant once you use the new version below > > ftp://surfer.nmr.mgh.harvard.edu/transfer/outgoing/flat/greve/mri_surf2surf.snowleopard > > note the --tval-xyz requires an argument (give it the orig.mgz) > > doug > > > On 08/30/2013 03:51 AM, Franz Liem wrote: >> Hi Doug, >> >> thanks a lot. >> I am using Darwin-snowleopard and centos6_x86_64. >> >> What I am trying to do is to use the white surface as seed for probtrackx. >> Therefore, I would like to reduce the number of vertices and at the same >> time bring the surfaces into a common space (so that vertex x is meaning the >> same thing in all subjects, while respecting the individual coordinates). I >> think my command did this but did not take the c_ras offset into account. >> Is there a better way to do this. >> >> Thank you very much, >> Franz >> >> Am 29.08.2013 um 20:54 schrieb Douglas N Greve: >> >>> Hi Franz, I just programmed a fix into mri_surf2surf. What platform do >>> you use? >>> >>> As for the shift, you would not expect them to line up. In fact, that >>> command line does not make a lot of sense. What it is doing is mapping >>> the xyz coordinates in the native space to a new tesselation. The xyz >>> coorindates don't change at all. It is surprising that they are as close >>> as they are. What are you trying to do? >>> >>> doug >>> >>> >>> On 08/29/2013 07:41 AM, Franz Liem wrote: >>>> Dear Freesurfers, >>>> >>>> sorry for the bump, but my message seems to have gone unnoticed. >>>> Thanks so much for any ideas. >>>> Franz >>>> >>>> Am 22.08.2013 um 13:37 schrieb Franz Liem: >>>> >>>>> Dear Freesurfers, >>>>> >>>>> I tried to map a single subject surface to fsaverageX (for the sake of >>>>> demonstration lets take fsaverage6). I did the following: >>>>> mri_surf2surf --hemi lh --srcsubject $s --sval-xyz white --trgsubject >>>>> fsaverage6 --tval-xyz --tval ./lh.white.ico6 >>>>> This produces a surface that seems systematically shifted (see figure). >>>>> Also the newly generated surface does not contain valid geomery >>>>> information (see mris_info print of lh.white and lh.white.ico6). Is there >>>>> a way to fix this? >>>>> >>>>> Another question: is there a reason why mris_decimate is not included in >>>>> the freesurfer-Darwin-snowleopard-i686-stable-pub-v5.3.0 build >>>>> >>>>> Any help is very much appreciated. >>>>> Best, Franz >>>>> >>>>> >>>>> mris_info $s/surf/lh.white >>>>>> SURFACE INFO >>>>>> type: MRIS_TRIANGULAR_SURFACE=MRIS_ICO_SURFACE >>>>>> num vertices: 118611 >>>>>> num faces : 237218 >>>>>> num strips : 0 >>>>>> surface area: 77595.6 >>>>>> AvgVtxArea 0.654202 >>>>>> AvgVtxDist 0.885026 >>>>>> StdVtxDist 0.251941 >>>>>> ctr : (-33.3535, -11.9536, 42.7693) >>>>>> vertex locs : surfaceRAS >>>>>> talairch.xfm: >>>>>> 1.045 -0.093 -0.014 1.081; >>>>>> 0.099 1.095 0.070 -4.263; >>>>>> 0.010 -0.083 1.290 -41.092; >>>>>> 0.000 0.000 0.000 1.000; >>>>>> surfaceRAS to talaraiched surfaceRAS: >>>>>> 1.045 -0.093 -0.014 1.177; >>>>>> 0.099 1.095 0.070 13.377; >>>>>> 0.010 -0.083 1.290 -49.756; >>>>>> 0.000 0.000 0.000 1.000; >>>>>> talairached surfaceRAS to surfaceRAS: >>>>>> 0.949 0.081 0.006 -1.900; >>>>>> -0.085 0.902 -0.050 -14.449; >>>>>> -0.013 0.058 0.772 37.650; >>>>>> 0.000 0.000
Re: [Freesurfer] mri_surf2surf to fsaverageX introduces offset
Hi Doug, this gives exactly the same surface as surf2surf followed by mris_convert (i.e. with offset). Thanks, Franz Am 02.09.2013 um 16:50 schrieb Douglas Greve: > > What if you specify the output of surf2surf to be a gii file? > > > On 9/2/13 6:47 AM, Franz Liem wrote: >> Dear Doug, >> >> thank you so much, the fix works great. >> The problem now is that when I mris_convert the newly generated surface to >> .gii the volume geometry is lost again and the offset reintroduced. >> Is there a way to fix this? I have tried to give mri_surf2surf a >> register.dat that would correct for the c_ras offset, but that did not work. >> >> Thanks, >> Franz >> >> Am 30.08.2013 um 17:41 schrieb Douglas N Greve: >> >>> Sorry, I'm answering your emails in reverse order. Your command should >>> do what youwant once you use the new version below >>> >>> ftp://surfer.nmr.mgh.harvard.edu/transfer/outgoing/flat/greve/mri_surf2surf.snowleopard >>> >>> note the --tval-xyz requires an argument (give it the orig.mgz) >>> >>> doug >>> >>> >>> On 08/30/2013 03:51 AM, Franz Liem wrote: >>>> Hi Doug, >>>> >>>> thanks a lot. >>>> I am using Darwin-snowleopard and centos6_x86_64. >>>> >>>> What I am trying to do is to use the white surface as seed for probtrackx. >>>> Therefore, I would like to reduce the number of vertices and at the same >>>> time bring the surfaces into a common space (so that vertex x is meaning >>>> the same thing in all subjects, while respecting the individual >>>> coordinates). I think my command did this but did not take the c_ras >>>> offset into account. >>>> Is there a better way to do this. >>>> >>>> Thank you very much, >>>> Franz >>>> >>>> Am 29.08.2013 um 20:54 schrieb Douglas N Greve: >>>> >>>>> Hi Franz, I just programmed a fix into mri_surf2surf. What platform do >>>>> you use? >>>>> >>>>> As for the shift, you would not expect them to line up. In fact, that >>>>> command line does not make a lot of sense. What it is doing is mapping >>>>> the xyz coordinates in the native space to a new tesselation. The xyz >>>>> coorindates don't change at all. It is surprising that they are as close >>>>> as they are. What are you trying to do? >>>>> >>>>> doug >>>>> >>>>> >>>>> On 08/29/2013 07:41 AM, Franz Liem wrote: >>>>>> Dear Freesurfers, >>>>>> >>>>>> sorry for the bump, but my message seems to have gone unnoticed. >>>>>> Thanks so much for any ideas. >>>>>> Franz >>>>>> >>>>>> Am 22.08.2013 um 13:37 schrieb Franz Liem: >>>>>> >>>>>>> Dear Freesurfers, >>>>>>> >>>>>>> I tried to map a single subject surface to fsaverageX (for the sake of >>>>>>> demonstration lets take fsaverage6). I did the following: >>>>>>> mri_surf2surf --hemi lh --srcsubject $s --sval-xyz white --trgsubject >>>>>>> fsaverage6 --tval-xyz --tval ./lh.white.ico6 >>>>>>> This produces a surface that seems systematically shifted (see figure). >>>>>>> Also the newly generated surface does not contain valid geomery >>>>>>> information (see mris_info print of lh.white and lh.white.ico6). Is >>>>>>> there a way to fix this? >>>>>>> >>>>>>> Another question: is there a reason why mris_decimate is not included >>>>>>> in the freesurfer-Darwin-snowleopard-i686-stable-pub-v5.3.0 build >>>>>>> >>>>>>> Any help is very much appreciated. >>>>>>> Best, Franz >>>>>>> >>>>>>> >>>>>>> mris_info $s/surf/lh.white >>>>>>>> SURFACE INFO >>>>>>>> type: MRIS_TRIANGULAR_SURFACE=MRIS_ICO_SURFACE >>>>>>>> num vertices: 118611 >>>>>>>> num faces : 237218 >>>>>>>> num strips : 0 >>>>>>>> surface area: 77595.6 >>>>>>>> AvgVtxArea 0.654202 >>>>&g
Re: [Freesurfer] mri_surf2surf to fsaverageX introduces offset
Hi Doug,
I found a workaround. I used matlab code from from gradient_nonlin_unwarp to
remove the c_ras offset from the vertex coordinates and set c_ras to 0. Then I
mris_convert the new surface to .gii. This gives me perfectly aligned surfaces.
Thanks for your help,
Franz
> [surf_struct, tags, M_surf2ras]=mris_read_surface( 'lh.white.ico5');
>
> M_surf2ras = eye(4);
> surf_struct.M_surf2ras = eye(4);
> surf_struct.vertices_trk= surf_struct.vertices ;
> surf_struct.tags(strfind(surf_struct.tags,'cras'):end) = '';
> surf_struct.tags = [surf_struct.tags, sprintf('cras = %2.15e %2.15e
> %2.15e', [0 0 0])];
>
> mris_save_surface('lh.white.ico5.noOffset', surf_struct, M_surf2ras);
Am 02.09.2013 um 21:43 schrieb Douglas Greve:
>
> This info is probably not stored in the gii header. I'll have to take a
> look which could take a while. Depending on what you are doing, it might
> not be important.
> doug
>
>
> On 9/2/13 2:58 PM, Franz Liem wrote:
>> Hi Doug,
>> this gives exactly the same surface as surf2surf followed by mris_convert
>> (i.e. with offset).
>>
>> Thanks,
>> Franz
>>
>> Am 02.09.2013 um 16:50 schrieb Douglas Greve:
>>
>>> What if you specify the output of surf2surf to be a gii file?
>>>
>>>
>>> On 9/2/13 6:47 AM, Franz Liem wrote:
>>>> Dear Doug,
>>>>
>>>> thank you so much, the fix works great.
>>>> The problem now is that when I mris_convert the newly generated surface to
>>>> .gii the volume geometry is lost again and the offset reintroduced.
>>>> Is there a way to fix this? I have tried to give mri_surf2surf a
>>>> register.dat that would correct for the c_ras offset, but that did not
>>>> work.
>>>>
>>>> Thanks,
>>>> Franz
>>>>
>>>> Am 30.08.2013 um 17:41 schrieb Douglas N Greve:
>>>>
>>>>> Sorry, I'm answering your emails in reverse order. Your command should
>>>>> do what youwant once you use the new version below
>>>>>
>>>>> ftp://surfer.nmr.mgh.harvard.edu/transfer/outgoing/flat/greve/mri_surf2surf.snowleopard
>>>>>
>>>>> note the --tval-xyz requires an argument (give it the orig.mgz)
>>>>>
>>>>> doug
>>>>>
>>>>>
>>>>> On 08/30/2013 03:51 AM, Franz Liem wrote:
>>>>>> Hi Doug,
>>>>>>
>>>>>> thanks a lot.
>>>>>> I am using Darwin-snowleopard and centos6_x86_64.
>>>>>>
>>>>>> What I am trying to do is to use the white surface as seed for
>>>>>> probtrackx. Therefore, I would like to reduce the number of vertices and
>>>>>> at the same time bring the surfaces into a common space (so that vertex
>>>>>> x is meaning the same thing in all subjects, while respecting the
>>>>>> individual coordinates). I think my command did this but did not take
>>>>>> the c_ras offset into account.
>>>>>> Is there a better way to do this.
>>>>>>
>>>>>> Thank you very much,
>>>>>> Franz
>>>>>>
>>>>>> Am 29.08.2013 um 20:54 schrieb Douglas N Greve:
>>>>>>
>>>>>>> Hi Franz, I just programmed a fix into mri_surf2surf. What platform do
>>>>>>> you use?
>>>>>>>
>>>>>>> As for the shift, you would not expect them to line up. In fact, that
>>>>>>> command line does not make a lot of sense. What it is doing is mapping
>>>>>>> the xyz coordinates in the native space to a new tesselation. The xyz
>>>>>>> coorindates don't change at all. It is surprising that they are as close
>>>>>>> as they are. What are you trying to do?
>>>>>>>
>>>>>>> doug
>>>>>>>
>>>>>>>
>>>>>>> On 08/29/2013 07:41 AM, Franz Liem wrote:
>>>>>>>> Dear Freesurfers,
>>>>>>>>
>>>>>>>> sorry for the bump, but my message seems to have gone unnoticed.
>>>>>>>> Thanks so much for any ideas.
>>>>>>>> Franz
>>>>>>>>
>>>>>>>> Am 22.08.2013 um 13:37 schrieb Franz Liem:
>>>>>>>>
>>>&g
[Freesurfer] downsampling surface in native space
Dear FS experts, I would like to downsample a subject's white surface to arrive with a smaller number of vertices in order to feed the surface into FSL's surface tracking. I tried to map the fsaverage6 onto the single subject: mri_surf2surf --hemi lh --srcsubject fsaverage6 --sval-xyz white --trgsubject s01 --trgsurfval white.ico6 --tval-xyz --trgicoorder 6 If I load it into tksurfer, the surface now looks (as expected) much coarser. However, the number of vertices is still ~ 130k. Furthermore, it would be great if vertex x would spatially correspond in all subjects. Any advice is much appreciated, Cheers, Franz ___ 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.
Re: [Freesurfer] downsampling surface in native space
Hi Doug, thanks for the answer. This works great. Franz Am 18.10.2012 um 17:37 schrieb Douglas N Greve: > Hi Franz, try mapping the xyz coordinates of the individual into > fsaverage6 (or fsaverage5 or lower) space. This should solve both of > your problems (I think). > doug > > > On 10/18/2012 07:53 AM, Franz Liem wrote: >> Dear FS experts, >> >> I would like to downsample a subject's white surface to arrive with a >> smaller number of vertices in order to feed the surface into FSL's surface >> tracking. >> >> I tried to map the fsaverage6 onto the single subject: >> mri_surf2surf --hemi lh --srcsubject fsaverage6 --sval-xyz white >> --trgsubject s01 --trgsurfval white.ico6 --tval-xyz --trgicoorder 6 >> >> If I load it into tksurfer, the surface now looks (as expected) much >> coarser. However, the number of vertices is still ~ 130k. >> >> >> Furthermore, it would be great if vertex x would spatially correspond in all >> subjects. >> >> Any advice is much appreciated, >> Cheers, Franz >> ___ >> Freesurfer mailing list >> Freesurfer@nmr.mgh.harvard.edu >> https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer >> >> > > -- > Douglas N. Greve, Ph.D. > MGH-NMR Center > gr...@nmr.mgh.harvard.edu > Phone Number: 617-724-2358 > Fax: 617-726-7422 > > Bugs: surfer.nmr.mgh.harvard.edu/fswiki/BugReporting > FileDrop: www.nmr.mgh.harvard.edu/facility/filedrop/index.html > > ___ > 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 mailing list Freesurfer@nmr.mgh.harvard.edu https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
[Freesurfer] make_face_parcellation ambiguous color table
Dear Freesurfers, I have performed make_face_parcellation on fsaverage (with ic5) (Darwin-leopard-i686-stable-pub-v5.1.0). I read_annotation ed the parcellation into matlab an noticed that while colortable.table has 10242 rows (as expected), length(unique(colortable.table(:,5))) produces 9834 => some entries are in the list more than once. If I grasped the procedure correctly, the entries in label are determined by colortable.table(:,5) and colortable.table(:,5) is determined by: % Column 5 is the structure ID, calculated from % R + G*2^8 + B*2^16 + flag*2^24 One example for this problem is colortable.table(43,:) and colortable.table(86,:) both read: 0 0 170 011141120 How are Rm G, B determined? I guess one quick fix would be to introduce flags >0. Would that affect anything else? Or, is there a way to force my own indices onto colortable.table(:,5)? (if I change this entry, save the annot and load the annot, the entry is at R + G*2^8 + B*2^16 + flag*2^24 again (I already encountered the effects of this problem a couple of months ago (2. in this post http://www.mail-archive.com/freesurfer@nmr.mgh.harvard.edu/msg21189.html).) Thank you so much for your help, Franz___ 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.
Re: [Freesurfer] make_face_parcellation ambiguous color table
Dear Doug, thanks for the quick response. Sorry that I missed the post. I downloaded the mac intel leopard dev from the nightly built and ran make_face_parcellation. Running it with ic5 produced 10236 unique values (instead of 10242), running it with ic3 641 (instead of 642) Is it possible that this is not the latest version? The BuildTimeStamp is: Jun 24 2012 06:10:12, you uploaded the ftp://surfer.nmr.mgh.harvard.edu/transfer/outgoing/flat/greve/mris_make_face_parcellation.linux version on 16.07.12. ProgramName: mris_make_face_parcellation ProgramArguments: --all-info ProgramVersion: $Name: $ TimeStamp: 2012/10/26-11:34:24-GMT BuildTimeStamp: Jun 24 2012 06:10:12 CVS: $Id: mris_make_face_parcellation.c,v 1.18 2012/06/07 17:52:09 greve Exp $ ... Platform: Darwin PlatformVersion: 10.8.0 CompilerName: GCC CompilerVersion: 4 Thanks for your help, Franz Am 25.10.2012 um 18:29 schrieb Douglas N Greve: > Hi Franz, this was noted and addressed a few weeks ago. You can download > a new version here: > ftp://surfer.nmr.mgh.harvard.edu/transfer/outgoing/flat/greve/mris_make_face_parcellation.linux > doug > > On 10/25/2012 10:33 AM, Franz Liem wrote: >> Dear Freesurfers, >> >> I have performed make_face_parcellation on fsaverage (with ic5) >> (Darwin-leopard-i686-stable-pub-v5.1.0). I read_annotation ed the >> parcellation into matlab an noticed that while colortable.table has >> 10242 rows (as expected), length(unique(colortable.table(:,5))) >> produces 9834 => some entries are in the list more than once. If I >> grasped the procedure correctly, the entries in label are determined >> by colortable.table(:,5) and colortable.table(:,5) is determined by: >> % Column 5 is the structure ID, calculated from >> % R + G*2^8 + B*2^16 + flag*2^24 >> >> One example for this problem is colortable.table(43,:) >> and colortable.table(86,:) both read: >> 0 0 170 011141120 >> >> How are Rm G, B determined? >> I guess one quick fix would be to introduce flags >0. Would that >> affect anything else? Or, is there a way to force my own indices >> onto colortable.table(:,5)? (if I change this entry, save the annot >> and load the annot, the entry is atR + G*2^8 + B*2^16 + flag*2^24again >> >> (I already encountered the effects of this problem a couple of months >> ago (2. in this post >> http://www.mail-archive.com/freesurfer@nmr.mgh.harvard.edu/msg21189.html).) >> >> Thank you so much for your help, >> Franz >> >> >> ___ >> Freesurfer mailing list >> Freesurfer@nmr.mgh.harvard.edu >> https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer > > -- > Douglas N. Greve, Ph.D. > MGH-NMR Center > gr...@nmr.mgh.harvard.edu > Phone Number: 617-724-2358 > Fax: 617-726-7422 > > Bugs: surfer.nmr.mgh.harvard.edu/fswiki/BugReporting > FileDrop: www.nmr.mgh.harvard.edu/facility/filedrop/index.html > > ___ > 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 mailing list Freesurfer@nmr.mgh.harvard.edu https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
Re: [Freesurfer] make_face_parcellation ambiguous color table
Hi Doug, works great. Thanks a lot. Franz Am 26.10.2012 um 22:13 schrieb Douglas N Greve: > Try this one > ftp://surfer.nmr.mgh.harvard.edu/transfer/outgoing/flat/greve/mris_make_face_parcellation.mac > > doug > > On 10/26/2012 07:38 AM, Franz Liem wrote: >> Dear Doug, >> thanks for the quick response. Sorry that I missed the post. >> I downloaded the mac intel leopard dev from the nightly built and ran >> make_face_parcellation. >> Running it with ic5 produced 10236 unique values (instead of 10242), running >> it with ic3 641 (instead of 642) >> >> Is it possible that this is not the latest version? The BuildTimeStamp is: >> Jun 24 2012 06:10:12, you uploaded the >> ftp://surfer.nmr.mgh.harvard.edu/transfer/outgoing/flat/greve/mris_make_face_parcellation.linux >> version on 16.07.12. >> >> ProgramName: mris_make_face_parcellation ProgramArguments: >> --all-info ProgramVersion: $Name: $ TimeStamp: 2012/10/26-11:34:24-GMT >> BuildTimeStamp: Jun 24 2012 06:10:12 CVS: $Id: >> mris_make_face_parcellation.c,v 1.18 2012/06/07 17:52:09 greve Exp $ ... >> Platform: Darwin PlatformVersion: 10.8.0 CompilerName: GCC >> CompilerVersion: 4 >> >> >> Thanks for your help, >> Franz >> >> >> Am 25.10.2012 um 18:29 schrieb Douglas N Greve: >> >>> Hi Franz, this was noted and addressed a few weeks ago. You can download >>> a new version here: >>> ftp://surfer.nmr.mgh.harvard.edu/transfer/outgoing/flat/greve/mris_make_face_parcellation.linux >>> doug >>> >>> On 10/25/2012 10:33 AM, Franz Liem wrote: >>>> Dear Freesurfers, >>>> >>>> I have performed make_face_parcellation on fsaverage (with ic5) >>>> (Darwin-leopard-i686-stable-pub-v5.1.0). I read_annotation ed the >>>> parcellation into matlab an noticed that while colortable.table has >>>> 10242 rows (as expected), length(unique(colortable.table(:,5))) >>>> produces 9834 => some entries are in the list more than once. If I >>>> grasped the procedure correctly, the entries in label are determined >>>> by colortable.table(:,5) and colortable.table(:,5) is determined by: >>>> % Column 5 is the structure ID, calculated from >>>> % R + G*2^8 + B*2^16 + flag*2^24 >>>> >>>> One example for this problem is colortable.table(43,:) >>>> and colortable.table(86,:) both read: >>>> 0 0 170 011141120 >>>> >>>> How are Rm G, B determined? >>>> I guess one quick fix would be to introduce flags>0. Would that >>>> affect anything else? Or, is there a way to force my own indices >>>> onto colortable.table(:,5)? (if I change this entry, save the annot >>>> and load the annot, the entry is atR + G*2^8 + B*2^16 + flag*2^24again >>>> >>>> (I already encountered the effects of this problem a couple of months >>>> ago (2. in this post >>>> http://www.mail-archive.com/freesurfer@nmr.mgh.harvard.edu/msg21189.html).) >>>> >>>> Thank you so much for your help, >>>> Franz >>>> >>>> >>>> ___ >>>> Freesurfer mailing list >>>> Freesurfer@nmr.mgh.harvard.edu >>>> https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer >>> -- >>> Douglas N. Greve, Ph.D. >>> MGH-NMR Center >>> gr...@nmr.mgh.harvard.edu >>> Phone Number: 617-724-2358 >>> Fax: 617-726-7422 >>> >>> Bugs: surfer.nmr.mgh.harvard.edu/fswiki/BugReporting >>> FileDrop: www.nmr.mgh.harvard.edu/facility/filedrop/index.html >>> >>> ___ >>> 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. >>> >> >> > > -- > Douglas N. Greve, Ph.D. > MGH-NMR Center > gr...@nmr.mgh.harvard.edu > Phone Number: 617-724-2358 > Fax: 617-726-7422 > > Bugs: surfer.nmr.mgh.harvard.edu/fswiki/BugReporting > FileDrop: www.nmr.mgh.harvard.edu/facility/filedrop/index.html > ___ Freesurfer mailing list Freesurfer@nmr.mgh.harvard.edu https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
Re: [Freesurfer] mris_convert to GIFTI misaligned in freeview
Hi Michael, I had a similar problem a while ago. Maybe this might help. http://www.mail-archive.com/freesurfer%40nmr.mgh.harvard.edu/msg31152.html Best, Franz Am 23.05.2014 um 05:38 schrieb Harms, Michael: > > Hi, > I converted a surface to GIFTI > e.g., > mris_convert lh.white lh.white.gii > > lh.white and lh.white.gii align when they are both loaded in 'tkmedit'. > However, they do not align when loaded simultaneously in 'freeview'. > > Of possible relevance: When I loaded lh.white.gii into 'freeview', I got the > following message in the terminal: > "Did not find any volume geometry information in the surface" > > Is this possibly a bug of some sort in the display of GIFTI surfaces within > 'freeview'? > > This was all done with FS 5.3. > > thanks, > -MH > > -- > Michael Harms, Ph.D. > --- > Conte Center for the Neuroscience of Mental Disorders > Washington University School of Medicine > Department of Psychiatry, Box 8134 > 660 South Euclid Ave. Tel: 314-747-6173 > St. Louis, MO 63110 Email: mha...@wustl.edu > > > > The materials in this message are private and may contain Protected > Healthcare Information or other information of a sensitive nature. If you are > not the intended recipient, be advised that any unauthorized use, disclosure, > copying or the taking of any action in reliance on the contents of this > information is strictly prohibited. If you have received this email in error, > please immediately notify the sender via telephone or return mail. > > ___ > 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 mailing list Freesurfer@nmr.mgh.harvard.edu https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
[Freesurfer] mris_make_face_parcellation
Dear Freesurfers, I have some questions regarding mris_make_face_parcellation (and possibly found one error in the .tri file). (I am working with freesurfer-Darwin-leopard-i686-stable-pub-v5.1.0). I would like to make a high res parcellation of several subjects and used ic3.tri. Parcels should correspond across subjects. I computed mris_make_face_parcellation ../surf/lh.sphere $FREESURFER_HOME/lib/bem/ic3.tri ./lh.ic3.annot 1. It seems not to make a difference whether I choose .sphere or .sphere.reg as input, the resulting parcellations are identical (i checked by comparing vertex label values in matlab; .inflated deviates a bit, but not substantially). According to Bruce (http://www.mail-archive.com/freesurfer@nmr.mgh.harvard.edu/msg18509.html): "You want to use either ?h.sphere if you want it to be uniform in subject space or ?h.sphere.reg if you want the parcels to correspond across subjects" Could anybody tell me how the parcellation is performed exactly? I thought it was performed on the input surf (the input surf is parcellated into (e.g.) 642 equally sized parcels), which should lead to different results at .sphere and .sphere.reg, shouldn't it? Alternatively, would it be better to mris_make_face_parcellation the fsaverage and mri_surf2surf the high res parcellation onto each subject to get cross-subject correspondency (I tried this. It didn't look that great with this command: mri_surf2surf --srcsubject fsaverage --sval-annot ic3.annot --trgsubject subject1 --tval ic3s03.annot --hemi lh )? To recap, what is the best strategy to arrive with cross-subject-corresponing parcellations? Performing mris_make_face_parcellation with ?h.sphere.reg for each subject individually? 2. There seems to be duplicate structNames/annotationValues when applying mris_make_face_parcellation with ic3.tri In fsaverage at least the following labelnames are given to two spatially separated labels. ic3.tri_vertex_25 (cluster 1 around vertex 41132, cluster 2 around vertex 157199) ic3.tri_vertex_42 (cluster 1 around vertex 137845, cluster 2 around vertex 155417) How come? Thanks for you help, Franz ___ 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.
Re: [Freesurfer] mris_make_face_parcellation
Dear Bruce, thank you so much for your reply; it seems to work now. However, a weird thing, I also mentioned in my previous post, still happens: when using ic3 there are duplicate labels in the newly created annotations. > at least the following labelnames are given to two spatially separated > labels. > ic3.tri_vertex_25 (in fsaverage lh: cluster 1 around vertex 41132, cluster 2 > around vertex 157199) > ic3.tri_vertex_42 (in fsaverage lh: cluster 1 around vertex 137845, cluster 2 > around vertex 155417) Is there a way to avoid this? Thanks for your help, Franz Am 26.01.2012 um 14:47 schrieb Bruce Fischl: > Hi Franz > > looks like this was a bug in mris_make_face_parcellation, which I just > fixed. It was always using the sphere regardless of what you specified. > Krish: can you get Franz a new mac version of it to try out? > > sorry > Bruce > > > On Thu, 26 Jan 2012, Franz Liem wrote: > >> Dear Freesurfers, >> >> I have some questions regarding mris_make_face_parcellation (and possibly >> found one error in the .tri file). >> (I am working with freesurfer-Darwin-leopard-i686-stable-pub-v5.1.0). >> >> I would like to make a high res parcellation of several subjects and used >> ic3.tri. Parcels should correspond across subjects. >> I computed mris_make_face_parcellation ../surf/lh.sphere >> $FREESURFER_HOME/lib/bem/ic3.tri ./lh.ic3.annot >> >> 1. It seems not to make a difference whether I choose .sphere or >> .sphere.reg as input, the resulting parcellations are identical (i checked >> by comparing vertex label values in matlab; .inflated deviates a bit, but >> not substantially). >> According to Bruce >> (http://www.mail-archive.com/freesurfer@nmr.mgh.harvard.edu/msg18509.html): >> "You want to use either ?h.sphere if you want it to be uniform in subject >> space or ?h.sphere.reg if you want the parcels to correspond across subjects" >> >> Could anybody tell me how the parcellation is performed exactly? I thought >> it was performed on the input surf (the input surf is parcellated into >> (e.g.) 642 equally sized parcels), which should lead to different results at >> .sphere and .sphere.reg, shouldn't it? >> >> Alternatively, would it be better to mris_make_face_parcellation the >> fsaverage and mri_surf2surf the high res parcellation onto each subject to >> get cross-subject correspondency (I tried this. It didn't look that great >> with this command: mri_surf2surf --srcsubject fsaverage --sval-annot >> ic3.annot --trgsubject subject1 --tval ic3s03.annot --hemi lh )? >> >> To recap, what is the best strategy to arrive with >> cross-subject-corresponing parcellations? Performing >> mris_make_face_parcellation with ?h.sphere.reg for each subject individually? >> >> 2. There seems to be duplicate structNames/annotationValues when applying >> mris_make_face_parcellation with ic3.tri >> In fsaverage at least the following labelnames are given to two spatially >> separated labels. >> ic3.tri_vertex_25 (cluster 1 around vertex 41132, cluster 2 around vertex >> 157199) >> ic3.tri_vertex_42 (cluster 1 around vertex 137845, cluster 2 around vertex >> 155417) >> How come? >> >> >> Thanks for you help, >> Franz >> >> >> ___ >> Freesurfer mailing list >> Freesurfer@nmr.mgh.harvard.edu >> https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer >> >> >> > ___ > 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 mailing list Freesurfer@nmr.mgh.harvard.edu https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
[Freesurfer] tracula bvecs problem
Dear Freesurfers. I am trying to run trac-all on one subject and have a problem with the bvecs file at the -prep stage. After dtifit is started an error massage occurs: Error: bvecs and bvals don't have the same number of entries. I checked the dmri/bvals and dmri/bvecs. There seems to be a problem at the -corr stage (-corr alone finishes without error). My input file is one 4d .nii.gz file (with a total of 33 images, with the first being a b0 image). (I have attached the files from the dmri folder) The dmri/bvecs file only contains: 0,000 0,000 0,000 The original bvecs contains 3 columns and 33 lines. The dmri/bvals seems to be ok (1 column and 33 lines). eddy_correct processes 33 files (dmri/dwi_tmp ... dmri/dwi_tmp0032). I am running FSL(4.6.1) and Freesurfer v5.1.0 on Mac (10.6.4) (although the recon was done with 5.0.0, but I guess this not important at this stage, is it?) *** My Configuration File: set dtroot = $SUBJECTS_DIR/DTI set subjlist = (s02x) set dcmroot = $SUBJECTS_DIR/DTI set dcmlist = (s02x/dti4d.nii.gz) set bvalfile = /Users/.../DTI/bvals/bvals set bvecfile = /Users/.../DTI/bvals/bvecs set nb0 = 1 set doeddy = 1 set dorotbvecs = 1 set thrbet = 0.3 set doregflt = 1 set doregbbr = 0 *** Thanks, Franz bvals Description: Binary data bvecs Description: Binary data bvecs.norot Description: Binary data dwi_orig.mghdti.bvals Description: Binary data dwi_orig.mghdti.bvecs Description: Binary data ___ 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.
Re: [Freesurfer] tracula bvecs problem
Hello again.
I dug into the code and could locate the problem (I don't have a solution,
though. My coding skills are quite amateurish.) I think the problem somehow
lies in the format of my bvecs file.
flip4fsl is not able to read it correctly:
---
if (-e $inbvecs) then
echo "INFO: found $inbvecs, converting to FSL format"
if $fslflipx then
set sign = `echo $inorient | sed "s/[RAS]/+\ /g; s/[LPI]/-\ /g"`
endif
cp /dev/null $outbvecs
foreach j (1 2 3)
foreach k (1 2 3)
if ($order[$k] == $j) then
printf '%s ' `cat $inbvecs | awk -v sgn=$sign[$k]1 -v n=$k '{print
sgn*$n}'` \
>> $outbvecs
printf '\n' >> $outbvecs
endif
end
end
endif
---
I tried
awk '{ print $1 }' bvecs (with my original bvecs file)
this printed:
0
This has something to do with the file's carriage return. I then produced a new
bvecs file by manually typing values into a new text file. Now awk '{ print $1
}' bvecs delivers one column with 33 lines.
Nevertheless, the bvecs output of flip4fsl is weird (full of zeros; 3 x 66; see
attachment).
I don't really get how this printf & awk command works.
Any comments are very much appreciated.
Franz
bvecs
Description: Binary data
Am 05.07.2011 um 15:19 schrieb Franz Liem:
> Dear Freesurfers.
>
> I am trying to run trac-all on one subject and have a problem with the bvecs
> file at the -prep stage.
> After dtifit is started an error massage occurs: Error: bvecs and bvals don't
> have the same number of entries.
> I checked the dmri/bvals and dmri/bvecs. There seems to be a problem at the
> -corr stage (-corr alone finishes without error).
>
> My input file is one 4d .nii.gz file (with a total of 33 images, with the
> first being a b0 image).
>
> (I have attached the files from the dmri folder)
>
> The dmri/bvecs file only contains:
> 0,000
> 0,000
> 0,000
>
> The original bvecs contains 3 columns and 33 lines.
>
> The dmri/bvals seems to be ok (1 column and 33 lines).
>
> eddy_correct processes 33 files (dmri/dwi_tmp ... dmri/dwi_tmp0032).
>
> I am running FSL(4.6.1) and Freesurfer v5.1.0 on Mac (10.6.4) (although the
> recon was done with 5.0.0, but I guess this not important at this stage, is
> it?)
>
>
> ***
> My Configuration File:
>
> set dtroot = $SUBJECTS_DIR/DTI
> set subjlist = (s02x)
>
> set dcmroot = $SUBJECTS_DIR/DTI
> set dcmlist = (s02x/dti4d.nii.gz)
>
> set bvalfile = /Users/.../DTI/bvals/bvals
> set bvecfile = /Users/.../DTI/bvals/bvecs
> set nb0 = 1
>
> set doeddy = 1
> set dorotbvecs = 1
> set thrbet = 0.3
> set doregflt = 1
> set doregbbr = 0
> ***
>
>
> Thanks,
> Franz
>
> ___
> 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 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.
Re: [Freesurfer] tracula bvecs problem
Hi Priti and Anastasia.
Thank you very much for your replies.
Prit, I ran you modified_bvecs. This resulted in zeros (see bvecs_out). I also
tried the modified_bvecs in a tab-deliniated version. same result.
Anastasia, the original bvecs file is attached as bvecs_orig. I imported this
into excel and transposed it. Since (cp $bvecfile
$dwidir/dwi_orig.mghdti.bvecs) the dwi_orig.mghdti.bvecs from my first post
should be an exact copy of my original input.
1) I then took the bvecs file provided in the tutorial data (and deleted the
lines >33). This again resulted in zeros (see bvecs_tutorial_out).
2) I then created a file with only ones and zeros (see bvecs_onezero_western):
33 lines of
0 0 0
1 0 0
This resulted in correct bvecs after ecc (see bvecs_onezero_western_out).
3) I then appended .000 (see bvecs_onezero3dec_western)
0.000 0.000 0.000
1.000 0.000 0.000
...
this resulted in the exact same bvecs after ecc (with integers - see
bvecs_onezero3dec_western_out).
4) I then wrote 1.100 (instead of 1.000; see bvecs_onezero3decpoint1_western).
This again led to the same output (see
bvecs_bvecs_onezero3decpoint1_western_out).
So in conclusion, it seems as if the flip4fsl cannot read the digits after the
decimal point. Can you reproduce this error? Might this be a problem with my
german-language-settings computer (mac osx 10.6.4; although, since it is a
swiss-german machine the system wide setting for decimal separator is the dot )?
Thank you,
Franz
bvecs_out
Description: Binary data
bvecs_orig
Description: Binary data
bvecs_tutorial_out
Description: Binary data
bvecs_onezero_western
Description: Binary data
bvecs_onezero_western_out
Description: Binary data
bvecs_onezero3dec_western
Description: Binary data
bvecs_onezero3dec_western_out
Description: Binary data
bvecs_onezero3decpoint1_western
Description: Binary data
bvecs_bvecs_onezero3decpoint1_western_out
Description: Binary data
Am 05.07.2011 um 20:17 schrieb rspr...@nmr.mgh.harvard.edu:
> Hi Franz,
>
> Sorry I just saw your previous email now. The problem could be due to the
> variable decimal places you've used in your input bvecs file. I've
> modified your bvecs file from the previous email to 3 decimal places
> constantly for all the gradient values (See Attached!!). Can you check to
> see if this solves the problem?
>
> Thanks,
> Priti
>
>
>> Hello again.
>>
>> I dug into the code and could locate the problem (I don't have a solution,
>> though. My coding skills are quite amateurish.) I think the problem
>> somehow lies in the format of my bvecs file.
>>
>> flip4fsl is not able to read it correctly:
>> ---
>> if (-e $inbvecs) then
>> echo "INFO: found $inbvecs, converting to FSL format"
>> if $fslflipx then
>>set sign = `echo $inorient | sed "s/[RAS]/+\ /g; s/[LPI]/-\ /g"`
>> endif
>> cp /dev/null $outbvecs
>> foreach j (1 2 3)
>>foreach k (1 2 3)
>> if ($order[$k] == $j) then
>>printf '%s ' `cat $inbvecs | awk -v sgn=$sign[$k]1 -v n=$k '{print
>> sgn*$n}'` \
>>>> $outbvecs
>>printf '\n' >> $outbvecs
>> endif
>>end
>> end
>> endif
>> ---
>>
>> I tried
>> awk '{ print $1 }' bvecs (with my original bvecs file)
>> this printed:
>> 0
>>
>> This has something to do with the file's carriage return. I then produced
>> a new bvecs file by manually typing values into a new text file. Now awk
>> '{ print $1 }' bvecs delivers one column with 33 lines.
>>
>>
>> Nevertheless, the bvecs output of flip4fsl is weird (full of zeros; 3 x
>> 66; see attachment).
>> I don't really get how this printf & awk command works.
>>
>> Any comments are very much appreciated.
>> Franz
>>
>>
>>
>>
>> Am 05.07.2011 um 15:19 schrieb Franz Liem:
>>
>>> Dear Freesurfers.
>>>
>>> I am trying to run trac-all on one subject and have a problem with the
>>> bvecs file at the -prep stage.
>>> After dtifit is started an error massage occurs: Error: bvecs and bvals
>>> don't have the same number of entries.
>>> I checked the dmri/bvals and dmri/bvecs. There seems to be a problem at
>>> the -corr stage (-corr alone finishes without error).
>>>
>>> My input file is one 4d .nii.gz file (with a total of 33 images, with
>>> the first being a b0 image).
>>>
>>> (I have attached the files from the dmri folder)
>>>
>>> The dmri/bvecs file only contains:
>>> 0,000
>>
Re: [Freesurfer] tracula bvecs problem
and another question.
Is it OK to run tracula with recons done with an earlier version (5.0.0)?
Thank you,
Franz
Am 06.07.2011 um 00:05 schrieb Anastasia Yendiki:
>
> Hi Franz - Which of the files that you sent us are the original files (the
> bvalfile and bvecfile from your dmrirc)? I could not find any files that had
> 33 lines among your attachments so I'm not sure what your input files look
> like.
>
> Thanks,
> a.y
>
> On Tue, 5 Jul 2011, Franz Liem wrote:
>
>> Hello again.
>>
>> I dug into the code and could locate the problem (I don't have a solution,
>> though. My coding skills are quite amateurish.) I think the problem somehow
>> lies in the format of my bvecs file.
>>
>> flip4fsl is not able to read it correctly:
>> ---
>> if (-e $inbvecs) then
>> echo "INFO: found $inbvecs, converting to FSL format"
>> if $fslflipx then
>> set sign = `echo $inorient | sed "s/[RAS]/+\ /g; s/[LPI]/-\ /g"`
>> endif
>> cp /dev/null $outbvecs
>> foreach j (1 2 3)
>> foreach k (1 2 3)
>> if ($order[$k] == $j) then
>> printf '%s ' `cat $inbvecs | awk -v sgn=$sign[$k]1 -v n=$k '{print
>> sgn*$n}'` \
>> >> $outbvecs
>> printf '\n' >> $outbvecs
>> endif
>> end
>> end
>> endif
>> ---
>>
>> I tried
>> awk '{ print $1 }' bvecs (with my original bvecs file)
>> this printed:
>> 0
>>
>> This has something to do with the file's carriage return. I then produced a
>> new bvecs file by manually typing values into a new text file. Now awk '{
>> print $1 }' bvecs delivers one column with 33 lines.
>>
>>
>> Nevertheless, the bvecs output of flip4fsl is weird (full of zeros; 3 x 66;
>> see attachment).
>> I don't really get how this printf & awk command works.
>>
>> Any comments are very much appreciated.
>> Franz
>>
>>
>>
>>
>
>
> 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 mailing list
Freesurfer@nmr.mgh.harvard.edu
https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
Re: [Freesurfer] tracula bvecs problem
Hi Anastasia, thank you. I created this file from scratch with osx' TextEdit and saved it as western european (Mac OS Roman). Are you able to read this? Thanks, Franz bvecs_onezero3decpoint1_western Description: Binary data Am 06.07.2011 um 17:42 schrieb Anastasia Yendiki: > > Hi Franz - Looks like it may be a windows vs. unix text file issue. > > Looking at dwi_orig.mghdti.bvecs under unix, it seems that it has > windows-specific carriage returns (they look like "^M" in unix). Actually, > I could only see this on a darwin machine, on a centos machine I can only > read the first 3 lines of the file. This was probably courtesy of excel. > Can you try using dos2unix on the files or saving them in another program? > > a.y > > On Wed, 6 Jul 2011, Franz Liem wrote: > >> Hi Priti and Anastasia. >> >> Thank you very much for your replies. >> >> Prit, I ran you modified_bvecs. This resulted in zeros (see bvecs_out). I >> also tried the modified_bvecs in a tab-deliniated version. same result. >> >> Anastasia, the original bvecs file is attached as bvecs_orig. I imported >> this into excel and transposed it. Since (cp $bvecfile >> $dwidir/dwi_orig.mghdti.bvecs) the dwi_orig.mghdti.bvecs from my first >> post should be an exact copy of my original input. >> >> >> 1) I then took the bvecs file provided in the tutorial data (and deleted the >> lines >33). This again resulted in zeros (see bvecs_tutorial_out). >> >> 2) I then created a file with only ones and zeros (see >> bvecs_onezero_western): >> 33 lines of >> 0 0 0 >> 1 0 0 >> >> >> This resulted in correct bvecs after ecc (see bvecs_onezero_western_out). >> >> >> 3) I then appended .000 (see bvecs_onezero3dec_western) >> 0.000 0.000 0.000 >> 1.000 0.000 0.000 >> ... >> >> this resulted in the exact same bvecs after ecc (with integers - see >> bvecs_onezero3dec_western_out). >> >> 4) I then wrote 1.100 (instead of 1.000; see >> bvecs_onezero3decpoint1_western). This again led to the same output (see >> bvecs_bvecs_onezero3decpoint1_western_out). >> >> So in conclusion, it seems as if the flip4fsl cannot read the digits after >> the decimal point. Can you reproduce this error? Might this be a problem >> with my german-language-settings computer (mac osx 10.6.4; although, since >> it is a swiss-german machine the system wide setting for decimal separator >> is the dot )? >> >> Thank you, >> Franz >> >> >> >> >> > ___ > 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 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.
Re: [Freesurfer] tracula bvecs problem
does your flip4fsl convert this file correctly (with the numbers after the decimal point)? Thank you, Franz Am 06.07.2011 um 18:06 schrieb Anastasia Yendiki: > > Yes! > > On Wed, 6 Jul 2011, Franz Liem wrote: > >> Hi Anastasia, >> thank you. I created this file from scratch with osx' TextEdit and saved it >> as western european (Mac OS Roman). >> Are you able to read this? >> >> Thanks, >> Franz >> > ___ > 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 mailing list Freesurfer@nmr.mgh.harvard.edu https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
Re: [Freesurfer] tracula bvecs problem
If i flip4fsl my fake file the the numbers after the decimal point are missing in the output (bvecs_bvecs_onezero3decpoint1_western_out). I have attached a fake bvecs fitting your tutorial data (70 lines). Would you be so kind, as to run this. Thank you so much for your help, Franz bvecs_bvecs_onezero3decpoint1_western_out Description: Binary data bvecs_faketutorial Description: Binary data Am 06.07.2011 um 19:48 schrieb Anastasia Yendiki: > > I'd need the nifti file to run flip4fsl. Can you try it on your data? > > On Wed, 6 Jul 2011, Franz Liem wrote: > >> does your flip4fsl convert this file correctly (with the numbers after the >> decimal point)? >> >> Thank you, >> Franz >> >> Am 06.07.2011 um 18:06 schrieb Anastasia Yendiki: >> >>> >>> Yes! >>> >>> On Wed, 6 Jul 2011, Franz Liem wrote: >>> >>>> Hi Anastasia, >>>> thank you. I created this file from scratch with osx' TextEdit and saved >>>> it as western european (Mac OS Roman). >>>> Are you able to read this? >>>> >>>> Thanks, >>>> Franz >>>> >>> ___ >>> 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 mailing list > Freesurfer@nmr.mgh.harvard.edu > https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer ___ 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.
Re: [Freesurfer] tracula bvecs problem
Hi again,
I found out that, if I change the flip4fsl line
printf '%s ' `cat $inbvecs | awk -v sgn=$sign[$k]1 -v n=$k
'{print sgn*$n}'` \
to
printf '%s ' `cat $inbvecs | awk -v sgn=$sign[$k]1 -v n=$k
'{print $n}'` \
(deleting the sgn*) the values in the out-bvecs are correct, i.e. the numbers
after the decimal separator are there.
Could you please help me to figure out what this line does.
In my case: sign = + + + (my image orientation is LAS)
therefore sgn is +1
What is the difference in my case between '{print sgn*$n}'` and '{print
$n}'` ?
Thank you very much,
Franz
Am 06.07.2011 um 21:32 schrieb Anastasia Yendiki:
>
> I'm attaching what I get when I run it. Only the trailing zeros are missing.
>
> On Wed, 6 Jul 2011, Franz Liem wrote:
>
>> If i flip4fsl my fake file the the numbers after the decimal point are
>> missing in the output (bvecs_bvecs_onezero3decpoint1_western_out).
>>
>> I have attached a fake bvecs fitting your tutorial data (70 lines). Would
>> you be so kind, as to run this.
>>
>> Thank you so much for your help,
>> Franz
>>
>>
> ___
> 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 mailing list
Freesurfer@nmr.mgh.harvard.edu
https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
Re: [Freesurfer] tracula bvecs problem
Dear Anastasia & all. I fixed it. The problem was my LOCALE setting which leads to different handling of decimal separators by awk (for further details see http://objectmix.com/awk/716715-awk-different-decimal-separator-different-linux-distros.html). My original setting was: % locale LANG="de_CH.UTF-8" LC_COLLATE="de_CH.UTF-8" LC_CTYPE="de_CH.UTF-8" LC_MESSAGES="de_CH.UTF-8" LC_MONETARY="de_CH.UTF-8" LC_NUMERIC="de_CH.UTF-8" LC_TIME="de_CH.UTF-8" LC_ALL= Therefore awk used the comma as decimal separator. In order to change this I added the following line to the .tcshrc file: setenv LC_ALL en_US resulting in: % locale LANG="de_CH.UTF-8" LC_COLLATE="en_US" LC_CTYPE="en_US" LC_MESSAGES="en_US" LC_MONETARY="en_US" LC_NUMERIC="en_US" LC_TIME="en_US" LC_ALL="en_US" Now the bvec rotation and correction works fine. Is your setting en_US or another format (e.g. en_US.ISO8859-1, en_US.ISO8859-15, en_US.US-ASCII, en_US.UTF-8)? Anastasia and Priti, thank you for your time. Best, Franz Am 06.07.2011 um 21:32 schrieb Anastasia Yendiki: > > I'm attaching what I get when I run it. Only the trailing zeros are missing. > > On Wed, 6 Jul 2011, Franz Liem wrote: > >> If i flip4fsl my fake file the the numbers after the decimal point are >> missing in the output (bvecs_bvecs_onezero3decpoint1_western_out). >> >> I have attached a fake bvecs fitting your tutorial data (70 lines). Would >> you be so kind, as to run this. >> >> Thank you so much for your help, >> Franz >> >> > ___ > 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 mailing list Freesurfer@nmr.mgh.harvard.edu https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
