From minc-users@bic.mni.mcgill.ca Wed Sep 4 01:38:19 2002 From: minc-users@bic.mni.mcgill.ca (Jon Erik Ween, MD) Date: 03 Sep 2002 17:38:19 -0700 Subject: [MINC-users] x86 system optimization Message-ID: <1031099904.1866.87.camel@ADIlab> Hello everyone I'm trying to optimize the performance of display and register on an x86 system realizing this is ported software from the SGI world. Is there a "best" configuration, particularly using polygon-based video components? (My configuration if it matters: 2.2GHz P4, 512MB PC1066, ATI Radeon 8500 128MB) I notice that the apps are VERY CPU intensive and suspect they are not utilizing the VPU on the videocard very much? Also "ldd Display" does not show any links to the Mesa libraries. I thought these program were Mesa dependent? Is there any compilation of minc tool functions, usage and syntax apart from the man pages? Any hints to the novice would be appreciated. Jon Jon Erik Ween, MD Assistant Professor Cognitive and Cerebrovascular Neurology Loam Linda University From minc-users@bic.mni.mcgill.ca Wed Sep 4 14:04:55 2002 From: minc-users@bic.mni.mcgill.ca (Jason Lerch) Date: Wed, 4 Sep 2002 09:04:55 -0400 Subject: [MINC-users] x86 system optimization In-Reply-To: <1031099904.1866.87.camel@ADIlab>; from jween@som.llu.edu on Tue, Sep 03, 2002 at 05:38:19PM -0700 References: <1031099904.1866.87.camel@ADIlab> Message-ID: <20020904090455.A2170998@bic.mni.mcgill.ca> Hi John, > I notice that the apps are VERY CPU intensive and suspect they are not > utilizing the VPU on the videocard very much? > > Also "ldd Display" does not show any links to the Mesa libraries. I > thought these program were Mesa dependent? They are indeed OpenGL dependent (ldd should show a link to libGL and libGLU), whether Mesa or some other implementation. Unfortunately, however, they were not written to take advantage of most of the OpenGL acceleration you can gain, whether it be on an SGI or a Linux box. This is especially the case for the geometry window, unfortunately. There are a few other visualisation tools around here at the MNI, though none of them are all that mature at this point. > Is there any compilation of minc tool functions, usage and syntax apart > from the man pages? Try http://www.bic.mni.mcgill.ca/software While it isn't nearly as comprehensive as it ought to be, it might provide a few more pointers than just the man pages. Please let me know if you find anything that is especially notable for its absence! Cheers, Jason From minc-users@bic.mni.mcgill.ca Wed Sep 4 15:19:40 2002 From: minc-users@bic.mni.mcgill.ca (Jon Erik Ween, MD) Date: 04 Sep 2002 07:19:40 -0700 Subject: [MINC-users] x86 system optimization In-Reply-To: <20020904090455.A2170998@bic.mni.mcgill.ca> References: <1031099904.1866.87.camel@ADIlab> <20020904090455.A2170998@bic.mni.mcgill.ca> Message-ID: <1031149185.23022.3.camel@ADIlab> On Wed, 2002-09-04 at 06:04, Jason Lerch wrote: Jason Thanks for your reply. This is my output of "ldd Display". I don't see any link to a GL library, though I'm not sure what all these mean. The version of Display/register I use was compiled by Rick Hoge at MGH. Maybe his binaries are ideosyncratic? /lib/libNoVersion.so.1 => /lib/libNoVersion.so.1 (0x40014000) libm.so.6 => /lib/i686/libm.so.6 (0x40031000) libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x40053000) libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x40128000) libXt.so.6 => /usr/X11R6/lib/libXt.so.6 (0x40135000) libXmu.so.6 => /usr/X11R6/lib/libXmu.so.6 (0x40181000) libc.so.6 => /lib/i686/libc.so.6 (0x42000000) libdl.so.2 => /lib/libdl.so.2 (0x40197000) libSM.so.6 => /usr/X11R6/lib/libSM.so.6 (0x4019a000) libICE.so.6 => /usr/X11R6/lib/libICE.so.6 (0x401a2000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) Jon > Hi John, > > > I notice that the apps are VERY CPU intensive and suspect they are not > > utilizing the VPU on the videocard very much? > > > > Also "ldd Display" does not show any links to the Mesa libraries. I > > thought these program were Mesa dependent? > > They are indeed OpenGL dependent (ldd should show a link to libGL and > libGLU), whether Mesa or some other implementation. Unfortunately, > however, they were not written to take advantage of most of the OpenGL > acceleration you can gain, whether it be on an SGI or a Linux box. This is > especially the case for the geometry window, unfortunately. There are a > few other visualisation tools around here at the MNI, though none of them > are all that mature at this point. > > > Is there any compilation of minc tool functions, usage and syntax apart > > from the man pages? > > Try http://www.bic.mni.mcgill.ca/software > > While it isn't nearly as comprehensive as it ought to be, it might provide > a few more pointers than just the man pages. Please let me know if you > find anything that is especially notable for its absence! > > Cheers, > > Jason > _______________________________________________ > MINC-users@bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users From minc-users@bic.mni.mcgill.ca Wed Sep 4 15:21:45 2002 From: minc-users@bic.mni.mcgill.ca (Jason Lerch) Date: Wed, 4 Sep 2002 10:21:45 -0400 Subject: [MINC-users] x86 system optimization In-Reply-To: <1031149185.23022.3.camel@ADIlab>; from jween@som.llu.edu on Wed, Sep 04, 2002 at 07:19:40AM -0700 References: <1031099904.1866.87.camel@ADIlab> <20020904090455.A2170998@bic.mni.mcgill.ca> <1031149185.23022.3.camel@ADIlab> Message-ID: <20020904102145.A2280143@bic.mni.mcgill.ca> Jon, ldd only lists dynamically loaded libraries - it is therefore possible that Rick compiled Display using a static version of Mesa. There is no way, however, that Display can run without some version of OpenGL or its predecessors (that I know of, anyway). Cheers, Jason On Wed, Sep 04, 2002 at 07:19:40AM -0700, Jon Erik Ween, MD wrote: > On Wed, 2002-09-04 at 06:04, Jason Lerch wrote: > > Jason > > Thanks for your reply. This is my output of "ldd Display". I don't see > any link to a GL library, though I'm not sure what all these mean. The > version of Display/register I use was compiled by Rick Hoge at MGH. > Maybe his binaries are ideosyncratic? > > > /lib/libNoVersion.so.1 => /lib/libNoVersion.so.1 (0x40014000) > libm.so.6 => /lib/i686/libm.so.6 (0x40031000) > libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x40053000) > libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x40128000) > libXt.so.6 => /usr/X11R6/lib/libXt.so.6 (0x40135000) > libXmu.so.6 => /usr/X11R6/lib/libXmu.so.6 (0x40181000) > libc.so.6 => /lib/i686/libc.so.6 (0x42000000) > libdl.so.2 => /lib/libdl.so.2 (0x40197000) > libSM.so.6 => /usr/X11R6/lib/libSM.so.6 (0x4019a000) > libICE.so.6 => /usr/X11R6/lib/libICE.so.6 (0x401a2000) > /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) > > Jon > > > Hi John, > > > > > I notice that the apps are VERY CPU intensive and suspect they are not > > > utilizing the VPU on the videocard very much? > > > > > > Also "ldd Display" does not show any links to the Mesa libraries. I > > > thought these program were Mesa dependent? > > > > They are indeed OpenGL dependent (ldd should show a link to libGL and > > libGLU), whether Mesa or some other implementation. Unfortunately, > > however, they were not written to take advantage of most of the OpenGL > > acceleration you can gain, whether it be on an SGI or a Linux box. This is > > especially the case for the geometry window, unfortunately. There are a > > few other visualisation tools around here at the MNI, though none of them > > are all that mature at this point. > > > > > Is there any compilation of minc tool functions, usage and syntax apart > > > from the man pages? > > > > Try http://www.bic.mni.mcgill.ca/software > > > > While it isn't nearly as comprehensive as it ought to be, it might provide > > a few more pointers than just the man pages. Please let me know if you > > find anything that is especially notable for its absence! > > > > Cheers, > > > > Jason > > _______________________________________________ > > 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 Wed Sep 4 15:26:06 2002 From: minc-users@bic.mni.mcgill.ca (Steve ROBBINS) Date: Wed, 4 Sep 2002 10:26:06 -0400 Subject: [MINC-users] x86 system optimization In-Reply-To: <1031149185.23022.3.camel@ADIlab>; from jween@som.llu.edu on Wed, Sep 04, 2002 at 07:19:40AM -0700 References: <1031099904.1866.87.camel@ADIlab> <20020904090455.A2170998@bic.mni.mcgill.ca> <1031149185.23022.3.camel@ADIlab> Message-ID: <20020904102606.C2221696@shadow.bic.mni.mcgill.ca> On Wed, Sep 04, 2002 at 07:19:40AM -0700, Jon Erik Ween, MD wrote: > On Wed, 2002-09-04 at 06:04, Jason Lerch wrote: > > Jason > > Thanks for your reply. This is my output of "ldd Display". I don't see > any link to a GL library, That likely just means that the binary was linked with a static GL library. -Steve From minc-users@bic.mni.mcgill.ca Wed Sep 4 17:23:15 2002 From: minc-users@bic.mni.mcgill.ca (Jon Erik Ween, MD) Date: 04 Sep 2002 09:23:15 -0700 Subject: [MINC-users] x86 system optimization In-Reply-To: <20020904102145.A2280143@bic.mni.mcgill.ca> References: <1031099904.1866.87.camel@ADIlab> <20020904090455.A2170998@bic.mni.mcgill.ca> <1031149185.23022.3.camel@ADIlab> <20020904102145.A2280143@bic.mni.mcgill.ca> Message-ID: <1031156600.23022.6.camel@ADIlab> OK, Thanks.I gues this means there is no tweak to Mesa that will improve performance unless you recompile the binary? Jon On Wed, 2002-09-04 at 07:21, Jason Lerch wrote: > Jon, > > ldd only lists dynamically loaded libraries - it is therefore possible > that Rick compiled Display using a static version of Mesa. There is no > way, however, that Display can run without some version of OpenGL or its > predecessors (that I know of, anyway). > > Cheers, > > Jason > > On Wed, Sep 04, 2002 at 07:19:40AM -0700, Jon Erik Ween, MD wrote: > > On Wed, 2002-09-04 at 06:04, Jason Lerch wrote: > > > > Jason > > > > Thanks for your reply. This is my output of "ldd Display". I don't see > > any link to a GL library, though I'm not sure what all these mean. The > > version of Display/register I use was compiled by Rick Hoge at MGH. > > Maybe his binaries are ideosyncratic? > > > > > > /lib/libNoVersion.so.1 => /lib/libNoVersion.so.1 (0x40014000) > > libm.so.6 => /lib/i686/libm.so.6 (0x40031000) > > libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x40053000) > > libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x40128000) > > libXt.so.6 => /usr/X11R6/lib/libXt.so.6 (0x40135000) > > libXmu.so.6 => /usr/X11R6/lib/libXmu.so.6 (0x40181000) > > libc.so.6 => /lib/i686/libc.so.6 (0x42000000) > > libdl.so.2 => /lib/libdl.so.2 (0x40197000) > > libSM.so.6 => /usr/X11R6/lib/libSM.so.6 (0x4019a000) > > libICE.so.6 => /usr/X11R6/lib/libICE.so.6 (0x401a2000) > > /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) > > > > Jon > > > > > Hi John, > > > > > > > I notice that the apps are VERY CPU intensive and suspect they are not > > > > utilizing the VPU on the videocard very much? > > > > > > > > Also "ldd Display" does not show any links to the Mesa libraries. I > > > > thought these program were Mesa dependent? > > > > > > They are indeed OpenGL dependent (ldd should show a link to libGL and > > > libGLU), whether Mesa or some other implementation. Unfortunately, > > > however, they were not written to take advantage of most of the OpenGL > > > acceleration you can gain, whether it be on an SGI or a Linux box. This is > > > especially the case for the geometry window, unfortunately. There are a > > > few other visualisation tools around here at the MNI, though none of them > > > are all that mature at this point. > > > > > > > Is there any compilation of minc tool functions, usage and syntax apart > > > > from the man pages? > > > > > > Try http://www.bic.mni.mcgill.ca/software > > > > > > While it isn't nearly as comprehensive as it ought to be, it might provide > > > a few more pointers than just the man pages. Please let me know if you > > > find anything that is especially notable for its absence! > > > > > > Cheers, > > > > > > Jason > > > _______________________________________________ > > > 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 > _______________________________________________ > MINC-users@bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users From minc-users@bic.mni.mcgill.ca Wed Sep 4 17:34:57 2002 From: minc-users@bic.mni.mcgill.ca (Jason Lerch) Date: Wed, 4 Sep 2002 12:34:57 -0400 Subject: [MINC-users] x86 system optimization In-Reply-To: <1031156600.23022.6.camel@ADIlab>; from jween@som.llu.edu on Wed, Sep 04, 2002 at 09:23:15AM -0700 References: <1031099904.1866.87.camel@ADIlab> <20020904090455.A2170998@bic.mni.mcgill.ca> <1031149185.23022.3.camel@ADIlab> <20020904102145.A2280143@bic.mni.mcgill.ca> <1031156600.23022.6.camel@ADIlab> Message-ID: <20020904123457.F2280143@bic.mni.mcgill.ca> On Wed, Sep 04, 2002 at 09:23:15AM -0700, Jon Erik Ween, MD wrote: > OK, Thanks.I gues this means there is no tweak to Mesa that will improve > performance unless you recompile the binary? Pretty much. But again, don't expect blazing performance out of Display no matter what OpenGL library/drivers you use! Jason From John.Sled@swchsc.on.ca Thu Sep 5 01:22:09 2002 From: John.Sled@swchsc.on.ca (John Sled) Date: Wed, 4 Sep 2002 20:22:09 -0400 Subject: [MINC-users] x86 system optimization In-Reply-To: <1031149185.23022.3.camel@ADIlab>; from jween@som.llu.edu on Wed, Sep 04, 2002 at 07:19:40AM -0700 References: <1031099904.1866.87.camel@ADIlab> <20020904090455.A2170998@bic.mni.mcgill.ca> <1031149185.23022.3.camel@ADIlab> Message-ID: <20020904202209.B29386@billy.sunnybrook.utoronto.ca> Jon, While as Jason pointed out the implementation of Display doesn't take full advantage of modern graphics hardware, the performance of the program should be quite respectable on the PC you describe, particularly if you have a version that is linked against the GL library specific to the graphic system on your linux distribution. Unless by chance Rick's system closely matches your own, I think it would be worthwhile to rebuild Display so that it links against libGL.so and libGLU.so for your system. John Hospital for Sick Children Mouse Imaging Centre 555 University Ave. Toronto, Ontario M5G 1X8 Canada Phone: 416 813-7654 x1438 Fax: 416 813-2208 On Wed, Sep 04, 2002 at 07:19:40AM -0700, Jon Erik Ween, MD wrote: > On Wed, 2002-09-04 at 06:04, Jason Lerch wrote: > > Jason > > Thanks for your reply. This is my output of "ldd Display". I don't see > any link to a GL library, though I'm not sure what all these mean. The > version of Display/register I use was compiled by Rick Hoge at MGH. > Maybe his binaries are ideosyncratic? > > > /lib/libNoVersion.so.1 => /lib/libNoVersion.so.1 (0x40014000) > libm.so.6 => /lib/i686/libm.so.6 (0x40031000) > libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x40053000) > libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x40128000) > libXt.so.6 => /usr/X11R6/lib/libXt.so.6 (0x40135000) > libXmu.so.6 => /usr/X11R6/lib/libXmu.so.6 (0x40181000) > libc.so.6 => /lib/i686/libc.so.6 (0x42000000) > libdl.so.2 => /lib/libdl.so.2 (0x40197000) > libSM.so.6 => /usr/X11R6/lib/libSM.so.6 (0x4019a000) > libICE.so.6 => /usr/X11R6/lib/libICE.so.6 (0x401a2000) > /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) > > Jon > From minc-users@bic.mni.mcgill.ca Thu Sep 5 07:23:13 2002 From: minc-users@bic.mni.mcgill.ca (Andrew Janke) Date: Thu, 5 Sep 2002 16:23:13 +1000 Subject: [MINC-users] minctoraw In-Reply-To: Message-ID: On Thu, 29 Aug 2002, Stephen Smith wrote: > Hi - thanks for the reply, though I couldn't quite follow what the range > options are really doing. I have tried that and sadly it gives junk output > - most values being set to 32767... > > The intensity range parts of mincheader are below - does that tell you > anything useful about what the options should be to mincextract? Time for me to add my 2c + 15% GST worth. > image-min = 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, > image-max = 5896592.46886447, 6089528.00976801, 5860417.05494506, What peter is elluding to is that your images have probably been rescaled (per slice) along the way. This can be viewed as either an unfortunate or fortunate thing... :) Peter also is taking a stab at your input and output data range being 12-bit. (something that we all know is very common of certain unnamed manufacturers). The problem as you describe it sounds like you are writing out data that is scaled per slice and getting "zippering" between slices. Unfortunately minctoraw and mincextract don't appear to have an option to "normalize" just between slices although peter will correct me here if I am wrong. As such what you need to do is make sure a MINC image has only one max and min value before doing a minctoraw/mincextract. Most programs that use volume_io and set_volume_real_range have the side-effect of doing this.. :) On this note, I have been meaning to write a quick volume_io proggie to do this. Stay tuned (or email me again in a week) and I'll have a fix for you. andrew From minc-users@bic.mni.mcgill.ca Thu Sep 5 09:00:52 2002 From: minc-users@bic.mni.mcgill.ca (Stephen Smith) Date: Thu, 5 Sep 2002 09:00:52 +0100 (BST) Subject: [MINC-users] minctoraw In-Reply-To: Message-ID: Hi - thanks for this. In fact, using the normalise option DOES make all the slices have the right intensity _relative to eachother_ but the overall 3D intensity scaling is in general lost - unless you use the normalise option with the output datatype set as float in which case all is well. It is a pain to have to use floats but that seems the only thing that works....hohum :) Thanks, Steve. On Thu, 5 Sep 2002, Andrew Janke wrote: > On Thu, 29 Aug 2002, Stephen Smith wrote: > > > Hi - thanks for the reply, though I couldn't quite follow what the range > > options are really doing. I have tried that and sadly it gives junk output > > - most values being set to 32767... > > > > The intensity range parts of mincheader are below - does that tell you > > anything useful about what the options should be to mincextract? > > Time for me to add my 2c + 15% GST worth. > > > image-min = 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, > > image-max = 5896592.46886447, 6089528.00976801, 5860417.05494506, > > What peter is elluding to is that your images have probably been rescaled (per > slice) along the way. This can be viewed as either an unfortunate or fortunate > thing... :) > > Peter also is taking a stab at your input and output data range being 12-bit. > (something that we all know is very common of certain unnamed manufacturers). > > The problem as you describe it sounds like you are writing out data that is > scaled per slice and getting "zippering" between slices. Unfortunately minctoraw > and mincextract don't appear to have an option to "normalize" just between > slices although peter will correct me here if I am wrong. > > As such what you need to do is make sure a MINC image has only one max and min > value before doing a minctoraw/mincextract. Most programs that use volume_io > and set_volume_real_range have the side-effect of doing this.. :) > > On this note, I have been meaning to write a quick volume_io proggie to do this. > Stay tuned (or email me again in a week) and I'll have a fix for you. > > > andrew > > > > _______________________________________________ > MINC-users@bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users > Stephen M. Smith Head of Image Analysis, FMRIB Oxford University Centre for Functional MRI of the Brain John Radcliffe Hospital, Headington, Oxford OX3 9DU, UK +44 (0) 1865 222726 (fax 222717) steve@fmrib.ox.ac.uk http://www.fmrib.ox.ac.uk/~steve From minc-users@bic.mni.mcgill.ca Thu Sep 5 10:34:22 2002 From: minc-users@bic.mni.mcgill.ca (Anders Rodell) Date: Thu, 5 Sep 2002 11:34:22 +0200 (CEST) Subject: [MINC-users] Mystery conversion Message-ID: Hi Minc-users Thank you for all your replies! I managed to convert the images from ecat6 to ecat7 using the ecat software which comes with our scanner. From ecat7 to MINC, peters ecattominc worked nicely If you are still interested in the header info for improvement of ecattominc I can try to provide it. best regards Anders -- -- Anders Bertil Rodell Aarhus PET Centre, Aarhus University Hospital, Norrebrogade 44, 8000 Aarhus C, phone work: +45 89 49 44 01 phone home: +45 86 99 34 64 email: rodell@pet.auh.dk From John.Sled@swchsc.on.ca Thu Sep 5 15:39:48 2002 From: John.Sled@swchsc.on.ca (John Sled) Date: Thu, 5 Sep 2002 10:39:48 -0400 Subject: [MINC-users] minctoraw In-Reply-To: ; from steve@fmrib.ox.ac.uk on Thu, Sep 05, 2002 at 09:00:52AM +0100 References: Message-ID: <20020905103947.B2438@billy.sunnybrook.utoronto.ca> Hi Steve, Another option you might consider is to use mincreshape to normalize the slices as follows volume_stats -min -max brain.mnc File: brain.mnc # voxels: 902629 % of total: 100 Volume (mm3): 7.22103e+06 Min: 0 Max: 1.32407e+06 mincreshape -image_range 0 1.32407e06 brain.mnc brain_norm.mnc File: brain_norm.mnc # voxels: 902629 % of total: 100 Volume (mm3): 7.22103e+06 Min: 0 Max: 1.32407e+06 This seems to leave the overall scaling the same but removes the interslice scaling. with regards, John Sled Hospital for Sick Children Mouse Imaging Centre 555 University Ave. Toronto, Ontario M5G 1X8 Canada Phone: 416 813-7654 x1438 Fax: 416 813-2208 On Thu, Sep 05, 2002 at 09:00:52AM +0100, Stephen Smith wrote: > > Hi - thanks for this. In fact, using the normalise option DOES make all > the slices have the right intensity _relative to eachother_ but the > overall 3D intensity scaling is in general lost - unless you use the > normalise option with the output datatype set as float in which case all > is well. It is a pain to have to use floats but that seems the only thing > that works....hohum :) > > Thanks, Steve. > > > > On Thu, 5 Sep 2002, Andrew Janke wrote: > > > On Thu, 29 Aug 2002, Stephen Smith wrote: > > > > > Hi - thanks for the reply, though I couldn't quite follow what the range > > > options are really doing. I have tried that and sadly it gives junk output > > > - most values being set to 32767... > > > > > > The intensity range parts of mincheader are below - does that tell you > > > anything useful about what the options should be to mincextract? > > > > Time for me to add my 2c + 15% GST worth. > > > > > image-min = 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, > > > image-max = 5896592.46886447, 6089528.00976801, 5860417.05494506, > > > > What peter is elluding to is that your images have probably been rescaled (per > > slice) along the way. This can be viewed as either an unfortunate or fortunate > > thing... :) > > > > Peter also is taking a stab at your input and output data range being 12-bit. > > (something that we all know is very common of certain unnamed manufacturers). > > > > The problem as you describe it sounds like you are writing out data that is > > scaled per slice and getting "zippering" between slices. Unfortunately minctoraw > > and mincextract don't appear to have an option to "normalize" just between > > slices although peter will correct me here if I am wrong. > > > > As such what you need to do is make sure a MINC image has only one max and min > > value before doing a minctoraw/mincextract. Most programs that use volume_io > > and set_volume_real_range have the side-effect of doing this.. :) > > > > On this note, I have been meaning to write a quick volume_io proggie to do this. > > Stay tuned (or email me again in a week) and I'll have a fix for you. > > > > > > andrew > > > > > > > > _______________________________________________ > > MINC-users@bic.mni.mcgill.ca > > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users > > > > Stephen M. Smith > Head of Image Analysis, FMRIB > > Oxford University Centre for Functional MRI of the Brain > John Radcliffe Hospital, Headington, Oxford OX3 9DU, UK > +44 (0) 1865 222726 (fax 222717) > > steve@fmrib.ox.ac.uk http://www.fmrib.ox.ac.uk/~steve > > _______________________________________________ > MINC-users@bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users From minc-users@bic.mni.mcgill.ca Thu Sep 5 23:41:17 2002 From: minc-users@bic.mni.mcgill.ca (Andrew Janke) Date: Fri, 6 Sep 2002 08:41:17 +1000 Subject: [MINC-users] minctoraw In-Reply-To: <20020905103947.B2438@billy.sunnybrook.utoronto.ca> Message-ID: On Thu, 5 Sep 2002, John Sled wrote: > Another option you might consider is to use mincreshape to normalize > the slices as follows > > volume_stats -min -max brain.mnc > > File: brain.mnc > # voxels: 902629 > % of total: 100 > Volume (mm3): 7.22103e+06 > Min: 0 > Max: 1.32407e+06 Good point.. :) I'd forgotten about this method. For those who are wondering where volume_stats comes from, it's part of John Sleds N3 package. The volume_stats program has now been incorporated into MINC itself but is called mincstats.. mincstats brain.mnc will give you the same output. Then the folling is all the same.. > mincreshape -image_range 0 1.32407e06 brain.mnc brain_norm.mnc > > File: brain_norm.mnc > # voxels: 902629 > % of total: 100 > Volume (mm3): 7.22103e+06 > Min: 0 > Max: 1.32407e+06 andrew From minc-users@bic.mni.mcgill.ca Sat Sep 7 01:14:51 2002 From: minc-users@bic.mni.mcgill.ca (Jon Erik Ween, MD) Date: 06 Sep 2002 17:14:51 -0700 Subject: [MINC-users] mincair for 5.2.2 Message-ID: <1031357697.1825.5.camel@ADIlab> Hi Is there a mincair patch for air5.2.2? Jon From minc-users@bic.mni.mcgill.ca Sun Sep 8 04:07:40 2002 From: minc-users@bic.mni.mcgill.ca (Peter NEELIN) Date: Sat, 7 Sep 2002 23:07:40 -0400 Subject: [MINC-users] minctoraw In-Reply-To: Message-ID: On Thu, 5 Sep 2002, Andrew Janke wrote: > On Thu, 29 Aug 2002, Stephen Smith wrote: > > The problem as you describe it sounds like you are writing out data that is > scaled per slice and getting "zippering" between slices. Unfortunately minctoraw > and mincextract don't appear to have an option to "normalize" just between > slices although peter will correct me here if I am wrong. As Steve points out, the -normalize option already just does normalization between slices. > As such what you need to do is make sure a MINC image has only one max and min > value before doing a minctoraw/mincextract. Most programs that use volume_io > and set_volume_real_range have the side-effect of doing this.. :) No need for this. Both minctoraw and mincextract with -normalize do this. In fact, it is the default for mincextract. However, Steve's problem was normalizing two files to be on the same scale. That can only be done with mincextract -image_range. > On this note, I have been meaning to write a quick volume_io proggie to do this. mincreshape -normalize already does rescaling when the output is a minc file. If you want a particular scale, use the -image_range option to mincreshape. Peter ---- Peter Neelin (neelin@bic.mni.mcgill.ca) From minc-users@bic.mni.mcgill.ca Fri Sep 13 00:58:35 2002 From: minc-users@bic.mni.mcgill.ca (minc-users@bic.mni.mcgill.ca) Date: Thu, 12 Sep 2002 16:58:35 -0700 (MST) Subject: [MINC-users] installing N3 In-Reply-To: Message-ID: I met a problem when runing make test of N3. It failed for Error: Composite mask volume is empty. Check for one of the following: 1) the user supplied mask is empty (all zeros) 2) the values within the region of interest are entirely less than one 3) the user supplied background threshold is too high 4) the intersection of the various masking options yields an empty mask nu_estimate: crashed while running nu_estimate_np_and_em (termination status=7424) I use the downloaded dat in test. How to solve this problem? Thanks Sean