Re: [Freesurfer] LGI of annotated cortex
Thanks for responce, Dough. I've looked at recon-all as you suggested, and came up with the following commandline: mris_anatomical_stats -mgz -f lh.lgi.stats -b -a ../label/lh.aparc.annot -c ../label/lgi.annot.ctab $SUBJECT lh pial_lgi This, however yields segfault: INFO: assuming MGZ format for volumes. computing statistics for each annotation in ../label/lh.aparc.annot. reading volume $SUBJECT/mri/wm.mgz... reading input surface $SUBJECT/surf/lh.pial_lgi... Segmentation fault I'm wondering whether this could be related to the fact that mris_anatomical_stats, calculates mean and stdev on the per-vertex basis over the defined label, while here we want it to calculate LGI, which is not calculated in this manner. Thanks, Martin On Thursday 08 May 2008 18:32:28 Doug Greve wrote: > use mris_anatomical_stats. Look in recon-all to see how to invoke it. > You can create another stats file (can't add it to the one that is > already there). > > doug > > Martin Kavec wrote: > >Hi, > > > >is it possible to obtain LGI values of cortices, similarly as curvature > >indices in ?h.aparc.stats? Could this value possibly be included in > >the ?h.aparc.stats files? > > > >Thanks in advance, > > > >Martin ___ Freesurfer mailing list Freesurfer@nmr.mgh.harvard.edu https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
Re: [Freesurfer] LGI of annotated cortex
Martin, Try instead the option -t pial_lgi as follows: mris_anatomical_stats -mgz -f lh.lgi.stats -b -a ../label/lh.aparc.annot -c ../label/ lgi.annot.ctab -t pial_lgi $SUBJECT lh Otherwise it will read lh.pial_lgi as a surface file, whereas it is indeed a thickness / curv file Have a nice day, Marie On 9 mai 08, at 10:29, Martin Kavec wrote: Thanks for responce, Dough. I've looked at recon-all as you suggested, and came up with the following commandline: mris_anatomical_stats -mgz -f lh.lgi.stats -b -a ../label/lh.aparc.annot -c ../label/lgi.annot.ctab $SUBJECT lh pial_lgi This, however yields segfault: INFO: assuming MGZ format for volumes. computing statistics for each annotation in ../label/lh.aparc.annot. reading volume $SUBJECT/mri/wm.mgz... reading input surface $SUBJECT/surf/lh.pial_lgi... Segmentation fault I'm wondering whether this could be related to the fact that mris_anatomical_stats, calculates mean and stdev on the per-vertex basis over the defined label, while here we want it to calculate LGI, which is not calculated in this manner. Thanks, Martin On Thursday 08 May 2008 18:32:28 Doug Greve wrote: use mris_anatomical_stats. Look in recon-all to see how to invoke it. You can create another stats file (can't add it to the one that is already there). doug Martin Kavec wrote: Hi, is it possible to obtain LGI values of cortices, similarly as curvature indices in ?h.aparc.stats? Could this value possibly be included in the ?h.aparc.stats files? Thanks in advance, Martin ___ 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] LGI of annotated cortex
Thanks a lot help, Marie. Indeed the -t switch worked. Now, the lh.aparc.stats (thickness) and my generated lh.lgi.stats (lGI) differ in the columns 4,5,6, which correspond to GrayVol, AverageThk, and StdevThk. Could you please help me to understand these values? 1. Why is the GM volume different in the two files (column 4)? 2. Is the average lGI in the column 5? 3. My impression is that the lGI is a property of an area, e.i. of the lateraloccipital cortex, so I would expect to get only a single value for the area. Thanks a lot in advance, Martin On Friday 09 May 2008 10:53:13 Marie Schaer wrote: > Martin, > > Try instead the option -t pial_lgi as follows: > > mris_anatomical_stats -mgz -f > > lh.lgi.stats -b -a ../label/lh.aparc.annot -c ../label/ > > lgi.annot.ctab -t pial_lgi > > $SUBJECT lh > > Otherwise it will read lh.pial_lgi as a surface file, whereas it is > indeed a thickness / curv file > > Have a nice day, > > Marie > > On 9 mai 08, at 10:29, Martin Kavec wrote: > > Thanks for responce, Dough. > > > > I've looked at recon-all as you suggested, and came up with the > > following > > commandline: > > > > mris_anatomical_stats -mgz -f > > lh.lgi.stats -b -a ../label/lh.aparc.annot -c ../label/lgi.annot.ctab > > $SUBJECT lh pial_lgi > > > > This, however yields segfault: > > > > INFO: assuming MGZ format for volumes. > > computing statistics for each annotation in ../label/lh.aparc.annot. > > reading volume $SUBJECT/mri/wm.mgz... > > reading input surface $SUBJECT/surf/lh.pial_lgi... > > Segmentation fault > > > > I'm wondering whether this could be related to the fact that > > mris_anatomical_stats, calculates mean and stdev on the per-vertex > > basis over > > the defined label, while here we want it to calculate LGI, which is > > not > > calculated in this manner. > > > > Thanks, > > > > Martin > > > > On Thursday 08 May 2008 18:32:28 Doug Greve wrote: > >> use mris_anatomical_stats. Look in recon-all to see how to invoke it. > >> You can create another stats file (can't add it to the one that is > >> already there). > >> > >> doug > >> > >> Martin Kavec wrote: > >>> Hi, > >>> > >>> is it possible to obtain LGI values of cortices, similarly as > >>> curvature > >>> indices in ?h.aparc.stats? Could this value possibly be included in > >>> the ?h.aparc.stats files? > >>> > >>> Thanks in advance, > >>> > >>> Martin > > > > ___ > > 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] LGI of annotated cortex
Martin, As lgi is read like a thickness file, the lgi values in your tabular output replaced the value where you had thickness before. So mean lgi is in column 4 (note that average lgi values per parcell are comprised between 1 and 5 if your lgi computation is ok). Standard deviation for lgi is in column 5. The other columns should not change if you run mris_anatomical_stats without the -t option (i.e on the thickness). About your last point, the main difference between gyrification index as previously computed (e.g. Zilles 1988) and local gyrification index is indeed the increased spatial resolution: you get one lgi value per cortical vertex (i.e. >100'000 lgi values over the hemisphere). Thus, the lgi per parcell from mris_anatomical_stats is the average lgi over all vertices included in each cortical parcel. Does it make sense? Marie On 9 mai 08, at 14:21, Martin Kavec wrote: Thanks a lot help, Marie. Indeed the -t switch worked. Now, the lh.aparc.stats (thickness) and my generated lh.lgi.stats (lGI) differ in the columns 4,5,6, which correspond to GrayVol, AverageThk, and StdevThk. Could you please help me to understand these values? 1. Why is the GM volume different in the two files (column 4)? 2. Is the average lGI in the column 5? 3. My impression is that the lGI is a property of an area, e.i. of the lateraloccipital cortex, so I would expect to get only a single value for the area. Thanks a lot in advance, Martin On Friday 09 May 2008 10:53:13 Marie Schaer wrote: Martin, Try instead the option -t pial_lgi as follows: mris_anatomical_stats -mgz -f lh.lgi.stats -b -a ../label/lh.aparc.annot -c ../label/ lgi.annot.ctab -t pial_lgi $SUBJECT lh Otherwise it will read lh.pial_lgi as a surface file, whereas it is indeed a thickness / curv file Have a nice day, Marie On 9 mai 08, at 10:29, Martin Kavec wrote: Thanks for responce, Dough. I've looked at recon-all as you suggested, and came up with the following commandline: mris_anatomical_stats -mgz -f lh.lgi.stats -b -a ../label/lh.aparc.annot -c ../label/ lgi.annot.ctab $SUBJECT lh pial_lgi This, however yields segfault: INFO: assuming MGZ format for volumes. computing statistics for each annotation in ../label/lh.aparc.annot. reading volume $SUBJECT/mri/wm.mgz... reading input surface $SUBJECT/surf/lh.pial_lgi... Segmentation fault I'm wondering whether this could be related to the fact that mris_anatomical_stats, calculates mean and stdev on the per-vertex basis over the defined label, while here we want it to calculate LGI, which is not calculated in this manner. Thanks, Martin On Thursday 08 May 2008 18:32:28 Doug Greve wrote: use mris_anatomical_stats. Look in recon-all to see how to invoke it. You can create another stats file (can't add it to the one that is already there). doug Martin Kavec wrote: Hi, is it possible to obtain LGI values of cortices, similarly as curvature indices in ?h.aparc.stats? Could this value possibly be included in the ?h.aparc.stats files? Thanks in advance, Martin ___ 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] LGI of annotated cortex
Thanks a lot for clarification, Marie. On Friday 09 May 2008 14:37:46 Marie Schaer wrote: > Martin, > > As lgi is read like a thickness file, the lgi values in your tabular > output replaced the value where you had thickness before. So mean lgi > is in column 4 (note that average lgi values per parcell are > comprised between 1 and 5 if your lgi computation is ok). Standard > deviation for lgi is in column 5. The other columns should not change > if you run mris_anatomical_stats without the -t option (i.e on the > thickness). Well, the point is that the 3rd column (not counting the structure name) is changed as well. This corresponds to GM volume, which is (almost) systematically larger in the lh.lgi.stats. Should it really be the same? This is already off my questions, but I am just saying that as a feedback. Thanks a lot, Martin ___ Freesurfer mailing list Freesurfer@nmr.mgh.harvard.edu https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
Re: [Freesurfer] LGI of annotated cortex
On my understanding, the GM volume given by mris_anatomical_stats should be the same independently of the -t option (unless you reprocessed the surfaces in between), so that's surprising. Doug, do you have any idea? Marie On 9 mai 08, at 15:12, Martin Kavec wrote: Thanks a lot for clarification, Marie. On Friday 09 May 2008 14:37:46 Marie Schaer wrote: Martin, As lgi is read like a thickness file, the lgi values in your tabular output replaced the value where you had thickness before. So mean lgi is in column 4 (note that average lgi values per parcell are comprised between 1 and 5 if your lgi computation is ok). Standard deviation for lgi is in column 5. The other columns should not change if you run mris_anatomical_stats without the -t option (i.e on the thickness). Well, the point is that the 3rd column (not counting the structure name) is changed as well. This corresponds to GM volume, which is (almost) systematically larger in the lh.lgi.stats. Should it really be the same? This is already off my questions, but I am just saying that as a feedback. Thanks a lot, Martin ___ Freesurfer mailing list Freesurfer@nmr.mgh.harvard.edu https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
Re: [Freesurfer] LGI of annotated cortex
Just a thought, but I suspect that the volume is calculated as some product of area * "thickness". Then, with the -t option, what FS is using as thickness is now really the lgi value. So, the "volume" value is really not appropriate in that case. cheers, Mike H. On Fri, 2008-05-09 at 15:28 +0200, Marie Schaer wrote: > On my understanding, the GM volume given by mris_anatomical_stats > should be the same independently of the -t option (unless you > reprocessed the surfaces in between), so that's surprising. > > Doug, do you have any idea? > > Marie > > > On 9 mai 08, at 15:12, Martin Kavec wrote: > > > Thanks a lot for clarification, Marie. > > > > On Friday 09 May 2008 14:37:46 Marie Schaer wrote: > >> Martin, > >> > >> As lgi is read like a thickness file, the lgi values in your tabular > >> output replaced the value where you had thickness before. So mean lgi > >> is in column 4 (note that average lgi values per parcell are > >> comprised between 1 and 5 if your lgi computation is ok). Standard > >> deviation for lgi is in column 5. The other columns should not change > >> if you run mris_anatomical_stats without the -t option (i.e on the > >> thickness). > > > > Well, the point is that the 3rd column (not counting the structure > > name) is > > changed as well. This corresponds to GM volume, which is (almost) > > systematically larger in the lh.lgi.stats. Should it really be the > > same? This > > is already off my questions, but I am just saying that as a feedback. > > > > Thanks a lot, > > > > Martin > > ___ > 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] Fixing Inaccuracies in White Matter Surfaces
Hi Pradeep, it's impossible to tell if it's an error from a single slice. Things that look like holes may actually just be sulci if you page through a couple of slices. You should also be looking at the intensity volume (e.g. norm.mgz) not just the wm.mgz. If the surface follows the gray/white boundary everywhere then you are all set. The problems occur if for example a lesion causes the topology correction to put the surface in the incorrect location in order to get the correct topology. cheers, Bruce On Tue, 6 May 2008, Pradeep Reddy Ramana wrote: Hello Everybody, This is Pradeep Reddy, just started my PhD in Medical Image Analysis and hence a newbie to FreeSurfer. I've passed the auto-recon2 stage in the reconstruction procedure. Now I am trying to verify WM segmentation produced by the recon-all/auto-recon2, before I move on to further processing. The excercise given in the freesurfer tutorial ( http://surfer.nmr.mgh.harvard.edu/fswiki/FsTutorial/WhiteMatterEdits ) gives me one example on how to detect if there were a lesion and outlines how to fix it. But now when I observe the outputs I have, I am quite confused as to how to detect inaccuracies in the segmentation of white matter. To make it more specific, I show you a slice of wm.mgh I have ( wmConfusion1 attached). Please look at the small yellow circle on the right. If I just follow the exercise, this looks like a lesion, as the yellow line cuts into it. but when I move up to next few slices, this hole opens up ( close to the green line ) giving me indications that it may NOT be a hole ( keeping in mind the inherent 3D nature of the MR image ). Also I am not sure whether there is an error in the image ( wmConfusion5 ) attched is an error is WM segmentation. So my questions: 1. What are the things I have to look for, while trying to verify the WM segmentation ( after autorecon2 )? 2. Any thumb-rules laid out for this already? My googling was in fact in vain. 3. Any other tutorials/resources/books stating clearly what to verify, in different stages of reconstruction? I am sorry to write a long email. Please be kind to help me in this regard. Regards, Pradeep Reddy PhD Student, Simon Fraser Unviersity, Canada. ___ Freesurfer mailing list Freesurfer@nmr.mgh.harvard.edu https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
[Freesurfer] unpacksdcmdir issue
Hello, I am getting an error saying that the path from the findsession command is not found. Here is the bugr information and following is the log from my terminal window; could anyone explain why the directory from findsession is missing? THANKS! FREESURFER_HOME: /usr/local/freesurfer/stable4 Build stamp: freesurfer-Linux-centos4-stable-v4.0.4-20080508 RedHat release: CentOS release 5 (Final) Kernel info: Linux 2.6.18-8.1.15.el5 i686 NMR Center info (/space/freesurfer exists): machine: striatum SUBJECTS_DIR: /space/amaebi/35/users/ablood/R01_Botox PWD: /space/amaebi/35/users/ablood/R01_Botox striatum:jake[81] cd /space/amaebi/35/users/ablood/R01_Botox striatum:jake[82] source /usr/local/freesurfer/nmr-std-env freesurfer-Linux-centos4-stable-v4.0.4-20080508 Setting up environment for FreeSurfer/FS-FAST (and FSL) FREESURFER_HOME /usr/local/freesurfer/stable4 FSFAST_HOME /usr/local/freesurfer/stable4/fsfast FSF_OUTPUT_FORMAT nii SUBJECTS_DIR /space/sake/3/users/inverse/subjects MNI_DIR /usr/local/freesurfer/stable4/mni FSL_DIR /usr/pubsw/packages/fsl/current [striatum:R01_Botox] (nmr-std-env) setenv SUBJECTS_DIR /space/amaebi/35/users/ablood/R01_Botox [striatum:R01_Botox] (nmr-std-env) findsession CD_RO1BTX_pat1_sess1 === SUBJECT: CD_RO1BTX_pat1_sess1 SUBJ ID: CD_RO1BTX_pat1_sess1 DATE : May 03, 2008 TIME : 19:27:12 XPRMNTR: PATH : /space/archive/160/siemens/TrioTim-35162-20080503-192630-556000 [striatum:R01_Botox] (nmr-std-env) unpacksdcmdir -src /space/archive/160/siemens/TrioTim-35162-20080503-192630-556000 -targ /space/amaebi/35/users/ablood/R01_Botox/CD_R01BTX_pat1_sess1 -scanonly CD_RO1BTX_pat1_sess1_info $Id: unpacksdcmdir,v 1.19.2.2 2008/03/11 19:56:38 nicks Exp $ /autofs/space/amaebi_035/users/ablood/R01_Botox -src /space/archive/160/siemens/TrioTim-35162-20080503-192630-556000 -targ /space/amaebi/35/users/ablood/R01_Botox/CD_R01BTX_pat1_sess1 -scanonly CD_RO1BTX_pat1_sess1_info Fri May 9 10:51:51 EDT 2008 mri_convert -all-info ProgramName: mri_convert ProgramArguments: -all-info ProgramVersion: $Name: stable4 $ TimeStamp: 2008/05/09-14:51:51-GMT BuildTimeStamp: May 8 2008 03:44:12 CVS: $Id: mri_convert.c,v 1.146.2.2 2008/03/02 02:53:20 nicks Exp $ User: jake Machine: striatum Platform: Linux PlatformVersion: 2.6.18-8.1.15.el5 CompilerName: GCC CompilerVersion: 30400 striatum Linux striatum 2.6.18-8.1.15.el5 #1 SMP Mon Oct 22 08:32:04 EDT 2007 i686 i686 i386 GNU/Linux ERROR: directory /space/archive/160/siemens/TrioTim-35162-20080503-192630-556000 does not exist [striatum:R01_Botox] (nmr-std-env) cd /space/archive/160/siemens/ /space/archive/160/siemens/: No such file or directory. [striatum:R01_Botox] (nmr-std-env) ___ Freesurfer mailing list Freesurfer@nmr.mgh.harvard.edu https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
Re: [Freesurfer] unpacksdcmdir issue
Questions on infrastructure issues at the Martinos Center like disk volumes you should direct to the Martinos IT support group at [EMAIL PROTECTED] I see no problem on striatum right now. It can see /space/archive/160/siemens/TrioTim-35162-20080503-192630-556000 just fine. Looks like you rebooted it about 2 hours ago so that might have cleared whatever automount problem there was. On Fri, 9 May 2008 [EMAIL PROTECTED] wrote: Hello, I am getting an error saying that the path from the findsession command is not found. Here is the bugr information and following is the log from my terminal window; could anyone explain why the directory from findsession is missing? THANKS! FREESURFER_HOME: /usr/local/freesurfer/stable4 Build stamp: freesurfer-Linux-centos4-stable-v4.0.4-20080508 RedHat release: CentOS release 5 (Final) Kernel info: Linux 2.6.18-8.1.15.el5 i686 NMR Center info (/space/freesurfer exists): machine: striatum SUBJECTS_DIR: /space/amaebi/35/users/ablood/R01_Botox PWD: /space/amaebi/35/users/ablood/R01_Botox striatum:jake[81] cd /space/amaebi/35/users/ablood/R01_Botox striatum:jake[82] source /usr/local/freesurfer/nmr-std-env freesurfer-Linux-centos4-stable-v4.0.4-20080508 Setting up environment for FreeSurfer/FS-FAST (and FSL) FREESURFER_HOME /usr/local/freesurfer/stable4 FSFAST_HOME /usr/local/freesurfer/stable4/fsfast FSF_OUTPUT_FORMAT nii SUBJECTS_DIR /space/sake/3/users/inverse/subjects MNI_DIR /usr/local/freesurfer/stable4/mni FSL_DIR /usr/pubsw/packages/fsl/current [striatum:R01_Botox] (nmr-std-env) setenv SUBJECTS_DIR /space/amaebi/35/users/ablood/R01_Botox [striatum:R01_Botox] (nmr-std-env) findsession CD_RO1BTX_pat1_sess1 === SUBJECT: CD_RO1BTX_pat1_sess1 SUBJ ID: CD_RO1BTX_pat1_sess1 DATE : May 03, 2008 TIME : 19:27:12 XPRMNTR: PATH : /space/archive/160/siemens/TrioTim-35162-20080503-192630-556000 [striatum:R01_Botox] (nmr-std-env) unpacksdcmdir -src /space/archive/160/siemens/TrioTim-35162-20080503-192630-556000 -targ /space/amaebi/35/users/ablood/R01_Botox/CD_R01BTX_pat1_sess1 -scanonly CD_RO1BTX_pat1_sess1_info $Id: unpacksdcmdir,v 1.19.2.2 2008/03/11 19:56:38 nicks Exp $ /autofs/space/amaebi_035/users/ablood/R01_Botox -src /space/archive/160/siemens/TrioTim-35162-20080503-192630-556000 -targ /space/amaebi/35/users/ablood/R01_Botox/CD_R01BTX_pat1_sess1 -scanonly CD_RO1BTX_pat1_sess1_info Fri May 9 10:51:51 EDT 2008 mri_convert -all-info ProgramName: mri_convert ProgramArguments: -all-info ProgramVersion: $Name: stable4 $ TimeStamp: 2008/05/09-14:51:51-GMT BuildTimeStamp: May 8 2008 03:44:12 CVS: $Id: mri_convert.c,v 1.146.2.2 2008/03/02 02:53:20 nicks Exp $ User: jake Machine: striatum Platform: Linux PlatformVersion: 2.6.18-8.1.15.el5 CompilerName: GCC CompilerVersion: 30400 striatum Linux striatum 2.6.18-8.1.15.el5 #1 SMP Mon Oct 22 08:32:04 EDT 2007 i686 i686 i386 GNU/Linux ERROR: directory /space/archive/160/siemens/TrioTim-35162-20080503-192630-556000 does not exist [striatum:R01_Botox] (nmr-std-env) cd /space/archive/160/siemens/ /space/archive/160/siemens/: No such file or directory. [striatum:R01_Botox] (nmr-std-env) ___ Freesurfer mailing list Freesurfer@nmr.mgh.harvard.edu https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer -- --- Paul Rainesemail: raines at nmr.mgh.harvard.edu MGH/MIT/HMS Athinoula A. Martinos Center for Biomedical Imaging 149 (2301) 13th Street Charlestown, MA 02129USA ___ Freesurfer mailing list Freesurfer@nmr.mgh.harvard.edu https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
[Freesurfer] Optseq2 and 2-way design?
Hello all, I am new to Optseq2 and I have a question about generating 2-way design orders using the program and about a question about temporal jitter. I am working on a design with 7 conditions. I have run the following design through optseq2 and gotten out reasonable looking orders. --ntp 160 --tr 3 --psdwin 0 21 --ev imi_touch 3 20 --ev imi_separate 3 20 --ev obs_touch 3 20 --ev obs_separate 3 20 --ev exe_touch 3 20 --ev exe_separate 3 20 --ev ident 3 20 - -o pilot_order_evrltd --nsearch 1 --nkeep 3 1) The stimuli are hand signs presented for 3 seconds each and there are 20 repetitions for each of the conditions. The conditions that have seperate or touch in their labels involve presentation of the same set of hand signs in each condition; the different conditions just involve doing different things in response to seeing these hand signs, e.g. imitating or observing them, etc. For example, ev imi_touch, obs_touch and ev exe_touch involve seeing the same set of 20 signs and either observing, imitating or executing them. So, while I'm not interested in analyzing responses to the 20 different hands signs separately, I also don't want the same sign to appear in different conditions successively or even close in time, i.e. imitate and then observe the same sign close in time. I'm wondering if there is a way to tell optseq2 all of this information so that it will generate an order specifying not only my conditions but also randomize the specific repetition of the condition. Basically I want all of the considerations such as psdwin taken into account for condition order and only randomization taken into account for the order of trial repetitions. Somehow I need to let optseq know that the same repetition numbers in different conditions are linked. Is there any way to do this with Optseq2? If not, can you suggest some way I can achieve this, perhaps using optseq2 for condition order and then another program for trial order? Thanks! 2) The second question I have is regarding ISI jitter. I have heard that it is optimal in fast event-related designs that the stimulus duration NOT be a multiple of the TR, yet it seems that this is what optseq is looking for. It doesn't seem that optseq is generating jitter between successive stimuli but only between successive presentations of the same condition. Is this all that is necessary for deconvolution of the signal during post processing, or is a jittered ISI between successive stimuli also necessary (or desirable), and if so, how can this be achieved? One strategy I have heard of is moving the stimulus onset time around within a larger TR. For example shifting a 1.5 sec stimulus around within a 3 sec TR to create temporal jitter. Is this type of timing something optseq could generate? Thanks. Liz ___ Freesurfer mailing list Freesurfer@nmr.mgh.harvard.edu https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
[Freesurfer] mri_mask
Hi, I have tried applying a binary mask, specifically for STG, in conjunction with the mri_mask command. We applied it to a brainmask volume, but we did not get the result we wanted. The output we recieved was simply the mask that we used. We wish to produce an output that gives the STG volume alone from the brain, and not from the binary mask. Are we using the command incorrectly? Thanks -- Daniel Horim Choi Northwestern University Class of 2009 [EMAIL PROTECTED] or [EMAIL PROTECTED] ___ Freesurfer mailing list Freesurfer@nmr.mgh.harvard.edu https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
[Freesurfer] Re: mri_mask
Please note the command we used: mri_mask brainmask.mgz lh.stg.mask.mgz brainout.mgz and the result we got was: Writing masked volume to brainout.mgz...done. On Fri, May 9, 2008 at 2:39 PM, Daniel H Choi <[EMAIL PROTECTED]> wrote: > Hi, > > I have tried applying a binary mask, specifically for STG, in conjunction > with the mri_mask command. We applied it to a brainmask volume, but we did > not get the result we wanted. The output we recieved was simply the mask > that we used. We wish to produce an output that gives the STG volume alone > from the brain, and not from the binary mask. Are we using the command > incorrectly? Thanks > > -- > Daniel Horim Choi > Northwestern University > Class of 2009 > [EMAIL PROTECTED] or > [EMAIL PROTECTED] -- Daniel Horim Choi Northwestern University Class of 2009 [EMAIL PROTECTED] or [EMAIL PROTECTED] ___ Freesurfer mailing list Freesurfer@nmr.mgh.harvard.edu https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
