Freesurfer

freesurfer@nmr.mgh.harvard.edu

18 participants
30131 discussions

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

WM for ROIs
by Gabriel Go.Es. 06 Apr '09

06 Apr '09

Dear freesurfers im trying to obtain the wm volume for some ROIs created by myself, ando that not fit with the parcellation of FS, i'm using mri_segstats but i can't make it work, can any of you help me? i always recibe a message that says: "in Get MAC Adress (internal) : There was a configuration problem (or no cable !) on your platform: Success ERROR: Option X unknown the X is the name of the --sum, --i, --in or --seg that i write each time i've tried Regards Gabriel Haz búsquedas desde Live Search y ayuda a 22 niños de un orfanato en Nepal ¡Colabora! _________________________________________________________________ ¿Quieres crear tus propios emoticonos gratis? Descubre cómo hacerlo en el Club Oficial de Messenger http://vivelive.com/ilovemessenger/

2 1

Re: [Freesurfer] Problem changing the colourmap properties of the overlay ...
by Lloyd Elliott 06 Apr '09

06 Apr '09

The problem is that the Apply Close and Help button controls don't appear on the mac because the window is too long (MacBook laptops have a maximum resolution of 1280x800) (I didn't realise there was such a button because the beveling behind the rest of the controls makes it look like the window ends before the apply ---). I actually thought that this might be the case after I first posted, so I searched mac forums for a way to move windows without having to drag the title bar but I could only find other people with the same problem. I suppose I will hack the tcl to make it display in columns or add a scrollbar or something. Rather embarrassed, L On 6-Apr-09, at 5:07 PM, Bruce Fischl wrote: > did you try clickin "apply"? > On Mon, 6 Apr 2009, Lloyd Elliott wrote: > >> Yes, I did try right clicking to set the upper threshold. When I >> left click, or right click, the respective bar moves, but the >> colour map remains unchanged. When I click "copy settings to >> layer" the bars almost always reset. I've managed to make them not >> reset at least once, but the colour map still remained unchanged >> and I've been unable to reliably reproduce this non-resetting >> behaviour. >> >> Thanks! >> L >> >> On 6-Apr-09, at 2:42 PM, Bruce Fischl wrote: >> >>> did you try right-clicking to set the upper threshold? >>> On Mon, 6 Apr 2009, Lloyd Elliott wrote: >>>> Hi, >>>> I am trying to modify the colour map of an overlay in tksurfer. >>>> Unfortunately, the changes I make to the View -> Configure -> >>>> Overlay tcl/tk control are either ignored, or end in errors. >>>> For example, if I left click on the histogram to set the lower >>>> thresh hold, and then click 'coppy settings to layer', then the >>>> thresh hold resets to the original value. >>>> If I change the X Axis Range manually, for example by entering >>>> '6' in the Max edit box, then I get something like this error >>>> whenever I try to change something: >>>> ERROR updating histo: impossible limits (min 6.73089 >= max >>>> 6.73089) for axis "x" >>>> I'm guessing that this is a bug --- that is, it's not that I am >>>> misusing these controls. >>>> I just want the brain to be coloured according to the whole range >>>> of values in my w file --- ie, for the heat map, the minimum >>>> should be the darkest blue and the maximum should be the >>>> brightest red (no gray where I guess freesurfer assumes >>>> p>whatever --- this overlay is not a statistical test). Any >>>> suggestions? >>>> lloyd$ tksurfer --version >>>> stable4 >>>> lloyd$ uname -a >>>> Darwin 307-the-philosophers-foothold.local 9.6.0 Darwin Kernel >>>> Version 9.6.0: Mon Nov 24 17:37:00 PST 2008; root:xnu-1228.9.59~1/ >>>> RELEASE_I386 i386 >>>> surfer: current subjects dir: /Users/lloyd/work/subjects >>>> surfer: not in "scripts" dir ==> using cwd for session root >>>> surfer: session root data dir ($session) set to: >>>> surfer: /Users/lloyd >>>> surfer: Reading header info from /Users/mathpunk/work/subjects/ >>>> AAA03/ mri/T1.mgz >>>> surfer: vertices=123084, faces=246164 >>>> Thanks! >>>> L >>>> PS --- a screenshot of these errors: http://mathpunk.churchturing.org/overlay-problems.png >>>> _______________________________________________ >>>> Freesurfer mailing list >>>> Freesurfer(a)nmr.mgh.harvard.edu >>>> https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer >> >> >>

2 1

Re: [Freesurfer] Problem changing the colourmap properties of the overlay ...
by Lloyd Elliott 06 Apr '09

06 Apr '09

Yes, I did try right clicking to set the upper threshold. When I left click, or right click, the respective bar moves, but the colour map remains unchanged. When I click "copy settings to layer" the bars almost always reset. I've managed to make them not reset at least once, but the colour map still remained unchanged and I've been unable to reliably reproduce this non-resetting behaviour. Thanks! L On 6-Apr-09, at 2:42 PM, Bruce Fischl wrote: > did you try right-clicking to set the upper threshold? > On Mon, 6 Apr 2009, Lloyd Elliott wrote: > >> Hi, >> >> I am trying to modify the colour map of an overlay in tksurfer. >> Unfortunately, the changes I make to the View -> Configure -> >> Overlay tcl/tk control are either ignored, or end in errors. >> >> For example, if I left click on the histogram to set the lower >> thresh hold, and then click 'coppy settings to layer', then the >> thresh hold resets to the original value. >> >> If I change the X Axis Range manually, for example by entering '6' >> in the Max edit box, then I get something like this error whenever >> I try to change something: >> >> ERROR updating histo: impossible limits (min 6.73089 >= max >> 6.73089) for axis "x" >> >> I'm guessing that this is a bug --- that is, it's not that I am >> misusing these controls. >> >> I just want the brain to be coloured according to the whole range >> of values in my w file --- ie, for the heat map, the minimum >> should be the darkest blue and the maximum should be the brightest >> red (no gray where I guess freesurfer assumes p>whatever --- this >> overlay is not a statistical test). Any suggestions? >> >> lloyd$ tksurfer --version >> stable4 >> lloyd$ uname -a >> Darwin 307-the-philosophers-foothold.local 9.6.0 Darwin Kernel >> Version 9.6.0: Mon Nov 24 17:37:00 PST 2008; root:xnu-1228.9.59~1/ >> RELEASE_I386 i386 >> >> >> surfer: current subjects dir: /Users/lloyd/work/subjects >> surfer: not in "scripts" dir ==> using cwd for session root >> surfer: session root data dir ($session) set to: >> surfer: /Users/lloyd >> surfer: Reading header info from /Users/mathpunk/work/subjects/ >> AAA03/ mri/T1.mgz >> surfer: vertices=123084, faces=246164 >> >> Thanks! >> L >> >> PS --- a screenshot of these errors: http://mathpunk.churchturing.org/overlay-problems.png >> >> _______________________________________________ >> Freesurfer mailing list >> Freesurfer(a)nmr.mgh.harvard.edu >> https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer >> >> >>

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