Freesurfer

freesurfer@nmr.mgh.harvard.edu

19 participants
30132 discussions

Recon-all error
by Rapuano, Kristina (NIH/NIMH) [F] 10 Nov '10

10 Nov '10

Hello again, As a new freesurfer-er, I have one more question: I have another recon-all script that failed during the skull stripping step. It says it exited with errors, but does not actually specify any "ERROR" messages or even warnings. This the last thing it runs before failing: register_mri: find_optimal_transform find_optimal_transform: nsamples 3481, passno 0, spacing 8 GCAhistoScaleImageIntensities: could not find wm peak resetting wm mean[0]: 117 --> 126 resetting gm mean[0]: 74 --> 74 input volume #1 is the most T1-like using real data threshold=9.0 skull bounding box = (48, 56, 22) --> (201, 204, 220) using (99, 105, 121) as brain centroid... mean wm in atlas = 126, using box (80,87,97) --> (117, 123,145) to find MRI wm before smoothing, mri peak at 0 after smoothing, mri peak at 0, scaling input intensities by inf Any ideas why this could be happening? Please help! Thank you very much, Kristina ---- Kristina Rapuano Post-Bac IRTA Laboratory of Brain and Cognition, NIMH/NIH/DHHS Building 10, Room 4C214 10 Center Drive MSC 1366 Bethesda MD 20892-1366 Phone: (301) 402-4419 E-Mail : rapuanokm(a)mail.nih.gov

3 2

Confused with Monte Carlo results
by Adam Nitenson 10 Nov '10

10 Nov '10

Hi Freesurfers I'm a bit confused as to some recent Monte Carlo findings I've been looking at. After generating 10,000 estimations with mri_glmfit. I used mri_surfcluster to generate nii, ocn.nii, and .sum files to analyze the clusters. However I found that, when looking at the dACC, the cluster within an ROI (label) specific analysis, which almost filled the entire label, was not significant, yet the dACC region cluster in the label-free, whole brain analysis was significant. I figured that, since the whole brain (no label) monte carlo analysis compares the clusters to the entire brain and the label analysis confines the cluster to just the label, that the latter would result in a more signifcant cluster (since it fills up almost all of the space under consideration). However, I have found the opposite, and don't understand why this is. Any ideas would be greatly appreciated. I've written my commands below (Stable 4). Thanks, Adam mri_glmfit --y /autofs/space/ventzl_036/users/RespMon12C/group-analysis/Adam_25MatchedControls_genotyped/RM_correct_error/error_vs_correct/lh.ces.005.nii --fsgd /autofs/space/ventzl_036/users/RespMon12C/fsgd_and_contrast_files/Adam_25MatchedControls_genotyped.fsgd --C /autofs/space/ventzl_036/users/RespMon12C/fsgd_and_contrast_files/CHomozyg_Minus_TCarrier.mtx --surf fsaverage lh --sim mc-full 1000 1.3 /autofs/space/ventzl_036/users/RespMon12C/group-analysis/Adam_25MatchedControls_genotyped/RM_correct_error/CC_Minus_T/Monte_Carlo_LH_error_vs_correct_6sec/LH_MCSIM1 --fwhm 16.351771 mri_surfcluster --in /autofs/space/ventzl_036/users/RespMon12C/group-analysis/Adam_25MatchedControls_genotyped/RM_correct_error/CC_Minus_T/LH_error_vs_correct_6sec/CHomozyg_Minus_TCarrier/sig.mgh --csd /autofs/space/ventzl_036/users/RespMon12C/group-analysis/Adam_25MatchedControls_genotyped/RM_correct_error/CC_Minus_T/Monte_Carlo_LH_error_vs_correct_6sec/LH_MCSIM1-CHomozyg_Minus_TCarrier.csd ....(rest of monte carlo files).... --srcsubj fsaverage --thmax infinity --annot aparc --clabel /autofs/space/ventzl_036/users/RespMon12C/subjects/fsaverage/label/lh.dACC.All56Grouplabel --sum /autofs/space/ventzl_036/users/RespMon12C/group-analysis/Adam_25MatchedControls_genotyped/RM_correct_error/CC_Minus_T/MC_Findings/LH_56Group_dACC.sum --o /autofs/space/ventzl_036/users/RespMon12C/group-analysis/Adam_25MatchedControls_genotyped/RM_correct_error/CC_Minus_T/MC_Findings/LH_56Group_dACC.nii --ocn /autofs/space/ventzl_036/users/RespMon12C/group-analysis/Adam_25MatchedControls_genotyped/RM_correct_error/CC_Minus_T/MC_Findings/LH_56Group_dACC.ocn.nii mri_surfcluster --in /autofs/space/ventzl_036/users/RespMon12C/group-analysis/Adam_25MatchedControls_genotyped/RM_correct_error/CC_Minus_T/LH_error_vs_correct_6sec/CHomozyg_Minus_TCarrier/sig.mgh --csd /autofs/space/ventzl_036/users/RespMon12C/group-analysis/Adam_25MatchedControls_genotyped/RM_correct_error/CC_Minus_T/Monte_Carlo_LH_error_vs_correct_6sec/LH_MCSIM1-CHomozyg_Minus_TCarrier.csd ........ --srcsubj fsaverage --thmax infinity --annot aparc --sum /autofs/space/ventzl_036/users/RespMon12C/group-analysis/Adam_25MatchedControls_genotyped/RM_correct_error/CC_Minus_T/MC_Findings/LH_WholeBrain.sum --o /autofs/space/ventzl_036/users/RespMon12C/group-analysis/Adam_25MatchedControls_genotyped/RM_correct_error/CC_Minus_T/MC_Findings/LH_WholeBrain.nii --ocn /autofs/space/ventzl_036/users/RespMon12C/group-analysis/Adam_25MatchedControls_genotyped/RM_correct_error/CC_Minus_T/MC_Findings/LH_WholeBrain.ocn.nii Adam Nitenson, B.S. Brain Genomics Lab Massachusetts General Hospital

2 1

working with labels
by swoodman＠nmr.mgh.harvard.edu 10 Nov '10

10 Nov '10

Hi All, We were wondering what is the best way to find the overlap of two label files? For example, we want to save the region where segmentation1.label and segmentation2.label files overlap. Additionaly, we also wanted to know if we could find this region for the overlap of three label files. Thanks for your help! Sandra

1 0

Re: [Freesurfer] Problem with mri_segstats
by Douglas N Greve 10 Nov '10

10 Nov '10

Hi Elizabeth, I'm cc'ing the list so that others may benefit from the answer: The labels that you are referencing are defined in the aparc.a2009s atlas, but the wmparc is generated from the aparc atlas. To generate a wmparc using the a2009s, run the following: cd $SUBJECTS_DIR/subject mri_aparc2aseg --s subject --labelwm --hypo-as-wm --rip-unknown --volmask --o mri/wmparc.a2009s.mgz --ctxseg aparc.a2009s+aseg.mgz --a2009s Then reference wmparc.a2009s.mgz instead of wmparc.mgz in the mri_segstats cmd doug Elizabeth Gutierrez wrote: > Hi Douglas, > Thank you for directing me towards reporting form. > Here is more information: > > FREESURFER_HOME: /software/Freesurfer/5.0.0 > > Build stamp: freesurfer-Linux-centos5_x86_64-stable-pub-v5.0.0 > > Debian version: squeeze/sid > > Kernel info: Linux 2.6.31-22-generic x86_64 > > 1) subject name - s120 > SUBJECTS_DIR - /mindhive/gablab/memory/sourcemem/fsdata_REM > > 2) the entire command-line executed > > *Successful -* mri_segstats --seg > /mindhive/gablab/memory/sourcemem/fsdata_REM/s120/mri/wmparc.mgz > --ctab-default --id 3001 --in fa.anat.mgh --sum fa.stats > > *Unsuccessful* - mri_segstats --seg > /mindhive/gablab/memory/sourcemem/fsdata_REM/s120/mri/wmparc.mgz > --ctab-default --id 3101 --in fa.anat.mgh --sum fa.stats > > also unsuccessful for other 30 ids from aparc2009 > -id 13112 --id 14112 --id 13113 --id 14113 --id 13114 --id 14114 --id > 13118 --id 14118 --id 13115 --id 14115 --id 13116 --id 14116 --id > 13123 --id 14123 --id 13137 --id 13138 --id 14138 --id 13148 --id > 14148 --id 13150 --id 14150 --id 13163 --id 14163 --id 13153 --id > 14153 --id 13154 --id 14154 --id 13155 --id 14155 > > > 3) the error message generated > Reporting on 0 segmentations > > > More on fa.stats file : > > > sysname Linux > # hostname ba6 > # machine x86_64 > # user eguti > # anatomy_type volume > # > # SegVolFile > /mindhive/gablab/memory/sourcemem/fsdata_REM/s120/mri/wmparc.mgz > # SegVolFileTimeStamp 2010/06/02 15:09:42 > # ColorTable /software/Freesurfer/5.0.0/FreeSurferColorLUT.txt > # ColorTableTimeStamp 2010/08/13 20:56:24 > # InVolFile fa.anat.mgh > # InVolFileTimeStamp 2010/11/05 17:09:14 > # InVolFrame 0 > # Only reporting non-empty segmentations > # VoxelVolume_mm3 1 > > > > On Wed, Nov 10, 2010 at 10:45 AM, Douglas N Greve > <greve(a)nmr.mgh.harvard.edu <mailto:greve@nmr.mgh.harvard.edu>> wrote: > > Hi Elizabeth, > > we'll need more info to track down the problem. Please take a look > at surfer.nmr.mgh.harvard.edu/fswiki/BugReporting > <http://surfer.nmr.mgh.harvard.edu/fswiki/BugReporting> for the > kinds of things we need. > > thanks > > doug > Elizabeth Gutierrez wrote: > > Hi, > > I've been trying to use mri_segstats on a FA map with a white > matter parcellation file (wmparc.mgz) but there might be a > problem in the program. When I open the fa.stats output file, > all the values (std.dev, etc) are 0.0000 for the 2009 table > parcellation ids. However, when I use the label id 251 (corpus > collosum) from the first few labels on the list, I get a > value. When I use the corpus collosum id for more current > labels like the aparc 2005 and 2009, I get 0.0000 again. > > Could there be a bug in the program? > > > -- > Elizabeth C. Gutierrez > Graduate Student > Department of Brain and Cognitive Sciences > Massachusetts Institute of Technology > ------------------------------------------------------------------------ > > _______________________________________________ > 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 > greve(a)nmr.mgh.harvard.edu <mailto:greve@nmr.mgh.harvard.edu> > Phone Number: 617-724-2358 Fax: 617-726-7422 > > Bugs: surfer.nmr.mgh.harvard.edu/fswiki/BugReporting > <http://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> > > > > 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. > > > > > -- > Elizabeth C. Gutierrez > Graduate Student > Department of Brain and Cognitive Sciences > Massachusetts Institute of Technology -- Douglas N. Greve, Ph.D. MGH-NMR Center greve(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

1 0

Talairach transform error
by Rapuano, Kristina (NIH/NIMH) [F] 10 Nov '10

10 Nov '10

Hello, I am fairly new to freesurfer, and recently encountered an error while running recon-all (-autorecon1 -autorecon2) during Talairach Failure Detection: talairach_afd -T 0.005 -xfm transforms/talairach.xfm ERROR: talairach_afd: Talairach Transform: transforms/talairach.xfm ***Fp=0.0001, pval=0.0000 < threshold=0.0050) I have looked at the tutorial on "fixing bad output from the talairach registration," however, when I open up the image with tkregister2, there are no green lines. It seems to me that I should be using those lines to align various anatomical points. I tried using the 's' key to turn the lines "on," but nothing seems to happen (and yes, the fmov box is set to 1.0). I appreciate any help you can give me, thanks! Kristina ---- Kristina Rapuano Post-Bac IRTA Laboratory of Brain and Cognition, NIMH/NIH/DHHS Building 10, Room 4C214 10 Center Drive MSC 1366 Bethesda MD 20892-1366 Phone: (301) 402-4419 E-Mail : rapuanokm(a)mail.nih.gov

1 0

Core dump during imgreg_4dfp
by Freesurfer Local Archive 10 Nov '10

10 Nov '10

Freesurfers, I am running freesurfer-Linux-centos5_x86_64-stable-pub-v5.0.0 on a Linux 2.6.18-164.11.1.el5_lustre.1.8.3 cluster and I have a group of subjects that consistently crash during the talairach transform with the following message in the recon-all.log: ERROR: mpr2mni305 failed, see transforms/talairach_avi.log The talairach_avi.log indicates that imgreg_4dfp abnormally terminates with a core dump: Reading image: /lustre/scratch/jjoncaja/freesurfer/average/711-2C_as_mni_average_305.4dfp.img dimensions: 256 256 256 mmppix: 1.0000 -1.0000 -1.0000 center: 128.0000 -129.0000 -129.0000 talsrcimg_g11.4dfp.img 256 256 256 1 1.000000 1.000000 1.000000 orientation T byte_order littleendian Reading image: talsrcimg_g11.4dfp.img dimensions: 256 256 256 mmppix: 1.0000 -1.0000 -1.0000 center: 128.0000 -129.0000 -129.0000 Abort (core dumped) ERROR: 'imgreg_4dfp /lustre/scratch/jjoncaja/freesurfer/average/711-2C_as_mni_average_305 none talsrcimg_g11 none talsrcimg_to_711-2C_as_mni_average_305_t4 4355' failed! status=134 ERROR: mpr2mni305 execution aborted This problem was replicated on FS 4.2, 4.3, and 5.0. While datasets I am analyzing were not exactly optimized for use with Freesurfer (screen shots attached), most of my subject either process okay or return error message identifying the problem. Before dropping the "core dump" subjects from the analysis I wanted to see what I can do to save them. If needed I can drop a tarball containing a single problematic subject into the filedrop or email the 001.mgz whichever is more convenient. Thank you in advance for all your help. Greetings, Jacek Jonca-Jasinski ღ >^..^< Jacek Jonca-Jasinski Texas Tech University As we act, let us not become the evil that we deplore. --Barbara Lee

2 2

selxavg-sess vs selxavg3-sess
by Katie Bettencourt 10 Nov '10

10 Nov '10

Hi all, I'm still trying to figure out what's going on with the differences I'm getting between selxavg-sess and selxavg3-sess. I"m using freesurfer4.5. I was using selxavg3-sess (as suggested on the wiki) but I was getting weird activation maps when I compared any condition vs. baseline, where most of the brain was more activity for baseline (which was fixation) - see the attached picture for act-fix-gamma-selxavg3-rh.png. So I ran selxavg-sess which was what I used to run with an older version of freesurfer, and when I did this I got a more appropriate picture - see act-fix-gamma-rh.png The experiment starts with fixation (baseline) so I tried running the analysis with and without skipping the first 2 TRs to account for the BOLD spike, but it makes no difference in the activation map. These are essentially the commands I ran: mkanalysis-sess.new -analysis loc_loc -TR 2 -paradigm loc.dat -designtype blocked -funcstem fmc -runlistfile loc_runs.txt -inorm -nconditions 2 -timewindow 20 -gammafit 2.25 1.25 mkcontrast-sess -analysis loc_loc -contrast shape_vs_fix -a 2 -c 0 selxavg3-sess -s 101006SP_loc_loc -df loc_loc.dir -analysis loc_loc Thoughts? Or should I just not use selxavg3-sess? Katie ---------- Forwarded message ---------- From: Katie Bettencourt <kcrum(a)bu.edu> Date: Tue, Nov 2, 2010 at 2:31 PM Subject: Questions about event related processing and selxavg-sess and selxavg3-sess To: freesurfer maillist <freesurfer(a)nmr.mgh.harvard.edu> Hi all, I've been trying to analyses both an event related and block design experiments and have noticed a couple things that are confusing me and I would appreciate any help anyone could give me. 1. In trying do the event-related analysis, I'm am a bit confused by the FIR vs Gamma analysis and the use of the time window and tprestim in the FIR analysis. I have an experiment with 6 set size conditions and 1 fixation condition. each trial is 6s long with a TR of 1.5 I have run both of these commands: mkanalysis-sess.new -analysis supIPS_loc -TR 1.5 -paradigm supIPS.dat -designtype event-related -funcstem fmc -motioncor -runlistfile supIPSruns.txt -inorm -nskip 2 -nconditions 6 -gammafit 2.25 1.25 mkanalysis-sess.new -analysis supIPS_loc -TR 1.5 -paradigm supIPS.dat -designtype event-related -funcstem fmc -motioncor -runlistfile supIPSruns.txt -inorm -nskip 2 -nconditions 6 -tprestim 2 -timewindow 20 The FIR gives me a time course window, which makes me think that perhaps that is the one I want to use, but it shows very little activation. This data has been previously analyzed in Brain Voyager, so I know it's not a case of the conditions not actually causing activation, but for some reason, the FIR analysis doesn't show any. I'm not sure if this is due to a bad time window/tprestim settings, or something else. However the gamma fit analysis shows a bunch of activity where I expect to see it, but no time course window. (attached are pngs of the differences for the act_vs_fixation comparison). 2. In addition, in both the event related (gamma) and a normal block design (different experiment) I get very different results (at least for certain comparisons) depending on whether I use selxavg-sess (with stxgrinder-sess for each contrast) or selxavg3-sess. The differences are shown in the attached pngs (act_vs_fix-gamma.png (which is the selxavg-sess and stxgrinder-sess analysis and act_vs_fix-gamma-selxavg3). In the block design, both selxavg3 and selxavg (+stxgrinder) give me very similar activation when comparing two non-null conditions (ie. shape_vs_noise) but very different (and similar to the differences in the attached pictures) activations when comparing against the null (ie shape_vs_fix or noise_vs_fix). What am I doing wrong here? Thanks for your help! Katie

2 1

Problem with mri_segstats
by Elizabeth Gutierrez 10 Nov '10

10 Nov '10

Hi, I've been trying to use mri_segstats on a FA map with a white matter parcellation file (wmparc.mgz) but there might be a problem in the program. When I open the fa.stats output file, all the values (std.dev, etc) are 0.0000 for the 2009 table parcellation ids. However, when I use the label id 251 (corpus collosum) from the first few labels on the list, I get a value. When I use the corpus collosum id for more current labels like the aparc 2005 and 2009, I get 0.0000 again. Could there be a bug in the program? -- Elizabeth C. Gutierrez Graduate Student Department of Brain and Cognitive Sciences Massachusetts Institute of Technology

2 1

Re: [Freesurfer] -noconform flag of mri_normalize doesn't work
by "Falk Lüsebrink" 10 Nov '10

10 Nov '10

Hi Bruce, I'm so sorry, I should have double-checked. You are completely right; mri_normalize does work perfectly fine. The conformation to 1mm isotropic is done in the last step of mri_nu_correct.mni. In the last step of mri_nu_correct.mni the --conform flag is used, which shouldn't be used: ************************************ mri_convert ./tmp.mri_nu_correct.mni.32343/nu1.mnc nu.mgz --like orig.mgz --conform mri_convert ./tmp.mri_nu_correct.mni.32343/nu1.mnc nu.mgz --like orig.mgz --conform $Id: mri_convert.c,v 1.166.2.2 2010/08/10 19:11:50 greve Exp $ reading from ./tmp.mri_nu_correct.mni.32343/nu1.mnc... TR=0.00, TE=0.00, TI=0.00, flip angle=0.00 i_ras = (-1, 0, 2.12874e-08) j_ras = (3.72529e-08, 0, -1) k_ras = (0, 1, 0) Original Data has (0.7, 0.7, 0.7) mm size and (321, 321, 321) voxels. Data is conformed to 1 mm size and 256 voxels for all directions INFO: transform src into the like-volume: orig.mgz changing data type from float to uchar (noscale = 0)... MRIchangeType: Building histogram Reslicing using trilinear interpolation writing to nu.mgz... Wed Nov 10 10:47:32 CET 2010 mri_nu_correct.mni done ************************************ Also attached is the recon-all.log and the output of mri_info of orig.mgz and nu.mgz. Thanks again, Falk Lüsebrink -------- Original-Nachricht -------- > Datum: Tue, 9 Nov 2010 21:06:49 -0500 (EST) > Von: Bruce Fischl <fischl(a)nmr.mgh.harvard.edu> > An: "Falk Lüsebrink" <falk.luese(a)gmx.net> > CC: freesurfer(a)nmr.mgh.harvard.edu > Betreff: Re: [Freesurfer] -noconform flag of mri_normalize doesn\'t work > Hi Falk, > > I just tried it and it seemed to work for me: > > mri_info Gaab20070225a/mri/rawavg.mgz > Volume information for Gaab20070225a/mri/rawavg.mgz > type: MGH > dimensions: 256 x 256 x 128 > voxel sizes: 1.0000, 1.0000, 1.3300 > type: SHORT (4) > fov: 256.000 > dof: 0 > xstart: -128.0, xend: 128.0 > ystart: -128.0, yend: 128.0 > zstart: -85.1, zend: 85.1 > TR: 2000.00 msec, TE: 3.44 msec, TI: 900.00 msec, flip angle: > 9.00 degrees > nframes: 1 > PhEncDir: ROW > ras xform present > xform info: x_r = 0.5924, y_r = 0.0086, z_r = -0.8056, c_r = > -9.9942 > : x_a = -0.7780, y_a = -0.2537, z_a = -0.5747, c_a = > 13.5548 > : x_s = 0.2093, y_s = -0.9672, z_s = 0.1436, c_s = > -22.2562 > > mri_normalize -noconform rawavg.mgz test.mgz > not interpolating and embedding volume to be 256^3... > reading from rawavg.mgz... > normalizing image... > MRInormInit: > Talairach origin at (142, 110, 71) > wsize 10, windows 14 above, 9 below > max gradient 1.000 > . > . > . > mri_info test.mgz > Volume information for test.mgz > type: MGH > dimensions: 256 x 256 x 128 > voxel sizes: 1.0000, 1.0000, 1.3300 > type: SHORT (4) > fov: 256.000 > dof: 0 > xstart: -128.0, xend: 128.0 > ystart: -128.0, yend: 128.0 > zstart: -85.1, zend: 85.1 > TR: 2000.00 msec, TE: 3.44 msec, TI: 900.00 msec, flip angle: > 9.00 degrees > nframes: 1 > PhEncDir: UNKNOWN > ras xform present > xform info: x_r = 0.5924, y_r = 0.0086, z_r = -0.8056, c_r = > -9.9942 > : x_a = -0.7780, y_a = -0.2537, z_a = -0.5747, c_a = > 13.5548 > : x_s = 0.2093, y_s = -0.9672, z_s = 0.1436, c_s = > -22.2562 > > > > On Tue, 9 Nov 2010, Falk > Lüsebrink wrote: > > > Dear FreeSurfers, > > > > The -noconform flag of mri_normalize doesn't seem to work properly in > the centos4_x86_64_stable-pub-v5.0.0 build. I have been trying to process a > volume with a native isotropic resolution of 0.7mm using recon-ll including > the -cm flag to conform the input to minimum. But during the normalization > of mri_normalize the volume is conformed to an isotropic resolution of 1mm. > > > > The flag is correctly used during mri_normalize, but it doesn't seem to > do anything. The recon-all log says: > > > > "not interpolating and embedding volume to be 256^3..." > > > > But the output volume T1.mgz is conformed to 256^3 and therefore to an > isotropic resolution of 1mm. This also happens if mri_normalize is used by > hand using the -noconform flag. > > > > A fix is highly appreciated. > > > > Thanks in advance, > > Falk Lüsebrink > > > > > > -- GRATIS! Movie-FLAT mit über 300 Videos. Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome

4 3

-noconform flag of mri_normalize doesn't work
by Falk Lüsebrink 09 Nov '10

09 Nov '10

Dear FreeSurfers, The -noconform flag of mri_normalize doesn't seem to work properly in the centos4_x86_64_stable-pub-v5.0.0 build. I have been trying to process a volume with a native isotropic resolution of 0.7mm using recon-ll including the -cm flag to conform the input to minimum. But during the normalization of mri_normalize the volume is conformed to an isotropic resolution of 1mm. The flag is correctly used during mri_normalize, but it doesn't seem to do anything. The recon-all log says: "not interpolating and embedding volume to be 256^3..." But the output volume T1.mgz is conformed to 256^3 and therefore to an isotropic resolution of 1mm. This also happens if mri_normalize is used by hand using the -noconform flag. A fix is highly appreciated. Thanks in advance, Falk Lüsebrink

2 2

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