Freesurfer

freesurfer@nmr.mgh.harvard.edu

16 participants
30084 discussions

Md5sum download mismatch
by john.dornisch＠scra.org 08 Apr '09

08 Apr '09

Hello, I am having a problem downloading the latest version of freesurfer 4.3. On 2 separate servers on 2 separate days I get the same md5sum which does not match the md5sums listed in the md5sum file in the downloads section. your md5s 29450bd531d94909cc858384551d43b0 freesurfer-Linux-centos4_x86_64-stable-pub-v4.3.0-full.tar.gz df4c679702d3bf01c458276a93a90547 freesurfer-Linux-centos4-stable-pub-v4.3.0-full.tar.gz My md5sums 54de93353546c88ed9dc7b9de0b2384d freesurfer-Linux-centos4-stable-pub-v4.3.0-full.tar.gz 6da2363ffc42e9c65a22033ad057748c freesurfer-Linux-centos4_x86_64-stable-pub-v4.3.0-full.tar.gz Please advise. Thanks John Dornisch

2 1

mri_ca_train parameters?
by Jamie Hanson 08 Apr '09

08 Apr '09

Hi Freesufer folks- I was just about to start constructing a custom aseg atlas and I wondered if there were any recommendations for any of the optional flags? Any parameters yield better results (especially for specific brain regions)? I was focused on improving amygdala segmentation for my structural images (hence my asking). Best, jamie. -- Jamie L. Hanson Waisman Laboratory for Brain Imaging & Behavior | Child Emotion Research Lab University of Wisconsin - Madison 1500 Highland Avenue Madison, WI 53705 Email: jamielarshanson(a)gmail.com Homepage: http://tezpur.keck.waisman.wisc.edu/~hanson/

3 3

RES: [Freesurfer] libvtkpng.so.5.2 missing?
by Pedro Paulo de Magalhaes Oliveira Junior 08 Apr '09

08 Apr '09

run yum list | grep vtk | grep png Sent from my Nokia phone @E71 -----Msg original----- De: Derin Cobia Enviada: 08/04/2009 15:56:27 Assunto: [Freesurfer] libvtkpng.so.5.2 missing? We're running subjects under the new 4.3.0 version (CentOS 4 platform), and are experiencing the following error during the cortical ribbon mask stage: -------------------------------------------------------------------------------------------- #@# Cortical ribbon mask Wed Apr 8 07:12:20 CDT 2009 /disk/NIACAL/human/freesurfer/conte_mprage_v4.3/020319_2263/mri mris_volmask --label_left_white 2 --label_left_ribbon 3 -- label_right_white 41 --label_right_ribbon 42 --save_ribbon -- save_distance 020319_2263 mris_volmask.bin: error while loading shared libraries: libvtkpng.so. 5.2: cannot open shared object file: No such file or directory Linux heinz 2.6.18-92.el5 #1 SMP Tue Apr 29 13:16:15 EDT 2008 x86_64 x86_64 x86_64 GNU/Linux recon-all exited with ERRORS at Wed Apr 8 07:12:21 CDT 2009 -------------------------------------------------------------------------------------------- It appears that libvtkpng.so.5.2 does indeed not exist (in fact, no libvtkpng* files were found) in ~/freesurfer/lib/vtk/lib/vtk-5.2 for the current 4.3.0 CentOS 4 (32-bit) distribution we have, but found them present in our 4.1.0 (32-bit) and 4.3.0 (64-bit) distros . This may just be a case of "the missing libraries," but are they supposed to be gone? If not, are we safe to just copy them into the 4.3.0 vtk dir as a short term fix? Thanks. -Derin _______________________________________________ Freesurfer mailing list Freesurfer(a)nmr.mgh.harvard.edu https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer

1 0

libvtkpng.so.5.2 missing?
by Derin Cobia 08 Apr '09

08 Apr '09

We're running subjects under the new 4.3.0 version (CentOS 4 platform), and are experiencing the following error during the cortical ribbon mask stage: -------------------------------------------------------------------------------------------- #@# Cortical ribbon mask Wed Apr 8 07:12:20 CDT 2009 /disk/NIACAL/human/freesurfer/conte_mprage_v4.3/020319_2263/mri mris_volmask --label_left_white 2 --label_left_ribbon 3 -- label_right_white 41 --label_right_ribbon 42 --save_ribbon -- save_distance 020319_2263 mris_volmask.bin: error while loading shared libraries: libvtkpng.so. 5.2: cannot open shared object file: No such file or directory Linux heinz 2.6.18-92.el5 #1 SMP Tue Apr 29 13:16:15 EDT 2008 x86_64 x86_64 x86_64 GNU/Linux recon-all exited with ERRORS at Wed Apr 8 07:12:21 CDT 2009 -------------------------------------------------------------------------------------------- It appears that libvtkpng.so.5.2 does indeed not exist (in fact, no libvtkpng* files were found) in ~/freesurfer/lib/vtk/lib/vtk-5.2 for the current 4.3.0 CentOS 4 (32-bit) distribution we have, but found them present in our 4.1.0 (32-bit) and 4.3.0 (64-bit) distros . This may just be a case of "the missing libraries," but are they supposed to be gone? If not, are we safe to just copy them into the 4.3.0 vtk dir as a short term fix? Thanks. -Derin

1 0

v 1.20 asegstats2table bug
by Victoria Williams 08 Apr '09

08 Apr '09

Hello, I am having a bit of trouble using asegstats2table. I have tried using different versions of this command and if only I could combine the two, it would work perfectly. I am trying to compile wmparc stats for about 160 subjects. Unlike the new aparcstats2table, asegstats2table seems to not have the capacity to only report segmentations common to all subjects. Therefore, I end up with about 160 subjects with unmatching columns in the table. The first version of asegstats2table I tried was v 1.8 in my stable4 environment. This version allowed me to specify the --statsfile as wmparc.stats. However, I could not exclude segmentations such as the wm-hypointensities that was not common to all subjects and was messing up my table. The newer 1.20 version in the dev environment does let me specify --no-segno, however it is not recognizing the --statsfile flag although it is mentioned in the usage, and gives the following error: leia:tori:~[82] asegstats2table --version $Id: asegstats2table,v 1.20 2009/04/07 18:18:09 krish Exp $ leia:tori:CVRAM[87] asegstats2table --subjects CVRAM_001_recon CVRAM_002_recon CVRAM_003_recon CVRAM_004_recon CVRAM_005_recon CVRAM_006_recon CVRAM_007_recon CVRAM_008_recon CVRAM_009_recon CVRAM_010_recon CVRAM_011_recon CVRAM_012_recon CVRAM_013_recon CVRAM_014_recon CVRAM_016_recon CVRAM_017_recon CVRAM_018_recon CVRAM_019_recon CVRAM_020_recon CVRAM_021_recon CVRAM_022_recon CVRAM_023_recon CVRAM_024_recon CVRAM_025_recon CVRAM_026_recon CVRAM_027_recon CVRAM_028_recon CVRAM_029_recon CVRAM_030_recon CVRAM_031_recon CVRAM_032_recon CVRAM_033_recon CVRAM_034_recon CVRAM_035_recon CVRAM_036_recon CVRAM_037_recon CVRAM_038_recon CVRAM_040_recon CVRAM_041_recon CVRAM_042_recon CVRAM_043_recon CVRAM_044_recon CVRAM_045_recon CVRAM_046_recon CVRAM_047_recon CVRAM_048_recon CVRAM_050_recon CVRAM_051_recon CVRAM_052_recon CVRAM_053_recon CVRAM_054_recon CVRAM_055_recon CVRAM_057_recon CVRAM_058_recon CVRAM_059_recon CVRAM_060_recon CVRAM_061_recon CVRAM_062_recon CVRAM_063_recon CVRAM_064_recon CVRAM_066_recon CVRAM_067_recon CVRAM_068_recon CVRAM_069_recon CVRAM_070_recon CVRAM_072_recon CVRAM_073_recon CVRAM_074_recon CVRAM_075_recon CVRAM_076_recon CVRAM_077_recon CVRAM_078_recon CVRAM_079_recon CVRAM_080_recon CVRAM_081_recon CVRAM_082_recon CVRAM_083_recon CVRAM_084_recon CVRAM_085_recon CVRAM_086_recon CVRAM_087_recon CVRAM_089_recon CVRAM_090_recon CVRAM_091_recon CVRAM_092_recon CVRAM_093_recon CVRAM_095_recon CVRAM_096_recon CVRAM_097_recon CVRAM_098_recon CVRAM_099_recon CVRAM_100_recon CVRAM_101_recon CVRAM_103_recon CVRAM_104_recon CVRAM_1045_recon CVRAM_1046_recon CVRAM_105_recon CVRAM_106_recon CVRAM_108_recon CVRAM_109_recon CVRAM_111_recon CVRAM_112_recon CVRAM_113_recon CVRAM_114_recon CVRAM_115_recon CVRAM_117_recon CVRAM_118_recon CVRAM_119_recon CVRAM_120_recon CVRAM_121_recon CVRAM_122_recon CVRAM_124_recon CVRAM_125_recon CVRAM_126_recon CVRAM_127_recon CVRAM_128_recon CVRAM_129_recon CVRAM_130_recon CVRAM_131_recon CVRAM_132_recon CVRAM_133_recon CVRAM_135_recon CVRAM_136_recon CVRAM_138_recon CVRAM_139_recon CVRAM_140_recon CVRAM_142_recon CVRAM_143_recon CVRAM_144_recon CVRAM_145_recon CVRAM_146_recon CVRAM_147_recon CVRAM_148_recon CVRAM_149_recon CVRAM_151_recon CVRAM_152_recon CVRAM_153_recon CVRAM_154_recon CVRAM_155_recon CVRAM_156_recon CVRAM_157_recon CVRAM_158_recon CVRAM_159_recon --no-segno 77 78 79 80 81 82 --subdir stats --statsfile wmparc-nonzero.stats --tablefile STATS2/stats_tables-cvram/WMparc_stats_nonzero_04082009.txt asegstats2table: error: no such option: --statsfile I also tried this: leia:tori:CVRAM[88] asegstats2table --subjects CVRAM_001_recon CVRAM_002_recon CVRAM_003_recon CVRAM_004_recon CVRAM_005_recon CVRAM_006_recon CVRAM_007_recon CVRAM_008_recon CVRAM_009_recon CVRAM_010_recon CVRAM_011_recon CVRAM_012_recon CVRAM_013_recon CVRAM_014_recon CVRAM_016_recon CVRAM_017_recon CVRAM_018_recon CVRAM_019_recon CVRAM_020_recon CVRAM_021_recon CVRAM_022_recon CVRAM_023_recon CVRAM_024_recon CVRAM_025_recon CVRAM_026_recon CVRAM_027_recon CVRAM_028_recon CVRAM_029_recon CVRAM_030_recon CVRAM_031_recon CVRAM_032_recon CVRAM_033_recon CVRAM_034_recon CVRAM_035_recon CVRAM_036_recon CVRAM_037_recon CVRAM_038_recon CVRAM_040_recon CVRAM_041_recon CVRAM_042_recon CVRAM_043_recon CVRAM_044_recon CVRAM_045_recon CVRAM_046_recon CVRAM_047_recon CVRAM_048_recon CVRAM_050_recon CVRAM_051_recon CVRAM_052_recon CVRAM_053_recon CVRAM_054_recon CVRAM_055_recon CVRAM_057_recon CVRAM_058_recon CVRAM_059_recon CVRAM_060_recon CVRAM_061_recon CVRAM_062_recon CVRAM_063_recon CVRAM_064_recon CVRAM_066_recon CVRAM_067_recon CVRAM_068_recon CVRAM_069_recon CVRAM_070_recon CVRAM_072_recon CVRAM_073_recon CVRAM_074_recon CVRAM_075_recon CVRAM_076_recon CVRAM_077_recon CVRAM_078_recon CVRAM_079_recon CVRAM_080_recon CVRAM_081_recon CVRAM_082_recon CVRAM_083_recon CVRAM_084_recon CVRAM_085_recon CVRAM_086_recon CVRAM_087_recon CVRAM_089_recon CVRAM_090_recon CVRAM_091_recon CVRAM_092_recon CVRAM_093_recon CVRAM_095_recon CVRAM_096_recon CVRAM_097_recon CVRAM_098_recon CVRAM_099_recon CVRAM_100_recon CVRAM_101_recon CVRAM_103_recon CVRAM_104_recon CVRAM_1045_recon CVRAM_1046_recon CVRAM_105_recon CVRAM_106_recon CVRAM_108_recon CVRAM_109_recon CVRAM_111_recon CVRAM_112_recon CVRAM_113_recon CVRAM_114_recon CVRAM_115_recon CVRAM_117_recon CVRAM_118_recon CVRAM_119_recon CVRAM_120_recon CVRAM_121_recon CVRAM_122_recon CVRAM_124_recon CVRAM_125_recon CVRAM_126_recon CVRAM_127_recon CVRAM_128_recon CVRAM_129_recon CVRAM_130_recon CVRAM_131_recon CVRAM_132_recon CVRAM_133_recon CVRAM_135_recon CVRAM_136_recon CVRAM_138_recon CVRAM_139_recon CVRAM_140_recon CVRAM_142_recon CVRAM_143_recon CVRAM_144_recon CVRAM_145_recon CVRAM_146_recon CVRAM_147_recon CVRAM_148_recon CVRAM_149_recon CVRAM_151_recon CVRAM_152_recon CVRAM_153_recon CVRAM_154_recon CVRAM_155_recon CVRAM_156_recon CVRAM_157_recon CVRAM_158_recon CVRAM_159_recon --no-segno 77 78 79 80 81 82 --subdir stats/wmparc-nonzero.stats --tablefile STATS2/stats_tables-cvram/WMparc_stats_nonzero_04082009.txt Building the table.. SUBJECTS_DIR : /autofs/space/lang_012/users/CVRAM ERROR: cannot find /autofs/space/lang_012/users/CVRAM/CVRAM_001_recon/stats/wmparc-nonzero.stats/aseg.stats Use --skip flag if you want to continue in such cases So, it seems that it recognizes the --subdir flag, but is still looking for aseg.stats instead of a specified statsfile. Does anyone have any suggestions? Thanks! Tori

2 2

RE: [Freesurfer] Measuring cortical thickness with high resolution data
by Doug Greve 08 Apr '09

08 Apr '09

Falk, it looks like that file was somehow converted to DOS. try: dos2unix recon-all chmod a+x recon-all then re-run doug On Mon, 6 Apr 2009, Falk Lüsebrink wrote: > Hi Nick, > > I tried using your modified recon-all today but as soon as I try to process any data I receive following error message: > > 'nknown option: `- > Usage: tcsh [ -bcdefilmnqstvVxX ] [argument ...]. > > Also it doesn't matter at all which flags I add to recon-all or if I don't use any flags at all, the error is the same. The unmodified recon-all performs well. > > Regards, > Falk > > -----Original Message----- > From: freesurfer-bounces(a)nmr.mgh.harvard.edu [mailto:freesurfer-bounces@nmr.mgh.harvard.edu] On Behalf Of Nick Schmansky > Sent: Thursday, April 02, 2009 3:28 PM > To: Falk Lüsebrink > Cc: Freesurfer Mailing List > Subject: RE: [Freesurfer] Measuring cortical thickness with high resolution data > > Falk, > > There are no plans in the near future, but in the long term we'd like to remove the dependence on conforming the data. > > It just occurred to me that you could have the best of both worlds: > first run your data through the normal stream (conforming) up through autorecon1, then use mri_vol2vol to create a brainmask.mgz at the same resolution as that created using the -hires stream, and copy it over. > At least that would eliminate having to edit the original hires brainmask, which would save hours of work. If i get few minutes i will try this. > > You can copy that recon-all over top your existing v4.x freesurfer installation (attached again for the list). > > Nick > > > On Thu, 2009-04-02 at 10:58 +0200, Falk Lüsebrink wrote: >> Hi Nick, >> >> Thank you very much. I'll have to look into that and try to process some other volumes which might work a bit better, with less manual intervention. >> >> Are there any plans to improve Freesurfer in the (near) future so that hires data can be processed within the currently available stream? >> >> Regards, >> Falk >> >> -----Original Message----- >> From: Nick Schmansky [mailto:nicks@nmr.mgh.harvard.edu] >> Sent: Wednesday, April 01, 2009 7:53 PM >> To: Falk Lüsebrink >> Cc: Freesurfer Mailing List >> Subject: Re: [Freesurfer] Measuring cortical thickness with high >> resolution data >> >> Falk, >> >> Attached is a modified recon-all script where I've added a -hires switch to force the stream to not conform the data to 1mm^3, and to not use the atlases. >> >> Note that you should add the -clean flag to delete any work that had been done prior (namely, -clean deletes brainmask.mgz, aseg.mgz and wm.mgz). >> >> However, in working with the .8mm data that you sent me, working with hires data will require quite a bit of manual intervention due to the fact that the atlases normally used cannot be used. The first problem occurs in skull-stripping, where quite a bit of dura and skull remains, and seems to have intensity values close to gray matter. This would have to be manually erased on each of the slices. If it is not erased (I did not do this because of the amount of time required), then the wm.mgz file, which is what is tessellated to create the initial surface, will be very wrong (it tessellates the garbage surrounding the gray matter). >> >> See also Bruce's prior posting on the problems of working with hires data in freesurfer. >> >> Nick >> >> >> On Wed, 2009-03-25 at 13:04 +0100, Falk Lüsebrink wrote: >>> Hi Freesurfers, >>> >>> >>> >>> Iÿÿm trying to evaluate the usefulness of high resolution scans >>> acquired at 7T with an isometric voxel size of .6mm for the >>> measurement of cortical thickness. The inhomogeneities are taken >>> care of by dividing the scans with another scan of another sequence, >>> so they are not an issue anymore. >>> >>> >>> >>> My problem is that Freesurfer usually conforms the voxel size to 1mm >>> which is not desirable. I tried using the ÿÿcm and ÿÿnoaseg flags for >>> the recon-all process to avoid the conformation and to skip the >>> subcortical segmentation, but another problem arises while using >>> these flags. >>> >>> >>> >>> The error I receive is occurring after the WM Segmentation and >>> states as follows: >>> >>> >>> >>> #-------------------------------------------- >>> >>> #...@# WM Segmentation Wed Mar 18 10:14:42 CET 2009 >>> >>> >>> >>> cp wm.mgz wm.seg.mgz >>> >>> >>> >>> >>> >>> mri_segment -keep brain.mgz wm.seg.mgz >>> >>> >>> >>> preserving editing changes in output volume... >>> >>> doing initial intensity segmentation... >>> >>> using local statistics to label ambiguous voxels... >>> >>> computing class statistics for intensity windows... >>> >>> WM (106.0): 106.9 +- 5.8 [80.0 --> 125.0] >>> >>> GM (69.0) : 66.3 +- 11.6 [30.0 --> 96.0] >>> >>> setting bottom of white matter range to 77.9 >>> >>> setting top of gray matter range to 89.4 >>> >>> doing initial intensity segmentation... >>> >>> using local statistics to label ambiguous voxels... >>> >>> using local geometry to label remaining ambiguous voxels... >>> >>> >>> >>> reclassifying voxels using Gaussian border classifier... >>> >>> >>> >>> removing voxels with positive offset direction... >>> >>> smoothing T1 volume with sigma = 0.250 >>> >>> removing 1-dimensional structures... >>> >>> thickening thin strands.... >>> >>> 20 segments, 4813 filled >>> >>> 10270 bright non-wm voxels segmented. >>> >>> 5589 diagonally connected voxels added... >>> >>> white matter segmentation took 2.4 minutes >>> >>> writing output to wm.seg.mgz... >>> >>> ERROR: mri_segment-MRIcheckVolDims: volume1 height=256 != volume2 >>> height=320. >>> >>> >>> >>> The dimensions of the data Iÿÿm trying to process is 320 x 320 x 224 >>> and is changed to 320 x 320 x 320 while using the ÿÿcm flag. It seems >>> the mri_segment process canÿÿt handle any dimensions above 256 or Iÿÿm >>> missing another flag. >>> >>> >>> >>> Does someone has any ideas about that issue? >>> >>> >>> >>> Regards, >>> >>> Falk >>> >>> >>> _______________________________________________ >>> Freesurfer mailing list >>> 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 Center greve(a)nmr.mgh.harvard.edu 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

2 2

Masking brainmask based on surfaces
by Martin Kavec 08 Apr '09

08 Apr '09

Hi, I am trying to mask a non-brain tissue left by watershed based on the cortical surfaces. I found that all what I need to be left is in aparc+aseg.mgz, so I converted it to nifiti, along with brainmask.mgz and used FSL to binarize aparc+aseg and mask the brainmask. I found that at many places the results is too conservative and too much of the GM is missing, see the attached images, and particularly the temporal lobes. Is there a better approach to what I am trying to do and what could be the explanation to the results I get. Thanks, Martin

5 9

tksurfer Load Group Descriptor File error
by Jeff Sadino 07 Apr '09

07 Apr '09

Hello, Can someone help me get scatterplots of my data? I am using freesurfer 3.0.5. I have ran these commands: mris_preproc --fsgd try1.fsgd --target fsaverage --hemi lh --meas thickness --out lh.try1.mgh mri_surf2surf --hemi lh --s fsaverage --sval lh.try1.mgh --fwhm 10 --tval lh.try1.fw.mgh mri_glmfit --y lh.try1.fw.mgh --fsgd try1.fsgd dods --C try1.mtx --surf fsaverage lh --glmdir lh.try1.dir tksurfer fsaverage lh inflated -annot aparc.atlas2005_simple -overlay lh.try1.dir/try1.mtx/sig.mgh Then selected a vertex, then File->Load Group Descriptor File and selected try1.fsgd, but I get this error: WARNING: Marker for class ctrl was invalid. WARNING: Color for class ctrl was invalid. WARNING: Marker for class cd was invalid. WARNING: Color for class cd was invalid. This is try1.fsgd: GroupDescriptorFile 1 Title try1 MeasurementName thickness Class ctrl Class cd Variables Age Input 040004_P02 ctrl 55.18 Input 050046_S02 ctrl 37.45 ... ... Input 070073_S01 cd 20.54 Input 070114_OGM01 cd 46.03 I also tried with lh.try1.dir/y.fsgd, but get a similar error: INFO: ignoring tag Creator INFO: ignoring tag SUBJECTS_DIR INFO: ignoring tag SynthSeed INFO: gdfRead: reshaping WARNING: Marker for class ctrl was invalid. WARNING: Color for class ctrl was invalid. WARNING: Marker for class cd was invalid. WARNING: Color for class cd was invalid. y.fsgd looks like this: GroupDescriptorFile 1 Title try1 MeasurementName external Tessellation surface PlotFile /data/Jeff/glmtut/pass5/try1/lh.try1.fw.mgh DesignMatFile fsgd.X.mat dods ResidualFWHM 22.331472 Class ctrl Class cd Variables Age Input 040004_P02 ctrl 55.18 Input 050046_S02 ctrl 37.45 ... ... Input 070073_S01 cd 20.54 Input 070114_OGM01 cd 46.03 Creator mri_glmfit SUBJECTS_DIR /share/apps/freesurfer/subjects SynthSeed 1237057379 In both cases, a graph pops up, but it is blank. Thank you in advance for your suggestions, Jeff Sadino _________________________________________________________________ Hotmail® is up to 70% faster. Now good news travels really fast. http://windowslive.com/online/hotmail?ocid=TXT_TAGLM_WL_HM_70faster_032009

4 4

LGI trouble
by Gabriel Go.Es. 07 Apr '09

07 Apr '09

hello i'm running the LGI for all my subjects, and i have no problem with almost all, but, i recibe an error message with one subject, and just with the right hemisphere no problem when making Left hemisphere, does anybody knows what can i do for correcting that error and to calculate the LGI?. the error message is: ... lGI for vertex number 33301 of the outer mesh is 2.2086 lGI for vertex number 33401 of the outer mesh is 2.8605 ... remeasuring lGI value for vertex iV = 33501. It may take a few minutes. WARNING -- Problem for vertex iV = 33501, lGI value is aberrantly high (lGI=43.811)... ...lGI computation will be stopped. This may be caused by topological defects, check mris_euler_number on the pial surface. ERROR: compute_lgi did not create output file 'tmp-mris_compute_lgi-rh.pial/rh.pial_lgi.asc'! Linux localhost.localdomain 2.6.9-34.ELsmp #1 SMP Thu Mar 9 06:23:23 GMT 2006 x86_64 x86_64 x86_64 GNU/Linux recon-all exited with ERRORS at Fri Apr 3 19:47:35 CEST 2009 Regards Gabriel _________________________________________________________________ ¿Quieres que tus hijos naveguen seguros? Aprende aquí cómo con Protección Infantil http://www.protegeatushijos.com

2 1

Fwd: FW: XNAT update: Processing failed for PrenatalMA_13_MR_1
by Nurunisa Neyzi 06 Apr '09

06 Apr '09

Hi, just a quick question... We get this error: 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=6.0 using (99, 95, 113) as brain centroid... mean wm in atlas = 126, using box (82,71,91) --> (116, 118,134) to find MRI wm before smoothing, mri peak at 0 after smoothing, mri peak at 0, scaling input intensities by inf Darwin mac124901.med.cornell.edu 8.11.1 Darwin Kernel Version 8.11.1: Wed Oct 10 18:23:28 PDT 2007; root:xnu-792.25.20~1/RELEASE_I386 i386 i386 recon-all exited with ERRORS at Mon Apr 6 15:19:36 EDT 2009 How do we scale the nu.mgz images? Our 001.mgz are looking fine... thanks! ---------- Forwarded message ---------- From: Nurunisa Neyzi <nneyzi(a)gmail.com> Date: Mon, Apr 6, 2009 at 3:31 PM Subject: Re: FW: XNAT update: Processing failed for PrenatalMA_13_MR_1 To: Chris Derauf <dderauf(a)hawaii.edu> i think this is what's going on: we get "before smoothing, mri peak at 0 after smoothing, mri peak at 0, scaling input intensities by inf" which is wrong. this is happening because nu.mgz is very dark. same problem they had here: https://mail.nmr.mgh.harvard.edu/pipermail//freesurfer/2008-April/007603.ht… in our case though I think 001.mgz is looking fine, it is the nu.mgz that's kind of dark. let's see what's the easiest way fix it. On Mon, Apr 6, 2009 at 3:25 PM, Nurunisa Neyzi <nneyzi(a)gmail.com> wrote: > actually it goes wrong in the first step. even outside the pipeline. > so it's not an XNAT issue. > > On Mon, Apr 6, 2009 at 3:23 PM, Chris Derauf <dderauf(a)hawaii.edu> wrote: >> Yes, I did specify the BK Pediatric atlas >> >>

1 0

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