Freesurfer

freesurfer@nmr.mgh.harvard.edu

30132 discussions

Re: [Freesurfer] Fwd: Freesurfer Digest, Vol 98, Issue 29
by Andrew C Yourich 26 Apr '12

26 Apr '12

I've replaced my old mris_expand file with the one downloaded from the link below, and now it is working perfectly. Thank you so much to all of you who helped me resolve this issue. I really appreciate it. - Andrew ________________________________________ From: Nick Schmansky [nicks(a)nmr.mgh.harvard.edu] Sent: Thursday, April 26, 2012 10:18 AM To: Andrew C Yourich Cc: Bruce Fischl; gramfort(a)nmr.mgh.harvard.edu Subject: Re: [Freesurfer] Fwd: Freesurfer Digest, Vol 98, Issue 29 i've posted a build for the mac here: ftp://surfer.nmr.mgh.harvard.edu/pub/dist/freesurfer/misc/macos-leopard-int… n. On Wed, 2012-04-25 at 15:02 +0000, Andrew C Yourich wrote: > If you all have a fixed binary for a Mac Pro running Mac OS 10.6.8 that you would be able to forward me, I would greatly appreciate it. > > Thanks, > Andrew > ________________________________________ > From: Bruce Fischl [fischl(a)nmr.mgh.harvard.edu] > Sent: Wednesday, April 25, 2012 8:56 AM > To: Alexandre Gramfort > Cc: Andrew C Yourich; Robert C Knowlton; freesurfer(a)nmr.mgh.harvard.edu > Subject: Re: Fwd: Freesurfer Digest, Vol 98, Issue 29 > > thanks Alex. > > If anyone needs a fix before the next release let us know what > hardware/software version you are running and we'll send you a binary > > cheers > Bruce > > On > Wed, 25 Apr 2012, Alexandre Gramfort wrote: > > > hi all, > > > > @bruce : I've just given a try your own binaries in > > > > ~fischl/dev/freesurfer/bin/ > > > > and it worked fine. It looks like a bug has been fixed since the last > > stable release. > > > > Alex > > > > On Tue, Apr 24, 2012 at 10:44 PM, Andrew C Yourich <ayourich(a)uab.edu> wrote: > >> Sadly, I haven't been able to determine the problem yet. I have tested the exact command that was suggested in both the Mac 5.1.0 version as well as the Windows/Ubuntu 5.1.0 virtual machine version, and neither have seemed to expand correctly when viewed in freeview. I won't have access to a machine running Linux natively until tomorrow. A colleague who runs Freesurfer 5.0 and 5.1.0 on a Linux machine is going to work with me to test if he has this issue as well. > >> > >> Do you know if there have been any changes to the code of the mris_expand binary since 4.0.2? If not, we may try using the mris_expand from that version on the recon-all results from a 5.1.0 segmentation to see if the issue truly is the expand binary or not. > >> > >> Any other suggestions you all have would be appreciated. > >> > >> Thanks, > >> Andrew > >> ________________________________________ > >> From: Alexandre Gramfort [gramfort(a)nmr.mgh.harvard.edu] > >> Sent: Tuesday, April 24, 2012 3:24 PM > >> To: Andrew C Yourich > >> Subject: Fwd: Fwd: Freesurfer Digest, Vol 98, Issue 29 > >> > >> hi, > >> > >> have you fixed your problem? I still don't manage to make it work? > >> > >> thanks > >> Alex > >> > >> ---------- Forwarded message ---------- > >> From: Alexandre Gramfort <gramfort(a)nmr.mgh.harvard.edu> > >> Date: Mon, Apr 23, 2012 at 7:10 PM > >> Subject: Re: Fwd: Freesurfer Digest, Vol 98, Issue 29 > >> To: Bruce Fischl <fischl(a)nmr.mgh.harvard.edu> > >> Cc: Nick Schmansky <nicks(a)nmr.mgh.harvard.edu>, ayourich(a)uab.edu, > >> Krish Subramaniam <krish(a)nmr.mgh.harvard.edu>, Ruopeng Wang > >> <rpwang(a)nmr.mgh.harvard.edu> > >> > >> > >>> not sure about the mac, I'll cc Nick, Krish and Ruopeng so that they can > >>> answer. > >> > >> could be due to my update of XCode this morning but things work fine > >> with freeview -f lh.white -v ../mri/T1.mgz > >> on my mac with lion. sorry for the noise > >> > >>> I built my own in ~fischl/dev/freesurfer/bin/freeview. Sure, put the > >>> surfaces somewhere I can look at them and I'll take a look > >> > >> see the files in : > >> > >> /homes/6/gramfort/cluster/work/data/MNE-sample-data/subjects/fsaverage/surf/lh.white.expanded > >> > >> that's the sample data we use for MNE. > >> > >> the log: > >> > >> $ mris_expand -thickness lh.white 0.5 lh.white.expanded > >> using distance as a % of thickness > >> expanding surface lh.white by 50.0% of thickness and writing it to > >> lh.white.expanded > >> reading thickness... > >> ending sse = 4485.856144 > >> nrounds = 6 > >> writing expanded surface to lh.white.expanded... > >> writing group avg surface area 822 cm^2 into surface file > >> surface expansion took 27 minutes and 15 seconds. > >> > >> Alex > >> > >> > >> The information in this e-mail is intended only for the person to whom it is > >> addressed. If you believe this e-mail was sent to you in error and the e-mail > >> contains patient information, please contact the Partners Compliance HelpLine at > >> http://www.partners.org/complianceline . If the e-mail was sent to you in error > >> but does not contain patient information, please contact the sender and properly > >> dispose of the e-mail. > > > > > > > _______________________________________________ > Freesurfer mailing list > Freesurfer(a)nmr.mgh.harvard.edu > https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer > >

2 1

using "label" flag w tksurfer
by Justin Baker 26 Apr '12

26 Apr '12

I've ported a tksurfer call from one system (NCF, where it was working) to another (MGH) and now the "label" argument is no longer recognized. Here is the command: tksurfer fsaverage5 lh inflated -o test.nii.gz -fthresh 3 -fmid 4.301 -fslope 1 -colscalebarflag 1 -label lh.17Networks_LH_ContA_Cinga.label -labels-under -tcl tksurfer_Taplin.tcl Can someone point me to the correct version of tksurfer? Thanks Justin

1 0

5.1.0 volume analysis in native space
by Maya Rosen 26 Apr '12

26 Apr '12

Hi all, In v5.1.0 is there a way to do a volume analysis in native space? I know when you do mkanalysis for the surface you can use -surface self. But for the volume analysis the only flag I see is -mni305. Is there some way to give it a native space flag for the volume? Thanks! Maya

1 0

Re: [Freesurfer] your insight: parameter definition and --tnullmin necessary?
by Betina Ip 26 Apr '12

26 Apr '12

Dear Doug, Thanks for your reply. I will compare conditions against the NULL, but the ultimate aim is to compare conditions against each other. The effect I am looking for will be very small, so I am trying to make sure I optimise the design- I really appreciate your insight. Miezin et al., 2000 NeuroImage showed that presenting flashing chequer boards with short ITI (min=2,5, mean=5s, TR=2.5 for events of 1.5 duration) resulted in highest power (mean z-score) for responses in the visual cortex compared to longer ITI. This is mainly due to the greater amount of trials shown per condition. They only used one stimulus condition and compared it to the NULL (consistent with scenario described in your point 2), however my aim is to compare different conditions against each other. I am concerned that the reduction in amplitude of closely spaced trials will affect the between-condition comparison. If the second of two closely spaced trials will have a reduced amplitude (your point 1) - and it is the amplitude between conditions I am interested, I'd be wiping out my effect of interest. If this is the case, introducing ITIs between each trial to bring back the amplitude of the second (and subsequent trials) would be better for between condition comparisons. Does this sound right? Many thanks for your patience in explaining. Betina On 04/24/2012 07:34 AM, Betina Ip wrote: > Dear Doug, > > Thank you for your excellent answers, they are very helpful. Please > allow me to summarise and ask for additional clarification: > > 1) The main problem I'd like to solve is, as you spotted, whether the > sequence will have required power to detect and effect (if there is > one!). So, please disagree with me if this is incorrect, but one way > to evaluate the potential of the sequence in terms of detecting an > effect would be to plug the condition files directly into a Fsl FEAT > analysis design matrix (FEAT>Stats>Full Model Setup> Efficiency), > which would come out with an efficiency/estimability % to detect a > statistically significant effect for a given comparison. The lower the > effect required, the more efficient the design. yes, that's fine. You'll have to enter a guess as to the level of the noise and the size of the effect. > > 2) The second question is related to spacing of NULL trials. I would > like to first run a univariate analysis and then run a multivariate > analysis. You mentioned NULL trials would be 'helpful'- could you > please clarify whether you mean having ANY null trials or having null > trials between EACH trial would be helpful? There are two answers to this. (1) The point I was trying make below is that two closely space non-null trials will result in a smaller amplitude for the 2nd. Putting a null between them helps to bring back the amplitude of the 2nd. For this you would need nulls between each event. (2) If you have a hypothesis in which you compare a condition against the null, then you need about as many null trials as you have any other condition and you don't necessarily need nulls between each condition (sounds like this is already the case). > > My current design is allocating as much total null time as for any > other condition (as recommended in freesurver list). This means that I > do have some NULL trials, and they are randomly inserted in the > sequence. However, most trials have no ITI between them. If I did > force ITIs between EACH trial I would have to decrease number of > trials for each condition type, which could lower the design efficiency. > > IF the problem of having carry-over effects of closely very spaced > trials (i.e. majority of trials with no separation between trials) > could be alleviated by rigorous first order counter-balancing within > Optseq2 using the --focb option, is it necessary at all to add a null > trial between EACH trial into the design? The carry over is not the problem, it is the reduction in amplitude for the 2nd of closely spaced trials. doug > > Thanks for your clarification. > > Best, > > Betina > > Hi Betina, see answers below > doug > > On 04/23/2012 12:04 PM, Betina Ip wrote: > >/ Dear Freesurfer list, > />/ > />/ I am using optseq2 for the first time and wanted to check with you > whether my protocol makes sense, many thanks in advance for your insight. > />/ > />/ 1) I start by choosing the maximum scan duration equalling ~30 min: > /You might want to break this up into shorter chunks. It's totally up to > you, you just don't need to have everything in a single run. > >/ 2) set the psd window so it can capture the entire waveform of a 4 second > >event > />/ 3) select equal amounts of trials for each of the 4 event types, I > played around with it and 80 trials give me the greatest efficiency (2.72) > and variance reduction factor average (54.37). Are these values acceptable? > They are the best I could get tweaking the number of trials. > /You can't tell whether a VRF of 54 is good enough. You are asking a > question about the power of your experiment, which optseq can't answer. > If you don't have an effect, then no number of trials or efficiency will > be good enough. Having said that, I usually shoot for a VRF of between > 20 and 40, but that's just a rule of thumb. > >/ > />/ The command is here: > />/ > />/ ./optseq2 --ntp 440 --tr 4 --psdwin 0 20 \ > />/ --ev evt1 4 80 \ > />/ --ev evt2 4 80 \ > />/ --ev evt3 4 80 \ > />/ --ev evt4 4 80 \ > />/ --nkeep 3 \ > />/ --o gfatrial \ > />/ --focb 10 \ > />/ --nsearch 10000 > />/ > />/ A sample trial list is here: > />/ > />/ 0.0000 2 4.000 1.0000 evt2 > />/ 4.0000 4 4.000 1.0000 evt4 > />/ 8.0000 0 4.000 1.0000 NULL > />/ 12.0000 3 4.000 1.0000 evt3 > />/ 16.0000 3 4.000 1.0000 evt3 > />/ 20.0000 2 4.000 1.0000 evt2 > />/ … > />/ > />/ The other question I had concerns the position of null trials. Many > trials are not separated by a NULL event, however studies of rapid > event-related designs to report a minimum ITI, in this case the minimum seems > to be 0? To assess the effect of forcing a minimum ITI on the sequence, I > have run the search defining the --tnullmin to 4 sec (equal to 1 TR) however > efficiency and VRFAvg drop to .79 and 16.07, obviously due to trade of > between ntp and ntrials (ntp=440, ntrials=62). > />/ > />/ Are NULL trials between each event required at all if a standard FIR is > used for the analysis? My aim is to first apply a univariate BOLD-analysis > and subsequently a multivariate analysis to the dataset. Thanks for > clarifying. > /They are not strictly necessary, however, they may be helpful. If you > really don't want them as part of your design (eg, it would interfere > with the psychology), then don't use them but make sure to optimize the > FOCB more (I usually use 100 regardless). The disadvantage of not having > the nulls is that there will probably be some non-linearity in that the > second of two closely spaced trials will have a lower amplitude than if > it occurred in isolation. This will hurt your power and might cause a > false difference between conditions if they are not well counter-balanced. > doug > >/ > />/ Betina > />/ _______________________________________________ > />/ Freesurfer mailing list > />/ Freesurfer at nmr.mgh.harvard.edu<http://nmr.mgh.harvard.edu> > <https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer> > />/ https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer > />/ > />/ > / > -- > Douglas N. Greve, Ph.D. > MGH-NMR Center > greve at nmr.mgh.harvard.edu<http://nmr.mgh.harvard.edu> > <https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer> > Phone Number: 617-724-2358 > Fax: 617-726-7422 > > Bugs: surfer.nmr.mgh.harvard.edu/fswiki/BugReporting > FileDrop:www.nmr.mgh.harvard.edu/facility/filedrop/index.html > <http://www.nmr.mgh.harvard.edu/facility/filedrop/index.html> > > > > _______________________________________________ > Freesurfer mailing list > Freesurfer(a)nmr.mgh.harvard.edu<mailto:Freesurfer@nmr.mgh.harvard.edu> > https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer -- Douglas N. Greve, Ph.D. MGH-NMR Center gr...(a)nmr.mgh.harvard.edu Phone Number: 617-724-2358 Fax: 617-726-7422 Bugs: surfer.nmr.mgh.harvard.edu/fswiki/BugReporting FileDrop: www.nmr.mgh.harvard.edu/facility/filedrop/index.html<http://www.nmr.mgh.harvard.edu/facility/filedrop/index.html> _______________________________________________ Freesurfer mailing list Freesurfer(a)nmr.mgh.harvard.edu<mailto:Freesurfer@nmr.mgh.harvard.edu> https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer The information in this e-mail is intended only for the person to whom it is addressed. If you believe this e-mail was sent to you in error and the e-mail contains patient information, please contact the Partners Compliance HelpLine at http://www.partners.org/complianceline . If the e-mail was sent to you in error but does not contain patient information, please contact the sender and properly dispose of the e-mail.

2 1

About GroupAnalysis
by bowang21＠mail.ustc.edu.cn 26 Apr '12

26 Apr '12

Dear All, I am learning GroupAnalysis and I have some problem about the vector that embodies the hypothesis we want to test(such as:0 0 0.5 0.5).I just want to know how each number of the vector involve in the calculating process of mri_glmfit.That is, I want to acquire some materials of how mri_glmfit process the data? Bobo

2 1

mri_convert - returns different image size
by Popescu, V. 26 Apr '12

26 Apr '12

Dear all, I want to use N3 on nifti images, and I have different versions installed on two machines. On one machine I have an older version of N3 (1.7.2.2) which uses mri_convert version 4 and everything works fine. On the other machine I have N3 version 1.12 which uses mri_convert version 5; this one returns a 256/256/256 image volume instead of the original-like volume. Is there anything I can do to "fix" it or is there a problem if I just use mri_convert version 4 instead of 5 for the newer N3? Thank you very much in advance! Best regards, Veronica Popescu VU University Medical Center, Department of Radiology De Boelelaan 1118, 1081 HZ Amsterdam, The Netherlands Room PK -1 X 108 Phone: +31 (0) 204 444 596 Fax: +31 (0) 204 440 397

3 8

longitudinal data check problem
by Charlotte Bernard 25 Apr '12

25 Apr '12

Dear Freesurfer users, I try to visualize my longitudinal data for one subject whit the command line given in the freesurfer website: freeview -v 00049_T1/mri/norm.mgz -f 00049_T1/surf/lh.pial:edgecolor=red 00049_T1/surf/rh.pial:edgecolor=red 00049_T1/surf/lh.white:edgecolor=blue 00049_T1/surf/rh.white:edgecolor=blue I can open the norm.mgz but then the sofware crash for pial and white surf! I have that error message: MatrixMultiply: m2 is null! I don't understand where the problem is? Can somebody help me? Thanks for all, Charlotte

2 1

trakula segmentation fault
by Viviana Siless 25 Apr '12

25 Apr '12

Hello, I'm trying to run trac-all prec and I'm getting a segmentation fault error. Loading streamlines from /media/vivi/code/freesurfer/trctrain/trc032/dlabel/mni/lh.cst_AS.flt.trk Loading streamline start ROI from /media/vivi/code/freesurfer/trctrain/trc033/dlabel/mni/lh.cst_AS_roi1.flt.nii.gz Loading streamline end ROI from /media/vivi/code/freesurfer/trctrain/trc033/dlabel/mni/lh.cst_AS_roi2.flt.nii.gz Loading streamlines from /media/vivi/code/freesurfer/trctrain/trc033/dlabel/mni/lh.cst_AS.flt.trk INFO: Rejected 0 streamlines for straying off mask INFO: Rejected 0 streamlines for reversing direction Segmentation fault Linux vivi-ThinkStation-C20X 2.6.38-8-generic #42-Ubuntu SMP Mon Apr 11 03:31:24 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux trac-preproc exited with ERRORS at Wed Apr 4 18:24:21 CEST 2012 - When I look at the trak-all.error I see this error: ------------------------------ SUBJECT 000000112288Proc DATE Wed Apr 4 18:24:21 CEST 2012 USER vivi HOST vivi-ThinkStation-C20X PROCESSOR x86_64 OS Linux Linux vivi-ThinkStation-C20X 2.6.38-8-generic #42-Ubuntu SMP Mon Apr 11 03:31:24 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux $Id: trac-preproc,v 1.17.2.5 2011/05/20 06:51:51 ayendiki Exp $ /media/vivi/code/freesurfer/bin/trac-preproc PWD /media/vivi/code/freesurfer CMD /media/vivi/code/freesurfer/bin/dmri_train --outdir /media/vivi/images/freesurfer/000000112288Proc/dlabel/mni --out lh.cst_AS_avg33_mni_flt rh.cst_AS_avg33_mni_flt lh.unc_AS_avg33_mni_flt rh.unc_AS_avg33_mni_flt lh.ilf_AS_avg33_mni_flt rh.ilf_AS_avg33_mni_flt fmajor_PP_avg33_mni_flt fminor_PP_avg33_mni_flt lh.atr_PP_avg33_mni_flt rh.atr_PP_avg33_mni_flt lh.ccg_PP_avg33_mni_flt rh.ccg_PP_avg33_mni_flt lh.cab_PP_avg33_mni_flt rh.cab_PP_avg33_mni_flt lh.slfp_PP_avg33_mni_flt rh.slfp_PP_avg33_mni_flt lh.slft_PP_avg33_mni_flt rh.slft_PP_avg33_mni_flt --slist /tmp/subj33.000000112288Proc.16360.txt --trk dlabel/mni/lh.cst_AS.flt.trk dlabel/mni/rh.cst_AS.flt.trk dlabel/mni/lh.unc_AS.flt.trk dlabel/mni/rh.unc_AS.flt.trk dlabel/mni/lh.ilf_AS.flt.trk dlabel/mni/rh.ilf_AS.flt.trk dlabel/mni/fmajor_PP.flt.trk dlabel/mni/fminor_PP.flt.trk dlabel/mni/lh.atr_PP.flt.trk dlabel/mni/rh.atr_PP.flt.trk dlabel/mni/lh.ccg_PP.flt.trk dlabel/mni/rh.ccg_PP.flt.trk dlabel/mni/lh.cab_PP.flt.trk dlabel/mni/rh.cab_PP.flt.trk dlabel/mni/lh.slfp_PP.flt.trk dlabel/mni/rh.slfp_PP.flt.trk dlabel/mni/lh.slft_PP.flt.trk dlabel/mni/rh.slft_PP.flt.trk --seg dlabel/mni/aparc+aseg.nii.gz --cmask dlabel/mni/cortex+2mm.nii.gz --lmask 16 16 0 0 0 0 0 0 10 49 0 0 0 0 0 0 0 0 --rois dlabel/mni/lh.cst_AS_roi1.flt.nii.gz dlabel/mni/lh.cst_AS_roi2.flt.nii.gz dlabel/mni/rh.cst_AS_roi1.flt.nii.gz dlabel/mni/rh.cst_AS_roi2.flt.nii.gz dlabel/mni/lh.unc_AS_roi1.flt.nii.gz dlabel/mni/lh.unc_AS_roi2.flt.nii.gz dlabel/mni/rh.unc_AS_roi1.flt.nii.gz dlabel/mni/rh.unc_AS_roi2.flt.nii.gz dlabel/mni/lh.ilf_AS_roi1.flt.nii.gz dlabel/mni/lh.ilf_AS_roi2.flt.nii.gz dlabel/mni/rh.ilf_AS_roi1.flt.nii.gz dlabel/mni/rh.ilf_AS_roi2.flt.nii.gz dlabel/mni/fmajor_PP_roi1.flt.nii.gz dlabel/mni/fmajor_PP_roi2.flt.nii.gz dlabel/mni/fminor_PP_roi1.flt.nii.gz dlabel/mni/fminor_PP_roi2.flt.nii.gz dlabel/mni/lh.atr_PP_roi1.flt.nii.gz dlabel/mni/lh.atr_PP_roi2.flt.nii.gz dlabel/mni/rh.atr_PP_roi1.flt.nii.gz dlabel/mni/rh.atr_PP_roi2.flt.nii.gz dlabel/mni/lh.ccg_PP_roi1.flt.nii.gz dlabel/mni/lh.ccg_PP_roi2.flt.nii.gz dlabel/mni/rh.ccg_PP_roi1.flt.nii.gz dlabel/mni/rh.ccg_PP_roi2.flt.nii.gz dlabel/mni/lh.cab_PP_roi1.flt.nii.gz dlabel/mni/lh.cab_PP_roi2.flt.nii.gz dlabel/mni/rh.cab_PP_roi1.flt.nii.gz dlabel/mni/rh.cab_PP_roi2.flt.nii.gz dlabel/mni/lh.slfp_PP_roi1.flt.nii.gz dlabel/mni/lh.slfp_PP_roi2.flt.nii.gz dlabel/mni/rh.slfp_PP_roi1.flt.nii.gz dlabel/mni/rh.slfp_PP_roi2.flt.nii.gz dlabel/mni/lh.slft_PP_roi1.flt.nii.gz dlabel/mni/lh.slft_PP_roi2.flt.nii.gz dlabel/mni/rh.slft_PP_roi1.flt.nii.gz dlabel/mni/rh.slft_PP_roi2.flt.nii.gz --bmask /media/vivi/images/freesurfer/000000112288Proc/dlabel/mni/aparc+aseg_mask.nii.gz --fa /media/vivi/images/freesurfer/000000112288Proc/dmri/mni/dtifit_FA.flt.nii.gz --ncpts 5 --debug - If I run that command, I get the same (of course): INFO: Rejected 0 streamlines for straying off mask INFO: Rejected 0 streamlines for reversing direction Segmentation fault Can anybody give me an idea of the problem? I run recon-all and finished without errors. I attach the log file, the error file, and my dmrirc file. Please let me know if you need anything else. Thanks in advance! Viviana Siless -- Parietal Team, INRIA Saclay Neurospin, Centre CEA de Saclay 91191 Gif sur Yvette – FRANCE

2 7

Re: [Freesurfer] bbregister for fmri FEAT data
by Erlend Hodneland 25 Apr '12

25 Apr '12

Both the fmri data registered to orig is mismatched, and also the original raw fmri data are mismatched with orig, see the link here showing our raw data (fmri, orig and 152MNI) shown in fslview http://vedlegg.uib.no/?id=297a1242fa82b4b7565b470806254c5a It is orig.nii converted from orig.mgz that we show yes. Erlend What images are mismatched? Specifically, which anatomical image are you loading into fslview? If you have not loaded the orig.mgz (converted to nii), then there will be be a mismatch. doug On 04/24/2012 04:29 AM, Erlend Hodneland wrote: > Hi again, > > We are trying to do the same as was done in Trachtenberg et al 2012 > (Neurobiology of Aging), ie opt.the commonly used FLIRT+FNIRT registration in > FEAT with BBreg: > > "For group analysis, functional data were registered, via the high resolution > anatomical image, to the Montreal Neurological Institute (MNI) standard > brain. Functional data were aligned to the anatomical image initially using > FMRIB's Linear Image Registration Tool, (FLIRT) ([Jenkinson and Smith, 2001] > <http://www.sciencedirect.com/science/article/pii/S0197458010004926#bib27> > and[Jenkinson et al., 2002] > <http://www.sciencedirect.com/science/article/pii/S0197458010004926#bib28>), > then optimized using the Boundary-Based Registration (BBR) approach (Greve > and Fischl, 2009 > <http://www.sciencedirect.com/science/article/pii/S0197458010004926#bib21>). > Registration from anatomical to standard space was carried out using FMRIB’s > Non-Linear Image Registration Tool (FNIRT)." > > > That is, flirt from fmri --> brain, then initializing bbregister fmri --> > brain by the previous flirt registration, then flirt and fnirt from brain --> > standard space and finally fmri --> standard space and putting all these > transformations together. > > > However, our images are orientad as follows from top -> bottom (fmri, orig, > 152MNI): > > http://vedlegg.uib.no/?id=297a1242fa82b4b7565b470806254c5a > > As shown in the previous communication, when we directly apply the images to > the registration the results are oriented incorrectly, as the input images. > > Can you recommend a specific solution to overcome the orientation mismatch in > these images which is compatible with the registration tasks? > > > Thank you for your patience and help! > > > All best > > E.H. > > > Hi Erlend, while the images in the tkregister2 pics are oriented > correctly the registration is way off. What images are you loading into > fslview? You'll need to convert the orig.mgz into nii and load that to > check the registration. > doug > > On 04/22/2012 04:16 AM, Erlend Hodneland wrote: > > Hi again, > > > > the registration looks fine in tkregister2, but is apparently wrong in > > fslview (and also mricron). See the attached files (as link from > > http://vedlegg.uib.no/?id=399ad2cce1a3138f8eb4f6a06f4acfc4) showing > > screenshots of fslview and tkregister2. How can this be explained, and > > how can we visualize the correct orientation in fslview? > > What does this misalignment influence any further processing with > > fnirt and concatenation of the affine transformation fields? > > > > This is our command we run for bbregister: > > > > bbregister --s subj_505 --mov vol0001.nii.gz --reg register-test.dat > > --init-fsl --t2 --o test.nii.gz > > > > where vol0001 is the first volume in the fmri sequence and is flipped > > to align with LAS (as the highres). > > > > Thank you for your kind help, > > > > Erlend Hodneland > > > > ean that it is in the wrong orientation? It should be in > > the same orientation as the anatomical. How does the reg look in > > tkregister2? Note that fslview can display volumes in odd orientations > > even when the orientation is correct. > > doug > > > > On 04/13/2012 03:31 AM, Erlend Hodneland wrote: > > > Hi, > > > > > > we are trying to register fmri FEAT data (example_func.nii) to the > > > anatomical scan (processed in Freesurfer) using bbregister to opt. > > > the affine registration before running FNIRT. > > > > > > However, the orientation of the registered image is flipped around and > > > is incorrect after applying bbregister. > > > > > > We have tried: > > > > > > 1) bbregister --s subj_501 --mov example_func.nii.gz --reg > > > register.dat --init-header --bold --o example_func2highres-fs.nii > > > 2) bbregister --s subj_501 --mov example_func.nii.gz --reg > > > register.dat --init-fsl --bold --o example_func2highres-fs.nii > > > 3) bbregister --s subj_501 --o example_func2highres-fs.nii --feat > > > "myfeatdirectory" > > > 4) tkregister2 --mov example_func.nii --regheader --reg tkreg.dat > > > (this one looks correct) > > > followed by > > > bbregister --s subj_501 --mov example_func.nii.gz --reg register.dat > > > --init-reg tkreg.dat --bold --o example_func2highres-fs.nii > > > > > > 5) reorienting to match the highres: > > > > > > fslorient -swaporient example_func > > > fslswapdim example_func x -y z example_func_swap (correct > > > orientation) > > > > > > followed by > > > bbregister --s subj_501 --mov example_func_swap.nii.gz --reg > > > register.dat --init-fsl --bold --o example_func_swap2highres-fs.nii > > > > > > with the output being flipped in wrong orientation for all options. > > > > > > We would greatly appreciate if you have any suggestions for how to > > > overcome this problem! > > > > > > Cheers/Sincerly/All best > > > > > > Erlend Hodneland > > > > > > > > > > _______________________________________________ > > Freesurfer mailing list > > Freesurfer(a)nmr.mgh.harvard.edu <mailto:Freesurfer@nmr.mgh.harvard.edu <Freesurfer(a)nmr.mgh.harvard.edu>> > > https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer > > > > _______________________________________________ > Freesurfer mailing list > Freesurfer(a)nmr.mgh.harvard.edu > https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer -- Douglas N. Greve, Ph.D. MGH-NMR Centergr...(a)nmr.mgh.harvard.edu Phone Number: 617-724-2358 Fax: 617-726-7422

2 1

Parcellation Colorscale
by Baum, Sarah H 25 Apr '12

25 Apr '12

Hi- I'm looking to compare two parcellations (one is a stroke patient with her brain as is, the other is the same subject with the lesion "fixed" run as a separate subject). It would be helpful if the parcellations would color the same area the same color, but currently every single ROI is colored differently than the corresponding parcellation in the other subject's brain. I looked up the color table in the .annot file, and the RGB coordinates listed for each region are exactly the same for each surface volume. Is there any easy way to make the colors the same? If it helps— I use AFNI/SUMA for visualizing data. Thanks in advance, Sarah Sarah H. Baum Ph.D. Candidate, Neuroscience Sarah.H.Baum(a)uth.tmc.edu w: 713.500.5089 c: 571.225.7007

2 7

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Freesurfer