[Freesurfer] problem with mri_em_register
Hi all, I want to try Freesurfer in object with a physical sizes are (310.00 mm, 310.00 mm, 310.00 mm) but I have a segmentation fault when running the recon-all, precisely, in stage 2 when running: mri_em_register -mask brainmask.mgz nu.mgz /home/samba/user/douiri/dev/freesurfer/average/RB_all_2006-02-15.gca transforms/talairach.lta the out put is : using MR volume brainmask.mgz to mask input volume... reading 1 input volumes... logging results to talairach.log reading '/home/samba/user/douiri/dev/freesurfer/average/RB_all_2006-02-15.gca'... setting gca type = Normal gca type average std = 7.4 using min determinant for regularization = 5.5 0 singular and 1662 ill-conditioned covariance matrices regularized reading 'nu.mgz'... Segmentation fault I have done an mri_info on nu.mgz (Fov: 310) and brainmask.mgz (Fov: 256) and I found that brainmask.mgz ((256.00 mm, 256.00 mm, 256.00 mm)) has a size smaller of nu.mgz. I would be gratefully if you can tell me what going wrong with my data. Regards A ___ Freesurfer mailing list Freesurfer@nmr.mgh.harvard.edu https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
Re: [Freesurfer] printing out from tksurfer and tkmedit
just make sure that the window shows as you want it (you may need to redraw it before hitting save). On Wed, 12 Jul 2006, Chacko Cherian wrote: when i want to print-out the outputs using Save TIFF as it isn't giving me any results.Is there something else that I need to do to save the outputs as TIFF files?? --- Bruce Fischl [EMAIL PROTECTED] wrote: but you could write a tcl script to do it automatically On Fri, 30 Jun 2006, Kevin Teich wrote: How can I can I print out the display images from tksurfer and tkmedit other than manually saving them into tiff and then printing them.IS there any way to print them directly? No, sorry, saving TIFFs is the only output that tkmedit and tksurfer do of that kind. __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ Freesurfer mailing list Freesurfer@nmr.mgh.harvard.edu https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
Re: [Freesurfer] problem with mri_em_register
we are currently limited to 256^3, which fits pretty much every brain I've ever seen. What is 310^3? This is on our to-do list. Bruce On Thu, 13 Jul 2006, Abdel Douiri wrote: Hi all, I want to try Freesurfer in object with a physical sizes are (310.00 mm, 310.00 mm, 310.00 mm) but I have a segmentation fault when running the recon-all, precisely, in stage 2 when running: mri_em_register -mask brainmask.mgz nu.mgz /home/samba/user/douiri/dev/freesurfer/average/RB_all_2006-02-15.gca transforms/talairach.lta the out put is : using MR volume brainmask.mgz to mask input volume... reading 1 input volumes... logging results to talairach.log reading '/home/samba/user/douiri/dev/freesurfer/average/RB_all_2006-02-15.gca'... setting gca type = Normal gca type average std = 7.4 using min determinant for regularization = 5.5 0 singular and 1662 ill-conditioned covariance matrices regularized reading 'nu.mgz'... Segmentation fault I have done an mri_info on nu.mgz (Fov: 310) and brainmask.mgz (Fov: 256) and I found that brainmask.mgz ((256.00 mm, 256.00 mm, 256.00 mm)) has a size smaller of nu.mgz. I would be gratefully if you can tell me what going wrong with my data. Regards A ___ Freesurfer mailing list Freesurfer@nmr.mgh.harvard.edu https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
Re: [Freesurfer] printing out from tksurfer and tkmedit
Can you say exactly what you're doing so we can try to reproduce it? On Wed, Jul 12, 2006 at 10:46:34PM -0700, Chacko Cherian wrote: when i want to print-out the outputs using Save TIFF as it isn't giving me any results.Is there something else that I need to do to save the outputs as TIFF files?? --- Bruce Fischl [EMAIL PROTECTED] wrote: but you could write a tcl script to do it automatically On Fri, 30 Jun 2006, Kevin Teich wrote: How can I can I print out the display images from tksurfer and tkmedit other than manually saving them into tiff and then printing them.IS there any way to print them directly? No, sorry, saving TIFFs is the only output that tkmedit and tksurfer do of that kind. -- Kevin Teich ___ Freesurfer mailing list Freesurfer@nmr.mgh.harvard.edu https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
Re: [Freesurfer] mri_label2label validation failed
Hmmm, I just tried this and did not have a problem. There's something
funny going on here. The indices for both labels are the same, only the
cooridnates are different. This means that the source label and the new
label are using different surfaces. Are you sure you created the source
label from the white surface? Can you take your new label and generate
another new label in the same way?
doug
Darren Weber wrote:
This is an example of diff output for the test without the --trgsurf option:
endorphin.14 diff --side-by-side DLWeber_rh_ACC.label
DLWeber_surface_rh_ACC.label | head -
#!ascii label , from subject ucsf_wa#!ascii
label , from subject ucsf_wa
660 660
106091 3.122 21.824 57.650 0.00| 106091
2.037 22.222 57.359 0.00
106981 7.056 22.926 59.092 0.00| 106981
7.114 22.942 59.024 0.00
106982 6.147 22.676 59.500 0.00| 106982
6.137 22.636 59.159 0.00
106983 5.178 22.521 58.995 0.00| 106983
4.816 22.583 58.765 0.00
106984 4.149 22.523 58.728 0.00| 106984
3.440 22.988 58.509 0.00
106985 3.138 22.925 58.465 0.00| 106985
2.206 23.278 58.150 0.00
106991 7.153 22.847 58.153 0.00| 106991
7.272 22.963 58.219 0.00
106992 6.603 22.649 58.357 0.00| 106992
6.639 22.730 58.329 0.00
Are these values just from different layers in the rh.surf data?
Thanks, Darren
Doug Greve wrote:
I think it should be the same. When the source and target subjs are
the same, there should not be any resampling.
On Tue, 11 Jul 2006, Bruce Fischl wrote:
It probably won't be the same as a cp in any case, as you will go
through some resampling steps.
cheers,
Bruce
On Tue, 11 Jul 2006, Doug Greve wrote:
The label coords as created by tksurfer should be that of the white
surface, so you're really just changing the coords from that of white
to that of pial. Can you try removing --trgsurf pial from your cmd
and see if the labels are the same?
doug
Darren Weber wrote:
Dear Doug et al.,
I'm trying to test mri_label2label because we've observed some strange
results in the download for:
freesurfer-Linux-rh9-stable-pub-v3.0.2
To test the program, I thought it would be sensible to map a label of
one subject onto itself, with a different label filename for the
output.
So I created a large label in a subject rh inflated surface and
saved it
to X.label file. I then tried to run mri_label2label using the same
srcsubject and target subject, with a different name for the target
label, ie:
mri_label2label \
--srclabel $SUBJECTS_DIR/${srcsubject}/label/$label \
--trglabel $SUBJECTS_DIR/${srcsubject}/label/$newlabel \
--srcsubject ${srcsubject} \
--trgsubject ${srcsubject} \
--regmethod surface --hemi $hemi --trgsurf pial
In effect, this should be equivalent to:
cd $SUBJECTS_DIR/${srcsubject}/label/
cp $label $newlabel
That is, the label mapping onto the same subject surface should be
identical. It is not. Can you please try to replicate this result? I
would like to know if it is particular to the setup here. If you
find a
bug in mri_label2label, please forward a fix ASAP, as we are trying to
complete some analysis that depends on mapping labels across subjects.
Thanks, Darren
--
Darren L. Weber, Ph.D.
Postdoctoral Scholar
Dynamic Neuroimaging Laboratory,
UCSF Department of Radiology,
185 Berry Street, Suite 350, Box 0946,
San Francisco, CA 94107, USA.
Tel: +1 415 353-9444
Fax: +1 415 353-9421
www: http://dnl.ucsf.edu/users/dweber
"To explicate the uses of the brain seems as difficult
a task as to paint the soul, of which it is commonly
said, that it understands all things but itself."
Thomas Willis (The Anatomy of the Brain and Nerves, 1664)
___
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] read_surf
Hi Doug, I'm using the matlab routine 'read_surf' from the 3.0.3 distribution to read a surface generated by mri_tessellate. The magic number for the surface is: 16777213, which does not match either the QUAD or the TRI magic numbers listed in read_surf and hence does not read it. Is there an updated version of read_surf available? Thanks, Satra ___ Freesurfer mailing list Freesurfer@nmr.mgh.harvard.edu https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
Re: [Freesurfer] read_surf
Hi Satra, I think the magic # should still be 16777215. Did your surface get corrupted somehow? Bruce On Thu, 13 Jul 2006, Satrajit Ghosh wrote: Hi Doug, I'm using the matlab routine 'read_surf' from the 3.0.3 distribution to read a surface generated by mri_tessellate. The magic number for the surface is: 16777213, which does not match either the QUAD or the TRI magic numbers listed in read_surf and hence does not read it. Is there an updated version of read_surf available? Thanks, Satra ___ Freesurfer mailing list Freesurfer@nmr.mgh.harvard.edu https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer ___ Freesurfer mailing list Freesurfer@nmr.mgh.harvard.edu https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
RE: [Freesurfer] read_surf
Hi Bruce, tksurfer can read the surface but matlab cannot. I'm therefore not sure if it is corrupted. I'm running on a 64 bit opteron, if that makes a difference. Satra -Original Message- From: Bruce Fischl [mailto:[EMAIL PROTECTED] Sent: Thursday, July 13, 2006 1:56 PM To: Satrajit Ghosh Cc: freesurfer@nmr.mgh.harvard.edu Subject: Re: [Freesurfer] read_surf Hi Satra, I think the magic # should still be 16777215. Did your surface get corrupted somehow? Bruce On Thu, 13 Jul 2006, Satrajit Ghosh wrote: Hi Doug, I'm using the matlab routine 'read_surf' from the 3.0.3 distribution to read a surface generated by mri_tessellate. The magic number for the surface is: 16777213, which does not match either the QUAD or the TRI magic numbers listed in read_surf and hence does not read it. Is there an updated version of read_surf available? Thanks, Satra ___ Freesurfer mailing list Freesurfer@nmr.mgh.harvard.edu https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer ___ Freesurfer mailing list Freesurfer@nmr.mgh.harvard.edu https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
Re: [Freesurfer] cortical thickness table.
Use the asegstats2table or aparcstats2table utilities, which are new to v3.0.3 of freesurfer. For help: asegstats2table --help and aparcstats2table --help On Thu, 2006-07-13 at 12:27 -0700, Chacko Cherian wrote: Hello all, The cortical thickness table which is located in the stats folder..i am currently opening it with my vi editor.Is there any way to open it directly as a spreadsheet to print it out?? THanks Chacko. __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ Freesurfer mailing list Freesurfer@nmr.mgh.harvard.edu https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer ___ Freesurfer mailing list Freesurfer@nmr.mgh.harvard.edu https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
Re: [Freesurfer] cortical thickness table.
Have you tried opening it in excel? Alternatively, you can run aparcstats2table. This program was intended to be run on multiple subjects in order to produce a spreadsheet, but you can run it on one subject just as well. This is a fairly recent addition (within the last 8 weeks), so you might not have it in your distribution. If not, let me know, and I can put it on the net. There's also a program called asegstats2table which does the same for the aseg.stats file. doug Chacko Cherian wrote: Hello all, The cortical thickness table which is located in the stats folder..i am currently opening it with my vi editor.Is there any way to open it directly as a spreadsheet to print it out?? THanks Chacko. __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ 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
Re: [Freesurfer] Starting with brain-extracted volume?
Hi Graham, the EM Registration with Skull is for generating ICV measures, which of course you won't be able to get with the skull gone. Bruce On Thu, 13 Jul 2006, Graham Wideman wrote: Nick, Doug or anyone with thoughts on the matter, This is a return to a similar question I raised in June-2nd thread Some FS input questions, but a little less awkward. We'd like to present to FS already brain-extracted volumes that are already conformed, ie: 256^3, and 1 mm isotropic This would appear to avoid the necessity to turn off aseg (mentioned by Nick in previous thread). I also see the enticing looking options like noskullstrip, but... I'm wary of two things: a) In general, when you select a nosomething option, does recon-all do the right thing to pass the data through (usually a copy I suspect) so that subsequent steps receive their input file(s)? b) There may be steps that expect the skull or neck to be in place? EM Registration with Skull (skull-lta) sounds like it might be one? So I'd like to know if there are such, and whether I should care? According to my chart here: grahamwideman.com/gw/brain/fs/fsunderstanding2006/processvsdata2006.htm ...looks like I *should* be able to bypass rmneck and skull-lta (or just let them run unsatisfactorily) with no downstream impact. Any thoughts? Thanks, Graham ___ Freesurfer mailing list Freesurfer@nmr.mgh.harvard.edu https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer ___ Freesurfer mailing list Freesurfer@nmr.mgh.harvard.edu https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
Re: [Freesurfer] mgh format wiki doc: Error; additions
Graham,
Thanks for pointing these out. We've corrected the page (but it still
needs quite a bit more work to make it a true 'file spec').
Nick
On Wed, 2006-07-12 at 20:05 -0700, Graham Wideman wrote:
Folks: (Probably Nick S?)
Comments on the MghFormat wiki doc page:
https://surfer.nmr.mgh.harvard.edu/fswiki/FsTutorial_2fMghFormat
1. Width/Height/Depth confusion.
Doc says...
width integer first dimension of the image buffer (slowest)
height integersecond dimension of the image buffer (2nd slowest)
depth integer fastest dimension when reading the buffer
... yet mriio mghWrite(...) source code says...
for (frame = start_frame ; frame = end_frame ; frame++) {
for (z = 0 ; z depth ; z++) {
for (y = 0 ; y height ; y++) { [...]
for (x = 0 ; x width ; x++)
Ie: width should be fastest, and depth slowest, contrary to doc.
Further, the statement the bytes being read in the order Z -- Y -- X is
either incorrect or doesn't have any meaning.
2. image data starts at specified offset, which is currently ???.
Looks like from the source code that the header is padded to 24 + 256,
which means image starting at byte 280 (counting from zero).
3. Other Data
--
In the doc, the Other Data section ends at FoV. Actually the source code
shows that mghWrite writes out other stuff beyond that, which in the
examples I looked at appears to be a history of commands performed on the
image so far, for example (abbreviated [...] and wrapped by me):
===
[...]
mri_convert /data/[...]/39174a/mri/rawavg.mgz [output filepath] --conform
ProgramVersion: $Name: stable3
$ TimeStamp: 06/06/07-04:10:32-GMT CVS:
$Id: mri_convert.c,v 1.121 2006/02/22 05:39:36 greve Exp
$ User: graham Machine: gwlin[...]
CompilerName: GCC Compile[...]
mri_ca_normalize -mask brainmask.mgz nu.mgz [...] norm.mgz
ProgramVersion: $Name: stable3
$ TimeStamp: 06/06/11-05:41:45-GMT CVS:
$Id: mri_ca_normalize.c,v 1.31 2005/08/15 14:14:22 fischl Exp
$ User: graham Machine: gwlin[...]
GCC CompilerVersion:
[...]
===
(Plus the source code suggests that if a Talairach transform has been
applied it appears here in some form).
-
Graham
___
Freesurfer mailing list
Freesurfer@nmr.mgh.harvard.edu
https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
___
Freesurfer mailing list
Freesurfer@nmr.mgh.harvard.edu
https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
Re: [Freesurfer] Starting with brain-extracted volume?
Graham, In general, you should be careful when selecting the '-nosomething' options, as recon-all does not perform much checking for these flags (only the -autorecon1,2,3 flags contain the validity checks). An option when experimenting with the flags is to use the -dontrun flag, which just prints all the commands it will run without executing. Then you can manually check for validity. Also, perusing the recon-all script is the next best thing. In the case of the -noskullstrip flag, this just skips the mri_watershed block of code, so that means brainmask.auto.mgz is not created. This means, I suppose, that you could just name your own skullstripped volume brainmask.auto.mgz (and copy that to brainmask.mgz, which is the one that should be edited, if need be), and then run: recon-all -autorecon2 -normneck -noskull-lta Nick On Thu, 2006-07-13 at 13:10 -0700, Graham Wideman wrote: Nick, Doug or anyone with thoughts on the matter, This is a return to a similar question I raised in June-2nd thread Some FS input questions, but a little less awkward. We'd like to present to FS already brain-extracted volumes that are already conformed, ie: 256^3, and 1 mm isotropic This would appear to avoid the necessity to turn off aseg (mentioned by Nick in previous thread). I also see the enticing looking options like noskullstrip, but... I'm wary of two things: a) In general, when you select a nosomething option, does recon-all do the right thing to pass the data through (usually a copy I suspect) so that subsequent steps receive their input file(s)? b) There may be steps that expect the skull or neck to be in place? EM Registration with Skull (skull-lta) sounds like it might be one? So I'd like to know if there are such, and whether I should care? According to my chart here: grahamwideman.com/gw/brain/fs/fsunderstanding2006/processvsdata2006.htm ...looks like I *should* be able to bypass rmneck and skull-lta (or just let them run unsatisfactorily) with no downstream impact. Any thoughts? Thanks, Graham ___ Freesurfer mailing list Freesurfer@nmr.mgh.harvard.edu https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer ___ Freesurfer mailing list Freesurfer@nmr.mgh.harvard.edu https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
