[Freesurfer] freesurfer and debian "etch"

2006-02-22 Thread wilms
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

2006-02-22 Thread Bruce Fischl
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)

2006-02-22 Thread Glenn Lawyer




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"

2006-02-22 Thread Nick Schmansky
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

2006-02-22 Thread Glenn Lawyer




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

2006-02-22 Thread Kevin Teich

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

2006-02-22 Thread Daniel Goldenholz

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

2006-02-22 Thread Doug Greve




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)

2006-02-22 Thread Sebastian Moeller

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)

2006-02-22 Thread Nick Schmansky
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)

2006-02-22 Thread Sebastian Moeller

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)

2006-02-22 Thread Nick Schmansky
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