Freesurfer March 2004

freesurfer@nmr.mgh.harvard.edu

21 participants
23 discussions

looking at blocked data on a patch in surf-sess
by Stephanie McMains 19 Mar '04

19 Mar '04

I am trying to look at data analyzed as a block design on a flat.occip.patch. I am trying to use surf-sess to do this, but I have found if I set the patch option in the command line then it automatically thinks I am doing retinotopy and tries to use the twocond-flat.tcl script, which is incorrect. Is there a way to use surf-sess to view blocked design data on the patch? I just could not see a way. So I went in and edited the surf-sess script so that it did not automatically set the tcl script to twocond-flat.tcl when you used the -patch flag. I now have surf-sess setting the patch correctly, but in the end the inflated surface still comes up. Is there some way to override the inflated surface and get it to use the patch? An answer to either question would be most helpful! Thanks! Stephanie

2 1

Re: mri_convert - use of hdr.hist.orient field incorrect
by Darren Weber 16 Mar '04

16 Mar '04

OK, so I find that mri_convert, without any -i?d or -o?d specifications does a fine job of reading the axial, unflipped data and it correctly outputs a coronal, flipped volume. So, my concern is how to output an axial unflipped volume correctly. I'm not getting the right answer using the -o?d flags. Please enlighten me ;-) Best, Darren PS, if this email gets through the mail server before the previous email (which has image attachments)...read the text of the previous email below and this message might make more sense :-) Darren Weber wrote: > > Hi, > > as best I can determine, the latest version of mri_convert is not using > the hdr.hist.orient field correctly. It is using orient=0 as if it is > RAS, when it must be LAS. it is also using the flipped values > (orient=3-5) incorrectly. > > Lets start with an Analyze volume with orient=0 (ie, the default Analyze > orientation in axial slices, with +X left, +Y anterior, +Z superior). A > display of this volume is attached as ucsf_ag_t1.jpg. Note how the > anatomical marker placed on the left cheek appears on the right hand > side of the axial slice (+X is LEFT, +Y is anterior, +Z is superior; > radiological orientation). The matlab tools I have for reading this > give the following: > > >> avw = avw_read('ucsf_ag/mri/analyze/ucsf_ag_t1') > > AVW_HDR_READ [v 1.10] > ...reading ieee-le Analyze format...done ( 0.02 sec). > > AVW_IMG_READ [v 1.9 ] > ...reading ieee-le Analyze int16 image format. > ...reading axial unflipped orientation > ...done (10.05 sec). > > > avw = > > hdr: [1x1 struct] > fileprefix: 'ucsf_ag/mri/analyze/ucsf_ag_t1' > img: [256x256x200 double] > > >> avw.hdr.hist.orient > > ans = > > 0 > > > > OK, now lets process this volume with mri_convert (to get from > 256x256x200 into 256x256x256, 1mm^3 voxels): > > Given that freesurfer prefers RAS volumes, we use the following command > on this Analyze volume: > > mri_convert -iid -1 0 0 -ijd 0 1 0 -ikd 0 0 1 analyze_in.img orig > > where the -iid indicates that the left-right direction is LAS rather > than RAS. This volume is then correctly oriented within the tkmedit > display. > > So now, we should be able to convert back from the orig volume into > Analyze, with the following command: > > mri_convert orig -oid -1 0 0 -ojd 0 1 0 -okd 0 0 1 analyze_out.img > > Again, we want to flip in X so we get back an LAS volume. However, > mri_convert is using the orient=3 (axial flipped) when it sees -oid -1 0 0. > > I stress that the flipped orient values (3-5) are not intended to > represent Neurological or Radiological orientation. The flipped values > are only designed to be used in movies (so they actually facilitate > speed of display for volumetic images on a 2D screen where the pixels > are updated from top to bottom of the screen). > > Even the default orientation is not correct. This, I think, is a > fundamental error of associating freesurfer RAS with Analyze orient=0. > The problem is that the orient=0 value is LAS, not RAS! For example, if > we specify the following: > > mri_convert ${sub}/mri/orig -oid 1 0 0 -ojd 0 1 0 -okd 0 0 1 > $sub/mri/analyze/${sub}_orig_axial_las.img >> ${sub}_mri_convert.log > > and then check the results with my matlab tools (mri_toolbox at > http://eeg.sf.net) we see the graphic attached in > ucsf_ag_orig_axial_ras.jpg (note that an anatomical marker was placed on > the LEFT cheek and according to orient=0, it should appear in > radiological orientation, with +X LEFT, but here it appears as +X RIGHT > - this is wrong!); here are the matlab commands: > > >> > >> avw = avw_read('ucsf_ag/mri/analyze/ucsf_ag_orig_axial_las') > > AVW_HDR_READ [v 1.10] > ...reading ieee-le Analyze format...done ( 0.02 sec). > > AVW_IMG_READ [v 1.9 ] > ...reading ieee-le Analyze uchar image format. > ...reading axial unflipped orientation > ...done (24.39 sec). > > > avw = > > hdr: [1x1 struct] > fileprefix: 'ucsf_ag/mri/analyze/ucsf_ag_orig_axial_las' > img: [256x256x256 double] > > >> avw.hdr.hist.orient > > ans = > > 0 > > > I may be missing something about how mri_convert has implemented the > allocation of values to the orient field of the header, but it appears > to me that it is not working in the manner described in the Analyze 7.5 > data format. I refer to the document available at: > > http://eeg.sourceforge.net/AnalyzeDirect_ANALYZEformat.pdf > > I did not see this problem in the previous version of mri_convert, so I > assume this is an initial attempt to implement handling of the orient > values in mri_convert. I'm not clear about how you have interpreted > this field or verified that mri_convert is working with it correctly. > Certainly, there is some inconsistency with my understanding of the > field and mri_convert implementation. I 'believe' that my reading and > implementation of the format documentation is correct. > > Best, Darren > > -- > Darren L. Weber, Postdoctoral Research Fellow, > Room 371-10, China Basin Landing, Dynamic Neuroimaging Laboratory, > Department of Radiology, University of California, San Francisco > 185 Berry Street, San Francisco, CA 94143-0946 > > Address for express mail/deliveries: > 185 Berry Street. Suite 350 > San Francisco, CA 94107 > > voice:(1) 415 353-9444 > fax: (1) 415 353-9421 > www: http://dnl.ucsf.edu/users/dweber > > > "People travel to wonder at the height of the mountains, > at the huge waves of the seas, at the long course of the rivers, > at the vast compass of the ocean, at the circular motion of the stars, > and yet they pass by themselves without wondering." > > St. Augustine, 354 430 > > ------------------------------------------------------------------------ > > > ------------------------------------------------------------------------ > -- Best, Darren -- Darren L. Weber, Postdoctoral Research Fellow, Room 371-10, China Basin Landing, Dynamic Neuroimaging Laboratory, Department of Radiology, University of California, San Francisco 185 Berry Street, San Francisco, CA 94143-0946 Address for express mail/deliveries: 185 Berry Street. Suite 350 San Francisco, CA 94107 voice:(1) 415 353-9444 fax: (1) 415 353-9421 www: http://dnl.ucsf.edu/users/dweber "People travel to wonder at the height of the mountains, at the huge waves of the seas, at the long course of the rivers, at the vast compass of the ocean, at the circular motion of the stars, and yet they pass by themselves without wondering." St. Augustine, 354 430

1 0

mris_sample_parc error
by Satrajit Ghosh 15 Mar '04

15 Mar '04

I am getting the following error when I run mris_sample_parc. Is this the proper command line? Thanks, Satra [labuser@... ~/subjects]$ mris_sample_parc ralasubj.01 lh parc1 parc reading parcellation volume from /speechlab/software/freesurfer/subjects/ralasubj.01/mri/parc1... reading input surface /speechlab/software/freesurfer/subjects/ralasubj.01/surf/lh.white... pass 1: 1588 segments changed pass 2: 407 segments changed pass 3: 182 segments changed pass 4: 181 segments changed pass 5: 177 segments changed pass 6: 180 segments changed pass 7: 177 segments changed pass 8: 180 segments changed pass 9: 177 segments changed pass 10: 180 segments changed pass 11: 177 segments changed writing annotation to lh.parc.annot... could not read annot file /speechlab/software/freesurfer/subjects/ralasubj.01/surf/../label/lh.lh.parc.annot No such file or directory

2 1

Mris_sample_parc
by Satrajit Ghosh 12 Mar '04

12 Mar '04

I can't find the mris_sample_parc command any longer in the distribution. Is this available somewhere or is there a substitute for it? Thanks, Satra

1 0

mri_normalize update
by Kevin Teich 11 Mar '04

11 Mar '04

The processing of control points in volume/surface creation in mri_normalize, used by csurf and recon-all, is broken for certain types of data in the 20040218 release. Please download one of these updates if you are having trouble: Darwin, 872KB: ftp://surfer.nmr.mgh.harvard.edu/pub/dist/mri_normalize-20040311-Darwin.tar… Linux, 1263KB: ftp://surfer.nmr.mgh.harvard.edu/pub/dist/mri_normalize-20040311-Linux.tar.… To unpack, move the file you download to your freesurfer/ directory, cd there, and run "tar zxvf <filename>". It will install bin/<OS>/mri_normalize. -- Kevin Teich

2 2

Tkmedit update for display transforms
by Kevin Teich 11 Mar '04

11 Mar '04

Display transforms in tkmedit are broken for certain types of data in the 20040218 release. Please download one of these updates if you are having trouble: Darwin, 1890KB: ftp://surfer.nmr.mgh.harvard.edu/pub/dist/tkmedit-20040311-Darwin.tar.gz Linux, 1712KB: ftp://surfer.nmr.mgh.harvard.edu/pub/dist/tkmedit-20040311-Linux.tar.gz To unpack, move the file you download to your freesurfer/ directory, cd there, and run "tar zxvf <filename>". It will install bin/<OS>/tkmedit and lib/tcl/tkmedit.tcl. -- Kevin Teich

1 0

Re: question about average7...
by Doug Greve 11 Mar '04

11 Mar '04

Ray Fix wrote: > > Hello List, > > Question 1: > Where does the sample average7 come from? I searched through the > manuals, googled, searched around a little but was unable to find any > info. For example, is this the averaged brains of 7 male subjects in > there 40s? It's a 7th order icosahedron (163842 vertices). I think the orig coordinates are supposed to be talariach coordinates averaged over some subjects (but it does not overlay very well on the talairach brain). Bruce can give you more details. > Question 2: > My plan is to create my own ICBM labels using average7 and then apply > them via mri_label2label to two groups of subjects (which happen to be > pediatric data). Does this stand any chance of working? I would be > very interested if their are any other approaches you recommend. It all depends on how you're going to map the labels. What coordinate system are the ICBM labels in? doug > Thanks for your guidance, > > Ray Fix -- Douglas N. Greve, Ph.D. MGH-NMR Center greve(a)nmr.mgh.harvard.edu Phone Number: 617-724-2358 Fax: 617-726-7422

2 1

parcellation - missing areas
by Rutvik Desai 10 Mar '04

10 Mar '04

When converting annotations to labels, mri_annotation2label shows some missing areas (it prints "Skipping"). Are these areas skipped because the parcellation algorithm as not able to find clear boundries to define them? Is there a way to get around this (i.e., have the algorithm take its best guess about that area)? thanks, Rutvik

2 1

talairach transformation
by Sergey A Solovyev 10 Mar '04

10 Mar '04

Hi, I am getting consistent errors with one subject. After running: >mri_convert orig orig/orig.mnc >mritotal -verbose -debug -clobber -protocol icbm orig/orig.mnc transforms/talairach.xfm (or, >talairach $subj_id >talairach2 $subj_id, does not matter) I check if it is correct: view the talairach transform in tkmedit by clicking on the VOLUME button to start tkmedit (or starting it directly on the command line), then doing file->transforms->load transform for main volume, and selecting the talairach.xfm. If it is correct, the transferred brain should be slightly tilted forward, and the inter-hemispheric fissure should be pretty much vertical (with x=0 on the midline). Unfortunately, I am getting a significant leftward shift (in coronal orientation). Surface reconstruction is problematic. For example, in the left hemisphere it seems that no voxels to the right of the (0 0 0) point were used. Therefore, lh surface is 50% of what it should be, topology is very wrong... Any attempt to fix it with manually defining the cutting planes, or editing the volume, failed.. Could you please suggest how to fix talairach transformation? thank you, Serge

1 0

choosing parcellation schemes
by Frederic Dick 10 Mar '04

10 Mar '04

Hi all is there a flag in parcellate_subject for switching between the two parcellation schemes (Destrieux/Kennedy et al)? Or maybe the latter isn't included in the distribution yet? (I didn't see it in $CSURF_DIR/average...) cheers, Fred

2 1

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Freesurfer March 2004