[Freesurfer] freesurfer and debian "etch"
Dear all, does someone out there run freesurfer (freesurfer-Linux-rh9-dev20060210-full.tar.gz) under debian etch? Installation runs smoothly, however, when I test the freesurfer installation with medpc32:~$ tksurfer bert rh pial only a tiny fraction of Bert's brain is displayed. The GUI otherwise seems to work as I can rotate etc this brain fraction. I installed the same freesurfer version on a different computer running debian "sarge", which is the current stable distribution. - Here, I can see the whole brain! As suggested elsewhere I thus compared the shared library dependencies using medpc32:~$ ldd `which tkmedit` Here is what I got: # "etch"-machine: # medpc32:~$ ldd `which tkmedit` linux-gate.so.1 => (0xe000) libtix8.1.8.3.so => /local/opt/freesurfer_dev20060210/lib/tcltktixblt/lib/libtix8.1.8.3.so (0xb7fb) libtk8.4.so => /local/opt/freesurfer_dev20060210/lib/tcltktixblt/lib/libtk8.4.so (0xb7ef) libtcl8.4.so => /local/opt/freesurfer_dev20060210/lib/tcltktixblt/lib/libtcl8.4.so (0xb7e57000) libglut.so.3 => /usr/lib/libglut.so.3 (0xb7e0d000) libSM.so.6 => /usr/X11R6/lib/libSM.so.6 (0xb7e04000) libICE.so.6 => /usr/X11R6/lib/libICE.so.6 (0xb7dec000) libXmu.so.6 => /usr/X11R6/lib/libXmu.so.6 (0xb7dd6000) libXi.so.6 => /usr/X11R6/lib/libXi.so.6 (0xb7dce000) libGLU.so.1 => /usr/lib/libGLU.so.1 (0xb7d4f000) libGL.so.1 => /usr/lib/libGL.so.1 (0xb7ceb000) libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0xb7c2) libgsl.so.0 => /local/opt/freesurfer_dev20060210/lib/gsl/lib/libgsl.so.0 (0xb7acc000) libgslcblas.so.0 => /local/opt/freesurfer_dev20060210/lib/gsl/lib/libgslcblas.so.0 (0xb7a9c000) libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0xb7a7c000) libtiff.so.3 => /usr/lib/libtiff.so.3 (0xb7a2a000) libz.so.1 => /usr/lib/libz.so.1 (0xb7a15000) libm.so.6 => /lib/tls/libm.so.6 (0xb79ef000) libcrypt.so.1 => /lib/tls/libcrypt.so.1 (0xb79c1000) libc.so.6 => /lib/tls/libc.so.6 (0xb788a000) libdl.so.2 => /lib/tls/libdl.so.2 (0xb7886000) libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0xb7878000) libXt.so.6 => /usr/X11R6/lib/libXt.so.6 (0xb7827000) libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb774a000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb773f000) libpthread.so.0 => /lib/tls/libpthread.so.0 (0xb772d000) libXxf86vm.so.1 => /usr/X11R6/lib/libXxf86vm.so.1 (0xb7728000) /lib/ld-linux.so.2 (0xb7feb000) # "sarge" machine: # kogneuro-web:~$ ldd `which tkmedit` libtix8.1.8.3.so => /local/data/tools/freesurfer/lib/tcltktixblt/lib/libtix8.1.8.3.so (0xb7fae000) libtk8.4.so => /local/data/tools/freesurfer/lib/tcltktixblt/lib/libtk8.4.so (0xb7eee000) libtcl8.4.so => /local/data/tools/freesurfer/lib/tcltktixblt/lib/libtcl8.4.so (0xb7e55000) libglut.so.3 => /usr/lib/libglut.so.3 (0xb7e1b000) libSM.so.6 => /usr/X11R6/lib/libSM.so.6 (0xb7e12000) libICE.so.6 => /usr/X11R6/lib/libICE.so.6 (0xb7dfb000) libXmu.so.6 => /usr/X11R6/lib/libXmu.so.6 (0xb7de4000) libXi.so.6 => /usr/X11R6/lib/libXi.so.6 (0xb7ddc000) libGLU.so.1 => /usr/lib/libGLU.so.1 (0xb7d61000) libGL.so.1 => /usr/lib/libGL.so.1 (0xb7cf2000) libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0xb7c2b000) libgsl.so.0 => /local/data/tools/freesurfer/lib/gsl/lib/libgsl.so.0 (0xb7ad7000) libgslcblas.so.0 => /local/data/tools/freesurfer/lib/gsl/lib/libgslcblas.so.0 (0xb7aa6000) libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0xb7a88000) libtiff.so.3 => /usr/lib/libtiff.so.3 (0xb7a38000) libz.so.1 => /usr/lib/libz.so.1 (0xb7a26000) libm.so.6 => /lib/tls/libm.so.6 (0xb7a04000) libcrypt.so.1 => /lib/tls/libcrypt.so.1 (0xb79d7000) libc.so.6 => /lib/tls/libc.so.6 (0xb78a1000) libdl.so.2 => /lib/tls/libdl.so.2 (0xb789e000) libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0xb789) libXt.so.6 => /usr/X11R6/lib/libXt.so.6 (0xb783f000) libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0xb7785000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb7779000) libpthread.so.0 => /lib/tls/libpthread.so.0 (0xb776a000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0xb7fea000) The differences seem to be: # "etch" machine: # libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb774a000) libXxf86vm.so.1 => /usr/X11R6/lib/libXxf86vm.so.1 (0xb7728000) /lib/ld-linux.so.2 (0xb7feb000) # "sarge" machine: # libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0xb7785000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0xb7fea000) Does this mean that the c++ libraries on my etch-running machine are "too" new? Why is there no "=>" for /lib/ld-linux.so.2 on my etch-running machine? I would greatly appreciate any comments or ideas what else I could do. Many thanks
Re: [Freesurfer] problems with wm surface
is that the orig surface? Usually that's what is displayed in green (the white is in yellow). This kind of thing usually means an incorrectly fixed topological defect, so the best bet is to manually correct the defect. Bruce On Wed, 22 Feb 2006, Martin Ystad wrote: Hi, I've just installed the newest centos-dev version. I did a rerun on some of my subjects, and in one particular subject the white matter orig-surface didn't follow the white matter volume at the right hemisphere. It looks like the surface takes some 'shorcuts' passing through gyri and over sulci. This only happens in the right hemisphere, and it didn't happen in the previous version. (I've attached an image to illustrate) Do you have any idea what causes this, and if so, what I can do to fix it? Also, I'd like to know if the talairach-conversion has any significant impact on the final result, so that I should try to obtain the lowest 'Final objective function value' by applying the tecniques suggested in your tutorial. Thanks, Martin Ystad Medical Student University of Bergen Institute of Biomedicine Jonas Lies vei 91, 5009 Bergen, Norway. ___ Freesurfer mailing list Freesurfer@nmr.mgh.harvard.edu https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
[Freesurfer] Re: tcl script - rotate and save graphics (Darren Weber)
Hi, Darren, I once made an animated gif of a rotating brain showing some freesurfer results. I did this with two scripts. The first is a tcl script that was passed to tksurfer; it rotates the brain and saves the resulting images. The second is a shell script that uses imagemagik to convert all of the resulting rgb images into one animated gif. I am attaching the scripts. Please be aware, however, that the tcl script isn't very elegent. I'm actually a little embarassed by it. Also, both scripts are set up for my file system, you will need to edit a few of the settings to get them to work for you. The tcl script is based on an earlier one I saw on the mailing list, I think it was Doug Greve's, but I'm not sure. I don't give credit in the script itself, sorry for the oversight! +glenn -- It is not an aesthetic process; it's a form of magic that interposes itself between us and the hostile universe, a means of seizing power by imposing a form on our terrors as well as on our desires. > Glenn Lawyer < > +352 061 967 244 < > Instituttgruppe for psykiatri < > Postboks 1130 Blindern < > 0318 Oslo < < http://folk.uio.no/davidgl > <><><><><><><><><><><><><><><><><:) # snapshot.tcl # # tcl script for making pics using tksurfer. # # This script automates a set of tksurfer commands. # # Be sure to check the base directory and the # regular expression before running! # # Pictures will be put in the images directory # underneath the basedir. # # You may also want to adjust the thresholds # and lighting models. # # glenn, sept 2005 ## # To use: Set all the parameters and then # pass the script as an argument to tksurfer # for example: # tksurfer average7 lh inflated -tcl snapshots.tcl # # The basedir is where all the w files are found # You probably need to set this to the correct value set basedir "/home/DARREN/MY_ANALYSIS/" # Use a regular expression to find all of the # *.w files for each hemisphere foreach wfile [glob ${hemi}*.w] { # read the wfile set layr 0 set val "${basedir}/${wfile}" sclv_read_binary_values $layr # set thresholds for the overlay # and values for the lighting model set fthresh 1 set fslope 1 set fmid 2 do_lighting_model 0.6 0.9 0.6 0.2 0.4; # Make and save .rgb images set cnt 1 set imagename [string trim $wfile .w] set filestem "/${basedir}/images/${imagename}" puts "Taking Snapshots to $filestem"; make_lateral_view; # sets to default orientation redraw; set filestem "/${basedir}/images/${cnt}_${imagename}" setfile rgb "${filestem}.rgb"; puts $rgb; save_rgb; # rotate up set i 0 while {$i < 110} { rotate_brain_x -1; incr i 1; incr cnt 1; redraw; set filestem "/${basedir}/images/${cnt}_${imagename}" setfile rgb "${filestem}.rgb"; puts $rgb; save_rgb; } # rotate down/towards set i 0 while {$i < 90} { rotate_brain_x 1; rotate_brain_y -1; rotate_brain_z 1; incr i 1; incr cnt 1; redraw; set filestem "/${basedir}/images/${cnt}_${imagename}" setfile rgb "${filestem}.rgb"; puts $rgb; save_rgb; } # rotate down/away set i 0 while {$i < 20} { rotate_brain_x -1; rotate_brain_y 1; incr i 1; incr cnt 1; redraw; set filestem "/${basedir}/images/${cnt}_${imagename}" setfile rgb "${filestem}.rgb"; puts $rgb; save_rgb; } # rotate away make_lateral_view; rotate_brain_y -90; set i 0 set j 0 while {$i < 100} { rotate_brain_y 2; if {$j < 20 && $j > -1} { rotate_brain_x 1; rotate_brain_z -1;} if {$j >= 30 && $j < 50} { rotate_brain_x -1; rotate_brain_z 1;} if {$j == 60} { set j -10;} if {$i > 79} { set j 3} incr j 1; incr i 1; incr cnt 1; redraw; set filestem "/${basedir}/images/${cnt}_${imagename}" setfile rgb "${filestem}.rgb"; puts $rgb; save_rgb; } # rotate up set i 0 while {$i < 40} { rotate_brain_x 1; rotate_brain_y -1; rotate_brain_z -1; incr i 1; incr cnt 1; redraw; set filestem "/${basedir}/images/${cnt}_${imagename}" setfile rgb "${filestem}.rgb"; puts $rgb; save_rgb; } # rotate up set i 0 while {$i < 40} { # rotate_brain_x -1; rotate_brain_y -1; rotate_brain_z -1; incr i 1; incr cnt 1; redraw; set filestem "/${basedir}/images/${cnt}_${imagename}" setfile rgb "${filestem}.rgb"; puts $rgb; save_rgb; } # and back home #set i 0 while {$i < 90} { rotate_brain_x -1; # rotate_brain_y -1; rotate_brain_z -1; incr i 1; incr cnt 1; redraw; set filestem "/${basedir}/images/${cnt}_${imagename}" setfile rgb "${filestem}.rgb"; puts $rgb; save_rgb; } } exit immagic.sh Description: application/shellscript ___ Freesurfer mailing list Freesurfer@nmr.mgh.harvard.edu https://mail.nmr.mgh.harvard.edu/mailm
Re: [Freesurfer] freesurfer and debian "etch"
Marcus, You may want to try the centos4 build of freesurfer. It is built against libstdc++.so.6, whereas the rh9 build builds against libstdc+ +.so.5. I don't know whether this would account for the partial brain you are seeing, or why, but its worth a try. Nick On Wed, 2006-02-22 at 10:58 +0100, wilms wrote: > Dear all, > > does someone out there run freesurfer > (freesurfer-Linux-rh9-dev20060210-full.tar.gz) under debian etch? > Installation runs smoothly, however, when I test the freesurfer > installation with > > medpc32:~$ tksurfer bert rh pial > > only a tiny fraction of Bert's brain is displayed. The GUI otherwise > seems to work as I can rotate etc this brain fraction. > > I installed the same freesurfer version on a different computer running > debian "sarge", which is the current stable distribution. - Here, I can > see the whole brain! > > As suggested elsewhere I thus compared the shared library dependencies > using > > medpc32:~$ ldd `which tkmedit` > > > Here is what I got: > > # > "etch"-machine: > # > > medpc32:~$ ldd `which tkmedit` > linux-gate.so.1 => (0xe000) > libtix8.1.8.3.so => > /local/opt/freesurfer_dev20060210/lib/tcltktixblt/lib/libtix8.1.8.3.so > (0xb7fb) > libtk8.4.so => > /local/opt/freesurfer_dev20060210/lib/tcltktixblt/lib/libtk8.4.so > (0xb7ef) > libtcl8.4.so => > /local/opt/freesurfer_dev20060210/lib/tcltktixblt/lib/libtcl8.4.so > (0xb7e57000) > libglut.so.3 => /usr/lib/libglut.so.3 (0xb7e0d000) > libSM.so.6 => /usr/X11R6/lib/libSM.so.6 (0xb7e04000) > libICE.so.6 => /usr/X11R6/lib/libICE.so.6 (0xb7dec000) > libXmu.so.6 => /usr/X11R6/lib/libXmu.so.6 (0xb7dd6000) > libXi.so.6 => /usr/X11R6/lib/libXi.so.6 (0xb7dce000) > libGLU.so.1 => /usr/lib/libGLU.so.1 (0xb7d4f000) > libGL.so.1 => /usr/lib/libGL.so.1 (0xb7ceb000) > libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0xb7c2) > libgsl.so.0 => > /local/opt/freesurfer_dev20060210/lib/gsl/lib/libgsl.so.0 (0xb7acc000) > libgslcblas.so.0 => > /local/opt/freesurfer_dev20060210/lib/gsl/lib/libgslcblas.so.0 (0xb7a9c000) > libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0xb7a7c000) > libtiff.so.3 => /usr/lib/libtiff.so.3 (0xb7a2a000) > libz.so.1 => /usr/lib/libz.so.1 (0xb7a15000) > libm.so.6 => /lib/tls/libm.so.6 (0xb79ef000) > libcrypt.so.1 => /lib/tls/libcrypt.so.1 (0xb79c1000) > libc.so.6 => /lib/tls/libc.so.6 (0xb788a000) > libdl.so.2 => /lib/tls/libdl.so.2 (0xb7886000) > libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0xb7878000) > libXt.so.6 => /usr/X11R6/lib/libXt.so.6 (0xb7827000) > libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb774a000) > libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb773f000) > libpthread.so.0 => /lib/tls/libpthread.so.0 (0xb772d000) > libXxf86vm.so.1 => /usr/X11R6/lib/libXxf86vm.so.1 (0xb7728000) > /lib/ld-linux.so.2 (0xb7feb000) > > > # > "sarge" machine: > # > > kogneuro-web:~$ ldd `which tkmedit` > libtix8.1.8.3.so => > /local/data/tools/freesurfer/lib/tcltktixblt/lib/libtix8.1.8.3.so > (0xb7fae000) > libtk8.4.so => > /local/data/tools/freesurfer/lib/tcltktixblt/lib/libtk8.4.so (0xb7eee000) > libtcl8.4.so => > /local/data/tools/freesurfer/lib/tcltktixblt/lib/libtcl8.4.so (0xb7e55000) > libglut.so.3 => /usr/lib/libglut.so.3 (0xb7e1b000) > libSM.so.6 => /usr/X11R6/lib/libSM.so.6 (0xb7e12000) > libICE.so.6 => /usr/X11R6/lib/libICE.so.6 (0xb7dfb000) > libXmu.so.6 => /usr/X11R6/lib/libXmu.so.6 (0xb7de4000) > libXi.so.6 => /usr/X11R6/lib/libXi.so.6 (0xb7ddc000) > libGLU.so.1 => /usr/lib/libGLU.so.1 (0xb7d61000) > libGL.so.1 => /usr/lib/libGL.so.1 (0xb7cf2000) > libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0xb7c2b000) > libgsl.so.0 => > /local/data/tools/freesurfer/lib/gsl/lib/libgsl.so.0 (0xb7ad7000) > libgslcblas.so.0 => > /local/data/tools/freesurfer/lib/gsl/lib/libgslcblas.so.0 (0xb7aa6000) > libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0xb7a88000) > libtiff.so.3 => /usr/lib/libtiff.so.3 (0xb7a38000) > libz.so.1 => /usr/lib/libz.so.1 (0xb7a26000) > libm.so.6 => /lib/tls/libm.so.6 (0xb7a04000) > libcrypt.so.1 => /lib/tls/libcrypt.so.1 (0xb79d7000) > libc.so.6 => /lib/tls/libc.so.6 (0xb78a1000) > libdl.so.2 => /lib/tls/libdl.so.2 (0xb789e000) > libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0xb789) > libXt.so.6 => /usr/X11R6/lib/libXt.so.6 (0xb783f000) > libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0xb7785000) > libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb7779000) > libpthread.so.0 => /lib/tls/libpthread.so.0 (0xb776a000) > /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0xb7fea000) > > > > The differences seem to be: > > # > "etch" machine: >
[Freesurfer] file paths in mgz headers
Hi, We like to structure our work by putting all scans into a batch account and doing recon-all -autorecon1 -autorecon2. We then transfer the scans to our individual accounts to check the quality before running the rest of the processing stream. This creates a small problem, in that the full path to the talairach.xfm is saved as part of the mgz volume. When we move the scan from the batch account to the user account, this path is no longer valid. We can fix this by using mri_add_xform_to_header, as per msg02241 on the mailing list (Doug Greve, 27 Jan 2006). What we are wondering is if the mgz header has any other path-dependant information that we would need to update in the scenario such as above, where scan workup and group analysis processing can take place over multiple file locations? +glenn ___ Freesurfer mailing list Freesurfer@nmr.mgh.harvard.edu https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
Re: [Freesurfer] tcl script - rotate and save graphics
If you are using a recent dev version of tksurfer, then try the function: save_tiff If you enter this into the shell and it doesn't work, then you have an older version. Our new release will have this function. There is (finally) some documentation for scripting commands in tksurfer, although it is for the newer dev version. https://surfer.nmr.mgh.harvard.edu/fswiki/TkSurferGuide_2fTkSurferScripting > I would like a short tcl script to rotate each hemisphere through > all the main views (lateral, medial, dorsal, ventral, anterior, > posterior) and output a graphics file with the name of the subject > and the view in the file name. I've found rotate_brain_[xyz] and > save_rgb, but the latter does not permit a file name for the output > graphics. I would like high-resolution graphics for publications, > but the save_rgb outputs about 85-90 dpi images. Is there an option > for vector graphics or high resolution tiff or png images? -- Kevin Teich ___ Freesurfer mailing list Freesurfer@nmr.mgh.harvard.edu https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
Re: [Freesurfer] tcl script - rotate and save graphics
Hi Darren and other Freesurfers I wrote a tcl script to do just what was described. The one I made gives the flexibility to name the tiff files based on a prefix that you specify before running the script. This way you run the same exact script for as many pictures as you like, simply changing the prefix before running the script. Here is what you do. In tksurfer, after you have set up whatever overlays and/or labels and/or surfaces etc that you like, you enter at the command prompt set pre (where the stuff inside the < > is any file prefix... for instance, set pre bold_contrast1 ) then you run the following tcl script via the menu for running a script... UpdateAndRedraw puts "Taking Snapshots..." make_lateral_view rotate_brain_y 90 redraw set tiff "${pre}_bck.tif" save_tiff $tiff make_lateral_view redraw set tiff "${pre}_lat.tif" save_tiff $tiff rotate_brain_y 180 redraw set tiff "${pre}_med.tif" save_tiff $tiff make_lateral_view rotate_brain_x 90 redraw set tiff "${pre}_inf.tif" save_tiff $tiff rotate_brain_x 180 redraw set tiff "${pre}_sup.tif" save_tiff $tiff make_lateral_view rotate_brain_y 270 redraw set tiff "${pre}_front.tif" save_tiff $tiff Darren Weber wrote: Hi Bruce etal, I would like a short tcl script to rotate each hemisphere through all the main views (lateral, medial, dorsal, ventral, anterior, posterior) and output a graphics file with the name of the subject and the view in the file name. I've found rotate_brain_[xyz] and save_rgb, but the latter does not permit a file name for the output graphics. I would like high-resolution graphics for publications, but the save_rgb outputs about 85-90 dpi images. Is there an option for vector graphics or high resolution tiff or png images? Best, Darren ___ Freesurfer mailing list Freesurfer@nmr.mgh.harvard.edu https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer -- Daniel Goldenholz - Cell: 617-935-9421 http://people.bu.edu/danielg/ "Mavet v'chaim b'yad halashon" "Life and death are in the hands of language" - Proverbs 18:21 ___ Freesurfer mailing list Freesurfer@nmr.mgh.harvard.edu https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
Re: [Freesurfer] file paths in mgz headers
I don't think so. Glenn Lawyer wrote: Hi, We like to structure our work by putting all scans into a batch account and doing recon-all -autorecon1 -autorecon2. We then transfer the scans to our individual accounts to check the quality before running the rest of the processing stream. This creates a small problem, in that the full path to the talairach.xfm is saved as part of the mgz volume. When we move the scan from the batch account to the user account, this path is no longer valid. We can fix this by using mri_add_xform_to_header, as per msg02241 on the mailing list (Doug Greve, 27 Jan 2006). What we are wondering is if the mgz header has any other path-dependant information that we would need to update in the scenario such as above, where scan workup and group analysis processing can take place over multiple file locations? +glenn ___ Freesurfer mailing list Freesurfer@nmr.mgh.harvard.edu https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer -- Douglas N. Greve, Ph.D. MGH-NMR Center [EMAIL PROTECTED] Phone Number: 617-724-2358 Fax: 617-726-7422 In order to help us help you, please follow the steps in: surfer.nmr.mgh.harvard.edu/fswiki/BugReporting ___ Freesurfer mailing list Freesurfer@nmr.mgh.harvard.edu https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
[Freesurfer] troubles with monkey brains (inflate)
Dear all, at the moment I am struggling with flattening monkey anatomical scans. Specifically I manually got to the point where I get a wm.mgz and now I want to inflate it. My instructions refer to using csurf, which does not like my mgz volumes and is deprecated IIRC, the alternative is hooking my data into the recon-all pipe-line. But that fails as I do not have any aseg.mgz (does the segmentation work for monkeys?). So any advice on how to proceed with the processing? Ahoi & Thanks Sebastian -- Sebastian Moeller Tel.: 04 21 - 2 18 - 78 38 oder 96 91 Fax.: 04 21 - 2 18 - 90 04 GSM: 01 62 - 3 25 45 59 [EMAIL PROTECTED] AG Kreiter / FB 2 Institut fuer Hirnforschung III Abteilung Theoretische Neurobiologie Universitaet Bremen Biogarten Hochschulring 16a Postfach 33 04 40 28359 Bremen ___ Freesurfer mailing list Freesurfer@nmr.mgh.harvard.edu https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
Re: [Freesurfer] troubles with monkey brains (inflate)
In the freesurfer dev releases post 2006-18-01, there is a -noaseg flag in recon-all. It will skip the auto-segmentation step, and not include aseg.mgz in any subsequent processing (eg. wm seg and filling). The flag is intended for usage with baby brains and non-human primates, as these brains cannot be auto-segmented with the default atlas (which is based on 40 adult normals). On Wed, 2006-02-22 at 18:19 +0100, Sebastian Moeller wrote: > Dear all, > > at the moment I am struggling with flattening monkey anatomical scans. > Specifically I manually got to the point where I get a wm.mgz and now I > want to inflate it. My instructions refer to using csurf, which does > not like my mgz volumes and is deprecated IIRC, the alternative is > hooking my data into the recon-all pipe-line. But that fails as I do > not have any aseg.mgz (does the segmentation work for monkeys?). So any > advice on how to proceed with the processing? > > Ahoi & Thanks > Sebastian ___ Freesurfer mailing list Freesurfer@nmr.mgh.harvard.edu https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
Re: [Freesurfer] troubles with monkey brains (inflate)
Hi Nick, hi All, On 22. Feb 2006, at 19:39 Uhr, Nick Schmansky wrote: In the freesurfer dev releases post 2006-18-01, there is a -noaseg flag in recon-all. It will skip the auto-segmentation step, and not include aseg.mgz in any subsequent processing (eg. wm seg and filling). The flag is intended for usage with baby brains and non-human primates, as these brains cannot be auto-segmented with the default atlas (which is based on 40 adult normals). I still run the dev20051003 version, is everything else compatible? Anyway I used the -nofill directive for recon-all autorecon2-wm, after running mri_fill manually, supplying the required cc and pons coordinates, but specifying -noaseg sure beats my "do it by hand" approach, by far. Thanks for the impressive automatization work. Ahoi & Thanks Sebastian On Wed, 2006-02-22 at 18:19 +0100, Sebastian Moeller wrote: Dear all, at the moment I am struggling with flattening monkey anatomical scans. Specifically I manually got to the point where I get a wm.mgz and now I want to inflate it. My instructions refer to using csurf, which does not like my mgz volumes and is deprecated IIRC, the alternative is hooking my data into the recon-all pipe-line. But that fails as I do not have any aseg.mgz (does the segmentation work for monkeys?). So any advice on how to proceed with the processing? Ahoi & Thanks Sebastian -- Sebastian Moeller Tel.: 04 21 - 2 18 - 78 38 oder 96 91 Fax.: 04 21 - 2 18 - 90 04 GSM: 01 62 - 3 25 45 59 [EMAIL PROTECTED] AG Kreiter / FB 2 Institut fuer Hirnforschung III Abteilung Theoretische Neurobiologie Universitaet Bremen Biogarten Hochschulring 16a Postfach 33 04 40 28359 Bremen ___ Freesurfer mailing list Freesurfer@nmr.mgh.harvard.edu https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
Re: [Freesurfer] troubles with monkey brains (inflate)
Sebastian, I've attached a gzipped recon-all that has the -noseg flag. Do not copy over the recon-all in your 2005-10-03 release, as it's not fully compatible with that. Rather, I suggest opening the new recon-all in a text editor, and look for instances of the variable 'UseAseg', and the - noaseg flag, and I think you can modify your existing recon-all to do the same. There is no magic involved, the -noaseg flag just does what you were probably doing manually. Your 2005-10-03 release should work with the changes. Nick On Wed, 2006-02-22 at 20:02 +0100, Sebastian Moeller wrote: > Hi Nick, hi All, > > On 22. Feb 2006, at 19:39 Uhr, Nick Schmansky wrote: > > > In the freesurfer dev releases post 2006-18-01, there is a -noaseg flag > > in recon-all. It will skip the auto-segmentation step, and not include > > aseg.mgz in any subsequent processing (eg. wm seg and filling). The > > flag is intended for usage with baby brains and non-human primates, as > > these brains cannot be auto-segmented with the default atlas (which is > > based on 40 adult normals). > I still run the dev20051003 version, is everything else compatible? > Anyway I used the -nofill directive for recon-all autorecon2-wm, after > running mri_fill manually, supplying the required cc and pons > coordinates, but specifying -noaseg sure beats my "do it by hand" > approach, by far. Thanks for the impressive automatization work. > > Ahoi & Thanks > Sebastian > > > > > > > On Wed, 2006-02-22 at 18:19 +0100, Sebastian Moeller wrote: > >> Dear all, > >> > >> at the moment I am struggling with flattening monkey anatomical scans. > >> Specifically I manually got to the point where I get a wm.mgz and now > >> I > >> want to inflate it. My instructions refer to using csurf, which does > >> not like my mgz volumes and is deprecated IIRC, the alternative is > >> hooking my data into the recon-all pipe-line. But that fails as I do > >> not have any aseg.mgz (does the segmentation work for monkeys?). So > >> any > >> advice on how to proceed with the processing? > >> > >> Ahoi & Thanks > >>Sebastian > > > > > > recon-all.gz Description: GNU Zip compressed data ___ Freesurfer mailing list Freesurfer@nmr.mgh.harvard.edu https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer