Re: [Freesurfer] Experience with -localGI on Mac

[Marie Schaer]

Martin,

Do you have a Mac intel or PowerPC?
I am using Mac Intel, with Matlab 7.3 (release 2007a) and don't get  
this problem. Just to try, I relaunched the code with Matlab 7.4  
(2007b), and got the same problem that you have, so that it should be  
related to a specificity of the Matlab 7.4 version but I am still not  
able to figure the reason for it... I'll let you know as soon as I  
have a response.


Marie


On 23 avr. 08, at 20:10, Martin Kavec wrote:


Hello folks,

I am trying -localGI on Mac, with working Matlab2007.

1. I think that the getmatlab script is not designed to work on Mac  
out of the

box, since it is not by default in the $PATH, so it could be caught
by "which". So I uncommented the three lines and set it hard.

2. That was easy, but now I am stacked with execution, as it seems  
that the

script stops after few minutes, after completing the first matlab
function "make_outer_surface(...)". The outputs are there, in the
$SUBJECT/surf/tmp directory. Here is the output from

recon-all -s $SUBJECT -localGI

set MLF = /tmp/mos"_$$_".m
set MLF = /tmp/mos_10410_.m
set arg1 = ${tmpdir}/${input}.filled.mgz
set arg1 = tmp-mris_compute_lgi/lh.pial.filled.mgz
set arg2 = ${closespheresize}
set arg2 = 15
set arg3 = ${tmpdir}/${input}-outer
set arg3 = tmp-mris_compute_lgi/lh.pial-outer
rm -f ${arg3}
rm -f tmp-mris_compute_lgi/lh.pial-outer
echo "make_outer_surface('${arg1}',${arg2},'${arg3}')" > $MLF
echo
make_outer_surface('tmp-mris_compute_lgi/lh.pial.filled.mgz', 
15,'tmp-mris_compute_lgi/lh.pial-outer')

echo "="
echo =
=
echo "`cat $MLF`"
echo `cat /tmp/mos_10410_.m`
cat /tmp/mos_10410_.m
make_outer_surface('tmp-mris_compute_lgi/lh.pial.filled.mgz', 
15,'tmp-mris_compute_lgi/lh.pial-outer')

echo "="
echo =
=
if ( $RunIt ) then
if ( 1 ) then
cat $MLF | ${MATLAB} -display iconic -nojvm -nosplash
cat /tmp/mos_10410_.m
/Applications/Matlab74/bin/matlab -display iconic -nojvm -nosplash
Warning: Unable to open display iconic, MATLAB is starting without  
a display.

  You will not be able to display graphics on the screen.

  < M A T L A B >
  Copyright 1984-2007 The MathWorks, Inc.
 Version 7.4.0.287 (R2007a)
  January 29, 2007


  To get started, type one of these: helpwin, helpdesk, or demo.
  For product information, visit www.mathworks.com.


reading filled volume...

closing volume...
morphological closing done.
writing outer surface...




After this, the processor goes down and stays like that, nothing is  
happening.


Thanks for help,

Martin
___
Freesurfer mailing list
Freesurfer@nmr.mgh.harvard.edu
https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer


___
Freesurfer mailing list
Freesurfer@nmr.mgh.harvard.edu
https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer

[Freesurfer] Qdec display error

[Christine Ecker]

Hi,
I am using freesurfer v4.0.2 on Mac OS Tiger and am getting a qdec error
message: WARNING: Marker for class Main was invalid

And

ERROR: In
/usr/pubsw/packages/KWWidgets/CVS/src/KWW., line 1182
VtkKWQdecApp : TclTkerror:
Invalid command ... "vtkTemp249"


I have substituted to old version of the script fsgdfPlot.tcl by a newer
version that was posted online :
## fsgdfPlot.tcl
##
## CVS Revision Info:
##$Author: nicks $
##$Date: 2008/01/03 13:45:36 $
##$Revision: 1.24.2.2 $

,but the problem still occurs.

I would be very grateful for any ideas what the problem could be.
Thanks very much,
Christine

___
Freesurfer mailing list
Freesurfer@nmr.mgh.harvard.edu
https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer

Re: [Freesurfer] IO with freesurfer files (.mgh in particular) from Python

[Pádraig Kitterick]

How much detail do you need frmo the mgh file? I wrote a quick Python 
script which reads in at least the volume data but I think I just passed 
over most of the other stuff in there...


Yaroslav Halchenko wrote:

Does anyone know any handy module to at least read in .mgh files from
Python? Or should I simply try mri_convert them into .minc and use
netcdf module within python?

Thanks in advance for the ideas!



--
Pádraig Kitterick
Graduate Student
Department of Psychology
University of York
Heslington
York YO10 5DD
UK

Tel: +44 (0) 1904 43 3170
Email: [EMAIL PROTECTED]
___
Freesurfer mailing list
Freesurfer@nmr.mgh.harvard.edu
https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer

[Freesurfer] FA registration problems

[Damian Jenkins]

We are currently attempting to check the FA registration of each subject within 
an MS study group using the following command:

tkregister2 --s fsaverage --surf white --reg 
/Volumes/Data/magnims/group_study/P??-??/dti_analysis/fa-tal.nii.reg --mov 
/Volumes/Data/magnims/group_study/P??-??/dti_analysis/fa-tal.nii

However, this generates the following error message despite there being an 
orig.mgz in the fsaverage directory:
ERROR: could not find orig as either mgz or COR

Any ideas on what the problem might be?
Thanks
Damian

Dr Damian Jenkins
Department of Clinical Neurology
Oxford University

___
Freesurfer mailing list
Freesurfer@nmr.mgh.harvard.edu
https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer

Re: [Freesurfer] IO with freesurfer files (.mgh in particular) from Python

[Yaroslav Halchenko]

actually I need thickness data out of it. Is .mgh format documented
somewhere?

On Thu, 24 Apr 2008, Pádraig Kitterick wrote:

> How much detail do you need frmo the mgh file? I wrote a quick Python  
> script which reads in at least the volume data but I think I just passed  
> over most of the other stuff in there...
>
> Yaroslav Halchenko wrote:
>> Does anyone know any handy module to at least read in .mgh files from
>> Python? Or should I simply try mri_convert them into .minc and use
>> netcdf module within python?

>> Thanks in advance for the ideas!
-- 
Yaroslav Halchenko
Research Assistant, Psychology Department, Rutgers-Newark
Student  Ph.D. @ CS Dept. NJIT
Office: (973) 353-5440x263 | FWD: 82823 | Fax: (973) 353-1171
101 Warren Str, Smith Hall, Rm 4-105, Newark NJ 07102
WWW: http://www.linkedin.com/in/yarik
___
Freesurfer mailing list
Freesurfer@nmr.mgh.harvard.edu
https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer

Re: [Freesurfer] IO with freesurfer files (.mgh in particular) from Python

[Krish Subramaniam]

Here you go Yaroslav...

http://surfer.nmr.mgh.harvard.edu/fswiki/FsTutorial/MghFormat

Krish

On Apr 24, 2008, at 11:49 AM, Yaroslav Halchenko wrote:


actually I need thickness data out of it. Is .mgh format documented
somewhere?

On Thu, 24 Apr 2008, Pádraig Kitterick wrote:


How much detail do you need frmo the mgh file? I wrote a quick Python
script which reads in at least the volume data but I think I just  
passed

over most of the other stuff in there...

Yaroslav Halchenko wrote:
Does anyone know any handy module to at least read in .mgh files  
from

Python? Or should I simply try mri_convert them into .minc and use
netcdf module within python?



Thanks in advance for the ideas!

--
Yaroslav Halchenko
Research Assistant, Psychology Department, Rutgers-Newark
Student  Ph.D. @ CS Dept. NJIT
Office: (973) 353-5440x263 | FWD: 82823 | Fax: (973) 353-1171
   101 Warren Str, Smith Hall, Rm 4-105, Newark NJ 07102
WWW: http://www.linkedin.com/in/yarik
___
Freesurfer mailing list
Freesurfer@nmr.mgh.harvard.edu
https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer





___
Freesurfer mailing list
Freesurfer@nmr.mgh.harvard.edu
https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer

[Freesurfer] Talairach QA check

[Damian Jenkins]

You'll see we have a few Qs!

We have been having problems with a couple datasets with patients who have 
severe atrophy (MS and Alzheimer's) where they fail in autorecon1 with the 
Talairach QA check. The registrations look fine so I was wondering what other 
problems might cause this check to fail. Is there a simple way to bypass the 
Talairach QA step in recon-all -autorecon1 if we are satisfied with the 
registration?

Damian

Dr Damian Jenkins
Department of Clinical Neurology
Oxford University

___
Freesurfer mailing list
Freesurfer@nmr.mgh.harvard.edu
https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer

[Freesurfer] mri_ca_register

[Damian Jenkins]

In addition to this we have several datasets here that have a couple of 
subjects failing with:

Killed
ERROR: mri_ca_register with non-zero status
Linux jalapeno14 2.6.20-1.2320.fc5 #1 SMP Tue Jun 12 18:50:49 EDT 2007 x86_64 
x86_64 x86_64 GNU/Linux

I see from the new 4.0.3 release notes that there is a fix for mri_ca_register 
for Darwin but all our errors have been on Linux. Could this be the same 
problem?

D

Dr Damian Jenkins
Department of Clinical Neurology
Oxford University

___
Freesurfer mailing list
Freesurfer@nmr.mgh.harvard.edu
https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer

Re: [Freesurfer] IO with freesurfer files (.mgh in particular) from Python

[Nick Schmansky]

Yaroslav,

The mgh format is pseudo-documented here:

https://surfer.nmr.mgh.harvard.edu/fswiki/FsTutorial/MghFormat

But the thickness data is not stored in mgh format, but rather in
another proprietary format, with documentation here:

http://wideman-one.com/gw/brain/fs/surfacefileformats.htm

Your best option is to look at the matlab scripts in the
$FREESURFER_HOME/matlab directory.  In particular, read_curv.m, which I
have attached to the email (along with worker routine fread3.m).

Krish Subramaniam, a new software engineer here at MGH, cc'd in this
email, has just started a project where some of the major IO routines
will be written in python, so maybe you can coordinate with him.

Nick


On Thu, 2008-04-24 at 11:49 -0400, Yaroslav Halchenko wrote:
> actually I need thickness data out of it. Is .mgh format documented
> somewhere?
> 
> On Thu, 24 Apr 2008, Pádraig Kitterick wrote:
> 
> > How much detail do you need frmo the mgh file? I wrote a quick Python  
> > script which reads in at least the volume data but I think I just passed  
> > over most of the other stuff in there...
> >
> > Yaroslav Halchenko wrote:
> >> Does anyone know any handy module to at least read in .mgh files from
> >> Python? Or should I simply try mri_convert them into .minc and use
> >> netcdf module within python?
> 
> >> Thanks in advance for the ideas!
function [retval] = fd3(fid)
% [retval] = fd3(fid)
% read a 3 byte integer out of a file


%
% fread3.m
%
% Original Author: Bruce Fischl
% CVS Revision Info:
%$Author: nicks $
%$Date: 2007/01/10 22:55:09 $
%$Revision: 1.2 $
%
% Copyright (C) 2002-2007,
% The General Hospital Corporation (Boston, MA). 
% All rights reserved.
%
% Distribution, usage and copying of this software is covered under the
% terms found in the License Agreement file named 'COPYING' found in the
% FreeSurfer source code root directory, and duplicated here:
% https://surfer.nmr.mgh.harvard.edu/fswiki/FreeSurferOpenSourceLicense
%
% General inquiries: freesurfer@nmr.mgh.harvard.edu
% Bug reports: [EMAIL PROTECTED]
%

b1 = fread(fid, 1, 'uchar') ;
b2 = fread(fid, 1, 'uchar') ;
b3 = fread(fid, 1, 'uchar') ;
retval = bitshift(b1, 16) + bitshift(b2,8) + b3 ;

function [curv, fnum] = read_curv(fname)
%
% [curv, fnum] = read_curv(fname)
% reads a binary curvature file into a vector
%


%
% read_curv.m
%
% Original Author: Bruce Fischl
% CVS Revision Info:
%$Author: nicks $
%$Date: 2007/01/10 22:55:09 $
%$Revision: 1.2 $
%
% Copyright (C) 2002-2007,
% The General Hospital Corporation (Boston, MA). 
% All rights reserved.
%
% Distribution, usage and copying of this software is covered under the
% terms found in the License Agreement file named 'COPYING' found in the
% FreeSurfer source code root directory, and duplicated here:
% https://surfer.nmr.mgh.harvard.edu/fswiki/FreeSurferOpenSourceLicense
%
% General inquiries: freesurfer@nmr.mgh.harvard.edu
% Bug reports: [EMAIL PROTECTED]
%


%fid = fopen(fname, 'r') ;
%nvertices = fscanf(fid, '%d', 1);
%all = fscanf(fid, '%d %f %f %f %f\n', [5, nvertices]) ;
%curv = all(5, :)' ;

% open it as a big-endian file
fid = fopen(fname, 'rb', 'b') ;
if (fid < 0)
	 str = sprintf('could not open curvature file %s.', fname) ;
	 error(str) ;
end
vnum = fread3(fid) ;
NEW_VERSION_MAGIC_NUMBER = 16777215;
if (vnum == NEW_VERSION_MAGIC_NUMBER)
	 vnum = fread(fid, 1, 'int32') ;
	 fnum = fread(fid, 1, 'int32') ;
	 vals_per_vertex = fread(fid, 1, 'int32') ;
   curv = fread(fid, vnum, 'float') ; 
	   	
  fclose(fid) ;
else

	fnum = fread3(fid) ;
  curv = fread(fid, vnum, 'int16') ./ 100 ; 
  fclose(fid) ;
end
%nvertices = fscanf(fid, '%d', 1);
%all = fscanf(fid, '%d %f %f %f %f\n', [5, nvertices]) ;
%curv = all(5, :)' ;
function [curv] = write_curv(fname, curv, fnum)
% [curv] = write_curv(fname, curv, fnum)
%
% writes a curvature vector into a binary file
%fname - name of file to write to
%curv  - vector of curvatures
%fnum  - # of faces in surface.
%


%
% write_curv.m
%
% Original Author: Bruce Fischl
% CVS Revision Info:
%$Author: nicks $
%$Date: 2007/01/10 22:55:10 $
%$Revision: 1.2 $
%
% Copyright (C) 2002-2007,
% The General Hospital Corporation (Boston, MA). 
% All rights reserved.
%
% Distribution, usage and copying of this software is covered under the
% terms found in the License Agreement file named 'COPYING' found in the
% FreeSurfer source code root directory, and duplicated here:
% https://surfer.nmr.mgh.harvard.edu/fswiki/FreeSurferOpenSourceLicense
%
% General inquiries: freesurfer@nmr.mgh.harvard.edu
% Bug reports: [EMAIL PROTECTED]
%


% open it as a big-endian file
fid = fopen(fname, 'wb', 'b') ;
vnum = length(curv) ;
NEW_VERSION_MAGIC_NUMBER = 16777215;
fwrite3(fid, NEW_VERSION_MAGIC_NUMBER ) ;
fwrite(fid, vnum,'int32') ;
fwrite(fid, fnum,'int32') ;
fwrite(fid, 1, 'int32');
fwrite(fid, curv, 'float') ;
fclose(fid) ;

___
Freesurfer mailing list
Freesurfer@nmr.mgh.harvard.edu

Re: [Freesurfer] Talairach QA check

[Nick Schmansky]

Damian,

The talairach check can be bypassed with the -notal-check flag added to
recon-all.

Nick


On Thu, 2008-04-24 at 17:02 +0100, Damian Jenkins wrote:
> You'll see we have a few Qs!
> 
> We have been having problems with a couple datasets with patients who have 
> severe atrophy (MS and Alzheimer's) where they fail in autorecon1 with the 
> Talairach QA check. The registrations look fine so I was wondering what other 
> problems might cause this check to fail. Is there a simple way to bypass the 
> Talairach QA step in recon-all -autorecon1 if we are satisfied with the 
> registration?
> 
> Damian
> 
> Dr Damian Jenkins
> Department of Clinical Neurology
> Oxford University
> 
> ___
> Freesurfer mailing list
> Freesurfer@nmr.mgh.harvard.edu
> https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
> 
> 

___
Freesurfer mailing list
Freesurfer@nmr.mgh.harvard.edu
https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer

Re: [Freesurfer] IO with freesurfer files (.mgh in particular) from Python

[Pádraig Kitterick]

MGH is just a generic volume-based format so I think thickness data will 
be stored in a 1xNumVerticesx1x1 volume. Here is a python function which 
reads in the volume data. It's basically a translation of the readmgh 
function from the Freesurfer matlab toolbox. You can modify it to return 
more parts of the file data if necessary...


---
import struct
import numpy

def read_mgh(filename):
fp = open(filename,'rb')
intsize = struct.calcsize('>i')
shortsize = struct.calcsize('>h')
floatsize = struct.calcsize('>f')
charsize = struct.calcsize('>b')

v = struct.unpack('>i',fp.read(intsize))[0]
ndim1 = struct.unpack('>i',fp.read(intsize))[0]
ndim2 = struct.unpack('>i',fp.read(intsize))[0]
ndim3 = struct.unpack('>i',fp.read(intsize))[0]
nframes = struct.unpack('>i',fp.read(intsize))[0]
vtype = struct.unpack('>i',fp.read(intsize))[0]
dof = struct.unpack('>i',fp.read(intsize))[0]

UNUSED_SPACE_SIZE = 256
USED_SPACE_SIZE = (3*4) + (4*3*4) # space for ras transform
unused_space_size = UNUSED_SPACE_SIZE - 2

ras_good_flag = struct.unpack('>h',fp.read(shortsize))[0]
if ras_good_flag:
# We read these in but don't process them
# as we just want to move to the volume data
delta = struct.unpack('>fff',fp.read(floatsize*3))
Mdc = struct.unpack('>f',fp.read(floatsize*9))
Pxyz_c = struct.unpack('>fff',fp.read(floatsize*3))

unused_space_size = unused_space_size - USED_SPACE_SIZE

for i in range(unused_space_size):
struct.unpack('>b',fp.read(charsize))[0]

nv = ndim1 * ndim2 * ndim3 * nframes
vol = 
numpy.fromstring(fp.read(floatsize*nv),dtype=numpy.float32).byteswap()


nvert = max([ndim1,ndim2,ndim3])
vol = numpy.reshape(vol,(ndim1,ndim2,ndim3,nframes),order='F')
vol = numpy.squeeze(vol)
fp.close()

return vol

--
Padraig.

Yaroslav Halchenko wrote:

actually I need thickness data out of it. Is .mgh format documented
somewhere?

On Thu, 24 Apr 2008, Pádraig Kitterick wrote:

How much detail do you need frmo the mgh file? I wrote a quick Python  
script which reads in at least the volume data but I think I just passed  
over most of the other stuff in there...


Yaroslav Halchenko wrote:

Does anyone know any handy module to at least read in .mgh files from
Python? Or should I simply try mri_convert them into .minc and use
netcdf module within python?



Thanks in advance for the ideas!


--
Pádraig Kitterick
Graduate Student
Department of Psychology
University of York
Heslington
York YO10 5DD
UK

Tel: +44 (0) 1904 43 3170
Email: [EMAIL PROTECTED]
___
Freesurfer mailing list
Freesurfer@nmr.mgh.harvard.edu
https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer

Re: [Freesurfer] mri_ca_register

[Nick Schmansky]

Damian,

Yes, it would be worth the effort to try v4.0.3 to see if the problem is
corrected.  While the problem with mri_ca_register seemed to manifest
itself only on Darwin, the source of that bug was not Darwin specific,
so in theory it could appear on Linux (but we had never actually
encountered it, as we use freesurfer on Linux daily at our center).

Nick


On Thu, 2008-04-24 at 17:03 +0100, Damian Jenkins wrote:
> In addition to this we have several datasets here that have a couple of 
> subjects failing with:
> 
> Killed
> ERROR: mri_ca_register with non-zero status
> Linux jalapeno14 2.6.20-1.2320.fc5 #1 SMP Tue Jun 12 18:50:49 EDT 2007 x86_64 
> x86_64 x86_64 GNU/Linux
> 
> I see from the new 4.0.3 release notes that there is a fix for 
> mri_ca_register for Darwin but all our errors have been on Linux. Could this 
> be the same problem?
> 
> D
> 
> Dr Damian Jenkins
> Department of Clinical Neurology
> Oxford University
> 
> ___
> Freesurfer mailing list
> Freesurfer@nmr.mgh.harvard.edu
> https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
> 
> 

___
Freesurfer mailing list
Freesurfer@nmr.mgh.harvard.edu
https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer

[Freesurfer] SurfaceRAS space

[Michael Harms]

Hello,
I need to determine the transform between the surface coordinates
between FS and the surface generated using some of the tools from JHU.
I think that I have a handle on this, but just wanted to confirm a
couple things.

1) First, the "voxel to ras transform" returned by 'mri_info' is the
transform between a 0-based volume index DEFINED IN THE AXES OF THAT
VOLUME'S ORIENTATION (as also returned by mri_info) to a "ras" space
with origin at the center of the physical space spanned by that volume,
correct (provided that you have not specified an alternative "ras"
center as part of an 'mri_convert' command)?  That is, say you have a
rawavg.mgz volume created with a plain vanilla 'mri_convert' command on
an Analyze volume (.img, .hdr) having the default Analyze orientation
(hist.orient = 0, axial slice direction).  This rawavg.mgz volume will
have an 'mri_info' orientation of "LAS".  And you have the corresponding
orig.mgz volume with a (conformed) orientation of "LIA".  THEN, the
"voxel to ras transform" indicated for these volumes is NOT to an
identical "ras" space, correct?  (Namely, there will be a translation
between the two "ras" spaces, due to the different orientations of the
rawavg.mgz and orig.mgz, correct?)

2) The "SurfaceRAS" space of the vertices of the actual FS surfaces is
always defined relative to the "conformed" volume with "LIA"
orientation, correct?

3) Given (1) and (2), it is necessary to account for axes orientation of
any non-conformed (i.e., non-LIA) volumes as part of the transformation
between that volume representation and "SurfaceRAS" of the actual
surfaces, since the "ras" center of the volume will shift by 1 voxel in
physical space when you reverse the orientation of a given axis (given
the use of a 0-based volume indexing scheme).  Correct?

Hope my questions are clear.  I know that these various transformations
can be tricky to get just right.

thanks,
Mike H.


-- 
Michael Harms, Ph.D.

Conte Center for the Neuroscience of Mental Disorders
Washington University School of Medicine
Department of Psychiatry, Box 8134
Renard Hospital, Room 6615   Tel: 314-747-6173
660 South Euclid Ave.Fax: 314-747-2182
St. Louis, MO 63110  Email: [EMAIL PROTECTED]



___
Freesurfer mailing list
Freesurfer@nmr.mgh.harvard.edu
https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer

Re: [Freesurfer] IO with freesurfer files (.mgh in particular) from Python

[Nick Schmansky]

Pádraig is correct in stating that thickness data can be stored in an
mgh file.  But the default output of the freesurer recon-all stream does
not store them in that format: it will output ?h.thickness files, which
are the proprietary format.

However, those can be converted to .mgh like this:

mris_convert -c lh.thickness lh.inflated lh.thickness.mgh

or to ascii like this:

mris_convert -c lh.thickness lh.inflated lh.thickness.asc

But I doubt that helps too much, since I'm guessing you want to avoid
having to use the freesurfer binaries and want to just read the files
directly.

Nick


On Thu, 2008-04-24 at 17:09 +0100, Pádraig Kitterick wrote:
> MGH is just a generic volume-based format so I think thickness data will 
> be stored in a 1xNumVerticesx1x1 volume. Here is a python function which 
> reads in the volume data. It's basically a translation of the readmgh 
> function from the Freesurfer matlab toolbox. You can modify it to return 
> more parts of the file data if necessary...
> 
> ---
> import struct
> import numpy
> 
> def read_mgh(filename):
>  fp = open(filename,'rb')
>  intsize = struct.calcsize('>i')
>  shortsize = struct.calcsize('>h')
>  floatsize = struct.calcsize('>f')
>  charsize = struct.calcsize('>b')
> 
>  v = struct.unpack('>i',fp.read(intsize))[0]
>  ndim1 = struct.unpack('>i',fp.read(intsize))[0]
>  ndim2 = struct.unpack('>i',fp.read(intsize))[0]
>  ndim3 = struct.unpack('>i',fp.read(intsize))[0]
>  nframes = struct.unpack('>i',fp.read(intsize))[0]
>  vtype = struct.unpack('>i',fp.read(intsize))[0]
>  dof = struct.unpack('>i',fp.read(intsize))[0]
> 
>  UNUSED_SPACE_SIZE = 256
>  USED_SPACE_SIZE = (3*4) + (4*3*4) # space for ras transform
>  unused_space_size = UNUSED_SPACE_SIZE - 2
> 
>  ras_good_flag = struct.unpack('>h',fp.read(shortsize))[0]
>  if ras_good_flag:
>  # We read these in but don't process them
>  # as we just want to move to the volume data
>  delta = struct.unpack('>fff',fp.read(floatsize*3))
>  Mdc = struct.unpack('>f',fp.read(floatsize*9))
>  Pxyz_c = struct.unpack('>fff',fp.read(floatsize*3))
> 
>  unused_space_size = unused_space_size - USED_SPACE_SIZE
> 
>  for i in range(unused_space_size):
>  struct.unpack('>b',fp.read(charsize))[0]
> 
>  nv = ndim1 * ndim2 * ndim3 * nframes
>  vol = 
> numpy.fromstring(fp.read(floatsize*nv),dtype=numpy.float32).byteswap()
> 
>  nvert = max([ndim1,ndim2,ndim3])
>  vol = numpy.reshape(vol,(ndim1,ndim2,ndim3,nframes),order='F')
>  vol = numpy.squeeze(vol)
>  fp.close()
> 
>  return vol
> 
> --
> Padraig.
> 
> Yaroslav Halchenko wrote:
> > actually I need thickness data out of it. Is .mgh format documented
> > somewhere?
> > 
> > On Thu, 24 Apr 2008, Pádraig Kitterick wrote:
> > 
> >> How much detail do you need frmo the mgh file? I wrote a quick Python  
> >> script which reads in at least the volume data but I think I just passed  
> >> over most of the other stuff in there...
> >>
> >> Yaroslav Halchenko wrote:
> >>> Does anyone know any handy module to at least read in .mgh files from
> >>> Python? Or should I simply try mri_convert them into .minc and use
> >>> netcdf module within python?
> > 
> >>> Thanks in advance for the ideas!
> 

___
Freesurfer mailing list
Freesurfer@nmr.mgh.harvard.edu
https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer

Re: [Freesurfer] Qdec display error

[Nick Schmansky]

Christine,

The warning message can be ignored.

As for the error, can you try v4.0.3?  I have heard of the problem you
are seeing but have never been able to recreate it locally.  I suspect
it might be rooted in the KWWidgets library, which is distributed with
freesurfer, and was updated from v4.0.2 to v4.0.3, but have no way to
test if that is the fix.

Nick



On Thu, 2008-04-24 at 12:15 +0100, Christine Ecker wrote:
> Hi,
> I am using freesurfer v4.0.2 on Mac OS Tiger and am getting a qdec error
> message: WARNING: Marker for class Main was invalid
> 
> And
> 
> ERROR: In
> /usr/pubsw/packages/KWWidgets/CVS/src/KWW., line 1182
> VtkKWQdecApp : TclTkerror:
> Invalid command ... "vtkTemp249"
> 
> 
> I have substituted to old version of the script fsgdfPlot.tcl by a newer
> version that was posted online :
> ## fsgdfPlot.tcl
> ##
> ## CVS Revision Info:
> ##$Author: nicks $
> ##$Date: 2008/01/03 13:45:36 $
> ##$Revision: 1.24.2.2 $
> 
> ,but the problem still occurs.
> 
> I would be very grateful for any ideas what the problem could be.
> Thanks very much,
> Christine
> 
> ___
> Freesurfer mailing list
> Freesurfer@nmr.mgh.harvard.edu
> https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
> 
> 

___
Freesurfer mailing list
Freesurfer@nmr.mgh.harvard.edu
https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer

Re: [Freesurfer] Experience with -localGI on Mac

[Nick Schmansky]

Martin and other -localGI users,

Independent of the matlab problem, there was a bug that was just
discovered, affecting mris_fill, that breaks the -localGI usage.  A fix
will be provided (hopefully along with a fix for this matlab problem) in
v4.0.4.  If you need to use the -localGI feature, I can provide fixed
binaries as they appear (email me to request these).

Nick


On Wed, 2008-04-23 at 20:10 +0200, Martin Kavec wrote:
> Hello folks,
> 
> I am trying -localGI on Mac, with working Matlab2007. 
> 
> 1. I think that the getmatlab script is not designed to work on Mac out of 
> the 
> box, since it is not by default in the $PATH, so it could be caught 
> by "which". So I uncommented the three lines and set it hard.
> 
> 2. That was easy, but now I am stacked with execution, as it seems that the 
> script stops after few minutes, after completing the first matlab 
> function "make_outer_surface(...)". The outputs are there, in the 
> $SUBJECT/surf/tmp directory. Here is the output from
> 
> recon-all -s $SUBJECT -localGI
> 
> set MLF = /tmp/mos"_$$_".m
> set MLF = /tmp/mos_10410_.m
> set arg1 = ${tmpdir}/${input}.filled.mgz
> set arg1 = tmp-mris_compute_lgi/lh.pial.filled.mgz
> set arg2 = ${closespheresize}
> set arg2 = 15
> set arg3 = ${tmpdir}/${input}-outer
> set arg3 = tmp-mris_compute_lgi/lh.pial-outer
> rm -f ${arg3}
> rm -f tmp-mris_compute_lgi/lh.pial-outer
> echo "make_outer_surface('${arg1}',${arg2},'${arg3}')" > $MLF
> echo 
> make_outer_surface('tmp-mris_compute_lgi/lh.pial.filled.mgz',15,'tmp-mris_compute_lgi/lh.pial-outer')
> echo "="
> echo =
> =
> echo "`cat $MLF`"
> echo `cat /tmp/mos_10410_.m`
> cat /tmp/mos_10410_.m
> make_outer_surface('tmp-mris_compute_lgi/lh.pial.filled.mgz',15,'tmp-mris_compute_lgi/lh.pial-outer')
> echo "="
> echo =
> =
> if ( $RunIt ) then
> if ( 1 ) then
> cat $MLF | ${MATLAB} -display iconic -nojvm -nosplash
> cat /tmp/mos_10410_.m
> /Applications/Matlab74/bin/matlab -display iconic -nojvm -nosplash
> Warning: Unable to open display iconic, MATLAB is starting without a display.
>   You will not be able to display graphics on the screen.
> 
>   < M A T L A B >
>   Copyright 1984-2007 The MathWorks, Inc.
>  Version 7.4.0.287 (R2007a)
>   January 29, 2007
> 
>  
>   To get started, type one of these: helpwin, helpdesk, or demo.
>   For product information, visit www.mathworks.com.
>  
> >> reading filled volume...
> closing volume...
> morphological closing done.
> writing outer surface...
> >> 
> 
> After this, the processor goes down and stays like that, nothing is happening.
> 
> Thanks for help,
> 
> Martin
> ___
> Freesurfer mailing list
> Freesurfer@nmr.mgh.harvard.edu
> https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
> 
> 

___
Freesurfer mailing list
Freesurfer@nmr.mgh.harvard.edu
https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer

[Freesurfer] Centos 5 freesurfer GLX GLXBadLargeRequest - Install NVidia driver manually?

[Brian Hanna]

Hi all,

We are having a problem running tksurfer on several Centos 5 machines. 
We are getting the dreaded GLXBadLargeRequest and just the front sliver 
of the brain displayed. By installing the Nvidia driver manually, we 
made it work.


We have one Centos 5 machine where it is working (machine01). That one 
machine has an Nvidia card and the Nvidia driver installed.


We find that machine01 runs tksurfer correctly locally, and other 
machines can connect to machine01 with VNC and run tksurfer remotely on 
machine01. None of the other machines work correctly.


Following up on the Nvidia driver difference, I notice that the Nvidia 
driver package includes a number of GL libraries. On the other machines, 
standard Centos 5 installs, I see:

$ ls -l /usr/lib*/libGL*
lrwxrwxrwx 1 root root 10 Jan  7 14:57 /usr/lib64/libGL.so -> 
libGL.so.1
lrwxrwxrwx 1 root root 12 Jan  7 14:57 /usr/lib64/libGL.so.1 -> 
libGL.so.1.2

-rwxr-xr-x 1 root root 492720 Nov 10 11:23 /usr/lib64/libGL.so.1.2
lrwxrwxrwx 1 root root 11 Jan  7 14:57 /usr/lib64/libGLU.so -> 
libGLU.so.1
lrwxrwxrwx 1 root root 20 Jan  7 14:57 /usr/lib64/libGLU.so.1 -> 
libGLU.so.1.3.060501

-rwxr-xr-x 1 root root 526048 Nov 10 11:23 /usr/lib64/libGLU.so.1.3.060501
lrwxrwxrwx 1 root root 12 Apr 23 14:49 /usr/lib/libGL.so.1 -> 
libGL.so.1.2

-rwxr-xr-x 1 root root 432016 Nov 10 11:24 /usr/lib/libGL.so.1.2
lrwxrwxrwx 1 root root 20 Feb  3 16:07 /usr/lib/libGLU.so.1 -> 
libGLU.so.1.3.060501

-rwxr-xr-x 1 root root 524000 Nov 10 11:24 /usr/lib/libGLU.so.1.3.060501
I see (based on the modification time of the install) that there are 
several new libraries installed from Nvidia. That's a new libGL and 10mb 
libGLcore, and my standard libGL.so.1.2 has been zapped.

$ ls -l /usr/lib*/lib* | grep 09:21
lrwxrwxrwx 1 root root   22 Apr 16 09:21 /usr/lib64/libGLcore.so.1 
-> libGLcore.so.100.14.11
-rwxr-xr-x 1 root root  904 Apr 16 09:21 
/usr/lib64/libGLcore.so.100.14.11

-rw-r--r-- 1 root root  661 Apr 16 09:21 /usr/lib64/libGL.la
lrwxrwxrwx 1 root root   10 Apr 16 09:21 /usr/lib64/libGL.so -> 
libGL.so.1
lrwxrwxrwx 1 root root   18 Apr 16 09:21 /usr/lib64/libGL.so.1 -> 
libGL.so.100.14.11

-rwxr-xr-x 1 root root   822960 Apr 16 09:21 /usr/lib64/libGL.so.100.14.11
lrwxrwxrwx 1 root root   18 Apr 16 09:21 
/usr/lib64/libnvidia-cfg.so -> libnvidia-cfg.so.1
lrwxrwxrwx 1 root root   26 Apr 16 09:21 
/usr/lib64/libnvidia-cfg.so.1 -> libnvidia-cfg.so.100.14.11
-rwxr-xr-x 1 root root   127096 Apr 16 09:21 
/usr/lib64/libnvidia-cfg.so.100.14.11
lrwxrwxrwx 1 root root   26 Apr 16 09:21 
/usr/lib64/libnvidia-tls.so.1 -> libnvidia-tls.so.100.14.11
-rwxr-xr-x 1 root root 3016 Apr 16 09:21 
/usr/lib64/libnvidia-tls.so.100.14.11

-r--r--r-- 1 root root   185148 Apr 16 09:21 /usr/lib64/libXvMCNVIDIA.a
lrwxrwxrwx 1 root root   26 Apr 16 09:21 
/usr/lib64/libXvMCNVIDIA_dynamic.so.1 -> libXvMCNVIDIA.so.100.14.11
-rwxr-xr-x 1 root root   137944 Apr 16 09:21 
/usr/lib64/libXvMCNVIDIA.so.100.14.11
lrwxrwxrwx 1 root root   22 Apr 16 09:21 /usr/lib/libGLcore.so.1 
-> libGLcore.so.100.14.11
-rwxr-xr-x 1 root root 10080488 Apr 16 09:21 
/usr/lib/libGLcore.so.100.14.11

-rw-r--r-- 1 root root  659 Apr 16 09:21 /usr/lib/libGL.la
lrwxrwxrwx 1 root root   10 Apr 16 09:21 /usr/lib/libGL.so -> 
libGL.so.1
lrwxrwxrwx 1 root root   18 Apr 16 09:21 /usr/lib/libGL.so.1 -> 
libGL.so.100.14.11

-rwxr-xr-x 1 root root   608400 Apr 16 09:21 /usr/lib/libGL.so.100.14.11
lrwxrwxrwx 1 root root   26 Apr 16 09:21 
/usr/lib/libnvidia-tls.so.1 -> libnvidia-tls.so.100.14.11
-rwxr-xr-x 1 root root 2352 Apr 16 09:21 
/usr/lib/libnvidia-tls.so.100.14.11
For a test, I temporarily copied the libraries and make the appropriate 
links on another machine - basically installing the driver manually. I 
find that now the entire brain displays and I don't get the 
GLXBadLargeRequest.


I suppose I could have installed an Nvidia card and installed the driver 
to accomplish the same thing. You can use the -x option to the NVidia 
driver package to just extract it without running the installer. Be sure 
to check the LICENSE file, sections 2.1.2 and 2.1.3, before deciding how 
to proceed with this information.


So the problem lies in functionality available in the Nvidia libGL (etc) 
libraries that is not available in the standard Centos 5 libGL. What 
GL/GLX libraries do I install on a non-Nvidia machine in order to run 
tksurfer? Does tksurfer depend specifically on having Nvidia cards or 
other proprietary drivers installed? The wiki states:
A 2GHz or faster processor, at least 2GB of RAM, and a 3D graphics 
card (with a GPU and its own graphics memory) with accelerated OpenGL 
drivers, is recommended. Freesurfer is highly CPU and memory intensive 
(and moderately disk intensive), so concentrate on boosting those 
performance aspects (more memory is better). Most modern video 
graphics card will perform fine, but be aware that graphics

Re: [Freesurfer] Centos 5 freesurfer GLX GLXBadLargeRequest - Install NVidia driver manually?

[Paul Raines]

The problem with the NVIDIA driver installation is that it overwrites
the GL shared lib links and removes the default CentOS GL libs.  If
you then do an update via up2date, yum, or whatever you use to keep
CentOS up to date and one of the packages updated is the GL one, then
the NVIDIA ones get overwritten with the defaults ones again.  The only
fix is to reinstall the NVIDIA driver.

So you have to monitor your upgrades closely and anytime you see an 'xorg'
package upgrage check the GL libs and reinstall NVIDIA if needed.


On Thu, 24 Apr 2008, Brian Hanna wrote:


Hi all,

We are having a problem running tksurfer on several Centos 5 machines. We are 
getting the dreaded GLXBadLargeRequest and just the front sliver of the brain 
displayed. By installing the Nvidia driver manually, we made it work.


We have one Centos 5 machine where it is working (machine01). That one 
machine has an Nvidia card and the Nvidia driver installed.


We find that machine01 runs tksurfer correctly locally, and other machines 
can connect to machine01 with VNC and run tksurfer remotely on machine01. 
None of the other machines work correctly.


Following up on the Nvidia driver difference, I notice that the Nvidia driver 
package includes a number of GL libraries. On the other machines, standard 
Centos 5 installs, I see:

$ ls -l /usr/lib*/libGL*
lrwxrwxrwx 1 root root 10 Jan  7 14:57 /usr/lib64/libGL.so -> 
libGL.so.1
lrwxrwxrwx 1 root root 12 Jan  7 14:57 /usr/lib64/libGL.so.1 -> 
libGL.so.1.2

-rwxr-xr-x 1 root root 492720 Nov 10 11:23 /usr/lib64/libGL.so.1.2
lrwxrwxrwx 1 root root 11 Jan  7 14:57 /usr/lib64/libGLU.so -> 
libGLU.so.1
lrwxrwxrwx 1 root root 20 Jan  7 14:57 /usr/lib64/libGLU.so.1 -> 
libGLU.so.1.3.060501

-rwxr-xr-x 1 root root 526048 Nov 10 11:23 /usr/lib64/libGLU.so.1.3.060501
lrwxrwxrwx 1 root root 12 Apr 23 14:49 /usr/lib/libGL.so.1 -> 
libGL.so.1.2

-rwxr-xr-x 1 root root 432016 Nov 10 11:24 /usr/lib/libGL.so.1.2
lrwxrwxrwx 1 root root 20 Feb  3 16:07 /usr/lib/libGLU.so.1 -> 
libGLU.so.1.3.060501

-rwxr-xr-x 1 root root 524000 Nov 10 11:24 /usr/lib/libGLU.so.1.3.060501
I see (based on the modification time of the install) that there are several 
new libraries installed from Nvidia. That's a new libGL and 10mb libGLcore, 
and my standard libGL.so.1.2 has been zapped.

$ ls -l /usr/lib*/lib* | grep 09:21
lrwxrwxrwx 1 root root   22 Apr 16 09:21 /usr/lib64/libGLcore.so.1 -> 
libGLcore.so.100.14.11
-rwxr-xr-x 1 root root  904 Apr 16 09:21 
/usr/lib64/libGLcore.so.100.14.11

-rw-r--r-- 1 root root  661 Apr 16 09:21 /usr/lib64/libGL.la
lrwxrwxrwx 1 root root   10 Apr 16 09:21 /usr/lib64/libGL.so -> 
libGL.so.1
lrwxrwxrwx 1 root root   18 Apr 16 09:21 /usr/lib64/libGL.so.1 -> 
libGL.so.100.14.11

-rwxr-xr-x 1 root root   822960 Apr 16 09:21 /usr/lib64/libGL.so.100.14.11
lrwxrwxrwx 1 root root   18 Apr 16 09:21 /usr/lib64/libnvidia-cfg.so -> 
libnvidia-cfg.so.1
lrwxrwxrwx 1 root root   26 Apr 16 09:21 /usr/lib64/libnvidia-cfg.so.1 
-> libnvidia-cfg.so.100.14.11
-rwxr-xr-x 1 root root   127096 Apr 16 09:21 
/usr/lib64/libnvidia-cfg.so.100.14.11
lrwxrwxrwx 1 root root   26 Apr 16 09:21 /usr/lib64/libnvidia-tls.so.1 
-> libnvidia-tls.so.100.14.11
-rwxr-xr-x 1 root root 3016 Apr 16 09:21 
/usr/lib64/libnvidia-tls.so.100.14.11

-r--r--r-- 1 root root   185148 Apr 16 09:21 /usr/lib64/libXvMCNVIDIA.a
lrwxrwxrwx 1 root root   26 Apr 16 09:21 
/usr/lib64/libXvMCNVIDIA_dynamic.so.1 -> libXvMCNVIDIA.so.100.14.11
-rwxr-xr-x 1 root root   137944 Apr 16 09:21 
/usr/lib64/libXvMCNVIDIA.so.100.14.11
lrwxrwxrwx 1 root root   22 Apr 16 09:21 /usr/lib/libGLcore.so.1 -> 
libGLcore.so.100.14.11
-rwxr-xr-x 1 root root 10080488 Apr 16 09:21 
/usr/lib/libGLcore.so.100.14.11

-rw-r--r-- 1 root root  659 Apr 16 09:21 /usr/lib/libGL.la
lrwxrwxrwx 1 root root   10 Apr 16 09:21 /usr/lib/libGL.so -> 
libGL.so.1
lrwxrwxrwx 1 root root   18 Apr 16 09:21 /usr/lib/libGL.so.1 -> 
libGL.so.100.14.11

-rwxr-xr-x 1 root root   608400 Apr 16 09:21 /usr/lib/libGL.so.100.14.11
lrwxrwxrwx 1 root root   26 Apr 16 09:21 /usr/lib/libnvidia-tls.so.1 -> 
libnvidia-tls.so.100.14.11
-rwxr-xr-x 1 root root 2352 Apr 16 09:21 
/usr/lib/libnvidia-tls.so.100.14.11
For a test, I temporarily copied the libraries and make the appropriate links 
on another machine - basically installing the driver manually. I find that 
now the entire brain displays and I don't get the GLXBadLargeRequest.


I suppose I could have installed an Nvidia card and installed the driver to 
accomplish the same thing. You can use the -x option to the NVidia driver 
package to just extract it without running the installer. Be sure to check 
the LICENSE file, sections 2.1.2 and 2.1.3, before deciding how to proceed 
with this information.


So the problem lies in functionality available in the Nvidia libGL (etc) 
libraries that is not available in the standard Centos 5 libGL. What GL/GLX 
libraries do I ins

Re: [Freesurfer] Centos 5 freesurfer GLX GLXBadLargeRequest - Install NVidia driver manually?

[Brian Hanna]

Yes, that makes sense. But what libraries can I use to run tksurfer 
-without- installing the Nvidia libraries?


Paul Raines wrote:


The problem with the NVIDIA driver installation is that it overwrites
the GL shared lib links and removes the default CentOS GL libs.  If
you then do an update via up2date, yum, or whatever you use to keep
CentOS up to date and one of the packages updated is the GL one, then
the NVIDIA ones get overwritten with the defaults ones again.  The only
fix is to reinstall the NVIDIA driver.

So you have to monitor your upgrades closely and anytime you see an 
'xorg'

package upgrage check the GL libs and reinstall NVIDIA if needed.


On Thu, 24 Apr 2008, Brian Hanna wrote:


Hi all,

We are having a problem running tksurfer on several Centos 5 
machines. We are getting the dreaded GLXBadLargeRequest and just the 
front sliver of the brain displayed. By installing the Nvidia driver 
manually, we made it work.


We have one Centos 5 machine where it is working (machine01). That 
one machine has an Nvidia card and the Nvidia driver installed.


We find that machine01 runs tksurfer correctly locally, and other 
machines can connect to machine01 with VNC and run tksurfer remotely 
on machine01. None of the other machines work correctly.


Following up on the Nvidia driver difference, I notice that the 
Nvidia driver package includes a number of GL libraries. On the other 
machines, standard Centos 5 installs, I see:

$ ls -l /usr/lib*/libGL*
lrwxrwxrwx 1 root root 10 Jan  7 14:57 /usr/lib64/libGL.so -> 
libGL.so.1
lrwxrwxrwx 1 root root 12 Jan  7 14:57 /usr/lib64/libGL.so.1 -> 
libGL.so.1.2

-rwxr-xr-x 1 root root 492720 Nov 10 11:23 /usr/lib64/libGL.so.1.2
lrwxrwxrwx 1 root root 11 Jan  7 14:57 /usr/lib64/libGLU.so -> 
libGLU.so.1
lrwxrwxrwx 1 root root 20 Jan  7 14:57 /usr/lib64/libGLU.so.1 -> 
libGLU.so.1.3.060501
-rwxr-xr-x 1 root root 526048 Nov 10 11:23 
/usr/lib64/libGLU.so.1.3.060501
lrwxrwxrwx 1 root root 12 Apr 23 14:49 /usr/lib/libGL.so.1 -> 
libGL.so.1.2

-rwxr-xr-x 1 root root 432016 Nov 10 11:24 /usr/lib/libGL.so.1.2
lrwxrwxrwx 1 root root 20 Feb  3 16:07 /usr/lib/libGLU.so.1 -> 
libGLU.so.1.3.060501
-rwxr-xr-x 1 root root 524000 Nov 10 11:24 
/usr/lib/libGLU.so.1.3.060501
I see (based on the modification time of the install) that there are 
several new libraries installed from Nvidia. That's a new libGL and 
10mb libGLcore, and my standard libGL.so.1.2 has been zapped.

$ ls -l /usr/lib*/lib* | grep 09:21
lrwxrwxrwx 1 root root   22 Apr 16 09:21 
/usr/lib64/libGLcore.so.1 -> libGLcore.so.100.14.11
-rwxr-xr-x 1 root root  904 Apr 16 09:21 
/usr/lib64/libGLcore.so.100.14.11

-rw-r--r-- 1 root root  661 Apr 16 09:21 /usr/lib64/libGL.la
lrwxrwxrwx 1 root root   10 Apr 16 09:21 /usr/lib64/libGL.so -> 
libGL.so.1
lrwxrwxrwx 1 root root   18 Apr 16 09:21 /usr/lib64/libGL.so.1 
-> libGL.so.100.14.11
-rwxr-xr-x 1 root root   822960 Apr 16 09:21 
/usr/lib64/libGL.so.100.14.11
lrwxrwxrwx 1 root root   18 Apr 16 09:21 
/usr/lib64/libnvidia-cfg.so -> libnvidia-cfg.so.1
lrwxrwxrwx 1 root root   26 Apr 16 09:21 
/usr/lib64/libnvidia-cfg.so.1 -> libnvidia-cfg.so.100.14.11
-rwxr-xr-x 1 root root   127096 Apr 16 09:21 
/usr/lib64/libnvidia-cfg.so.100.14.11
lrwxrwxrwx 1 root root   26 Apr 16 09:21 
/usr/lib64/libnvidia-tls.so.1 -> libnvidia-tls.so.100.14.11
-rwxr-xr-x 1 root root 3016 Apr 16 09:21 
/usr/lib64/libnvidia-tls.so.100.14.11

-r--r--r-- 1 root root   185148 Apr 16 09:21 /usr/lib64/libXvMCNVIDIA.a
lrwxrwxrwx 1 root root   26 Apr 16 09:21 
/usr/lib64/libXvMCNVIDIA_dynamic.so.1 -> libXvMCNVIDIA.so.100.14.11
-rwxr-xr-x 1 root root   137944 Apr 16 09:21 
/usr/lib64/libXvMCNVIDIA.so.100.14.11
lrwxrwxrwx 1 root root   22 Apr 16 09:21 /usr/lib/libGLcore.so.1 
-> libGLcore.so.100.14.11
-rwxr-xr-x 1 root root 10080488 Apr 16 09:21 
/usr/lib/libGLcore.so.100.14.11

-rw-r--r-- 1 root root  659 Apr 16 09:21 /usr/lib/libGL.la
lrwxrwxrwx 1 root root   10 Apr 16 09:21 /usr/lib/libGL.so -> 
libGL.so.1
lrwxrwxrwx 1 root root   18 Apr 16 09:21 /usr/lib/libGL.so.1 -> 
libGL.so.100.14.11
-rwxr-xr-x 1 root root   608400 Apr 16 09:21 
/usr/lib/libGL.so.100.14.11
lrwxrwxrwx 1 root root   26 Apr 16 09:21 
/usr/lib/libnvidia-tls.so.1 -> libnvidia-tls.so.100.14.11
-rwxr-xr-x 1 root root 2352 Apr 16 09:21 
/usr/lib/libnvidia-tls.so.100.14.11
For a test, I temporarily copied the libraries and make the 
appropriate links on another machine - basically installing the 
driver manually. I find that now the entire brain displays and I 
don't get the GLXBadLargeRequest.


I suppose I could have installed an Nvidia card and installed the 
driver to accomplish the same thing. You can use the -x option to the 
NVidia driver package to just extract it without running the 
installer. Be sure to check the LICENSE file, sections 2.1.2 and 
2.1.3, before deciding how to proceed with this information.


So the problem lies in functiona

Re: [Freesurfer] Centos 5 freesurfer GLX GLXBadLargeRequest - Install NVidia driver manually?

[Nick Schmansky]

Brian,

Does the 'qdec' application run for you on Centos5?  

Our apps do not require any particular graphics card.  Through
experience, it seems the Nvidia cards give the least trouble (compared
to ATI), but we have never been able to track down exactly why
(something in the bowels of each manufactures OpenGL/GLX
implementation).  I think, but am not positive, that GLX is graphics-
card specific (well I would think OpenGL is too), and tksurfer uses GLX
(although I think there is a way to force software rendering), so I
cannot say how the default Centos5 GL/GLX drivers will behave.

So for the systems that are not working, what graphics card is
installed?

Nick

On Thu, 2008-04-24 at 11:54 -0500, Brian Hanna wrote:
> Hi all,
> 
> We are having a problem running tksurfer on several Centos 5 machines. 
> We are getting the dreaded GLXBadLargeRequest and just the front sliver 
> of the brain displayed. By installing the Nvidia driver manually, we 
> made it work.
> 
> We have one Centos 5 machine where it is working (machine01). That one 
> machine has an Nvidia card and the Nvidia driver installed.
> 
> We find that machine01 runs tksurfer correctly locally, and other 
> machines can connect to machine01 with VNC and run tksurfer remotely on 
> machine01. None of the other machines work correctly.
> 
> Following up on the Nvidia driver difference, I notice that the Nvidia 
> driver package includes a number of GL libraries. On the other machines, 
> standard Centos 5 installs, I see:
> > $ ls -l /usr/lib*/libGL*
> > lrwxrwxrwx 1 root root 10 Jan  7 14:57 /usr/lib64/libGL.so -> 
> > libGL.so.1
> > lrwxrwxrwx 1 root root 12 Jan  7 14:57 /usr/lib64/libGL.so.1 -> 
> > libGL.so.1.2
> > -rwxr-xr-x 1 root root 492720 Nov 10 11:23 /usr/lib64/libGL.so.1.2
> > lrwxrwxrwx 1 root root 11 Jan  7 14:57 /usr/lib64/libGLU.so -> 
> > libGLU.so.1
> > lrwxrwxrwx 1 root root 20 Jan  7 14:57 /usr/lib64/libGLU.so.1 -> 
> > libGLU.so.1.3.060501
> > -rwxr-xr-x 1 root root 526048 Nov 10 11:23 /usr/lib64/libGLU.so.1.3.060501
> > lrwxrwxrwx 1 root root 12 Apr 23 14:49 /usr/lib/libGL.so.1 -> 
> > libGL.so.1.2
> > -rwxr-xr-x 1 root root 432016 Nov 10 11:24 /usr/lib/libGL.so.1.2
> > lrwxrwxrwx 1 root root 20 Feb  3 16:07 /usr/lib/libGLU.so.1 -> 
> > libGLU.so.1.3.060501
> > -rwxr-xr-x 1 root root 524000 Nov 10 11:24 /usr/lib/libGLU.so.1.3.060501
> I see (based on the modification time of the install) that there are 
> several new libraries installed from Nvidia. That's a new libGL and 10mb 
> libGLcore, and my standard libGL.so.1.2 has been zapped.
> > $ ls -l /usr/lib*/lib* | grep 09:21
> > lrwxrwxrwx 1 root root   22 Apr 16 09:21 /usr/lib64/libGLcore.so.1 
> > -> libGLcore.so.100.14.11
> > -rwxr-xr-x 1 root root  904 Apr 16 09:21 
> > /usr/lib64/libGLcore.so.100.14.11
> > -rw-r--r-- 1 root root  661 Apr 16 09:21 /usr/lib64/libGL.la
> > lrwxrwxrwx 1 root root   10 Apr 16 09:21 /usr/lib64/libGL.so -> 
> > libGL.so.1
> > lrwxrwxrwx 1 root root   18 Apr 16 09:21 /usr/lib64/libGL.so.1 -> 
> > libGL.so.100.14.11
> > -rwxr-xr-x 1 root root   822960 Apr 16 09:21 /usr/lib64/libGL.so.100.14.11
> > lrwxrwxrwx 1 root root   18 Apr 16 09:21 
> > /usr/lib64/libnvidia-cfg.so -> libnvidia-cfg.so.1
> > lrwxrwxrwx 1 root root   26 Apr 16 09:21 
> > /usr/lib64/libnvidia-cfg.so.1 -> libnvidia-cfg.so.100.14.11
> > -rwxr-xr-x 1 root root   127096 Apr 16 09:21 
> > /usr/lib64/libnvidia-cfg.so.100.14.11
> > lrwxrwxrwx 1 root root   26 Apr 16 09:21 
> > /usr/lib64/libnvidia-tls.so.1 -> libnvidia-tls.so.100.14.11
> > -rwxr-xr-x 1 root root 3016 Apr 16 09:21 
> > /usr/lib64/libnvidia-tls.so.100.14.11
> > -r--r--r-- 1 root root   185148 Apr 16 09:21 /usr/lib64/libXvMCNVIDIA.a
> > lrwxrwxrwx 1 root root   26 Apr 16 09:21 
> > /usr/lib64/libXvMCNVIDIA_dynamic.so.1 -> libXvMCNVIDIA.so.100.14.11
> > -rwxr-xr-x 1 root root   137944 Apr 16 09:21 
> > /usr/lib64/libXvMCNVIDIA.so.100.14.11
> > lrwxrwxrwx 1 root root   22 Apr 16 09:21 /usr/lib/libGLcore.so.1 
> > -> libGLcore.so.100.14.11
> > -rwxr-xr-x 1 root root 10080488 Apr 16 09:21 
> > /usr/lib/libGLcore.so.100.14.11
> > -rw-r--r-- 1 root root  659 Apr 16 09:21 /usr/lib/libGL.la
> > lrwxrwxrwx 1 root root   10 Apr 16 09:21 /usr/lib/libGL.so -> 
> > libGL.so.1
> > lrwxrwxrwx 1 root root   18 Apr 16 09:21 /usr/lib/libGL.so.1 -> 
> > libGL.so.100.14.11
> > -rwxr-xr-x 1 root root   608400 Apr 16 09:21 /usr/lib/libGL.so.100.14.11
> > lrwxrwxrwx 1 root root   26 Apr 16 09:21 
> > /usr/lib/libnvidia-tls.so.1 -> libnvidia-tls.so.100.14.11
> > -rwxr-xr-x 1 root root 2352 Apr 16 09:21 
> > /usr/lib/libnvidia-tls.so.100.14.11
> For a test, I temporarily copied the libraries and make the appropriate 
> links on another machine - basically installing the driver manually. I 
> find that now the entire brain displays and I don't get the 
> GLXBadLargeRequest.
> 
> I suppose I could have installed an Nvidia card and installed the driver 
> to a

Re: [Freesurfer] IO with freesurfer files (.mgh in particular) from Python

[Yaroslav Halchenko]

Thank everyone for very informative comments!

I am a newbie in freesurfer myself, I just got a dataset for the
analysis (data was preprocessed in freesurfer), and since I am moving
myself toward doing any analysis in python, and the tools I use now are
python libraries, I wanted to load the data in python.

What I got was

$> /bin/ls -R
.:
lh.exper_dossdintnoage.glmdir  rh.exper.thickness.10.mgh
lh.exper.thickness.10.mgh  rh.exper_dossdintnoage.glmdir 

./lh.exper_dossdintnoage.glmdir:
ar1.mgh  beta.mgh  dossdintnoage  eres.mgh  fsgd.X.mat  mri_glmfit.log  
rstd.mgh  rvar.mgh  Xg.dat  y.fsgd

./lh.exper_dossdintnoage.glmdir/dossdintnoage:
C.dat  F.mgh  gamma.mgh  maxvox.dat  sig.mgh

./rh.exper_dossdintnoage.glmdir:
ar1.mgh  beta.mgh  dossdintnoage  eres.mgh  fsgd.X.mat  mri_glmfit.log  
rstd.mgh  rvar.mgh  Xg.dat  y.fsgd

./rh.exper_dossdintnoage.glmdir/dossdintnoage:
C.dat  F.mgh  gamma.mgh  maxvox.dat  sig.mgh

Also there is a directory on top 
$> ls ../EXPERAVE/
4 label/  0 mri/  0 scripts/  4 stats/  4 surf/  0 tmp/
for the avg subject

If I understand it right, .glmdir are just the result of glm analysis which I
am not interested in at the moment. I wanted to get thickness out, thus
{l,r}h.exper.thickness.10.mgh seemed the one I needed ;)
I'm not sure if they originally were in the proprietary format...

if I got it right mris_convert needs original mesh (lh.inflated) which
was used for the lh.exper.thickness.10.mgh. I have a few for avg subject, but I
am not sure which one (inflated or not) was used for generation of the
thickness or is the thickness mesh independent somehow?

On Thu, 24 Apr 2008, Nick Schmansky wrote:
> But I doubt that helps too much, since I'm guessing you want to avoid
> having to use the freesurfer binaries and want to just read the files
> directly.

well, I can leave with 1 time conversion ;) Having direct interface from python
is a neat thing to have though. by ldd on mris_convert and its size (3MB) I
guess freesurfer statically compiles in IO functionality in. It would be great
if there just was a dynamic library which does IO. Then it could be quite easy
to create python wrapper which would use it more or less directly...

> Nick

-- 
Yaroslav Halchenko
Research Assistant, Psychology Department, Rutgers-Newark
Student  Ph.D. @ CS Dept. NJIT
Office: (973) 353-5440x263 | FWD: 82823 | Fax: (973) 353-1171
101 Warren Str, Smith Hall, Rm 4-105, Newark NJ 07102
WWW: http://www.linkedin.com/in/yarik
___
Freesurfer mailing list
Freesurfer@nmr.mgh.harvard.edu
https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer

[Freesurfer] Question: can't display retinotopy fieldsign data

[Kai Hwang]

Hello,
I'm trying to use freesurfer to map the visual cortex and get region
borders of V1, V2.. etc.
We used a conventional rotating/expanding wedge paradigm, and I followed
the steps described in FsFastIndividualRetinotopy Analysis
(https://surfer.nmr.mgh.harvard.edu/fswiki/FsFastIndividualRetinotopyAnalysis)


Everything worked fine till the last step, I can't view the results with
surf-sess. After I execute the command surf-sess, first a flatten cortex
appeared, then the view screen turned black and nothing showed up.



Here is what I have in the terminal window

[EMAIL PROTECTED]:~/Subjects> surf-sess -s Pilot1 -a VM_retinotopy -retinotopy
fieldsign -flat
grep: /home/hwang/Subjects/Pilot1/session.info: No such file or directory
-
surf-sess logfile is /home/hwang/Subjects/log/surf-sess.VM_retinotopy.fs.log
-
--
--
Session: Pilot1 
-- lh hemisphere --
/home/hwang/Subjects/Pilot1/bold/VM_retinotopy
--
/home/hwang/Subjects/Pilot1/bold/VM_retinotopy
tksurfer -Pilot1 lh inflated -tcl /usr/local/freesurfer/lib/tcl/fs-flat.tcl
--
Loading /usr/local/freesurfer/surface_labels.txt
surfer: current subjects dir: /home/hwang/Subjects
surfer: not in "scripts" dir ==> using cwd for session root
surfer: session root data dir ($session) set to:
surfer: /home/hwang/Subjects/Pilot1/bold/VM_retinotopy
surfer: Reading header info from /home/hwang/Subjects/Pilot1/mri/T1.mgz
surfer: vertices=149915, faces=299826
can't find talairach file
'/home/hwang/Subjects/Pilot1/surf/../mri/orig/COR-.info/../transforms/talairach.xfm'
surfer: ### redraw failed: no gl window open
Reading /usr/local/freesurfer/lib/tcl/tkm_common.tcl
Reading /usr/local/freesurfer/lib/tcl/tkm_wrappers.tcl
Reading /usr/local/freesurfer/lib/tcl/fsgdfPlot.tcl
Reading /usr/local/freesurfer/lib/tcl/tkUtils.tcl
Successfully parsed tksurfer.tcl
reading white matter vertex locations...
tksurfer: fs-flat.tcl: set flags
setdefpatchview: ### position.tcl for Pilot1 does not exist
setdefpatchview: ### setting flatzrot to 90 (default)
setdefpatchview: ### setting flatscale to 1.0 (default)
setdefpatchview: ### setting flatxtrans to 0.0 (default)
setdefpatchview: ### setting flatytrans to 0.0 (default)
readenv.tcl: ==> read global setenv vars
readenv: set invphaseflag 0
readenv: set fm fieldsign/fieldsignmask-lh
readenv: set angle_offset 0
readenv: set dir /home/hwang/Subjects/Pilot1/bold/VM_retinotopy
readenv: set truncphaseflag 0
readenv: set offset 0.4
readenv: set fmid 0.8
readenv: set fs fieldsign/fieldsign-lh
readenv: set lat
readenv: set fthresh 0.4
readenv: set complexname -imag
readenv: set realname -real
readenv: set eccendir eccen
readenv: set floatstem map
readenv: set hemi lh
readenv: set rgbname map
readenv: set use_vertex_arrays 0
readenv: set nosave 0
readenv: set polardir polar
readenv: set noexit
readenv: set curv lh.curv
readenv: set patchname occip.patch.flat
readenv: set fslope 1.3
readenv: set colscale 0
readenv: set mc () {  . /usr/share/mc/bin/mc-wrapper.sh
}
readenv: set smoothsteps 2
readenv: set revpolarflag 0
readenv.tcl: ==> read rgbname-specific setenv vars
%
tksurfer: fs-flat.tcl: read curvature
surfer: single buffered window
surfer: using interface /usr/local/freesurfer/lib/tcl/tksurfer.tcl
tksurfer: run tcl script: /usr/local/freesurfer/lib/tcl/fs-flat.tcl
surfer: curvature read: min=-1.677210 max=1.267429
% tksurfer: fs-flat.tcl: read patch
tksurfer: fs-flat.tcl: read fieldsign
tksurfer: fs-flat.tcl: read fieldsign mask
surfer: read_fieldsign(fieldsign/fieldsign-lh)
surfer: mris->nvertices = 149915, vnum = 149915
surfer: read_fsmask(fieldsign/fieldsignmask-lh)
% tksurfer: fs-flat.tcl: scale, position brain
surfer: ### GL window already open: can't open second
% tksurfer: fs-flat.tcl: save rgb's
tksurfer: fs-flat.tcl: save rgb
surfer: dipscale=0.00
% tksurfer: fs-flat.tcl: nosave setenv'd => nothing will be saved
invalid command name "dontsave_rgb_named"% surfer: dipscale=0.00
% surfer: dipscale=0.00



any suggestion how to make surf-sess work?

Thanks!
Kai
___
Freesurfer mailing list
Freesurfer@nmr.mgh.harvard.edu
https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer

Re: [Freesurfer] Centos 5 freesurfer GLX GLXBadLargeRequest - Install NVidia driver manually?

[Paul Raines]

Wait, you are copying the NVIDIA GL replacement libraries to machines that do 
not have NVIDIA cards and the proprietary nvidia driver installed?  ANd it 
works?  I would think no GL app would run in that case.


Maybe the NVIDIA GL libs are smart enough to handle the case they find
no NVIDIA card/driver.  Anyway, that points to some kind of bug in
the default CentOS GL libs from Mesa.

One thing you can also try is getting the GL libs from some older version
of the default Mesa ones, such as these from the original release of 5.0

mesa-libGL-6.5.1-7.2.el5.i386.rpm
mesa-libGL-devel-6.5.1-7.2.el5.i386.rpm

Looks like the current ones are 7.5.  SO if the 7.2 ones work, then
something was introduced since then.

On Thu, 24 Apr 2008, Brian Hanna wrote:

Yes, that makes sense. But what libraries can I use to run tksurfer -without- 
installing the Nvidia libraries?


Paul Raines wrote:


The problem with the NVIDIA driver installation is that it overwrites
the GL shared lib links and removes the default CentOS GL libs.  If
you then do an update via up2date, yum, or whatever you use to keep
CentOS up to date and one of the packages updated is the GL one, then
the NVIDIA ones get overwritten with the defaults ones again.  The only
fix is to reinstall the NVIDIA driver.

So you have to monitor your upgrades closely and anytime you see an 'xorg'
package upgrage check the GL libs and reinstall NVIDIA if needed.


On Thu, 24 Apr 2008, Brian Hanna wrote:


Hi all,

We are having a problem running tksurfer on several Centos 5 machines. We 
are getting the dreaded GLXBadLargeRequest and just the front sliver of 
the brain displayed. By installing the Nvidia driver manually, we made it 
work.


We have one Centos 5 machine where it is working (machine01). That one 
machine has an Nvidia card and the Nvidia driver installed.


We find that machine01 runs tksurfer correctly locally, and other machines 
can connect to machine01 with VNC and run tksurfer remotely on machine01. 
None of the other machines work correctly.


Following up on the Nvidia driver difference, I notice that the Nvidia 
driver package includes a number of GL libraries. On the other machines, 
standard Centos 5 installs, I see:

$ ls -l /usr/lib*/libGL*
lrwxrwxrwx 1 root root 10 Jan  7 14:57 /usr/lib64/libGL.so -> 
libGL.so.1
lrwxrwxrwx 1 root root 12 Jan  7 14:57 /usr/lib64/libGL.so.1 -> 
libGL.so.1.2

-rwxr-xr-x 1 root root 492720 Nov 10 11:23 /usr/lib64/libGL.so.1.2
lrwxrwxrwx 1 root root 11 Jan  7 14:57 /usr/lib64/libGLU.so -> 
libGLU.so.1
lrwxrwxrwx 1 root root 20 Jan  7 14:57 /usr/lib64/libGLU.so.1 -> 
libGLU.so.1.3.060501
-rwxr-xr-x 1 root root 526048 Nov 10 11:23 
/usr/lib64/libGLU.so.1.3.060501
lrwxrwxrwx 1 root root 12 Apr 23 14:49 /usr/lib/libGL.so.1 -> 
libGL.so.1.2

-rwxr-xr-x 1 root root 432016 Nov 10 11:24 /usr/lib/libGL.so.1.2
lrwxrwxrwx 1 root root 20 Feb  3 16:07 /usr/lib/libGLU.so.1 -> 
libGLU.so.1.3.060501

-rwxr-xr-x 1 root root 524000 Nov 10 11:24 /usr/lib/libGLU.so.1.3.060501
I see (based on the modification time of the install) that there are 
several new libraries installed from Nvidia. That's a new libGL and 10mb 
libGLcore, and my standard libGL.so.1.2 has been zapped.

$ ls -l /usr/lib*/lib* | grep 09:21
lrwxrwxrwx 1 root root   22 Apr 16 09:21 /usr/lib64/libGLcore.so.1 -> 
libGLcore.so.100.14.11
-rwxr-xr-x 1 root root  904 Apr 16 09:21 
/usr/lib64/libGLcore.so.100.14.11

-rw-r--r-- 1 root root  661 Apr 16 09:21 /usr/lib64/libGL.la
lrwxrwxrwx 1 root root   10 Apr 16 09:21 /usr/lib64/libGL.so -> 
libGL.so.1
lrwxrwxrwx 1 root root   18 Apr 16 09:21 /usr/lib64/libGL.so.1 -> 
libGL.so.100.14.11
-rwxr-xr-x 1 root root   822960 Apr 16 09:21 
/usr/lib64/libGL.so.100.14.11
lrwxrwxrwx 1 root root   18 Apr 16 09:21 /usr/lib64/libnvidia-cfg.so 
-> libnvidia-cfg.so.1
lrwxrwxrwx 1 root root   26 Apr 16 09:21 
/usr/lib64/libnvidia-cfg.so.1 -> libnvidia-cfg.so.100.14.11
-rwxr-xr-x 1 root root   127096 Apr 16 09:21 
/usr/lib64/libnvidia-cfg.so.100.14.11
lrwxrwxrwx 1 root root   26 Apr 16 09:21 
/usr/lib64/libnvidia-tls.so.1 -> libnvidia-tls.so.100.14.11
-rwxr-xr-x 1 root root 3016 Apr 16 09:21 
/usr/lib64/libnvidia-tls.so.100.14.11

-r--r--r-- 1 root root   185148 Apr 16 09:21 /usr/lib64/libXvMCNVIDIA.a
lrwxrwxrwx 1 root root   26 Apr 16 09:21 
/usr/lib64/libXvMCNVIDIA_dynamic.so.1 -> libXvMCNVIDIA.so.100.14.11
-rwxr-xr-x 1 root root   137944 Apr 16 09:21 
/usr/lib64/libXvMCNVIDIA.so.100.14.11
lrwxrwxrwx 1 root root   22 Apr 16 09:21 /usr/lib/libGLcore.so.1 -> 
libGLcore.so.100.14.11
-rwxr-xr-x 1 root root 10080488 Apr 16 09:21 
/usr/lib/libGLcore.so.100.14.11

-rw-r--r-- 1 root root  659 Apr 16 09:21 /usr/lib/libGL.la
lrwxrwxrwx 1 root root   10 Apr 16 09:21 /usr/lib/libGL.so -> 
libGL.so.1
lrwxrwxrwx 1 root root   18 Apr 16 09:21 /usr/lib/libGL.so.1 -> 
libGL.so.100.14.11

-rwxr-xr-x 1 root root   608400 Apr 16 09:21 /usr/lib/libGL.so.100.14.11
lrwxrwxrwx 1 ro

Re: [Freesurfer] Centos 5 freesurfer GLX GLXBadLargeRequest - Install NVidia driver manually?

[Brian Hanna]

Yes, qdec apparently works ok without the Nvidia driver libraries.

We want to run tksurfer remotely, so the video card won't really be 
used. But apparently we need special functionality that does not exist 
in the standard GL libraries.


Purchasing a video card just to get access to the driver libraries - is 
this what we need to do?


Or is there a standard, open-source GL library that supports everything 
that tksurfer requires?


Thanks,

Brian

Nick Schmansky wrote:

Brian,

Does the 'qdec' application run for you on Centos5?  


Our apps do not require any particular graphics card.  Through
experience, it seems the Nvidia cards give the least trouble (compared
to ATI), but we have never been able to track down exactly why
(something in the bowels of each manufactures OpenGL/GLX
implementation).  I think, but am not positive, that GLX is graphics-
card specific (well I would think OpenGL is too), and tksurfer uses GLX
(although I think there is a way to force software rendering), so I
cannot say how the default Centos5 GL/GLX drivers will behave.

So for the systems that are not working, what graphics card is
installed?

Nick

On Thu, 2008-04-24 at 11:54 -0500, Brian Hanna wrote:
  

Hi all,

We are having a problem running tksurfer on several Centos 5 machines. 
We are getting the dreaded GLXBadLargeRequest and just the front sliver 
of the brain displayed. By installing the Nvidia driver manually, we 
made it work.


We have one Centos 5 machine where it is working (machine01). That one 
machine has an Nvidia card and the Nvidia driver installed.


We find that machine01 runs tksurfer correctly locally, and other 
machines can connect to machine01 with VNC and run tksurfer remotely on 
machine01. None of the other machines work correctly.


Following up on the Nvidia driver difference, I notice that the Nvidia 
driver package includes a number of GL libraries. On the other machines, 
standard Centos 5 installs, I see:


$ ls -l /usr/lib*/libGL*
lrwxrwxrwx 1 root root 10 Jan  7 14:57 /usr/lib64/libGL.so -> 
libGL.so.1
lrwxrwxrwx 1 root root 12 Jan  7 14:57 /usr/lib64/libGL.so.1 -> 
libGL.so.1.2

-rwxr-xr-x 1 root root 492720 Nov 10 11:23 /usr/lib64/libGL.so.1.2
lrwxrwxrwx 1 root root 11 Jan  7 14:57 /usr/lib64/libGLU.so -> 
libGLU.so.1
lrwxrwxrwx 1 root root 20 Jan  7 14:57 /usr/lib64/libGLU.so.1 -> 
libGLU.so.1.3.060501

-rwxr-xr-x 1 root root 526048 Nov 10 11:23 /usr/lib64/libGLU.so.1.3.060501
lrwxrwxrwx 1 root root 12 Apr 23 14:49 /usr/lib/libGL.so.1 -> 
libGL.so.1.2

-rwxr-xr-x 1 root root 432016 Nov 10 11:24 /usr/lib/libGL.so.1.2
lrwxrwxrwx 1 root root 20 Feb  3 16:07 /usr/lib/libGLU.so.1 -> 
libGLU.so.1.3.060501

-rwxr-xr-x 1 root root 524000 Nov 10 11:24 /usr/lib/libGLU.so.1.3.060501
  
I see (based on the modification time of the install) that there are 
several new libraries installed from Nvidia. That's a new libGL and 10mb 
libGLcore, and my standard libGL.so.1.2 has been zapped.


$ ls -l /usr/lib*/lib* | grep 09:21
lrwxrwxrwx 1 root root   22 Apr 16 09:21 /usr/lib64/libGLcore.so.1 
-> libGLcore.so.100.14.11
-rwxr-xr-x 1 root root  904 Apr 16 09:21 
/usr/lib64/libGLcore.so.100.14.11

-rw-r--r-- 1 root root  661 Apr 16 09:21 /usr/lib64/libGL.la
lrwxrwxrwx 1 root root   10 Apr 16 09:21 /usr/lib64/libGL.so -> 
libGL.so.1
lrwxrwxrwx 1 root root   18 Apr 16 09:21 /usr/lib64/libGL.so.1 -> 
libGL.so.100.14.11

-rwxr-xr-x 1 root root   822960 Apr 16 09:21 /usr/lib64/libGL.so.100.14.11
lrwxrwxrwx 1 root root   18 Apr 16 09:21 
/usr/lib64/libnvidia-cfg.so -> libnvidia-cfg.so.1
lrwxrwxrwx 1 root root   26 Apr 16 09:21 
/usr/lib64/libnvidia-cfg.so.1 -> libnvidia-cfg.so.100.14.11
-rwxr-xr-x 1 root root   127096 Apr 16 09:21 
/usr/lib64/libnvidia-cfg.so.100.14.11
lrwxrwxrwx 1 root root   26 Apr 16 09:21 
/usr/lib64/libnvidia-tls.so.1 -> libnvidia-tls.so.100.14.11
-rwxr-xr-x 1 root root 3016 Apr 16 09:21 
/usr/lib64/libnvidia-tls.so.100.14.11

-r--r--r-- 1 root root   185148 Apr 16 09:21 /usr/lib64/libXvMCNVIDIA.a
lrwxrwxrwx 1 root root   26 Apr 16 09:21 
/usr/lib64/libXvMCNVIDIA_dynamic.so.1 -> libXvMCNVIDIA.so.100.14.11
-rwxr-xr-x 1 root root   137944 Apr 16 09:21 
/usr/lib64/libXvMCNVIDIA.so.100.14.11
lrwxrwxrwx 1 root root   22 Apr 16 09:21 /usr/lib/libGLcore.so.1 
-> libGLcore.so.100.14.11
-rwxr-xr-x 1 root root 10080488 Apr 16 09:21 
/usr/lib/libGLcore.so.100.14.11

-rw-r--r-- 1 root root  659 Apr 16 09:21 /usr/lib/libGL.la
lrwxrwxrwx 1 root root   10 Apr 16 09:21 /usr/lib/libGL.so -> 
libGL.so.1
lrwxrwxrwx 1 root root   18 Apr 16 09:21 /usr/lib/libGL.so.1 -> 
libGL.so.100.14.11

-rwxr-xr-x 1 root root   608400 Apr 16 09:21 /usr/lib/libGL.so.100.14.11
lrwxrwxrwx 1 root root   26 Apr 16 09:21 
/usr/lib/libnvidia-tls.so.1 -> libnvidia-tls.so.100.14.11
-rwxr-xr-x 1 root root 2352 Apr 16 09:21 
/usr/lib/libnvidia-tls.so.100.14.11
  
For a test, I temporarily copied the libraries and make the appr

Re: [Freesurfer] Centos 5 freesurfer GLX GLXBadLargeRequest - Install NVidia driver manually?

[Brian Hanna]

Well, yes, as a test I copied in the Nvidia GL libraries. For remote 
VNC, it works. Locally, though, glxgears and glxinfo now give segfaults.


On the wiki, I see a downloadable version of vncserver.glx.

http://surfer.nmr.mgh.harvard.edu/fswiki/RemoteAccess

This version sets up which refers to some special GLoverride libraries 
at mgh.


if ($ENV{LD_LIBRARY_PATH}) {
 $ENV{LD_LIBRARY_PATH} = '/usr/lib64/GLoverride:/usr/lib/GLoverride:' . 
$ENV{LD_LIBRARY_PATH};

} else {
 $ENV{LD_LIBRARY_PATH} = '/usr/lib64/GLoverride:/usr/lib/GLoverride';
}


What is in those libraries - where did they come from? Perhaps this is 
the approach I need to use - leave the standard distro GL libraries in 
place, and put the Nvidia libraries into another location for use only 
by vnc.


Thanks,

Brian


Paul Raines wrote:


Wait, you are copying the NVIDIA GL replacement libraries to machines 
that do not have NVIDIA cards and the proprietary nvidia driver 
installed?  ANd it works?  I would think no GL app would run in that 
case.


Maybe the NVIDIA GL libs are smart enough to handle the case they find
no NVIDIA card/driver.  Anyway, that points to some kind of bug in
the default CentOS GL libs from Mesa.

One thing you can also try is getting the GL libs from some older version
of the default Mesa ones, such as these from the original release of 5.0

mesa-libGL-6.5.1-7.2.el5.i386.rpm
mesa-libGL-devel-6.5.1-7.2.el5.i386.rpm

Looks like the current ones are 7.5.  SO if the 7.2 ones work, then
something was introduced since then.

On Thu, 24 Apr 2008, Brian Hanna wrote:

Yes, that makes sense. But what libraries can I use to run tksurfer 
-without- installing the Nvidia libraries?


Paul Raines wrote:


The problem with the NVIDIA driver installation is that it overwrites
the GL shared lib links and removes the default CentOS GL libs.  If
you then do an update via up2date, yum, or whatever you use to keep
CentOS up to date and one of the packages updated is the GL one, then
the NVIDIA ones get overwritten with the defaults ones again.  The only
fix is to reinstall the NVIDIA driver.

So you have to monitor your upgrades closely and anytime you see an 
'xorg'

package upgrage check the GL libs and reinstall NVIDIA if needed.


On Thu, 24 Apr 2008, Brian Hanna wrote:


Hi all,

We are having a problem running tksurfer on several Centos 5 
machines. We are getting the dreaded GLXBadLargeRequest and just 
the front sliver of the brain displayed. By installing the Nvidia 
driver manually, we made it work.


We have one Centos 5 machine where it is working (machine01). That 
one machine has an Nvidia card and the Nvidia driver installed.


We find that machine01 runs tksurfer correctly locally, and other 
machines can connect to machine01 with VNC and run tksurfer 
remotely on machine01. None of the other machines work correctly.


Following up on the Nvidia driver difference, I notice that the 
Nvidia driver package includes a number of GL libraries. On the 
other machines, standard Centos 5 installs, I see:

$ ls -l /usr/lib*/libGL*
lrwxrwxrwx 1 root root 10 Jan  7 14:57 /usr/lib64/libGL.so -> 
libGL.so.1
lrwxrwxrwx 1 root root 12 Jan  7 14:57 /usr/lib64/libGL.so.1 
-> libGL.so.1.2

-rwxr-xr-x 1 root root 492720 Nov 10 11:23 /usr/lib64/libGL.so.1.2
lrwxrwxrwx 1 root root 11 Jan  7 14:57 /usr/lib64/libGLU.so -> 
libGLU.so.1
lrwxrwxrwx 1 root root 20 Jan  7 14:57 /usr/lib64/libGLU.so.1 
-> libGLU.so.1.3.060501
-rwxr-xr-x 1 root root 526048 Nov 10 11:23 
/usr/lib64/libGLU.so.1.3.060501
lrwxrwxrwx 1 root root 12 Apr 23 14:49 /usr/lib/libGL.so.1 -> 
libGL.so.1.2

-rwxr-xr-x 1 root root 432016 Nov 10 11:24 /usr/lib/libGL.so.1.2
lrwxrwxrwx 1 root root 20 Feb  3 16:07 /usr/lib/libGLU.so.1 -> 
libGLU.so.1.3.060501
-rwxr-xr-x 1 root root 524000 Nov 10 11:24 
/usr/lib/libGLU.so.1.3.060501
I see (based on the modification time of the install) that there 
are several new libraries installed from Nvidia. That's a new libGL 
and 10mb libGLcore, and my standard libGL.so.1.2 has been zapped.

$ ls -l /usr/lib*/lib* | grep 09:21
lrwxrwxrwx 1 root root   22 Apr 16 09:21 
/usr/lib64/libGLcore.so.1 -> libGLcore.so.100.14.11
-rwxr-xr-x 1 root root  904 Apr 16 09:21 
/usr/lib64/libGLcore.so.100.14.11

-rw-r--r-- 1 root root  661 Apr 16 09:21 /usr/lib64/libGL.la
lrwxrwxrwx 1 root root   10 Apr 16 09:21 /usr/lib64/libGL.so 
-> libGL.so.1
lrwxrwxrwx 1 root root   18 Apr 16 09:21 /usr/lib64/libGL.so.1 
-> libGL.so.100.14.11
-rwxr-xr-x 1 root root   822960 Apr 16 09:21 
/usr/lib64/libGL.so.100.14.11
lrwxrwxrwx 1 root root   18 Apr 16 09:21 
/usr/lib64/libnvidia-cfg.so -> libnvidia-cfg.so.1
lrwxrwxrwx 1 root root   26 Apr 16 09:21 
/usr/lib64/libnvidia-cfg.so.1 -> libnvidia-cfg.so.100.14.11
-rwxr-xr-x 1 root root   127096 Apr 16 09:21 
/usr/lib64/libnvidia-cfg.so.100.14.11
lrwxrwxrwx 1 root root   26 Apr 16 09:21 
/usr/lib64/libnvidia-tls.so.1 -> libnvidia-tls.so.100.14.11
-rwxr-xr-x 1 root root 3016

Re: [Freesurfer] Centos 5 freesurfer GLX GLXBadLargeRequest - Install NVidia driver manually?

[Paul Raines]

At the Martinos Center, I have extracted the GL libraries from the Mesa
rpms and put them in those directories.  When some one is using VNC
(or even doing remote X), it is better to use those libraries than
the ones that come with NVIDIA.  Otherwise they do get errors.  Which
is pretty much the opposite of what you are describing.

The libs I have in /usr/lib64/GLoverride:/usr/lib/GLoverride were
extraced long ago and I have not kept them up to date with new
Mesa updates that come with CentOS unless a problem has arisen

So you putting the NVIDIA libraries there would be the complete opposite
of what we are doing.


On Thu, 24 Apr 2008, Brian Hanna wrote:

Well, yes, as a test I copied in the Nvidia GL libraries. For remote VNC, it 
works. Locally, though, glxgears and glxinfo now give segfaults.


On the wiki, I see a downloadable version of vncserver.glx.

http://surfer.nmr.mgh.harvard.edu/fswiki/RemoteAccess

This version sets up which refers to some special GLoverride libraries at 
mgh.


if ($ENV{LD_LIBRARY_PATH}) {
$ENV{LD_LIBRARY_PATH} = '/usr/lib64/GLoverride:/usr/lib/GLoverride:' . 
$ENV{LD_LIBRARY_PATH};

} else {
$ENV{LD_LIBRARY_PATH} = '/usr/lib64/GLoverride:/usr/lib/GLoverride';
}


What is in those libraries - where did they come from? Perhaps this is the 
approach I need to use - leave the standard distro GL libraries in place, and 
put the Nvidia libraries into another location for use only by vnc.


Thanks,

Brian


Paul Raines wrote:


Wait, you are copying the NVIDIA GL replacement libraries to machines that 
do not have NVIDIA cards and the proprietary nvidia driver installed?  ANd 
it works?  I would think no GL app would run in that case.


Maybe the NVIDIA GL libs are smart enough to handle the case they find
no NVIDIA card/driver.  Anyway, that points to some kind of bug in
the default CentOS GL libs from Mesa.

One thing you can also try is getting the GL libs from some older version
of the default Mesa ones, such as these from the original release of 5.0

mesa-libGL-6.5.1-7.2.el5.i386.rpm
mesa-libGL-devel-6.5.1-7.2.el5.i386.rpm

Looks like the current ones are 7.5.  SO if the 7.2 ones work, then
something was introduced since then.

On Thu, 24 Apr 2008, Brian Hanna wrote:

Yes, that makes sense. But what libraries can I use to run tksurfer 
-without- installing the Nvidia libraries?


Paul Raines wrote:


The problem with the NVIDIA driver installation is that it overwrites
the GL shared lib links and removes the default CentOS GL libs.  If
you then do an update via up2date, yum, or whatever you use to keep
CentOS up to date and one of the packages updated is the GL one, then
the NVIDIA ones get overwritten with the defaults ones again.  The only
fix is to reinstall the NVIDIA driver.

So you have to monitor your upgrades closely and anytime you see an 
'xorg'

package upgrage check the GL libs and reinstall NVIDIA if needed.


On Thu, 24 Apr 2008, Brian Hanna wrote:


Hi all,

We are having a problem running tksurfer on several Centos 5 machines. 
We are getting the dreaded GLXBadLargeRequest and just the front sliver 
of the brain displayed. By installing the Nvidia driver manually, we 
made it work.


We have one Centos 5 machine where it is working (machine01). That one 
machine has an Nvidia card and the Nvidia driver installed.


We find that machine01 runs tksurfer correctly locally, and other 
machines can connect to machine01 with VNC and run tksurfer remotely on 
machine01. None of the other machines work correctly.


Following up on the Nvidia driver difference, I notice that the Nvidia 
driver package includes a number of GL libraries. On the other machines, 
standard Centos 5 installs, I see:

$ ls -l /usr/lib*/libGL*
lrwxrwxrwx 1 root root 10 Jan  7 14:57 /usr/lib64/libGL.so -> 
libGL.so.1
lrwxrwxrwx 1 root root 12 Jan  7 14:57 /usr/lib64/libGL.so.1 -> 
libGL.so.1.2

-rwxr-xr-x 1 root root 492720 Nov 10 11:23 /usr/lib64/libGL.so.1.2
lrwxrwxrwx 1 root root 11 Jan  7 14:57 /usr/lib64/libGLU.so -> 
libGLU.so.1
lrwxrwxrwx 1 root root 20 Jan  7 14:57 /usr/lib64/libGLU.so.1 -> 
libGLU.so.1.3.060501
-rwxr-xr-x 1 root root 526048 Nov 10 11:23 
/usr/lib64/libGLU.so.1.3.060501
lrwxrwxrwx 1 root root 12 Apr 23 14:49 /usr/lib/libGL.so.1 -> 
libGL.so.1.2

-rwxr-xr-x 1 root root 432016 Nov 10 11:24 /usr/lib/libGL.so.1.2
lrwxrwxrwx 1 root root 20 Feb  3 16:07 /usr/lib/libGLU.so.1 -> 
libGLU.so.1.3.060501
-rwxr-xr-x 1 root root 524000 Nov 10 11:24 
/usr/lib/libGLU.so.1.3.060501
I see (based on the modification time of the install) that there are 
several new libraries installed from Nvidia. That's a new libGL and 10mb 
libGLcore, and my standard libGL.so.1.2 has been zapped.

$ ls -l /usr/lib*/lib* | grep 09:21
lrwxrwxrwx 1 root root   22 Apr 16 09:21 /usr/lib64/libGLcore.so.1 
-> libGLcore.so.100.14.11
-rwxr-xr-x 1 root root  904 Apr 16 09:21 
/usr/lib64/libGLcore.so.100.14.11

-rw-r--r-- 1 root root  661 Apr 16 09:21 /usr/lib64/libGL.la
lrwxrw

Re: [Freesurfer] Experience with -localGI on Mac

[Martin Kavec]

Hi Nick,

I am just giving a try to the new mris_compute_lgi matlab script kindly 
provided by Marie, and so far so good. I would appreciate the new binary for: 
Mac OS X 10.5.2, linux_x86, and linux_x86_64.

Thanks a lot.

Martin

On Thursday 24 April 2008 18:40:12 Nick Schmansky wrote:
> Martin and other -localGI users,
>
> Independent of the matlab problem, there was a bug that was just
> discovered, affecting mris_fill, that breaks the -localGI usage.  A fix
> will be provided (hopefully along with a fix for this matlab problem) in
> v4.0.4.  If you need to use the -localGI feature, I can provide fixed
> binaries as they appear (email me to request these).
>
> Nick
___
Freesurfer mailing list
Freesurfer@nmr.mgh.harvard.edu
https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer

Re: [Freesurfer] Experience with -localGI on Mac

[Nick Schmansky]

Martin,

The binary mris_fill for these OSs can be downloaded from here:

ftp://surfer.nmr.mgh.harvard.edu/transfer/outgoing/fsdev/nicks/stable

Nick


On Thu, 2008-04-24 at 20:43 +0200, Martin Kavec wrote:
> Hi Nick,
> 
> I am just giving a try to the new mris_compute_lgi matlab script kindly 
> provided by Marie, and so far so good. I would appreciate the new binary for: 
> Mac OS X 10.5.2, linux_x86, and linux_x86_64.
> 
> Thanks a lot.
> 
> Martin
> 
> On Thursday 24 April 2008 18:40:12 Nick Schmansky wrote:
> > Martin and other -localGI users,
> >
> > Independent of the matlab problem, there was a bug that was just
> > discovered, affecting mris_fill, that breaks the -localGI usage.  A fix
> > will be provided (hopefully along with a fix for this matlab problem) in
> > v4.0.4.  If you need to use the -localGI feature, I can provide fixed
> > binaries as they appear (email me to request these).
> >
> > Nick
> 
> 

___
Freesurfer mailing list
Freesurfer@nmr.mgh.harvard.edu
https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer

Re: [Freesurfer] IO with freesurfer files (.mgh in particular) from Python

[Krish Subramaniam]

Hi Yaroslav and Pádraig,

Please follow the link pasted below to get an alpha version of pymgh.  
It requires the latest Python and Numpy.


https://www.nmr.mgh.harvard.edu/facility/filedrop/showgroup/10224/1/2a5da2a125134fbdfc9e6850be1fcc09 
 (expires in 30 days )


Make sure PYTHONPATH has the directory which contains 'pymgh'. Found  
by typing,


>>>import sys
>>>sys.path

As far as the usage goes, pymgh basically instantiates a "MGH" class  
( which contains details about the header as well as the data ) when  
you call the load() method. There is a class save() method as well as  
a module save() method ( static function)

The following examples will throw more light.

from pymgh import mgh
m = mgh.MGH()
m.load('test.mgz') # this loads information from test.mgz onto m.  
Both .mgh and .mgz work


m.header # see the header information

m.vol # the N-D numpy volume of the same datatype as mri_type

v = m.vol * 3 # some basic manipulation

m.save(filename = 'modtest.mgz', volume = v ) # save the new volume  
with same headers onto a different file


There is also a module method mgh.save() which requires all keyword  
arguments. More documentation on functions are found in their  
docstrings and I am afraid it's the only documentation available now.  
pymgh mostly follows the structure in the wiki page describing  
MGHformat. And the resulting Numpy volume has the exact shape as the  
MATLAB volume loaded by load_mgh.m


This package is fresh, so expect surprises. I request you to go to the  
tests/ directory and run the test_mgh_io.py before everything. It has  
a few basic sanity tests.


cd tests/
python test_mgh_io.py -v 2

Contact me ( krish @ nmr... ) if you want to report a bug /  
suggestions etc.


Thanks
Krish

On Apr 24, 2008, at 1:23 PM, Yaroslav Halchenko wrote:





well, I can leave with 1 time conversion ;) Having direct interface  
from python
is a neat thing to have though. by ldd on mris_convert and its size  
(3MB) I
guess freesurfer statically compiles in IO functionality in. It  
would be great
if there just was a dynamic library which does IO. Then it could be  
quite easy

to create python wrapper which would use it more or less directly...





___
Freesurfer mailing list
Freesurfer@nmr.mgh.harvard.edu
https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer

[Freesurfer] percent signal change

[Elif SIKOGLU]

Hello,


We want to get the percent signal change for the activated regions and for
that we want to use the h.nii and h-offset.nii files.

We plan to divide the h.nii by h-offset.nii .


First of all is this a correct approach?


Second, h.nii has 4 frames in it, which one do we really need?


Thanks

Elif
___
Freesurfer mailing list
Freesurfer@nmr.mgh.harvard.edu
https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer

Re: [Freesurfer] percent signal change

[Doug Greve]

Yes, it is. The h.nii file has a somewhat tortured format. If you just 
want the contrast as a percent, then look in the contast directory for 
cespct.


Elif SIKOGLU wrote:


Hello,


We want to get the percent signal change for the activated regions and 
for that we want to use the h.nii and h-offset.nii files.


We plan to divide the h.nii by h-offset.nii .


First of all is this a correct approach?


Second, h.nii has 4 frames in it, which one do we really need?


Thanks

Elif



___
Freesurfer mailing list
Freesurfer@nmr.mgh.harvard.edu
https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer



--
Douglas N. Greve, Ph.D.
MGH-NMR Center
[EMAIL PROTECTED]
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


___
Freesurfer mailing list
Freesurfer@nmr.mgh.harvard.edu
https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer

Re: [Freesurfer] VNC/GLX... what is really vncserver.glx

[Tsung-Ren Huang]

Hi Yaroslav,

You can comment out those lines regarding GLoverride.
The real magic, as pointed out by Nick, is acutally the xf4vnc 
that can be downloaded from http://sourceforge.net/projects/xf4vnc .

Tren

> On Mon, 2007-01-15 at 23:27 -0500, Yaroslav Halchenko wrote:
> Thank you very much for providing the script.  Now the question is what
> magic do you keep under /usr/lib64/GLoverride:/usr/lib/GLoverride
> because the rest of the script seems to be close to the standard
> vnc server script shipped originally (Debian maintainer introduced some
> changes as well but most only for parameter/configuration
> specifications).

>> On Tue, 16 Jan 2007, Nick Schmansky wrote:
>> Yaroslav,
>> If you goto that RemoteAccess wiki page, and click on 'vncserver.glx',
>> it will now allow you to download that script.  You will have to modify
>> it a bit: look for instances of /usr/pubsw/packages, which point to our
>> installation of VNC.
>> Nick
___
Freesurfer mailing list
Freesurfer@nmr.mgh.harvard.edu
https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer

Re: [Freesurfer] VNC/GLX... what is really vncserver.glx

[Yaroslav Halchenko]

Thank you Tren,

Actually Nick Schmansky at the time of original request pointed me out
(I believe in an offlist conversation) to xf4vnc, I have built it
then from CVS snapshot (there were/are no source tarballs), but it was
segfaulting. Debian maintainer of VNC packages unfortunately isn't
really eager to jump into burden of building yet another VNC package for
Debian, so I just abandoned idea of using xf4vnc at that moment. May be
now is a good timing to give it a shout again ;)

On Thu, 24 Apr 2008, Tsung-Ren Huang wrote:

> Hi Yaroslav,

> You can comment out those lines regarding GLoverride.
> The real magic, as pointed out by Nick, is acutally the xf4vnc 
> that can be downloaded from http://sourceforge.net/projects/xf4vnc .

> Tren
d
> > On Mon, 2007-01-15 at 23:27 -0500, Yaroslav Halchenko wrote:
> > Thank you very much for providing the script.  Now the question is what
> > magic do you keep under /usr/lib64/GLoverride:/usr/lib/GLoverride
> > because the rest of the script seems to be close to the standard
> > vnc server script shipped originally (Debian maintainer introduced some
> > changes as well but most only for parameter/configuration
> > specifications).

> >> On Tue, 16 Jan 2007, Nick Schmansky wrote:
> >> Yaroslav,
> >> If you goto that RemoteAccess wiki page, and click on 'vncserver.glx',
> >> it will now allow you to download that script.  You will have to modify
> >> it a bit: look for instances of /usr/pubsw/packages, which point to our
> >> installation of VNC.
> >> Nick


-- 
Yaroslav Halchenko
Research Assistant, Psychology Department, Rutgers-Newark
Student  Ph.D. @ CS Dept. NJIT
Office: (973) 353-5440x263 | FWD: 82823 | Fax: (973) 353-1171
101 Warren Str, Smith Hall, Rm 4-105, Newark NJ 07102
WWW: http://www.linkedin.com/in/yarik
___
Freesurfer mailing list
Freesurfer@nmr.mgh.harvard.edu
https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer