Freesurfer January 2009

freesurfer@nmr.mgh.harvard.edu

72 participants
137 discussions

sulc & curv
by Juranek, Jenifer 29 Jan '09

29 Jan '09

Rudolph, many thanks for the additional details. Just a follow-up question (or two): 1. Short stubby gyri might have the following morphometric properties? a) Short feature: shallow sulcal depths would be expected to have sulc values hovering around the mean surface (e.g. around 0) in negative curvature areas b) Stubby feature: increased GM volume, increased surface area, and perhaps increased cortical thickness depending on how the WM behaved Thanks so much, Jenifer

1 0

Graphical problems or more
by Jürgen Hänggi 29 Jan '09

29 Jan '09

Dear FS experts We parcellated the aparc.a2005s of fsaverage into parcellations of 300 mm^2 (attached file FinerParcells_fsaverage). When I overlaid this new parcellations on a single subject, there seems to be something wrong (attached file FinerParcells_individual). Because I use this new finer parcellations with the command mris_anatomical_stats to get cortical thickness of these finer parcellations across subjects, I am wondering whether there is only a graphical problem. When I have a look at the resulted thickness values and the reported number and names of parcellations, everything seems to be OK. Any ideas? I use FS 4.2.0 Mac Intel. Thanks in advance Regards Jürgen ---------------------------------------------------------- Juergen Haenggi Ph.D. (Dr. des.) Division Neuropsychology Institute of Psychology University of Zurich Binzmuehlestrasse 14, PO Box 25 8050 Zurich, Switzerland 0041 44 635 73 97 (phone office) 0041 76 445 86 84 (phone mobile) 0041 44 635 74 09 (fax office) BIN 4.D.04 (office room number) j.haenggi[at]psychologie.uzh.ch (email) http://www.psychologie.uzh.ch/neuropsy/ (website) http://www.juergenhaenggi.ch (private website) ----------------------------------------------------------

2 1

Re: [Freesurfer] --fsgd file
by Siddharth Srivastava 29 Jan '09

29 Jan '09

Hi Jurgen, Thanks for the response. Seems like a feasible idea. I can do it for my "Normals", but the atypicals have a large variability in the measure. And only the atypicals have missing data. Thanks for the idea though... sid. On Thu, Jan 29, 2009 at 11:02 AM, Jürgen Hänggi < j.haenggi(a)psychologie.uzh.ch> wrote: > Hi Siddharth > > If there are not too many missing values, you can fill the missing values > by the mean of the values you have and hope that the subjects who completed > all tasks did not systematically deviate from the subjects who did not > complete the tasks. > > Regards > Jürgen > > > > On 28.1.2009 20:46 Uhr, "Siddharth Srivastava" <siddys(a)gmail.com> wrote: > > Hi everyone, > I was wondering if it is possible to flag missing > entries in > the covariates corresponding to subjects, in the construction of the file > passed > through --fsgd to mri_glmfit ? Not all my subjects completed all the > tasks, > and i need to code them in the file, somehow. > thanks, > sid. > > ------------------------------ > _______________________________________________ > Freesurfer mailing list > Freesurfer(a)nmr.mgh.harvard.edu > https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer > > > > > ---------------------------------------------------------- > Juergen Haenggi > Ph.D. (Dr. des.) > Division Neuropsychology > Institute of Psychology > University of Zurich > Binzmuehlestrasse 14, PO Box 25 > 8050 Zurich, Switzerland > 0041 44 635 73 97 (phone office) > 0041 76 445 86 84 (phone mobile) > 0041 44 635 74 09 (fax office) > BIN 4.D.04 (office room number) > j.haenggi[at]psychologie.uzh.ch (email) > http://www.psychologie.uzh.ch/neuropsy/ (website) > http://www.juergenhaenggi.ch (private website) > ---------------------------------------------------------- > >

1 0

--fsgd file
by Siddharth Srivastava 29 Jan '09

29 Jan '09

Hi everyone, I was wondering if it is possible to flag missing entries in the covariates corresponding to subjects, in the construction of the file passed through --fsgd to mri_glmfit ? Not all my subjects completed all the tasks, and i need to code them in the file, somehow. thanks, sid.

2 1

using old GE data to run FSFAST
by Krishna Srihasam 29 Jan '09

29 Jan '09

Hi, I have some fMRI data which i collect from GE signa 3T machine. I have the data in two formats : (1) IMA format ( where each run is a directory like "000001.SER" and each such directory has separate files for each acquisition i.e. if I had 150 acquisitions, I have 150 .IMA files (2) I also have the above-mentioned data in nifti format exactly like before..Separate directories for each runs and separate files for each acquisition. Is there any command or way to convert these files into a format that I can use to do analysis with FSFAST. regards, Krishna

2 1

Calculate Corticol Thickness
by Jeff Sadino 28 Jan '09

28 Jan '09

Nevermind, I figured out my mistake. Thanks for your help! _________________________________________________________________ Windows Live™: E-mail. Chat. Share. Get more ways to connect. http://windowslive.com/explore?ocid=TXT_TAGLM_WL_t2_allup_explore_012009

1 0

Calculate corticol thickness
by Jeff Sadino 28 Jan '09

28 Jan '09

Hello all, Real basic question: How do I calculate the thickness of the cortex, preferably at each vertex/face? I have tried read_curv.m, but get this error: [thickness, f] = read_curv('lh.thickness') ??? Undefined function or method 'fread3' for input arguments of type 'double'. Error in ==> read_curv at 21 vnum = fread3(fid) ; This should be simple, but the discussion board starts one step after me I think :) Any help would be appreciate! Second, when I try to load it in freesurfer, I get an error: [FSuser@cluster ~]$ tksurfer 050080_S01 lh thickness surfer: current subjects dir: /share/apps/freesurfer/subjects surfer: not in "scripts" dir ==> using cwd for session root surfer: session root data dir ($session) set to: surfer: /export/home/FSuser Talairach transform /home/freesurfer/subjects/050080_S01/mri/transforms/talairach.xfm does not exist ... Loading tal xfm file /share/apps/freesurfer/subjects/050080_S01/mri/transforms/talairach.xfm surfer: Reading header info from /share/apps/freesurfer/subjects/050080_S01/mri/T1.mgz I tried loading the inflated first, then loading the thickness, which works, but the surface just turns all red. Are the minimum thicknesses maxing out my color map? This seems unlikely. Can anybody help me? [FSuser@cluster ~]$ tksurfer 050080_S01 lh inflated surfer: current subjects dir: /share/apps/freesurfer/subjects surfer: not in "scripts" dir ==> using cwd for session root surfer: session root data dir ($session) set to: surfer: /export/home/FSuser Talairach transform /home/freesurfer/subjects/050080_S01/mri/transforms/talairach.xfm does not exist ... Loading tal xfm file /share/apps/freesurfer/subjects/050080_S01/mri/transforms/talairach.xfm surfer: Reading header info from /share/apps/freesurfer/subjects/050080_S01/mri/T1.mgz surfer: vertices=144686, faces=289368 Talairach transform /home/freesurfer/subjects/050080_S01/mri/transforms/talairach.xfm does not exist ... Loading tal xfm file /share/apps/freesurfer/subjects/050080_S01/surf/../mri/transforms/talairach.xfm surfer: single buffered window libGL error: open DRM failed (Operation not permitted) libGL error: reverting to (slow) indirect rendering surfer: using interface /share/apps/freesurfer/lib/tcl/tksurfer.tcl Reading /share/apps/freesurfer/lib/tcl/tkm_common.tcl Reading /share/apps/freesurfer/lib/tcl/tkm_wrappers.tcl Reading /share/apps/freesurfer/lib/tcl/fsgdfPlot.tcl Reading /share/apps/freesurfer/lib/tcl/tkUtils.tcl Successfully parsed tksurfer.tcl (And then File -> Load Curvature -> lh.thickness) % surfer: curvature read: min=0.226951 max=5.000000 Thanks you very much, Jeff Sadino _________________________________________________________________ Windows Live™: E-mail. Chat. Share. Get more ways to connect. http://windowslive.com/explore?ocid=TXT_TAGLM_WL_t2_allup_explore_012009

1 0

qdec & ?h.sulc
by Juranek, Jenifer 28 Jan '09

28 Jan '09

Thanks for the slide, Nick. Just a follow-up question... So does the info in ?h.sulc contain sulcal depth information wrt the mean cortical surface? How does this differ from the positive values contained in the ?h.curv file? Sorry for the confusion, but the wiki suggests that they are different without going into how they differ. Any additional details are greatly appreciated. Thanks, Jenifer

2 1

Re: [Freesurfer] cropping of average T1
by Siddharth Srivastava 28 Jan '09

28 Jan '09

Hi Krish, It works!! Thanks for the usable binary. And thanks also to Bruce, Nick and everyone else who helped debug it. sid. On Wed, Jan 28, 2009 at 12:42 PM, Krish Subramaniam < krish(a)nmr.mgh.harvard.edu> wrote: > I've put the file here > > ftp://surfer.nmr.mgh.harvard.edu/transfer/outgoing/fsdev/krish/mri_convert > > Back up your old mri_convert to somethign like mri_convert.bak and put this > in your bin directory. If you could test it out and let me know it works.. > > Krish > > > > On Jan 28, 2009, at 3:20 PM, Siddharth Srivastava wrote: > > >> freesurfer-Linux-centos4_x86_64-stable-pub-v4.1.0 >> >> >> On Wed, Jan 28, 2009 at 12:12 PM, Krish Subramaniam < >> krish(a)nmr.mgh.harvard.edu> wrote: >> Hi Siddharth >> >> Looks like Bruce fixed the bug. Can you tell me your platform? The output >> of >> >> cat build-stamp.txt >> >> >> Krish >> >> On Jan 27, 2009, at 10:42 PM, 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(a)gmail.com> >> wrote: >> 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(a)gmail.com> >> wrote: >> 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(a)gmail.com> >> wrote: >> 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(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)nmr.mgh.harvard.edu >> > https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer >> >> >> >> >> >> _______________________________________________ >> Freesurfer mailing list >> Freesurfer(a)nmr.mgh.harvard.edu >> https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer >> >> >> _______________________________________________ >> Freesurfer mailing list >> Freesurfer(a)nmr.mgh.harvard.edu >> https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer >> > >

1 0

Re: [Freesurfer] cropping of average T1
by Siddharth Srivastava 28 Jan '09

28 Jan '09

freesurfer-Linux-centos4_x86_64-stable-pub-v4.1.0 On Wed, Jan 28, 2009 at 12:12 PM, Krish Subramaniam < krish(a)nmr.mgh.harvard.edu> wrote: > Hi Siddharth > > Looks like Bruce fixed the bug. Can you tell me your platform? The output > of > > cat build-stamp.txt > > Krish > > On Jan 27, 2009, at 10:42 PM, 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(a)gmail.com> >> wrote: >> 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(a)gmail.com> >> wrote: >> 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(a)gmail.com> >> wrote: >> 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(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)nmr.mgh.harvard.edu >> > https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer >> >> >> >> >> >> _______________________________________________ >> Freesurfer mailing list >> Freesurfer(a)nmr.mgh.harvard.edu >> https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer >> > >

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Freesurfer January 2009