Hi bruce, This happens for every orig.mgz that passes through mri_convert at the start of make_average_volumes. The files are 9M each, is there a drop-area where i can upload them? I just made some checks: my orig/001.mgz files are LPS (primary->axial), while the converted files are LIA (coronal). Can this effect the result? In any case, if you send me the link to the drop area, i will put an example mgz. thanks, sid.
On Sat, Jan 24, 2009 at 12:40 PM, Bruce Fischl fischl@nmr.mgh.harvard.eduwrote:
Hi Sid,
can you send us the volume that has this happen? I think it's just a display problem and won't affect anything else, but if you give us the example we'll fix it.
Bruce
On Sat, 24 Jan 2009, Siddharth Srivastava wrote:
Hi everyone,
Has anyone faced this problem before? Is there analternative to mri_convert than i can try to get the transformation, and then run the subsequent steps? Why are k_ras components approaching zero, and not exactly zero. make_average_surface works fine, no clipping, i have spent the
last 20 or so odd hours checking each surf directory. This happens only for the structurals that pass through mri_convert. Tried changing the -oc values, there is a shift, as expected, but the clipping remains fixed at this level (hence more brain gets cropped if the -oc values shift the brain posteriorly. sid.
On Fri, Jan 23, 2009 at 11:37 AM, Siddharth Srivastava <siddys@gmail.com
wrote:
Hi bruce,
I think the offending command ismri_convert /../../orig.mgz /../../orig-subject.mgh --apply_transform /../../mri/transforms/talairach.xfm -oc 0 0 0 I am attaching the pre- and post mri_convert as tiffs. I have also attached the pial_avg surface in the posterior view, for you comments. The folowing is the screen dump (patient name deleted):
$Id: mri_convert.c,v 1.146.2.3 2008/08/11 22:18:58 nicks Exp $ reading from /../subject/mri/orig.mgz... TR=1820.00, TE=2.93, TI=1100.00, flip angle=12.00 i_ras = (-1, 0, 0) j_ras = (0, 0, -1) k_ras = (-9.31323e-10, 1, -1.49012e-08) INFO: Applying transformation from file /../subject/mri/transforms/talairach.xfm... Reading transform with LTAreadEx()
INFO: Transform Matrix (linear_ras_to_ras) 1.026 0.084 0.079 -9.471; -0.105 1.048 0.228 -84.640; -0.106 -0.174 1.165 -38.874; 0.000 0.000 0.000 1.000;
Applying LTAtransformInterp (resample_type 1) INFO: Transform dst volume info is not used (valid flag = 0). applying the vox to vox linear transform 1.026 0.079 -0.084 -1.205; -0.106 1.165 0.174 9.576; 0.105 -0.228 1.048 -61.401; 0.000 0.000 0.000 1.000; writing to /../../orig-subject.mgh...
does this help in any way?
thanks, sid.
On Fri, Jan 23, 2009 at 11:01 AM, Bruce Fischl < fischl@nmr.mgh.harvard.edu
wrote:
Hi Sid,
have you looked through the individual datasets? That's where the cropping would be, which would have caused big errors in your surfaces. I assume that is not the case. Bruce
On Fri, 23 Jan 2009, Siddharth Srivastava wrote:
Hi Bruce,
I just realised that the cropping at the posterior aspect issimilar to the cropping usually done for the inferior aspect in a saggital view (to get rid of the neck etc..) . Could it be (remotely) possible that the cropping was done in a different orientation (nose pointing up in the sagittal view), and then oriented to the views that we see now? I have only used the basic commands "make_average_subject" with no special flags except --force sid.
On Fri, Jan 23, 2009 at 10:33 AM, Bruce Fischl fischl@nmr.mgh.harvard.eduwrote:
I'm not really sure. Doug or Nick: any ideas?
On Fri, 23 Jan 2009, Siddharth Srivastava wrote:
Hi Bruce,
please find attached a tiff file generated by mri_concat> --mean on the original mprages. > Here i can see the full view, and i think no registration has been > performed > as yet on these > images... Regarding exploring the dataset for 1 image, is it > possible > that > just 1 rouge image > can cause this problem? The clipping has a sharp border, almost as if > the > bounding box > itself has been cropped at that level. the intensity in these > posterior > slices is zero. > thanks, > sid. > > On Fri, Jan 23, 2009 at 9:51 AM, Bruce Fischl < > fischl@nmr.mgh.harvard.edu > > wrote: >> >> > if you can find a small set (1?) of subjects that generate the same > > image, >> then maybe you can just send us that subject and your commandline >> >> On Fri, 23 Jan 2009, Siddharth Srivastava wrote: >> >> ok.. i will try that and let you know... what other image/logs can >> i >> >> provide >> >>> for >>> localizing the source of the error? >>> sid. >>> >>> On Fri, Jan 23, 2009 at 9:04 AM, Bruce Fischl < >>> fischl@nmr.mgh.harvard.edu >>> >>> wrote: >>> >>>> >>>> >>>> not really, it seems like there is a bug. If you can localize it >>> to >>> just >>> >>> one or a few subjects it would a lot easier to track down >>> >>>> >>>> On Fri, 23 Jan 2009, Siddharth Srivastava wrote: >>>> >>>> Hi Bruce, >>>> >>>> These are about 28 images. I have not tried fewer...do you >>>> >>>> think there >>>>> are some images with incorrect orientation in the cohort? That >>>>> would >>>>> show >>>>> up >>>>> in the other location in the average i think... >>>>> sid. >>>>> On Fri, Jan 23, 2009 at 8:46 AM, Bruce Fischl < >>>>> fischl@nmr.mgh.harvard.edu >>>>> >>>>> wrote: >>>>> >>>>> >>>>>> >>>>>> I don't think so. How many subjects? Have you tried fewer? >>>>>> >>>>> >>>>> >>>>> On Fri, 23 Jan 2009, Siddharth Srivastava wrote: >>>>> >>>>>> >>>>>> The surfaces look all right. It happens only to T1. It cant be >>>>>> a >>>>>> display >>>>>> >>>>>> problem, can it?? >>>>>> >>>>>> sid. >>>>>> >>>>>>> >>>>>>> On Fri, Jan 23, 2009 at 5:58 AM, Bruce Fischl < >>>>>>> fischl@nmr.mgh.harvard.edu >>>>>>> >>>>>>> wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>>> that is strange. Do the surfaces look ok? How many subjects >>>>>>>> are >>>>>>>> >>>>>>>> you >>>>>>> >>>>>>> averaging? Does this happen if you only average one or a few? >>>>>>> >>>>>>> >>>>>>> On Thu, 22 Jan 2009, Siddharth Srivastava wrote: >>>>>>>> >>>>>>>> Hi everyone, >>>>>>>> >>>>>>>> I am attaching a tiff file showing the tkmedit >>>>>>>> view >>>>>>>> of >>>>>>>> >>>>>>>> the average >>>>>>>> >>>>>>>> T1 that freesurfer created during make_average_subject. I am >>>>>>>>> a >>>>>>>>> bit >>>>>>>>> concerned >>>>>>>>> >>>>>>>>> about the cropping that is evident at the posterior aspect of >>>>>>>>> the >>>>>>>>> brain. >>>>>>>>> The >>>>>>>>> >>>>>>>>> individual T1's are complete and ok, so i am guessing that >>>>>>>>> something >>>>>>>>> went >>>>>>>>> wrong during the transform of the individual brain during the >>>>>>>>> process. >>>>>>>>> Can >>>>>>>>> anyone help me find out the problem ? The average surfaces >>>>>>>>> also >>>>>>>>> look >>>>>>>>> all >>>>>>>>> right. >>>>>>>>> thanks, >>>>>>>>> sid. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>> >>>>> >>> >
Hi Sid,
put one of them on our ftp site along with the tal xform file.
cheers, Bruce
On Sat, 24 Jan 2009, Siddharth Srivastava wrote:
Hi bruce, This happens for every orig.mgz that passes through mri_convert at the start of make_average_volumes. The files are 9M each, is there a drop-area where i can upload them? I just made some checks: my orig/001.mgz files are LPS (primary->axial), while the converted files are LIA (coronal). Can this effect the result? In any case, if you send me the link to the drop area, i will put an example mgz. thanks, sid.
On Sat, Jan 24, 2009 at 12:40 PM, Bruce Fischl fischl@nmr.mgh.harvard.eduwrote:
Hi Sid,
can you send us the volume that has this happen? I think it's just a display problem and won't affect anything else, but if you give us the example we'll fix it.
Bruce
On Sat, 24 Jan 2009, Siddharth Srivastava wrote:
Hi everyone,
Has anyone faced this problem before? Is there analternative to mri_convert than i can try to get the transformation, and then run the subsequent steps? Why are k_ras components approaching zero, and not exactly zero. make_average_surface works fine, no clipping, i have spent the
last 20 or so odd hours checking each surf directory. This happens only for the structurals that pass through mri_convert. Tried changing the -oc values, there is a shift, as expected, but the clipping remains fixed at this level (hence more brain gets cropped if the -oc values shift the brain posteriorly. sid.
On Fri, Jan 23, 2009 at 11:37 AM, Siddharth Srivastava <siddys@gmail.com
wrote:
Hi bruce,
I think the offending command ismri_convert /../../orig.mgz /../../orig-subject.mgh --apply_transform /../../mri/transforms/talairach.xfm -oc 0 0 0 I am attaching the pre- and post mri_convert as tiffs. I have also attached the pial_avg surface in the posterior view, for you comments. The folowing is the screen dump (patient name deleted):
$Id: mri_convert.c,v 1.146.2.3 2008/08/11 22:18:58 nicks Exp $ reading from /../subject/mri/orig.mgz... TR=1820.00, TE=2.93, TI=1100.00, flip angle=12.00 i_ras = (-1, 0, 0) j_ras = (0, 0, -1) k_ras = (-9.31323e-10, 1, -1.49012e-08) INFO: Applying transformation from file /../subject/mri/transforms/talairach.xfm... Reading transform with LTAreadEx()
INFO: Transform Matrix (linear_ras_to_ras) 1.026 0.084 0.079 -9.471; -0.105 1.048 0.228 -84.640; -0.106 -0.174 1.165 -38.874; 0.000 0.000 0.000 1.000;
Applying LTAtransformInterp (resample_type 1) INFO: Transform dst volume info is not used (valid flag = 0). applying the vox to vox linear transform 1.026 0.079 -0.084 -1.205; -0.106 1.165 0.174 9.576; 0.105 -0.228 1.048 -61.401; 0.000 0.000 0.000 1.000; writing to /../../orig-subject.mgh...
does this help in any way?
thanks, sid.
On Fri, Jan 23, 2009 at 11:01 AM, Bruce Fischl < fischl@nmr.mgh.harvard.edu
wrote:
Hi Sid,
have you looked through the individual datasets? That's where the cropping would be, which would have caused big errors in your surfaces. I assume that is not the case. Bruce
On Fri, 23 Jan 2009, Siddharth Srivastava wrote:
Hi Bruce,
I just realised that the cropping at the posterior aspect issimilar to the cropping usually done for the inferior aspect in a saggital view (to get rid of the neck etc..) . Could it be (remotely) possible that the cropping was done in a different orientation (nose pointing up in the sagittal view), and then oriented to the views that we see now? I have only used the basic commands "make_average_subject" with no special flags except --force sid.
On Fri, Jan 23, 2009 at 10:33 AM, Bruce Fischl fischl@nmr.mgh.harvard.eduwrote:
I'm not really sure. Doug or Nick: any ideas?
> > > On Fri, 23 Jan 2009, Siddharth Srivastava wrote: > > Hi Bruce, > > please find attached a tiff file generated by mri_concat >> --mean on the original mprages. >> Here i can see the full view, and i think no registration has been >> performed >> as yet on these >> images... Regarding exploring the dataset for 1 image, is it >> possible >> that >> just 1 rouge image >> can cause this problem? The clipping has a sharp border, almost as if >> the >> bounding box >> itself has been cropped at that level. the intensity in these >> posterior >> slices is zero. >> thanks, >> sid. >> >> On Fri, Jan 23, 2009 at 9:51 AM, Bruce Fischl < >> fischl@nmr.mgh.harvard.edu >> >> wrote: >>> >>> >> if you can find a small set (1?) of subjects that generate the same >> >> image, >>> then maybe you can just send us that subject and your commandline >>> >>> On Fri, 23 Jan 2009, Siddharth Srivastava wrote: >>> >>> ok.. i will try that and let you know... what other image/logs can >>> i >>> >>> provide >>> >>>> for >>>> localizing the source of the error? >>>> sid. >>>> >>>> On Fri, Jan 23, 2009 at 9:04 AM, Bruce Fischl < >>>> fischl@nmr.mgh.harvard.edu >>>> >>>> wrote: >>>> >>>>> >>>>> >>>>> not really, it seems like there is a bug. If you can localize it >>>> to >>>> just >>>> >>>> one or a few subjects it would a lot easier to track down >>>> >>>>> >>>>> On Fri, 23 Jan 2009, Siddharth Srivastava wrote: >>>>> >>>>> Hi Bruce, >>>>> >>>>> These are about 28 images. I have not tried fewer...do you >>>>> >>>>> think there >>>>>> are some images with incorrect orientation in the cohort? That >>>>>> would >>>>>> show >>>>>> up >>>>>> in the other location in the average i think... >>>>>> sid. >>>>>> On Fri, Jan 23, 2009 at 8:46 AM, Bruce Fischl < >>>>>> fischl@nmr.mgh.harvard.edu >>>>>> >>>>>> wrote: >>>>>> >>>>>> >>>>>>> >>>>>>> I don't think so. How many subjects? Have you tried fewer? >>>>>>> >>>>>> >>>>>> >>>>>> On Fri, 23 Jan 2009, Siddharth Srivastava wrote: >>>>>> >>>>>>> >>>>>>> The surfaces look all right. It happens only to T1. It cant be >>>>>>> a >>>>>>> display >>>>>>> >>>>>>> problem, can it?? >>>>>>> >>>>>>> sid. >>>>>>> >>>>>>>> >>>>>>>> On Fri, Jan 23, 2009 at 5:58 AM, Bruce Fischl < >>>>>>>> fischl@nmr.mgh.harvard.edu >>>>>>>> >>>>>>>> wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> that is strange. Do the surfaces look ok? How many subjects >>>>>>>>> are >>>>>>>>> >>>>>>>>> you >>>>>>>> >>>>>>>> averaging? Does this happen if you only average one or a few? >>>>>>>> >>>>>>>> >>>>>>>> On Thu, 22 Jan 2009, Siddharth Srivastava wrote: >>>>>>>>> >>>>>>>>> Hi everyone, >>>>>>>>> >>>>>>>>> I am attaching a tiff file showing the tkmedit >>>>>>>>> view >>>>>>>>> of >>>>>>>>> >>>>>>>>> the average >>>>>>>>> >>>>>>>>> T1 that freesurfer created during make_average_subject. I am >>>>>>>>>> a >>>>>>>>>> bit >>>>>>>>>> concerned >>>>>>>>>> >>>>>>>>>> about the cropping that is evident at the posterior aspect of >>>>>>>>>> the >>>>>>>>>> brain. >>>>>>>>>> The >>>>>>>>>> >>>>>>>>>> individual T1's are complete and ok, so i am guessing that >>>>>>>>>> something >>>>>>>>>> went >>>>>>>>>> wrong during the transform of the individual brain during the >>>>>>>>>> process. >>>>>>>>>> Can >>>>>>>>>> anyone help me find out the problem ? The average surfaces >>>>>>>>>> also >>>>>>>>>> look >>>>>>>>>> all >>>>>>>>>> right. >>>>>>>>>> thanks, >>>>>>>>>> sid. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>> >>>> >>
Sid,
What is the field-of-view size? Use:
mri_info orig.mgz
and look for the 'fov' output. It should be 256. What is the fov of the input files in subj/mri/orig? If it is greater than 256, that might be the problem, but the cropping problem we have seen with that occurs during the original recons, not during make_average_subject. If it is
256, then the -cropsize256 flag should be added to recon-all.
Nick
On Sat, 2009-01-24 at 15:21 -0800, Siddharth Srivastava wrote:
Hi bruce, This happens for every orig.mgz that passes through mri_convert at the start of make_average_volumes. The files are 9M each, is there a drop-area where i can upload them? I just made some checks: my orig/001.mgz files are LPS (primary-
axial), while
the converted files are LIA (coronal). Can this effect the result? In any case, if you send me the link to the drop area, i will put an example mgz. thanks, sid.
On Sat, Jan 24, 2009 at 12:40 PM, Bruce Fischl fischl@nmr.mgh.harvard.edu wrote: Hi Sid,
can you send us the volume that has this happen? I think it's just a display problem and won't affect anything else, but if you give us the example we'll fix it. Bruce On Sat, 24 Jan 2009, Siddharth Srivastava wrote: Hi everyone, Has anyone faced this problem before? Is there an alternative to mri_convert than i can try to get the transformation, and then run the subsequent steps? Why are k_ras components approaching zero, and not exactly zero. make_average_surface works fine, no clipping, i have spent the last 20 or so odd hours checking each surf directory. This happens only for the structurals that pass through mri_convert. Tried changing the -oc values, there is a shift, as expected, but the clipping remains fixed at this level (hence more brain gets cropped if the -oc values shift the brain posteriorly. sid. On Fri, Jan 23, 2009 at 11:37 AM, Siddharth Srivastava <siddys@gmail.com>wrote: Hi bruce, I think the offending command is mri_convert /../../orig.mgz /../../orig- subject.mgh --apply_transform /../../mri/transforms/talairach.xfm -oc 0 0 0 I am attaching the pre- and post mri_convert as tiffs. I have also attached the pial_avg surface in the posterior view, for you comments. The folowing is the screen dump (patient name deleted): ---------------------------------------------------------------------------------------------------- $Id: mri_convert.c,v 1.146.2.3 2008/08/11 22:18:58 nicks Exp $ reading from /../subject/mri/orig.mgz... TR=1820.00, TE=2.93, TI=1100.00, flip angle=12.00 i_ras = (-1, 0, 0) j_ras = (0, 0, -1) k_ras = (-9.31323e-10, 1, -1.49012e-08) INFO: Applying transformation from file /../subject/mri/transforms/talairach.xfm... Reading transform with LTAreadEx() --------------------------------- INFO: Transform Matrix (linear_ras_to_ras) 1.026 0.084 0.079 -9.471; -0.105 1.048 0.228 -84.640; -0.106 -0.174 1.165 -38.874; 0.000 0.000 0.000 1.000; --------------------------------- Applying LTAtransformInterp (resample_type 1) INFO: Transform dst volume info is not used (valid flag = 0). applying the vox to vox linear transform 1.026 0.079 -0.084 -1.205; -0.106 1.165 0.174 9.576; 0.105 -0.228 1.048 -61.401; 0.000 0.000 0.000 1.000; writing to /../../orig-subject.mgh... ---------------------------------------------------------------------- does this help in any way? thanks, sid. On Fri, Jan 23, 2009 at 11:01 AM, Bruce Fischl <fischl@nmr.mgh.harvard.edu wrote: Hi Sid, have you looked through the individual datasets? That's where the cropping would be, which would have caused big errors in your surfaces. I assume that is not the case. Bruce On Fri, 23 Jan 2009, Siddharth Srivastava wrote: Hi Bruce, I just realised that the cropping at the posterior aspect is similar to the cropping usually done for the inferior aspect in a saggital view (to get rid of the neck etc..) . Could it be (remotely) possible that the cropping was done in a different orientation (nose pointing up in the sagittal view), and then oriented to the views that we see now? I have only used the basic commands "make_average_subject" with no special flags except --force sid. On Fri, Jan 23, 2009 at 10:33 AM, Bruce Fischl <fischl@nmr.mgh.harvard.edu>wrote: I'm not really sure. Doug or Nick: any ideas? On Fri, 23 Jan 2009, Siddharth Srivastava wrote: Hi Bruce, please find attached a tiff file generated by mri_concat --mean on the original mprages. Here i can see the full view, and i think no registration has been performed as yet on these images... Regarding exploring the dataset for 1 image, is it possible that just 1 rouge image can cause this problem? The clipping has a sharp border, almost as if the bounding box itself has been cropped at that level. the intensity in these posterior slices is zero. thanks, sid. On Fri, Jan 23, 2009 at 9:51 AM, Bruce Fischl < fischl@nmr.mgh.harvard.edu wrote: if you can find a small set (1?) of subjects that generate the same image, then maybe you can just send us that subject and your commandline On Fri, 23 Jan 2009, Siddharth Srivastava wrote: ok.. i will try that and let you know... what other image/logs can i provide for localizing the source of the error? sid. On Fri, Jan 23, 2009 at 9:04 AM, Bruce Fischl < fischl@nmr.mgh.harvard.edu wrote: not really, it seems like there is a bug. If you can localize it to just one or a few subjects it would a lot easier to track down On Fri, 23 Jan 2009, Siddharth Srivastava wrote: Hi Bruce, These are about 28 images. I have not tried fewer...do you think there are some images with incorrect orientation in the cohort? That would show up in the other location in the average i think... sid. On Fri, Jan 23, 2009 at 8:46 AM, Bruce Fischl < fischl@nmr.mgh.harvard.edu wrote: I don't think so. How many subjects? Have you tried fewer? On Fri, 23 Jan 2009, Siddharth Srivastava wrote: The surfaces look all right. It happens only to T1. It cant be a display problem, can it?? sid. On Fri, Jan 23, 2009 at 5:58 AM, Bruce Fischl < fischl@nmr.mgh.harvard.edu wrote: that is strange. Do the surfaces look ok? How many subjects are you averaging? Does this happen if you only average one or a few? On Thu, 22 Jan 2009, Siddharth Srivastava wrote: Hi everyone, I am attaching a tiff file showing the tkmedit view of the average T1 that freesurfer created during make_average_subject. I am a bit concerned about the cropping that is evident at the posterior aspect of the brain. The individual T1's are complete and ok, so i am guessing that something went wrong during the transform of the individual brain during the process. Can anyone help me find out the problem ? The average surfaces also look all right. thanks, sid.
Freesurfer mailing list Freesurfer@nmr.mgh.harvard.edu https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
Hi Nick, Thanks for looking into this. I am pasting the dump of mri_info on the files: 1) mri_info orig/oo1.mgz ------------------------------------------------ Volume information for 001.mgz type: MGH dimensions: 256 x 256 x 160 voxel sizes: 1.0000, 1.0000, 1.0000 type: SHORT (4) fov: 256.000 dof: 0 xstart: -128.0, xend: 128.0 ystart: -128.0, yend: 128.0 zstart: -80.0, zend: 80.0 TR: 1820.00 msec, TE: 2.93 msec, TI: 1100.00 msec, flip angle: 12.00 degrees nframes: 1 ras xform present xform info: x_r = -0.9981, y_r = -0.0000, z_r = -0.0618, c_r = -1.9246 : x_a = 0.0098, y_a = -0.9874, z_a = -0.1581, c_a = 50.0265 : x_s = -0.0610, y_s = -0.1584, z_s = 0.9855, c_s = 48.4401
talairach xfm : Orientation : LPS Primary Slice Direction: axial
voxel to ras transform: -0.9981 -0.0000 -0.0618 130.7745 0.0098 -0.9874 -0.1581 187.8058 -0.0610 -0.1584 0.9855 -2.3123 0.0000 0.0000 0.0000 1.0000
voxel-to-ras determinant 1
ras to voxel transform: -0.9981 0.0098 -0.0610 128.5450 -0.0000 -0.9874 -0.1584 185.0682 -0.0618 -0.1581 0.9855 40.0535 0.0000 0.0000 0.0000 1.0000
------------------------------------------------ 2) mri_info on orig.mgz ---------------------------------------------------- Volume information for orig.mgz type: MGH dimensions: 256 x 256 x 256 voxel sizes: 1.0000, 1.0000, 1.0000 type: UCHAR (0) fov: 256.000 dof: 0 xstart: -128.0, xend: 128.0 ystart: -128.0, yend: 128.0 zstart: -128.0, zend: 128.0 TR: 1820.00 msec, TE: 2.93 msec, TI: 1100.00 msec, flip angle: 12.00 degrees nframes: 1 ras xform present xform info: x_r = -1.0000, y_r = 0.0000, z_r = -0.0000, c_r = -1.9246 : x_a = 0.0000, y_a = 0.0000, z_a = 1.0000, c_a = 50.0265 : x_s = 0.0000, y_s = -1.0000, z_s = -0.0000, c_s = 48.4401
talairach xfm : /share/data0/ssrivastava/processed/RO28NormVC/mri/transforms/talairach.xfm Orientation : LIA Primary Slice Direction: coronal
voxel to ras transform: -1.0000 0.0000 -0.0000 126.0754 0.0000 0.0000 1.0000 -77.9735 0.0000 -1.0000 -0.0000 176.4401 0.0000 0.0000 0.0000 1.0000
voxel-to-ras determinant -1
ras to voxel transform: -1.0000 -0.0000 0.0000 126.0754 -0.0000 -0.0000 -1.0000 176.4401 -0.0000 1.0000 -0.0000 77.9735 0.0000 0.0000 0.0000 1.0000
---------------------------------------------------- The fov in both cases is 256. Can i just mention (again), that this happens only during "make_average_volumes" when the orig/001.mgz passes through mri_convert. regards, sid.
On Mon, Jan 26, 2009 at 10:43 AM, Nick Schmansky nicks@nmr.mgh.harvard.eduwrote:
Sid,
What is the field-of-view size? Use:
mri_info orig.mgz
and look for the 'fov' output. It should be 256. What is the fov of the input files in subj/mri/orig? If it is greater than 256, that might be the problem, but the cropping problem we have seen with that occurs during the original recons, not during make_average_subject. If it is
256, then the -cropsize256 flag should be added to recon-all.
Nick
On Sat, 2009-01-24 at 15:21 -0800, Siddharth Srivastava wrote:
Hi bruce, This happens for every orig.mgz that passes through mri_convert at the start of make_average_volumes. The files are 9M each, is there a drop-area where i can upload them? I just made some checks: my orig/001.mgz files are LPS (primary-
axial), while
the converted files are LIA (coronal). Can this effect the result? In any case, if you send me the link to the drop area, i will put an example mgz. thanks, sid.
On Sat, Jan 24, 2009 at 12:40 PM, Bruce Fischl fischl@nmr.mgh.harvard.edu wrote: Hi Sid,
can you send us the volume that has this happen? I think it's just a display problem and won't affect anything else, but if you give us the example we'll fix it. Bruce On Sat, 24 Jan 2009, Siddharth Srivastava wrote: Hi everyone, Has anyone faced this problem before? Is there an alternative to mri_convert than i can try to get the transformation, and then run the subsequent steps? Why are k_ras components approaching zero, and not exactly zero. make_average_surface works fine, no clipping, i have spent the last 20 or so odd hours checking each surf directory. This happens only for the structurals that pass through mri_convert. Tried changing the -oc values, there is a shift, as expected, but the clipping remains fixed at this level (hence more brain gets cropped if the -oc values shift the brain posteriorly. sid. On Fri, Jan 23, 2009 at 11:37 AM, Siddharth Srivastava <siddys@gmail.com>wrote: Hi bruce, I think the offending command is mri_convert /../../orig.mgz /../../orig- subject.mgh --apply_transform /../../mri/transforms/talairach.xfm -oc 0 0 0 I am attaching the pre- and post mri_convert as tiffs. I have also attached the pial_avg surface in the posterior view, for you comments. The folowing is the screen dump (patient name deleted):
$Id: mri_convert.c,v 1.146.2.3 2008/08/11 22:18:58 nicks Exp $ reading from /../subject/mri/orig.mgz... TR=1820.00, TE=2.93, TI=1100.00, flip angle=12.00 i_ras = (-1, 0, 0) j_ras = (0, 0, -1) k_ras = (-9.31323e-10, 1, -1.49012e-08) INFO: Applying transformation from file /../subject/mri/transforms/talairach.xfm... Reading transform with LTAreadEx() --------------------------------- INFO: Transform Matrix (linear_ras_to_ras) 1.026 0.084 0.079 -9.471; -0.105 1.048 0.228 -84.640; -0.106 -0.174 1.165 -38.874; 0.000 0.000 0.000 1.000; --------------------------------- Applying LTAtransformInterp (resample_type 1) INFO: Transform dst volume info is not used (valid flag = 0). applying the vox to vox linear transform 1.026 0.079 -0.084 -1.205; -0.106 1.165 0.174 9.576; 0.105 -0.228 1.048 -61.401; 0.000 0.000 0.000 1.000; writing to /../../orig-subject.mgh...
does this help in any way? thanks, sid. On Fri, Jan 23, 2009 at 11:01 AM, Bruce Fischl <fischl@nmr.mgh.harvard.edu wrote: Hi Sid, have you looked through the individual datasets? That's where the cropping would be, which would have caused big errors in your surfaces. I assume that is not the case. Bruce On Fri, 23 Jan 2009, Siddharth Srivastava wrote: Hi Bruce, I just realised that the cropping at the posterior aspect is similar to the cropping usually done for the inferior aspect in a saggital view (to get rid of the neck etc..) . Could it be (remotely) possible that the cropping was done in a different orientation (nose pointing up in the sagittal view), and then oriented to the views that we see now? I have only used the basic commands "make_average_subject" with no special flags except --force sid. On Fri, Jan 23, 2009 at 10:33 AM, Bruce Fischl <fischl@nmr.mgh.harvard.eduwrote:
I'm not really sure. Doug or Nick: any ideas? On Fri, 23 Jan 2009, Siddharth Srivastava wrote: Hi Bruce, please find attached a tiff file generated by mri_concat --mean on the original mprages. Here i can see the full view, and i think no registration has been performed as yet on these images... Regarding exploring the dataset for 1 image, is it possible that just 1 rouge image can cause this problem? The clipping has a sharp border, almost as if the bounding box itself has been cropped at that level. the intensity in these posterior slices is zero. thanks, sid. On Fri, Jan 23, 2009 at 9:51 AM, Bruce Fischl <fischl@nmr.mgh.harvard.edu
wrote: if you can find a small set (1?) of subjects that generate the same image, then maybe you can just send us that subjectand your commandline
On Fri, 23 Jan 2009, SiddharthSrivastava wrote:
ok.. i will try that and let you know...what other image/logs can i
providefor
localizing the source of the error?
sid.
On Fri, Jan 23, 2009 at 9:04 AM, Bruce Fischl <
fischl@nmr.mgh.harvard.edu
wrote:
not really, it seems like there is a bug. If you can localize it to
just
one or a few subjects it would a lot easier to track down
On Fri, 23 Jan 2009, Siddharth Srivastava wrote:Hi Bruce,These are about 28 images. I have not tried fewer...do youthink thereare some images with incorrect orientation in the cohort? Thatwouldshowupin the other location in the average i think...sid.On Fri, Jan 23, 2009 at 8:46 AM, Bruce Fischl <fischl@nmr.mgh.harvard.eduwrote:I don't think so. How many subjects? Have you triedfewer?
On Fri, 23 Jan 2009, Siddharth Srivastava wrote:The surfaces look all right. It happens only to T1.It cant be a
displayproblem, can it??sid.On Fri, Jan 23, 2009 at 5:58 AM, Bruce Fischl<
fischl@nmr.mgh.harvard.eduwrote:that is strange. Do the surfaces lookok? How many subjects are
youaveraging? Does this happen if you onlyaverage one or a few?
On Thu, 22 Jan 2009, SiddharthSrivastava wrote:
Hi everyone,I am attaching a tiff file showing thetkmedit view
ofthe averageT1 that freesurfer createdduring make_average_subject. I am a
bitconcernedabout the cropping that isevident at the posterior aspect of
thebrain.Theindividual T1's are completeand ok, so i am guessing that
somethingwentwrong during the transform ofthe individual brain during the
process.Cananyone help me find out theproblem ? The average surfaces also
lookallright.thanks,sid.
Freesurfer mailing list Freesurfer@nmr.mgh.harvard.edu https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
just a correction: cropping happens when orig.mgz is operated by mri_convert to give orig-RO8NormVC .. (not on 001.mgz as mentioned earlier) sid.
On Mon, Jan 26, 2009 at 10:57 AM, Siddharth Srivastava siddys@gmail.comwrote:
Hi Nick, Thanks for looking into this. I am pasting the dump of mri_info on the files:
- mri_info orig/oo1.mgz
Volume information for 001.mgz type: MGH dimensions: 256 x 256 x 160 voxel sizes: 1.0000, 1.0000, 1.0000 type: SHORT (4) fov: 256.000 dof: 0 xstart: -128.0, xend: 128.0 ystart: -128.0, yend: 128.0 zstart: -80.0, zend: 80.0 TR: 1820.00 msec, TE: 2.93 msec, TI: 1100.00 msec, flip angle: 12.00 degrees nframes: 1 ras xform present xform info: x_r = -0.9981, y_r = -0.0000, z_r = -0.0618, c_r = -1.9246 : x_a = 0.0098, y_a = -0.9874, z_a = -0.1581, c_a = 50.0265 : x_s = -0.0610, y_s = -0.1584, z_s = 0.9855, c_s = 48.4401
talairach xfm : Orientation : LPS Primary Slice Direction: axial
voxel to ras transform: -0.9981 -0.0000 -0.0618 130.7745 0.0098 -0.9874 -0.1581 187.8058 -0.0610 -0.1584 0.9855 -2.3123 0.0000 0.0000 0.0000 1.0000
voxel-to-ras determinant 1
ras to voxel transform: -0.9981 0.0098 -0.0610 128.5450 -0.0000 -0.9874 -0.1584 185.0682 -0.0618 -0.1581 0.9855 40.0535 0.0000 0.0000 0.0000 1.0000
- mri_info on orig.mgz
Volume information for orig.mgz type: MGH dimensions: 256 x 256 x 256 voxel sizes: 1.0000, 1.0000, 1.0000 type: UCHAR (0) fov: 256.000 dof: 0 xstart: -128.0, xend: 128.0 ystart: -128.0, yend: 128.0 zstart: -128.0, zend: 128.0 TR: 1820.00 msec, TE: 2.93 msec, TI: 1100.00 msec, flip angle: 12.00 degrees nframes: 1 ras xform present xform info: x_r = -1.0000, y_r = 0.0000, z_r = -0.0000, c_r = -1.9246 : x_a = 0.0000, y_a = 0.0000, z_a = 1.0000, c_a = 50.0265 : x_s = 0.0000, y_s = -1.0000, z_s = -0.0000, c_s = 48.4401
talairach xfm : /share/data0/ssrivastava/processed/RO28NormVC/mri/transforms/talairach.xfm Orientation : LIA Primary Slice Direction: coronal
voxel to ras transform: -1.0000 0.0000 -0.0000 126.0754 0.0000 0.0000 1.0000 -77.9735 0.0000 -1.0000 -0.0000 176.4401 0.0000 0.0000 0.0000 1.0000
voxel-to-ras determinant -1
ras to voxel transform: -1.0000 -0.0000 0.0000 126.0754 -0.0000 -0.0000 -1.0000 176.4401 -0.0000 1.0000 -0.0000 77.9735 0.0000 0.0000 0.0000 1.0000
The fov in both cases is 256. Can i just mention (again), that this happens only during "make_average_volumes" when the orig/001.mgz passes through mri_convert. regards, sid.
On Mon, Jan 26, 2009 at 10:43 AM, Nick Schmansky < nicks@nmr.mgh.harvard.edu> wrote:
Sid,
What is the field-of-view size? Use:
mri_info orig.mgz
and look for the 'fov' output. It should be 256. What is the fov of the input files in subj/mri/orig? If it is greater than 256, that might be the problem, but the cropping problem we have seen with that occurs during the original recons, not during make_average_subject. If it is
256, then the -cropsize256 flag should be added to recon-all.
Nick
On Sat, 2009-01-24 at 15:21 -0800, Siddharth Srivastava wrote:
Hi bruce, This happens for every orig.mgz that passes through mri_convert at the start of make_average_volumes. The files are 9M each, is there a drop-area where i can upload them? I just made some checks: my orig/001.mgz files are LPS (primary-
axial), while
the converted files are LIA (coronal). Can this effect the result? In any case, if you send me the link to the drop area, i will put an example mgz. thanks, sid.
On Sat, Jan 24, 2009 at 12:40 PM, Bruce Fischl fischl@nmr.mgh.harvard.edu wrote: Hi Sid,
can you send us the volume that has this happen? I think it's just a display problem and won't affect anything else, but if you give us the example we'll fix it. Bruce On Sat, 24 Jan 2009, Siddharth Srivastava wrote: Hi everyone, Has anyone faced this problem before? Is there an alternative to mri_convert than i can try to get the transformation, and then run the subsequent steps? Why are k_ras components approaching zero, and not exactly zero. make_average_surface works fine, no clipping, i have spent the last 20 or so odd hours checking each surf directory. This happens only for the structurals that pass through mri_convert. Tried changing the -oc values, there is a shift, as expected, but the clipping remains fixed at this level (hence more brain gets cropped if the -oc values shift the brain posteriorly. sid. On Fri, Jan 23, 2009 at 11:37 AM, Siddharth Srivastava <siddys@gmail.com>wrote: Hi bruce, I think the offending command is mri_convert /../../orig.mgz /../../orig- subject.mgh --apply_transform /../../mri/transforms/talairach.xfm -oc 0 0 0 I am attaching the pre- and post mri_convert as tiffs. I have also attached the pial_avg surface in the posterior view, for you comments. The folowing is the screen dump (patient name deleted):
$Id: mri_convert.c,v 1.146.2.3 2008/08/11 22:18:58 nicks Exp $ reading from /../subject/mri/orig.mgz... TR=1820.00, TE=2.93, TI=1100.00, flip angle=12.00 i_ras = (-1, 0, 0) j_ras = (0, 0, -1) k_ras = (-9.31323e-10, 1, -1.49012e-08) INFO: Applying transformation from file /../subject/mri/transforms/talairach.xfm... Reading transform with LTAreadEx() --------------------------------- INFO: Transform Matrix (linear_ras_to_ras) 1.026 0.084 0.079 -9.471; -0.105 1.048 0.228 -84.640; -0.106 -0.174 1.165 -38.874; 0.000 0.000 0.000 1.000; --------------------------------- Applying LTAtransformInterp (resample_type 1) INFO: Transform dst volume info is not used (valid flag = 0). applying the vox to vox linear transform 1.026 0.079 -0.084 -1.205; -0.106 1.165 0.174 9.576; 0.105 -0.228 1.048 -61.401; 0.000 0.000 0.000 1.000; writing to /../../orig-subject.mgh...
does this help in any way? thanks, sid. On Fri, Jan 23, 2009 at 11:01 AM, Bruce Fischl <fischl@nmr.mgh.harvard.edu wrote: Hi Sid, have you looked through the individual datasets? That's where the cropping would be, which would have caused big errors in your surfaces. I assume that is not the case. Bruce On Fri, 23 Jan 2009, Siddharth Srivastava wrote: Hi Bruce, I just realised that the cropping at the posterior aspect is similar to the cropping usually done for the inferior aspect in a saggital view (to get rid of the neck etc..) . Could it be (remotely) possible that the cropping was done in a different orientation (nose pointing up in the sagittal view), and then oriented to the views that we see now? I have only used the basic commands "make_average_subject" with no special flags except --force sid. On Fri, Jan 23, 2009 at 10:33 AM, Bruce Fischl <fischl@nmr.mgh.harvard.eduwrote:
I'm not really sure. Doug or Nick: any ideas? On Fri, 23 Jan 2009, Siddharth Srivastava wrote: Hi Bruce, please find attached a tiff file generated by mri_concat --mean on the original mprages. Here i can see the full view, and i think no registration has been performed as yet on these images... Regarding exploring the dataset for 1 image, is it possible that just 1 rouge image can cause this problem? The clipping has a sharp border, almost as if the bounding box itself has been cropped at that level. the intensity in these posterior slices is zero. thanks, sid. On Fri, Jan 23, 2009 at 9:51 AM, Bruce Fischl <fischl@nmr.mgh.harvard.edu
wrote: if you can find a small set (1?) of subjects that generate the same image, then maybe you can just send us that subjectand your commandline
On Fri, 23 Jan 2009,Siddharth Srivastava wrote:
ok.. i will try that and let you know...what other image/logs can i
providefor
localizing the source of the error?
sid.
On Fri, Jan 23, 2009 at 9:04 AM, Bruce Fischl <
fischl@nmr.mgh.harvard.edu
wrote:
not really, it seems like there is a bug. If you can localize it to
just
one or a few subjects it would a lot easier to track down
On Fri, 23 Jan 2009, Siddharth Srivastava wrote:Hi Bruce,These are about 28 images. I have not tried fewer...do youthink thereare some images with incorrect orientation in the cohort?That
wouldshowupin the other location in the average i think...sid.On Fri, Jan 23, 2009 at 8:46 AM, Bruce Fischl <fischl@nmr.mgh.harvard.eduwrote:I don't think so. How many subjects? Have you triedfewer?
On Fri, 23 Jan 2009, Siddharth Srivastava wrote:The surfaces look all right. It happens only to T1.It cant be a
displayproblem, can it??sid.On Fri, Jan 23, 2009 at 5:58 AM, BruceFischl <
fischl@nmr.mgh.harvard.eduwrote:that is strange. Do the surfaceslook ok? How many subjects are
youaveraging? Does this happen if you onlyaverage one or a few?
On Thu, 22 Jan 2009, SiddharthSrivastava wrote:
Hi everyone,I am attaching a tiff file showingthe tkmedit view
ofthe averageT1 that freesurfer createdduring make_average_subject. I am a
bitconcernedabout the cropping that isevident at the posterior aspect of
thebrain.Theindividual T1's are completeand ok, so i am guessing that
somethingwentwrong during the transformof the individual brain during the
process.Cananyone help me find out theproblem ? The average surfaces also
lookallright.thanks,sid.
Freesurfer mailing list Freesurfer@nmr.mgh.harvard.edu https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
Hi Nick, Bruce, Just wondering if you were able to find something out regarding the cropping... thanks, sid.
On Mon, Jan 26, 2009 at 11:16 AM, Siddharth Srivastava siddys@gmail.comwrote:
just a correction: cropping happens when orig.mgz is operated by mri_convert to give orig-RO8NormVC .. (not on 001.mgz as mentioned earlier) sid.
On Mon, Jan 26, 2009 at 10:57 AM, Siddharth Srivastava siddys@gmail.comwrote:
Hi Nick, Thanks for looking into this. I am pasting the dump of mri_info on the files:
- mri_info orig/oo1.mgz
Volume information for 001.mgz type: MGH dimensions: 256 x 256 x 160 voxel sizes: 1.0000, 1.0000, 1.0000 type: SHORT (4) fov: 256.000 dof: 0 xstart: -128.0, xend: 128.0 ystart: -128.0, yend: 128.0 zstart: -80.0, zend: 80.0 TR: 1820.00 msec, TE: 2.93 msec, TI: 1100.00 msec, flip angle: 12.00 degrees nframes: 1 ras xform present xform info: x_r = -0.9981, y_r = -0.0000, z_r = -0.0618, c_r = -1.9246 : x_a = 0.0098, y_a = -0.9874, z_a = -0.1581, c_a = 50.0265 : x_s = -0.0610, y_s = -0.1584, z_s = 0.9855, c_s = 48.4401
talairach xfm : Orientation : LPS Primary Slice Direction: axial
voxel to ras transform: -0.9981 -0.0000 -0.0618 130.7745 0.0098 -0.9874 -0.1581 187.8058 -0.0610 -0.1584 0.9855 -2.3123 0.0000 0.0000 0.0000 1.0000
voxel-to-ras determinant 1
ras to voxel transform: -0.9981 0.0098 -0.0610 128.5450 -0.0000 -0.9874 -0.1584 185.0682 -0.0618 -0.1581 0.9855 40.0535 0.0000 0.0000 0.0000 1.0000
- mri_info on orig.mgz
Volume information for orig.mgz type: MGH dimensions: 256 x 256 x 256 voxel sizes: 1.0000, 1.0000, 1.0000 type: UCHAR (0) fov: 256.000 dof: 0 xstart: -128.0, xend: 128.0 ystart: -128.0, yend: 128.0 zstart: -128.0, zend: 128.0 TR: 1820.00 msec, TE: 2.93 msec, TI: 1100.00 msec, flip angle: 12.00 degrees nframes: 1 ras xform present xform info: x_r = -1.0000, y_r = 0.0000, z_r = -0.0000, c_r = -1.9246 : x_a = 0.0000, y_a = 0.0000, z_a = 1.0000, c_a = 50.0265 : x_s = 0.0000, y_s = -1.0000, z_s = -0.0000, c_s = 48.4401
talairach xfm : /share/data0/ssrivastava/processed/RO28NormVC/mri/transforms/talairach.xfm Orientation : LIA Primary Slice Direction: coronal
voxel to ras transform: -1.0000 0.0000 -0.0000 126.0754 0.0000 0.0000 1.0000 -77.9735 0.0000 -1.0000 -0.0000 176.4401 0.0000 0.0000 0.0000 1.0000
voxel-to-ras determinant -1
ras to voxel transform: -1.0000 -0.0000 0.0000 126.0754 -0.0000 -0.0000 -1.0000 176.4401 -0.0000 1.0000 -0.0000 77.9735 0.0000 0.0000 0.0000 1.0000
The fov in both cases is 256. Can i just mention (again), that this happens only during "make_average_volumes" when the orig/001.mgz passes through mri_convert. regards, sid.
On Mon, Jan 26, 2009 at 10:43 AM, Nick Schmansky < nicks@nmr.mgh.harvard.edu> wrote:
Sid,
What is the field-of-view size? Use:
mri_info orig.mgz
and look for the 'fov' output. It should be 256. What is the fov of the input files in subj/mri/orig? If it is greater than 256, that might be the problem, but the cropping problem we have seen with that occurs during the original recons, not during make_average_subject. If it is
256, then the -cropsize256 flag should be added to recon-all.
Nick
On Sat, 2009-01-24 at 15:21 -0800, Siddharth Srivastava wrote:
Hi bruce, This happens for every orig.mgz that passes through mri_convert at the start of make_average_volumes. The files are 9M each, is there a drop-area where i can upload them? I just made some checks: my orig/001.mgz files are LPS (primary-
axial), while
the converted files are LIA (coronal). Can this effect the result? In any case, if you send me the link to the drop area, i will put an example mgz. thanks, sid.
On Sat, Jan 24, 2009 at 12:40 PM, Bruce Fischl fischl@nmr.mgh.harvard.edu wrote: Hi Sid,
can you send us the volume that has this happen? I think it's just a display problem and won't affect anything else, but if you give us the example we'll fix it. Bruce On Sat, 24 Jan 2009, Siddharth Srivastava wrote: Hi everyone, Has anyone faced this problem before? Is there an alternative to mri_convert than i can try to get the transformation, and then run the subsequent steps? Why are k_ras components approaching zero, and not exactly zero. make_average_surface works fine, no clipping, i have spent the last 20 or so odd hours checking each surf directory. This happens only for the structurals that pass through mri_convert. Tried changing the -oc values, there is a shift, as expected, but the clipping remains fixed at this level (hence more brain gets cropped if the -oc values shift the brain posteriorly. sid. On Fri, Jan 23, 2009 at 11:37 AM, Siddharth Srivastava <siddys@gmail.com>wrote: Hi bruce, I think the offending command is mri_convert /../../orig.mgz /../../orig- subject.mgh --apply_transform /../../mri/transforms/talairach.xfm -oc 0 0 0 I am attaching the pre- and post mri_convert as tiffs. I have also attached the pial_avg surface in the posterior view, for you comments. The folowing is the screen dump (patient name deleted):
$Id: mri_convert.c,v 1.146.2.3 2008/08/11 22:18:58 nicks Exp $ reading from /../subject/mri/orig.mgz... TR=1820.00, TE=2.93, TI=1100.00, flip angle=12.00 i_ras = (-1, 0, 0) j_ras = (0, 0, -1) k_ras = (-9.31323e-10, 1, -1.49012e-08) INFO: Applying transformation from file /../subject/mri/transforms/talairach.xfm... Reading transform with LTAreadEx() --------------------------------- INFO: Transform Matrix (linear_ras_to_ras) 1.026 0.084 0.079 -9.471; -0.105 1.048 0.228 -84.640; -0.106 -0.174 1.165 -38.874; 0.000 0.000 0.000 1.000; --------------------------------- Applying LTAtransformInterp (resample_type 1) INFO: Transform dst volume info is not used (valid flag = 0). applying the vox to vox linear transform 1.026 0.079 -0.084 -1.205; -0.106 1.165 0.174 9.576; 0.105 -0.228 1.048 -61.401; 0.000 0.000 0.000 1.000; writing to /../../orig-subject.mgh...
does this help in any way? thanks, sid. On Fri, Jan 23, 2009 at 11:01 AM, Bruce Fischl <fischl@nmr.mgh.harvard.edu wrote: Hi Sid, have you looked through the individual datasets? That's where the cropping would be, which would have caused big errors in your surfaces. I assume that is not the case. Bruce On Fri, 23 Jan 2009, Siddharth Srivastava wrote: Hi Bruce, I just realised that the cropping at the posterior aspect is similar to the cropping usually done for the inferior aspect in a saggital view (to get rid of the neck etc..) . Could it be (remotely) possible that the cropping was done in a different orientation (nose pointing up in the sagittal view), and then oriented to the views that we see now? I have only used the basic commands "make_average_subject" with no special flags except --force sid. On Fri, Jan 23, 2009 at 10:33 AM, Bruce Fischl <fischl@nmr.mgh.harvard.eduwrote:
I'm not really sure. Doug or Nick: any ideas? On Fri, 23 Jan 2009, Siddharth Srivastava wrote: Hi Bruce, please find attached a tiff file generated by mri_concat --mean on the original mprages. Here i can see the full view, and i think no registration has been performed as yet on these images... Regarding exploring the dataset for 1 image, is it possible that just 1 rouge image can cause this problem? The clipping has a sharp border, almost as if the bounding box itself has been cropped at that level. the intensity in these posterior slices is zero. thanks, sid. On Fri, Jan 23, 2009 at 9:51 AM, Bruce Fischl <fischl@nmr.mgh.harvard.edu
wrote: if you can find a small set (1?) of subjects that generate the same image, then maybe you can just send us that subjectand your commandline
On Fri, 23 Jan 2009,Siddharth Srivastava wrote:
ok.. i will try that and let you know...what other image/logs can i
provide
for
localizing the source of the error?
sid.
On Fri, Jan 23, 2009 at 9:04 AM, Bruce Fischl <
fischl@nmr.mgh.harvard.edu
wrote:
not really, it seems like there is a bug. If you can localize it to
just
one or a few subjects it would a lot easier to track down
On Fri, 23 Jan 2009, Siddharth Srivastava wrote:Hi Bruce,These are about 28 images. I have not tried fewer...do youthink thereare some images with incorrect orientation in the cohort?That
wouldshowupin the other location in the average i think...sid.On Fri, Jan 23, 2009 at 8:46 AM, Bruce Fischl <fischl@nmr.mgh.harvard.eduwrote:I don't think so. How many subjects? Have you triedfewer?
On Fri, 23 Jan 2009, Siddharth Srivastava wrote:The surfaces look all right. It happens only to T1.It cant be a
displayproblem, can it??sid.On Fri, Jan 23, 2009 at 5:58 AM, BruceFischl <
fischl@nmr.mgh.harvard.eduwrote:that is strange. Do the surfaceslook ok? How many subjects are
youaveraging? Does this happen if you onlyaverage one or a few?
On Thu, 22 Jan 2009, SiddharthSrivastava wrote:
Hi everyone,I am attaching a tiff file showingthe tkmedit view
ofthe averageT1 that freesurfer createdduring make_average_subject. I am a
bitconcernedabout the cropping that isevident at the posterior aspect of
thebrain.Theindividual T1's are completeand ok, so i am guessing that
somethingwentwrong during the transformof the individual brain during the
process.Cananyone help me find out theproblem ? The average surfaces also
lookallright.thanks,sid.
Freesurfer mailing list Freesurfer@nmr.mgh.harvard.edu https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
Hi Nick, Bruce, Can you atleast suggest an alternative to get the average volumes, that can be used for some VBM in freesurfer. My work is kinda stuck because of this error... Or maybe a word or 2 about the progress on this front? sid.
On Tue, Jan 27, 2009 at 1:44 PM, Siddharth Srivastava siddys@gmail.comwrote:
Hi Nick, Bruce, Just wondering if you were able to find something out regarding the cropping... thanks, sid.
On Mon, Jan 26, 2009 at 11:16 AM, Siddharth Srivastava siddys@gmail.comwrote:
just a correction: cropping happens when orig.mgz is operated by mri_convert to give orig-RO8NormVC .. (not on 001.mgz as mentioned earlier) sid.
On Mon, Jan 26, 2009 at 10:57 AM, Siddharth Srivastava siddys@gmail.comwrote:
Hi Nick, Thanks for looking into this. I am pasting the dump of mri_info on the files:
- mri_info orig/oo1.mgz
Volume information for 001.mgz type: MGH dimensions: 256 x 256 x 160 voxel sizes: 1.0000, 1.0000, 1.0000 type: SHORT (4) fov: 256.000 dof: 0 xstart: -128.0, xend: 128.0 ystart: -128.0, yend: 128.0 zstart: -80.0, zend: 80.0 TR: 1820.00 msec, TE: 2.93 msec, TI: 1100.00 msec, flip angle: 12.00 degrees nframes: 1 ras xform present xform info: x_r = -0.9981, y_r = -0.0000, z_r = -0.0618, c_r = -1.9246 : x_a = 0.0098, y_a = -0.9874, z_a = -0.1581, c_a = 50.0265 : x_s = -0.0610, y_s = -0.1584, z_s = 0.9855, c_s = 48.4401
talairach xfm : Orientation : LPS Primary Slice Direction: axial
voxel to ras transform: -0.9981 -0.0000 -0.0618 130.7745 0.0098 -0.9874 -0.1581 187.8058 -0.0610 -0.1584 0.9855 -2.3123 0.0000 0.0000 0.0000 1.0000
voxel-to-ras determinant 1
ras to voxel transform: -0.9981 0.0098 -0.0610 128.5450 -0.0000 -0.9874 -0.1584 185.0682 -0.0618 -0.1581 0.9855 40.0535 0.0000 0.0000 0.0000 1.0000
- mri_info on orig.mgz
Volume information for orig.mgz type: MGH dimensions: 256 x 256 x 256 voxel sizes: 1.0000, 1.0000, 1.0000 type: UCHAR (0) fov: 256.000 dof: 0 xstart: -128.0, xend: 128.0 ystart: -128.0, yend: 128.0 zstart: -128.0, zend: 128.0 TR: 1820.00 msec, TE: 2.93 msec, TI: 1100.00 msec, flip angle: 12.00 degrees nframes: 1 ras xform present xform info: x_r = -1.0000, y_r = 0.0000, z_r = -0.0000, c_r = -1.9246 : x_a = 0.0000, y_a = 0.0000, z_a = 1.0000, c_a = 50.0265 : x_s = 0.0000, y_s = -1.0000, z_s = -0.0000, c_s = 48.4401
talairach xfm : /share/data0/ssrivastava/processed/RO28NormVC/mri/transforms/talairach.xfm Orientation : LIA Primary Slice Direction: coronal
voxel to ras transform: -1.0000 0.0000 -0.0000 126.0754 0.0000 0.0000 1.0000 -77.9735 0.0000 -1.0000 -0.0000 176.4401 0.0000 0.0000 0.0000 1.0000
voxel-to-ras determinant -1
ras to voxel transform: -1.0000 -0.0000 0.0000 126.0754 -0.0000 -0.0000 -1.0000 176.4401 -0.0000 1.0000 -0.0000 77.9735 0.0000 0.0000 0.0000 1.0000
The fov in both cases is 256. Can i just mention (again), that this happens only during "make_average_volumes" when the orig/001.mgz passes through mri_convert. regards, sid.
On Mon, Jan 26, 2009 at 10:43 AM, Nick Schmansky < nicks@nmr.mgh.harvard.edu> wrote:
Sid,
What is the field-of-view size? Use:
mri_info orig.mgz
and look for the 'fov' output. It should be 256. What is the fov of the input files in subj/mri/orig? If it is greater than 256, that might be the problem, but the cropping problem we have seen with that occurs during the original recons, not during make_average_subject. If it is
256, then the -cropsize256 flag should be added to recon-all.
Nick
On Sat, 2009-01-24 at 15:21 -0800, Siddharth Srivastava wrote:
Hi bruce, This happens for every orig.mgz that passes through mri_convert at the start of make_average_volumes. The files are 9M each, is there a drop-area where i can upload them? I just made some checks: my orig/001.mgz files are LPS (primary-
axial), while
the converted files are LIA (coronal). Can this effect the result? In any case, if you send me the link to the drop area, i will put an example mgz. thanks, sid.
On Sat, Jan 24, 2009 at 12:40 PM, Bruce Fischl fischl@nmr.mgh.harvard.edu wrote: Hi Sid,
can you send us the volume that has this happen? I think it's just a display problem and won't affect anything else, but if you give us the example we'll fix it. Bruce On Sat, 24 Jan 2009, Siddharth Srivastava wrote: Hi everyone, Has anyone faced this problem before? Is there an alternative to mri_convert than i can try to get the transformation, and then run the subsequent steps? Why are k_ras components approaching zero, and not exactly zero. make_average_surface works fine, no clipping, i have spent the last 20 or so odd hours checking each surf directory. This happens only for the structurals that pass through mri_convert. Tried changing the -oc values, there is a shift, as expected, but the clipping remains fixed at this level (hence more brain gets cropped if the -oc values shift the brain posteriorly. sid. On Fri, Jan 23, 2009 at 11:37 AM, Siddharth Srivastava <siddys@gmail.com>wrote: Hi bruce, I think the offending command is mri_convert /../../orig.mgz /../../orig- subject.mgh --apply_transform /../../mri/transforms/talairach.xfm -oc 0 0 0 I am attaching the pre- and post mri_convert as tiffs. I have also attached the pial_avg surface in the posterior view, for you comments. The folowing is the screen dump (patient name deleted):
$Id: mri_convert.c,v 1.146.2.3 2008/08/11 22:18:58 nicks Exp $ reading from /../subject/mri/orig.mgz... TR=1820.00, TE=2.93, TI=1100.00, flip angle=12.00 i_ras = (-1, 0, 0) j_ras = (0, 0, -1) k_ras = (-9.31323e-10, 1, -1.49012e-08) INFO: Applying transformation from file /../subject/mri/transforms/talairach.xfm... Reading transform with LTAreadEx() --------------------------------- INFO: Transform Matrix (linear_ras_to_ras) 1.026 0.084 0.079 -9.471; -0.105 1.048 0.228 -84.640; -0.106 -0.174 1.165 -38.874; 0.000 0.000 0.000 1.000; --------------------------------- Applying LTAtransformInterp (resample_type 1) INFO: Transform dst volume info is not used (valid flag = 0). applying the vox to vox linear transform 1.026 0.079 -0.084 -1.205; -0.106 1.165 0.174 9.576; 0.105 -0.228 1.048 -61.401; 0.000 0.000 0.000 1.000; writing to /../../orig-subject.mgh...
does this help in any way? thanks, sid. On Fri, Jan 23, 2009 at 11:01 AM, Bruce Fischl <fischl@nmr.mgh.harvard.edu wrote: Hi Sid, have you looked through the individual datasets? That's where the cropping would be, which would have caused big errors in your surfaces. I assume that is not the case. Bruce On Fri, 23 Jan 2009, Siddharth Srivastava wrote: Hi Bruce, I just realised that the cropping at the posterior aspect is similar to the cropping usually done for the inferior aspect in a saggital view (to get rid of the neck etc..) . Could it be (remotely) possible that the cropping was done in a different orientation (nose pointing up in the sagittal view), and then oriented to the views that we see now? I have only used the basic commands "make_average_subject" with no special flags except --force sid. On Fri, Jan 23, 2009 at 10:33 AM, Bruce Fischl <fischl@nmr.mgh.harvard.eduwrote:
I'm not really sure. Doug or Nick: any ideas? On Fri, 23 Jan 2009, Siddharth Srivastava wrote: Hi Bruce, please find attached a tiff file generated by mri_concat --mean on the original mprages. Here i can see the full view, and i think no registration has been performed as yet on these images... Regarding exploring the dataset for 1 image, is it possible that just 1 rouge image can cause this problem? The clipping has a sharp border, almost as if the bounding box itself has been cropped at that level. the intensity in these posterior slices is zero. thanks, sid. On Fri, Jan 23, 2009 at 9:51 AM, Bruce Fischl <fischl@nmr.mgh.harvard.edu
wrote: if you can find a small set (1?) of subjects that generate the same image, then maybe you can just send us thatsubject and your commandline
On Fri, 23 Jan 2009,Siddharth Srivastava wrote:
ok.. i will try that and let youknow... what other image/logs can i
provide
for
localizing the source of the error?
sid.
On Fri, Jan 23, 2009 at 9:04 AM, Bruce Fischl <
fischl@nmr.mgh.harvard.edu
wrote:
not really, it seems like there is a bug. If you can localize it to
just
one or a few subjects it would a lot easier to track down
On Fri, 23 Jan 2009, Siddharth Srivastava wrote:Hi Bruce,These are about 28 images. I have not tried fewer...do youthink thereare some images with incorrect orientation in the cohort?That
wouldshowupin the other location in the average i think...sid.On Fri, Jan 23, 2009 at 8:46 AM, Bruce Fischl <fischl@nmr.mgh.harvard.eduwrote:I don't think so. How many subjects? Have youtried fewer?
On Fri, 23 Jan 2009, Siddharth Srivastava wrote:The surfaces look all right. It happens only toT1. It cant be a
displayproblem, can it??sid.On Fri, Jan 23, 2009 at 5:58 AM, BruceFischl <
fischl@nmr.mgh.harvard.eduwrote:that is strange. Do the surfaceslook ok? How many subjects are
youaveraging? Does this happen if you onlyaverage one or a few?
On Thu, 22 Jan 2009, SiddharthSrivastava wrote:
Hi everyone,I am attaching a tiff file showingthe tkmedit view
ofthe averageT1 that freesurfer createdduring make_average_subject. I am a
bitconcernedabout the cropping that isevident at the posterior aspect of
thebrain.Theindividual T1's arecomplete and ok, so i am guessing that
somethingwentwrong during the transformof the individual brain during the
process.Cananyone help me find outthe problem ? The average surfaces also
lookallright.thanks,sid.
Freesurfer mailing list Freesurfer@nmr.mgh.harvard.edu https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
Hi Sid,
we have the data and can replicate the bug. It's high on our priority list.
Bruce
On Tue, 27 Jan 2009, Siddharth Srivastava wrote:
Hi Nick, Bruce, Can you atleast suggest an alternative to get the average volumes, that can be used for some VBM in freesurfer. My work is kinda stuck because of this error... Or maybe a word or 2 about the progress on this front? sid.
On Tue, Jan 27, 2009 at 1:44 PM, Siddharth Srivastava siddys@gmail.comwrote:
Hi Nick, Bruce, Just wondering if you were able to find something out regarding the cropping... thanks, sid.
On Mon, Jan 26, 2009 at 11:16 AM, Siddharth Srivastava siddys@gmail.comwrote:
just a correction: cropping happens when orig.mgz is operated by mri_convert to give orig-RO8NormVC .. (not on 001.mgz as mentioned earlier) sid.
On Mon, Jan 26, 2009 at 10:57 AM, Siddharth Srivastava siddys@gmail.comwrote:
Hi Nick, Thanks for looking into this. I am pasting the dump of mri_info on the files:
- mri_info orig/oo1.mgz
Volume information for 001.mgz type: MGH dimensions: 256 x 256 x 160 voxel sizes: 1.0000, 1.0000, 1.0000 type: SHORT (4) fov: 256.000 dof: 0 xstart: -128.0, xend: 128.0 ystart: -128.0, yend: 128.0 zstart: -80.0, zend: 80.0 TR: 1820.00 msec, TE: 2.93 msec, TI: 1100.00 msec, flip angle: 12.00 degrees nframes: 1 ras xform present xform info: x_r = -0.9981, y_r = -0.0000, z_r = -0.0618, c_r = -1.9246 : x_a = 0.0098, y_a = -0.9874, z_a = -0.1581, c_a = 50.0265 : x_s = -0.0610, y_s = -0.1584, z_s = 0.9855, c_s = 48.4401
talairach xfm : Orientation : LPS Primary Slice Direction: axial
voxel to ras transform: -0.9981 -0.0000 -0.0618 130.7745 0.0098 -0.9874 -0.1581 187.8058 -0.0610 -0.1584 0.9855 -2.3123 0.0000 0.0000 0.0000 1.0000
voxel-to-ras determinant 1
ras to voxel transform: -0.9981 0.0098 -0.0610 128.5450 -0.0000 -0.9874 -0.1584 185.0682 -0.0618 -0.1581 0.9855 40.0535 0.0000 0.0000 0.0000 1.0000
- mri_info on orig.mgz
Volume information for orig.mgz type: MGH dimensions: 256 x 256 x 256 voxel sizes: 1.0000, 1.0000, 1.0000 type: UCHAR (0) fov: 256.000 dof: 0 xstart: -128.0, xend: 128.0 ystart: -128.0, yend: 128.0 zstart: -128.0, zend: 128.0 TR: 1820.00 msec, TE: 2.93 msec, TI: 1100.00 msec, flip angle: 12.00 degrees nframes: 1 ras xform present xform info: x_r = -1.0000, y_r = 0.0000, z_r = -0.0000, c_r = -1.9246 : x_a = 0.0000, y_a = 0.0000, z_a = 1.0000, c_a = 50.0265 : x_s = 0.0000, y_s = -1.0000, z_s = -0.0000, c_s = 48.4401
talairach xfm : /share/data0/ssrivastava/processed/RO28NormVC/mri/transforms/talairach.xfm Orientation : LIA Primary Slice Direction: coronal
voxel to ras transform: -1.0000 0.0000 -0.0000 126.0754 0.0000 0.0000 1.0000 -77.9735 0.0000 -1.0000 -0.0000 176.4401 0.0000 0.0000 0.0000 1.0000
voxel-to-ras determinant -1
ras to voxel transform: -1.0000 -0.0000 0.0000 126.0754 -0.0000 -0.0000 -1.0000 176.4401 -0.0000 1.0000 -0.0000 77.9735 0.0000 0.0000 0.0000 1.0000
The fov in both cases is 256. Can i just mention (again), that this happens only during "make_average_volumes" when the orig/001.mgz passes through mri_convert. regards, sid.
On Mon, Jan 26, 2009 at 10:43 AM, Nick Schmansky < nicks@nmr.mgh.harvard.edu> wrote:
Sid,
What is the field-of-view size? Use:
mri_info orig.mgz
and look for the 'fov' output. It should be 256. What is the fov of the input files in subj/mri/orig? If it is greater than 256, that might be the problem, but the cropping problem we have seen with that occurs during the original recons, not during make_average_subject. If it is
256, then the -cropsize256 flag should be added to recon-all.
Nick
On Sat, 2009-01-24 at 15:21 -0800, Siddharth Srivastava wrote:
Hi bruce, This happens for every orig.mgz that passes through mri_convert at the start of make_average_volumes. The files are 9M each, is there a drop-area where i can upload them? I just made some checks: my orig/001.mgz files are LPS (primary- > axial), while the converted files are LIA (coronal). Can this effect the result? In any case, if you send me the link to the drop area, i will put an example mgz. thanks, sid.
On Sat, Jan 24, 2009 at 12:40 PM, Bruce Fischl fischl@nmr.mgh.harvard.edu wrote: Hi Sid,
can you send us the volume that has this happen? I think it's just a display problem and won't affect anything else, but if you give us the example we'll fix it. Bruce On Sat, 24 Jan 2009, Siddharth Srivastava wrote: Hi everyone, Has anyone faced this problem before? Is there an alternative to mri_convert than i can try to get the transformation, and then run the subsequent steps? Why are k_ras components approaching zero, and not exactly zero. make_average_surface works fine, no clipping, i have spent the last 20 or so odd hours checking each surf directory. This happens only for the structurals that pass through mri_convert. Tried changing the -oc values, there is a shift, as expected, but the clipping remains fixed at this level (hence more brain gets cropped if the -oc values shift the brain posteriorly. sid. On Fri, Jan 23, 2009 at 11:37 AM, Siddharth Srivastava <siddys@gmail.com>wrote: Hi bruce, I think the offending command is mri_convert /../../orig.mgz /../../orig- subject.mgh --apply_transform /../../mri/transforms/talairach.xfm -oc 0 0 0 I am attaching the pre- and post mri_convert as tiffs. I have also attached the pial_avg surface in the posterior view, for you comments. The folowing is the screen dump (patient name deleted):
$Id: mri_convert.c,v 1.146.2.3 2008/08/11 22:18:58 nicks Exp $ reading from /../subject/mri/orig.mgz... TR=1820.00, TE=2.93, TI=1100.00, flip angle=12.00 i_ras = (-1, 0, 0) j_ras = (0, 0, -1) k_ras = (-9.31323e-10, 1, -1.49012e-08) INFO: Applying transformation from file /../subject/mri/transforms/talairach.xfm... Reading transform with LTAreadEx() --------------------------------- INFO: Transform Matrix (linear_ras_to_ras) 1.026 0.084 0.079 -9.471; -0.105 1.048 0.228 -84.640; -0.106 -0.174 1.165 -38.874; 0.000 0.000 0.000 1.000; --------------------------------- Applying LTAtransformInterp (resample_type 1) INFO: Transform dst volume info is not used (valid flag = 0). applying the vox to vox linear transform 1.026 0.079 -0.084 -1.205; -0.106 1.165 0.174 9.576; 0.105 -0.228 1.048 -61.401; 0.000 0.000 0.000 1.000; writing to /../../orig-subject.mgh...
does this help in any way? thanks, sid. On Fri, Jan 23, 2009 at 11:01 AM, Bruce Fischl <fischl@nmr.mgh.harvard.edu wrote: Hi Sid, have you looked through the individual datasets? That's where the cropping would be, which would have caused big errors in your surfaces. I assume that is not the case. Bruce On Fri, 23 Jan 2009, Siddharth Srivastava wrote: Hi Bruce, I just realised that the cropping at the posterior aspect is similar to the cropping usually done for the inferior aspect in a saggital view (to get rid of the neck etc..) . Could it be (remotely) possible that the cropping was done in a different orientation (nose pointing up in the sagittal view), and then oriented to the views that we see now? I have only used the basic commands "make_average_subject" with no special flags except --force sid. On Fri, Jan 23, 2009 at 10:33 AM, Bruce Fischl <fischl@nmr.mgh.harvard.eduwrote:
I'm not really sure. Doug or Nick: any ideas? On Fri, 23 Jan 2009, Siddharth Srivastava wrote: Hi Bruce, please find attached a tiff file generated by mri_concat --mean on the original mprages. Here i can see the full view, and i think no registration has been performed as yet on these images... Regarding exploring the dataset for 1 image, is it possible that just 1 rouge image can cause this problem? The clipping has a sharp border, almost as if the bounding box itself has been cropped at that level. the intensity in these posterior slices is zero. thanks, sid. On Fri, Jan 23, 2009 at 9:51 AM, Bruce Fischl <fischl@nmr.mgh.harvard.edu
wrote: if you can find a small set (1?) of subjects that generate the same image, then maybe you can just send us thatsubject and your commandline
On Fri, 23 Jan 2009,Siddharth Srivastava wrote:
ok.. i will try that and let youknow... what other image/logs can i
provide
for
localizing the source of the error?
sid.
On Fri, Jan 23, 2009 at 9:04 AM, Bruce Fischl <
fischl@nmr.mgh.harvard.edu
wrote:
not really, it seems like there is a bug. If you can localize it to
just
one or a few subjects it would a lot easier to track down
On Fri, 23 Jan 2009, Siddharth Srivastava wrote:Hi Bruce,These are about 28 images. I have not tried fewer...do youthink thereare some images with incorrect orientation in the cohort?That
wouldshowupin the other location in the average i think...sid.On Fri, Jan 23, 2009 at 8:46 AM, Bruce Fischl <fischl@nmr.mgh.harvard.eduwrote:I don't think so. How many subjects? Have youtried fewer?
On Fri, 23 Jan 2009, Siddharth Srivastava wrote:The surfaces look all right. It happens only toT1. It cant be a
displayproblem, can it??sid.On Fri, Jan 23, 2009 at 5:58 AM, BruceFischl <
fischl@nmr.mgh.harvard.eduwrote:that is strange. Do the surfaceslook ok? How many subjects are
youaveraging? Does this happen if you onlyaverage one or a few?
On Thu, 22 Jan 2009, SiddharthSrivastava wrote:
Hi everyone,I am attaching a tiff file showingthe tkmedit view
ofthe averageT1 that freesurfer createdduring make_average_subject. I am a
bitconcernedabout the cropping that isevident at the posterior aspect of
thebrain.Theindividual T1's arecomplete and ok, so i am guessing that
somethingwentwrong during the transformof the individual brain during the
process.Cananyone help me find outthe problem ? The average surfaces also
lookallright.thanks,sid.
Freesurfer mailing list Freesurfer@nmr.mgh.harvard.edu https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
freesurfer@nmr.mgh.harvard.edu
-
Bruce Fischl -
Nick Schmansky -
Siddharth Srivastava