From minc-users@bic.mni.mcgill.ca Fri Jul 1 08:54:05 2005 From: minc-users@bic.mni.mcgill.ca (Nugent, Allison C. (NIH/NIMH)) Date: Fri Jul 1 07:54:05 2005 Subject: [MINC-users] cortical thickness code Message-ID: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C57D7E.2BE04B9D Content-Type: text/plain Hello all, I read on the freesurfer mailing list that the MNI publicly distribute their cortical thickness code but I can't find it on any of the web pages. Is it publicly available? Thanks! Allison Allison Nugent MRI Physicist SNMAD/MIB/NIMH/NIH Office: (301)451-8863 Mobile: (301)408-8560 nugenta@mail.nih.gov ------_=_NextPart_001_01C57D7E.2BE04B9D Content-Type: text/html

Hello all,

            I read on the freesurfer mailing list that the MNI publicly distribute their cortical thickness code but I can't find it on any of the web pages. Is it publicly available?

 

Thanks!

 

Allison

 

Allison Nugent

MRI Physicist

SNMAD/MIB/NIMH/NIH

Office: (301)451-8863

Mobile: (301)408-8560

nugenta@mail.nih.gov

 

------_=_NextPart_001_01C57D7E.2BE04B9D-- From minc-users@bic.mni.mcgill.ca Fri Jul 1 08:54:42 2005 From: minc-users@bic.mni.mcgill.ca (tomas kasparek) Date: Fri Jul 1 07:54:42 2005 Subject: [MINC-users] Error - building Display 1.3.9 Message-ID: <200507011120.17527@centrum.cz> ______________________________________________________________ Hi! I installed the missing package and everyghing went OK then. So, thank you for the assistance! Tomas Kasparek Dep. of Psychiatry, Masaryk University Brno, the Czech Republic > Od: jason@bic.mni.mcgill.ca > Komu: minc-users@bic.mni.mcgill.ca > CC: > Datum: 30.06.2005 01:53 > Pøedmìt: Re: [MINC-users] Error - building Display 1.3.9 > > Greetings, > > where did you get the source from? And what options did you pass to > configure? > > And ppm is an image library that is part of netpbm - an open source > library for which Mandrake surely has packages. > > Cheers, > > Jason > > On Jun 24, 2005, at 6:18 AM, tomas kasparek wrote: > > > Hi there! > > I tried to build Display 1.3.9 under Mandrake 9.2, gcc 3.3.1, ld > > 2.14.90 and got this error during "make": > > > > ...Graphics/libbicgl.a /usr/lib/libglut.so /usr/lib/libGLU.so > > /usr/lib/libGL.so -lXext -lpthread -lSM -lICE -lX11 -lXmu -lXi > > /usr/lib/libbicpl.a -L/home/jason/lib -L/usr/local/mni/lib > > -L/usr/local/qt3/lib -lppm /usr/local/lib/libvolume_io.a > > /usr/local/lib/libminc.a -lnetcdf -lm > > /usr/bin/ld: cannot find -lppm > > collect2: ld returned 1 exit status... > > > > I don't have anything like /home/jason/lib or /usr/local/qt3/lib... > > > > Anybody there to translate it to human language? Or tell me, what is > > '-lppm'? > > > > Thank You, > > Tomas Kasparek > > > > _______________________________________________ > > MINC-users@bic.mni.mcgill.ca > > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users > > _______________________________________________ > MINC-users@bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users > > From Andrew Liu Fri Jul 1 12:52:03 2005 From: Andrew Liu (Andrew Liu) Date: Fri Jul 1 11:52:03 2005 Subject: [MINC-users] mincresample and weird intensities Message-ID: Hi I have an image volume that I wish to resample to .8 mm cubic voxels from 1.2x0.9375x0.9375 mm voxels, but when I run mincresample -step .8 .8 .8 in.mnc out.mnc I get a volume where the colorbar in display gives me a range from 0 to 1.17549e-36, and the volume doesn't seem to contain any information (all zeros). I can view the original image in display with no problems. What's going on here and how do I go about fixing it? Thanks for your help! From minc-users@bic.mni.mcgill.ca Sun Jul 3 19:01:04 2005 From: minc-users@bic.mni.mcgill.ca (Morgan Hough) Date: Sun Jul 3 18:01:04 2005 Subject: [MINC-users] minc-1.4 on Mac OS X 10.4.1 Message-ID: <1120427815.15312.11.camel@dhania.fmrib.ox.ac.uk> Anybody try building minc-1.4 on tiger? I just got this error. if /bin/sh ./libtool --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I. -I./libsrc -I./volume_io/Include -I./volume_io/Include -I./progs/Proglib -I./conversion/Acr_nema -I/opt/local/include -g -O2 -MT volume_io/Prog_utils/time.lo -MD -MP -MF "$depbase.Tpo" -c -o volume_io/Prog_utils/time.lo volume_io/Prog_utils/time.c; \then mv -f "$depbase.Tpo" "$depbase.Plo"; else rm -f "$depbase.Tpo"; exit 1; figcc -DHAVE_CONFIG_H -I. -I. -I. -I./libsrc -I./volume_io/Include -I./volume_io/Include -I./progs/Proglib -I./conversion/Acr_nema -I/opt/local/include -g -O2 -MT volume_io/Prog_utils/time.lo -MD -MP -MF volume_io/Prog_utils/.deps/time.Tpo -c volume_io/Prog_utils/time.c -o volume_io/Prog_utils/time.ovolume_io/Prog_utils/time.c: In function 'get_clock_ticks_per_second':volume_io/Prog_utils/time.c:59: error: 'CLK_TCK' undeclared (first use in this function)volume_io/Prog_utils/time.c:59: error: (Each undeclared identifier is reported only oncevolume_io/Prog_utils/time.c:59: error: for each function it appears in.)make[2]: *** [volume_io/Prog_utils/time.lo] Error 1make[1]: *** [all-recursive] Error 1make: *** [all] Error 2 Thanks in advance. Cheers, -Morgan -- Morgan Hough DPhil student FMRIB, John Radcliffe Hospital, Headington, Oxford OX3 9DU, UK mhough@fmrib.ox.ac.uk www.fmrib.ox.ac.uk/~mhough tel +44 (0) 1865 222545 fax +44 (0) 1865 222717 From minc-users@bic.mni.mcgill.ca Sun Jul 3 19:21:04 2005 From: minc-users@bic.mni.mcgill.ca (Steve M. Robbins) Date: Sun Jul 3 18:21:04 2005 Subject: [MINC-users] minc-1.4 on Mac OS X 10.4.1 In-Reply-To: <1120427815.15312.11.camel@dhania.fmrib.ox.ac.uk> References: <1120427815.15312.11.camel@dhania.fmrib.ox.ac.uk> Message-ID: <20050703221743.GB8746@nyongwa.montreal.qc.ca> On Sun, Jul 03, 2005 at 10:56:55PM +0100, Morgan Hough wrote: > volume_io/Prog_utils/time.ovolume_io/Prog_utils/time.c: In function > 'get_clock_ticks_per_second':volume_io/Prog_utils/time.c:59: error: > 'CLK_TCK' undeclared (first use in this > function)volume_io/Prog_utils/time.c:59: error: (Each undeclared > identifier is reported only oncevolume_io/Prog_utils/time.c:59: error: > for each function it appears in.)make[2]: *** > [volume_io/Prog_utils/time.lo] Error 1make[1]: *** [all-recursive] Error > 1make: *** [all] Error 2 Change the line in time.c that reads clock_ticks_per_second = (Real) CLK_TCK; to clock_ticks_per_second = (Real) sysconf( _SC_CLK_TCK ); -S From minc-users@bic.mni.mcgill.ca Sun Jul 3 19:48:04 2005 From: minc-users@bic.mni.mcgill.ca (Morgan Hough) Date: Sun Jul 3 18:48:04 2005 Subject: [MINC-users] minc-1.4 on Mac OS X 10.4.1 In-Reply-To: <20050703221743.GB8746@nyongwa.montreal.qc.ca> References: <1120427815.15312.11.camel@dhania.fmrib.ox.ac.uk> <20050703221743.GB8746@nyongwa.montreal.qc.ca> Message-ID: <1120430656.15335.36.camel@dhania.fmrib.ox.ac.uk> Steve, Thanks. That took care of it. Cheers, -Morgan On Sun, 2005-07-03 at 23:17, Steve M. Robbins wrote: > On Sun, Jul 03, 2005 at 10:56:55PM +0100, Morgan Hough wrote: > > > volume_io/Prog_utils/time.ovolume_io/Prog_utils/time.c: In function > > 'get_clock_ticks_per_second':volume_io/Prog_utils/time.c:59: error: > > 'CLK_TCK' undeclared (first use in this > > function)volume_io/Prog_utils/time.c:59: error: (Each undeclared > > identifier is reported only oncevolume_io/Prog_utils/time.c:59: error: > > for each function it appears in.)make[2]: *** > > [volume_io/Prog_utils/time.lo] Error 1make[1]: *** [all-recursive] Error > > 1make: *** [all] Error 2 > > Change the line in time.c that reads > > clock_ticks_per_second = (Real) CLK_TCK; > > to > > clock_ticks_per_second = (Real) sysconf( _SC_CLK_TCK ); > > > -S > _______________________________________________ > MINC-users@bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users From minc-users@bic.mni.mcgill.ca Mon Jul 4 14:43:04 2005 From: minc-users@bic.mni.mcgill.ca (minc-users@bic.mni.mcgill.ca) Date: Mon Jul 4 13:43:04 2005 Subject: [MINC-users] mincresample and weird intensities In-Reply-To: <200507011601.j61G187X13952772@shadow.bic.mni.mcgill.ca> Message-ID: Hi Andrew, I have been using mincresample to change image resolutions as well. I have found that you often need to specify the # of elements (-nelements) and origin (-start) as well. Otherwise the resampled image may have an unusual size and location (i.e. one that exists in empty space and displaced from the object you would like to view). Perhaps this is what is producing your error. Good luck, Ernest Lo NeuroRX Research Montreal, Canada > Message: 3 > Date: Fri, 1 Jul 2005 11:51:40 -0400 > From: Andrew Liu > Reply-To: Andrew Liu > To: minc-users@bic.mni.mcgill.ca > Subject: [MINC-users] mincresample and weird intensities > > Hi > > I have an image volume that I wish to resample to .8 mm cubic voxels > from 1.2x0.9375x0.9375 mm voxels, but when I run > > mincresample -step .8 .8 .8 in.mnc out.mnc > > I get a volume where the colorbar in display gives me a range from 0 > to 1.17549e-36, and the volume doesn't seem to contain any information > (all zeros). > > I can view the original image in display with no problems. What's > going on here and how do I go about fixing it? > > Thanks for your help! > > > > --__--__-- > > _______________________________________________ > MINC-users mailing list > MINC-users@bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users > > > End of MINC-users Digest > From minc-users@bic.mni.mcgill.ca Wed Jul 6 11:45:04 2005 From: minc-users@bic.mni.mcgill.ca (minc-users@bic.mni.mcgill.ca) Date: Wed Jul 6 10:45:04 2005 Subject: [MINC-users] nu_correct error In-Reply-To: <200507051601.j65G197X14334027@shadow.bic.mni.mcgill.ca> Message-ID: Hello, I have encountered the following error while running nu_correct: inputCompactField(): Incorrect number of coefficients Failure reading field file: XXXXXXXXXXXXXXXXXXXXXX.imp nu_evaluate: crashed while running evaluate_field (termination status=256) nu_correct: crashed while running nu_evaluate (termination status=256) nu_correct failed on XXXXXXXXXXXXXXXXXXXX.mnc.gz Examination of the .imp file shows that it has 90 lines instead of the usual 110 lines. Therefore it may be that nu_evaluate expects a greater number of field coefficients. As a test I manually add 20 coefficients to the .imp file and then nu_evaluate works fine. What could be causing this error in the automated processing? Does nu_evaluate expect a different number of field coefficients than is provided by nu_estimate? nu_correct has worked fine on our other scans so this seems to be an uncommon type of failure. PS it would be very enlightening also to know what the parameters, matrix, and coefficients in the .imp file mean. Somehow they must represent the non-uniformity field - but what would the mathematical formulation be? Thanks in advance, Ernest Lo NeuroRX Research Montreal, Canada From Andrew Janke Wed Jul 6 23:22:05 2005 From: Andrew Janke (Andrew Janke) Date: Wed Jul 6 22:22:05 2005 Subject: [MINC-users] nu_correct error In-Reply-To: References: <200507051601.j65G197X14334027@shadow.bic.mni.mcgill.ca> Message-ID: Ernest, What version of N3 are you running? There have been a few "issues" with some previous versions.... The current version is 1.10 and can be found here: http://packages.bic.mni.mcgill.ca/tgz/ As for documentation on the field format, you have me there. The only one that could comment on this would be John Sled I guess. (the authour). In the meantime the best way would be to look at the code of evaluate_field. It takes a field file (.imp) and can turn it into a MINC file. Andrew On 06/07/05, elo@neurorx.com wrote: > Hello, > > I have encountered the following error while running nu_correct: > > inputCompactField(): Incorrect number of coefficients > Failure reading field file: > XXXXXXXXXXXXXXXXXXX.imp > nu_evaluate: crashed while running evaluate_field (termination status=256) > nu_correct: crashed while running nu_evaluate (termination status=256) > nu_correct failed on XXXXXXXXXXXXXXXXXX.mnc.gz > > Examination of the .imp file shows that it has 90 lines instead of the > usual 110 lines. Therefore it may be that nu_evaluate expects a greater > number of field coefficients. As a test I manually add 20 coefficients to > the .imp file and then nu_evaluate works fine. > > What could be causing this error in the automated processing? Does > nu_evaluate expect a different number of field coefficients than is > provided by nu_estimate? nu_correct has worked fine on our other scans > so this seems to be an uncommon type of failure. > > PS it would be very enlightening also to know what the parameters, matrix, > and coefficients in the .imp file mean. Somehow they must represent the > non-uniformity field - but what would the mathematical formulation be? > > Thanks in advance, > > Ernest Lo > NeuroRX Research > Montreal, Canada > > _______________________________________________ > MINC-users@bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users > -- Andrew Janke (a.janke@gmail.com || www.cmr.uq.edu.au/~rotor) Canada->Montreal Cell: +1 (514) 924 2012 From Mark Pinsk Mon Jul 11 21:39:04 2005 From: Mark Pinsk (Mark Pinsk) Date: Mon Jul 11 20:39:04 2005 Subject: [MINC-users] n3 1.10 error os x Message-ID: Hi, I just installed the latest minc-1.4 and n3-1.10 packages for os x onto my ibook running Tiger (OS X 10.4). I set my path to include /usr/local/mni/bin. All of the minc tools seem to working, but I get this error message when I type 'nu_correct': Can't locate MNI/Startup.pm in @INC (@INC contains: /sw/lib/perl5 /sw/lib/perl5/darwin /System/Library/Perl/5.8.6/darwin-thread-multi-2level /System/Library/Perl/5.8.6 /Library/Perl/5.8.6/darwin-thread-multi-2level /Library/Perl/5.8.6 /Library/Perl /Network/Library/Perl/5.8.6/darwin-thread-multi-2level /Network/Library/Perl/5.8.6 /Network/Library/Perl /System/Library/Perl/Extras/5.8.6/darwin-thread-multi-2level /System/Library/Perl/Extras/5.8.6 /Library/Perl/5.8.1 .) at /usr/local/mni/bin/nu_correct line 37. BEGIN failed--compilation aborted at /usr/local/mni/bin/nu_correct line 37. Any idea what's wrong? Thanks Mark From minc-users@bic.mni.mcgill.ca Tue Jul 12 09:34:03 2005 From: minc-users@bic.mni.mcgill.ca (Robert VINCENT) Date: Tue Jul 12 08:34:03 2005 Subject: [MINC-users] n3 1.10 error os x In-Reply-To: Message-ID: Hi Mark, You probably did not install the MNI perl libraries, which are required by N3. You can get them here: http://packages.bic.mni.mcgill.ca/tgz/mni_perllib-0.07.tar.gz Hope this solves the problem, -bert On Sun, 10 Jul 2005, Mark Pinsk wrote: > Hi, > I just installed the latest minc-1.4 and n3-1.10 packages for os x > onto my ibook running Tiger (OS X 10.4). I set my path to include > /usr/local/mni/bin. > > All of the minc tools seem to working, but I get this error message > when I type 'nu_correct': > > Can't locate MNI/Startup.pm in @INC (@INC contains: /sw/lib/perl5 > /sw/lib/perl5/darwin > /System/Library/Perl/5.8.6/darwin-thread-multi-2level > /System/Library/Perl/5.8.6 > /Library/Perl/5.8.6/darwin-thread-multi-2level /Library/Perl/5.8.6 > /Library/Perl /Network/Library/Perl/5.8.6/darwin-thread-multi-2level > /Network/Library/Perl/5.8.6 /Network/Library/Perl > /System/Library/Perl/Extras/5.8.6/darwin-thread-multi-2level > /System/Library/Perl/Extras/5.8.6 /Library/Perl/5.8.1 .) at > /usr/local/mni/bin/nu_correct line 37. > BEGIN failed--compilation aborted at /usr/local/mni/bin/nu_correct line 37. > > Any idea what's wrong? > Thanks > Mark > > _______________________________________________ > MINC-users@bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users > From minc-users@bic.mni.mcgill.ca Tue Jul 12 09:42:04 2005 From: minc-users@bic.mni.mcgill.ca (Jason Lerch) Date: Tue Jul 12 08:42:04 2005 Subject: [MINC-users] n3 1.10 error os x In-Reply-To: References: Message-ID: If you installed the .dmg package then the perl libraries have been installed - you just need to set one environment variable: setenv PERL5LIB /usr/local/mni/lib/Library/Perl/5.8.1 (See /usr/local/mni/ReadMe.rtf). Jason On Jul 12, 2005, at 8:33 AM, Robert VINCENT wrote: > Hi Mark, > > You probably did not install the MNI perl libraries, which are > required by > N3. > > You can get them here: > > http://packages.bic.mni.mcgill.ca/tgz/mni_perllib-0.07.tar.gz > > Hope this solves the problem, > > -bert > > On Sun, 10 Jul 2005, Mark Pinsk wrote: > >> Hi, >> I just installed the latest minc-1.4 and n3-1.10 packages for os x >> onto my ibook running Tiger (OS X 10.4). I set my path to include >> /usr/local/mni/bin. >> >> All of the minc tools seem to working, but I get this error message >> when I type 'nu_correct': >> >> Can't locate MNI/Startup.pm in @INC (@INC contains: /sw/lib/perl5 >> /sw/lib/perl5/darwin >> /System/Library/Perl/5.8.6/darwin-thread-multi-2level >> /System/Library/Perl/5.8.6 >> /Library/Perl/5.8.6/darwin-thread-multi-2level /Library/Perl/5.8.6 >> /Library/Perl /Network/Library/Perl/5.8.6/darwin-thread-multi-2level >> /Network/Library/Perl/5.8.6 /Network/Library/Perl >> /System/Library/Perl/Extras/5.8.6/darwin-thread-multi-2level >> /System/Library/Perl/Extras/5.8.6 /Library/Perl/5.8.1 .) at >> /usr/local/mni/bin/nu_correct line 37. >> BEGIN failed--compilation aborted at /usr/local/mni/bin/nu_correct >> line 37. >> >> Any idea what's wrong? >> Thanks >> Mark >> >> _______________________________________________ >> MINC-users@bic.mni.mcgill.ca >> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users >> > > _______________________________________________ > MINC-users@bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users From minc-users@bic.mni.mcgill.ca Tue Jul 12 16:27:04 2005 From: minc-users@bic.mni.mcgill.ca (Morgan Hough) Date: Tue Jul 12 15:27:04 2005 Subject: [MINC-users] Register-1.3.5 on Mac OS X 10.4.1 Message-ID: <1121196224.32050.4.camel@dhania.fmrib.ox.ac.uk> I was hoping to ask another Mac OS X question. ./configure fails with Register claiming it can't find GL/gl.h. Do you have to pass ./configure a GL path on Mac OS X? I have it in /usr/X11R6/include/GL/gl.h. Isn't that a normal place for it to be? Thanks in advance. Cheers, -Morgan -- Morgan Hough DPhil student FMRIB, John Radcliffe Hospital, Headington, Oxford OX3 9DU, UK mhough@fmrib.ox.ac.uk www.fmrib.ox.ac.uk/~mhough tel +44 (0) 1865 222545 fax +44 (0) 1865 222717 From minc-users@bic.mni.mcgill.ca Tue Jul 12 16:39:04 2005 From: minc-users@bic.mni.mcgill.ca (Alexandre CARMEL-VEILLEUX) Date: Tue Jul 12 15:39:04 2005 Subject: [MINC-users] Register-1.3.5 on Mac OS X 10.4.1 In-Reply-To: <1121196224.32050.4.camel@dhania.fmrib.ox.ac.uk>; from mhough@fmrib.ox.ac.uk on Tue, Jul 12, 2005 at 08:23:44PM +0100 References: <1121196224.32050.4.camel@dhania.fmrib.ox.ac.uk> Message-ID: <20050712153826.B1493@mrs.mni.mcgill.ca> On Tue, Jul 12, 2005 at 08:23:44PM +0100, Morgan Hough wrote: > > I was hoping to ask another Mac OS X question. ./configure fails with > Register claiming it can't find GL/gl.h. Do you have to pass ./configure > a GL path on Mac OS X? I have it in /usr/X11R6/include/GL/gl.h. Isn't > that a normal place for it to be? Thanks in advance. Try setting adding "-I/usr/X11R6/include" to the CFLAGS environment variable. Also set the corresponding bin dir in the LDFLAGS variable: setenv CFLAGS "$CFLAGS -I/usr/X11R6/include" setenv LDFLAGS "$LDFLAGS -L/usr/X11R6/lib" I hope that helps. Alex From minc-users@bic.mni.mcgill.ca Tue Jul 12 16:46:04 2005 From: minc-users@bic.mni.mcgill.ca (Sean McBride) Date: Tue Jul 12 15:46:04 2005 Subject: [MINC-users] Register-1.3.5 on Mac OS X 10.4.1 In-Reply-To: <1121196224.32050.4.camel@dhania.fmrib.ox.ac.uk> References: <1121196224.32050.4.camel@dhania.fmrib.ox.ac.uk> Message-ID: <20050712194518.11172@smtp10.qc.aibn.com> On 2005-07-12 20:23, Morgan Hough said: >I was hoping to ask another Mac OS X question. ./configure fails with >Register claiming it can't find GL/gl.h. Do you have to pass ./configure >a GL path on Mac OS X? I have it in /usr/X11R6/include/GL/gl.h. Isn't >that a normal place for it to be? Thanks in advance. I don't use/know-anything-about X11, but gl.h is also found here: /System/Library/Frameworks/OpenGL.framework/Versions/A/Headers/gl.h Maybe that's where minc looks by default? Do you have Xcode installed? -- ____________________________________________________________ Sean McBride, B. Eng sean@rogue-research.com Rogue Research www.rogue-research.com Mac Software Developer Montréal, Québec, Canada From Andrew Janke Tue Jul 12 16:52:04 2005 From: Andrew Janke (Andrew Janke) Date: Tue Jul 12 15:52:04 2005 Subject: [MINC-users] Register-1.3.5 on Mac OS X 10.4.1 In-Reply-To: <20050712194518.11172@smtp10.qc.aibn.com> References: <1121196224.32050.4.camel@dhania.fmrib.ox.ac.uk> <20050712194518.11172@smtp10.qc.aibn.com> Message-ID: First, get register 1.3.6 from packages.bic.mni.mcgill.ca/tgz There is some code added into the configure script to handle this. When you configure add: --with-apple-opengl-framework to the configure line. This will then link against the Apple OSX Gl libraries resulting in much faster code (and less bugs) than using a fink/darwinports/etc equivalent. Either that or go the easy way and use the binary OSX MINC packages here: packages.bic.mni.mcgill.ca/osx -- Andrew Janke (a.janke@gmail.com || www.cmr.uq.edu.au/~rotor) Canada->Montreal Cell: +1 (514) 924 2012 From minc-users@bic.mni.mcgill.ca Tue Jul 12 18:38:03 2005 From: minc-users@bic.mni.mcgill.ca (Mark Pinsk) Date: Tue Jul 12 17:38:03 2005 Subject: [MINC-users] n3 1.10 error os x In-Reply-To: References: Message-ID: <515C1B73-461C-49DF-99DD-157590101CE8@gmail.com> --Apple-Mail-4--984322068 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Thanks everyone for the prompt response. I'm using the latest Freesurfer OSX distribution which includes select MNI tools in its installation, but it seemed to be missing both the mni_perllib and getopt-tabular which were needed for N3 to run. all is good now, mark On Jul 12, 2005, at 8:41 AM, Jason Lerch wrote: > If you installed the .dmg package then the perl libraries have been > installed - you just need to set one environment variable: > > setenv PERL5LIB /usr/local/mni/lib/Library/Perl/5.8.1 > > (See /usr/local/mni/ReadMe.rtf). > > Jason > > On Jul 12, 2005, at 8:33 AM, Robert VINCENT wrote: > > >> Hi Mark, >> >> You probably did not install the MNI perl libraries, which are >> required by >> N3. >> >> You can get them here: >> >> http://packages.bic.mni.mcgill.ca/tgz/mni_perllib-0.07.tar.gz >> >> Hope this solves the problem, >> >> -bert >> >> On Sun, 10 Jul 2005, Mark Pinsk wrote: >> >> >>> Hi, >>> I just installed the latest minc-1.4 and n3-1.10 packages for os x >>> onto my ibook running Tiger (OS X 10.4). I set my path to include >>> /usr/local/mni/bin. >>> >>> All of the minc tools seem to working, but I get this error message >>> when I type 'nu_correct': >>> >>> Can't locate MNI/Startup.pm in @INC (@INC contains: /sw/lib/perl5 >>> /sw/lib/perl5/darwin >>> /System/Library/Perl/5.8.6/darwin-thread-multi-2level >>> /System/Library/Perl/5.8.6 >>> /Library/Perl/5.8.6/darwin-thread-multi-2level /Library/Perl/5.8.6 >>> /Library/Perl /Network/Library/Perl/5.8.6/darwin-thread-multi-2level >>> /Network/Library/Perl/5.8.6 /Network/Library/Perl >>> /System/Library/Perl/Extras/5.8.6/darwin-thread-multi-2level >>> /System/Library/Perl/Extras/5.8.6 /Library/Perl/5.8.1 .) at >>> /usr/local/mni/bin/nu_correct line 37. >>> BEGIN failed--compilation aborted at /usr/local/mni/bin/ >>> nu_correct line 37. >>> >>> Any idea what's wrong? >>> Thanks >>> Mark >>> >>> _______________________________________________ >>> MINC-users@bic.mni.mcgill.ca >>> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users >>> >>> >> >> _______________________________________________ >> MINC-users@bic.mni.mcgill.ca >> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users >> > > > Mark A. Pinsk, Ph.D. Green 3-C-5, Dept. of Psychology Princeton U., Princeton NJ 08544 (609) 258-8318 mpinsk@princeton.edu www.princeton.edu/~mpinsk/ --Apple-Mail-4--984322068 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1
Thanks everyone for the = prompt response.

I'm using the = latest Freesurfer OSX distribution which includes select MNI tools in = its installation, but it seemed to be missing
both the mni_perllib and getopt-tabular which were = needed for N3 to run.

all is good now,

On Jul 12, 2005, = at 8:41 AM, Jason Lerch wrote:

If you installed the .dmg package then the perl = libraries have been installed - you just need to set one environment = variable:

setenv PERL5LIB = /usr/local/mni/lib/Library/Perl/5.8.1

(See = /usr/local/mni/ReadMe.rtf).

Jason

On Jul = 12, 2005, at 8:33 AM, Robert VINCENT wrote:


Hi Mark,

You probably did not install the = MNI perl libraries, which are required by

You can get them here:


Hope = this solves the problem,

=A0 = =A0 -bert

On Sun, 10 Jul 2005, Mark Pinsk = wrote:

=
Hi,
I just installed the latest minc-1.4 and n3-1.10 = packages for os x
onto my ibook running Tiger (OS = X 10.4).=A0 I set my path = to include
/usr/local/mni/bin.

All of = the minc tools seem to working, but I get this error message
when I type 'nu_correct':

Can't = locate MNI/Startup.pm in @INC (@INC contains: /sw/lib/perl5
/sw/lib/perl5/darwin
/System/Library/Perl/5.8.6
/Library/Perl/5.8.6/darwin-thread-multi-2level = /Library/Perl/5.8.6
/Library/Perl = /Network/Library/Perl/5.8.6/darwin-thread-multi-2level
/Network/Library/Perl/5.8.6 = /Network/Library/Perl
/System/Library/Perl/Extras/5.8.6 = /Library/Perl/5.8.1 .) at
BEGIN = failed--compilation aborted at /usr/local/mni/bin/nu_correct line = 37.

Any idea what's wrong?
Mark




=




=
Mark A. Pinsk, Ph.D.
Green 3-C-5, Dept. of = Psychology
Princeton U., Princeton NJ 08544
(609) = 258-8318
www.princeton.edu/~mpinsk/<= /DIV>

=

= --Apple-Mail-4--984322068-- From minc-users@bic.mni.mcgill.ca Thu Jul 14 13:17:04 2005 From: minc-users@bic.mni.mcgill.ca (minc-users@bic.mni.mcgill.ca) Date: Thu Jul 14 12:17:04 2005 Subject: [MINC-users] nu_correct error In-Reply-To: <200507071601.j67G197X14093215@shadow.bic.mni.mcgill.ca> Message-ID: Hi Andrew, We have found an empirical 'fix' to the nu_correct issue (in case you might be interested). The nu_correct runs OK on our problem cases if we tweak the sampling parameter (set -shrink 4.0001). We also found that cropping the images (mincreshape) to zspace=0,192 resulted in nu_correct working. As for version bugs, the nu_correct worked on all of our non-linux systems (results listed below). Therefore the source of the issue might be numerical/computational. Anyway, thanks very much for your feedback. Ernest Lo NeuroRX Research Montreal, Canada Fails: N3-1.04 on Linux x86 N3-1.09 on Linux x86 N3-1.10 on Linux x86 Succeeds: N3-1.09 on SGI N3-1.05 on Mac OS X 10.3.9 > --__--__-- > > Message: 1 > Date: Wed, 6 Jul 2005 22:21:20 -0400 > From: Andrew Janke > Reply-To: Andrew Janke > To: minc-users@bic.mni.mcgill.ca > Subject: Re: [MINC-users] nu_correct error > > Ernest, > > What version of N3 are you running? There have been a few "issues" > with some previous versions.... The current version is 1.10 and can > be found here: > > http://packages.bic.mni.mcgill.ca/tgz/ > > As for documentation on the field format, you have me there. The only > one that could comment on this would be John Sled I guess. (the > authour). In the meantime the best way would be to look at the code > of evaluate_field. It takes a field file (.imp) and can turn it into > a MINC file. > > Andrew > > > On 06/07/05, elo@neurorx.com wrote: > > Hello, > > > > I have encountered the following error while running nu_correct: > > > > inputCompactField(): Incorrect number of coefficients > > Failure reading field file: > > XXXXXXXXX.imp > > nu_evaluate: crashed while running evaluate_field (termination status=256) > > nu_correct: crashed while running nu_evaluate (termination status=256) > > nu_correct failed on XXXXXXXX.mnc.gz > > > > Examination of the .imp file shows that it has 90 lines instead of the > > usual 110 lines. Therefore it may be that nu_evaluate expects a greater > > number of field coefficients. As a test I manually add 20 coefficients to > > the .imp file and then nu_evaluate works fine. > > > > What could be causing this error in the automated processing? Does > > nu_evaluate expect a different number of field coefficients than is > > provided by nu_estimate? nu_correct has worked fine on our other scans > > so this seems to be an uncommon type of failure. > > > > PS it would be very enlightening also to know what the parameters, matrix, > > and coefficients in the .imp file mean. Somehow they must represent the > > non-uniformity field - but what would the mathematical formulation be? > > > > Thanks in advance, > > > > Ernest Lo > > NeuroRX Research > > Montreal, Canada From minc-users@bic.mni.mcgill.ca Wed Jul 20 18:05:03 2005 From: minc-users@bic.mni.mcgill.ca (Alex ZIJDENBOS) Date: Wed Jul 20 17:05:03 2005 Subject: [MINC-users] mincstats -mask Message-ID: <20050720210418.GA16384527@bic.mni.mcgill.ca> A kind soul just alerted me to something possibly confusing with mincstats, being that it will (silently) ignore a -mask argument if not given at least one of -mask_{floor,ceil,range,binvalue}. In other words, the call mincstats -mask -floor does nothing with . Although this is stated in the man page, I suspect it is counterintuitive to many people; it seems to me mincstats should either do something sensible with the mask (i.e., default to '-mask_binvalue 1'), or barf when given a mask argument which is not used. I have a vague recollection of this being discussed before, but has it been fixed in recent releases of minc? -- A From minc-users@bic.mni.mcgill.ca Wed Jul 20 18:31:05 2005 From: minc-users@bic.mni.mcgill.ca (Robert VINCENT) Date: Wed Jul 20 17:31:05 2005 Subject: [MINC-users] mincstats -mask In-Reply-To: <20050720210418.GA16384527@bic.mni.mcgill.ca> Message-ID: Hi Alex, This appears to be unchanged. I hadn't been aware of the problem. I think adding some kind of default behavior such as -mask_binvalue 1 would not break anything. But I'm curious to hear other's opinions. -bert On Wed, 20 Jul 2005, Alex ZIJDENBOS wrote: > A kind soul just alerted me to something possibly confusing with > mincstats, being that it will (silently) ignore a -mask argument if > not given at least one of -mask_{floor,ceil,range,binvalue}. > > In other words, the call > > mincstats -mask -floor > > does nothing with . Although this is stated in the man page, > I suspect it is counterintuitive to many people; it seems to me > mincstats should either do something sensible with the mask (i.e., > default to '-mask_binvalue 1'), or barf when given a mask argument > which is not used. > > I have a vague recollection of this being discussed before, but has it > been fixed in recent releases of minc? > > -- A > _______________________________________________ > MINC-users@bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users > From Andrew Janke Wed Jul 20 18:35:04 2005 From: Andrew Janke (Andrew Janke) Date: Wed Jul 20 17:35:04 2005 Subject: [MINC-users] mincstats -mask In-Reply-To: References: <20050720210418.GA16384527@bic.mni.mcgill.ca> Message-ID: Sounds fair to me. Peter and I discussed this at length when we first wrote the thing but never managed to come to agreement. What has just been suggested is what I was hammering for... :) a On 20/07/05, Robert VINCENT wrote: > Hi Alex, > > This appears to be unchanged. I hadn't been aware of the problem. > > I think adding some kind of default behavior such as -mask_binvalue 1 > would not break anything. But I'm curious to hear other's opinions. > > -bert > > > On Wed, 20 Jul 2005, Alex ZIJDENBOS wrote: > > > A kind soul just alerted me to something possibly confusing with > > mincstats, being that it will (silently) ignore a -mask argument if > > not given at least one of -mask_{floor,ceil,range,binvalue}. > > > > In other words, the call > > > > mincstats -mask -floor > > > > does nothing with . Although this is stated in the man page, > > I suspect it is counterintuitive to many people; it seems to me > > mincstats should either do something sensible with the mask (i.e., > > default to '-mask_binvalue 1'), or barf when given a mask argument > > which is not used. > > > > I have a vague recollection of this being discussed before, but has it > > been fixed in recent releases of minc? > > > > -- A > > _______________________________________________ > > MINC-users@bic.mni.mcgill.ca > > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users > > > > _______________________________________________ > MINC-users@bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users > -- Andrew Janke (a.janke@gmail.com || www.cmr.uq.edu.au/~rotor) Canada->Montreal Cell: +1 (514) 924 2012 From minc-users@bic.mni.mcgill.ca Wed Jul 20 21:24:05 2005 From: minc-users@bic.mni.mcgill.ca (Dylan David Wagner) Date: Wed Jul 20 20:24:05 2005 Subject: [MINC-users] Very large dicom variables in the header crashing loni debabelizer. In-Reply-To: <20050720210418.GA16384527@bic.mni.mcgill.ca> References: <20050720210418.GA16384527@bic.mni.mcgill.ca> Message-ID: <42DEEB03.2030907@bic.mni.mcgill.ca> Hi, I've been trying to use the loni debabelizer to convert some minc files to nifti and/or analyze (couldn't find an in house converter for nifti, do we have one?). I've been finding that certain files crash it, other files aren't identified as MINC and a third group actually work! The reason why some files crash the babelizer, or aren't identified, seems to have to do with long headers caused by some of the dicom variables in the minc header. At least that's the only difference I can discern. Older mincfiles scanned before the Siemens got an upgrade are identified without fail. Aside from a few additional entries in the study variable, the main differences is the dicom variables are huge and the mincheader jumps from ~20kb to 700+ Kb. Newer files scanned after the upgrade work if they've been preprocessed with the fmri preprocessing tools (which seems to eliminate the dicom entries from the header). Oddly enough if I use cygwin to do the preprocessing with the same minctools, the dicom entries in the header are preserved (and loni debabelizer crashes). I'm guessing the fault lies with the Loni app, however does anyone have any quick fixes to eliminate all the dicom info from the header? I'd still like to keep the rest of the header intact. Thanks, DDW From Andrew Janke Wed Jul 20 22:44:05 2005 From: Andrew Janke (Andrew Janke) Date: Wed Jul 20 21:44:05 2005 Subject: [MINC-users] Very large dicom variables in the header crashing loni debabelizer. In-Reply-To: <42DEEB03.2030907@bic.mni.mcgill.ca> References: <20050720210418.GA16384527@bic.mni.mcgill.ca> <42DEEB03.2030907@bic.mni.mcgill.ca> Message-ID: ------=_Part_2979_277658.1121910147318 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Yes, try the attached script. but use with caution! It modifies the MINC file in place. a On 20/07/05, Dylan David Wagner wrote: > Hi, >=20 > I've been trying to use the loni debabelizer to convert some minc > files to nifti and/or analyze (couldn't find an in house converter for > nifti, do we have one?). I've been finding that certain files crash it, > other files aren't identified as MINC and a third group actually work! >=20 > The reason why some files crash the babelizer, or aren't > identified, seems to have to do with long headers caused by some of the > dicom variables in the minc header. At least that's the only difference > I can discern. >=20 > Older mincfiles scanned before the Siemens got an upgrade are > identified without fail. Aside from a few additional entries in the > study variable, the main differences is the dicom variables are huge and > the mincheader jumps from ~20kb to 700+ Kb. >=20 > Newer files scanned after the upgrade work if they've been > preprocessed with the fmri preprocessing tools (which seems to eliminate > the dicom entries from the header). Oddly enough if I use cygwin to do > the preprocessing with the same minctools, the dicom entries in the > header are preserved (and loni debabelizer crashes). >=20 > I'm guessing the fault lies with the Loni app, however does anyone > have any quick fixes to eliminate all the dicom info from the header? > I'd still like to keep the rest of the header intact. >=20 > Thanks, > DDW > _______________________________________________ > MINC-users@bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users >=20 --=20 Andrew Janke (a.janke@gmail.com || www.cmr.uq.edu.au/~rotor) Canada->Montreal Cell: +1 (514) 924 2012 ------=_Part_2979_277658.1121910147318 Content-Type: application/octet-stream; name="minc_de-dicomerise" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="minc_de-dicomerise" IyEgL3Vzci9iaW4vZW52IHBlcmwKIwojIEFuZHJldyBKYW5rZSAtIHJvdG9yQGNtci51cS5lZHUu YXUKIyBDZW50ZXIgZm9yIE1hZ25ldGljIFJlc29uYW5jZQojIFRoZSBVbml2ZXJzaXR5IG9mIFF1 ZWVuc2xhbmQKIyBodHRwOi8vd3d3LmNtci51cS5lZHUuYXUvfnJvdG9yCiMKIyBVU0UgQVQgT1dO IFJJU0shICBUSElTIE1BWSBNVU5HRSBZT1VSIE1JTkMgRklMRVMgSEVBREVSIQoKdXNlIHdhcm5p bmdzICJhbGwiOwp1c2UgRmlsZTo6QmFzZW5hbWU7CgokbWUgPSAmYmFzZW5hbWUoJDApOwppZigk I0FSR1YgIT0gMCl7CiAgIGRpZSAiXG4rKytXQVJOSU5HOiBUSElTIFNDUklQVCBNQVkgTVVOR0Ug WU9VUiBGSUxFIFBFUk1BTkVOVExZISsrK1xuXG4iLgogICAgICAgIlVzYWdlOiAkbWUgPGZpbGVf dG9fY2xlYW4ubW5jPlxuXG4iOwogICB9CgooQHl1a2t5X3ZhcnMpID0gc3BsaXQoJyAnLCBgbWlu Y2luZm8gLXZhcm5hbWVzICRBUkdWWzBdYCk7Cgpmb3JlYWNoICR2YXIgKGdyZXAgey9kaWNvbS99 IEB5dWtreV92YXJzKXsKICAgZm9yZWFjaCAoc3BsaXQoJyAnLCBgbWluY2luZm8gLXZhcmF0dHMg JHZhciAkQVJHVlswXWApKXsKICAgICAgcHJpbnQgIiB8IFskQVJHVlswXV0gLSByZW1vdmluZyAk dmFyOiRfXG4iOwogICAgICBzeXN0ZW0oJ21pbmNfbW9kaWZ5X2hlYWRlcicsICctZGVsZXRlJywg IiR2YXI6JF8iLCAkQVJHVlswXSkgPT0gMCBvciBkaWU7CiAgICAgIH0KICAgfQo= ------=_Part_2979_277658.1121910147318-- From minc-users@bic.mni.mcgill.ca Wed Jul 20 23:20:03 2005 From: minc-users@bic.mni.mcgill.ca (Alex ZIJDENBOS) Date: Wed Jul 20 22:20:03 2005 Subject: [MINC-users] mincstats -mask In-Reply-To: References: <20050720210418.GA16384527@bic.mni.mcgill.ca> Message-ID: <20050721021949.GB2766@bic.mni.mcgill.ca> Actually, perhaps '-binvalue 1' is a bit too restrictive. I've seen people create masks with values higher than one (e.g., using Display). I think that assuming a "mask" is made up of zero- and non-zero values (with a bit of tolerance perhaps for roundoff) would be reasonable. But if that's not general enough (I suppose that was Peter's argument?), generating an error message when the mask treatment is undefined makes sense too. volume_stats, mincstats predecessor, does the former (without tolerance though). If a mask is present but no extrema are given, it'll test for mask value != 0. -- A On Wed, Jul 20, 2005 at 05:33:38PM -0400, Andrew Janke wrote: > Sounds fair to me. > > Peter and I discussed this at length when we first wrote the thing but > never managed to come to agreement. > > What has just been suggested is what I was hammering for... :) > > > a > > On 20/07/05, Robert VINCENT wrote: > > Hi Alex, > > > > This appears to be unchanged. I hadn't been aware of the problem. > > > > I think adding some kind of default behavior such as -mask_binvalue 1 > > would not break anything. But I'm curious to hear other's opinions. > > > > -bert > > > > > > On Wed, 20 Jul 2005, Alex ZIJDENBOS wrote: > > > > > A kind soul just alerted me to something possibly confusing with > > > mincstats, being that it will (silently) ignore a -mask argument if > > > not given at least one of -mask_{floor,ceil,range,binvalue}. > > > > > > In other words, the call > > > > > > mincstats -mask -floor > > > > > > does nothing with . Although this is stated in the man page, > > > I suspect it is counterintuitive to many people; it seems to me > > > mincstats should either do something sensible with the mask (i.e., > > > default to '-mask_binvalue 1'), or barf when given a mask argument > > > which is not used. > > > > > > I have a vague recollection of this being discussed before, but has it > > > been fixed in recent releases of minc? > > > > > > -- A > > > _______________________________________________ > > > MINC-users@bic.mni.mcgill.ca > > > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users > > > > > > > _______________________________________________ > > MINC-users@bic.mni.mcgill.ca > > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users > > > > > -- > Andrew Janke (a.janke@gmail.com || www.cmr.uq.edu.au/~rotor) > Canada->Montreal Cell: +1 (514) 924 2012 > > _______________________________________________ > MINC-users@bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users From Andrew Janke Wed Jul 20 23:53:03 2005 From: Andrew Janke (Andrew Janke) Date: Wed Jul 20 22:53:03 2005 Subject: [MINC-users] mincstats -mask In-Reply-To: <20050721021949.GB2766@bic.mni.mcgill.ca> References: <20050720210418.GA16384527@bic.mni.mcgill.ca> <20050721021949.GB2766@bic.mni.mcgill.ca> Message-ID: And thus the argument begins again... :) In the end the mutual disagreement from memory was to spit out an error. Of course this will break a number of (possibly previously broken) scripts. Although I suspect Peter might crawl out of hibernation and correct me here. I suggest we take a vote! a On 20/07/05, Alex ZIJDENBOS wrote: > Actually, perhaps '-binvalue 1' is a bit too restrictive. I've seen > people create masks with values higher than one (e.g., using > Display). I think that assuming a "mask" is made up of zero- and > non-zero values (with a bit of tolerance perhaps for roundoff) would > be reasonable. But if that's not general enough (I suppose that was > Peter's argument?), generating an error message when the mask > treatment is undefined makes sense too. > > volume_stats, mincstats predecessor, does the former (without > tolerance though). If a mask is present but no extrema are given, > it'll test for mask value != 0. > > -- A > > On Wed, Jul 20, 2005 at 05:33:38PM -0400, Andrew Janke wrote: > > Sounds fair to me. > > > > Peter and I discussed this at length when we first wrote the thing but > > never managed to come to agreement. > > > > What has just been suggested is what I was hammering for... :) > > > > > > a > > > > On 20/07/05, Robert VINCENT wrote: > > > Hi Alex, > > > > > > This appears to be unchanged. I hadn't been aware of the problem. > > > > > > I think adding some kind of default behavior such as -mask_binvalue 1 > > > would not break anything. But I'm curious to hear other's opinions. > > > > > > -bert > > > > > > > > > On Wed, 20 Jul 2005, Alex ZIJDENBOS wrote: > > > > > > > A kind soul just alerted me to something possibly confusing with > > > > mincstats, being that it will (silently) ignore a -mask argument if > > > > not given at least one of -mask_{floor,ceil,range,binvalue}. > > > > > > > > In other words, the call > > > > > > > > mincstats -mask -floor > > > > > > > > does nothing with . Although this is stated in the man page, > > > > I suspect it is counterintuitive to many people; it seems to me > > > > mincstats should either do something sensible with the mask (i.e., > > > > default to '-mask_binvalue 1'), or barf when given a mask argument > > > > which is not used. > > > > > > > > I have a vague recollection of this being discussed before, but has it > > > > been fixed in recent releases of minc? > > > > > > > > -- A > > > > _______________________________________________ > > > > MINC-users@bic.mni.mcgill.ca > > > > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users > > > > > > > > > > _______________________________________________ > > > MINC-users@bic.mni.mcgill.ca > > > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users > > > > > > > > > -- > > Andrew Janke (a.janke@gmail.com || www.cmr.uq.edu.au/~rotor) > > Canada->Montreal Cell: +1 (514) 924 2012 > > > > _______________________________________________ > > MINC-users@bic.mni.mcgill.ca > > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users > _______________________________________________ > MINC-users@bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users > -- Andrew Janke (a.janke@gmail.com || www.cmr.uq.edu.au/~rotor) Canada->Montreal Cell: +1 (514) 924 2012 From minc-users@bic.mni.mcgill.ca Thu Jul 21 00:03:05 2005 From: minc-users@bic.mni.mcgill.ca (Najmeh Khalili M.) Date: Wed Jul 20 23:03:05 2005 Subject: [MINC-users] mincstats -mask In-Reply-To: <20050721021949.GB2766@bic.mni.mcgill.ca> Message-ID: Just two cents worth of request: If you are going to change anything, please don't forget to write the manual a bit more trivial. For example, I don't understand what -mask_floor ,... is trying to acheive. In fact, I always thought in any data set, there exist only ONE min, but it must be the old school of statistics ;) So I would appreciate some enlightenment on what subsets these several mins belong to! (I can assume they corespond to binvalue ... ... but why should I ASSUME?) Thanks, Najma On Wed, 20 Jul 2005, Alex ZIJDENBOS wrote: > Actually, perhaps '-binvalue 1' is a bit too restrictive. I've seen > people create masks with values higher than one (e.g., using > Display). I think that assuming a "mask" is made up of zero- and > non-zero values (with a bit of tolerance perhaps for roundoff) would > be reasonable. But if that's not general enough (I suppose that was > Peter's argument?), generating an error message when the mask > treatment is undefined makes sense too. > > volume_stats, mincstats predecessor, does the former (without > tolerance though). If a mask is present but no extrema are given, > it'll test for mask value != 0. > > -- A > > On Wed, Jul 20, 2005 at 05:33:38PM -0400, Andrew Janke wrote: > > Sounds fair to me. > > > > Peter and I discussed this at length when we first wrote the thing but > > never managed to come to agreement. > > > > What has just been suggested is what I was hammering for... :) > > > > > > a > > > > On 20/07/05, Robert VINCENT wrote: > > > Hi Alex, > > > > > > This appears to be unchanged. I hadn't been aware of the problem. > > > > > > I think adding some kind of default behavior such as -mask_binvalue 1 > > > would not break anything. But I'm curious to hear other's opinions. > > > > > > -bert > > > > > > > > > On Wed, 20 Jul 2005, Alex ZIJDENBOS wrote: > > > > > > > A kind soul just alerted me to something possibly confusing with > > > > mincstats, being that it will (silently) ignore a -mask argument if > > > > not given at least one of -mask_{floor,ceil,range,binvalue}. > > > > > > > > In other words, the call > > > > > > > > mincstats -mask -floor > > > > > > > > does nothing with . Although this is stated in the man page, > > > > I suspect it is counterintuitive to many people; it seems to me > > > > mincstats should either do something sensible with the mask (i.e., > > > > default to '-mask_binvalue 1'), or barf when given a mask argument > > > > which is not used. > > > > > > > > I have a vague recollection of this being discussed before, but has it > > > > been fixed in recent releases of minc? > > > > > > > > -- A > > > > _______________________________________________ > > > > MINC-users@bic.mni.mcgill.ca > > > > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users > > > > > > > > > > _______________________________________________ > > > MINC-users@bic.mni.mcgill.ca > > > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users > > > > > > > > > -- > > Andrew Janke (a.janke@gmail.com || www.cmr.uq.edu.au/~rotor) > > Canada->Montreal Cell: +1 (514) 924 2012 > > > > _______________________________________________ > > MINC-users@bic.mni.mcgill.ca > > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users > _______________________________________________ > MINC-users@bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users > From minc-users@bic.mni.mcgill.ca Thu Jul 21 07:52:04 2005 From: minc-users@bic.mni.mcgill.ca (Jonathan HARLAP) Date: Thu Jul 21 06:52:04 2005 Subject: [MINC-users] mincstats -mask In-Reply-To: References: <20050720210418.GA16384527@bic.mni.mcgill.ca> <20050721021949.GB2766@bic.mni.mcgill.ca> Message-ID: <20050721105150.GA15765883@bic.mni.mcgill.ca> On Wed, Jul 20, 2005 at 10:51:28PM -0400, Andrew Janke wrote: > And thus the argument begins again... :) you knew that the original simple solution was too good to be true, didn't you? ;P if it helps find consistency within minc, there is an analogous situation in mincmath in which the -segment option will use the range specified by -const2, and leaving out the -const2 results in an error message - "Operation and constants do not match". thus it sounds like the error message solution would be consistent. now i've opened it up for "well, uses a default instead of complaining..." ;) > In the end the mutual disagreement from memory was to spit out an > error. Of course this will break a number of (possibly previously > broken) scripts. > > Although I suspect Peter might crawl out of hibernation and correct me here. > > I suggest we take a vote! > > > a > > On 20/07/05, Alex ZIJDENBOS wrote: > > Actually, perhaps '-binvalue 1' is a bit too restrictive. I've seen > > people create masks with values higher than one (e.g., using > > Display). I think that assuming a "mask" is made up of zero- and > > non-zero values (with a bit of tolerance perhaps for roundoff) would > > be reasonable. But if that's not general enough (I suppose that was > > Peter's argument?), generating an error message when the mask > > treatment is undefined makes sense too. > > > > volume_stats, mincstats predecessor, does the former (without > > tolerance though). If a mask is present but no extrema are given, > > it'll test for mask value != 0. > > > > -- A > > > > On Wed, Jul 20, 2005 at 05:33:38PM -0400, Andrew Janke wrote: > > > Sounds fair to me. > > > > > > Peter and I discussed this at length when we first wrote the thing but > > > never managed to come to agreement. > > > > > > What has just been suggested is what I was hammering for... :) > > > > > > > > > a > > > > > > On 20/07/05, Robert VINCENT wrote: > > > > Hi Alex, > > > > > > > > This appears to be unchanged. I hadn't been aware of the problem. > > > > > > > > I think adding some kind of default behavior such as -mask_binvalue 1 > > > > would not break anything. But I'm curious to hear other's opinions. > > > > > > > > -bert > > > > > > > > > > > > On Wed, 20 Jul 2005, Alex ZIJDENBOS wrote: > > > > > > > > > A kind soul just alerted me to something possibly confusing with > > > > > mincstats, being that it will (silently) ignore a -mask argument if > > > > > not given at least one of -mask_{floor,ceil,range,binvalue}. > > > > > > > > > > In other words, the call > > > > > > > > > > mincstats -mask -floor > > > > > > > > > > does nothing with . Although this is stated in the man page, > > > > > I suspect it is counterintuitive to many people; it seems to me > > > > > mincstats should either do something sensible with the mask (i.e., > > > > > default to '-mask_binvalue 1'), or barf when given a mask argument > > > > > which is not used. > > > > > > > > > > I have a vague recollection of this being discussed before, but has it > > > > > been fixed in recent releases of minc? > > > > > > > > > > -- A > > > > > _______________________________________________ > > > > > MINC-users@bic.mni.mcgill.ca > > > > > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users > > > > > > > > > > > > > _______________________________________________ > > > > MINC-users@bic.mni.mcgill.ca > > > > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users > > > > > > > > > > > > > -- > > > Andrew Janke (a.janke@gmail.com || www.cmr.uq.edu.au/~rotor) > > > Canada->Montreal Cell: +1 (514) 924 2012 > > > > > > _______________________________________________ > > > MINC-users@bic.mni.mcgill.ca > > > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users > > _______________________________________________ > > MINC-users@bic.mni.mcgill.ca > > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users > > > > > -- > Andrew Janke (a.janke@gmail.com || www.cmr.uq.edu.au/~rotor) > Canada->Montreal Cell: +1 (514) 924 2012 > > _______________________________________________ > MINC-users@bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users From minc-users@bic.mni.mcgill.ca Thu Jul 21 09:55:04 2005 From: minc-users@bic.mni.mcgill.ca (Jonathan HARLAP) Date: Thu Jul 21 08:55:04 2005 Subject: [MINC-users] Very large dicom variables in the header crashing loni debabelizer. In-Reply-To: <42DEEB03.2030907@bic.mni.mcgill.ca> References: <20050720210418.GA16384527@bic.mni.mcgill.ca> <42DEEB03.2030907@bic.mni.mcgill.ca> Message-ID: <20050721125449.GA19609@bic.mni.mcgill.ca> There's also a mnc2nii (minc to nifti1), although I don't know much more than that... Bert Vincent (bert@bic...) would be the man to ask about it. Cheers, J On Wed, Jul 20, 2005 at 08:23:31PM -0400, Dylan David Wagner wrote: > Hi, > > I've been trying to use the loni debabelizer to convert some minc > files to nifti and/or analyze (couldn't find an in house converter for > nifti, do we have one?). I've been finding that certain files crash it, > other files aren't identified as MINC and a third group actually work! > > The reason why some files crash the babelizer, or aren't > identified, seems to have to do with long headers caused by some of the > dicom variables in the minc header. At least that's the only difference > I can discern. > > Older mincfiles scanned before the Siemens got an upgrade are > identified without fail. Aside from a few additional entries in the > study variable, the main differences is the dicom variables are huge and > the mincheader jumps from ~20kb to 700+ Kb. > > Newer files scanned after the upgrade work if they've been > preprocessed with the fmri preprocessing tools (which seems to eliminate > the dicom entries from the header). Oddly enough if I use cygwin to do > the preprocessing with the same minctools, the dicom entries in the > header are preserved (and loni debabelizer crashes). > > I'm guessing the fault lies with the Loni app, however does anyone > have any quick fixes to eliminate all the dicom info from the header? > I'd still like to keep the rest of the header intact. > > Thanks, > DDW > _______________________________________________ > MINC-users@bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users From minc-users@bic.mni.mcgill.ca Thu Jul 21 11:58:04 2005 From: minc-users@bic.mni.mcgill.ca (Robert VINCENT) Date: Thu Jul 21 10:58:04 2005 Subject: [MINC-users] mincstats -mask In-Reply-To: <20050721105150.GA15765883@bic.mni.mcgill.ca> Message-ID: Hi All, Considering the feedback so far, my thought would be to leave the behavior of the program "as is", except to add a warning message along the following lines: "Warning: mask file specified without a mask range. Mask will be ignored." This should not break existing behavior, while providing some guidance to the uninitiated... -bert On Thu, 21 Jul 2005, Jonathan HARLAP wrote: > On Wed, Jul 20, 2005 at 10:51:28PM -0400, Andrew Janke wrote: > > And thus the argument begins again... :) > > you knew that the original simple solution was too good to be true, > didn't you? ;P > > if it helps find consistency within minc, there is an analogous > situation in mincmath in which the -segment option will use the range > specified by -const2, and leaving out the -const2 results in an error > message - "Operation and constants do not match". > > thus it sounds like the error message solution would be consistent. > > now i've opened it up for "well, uses a default instead > of complaining..." ;) > > > In the end the mutual disagreement from memory was to spit out an > > error. Of course this will break a number of (possibly previously > > broken) scripts. > > > > Although I suspect Peter might crawl out of hibernation and correct me here. > > > > I suggest we take a vote! > > > > > > a > > > > On 20/07/05, Alex ZIJDENBOS wrote: > > > Actually, perhaps '-binvalue 1' is a bit too restrictive. I've seen > > > people create masks with values higher than one (e.g., using > > > Display). I think that assuming a "mask" is made up of zero- and > > > non-zero values (with a bit of tolerance perhaps for roundoff) would > > > be reasonable. But if that's not general enough (I suppose that was > > > Peter's argument?), generating an error message when the mask > > > treatment is undefined makes sense too. > > > > > > volume_stats, mincstats predecessor, does the former (without > > > tolerance though). If a mask is present but no extrema are given, > > > it'll test for mask value != 0. > > > > > > -- A > > > > > > On Wed, Jul 20, 2005 at 05:33:38PM -0400, Andrew Janke wrote: > > > > Sounds fair to me. > > > > > > > > Peter and I discussed this at length when we first wrote the thing but > > > > never managed to come to agreement. > > > > > > > > What has just been suggested is what I was hammering for... :) > > > > > > > > > > > > a > > > > > > > > On 20/07/05, Robert VINCENT wrote: > > > > > Hi Alex, > > > > > > > > > > This appears to be unchanged. I hadn't been aware of the problem. > > > > > > > > > > I think adding some kind of default behavior such as -mask_binvalue 1 > > > > > would not break anything. But I'm curious to hear other's opinions. > > > > > > > > > > -bert > > > > > > > > > > > > > > > On Wed, 20 Jul 2005, Alex ZIJDENBOS wrote: > > > > > > > > > > > A kind soul just alerted me to something possibly confusing with > > > > > > mincstats, being that it will (silently) ignore a -mask argument if > > > > > > not given at least one of -mask_{floor,ceil,range,binvalue}. > > > > > > > > > > > > In other words, the call > > > > > > > > > > > > mincstats -mask -floor > > > > > > > > > > > > does nothing with . Although this is stated in the man page, > > > > > > I suspect it is counterintuitive to many people; it seems to me > > > > > > mincstats should either do something sensible with the mask (i.e., > > > > > > default to '-mask_binvalue 1'), or barf when given a mask argument > > > > > > which is not used. > > > > > > > > > > > > I have a vague recollection of this being discussed before, but has it > > > > > > been fixed in recent releases of minc? > > > > > > > > > > > > -- A > > > > > > _______________________________________________ > > > > > > MINC-users@bic.mni.mcgill.ca > > > > > > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users > > > > > > > > > > > > > > > > _______________________________________________ > > > > > MINC-users@bic.mni.mcgill.ca > > > > > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users > > > > > > > > > > > > > > > > > -- > > > > Andrew Janke (a.janke@gmail.com || www.cmr.uq.edu.au/~rotor) > > > > Canada->Montreal Cell: +1 (514) 924 2012 > > > > > > > > _______________________________________________ > > > > MINC-users@bic.mni.mcgill.ca > > > > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users > > > _______________________________________________ > > > MINC-users@bic.mni.mcgill.ca > > > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users > > > > > > > > > -- > > Andrew Janke (a.janke@gmail.com || www.cmr.uq.edu.au/~rotor) > > Canada->Montreal Cell: +1 (514) 924 2012 > > > > _______________________________________________ > > MINC-users@bic.mni.mcgill.ca > > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users > _______________________________________________ > MINC-users@bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users > From minc-users@bic.mni.mcgill.ca Thu Jul 21 12:14:05 2005 From: minc-users@bic.mni.mcgill.ca (Robert VINCENT) Date: Thu Jul 21 11:14:05 2005 Subject: [MINC-users] Very large dicom variables in the header crashing loni debabelizer. In-Reply-To: <20050721125449.GA19609@bic.mni.mcgill.ca> Message-ID: mnc2nii will convert from MINC to Analyze or NIfTI-1 format. It's part of MINC 1.4 and MINC 2.0.09. It should work with most MINC, even with the overly large DICOM fields. -bert On Thu, 21 Jul 2005, Jonathan HARLAP wrote: > There's also a mnc2nii (minc to nifti1), although I don't know much > more than that... Bert Vincent (bert@bic...) would be the man to ask > about it. > > Cheers, > J > > > On Wed, Jul 20, 2005 at 08:23:31PM -0400, Dylan David Wagner wrote: > > Hi, > > > > I've been trying to use the loni debabelizer to convert some minc > > files to nifti and/or analyze (couldn't find an in house converter for > > nifti, do we have one?). I've been finding that certain files crash it, > > other files aren't identified as MINC and a third group actually work! > > > > The reason why some files crash the babelizer, or aren't > > identified, seems to have to do with long headers caused by some of the > > dicom variables in the minc header. At least that's the only difference > > I can discern. > > > > Older mincfiles scanned before the Siemens got an upgrade are > > identified without fail. Aside from a few additional entries in the > > study variable, the main differences is the dicom variables are huge and > > the mincheader jumps from ~20kb to 700+ Kb. > > > > Newer files scanned after the upgrade work if they've been > > preprocessed with the fmri preprocessing tools (which seems to eliminate > > the dicom entries from the header). Oddly enough if I use cygwin to do > > the preprocessing with the same minctools, the dicom entries in the > > header are preserved (and loni debabelizer crashes). > > > > I'm guessing the fault lies with the Loni app, however does anyone > > have any quick fixes to eliminate all the dicom info from the header? > > I'd still like to keep the rest of the header intact. > > > > Thanks, > > DDW > > _______________________________________________ > > MINC-users@bic.mni.mcgill.ca > > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users > _______________________________________________ > MINC-users@bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users > From minc-users@bic.mni.mcgill.ca Thu Jul 21 18:23:06 2005 From: minc-users@bic.mni.mcgill.ca (Richard Boyes) Date: Thu Jul 21 17:23:06 2005 Subject: [MINC-users] nu_correct & masking In-Reply-To: References: <20050401061203.GC5311@nyongwa.montreal.qc.ca> <20050415203847.GB7951@sickkids.ca> Message-ID: Hello everybody Regarding use of a mask with nu_correct, I have available to me two types: 1. A brain mask that excludes CSF completely - ie WM, GM only 2. A 'filled' brain mask - ie includes the CSF in the sulcal and ventricular spaces. My question is, which mask is more effective? Intuitively I thought that the CSF mask would be better, as it gives 3 classes in the histogram, which gives N3 3 histogram peaks to optimize over. Thanks in advance Richard From minc-users@bic.mni.mcgill.ca Thu Jul 21 18:23:47 2005 From: minc-users@bic.mni.mcgill.ca (Valentino, Daniel) Date: Thu Jul 21 17:23:47 2005 Subject: FW: [MINC-users] Very large dicom variables in the header crashin g loni debabelizer. Message-ID: <37B1919151E3D411B55800508BE3758817B3B513@medmail8.mednet.ucla.edu> Hi Dylan: David Shattuck forwarded your message to me as I'm not on the minc-users mailing list. If you can arrange to give us some examples of the files that you're having trouble with, then we'll figure out what is going on and help you to resolve the problem. In the future, please feel free to contact me or Scott Neu directly if you encounter any problems with the use of the LONI Debabeler. Thanks! Sincerely, Daniel ============================================================ | Daniel J. Valentino, Ph.D. | | Associate Professor of Radiology and Bioengineering | | Laboratory of Neuro Imaging (LONI) and | | Division of Interventional Neuro Radiology (DINR) | ============================================================ | Mail Stop 172115 | | UCLA Radiology | | Los Angeles CA 90095-1721 | ============================================================ | 310-794-7131 (office) | | 310-206-2967 (fax) | ============================================================ | dvalentino@mednet.ucla.edu http://www.loni.ucla.edu/ | ============================================================ ---------- Forwarded message ---------- From: Dylan David Wagner Date: Jul 20, 2005 5:23 PM Subject: [MINC-users] Very large dicom variables in the header crashing loni debabelizer. To: minc-users@bic.mni.mcgill.ca Hi, I've been trying to use the loni debabelizer to convert some minc files to nifti and/or analyze (couldn't find an in house converter for nifti, do we have one?). I've been finding that certain files crash it, other files aren't identified as MINC and a third group actually work! The reason why some files crash the babelizer, or aren't identified, seems to have to do with long headers caused by some of the dicom variables in the minc header. At least that's the only difference I can discern. Older mincfiles scanned before the Siemens got an upgrade are identified without fail. Aside from a few additional entries in the study variable, the main differences is the dicom variables are huge and the mincheader jumps from ~20kb to 700+ Kb. Newer files scanned after the upgrade work if they've been preprocessed with the fmri preprocessing tools (which seems to eliminate the dicom entries from the header). Oddly enough if I use cygwin to do the preprocessing with the same minctools, the dicom entries in the header are preserved (and loni debabelizer crashes). I'm guessing the fault lies with the Loni app, however does anyone have any quick fixes to eliminate all the dicom info from the header? I'd still like to keep the rest of the header intact. Thanks, DDW _______________________________________________ MINC-users@bic.mni.mcgill.ca http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users ---------------------------------------------------------- IMPORTANT WARNING: This email (and any attachments) is only intended for the use of the person or entity to which it is addressed, and may contain information that is privileged and confidential. You, the recipient, are obligated to maintain it in a safe, secure and confidential manner. Unauthorized redisclosure or failure to maintain confidentiality may subject you to federal and state penalties. If you are not the intended recipient, please immediately notify us by return email, and delete this message from your computer. ---------------------------------------------------------- From minc-users@bic.mni.mcgill.ca Mon Jul 25 07:58:04 2005 From: minc-users@bic.mni.mcgill.ca (Kim, Hyun-Pil) Date: Mon Jul 25 06:58:04 2005 Subject: [MINC-users] mnc2ana problem In-Reply-To: Message-ID: <1122289053776949.12353@webmail> Dear Andrew, There is a trivial bug in ana2mnc script. dim[4] in the header of a MINC2ANA-ed file should be set to 1 to be accessible from Analyze, Mayo Foundation, which is the father of all Analyze files :) The current version of mnc2ana sets it to zero by default, and Analyze crashes when I try to open it. I fixed this for myself but I hope this to be officially corrected for the next release. Thanks, PHIL <<------------------------------------------------>> Hyun-Pil Kim, Computational Neuroimage Analysis Lab., Dept. of Biomedical Engineering, Hanyang Univ. Sungdong P.O. Box 55, Seoul, 133-605, KOREA Tel: +82-2-2290-0697; FAX: +82-2-2296-5943 Mobile: +82-19-286-0485 E-mail: hpkim at ihanyang.ac.kr; aimtop77 at empal.com <<------------------------------------------------>> From Andrew Janke Wed Jul 27 01:27:06 2005 From: Andrew Janke (Andrew Janke) Date: Wed Jul 27 00:27:06 2005 Subject: [MINC-users] nu_correct & masking In-Reply-To: References: <20050401061203.GC5311@nyongwa.montreal.qc.ca> <20050415203847.GB7951@sickkids.ca> Message-ID: Hi Richard, I had hoped that John Sled would bite on this one, but it appears not so here's my thoughts... My feeling is that (2) is better. The more data you give N3 to smooth over the better it is going to perform. As far as I am aware, N3 does not optimise over peaks per-se but rather the histogram in general. Thus as you way, the more "information" in the image the better. Myself I tend to run nu_correct without a mask altogether beyond any masking it does internally. Andrew On 12/07/05, Richard Boyes wrote: > Hello everybody > > Regarding use of a mask with nu_correct, I have available > to me two types: > > 1. A brain mask that excludes CSF completely - ie WM, GM > only > > 2. A 'filled' brain mask - ie includes the CSF in the sulcal > and ventricular spaces. > > My question is, which mask is more effective? Intuitively > I thought that the CSF mask would be better, as it gives 3 > classes in the histogram, which gives N3 3 histogram peaks > to optimize over. > > Thanks in advance > Richard > _______________________________________________ > MINC-users@bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users > -- Andrew Janke (a.janke@gmail.com || www.cmr.uq.edu.au/~rotor) Canada->Montreal Cell: +1 (514) 924 2012 From minc-users@bic.mni.mcgill.ca Wed Jul 27 11:01:05 2005 From: minc-users@bic.mni.mcgill.ca (Maxime Descoteaux) Date: Wed Jul 27 10:01:05 2005 Subject: [MINC-users] mnc2nii & nii2mnc Message-ID: <63fa588eebe418bf93a0597e0dad3191@cim.mcgill.ca> Hi all, I heard about these scripts for mnc volume conversion. Where can I get them? I was using ana2mnc/mnc2ana for my analyze conversion but it does not support 4D data convertion. Can mn2nii do 4D conversion? thanks Max From minc-users@bic.mni.mcgill.ca Wed Jul 27 11:36:04 2005 From: minc-users@bic.mni.mcgill.ca (Robert VINCENT) Date: Wed Jul 27 10:36:04 2005 Subject: [MINC-users] mnc2nii & nii2mnc In-Reply-To: <63fa588eebe418bf93a0597e0dad3191@cim.mcgill.ca> Message-ID: Hi, mnc2nii & nii2mnc should both work with 4D datasets in either Analyze or NIfTI-1 format. They are part of MINC release 1.4, available here: http://packages.bic.mni.mcgill.ca/tgz/minc-1.4.tar.gz They are new and should therefore be viewed with skepticism. Check over the results carefully and let me know if you have any problems. -bert On Wed, 27 Jul 2005, Maxime Descoteaux wrote: > Hi all, > > I heard about these scripts for mnc volume conversion. Where can I get > them? I was using ana2mnc/mnc2ana for my analyze conversion but it > does not support 4D data convertion. Can mn2nii do 4D conversion? > > thanks > > Max > > _______________________________________________ > MINC-users@bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users > From minc-users@bic.mni.mcgill.ca Wed Jul 27 19:05:04 2005 From: minc-users@bic.mni.mcgill.ca (Alex ZIJDENBOS) Date: Wed Jul 27 18:05:04 2005 Subject: [MINC-users] nu_correct & masking In-Reply-To: References: <20050401061203.GC5311@nyongwa.montreal.qc.ca> <20050415203847.GB7951@sickkids.ca> Message-ID: <20050727220432.GE4878@bic.mni.mcgill.ca> Just to chip in: AFAIK it does hurt N3 if you give it data it should not optimize over. In other words, assuming you care about the brain only, I believe it does help to provide a brain mask such that it doesn't try to uniformize scalp/neck/etc. -- A On Wed, Jul 27, 2005 at 12:26:16AM -0400, Andrew Janke wrote: > Hi Richard, > > I had hoped that John Sled would bite on this one, but it appears not > so here's my thoughts... > > My feeling is that (2) is better. The more data you give N3 to smooth > over the better it is going to perform. As far as I am aware, N3 does > not optimise over peaks per-se but rather the histogram in general. > Thus as you way, the more "information" in the image the better. > > Myself I tend to run nu_correct without a mask altogether beyond any > masking it does internally. > > Andrew > > > On 12/07/05, Richard Boyes wrote: > > Hello everybody > > > > Regarding use of a mask with nu_correct, I have available > > to me two types: > > > > 1. A brain mask that excludes CSF completely - ie WM, GM > > only > > > > 2. A 'filled' brain mask - ie includes the CSF in the sulcal > > and ventricular spaces. > > > > My question is, which mask is more effective? Intuitively > > I thought that the CSF mask would be better, as it gives 3 > > classes in the histogram, which gives N3 3 histogram peaks > > to optimize over. > > > > Thanks in advance > > Richard > > _______________________________________________ > > MINC-users@bic.mni.mcgill.ca > > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users > > > > > -- > Andrew Janke (a.janke@gmail.com || www.cmr.uq.edu.au/~rotor) > Canada->Montreal Cell: +1 (514) 924 2012 > > _______________________________________________ > MINC-users@bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users From minc-users@bic.mni.mcgill.ca Thu Jul 28 00:10:04 2005 From: minc-users@bic.mni.mcgill.ca (Najmeh Khalili M.) Date: Wed Jul 27 23:10:04 2005 Subject: [MINC-users] nu_correct & masking In-Reply-To: Message-ID: > > My feeling is that (2) is better. The more data you give N3 to smooth Some time ago, I tested the effect of performing NU-correct with and without a brain mask, and as far as I could tell (and since I was dealing with pahological tissue, I "could" tell) masking improved the image processing stages that followed N3! So I would suggest option 2 as well. Najma > > > > 2. A 'filled' brain mask - ie includes the CSF in the sulcal > > and ventricular spaces. > > > > My question is, which mask is more effective? Intuitively > > I thought that the CSF mask would be better, as it gives 3 > > classes in the histogram, which gives N3 3 histogram peaks > > to optimize over. > > > > Thanks in advance > > Richard > > _______________________________________________ > > MINC-users@bic.mni.mcgill.ca > > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users > > > > > -- > Andrew Janke (a.janke@gmail.com || www.cmr.uq.edu.au/~rotor) > Canada->Montreal Cell: +1 (514) 924 2012 > > _______________________________________________ > MINC-users@bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users > From Andrew Janke Thu Jul 28 08:29:03 2005 From: Andrew Janke (Andrew Janke) Date: Thu Jul 28 07:29:03 2005 Subject: [MINC-users] ana2mnc update. In-Reply-To: <1122511191530494.30921@webmail> References: <1122511191530494.30921@webmail> Message-ID: Hyun-Pil Kim has kindly sent me some changes to ana2mnc that solve some problems with respect to defaults of pixdim. Essentially they are now all set to 1 when empty as opposed to 0. Apparently this solves some problems with some analyze viewers. I have placed the new version here. http://packages.bic.mni.mcgill.ca/scripts/ana2mnc-1.3d Those interested in MINC->ANALYZE conversion will also be interested to note that the new version of MINC (1.4) includes converters for MINC->Nifti-1 and the reverse called nii2mnc and mnc2nii. These two converters are the new official analyze converters for MINC. I suspect I will still apply minor patches to ana2mnc but hope to eventually retire it in favour of nii2mnc -- Andrew Janke (a.janke@gmail.com || www.cmr.uq.edu.au/~rotor) Canada->Montreal Cell: +1 (514) 924 2012 From minc-users@bic.mni.mcgill.ca Thu Jul 28 09:28:04 2005 From: minc-users@bic.mni.mcgill.ca (Kim, Hyun-Pil) Date: Thu Jul 28 08:28:04 2005 Subject: [MINC-users] ana2mnc update. Message-ID: <1122553619105092.987@webmail> The same problem also exists in mnc2nii. I hope this fixed for the next release of minc. Thanks, PHIL -----Original Message----- From: minc-users-admin@bic.mni.mcgill.ca [mailto:minc-users-admin@bic.mni.mcgill.ca] On Behalf Of Andrew Janke Sent: Thursday, July 28, 2005 8:29 PM To: Kim, Hyun-Pil; minc-users@bic.mni.mcgill.ca Subject: [MINC-users] ana2mnc update. Hyun-Pil Kim has kindly sent me some changes to ana2mnc that solve some problems with respect to defaults of pixdim. Essentially they are now all set to 1 when empty as opposed to 0. Apparently this solves some problems with some analyze viewers. I have placed the new version here. http://packages.bic.mni.mcgill.ca/scripts/ana2mnc-1.3d Those interested in MINC->ANALYZE conversion will also be interested to note that the new version of MINC (1.4) includes converters for MINC->Nifti-1 and the reverse called nii2mnc and mnc2nii. These two converters are the new official analyze converters for MINC. I suspect I will still apply minor patches to ana2mnc but hope to eventually retire it in favour of nii2mnc -- Andrew Janke (a.janke@gmail.com || www.cmr.uq.edu.au/~rotor) Canada->Montreal Cell: +1 (514) 924 2012 _______________________________________________ MINC-users@bic.mni.mcgill.ca http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users From Andrew Janke Thu Jul 28 09:58:04 2005 From: Andrew Janke (Andrew Janke) Date: Thu Jul 28 08:58:04 2005 Subject: [MINC-users] ana2mnc update. In-Reply-To: <1122553619105092.987@webmail> References: <1122553619105092.987@webmail> Message-ID: True! It should be, I am working on a fix for it. a On 28/07/05, Kim, Hyun-Pil wrote: > The same problem also exists in mnc2nii. > I hope this fixed for the next release of minc. > > Thanks, > PHIL > > -----Original Message----- > From: minc-users-admin@bic.mni.mcgill.ca > [mailto:minc-users-admin@bic.mni.mcgill.ca] On Behalf Of Andrew Janke > Sent: Thursday, July 28, 2005 8:29 PM > To: Kim, Hyun-Pil; minc-users@bic.mni.mcgill.ca > Subject: [MINC-users] ana2mnc update. > > Hyun-Pil Kim has kindly sent me some changes to ana2mnc that solve some > problems with respect to defaults of pixdim. Essentially they are now all > set to 1 when empty as opposed to 0. > > Apparently this solves some problems with some analyze viewers. I have > placed the new version here. > > http://packages.bic.mni.mcgill.ca/scripts/ana2mnc-1.3d > > Those interested in MINC->ANALYZE conversion will also be interested to note > that the new version of MINC (1.4) includes converters for > MINC->Nifti-1 and the reverse called nii2mnc and mnc2nii. These two > converters are the new official analyze converters for MINC. > > I suspect I will still apply minor patches to ana2mnc but hope to eventually > retire it in favour of nii2mnc > > > -- > Andrew Janke (a.janke@gmail.com || www.cmr.uq.edu.au/~rotor) > Canada->Montreal Cell: +1 (514) 924 2012 > > _______________________________________________ > MINC-users@bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users > > _______________________________________________ > MINC-users@bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users > -- Andrew Janke (a.janke@gmail.com || www.cmr.uq.edu.au/~rotor) Canada->Montreal Cell: +1 (514) 924 2012 From minc-users@bic.mni.mcgill.ca Fri Jul 29 16:34:04 2005 From: minc-users@bic.mni.mcgill.ca (minc-users@bic.mni.mcgill.ca) Date: Fri Jul 29 15:34:04 2005 Subject: [MINC-users] nu_correct & masking In-Reply-To: <200507281601.j6SG1C8p14203169@shadow.bic.mni.mcgill.ca> Message-ID: Hello, Some further thoughts on the nu_correct issue. nu_correct works by sharpening the intensity histogram (by successively deconvolving it). Therefore, if you mask out the csf, it will determine the optimal bias correction for the brain-without-csf intensity histogram. If masking is not done, then the optimal bias correction for the entire brain is done. The 'actual' bias field extends over the entire brain which includes the csf. But for processing purposes, the goal may not be to calculate the 'actual' field but rather the one that produces the best uniformity in a specific tissue type in the resulting image. So the most 'effective' use of nu_correct depends on your objective (which would be most likely the latter, for image processing purposes - hence use a mask). According to the Sled 1998 article (p.90), "simple thresholding is used to remove empty regions" from the brain volume. This may automatically exclude csf regions as well. Empirical testing would be useful to verify these ideas. Ernest Lo NeuroRX Research Montreal, Canada > Message: 1 > Date: Wed, 27 Jul 2005 18:04:33 -0400 > From: Alex ZIJDENBOS > Subject: Re: [MINC-users] nu_correct & masking > To: Andrew Janke > Cc: minc-users@bic.mni.mcgill.ca > Reply-To: minc-users@bic.mni.mcgill.ca > > Just to chip in: AFAIK it does hurt N3 if you give it data it should > not optimize over. In other words, assuming you care about the brain > only, I believe it does help to provide a brain mask such that it > doesn't try to uniformize scalp/neck/etc. > > -- A > > On Wed, Jul 27, 2005 at 12:26:16AM -0400, Andrew Janke wrote: > > Hi Richard, > > > > I had hoped that John Sled would bite on this one, but it appears not > > so here's my thoughts... > > > > My feeling is that (2) is better. The more data you give N3 to smooth > > over the better it is going to perform. As far as I am aware, N3 does > > not optimise over peaks per-se but rather the histogram in general. > > Thus as you way, the more "information" in the image the better. > > > > Myself I tend to run nu_correct without a mask altogether beyond any > > masking it does internally. > > > > Andrew > > > > > > On 12/07/05, Richard Boyes wrote: > > > Hello everybody > > > > > > Regarding use of a mask with nu_correct, I have available > > > to me two types: > > > > > > 1. A brain mask that excludes CSF completely - ie WM, GM > > > only > > > > > > 2. A 'filled' brain mask - ie includes the CSF in the sulcal > > > and ventricular spaces. > > > > > > My question is, which mask is more effective? Intuitively > > > I thought that the CSF mask would be better, as it gives 3 > > > classes in the histogram, which gives N3 3 histogram peaks > > > to optimize over. > > > > > > Thanks in advance > > > Richard > > > _______________________________________________ > > > MINC-users@bic.mni.mcgill.ca > > > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users > > > > > > > > > -- > > Andrew Janke (a.janke@gmail.com || www.cmr.uq.edu.au/~rotor) > > Canada->Montreal Cell: +1 (514) 924 2012 > > > > _______________________________________________ > > MINC-users@bic.mni.mcgill.ca > > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users > > --__--__-- > > Message: 2 > Date: Wed, 27 Jul 2005 23:09:16 -0400 > From: "Najmeh Khalili M." > To: Andrew Janke > cc: minc-users@bic.mni.mcgill.ca > Subject: Re: [MINC-users] nu_correct & masking > Reply-To: minc-users@bic.mni.mcgill.ca > > > > > My feeling is that (2) is better. The more data you give N3 to smooth > > Some time ago, I tested the effect of performing NU-correct with and > without a brain mask, and as far as I could tell (and since I was dealing > with pahological tissue, I "could" tell) masking improved the image > processing stages that followed N3! So I would suggest option 2 as well. > > Najma > > > > > > > 2. A 'filled' brain mask - ie includes the CSF in the sulcal > > > and ventricular spaces. > > > > > > My question is, which mask is more effective? Intuitively > > > I thought that the CSF mask would be better, as it gives 3 > > > classes in the histogram, which gives N3 3 histogram peaks > > > to optimize over. > > > > > > Thanks in advance > > > Richard > > > _______________________________________________ > > > MINC-users@bic.mni.mcgill.ca > > > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users > > > > > > > > > -- > > Andrew Janke (a.janke@gmail.com || www.cmr.uq.edu.au/~rotor) > > Canada->Montreal Cell: +1 (514) 924 2012 > > > > _______________________________________________ > > MINC-users@bic.mni.mcgill.ca > > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users > > > > > > > --__--__--