From pgravel@bic.mni.mcgill.ca Tue Jul 6 13:34:05 2004 From: pgravel@bic.mni.mcgill.ca (Paul GRAVEL) Date: Tue Jul 6 12:34:05 2004 Subject: [MINC-users] Automated Segmentation Yet More Questions In-Reply-To: <49C1A2CE-C3E3-11D8-A810-000D93520AA0@bic.mni.mcgill.ca> Message-ID: Hello all, Thank you very much for your feedback. It does however raise a few questions. (Please see below for previous replies to previous questions). 1 - Since ANIMAL uses the ICBM152 model for more robust linear registrations, does this mean that "mritotal" uses the ICBM152 model by default as well, or should I use the "-model icbm_avg_152_t1_tal_lin"? e.g. mritotal -model icbm_avg_152_t1_tal_lin $arg1'_mri.mnc' $arg1'_mri_stx_lin.xfm' 2 - If the "-model" switch needs to be used, is the "icbm_avg_152_t1_tal_lin" file the correct option to use for the ICBM152 model? 3 - After segmentation, in order to remove voxels in the skull, should I use a different mask than "average_305_mask.mnc"? Once again, I thank you. Best Regards, Paul On Mon, 21 Jun 2004, D. Louis Collins wrote: > Paul, > > The procedure described on my web site is still valid, however, many of > the programs have been updated and yield better results now. > > Answers are below. > > -Louis > > > On Jun 21, 2004, at 11:07 AM, Paul GRAVEL wrote: > > > Hi All, > > > > I am not sure if this is the appropriate mailing list to send these > > questions(bottom of e-mail) to, but I will ask them anyway. Please > > let me > > know if I should send them to another mailing list. > > > > I have 42 subjects that I needed to segment into several ROI's. > > I used the procedure displayed on Dr. Louis Collins Web Page > > (http://www.bic.mni.mcgill.ca/users/louis/pet_segment) > > > > The procedure is as followed: > > > > Step 1: mritotal $arg1'_mri.mnc' $arg1'_mri_stx_lin.xfm' > > > > Step 2: nu_correct $arg1'_mri.mnc' $arg1'_mri_nuc.mnc' > > > > Step 3: mritotal -nonlinear $arg1'_mri_nuc.mnc' -transformation > > $arg1'_mri_stx_lin.xfm' $arg1'_mri_stx_nonlin.xfm' > > > > Step 4a: mincresample -like > > /avgbrain/brain/images/icbm_template_1.00mm.mnc > > $arg1'_mri_nuc.mnc' -transformation $arg1'_mri_stx_lin.xfm' > > $arg1'_mri_stx_nuc.mnc' > > > > Step 4b: classify_clean $arg1'_mri_stx_nuc.mnc' > > $arg1'_mri_stx_classes.mnc' > > > > Step 5: stx_segment $arg1'_mri_stx_nonlin.xfm' $arg1'_mri_stx_lin.xfm' > > $arg1'_mri_stx_classes.mnc' $arg1'_mri_stx_labels.mnc' > > > > > > My questions are as followed: > > > > 1 - Is this still the best procedure to do segmentation? > > pretty much. ANIMAL now uses the ICBM152 model for more robust linear > registrations. > > > 2 - Is step 2(nu_correct) based on the N3 Algorithm, if not which > > algorithm is it based on? > > this is based on N3, the method of John Sled. > > > 3 - Is step 4b(classify_clean) based on the INSECT (Intensity > > Normalized > > Stereotaxic Environment for the Classification of Tissue) Algorithm, if > > not which algorithm is it based on? > > classify_clean is a perl script that uses both bayesian and artificial > neural nets for classification and is based on INSECT. > > > 4 - Is step 5(stx_segment) based on the ANIMAL (Automatic Nonlinear > > Imaging Matching and Anatomical Labelling) Algorithm, if not which > > algorithm is it based on? > > step 5, stx_segment, takes the output of the linear and non-linear > registrations and combines it with the classified data to achieve a > segmentation. The entire procedure, registrations+classifications is > ANIMAL. > > Hope this helps, > > -L > > > > > > I thank you very much in advance. > > > > Best Regards, > > > > Paul > > ______________________________ > > > > Paul Gravel > > Neurobiological Psychiatry Unit > > McGill University > > 1033 Pine Avenue West > > Montreal, Quebec, Canada, H3A 1A1 > > Phone: (514) 398-7301 > > Fax: (514) 398-4866 > > > > > > > > > > _______________________________________________ > > MINC-users@bic.mni.mcgill.ca > > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users > ______________________________ Paul Gravel Neurobiological Psychiatry Unit McGill University 1033 Pine Avenue West Montreal, Quebec, Canada, H3A 1A1 Phone: (514) 398-7301 Fax: (514) 398-4866 From sylvain@bic.mni.mcgill.ca Tue Jul 6 16:49:04 2004 From: sylvain@bic.mni.mcgill.ca (Sylvain MILOT) Date: Tue Jul 6 15:49:04 2004 Subject: [MINC-users] Automated Segmentation Yet More Questions In-Reply-To: Message-ID: Hello Paul, the current mritotal version uses the average_305 model : if you look in the perl code, you'll find the following variables which are set with mritotal options -modeldir and -model $ModelDir = "/usr/local/mni/data/mni_autoreg"; $Model = "average_305"; the icbm model lives in the same directory so use either of the following invocations: mritotal -model icbm_avg_152_t1_tal_lin ... or do_mritotal -mritotal '-model icbm_avg_152_t1_tal_lin' ... which is not the same as 'do_mritotal -model icbm_avg_152_t1_tal_lin ...' !!! since the latter is for resampling, not fitting. As for question 3, I dont think it will make any difference. Sylvain On Tue, 6 Jul 2004, Paul GRAVEL wrote: > Hello all, > > Thank you very much for your feedback. > It does however raise a few questions. > (Please see below for previous replies to previous questions). > > 1 - Since ANIMAL uses the ICBM152 model for more robust linear > registrations, does this mean that "mritotal" uses > the ICBM152 model by default as well, or should I use the > "-model icbm_avg_152_t1_tal_lin"? > > e.g. mritotal -model icbm_avg_152_t1_tal_lin $arg1'_mri.mnc' $arg1'_mri_stx_lin.xfm' > > 2 - If the "-model" switch needs to be used, is the > "icbm_avg_152_t1_tal_lin" file the correct option to use > for the ICBM152 model? > > 3 - After segmentation, in order to remove voxels in the skull, > should I use a different mask than "average_305_mask.mnc"? > > Once again, I thank you. > > Best Regards, > > Paul > > On Mon, 21 Jun 2004, D. Louis Collins wrote: > > > Paul, > > > > The procedure described on my web site is still valid, however, many of > > the programs have been updated and yield better results now. > > > > Answers are below. > > > > -Louis > > > > > > On Jun 21, 2004, at 11:07 AM, Paul GRAVEL wrote: > > > > > Hi All, > > > > > > I am not sure if this is the appropriate mailing list to send these > > > questions(bottom of e-mail) to, but I will ask them anyway. Please > > > let me > > > know if I should send them to another mailing list. > > > > > > I have 42 subjects that I needed to segment into several ROI's. > > > I used the procedure displayed on Dr. Louis Collins Web Page > > > (http://www.bic.mni.mcgill.ca/users/louis/pet_segment) > > > > > > The procedure is as followed: > > > > > > Step 1: mritotal $arg1'_mri.mnc' $arg1'_mri_stx_lin.xfm' > > > > > > Step 2: nu_correct $arg1'_mri.mnc' $arg1'_mri_nuc.mnc' > > > > > > Step 3: mritotal -nonlinear $arg1'_mri_nuc.mnc' -transformation > > > $arg1'_mri_stx_lin.xfm' $arg1'_mri_stx_nonlin.xfm' > > > > > > Step 4a: mincresample -like > > > /avgbrain/brain/images/icbm_template_1.00mm.mnc > > > $arg1'_mri_nuc.mnc' -transformation $arg1'_mri_stx_lin.xfm' > > > $arg1'_mri_stx_nuc.mnc' > > > > > > Step 4b: classify_clean $arg1'_mri_stx_nuc.mnc' > > > $arg1'_mri_stx_classes.mnc' > > > > > > Step 5: stx_segment $arg1'_mri_stx_nonlin.xfm' $arg1'_mri_stx_lin.xfm' > > > $arg1'_mri_stx_classes.mnc' $arg1'_mri_stx_labels.mnc' > > > > > > > > > My questions are as followed: > > > > > > 1 - Is this still the best procedure to do segmentation? > > > > pretty much. ANIMAL now uses the ICBM152 model for more robust linear > > registrations. > > > > > 2 - Is step 2(nu_correct) based on the N3 Algorithm, if not which > > > algorithm is it based on? > > > > this is based on N3, the method of John Sled. > > > > > 3 - Is step 4b(classify_clean) based on the INSECT (Intensity > > > Normalized > > > Stereotaxic Environment for the Classification of Tissue) Algorithm, if > > > not which algorithm is it based on? > > > > classify_clean is a perl script that uses both bayesian and artificial > > neural nets for classification and is based on INSECT. > > > > > 4 - Is step 5(stx_segment) based on the ANIMAL (Automatic Nonlinear > > > Imaging Matching and Anatomical Labelling) Algorithm, if not which > > > algorithm is it based on? > > > > step 5, stx_segment, takes the output of the linear and non-linear > > registrations and combines it with the classified data to achieve a > > segmentation. The entire procedure, registrations+classifications is > > ANIMAL. > > > > Hope this helps, > > > > -L > > > > > > > > > > I thank you very much in advance. > > > > > > Best Regards, > > > > > > Paul > > > ______________________________ > > > > > > Paul Gravel > > > Neurobiological Psychiatry Unit > > > McGill University > > > 1033 Pine Avenue West > > > Montreal, Quebec, Canada, H3A 1A1 > > > Phone: (514) 398-7301 > > > Fax: (514) 398-4866 > > > > > > > > > > > > > > > _______________________________________________ > > > MINC-users@bic.mni.mcgill.ca > > > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users > > > > ______________________________ > > Paul Gravel > Neurobiological Psychiatry Unit > McGill University > 1033 Pine Avenue West > Montreal, Quebec, Canada, H3A 1A1 > Phone: (514) 398-7301 > Fax: (514) 398-4866 > > > _______________________________________________ > MINC-users@bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users > --- Sylvain Milot (sylvain@bic.mni.mcgill.ca) (trinity@bic.mni.mcgill.ca) Brain Imaging Centre Montreal Neurological Institute Webster 2B, Room 208 Montreal, Qc., Canada, H3A 2B4 Phone : (514) 398-4965, 1996 Fax: 8948 Mobile : (514) 712-1768 Office : 527 Pine, room 204 From yves.roy@umontreal.ca Wed Jul 7 10:50:10 2004 From: yves.roy@umontreal.ca (Roy Yves) Date: Wed Jul 7 09:50:10 2004 Subject: [MINC-users] Getting resample_tal Message-ID: Hello: I installed minc 1.0 a while ago but it doesn't seem to include resample_tal. I just copied over the (perl) script over to my machine from the bic, but it needs modules from MNI. How can I fix things? Where can I get resample_tal together with some guidelines on what is required to run in? Here is the error I got: $ resample_tal Can't locate MNI/Startup.pm in @INC (@INC contains: /usr/lib/perl5/5.8.0/i386-linux-thread-multi /usr/lib/perl5/5.8.0 /usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi /usr/lib/perl5/site_perl/5.8.0 /usr/lib/perl5/site_perl /usr/lib/perl5/vendor_perl/5.8.0/i386-linux-thread-multi /usr/lib/perl5/vendor_perl/5.8.0 /usr/lib/perl5/vendor_perl /usr/lib/perl5/5.8.0/i386-linux-thread-multi /usr/lib/perl5/5.8.0 .) at /usr/local/mni/bin/resample_tal line 23. BEGIN failed--compilation aborted at /usr/local/mni/bin/resample_tal line 23. Thanks Yves From colliot@bic.mni.mcgill.ca Wed Jul 7 18:09:04 2004 From: colliot@bic.mni.mcgill.ca (Olivier Colliot) Date: Wed Jul 7 17:09:04 2004 Subject: [MINC-users] Some minc tools don't work on some gziped volume Message-ID: <40EC68CF.90300@bic.mni.mcgill.ca> Hi, Something strange is happening when I compress some MINC volumes. Tools mincinfo and mincheader work with the unziped volume but not the ziped ones. E.g. here is what happens with mincinfo : >mincinfo toto.mnc file: toto.mnc image: signed__ short 0 to 4095 image dimensions: zspace yspace xspace dimension name length step start -------------- ------ ---- ----- zspace 181 1 -72 yspace 217 1 -126 xspace 181 1 -90 >gzip toto.mnc >mincinfo toto.mnc.gz ncvarid: ncid 3: Variable not found There is the same kind of problem with mincheader : >mincheader toto.mnc.gz [........] dicom_0x0040:el_0x0245 = "110730.703000 " ; dicom_0x0040:el_0x0253 = "4060610651" ; ncdump: type_name: bad type 0 I never had these kind of problems before. This only occurs with MRIs coming from the Siemens Sonata scanner. These files have a huge minc header, maybe this can be related to the problem. Also, this make the minc2analyse program crash as well... Otherwise, these images can still be viewed and processed normally. Does anyone already had this problem or have an idea ? (of course, I can still use unziped images, but it would be more convenient to find the source of this error) Thanks, Olivier From rotor@cmr.uq.edu.au Thu Jul 8 04:36:03 2004 From: rotor@cmr.uq.edu.au (Andrew Janke) Date: Thu Jul 8 03:36:03 2004 Subject: [MINC-users] Some minc tools don't work on some gziped volume In-Reply-To: <40EC68CF.90300@bic.mni.mcgill.ca> References: <40EC68CF.90300@bic.mni.mcgill.ca> Message-ID: On Wed, 7 Jul 2004, Olivier Colliot wrote: > Something strange is happening when I compress some MINC volumes. > Tools mincinfo and mincheader work with the unziped volume but not the > ziped ones. > > There is the same kind of problem with mincheader : > >mincheader toto.mnc.gz > [........] > dicom_0x0040:el_0x0245 = "110730.703000 " ; > dicom_0x0040:el_0x0253 = "4060610651" ; > ncdump: type_name: bad type 0 > > I never had these kind of problems before. This only occurs with MRIs > coming from the Siemens Sonata scanner. > These files have a huge minc header, maybe this can be related to the > problem. This was a problem with older distributions of MINC whereby not all of the header was decompressed, (a guess was made as to how big a header might possibly grow to and only that was uncompressed, then people went and made huge headers by stuffing in all the dicom information! :). The other option is that certain dicom codes have been known to confuse netCDF/ncgen/ncdump somewhat as they (presumably) resemble control codes used within netCDF. The "fix" for this is the hack perl script below that will strip all such dicom information out of the header, however be _VERY_ aware that this script has the potention to wreak havoc on your MINC file headers as it simply removes any header that has "dicom" somewhere in it! It may also give you dental cavities, but that claim has never been proved. In other words, use it at your own risk and be aware that it works on the file in question in place... --cut here-- #! /usr/bin/env perl # # Andrew Janke - rotor@cmr.uq.edu.au # Center for Magnetic Resonance # The University of Queensland # http://www.cmr.uq.edu.au/~rotor # # USE AT OWN RISK! THIS MAY MUNGE YOUR MINC FILES HEADER! use warnings "all"; use File::Basename; $me = &basename($0); if($#ARGV != 0){ die "\n+++WARNING: THIS SCRIPT MAY MUNGE YOUR FILE PERMANENTLY!+++\n\n". "Usage: $me \n\n"; } (@yukky_vars) = split(' ', `mincinfo -varnames $ARGV[0]`); foreach $var (grep {/dicom/} @yukky_vars){ foreach (split(' ', `mincinfo -varatts $var $ARGV[0]`)){ print " | [$ARGV[0]] - removing $var:$_\n"; system('minc_modify_header', '-delete', "$var:$_", $ARGV[0]) == 0 or die; } } --cut here-- -- Andrew Janke ( rotorATcmr.uq.edu.au || www.cmr.uq.edu.au/~rotor ) Australia->University of Queensland->Centre for Magnetic Resonance W: +61 7 3232 7254 || H: +61 7 3800 4042 || M: +61 4 2138 8581 From rotor@cmr.uq.edu.au Thu Jul 8 04:38:04 2004 From: rotor@cmr.uq.edu.au (Andrew Janke) Date: Thu Jul 8 03:38:04 2004 Subject: [MINC-users] Getting resample_tal In-Reply-To: References: Message-ID: On Wed, 7 Jul 2004, Roy Yves wrote: > I installed minc 1.0 a while ago but it doesn't seem to include resample_tal. > I just copied over the (perl) script over to my machine from the bic, but it needs modules from MNI. > How can I fix things? Where can I get resample_tal together with some guidelines on what is required to run in? > > Here is the error I got: > > $ resample_tal > Can't locate MNI/Startup.pm in @INC (@INC contains: /usr/lib/perl5/5.8.0/i386-linux-thread-multi /usr/lib/perl5/5.8.0 /usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi /usr/lib/perl5/site_perl/5.8.0 /usr/lib/perl5/site_perl /usr/lib/perl5/vendor_perl/5.8.0/i386-linux-thread-multi /usr/lib/perl5/vendor_perl/5.8.0 /usr/lib/perl5/vendor_perl /usr/lib/perl5/5.8.0/i386-linux-thread-multi /usr/lib/perl5/5.8.0 .) at /usr/local/mni/bin/resample_tal line 23. > BEGIN failed--compilation aborted at /usr/local/mni/bin/resample_tal line 23. The script is looking for the mni perl libraries, be sure you have them installed. Get it from here. http://www.bic.mni.mcgill.ca/software/distribution/packages/mni_perllib-0.07.tar.gz If you have installed mni_perllib, then make sure you have your PERL5LIB environment variable set correctly -- Andrew Janke ( rotorATcmr.uq.edu.au || www.cmr.uq.edu.au/~rotor ) Australia->University of Queensland->Centre for Magnetic Resonance W: +61 7 3232 7254 || H: +61 7 3800 4042 || M: +61 4 2138 8581 From dwagne@bic.mni.mcgill.ca Mon Jul 12 12:11:04 2004 From: dwagne@bic.mni.mcgill.ca (Dylan WAGNER) Date: Mon Jul 12 11:11:04 2004 Subject: [MINC-users] Minc to analyze methods Message-ID: Hi minc-users, I've been wanting to try out some different visualization apps which don't support minc (mricro, mri3dX). I've been having a terrible time trying to convert functional minc data to analyze (the anatomicals pose no real problem). First I tried ana2mnc at bic, but couldn't find mnc2ana (nor could I get make_links to work). Tried manually making a mnc2ana symbolic link to ana2mnc but that didn't work either. However by no means a unix expert so perphaps I'm missing something very basic. Installed ana2mnc/mnc2ana on linux, seems to work, however with functional data its output is garbled. The slices seem shifted up and down relative to each other, like a comb effect. I tried forcing an orientation which didn't change things. Tried another mnc2ana tool from: http://cns-web.bu.edu/~satra/software.php This one worked well with the functional data except it confused the orientation, which I can fix with mricro however I'd have to do it one frame at a time. A bit daunting, what. Next I tried the loni debabeler (http://www.loni.ucla.edu/Software/Software_Detail.jsp?software_id=11) to no avail. It detects the anatomical MRIs as minc, but not the functional. Go figure. And I do believe that's all my options. I was wondering if anyone has any other ideas or recipes worth trying? Though I've never tried it, I understand that fmristat imports analyze. Can it also write analyze? From k.h.kho@azu.nl Tue Jul 13 05:40:04 2004 From: k.h.kho@azu.nl (Kuan H. Kho) Date: Tue Jul 13 04:40:04 2004 Subject: [MINC-users] 3Dvisualization/analysis Message-ID: <6.0.3.0.0.20040713093521.01f5a7a8@imap.med.uu.nl> Dear minc-users, In addition to Dylan's post ("Minc to analyze methods" - 12 July 2004), I was wondering if there is a simple MINC application to 1) easily skull strip and render individual brains, and 2) easy "point 'n' click on the cortical surface of the rendering to locate the exact voxel AND world coordinates (and simultaneously check those points in the corresponding slices). Indeed, as Dylan mentions, there are some other tools that would do the same (like mricro), but they don't support minc. Therefore, a minc tool would be easier and more reliable than the back and forth data conversion with possible flaws in it (especially in calculating the exact world coordinates in co-registered volumes with different dimensions). Thanks in advance, Kuan Kho Kuan H. Kho Rudolf Magnus Institute of Neuroscience Dept. of Neurosurgery and Psychiatry G03.124 section: Functional Neuroimaging University Medical Center Utrecht P.O.Box 85500 3508 GA Utrecht The Netherlands Phone: +31-30-2507969/2507977 Fax : +31-30-2542100 email: k.h.kho@azu.nl From rotor@cmr.uq.edu.au Wed Jul 14 04:33:04 2004 From: rotor@cmr.uq.edu.au (Andrew Janke) Date: Wed Jul 14 03:33:04 2004 Subject: [MINC-users] Minc to analyze methods In-Reply-To: References: Message-ID: On Mon, 12 Jul 2004, Dylan WAGNER wrote: > I've been wanting to try out some different visualization > apps which don't support minc (mricro, mri3dX). I've been having a > terrible time trying to convert functional minc data to analyze (the > anatomicals pose no real problem). > > Installed ana2mnc/mnc2ana on linux, seems to work, however with > functional data its output is garbled. The slices seem shifted up > and down relative to each other, like a comb effect. I tried forcing an > orientation which didn't change things. I can really only comment on mnc2ana. I have found that various analyze reading programs expect analyze files to be in a standard orientation. Perhaps try this: mincreshape -dimorder time,zspace,yspace,xspace in.mnc out.mnc before converting to analyze. (ie: the "standard" dimension ordering expected by analyze. -- Andrew Janke ( rotorATcmr.uq.edu.au || www.cmr.uq.edu.au/~rotor ) Australia->University of Queensland->Centre for Magnetic Resonance W: +61 7 3232 7254 || H: +61 7 3800 4042 || M: +61 4 2138 8581 From haytham@umich.edu Wed Jul 14 14:14:04 2004 From: haytham@umich.edu (haytham@umich.edu) Date: Wed Jul 14 13:14:04 2004 Subject: [MINC-users] ANIMAL+INSECT In-Reply-To: <200407141601.i6EG14Z815921794@shadow.bic.mni.mcgill.ca> References: <200407141601.i6EG14Z815921794@shadow.bic.mni.mcgill.ca> Message-ID: <1089825193.40f569a96adc2@mail.umich.edu> I am trying to follow the procedure to automatically segment and label the volume that is described in Dr. Collins paper titled "ANIMAL+INSECT: Improved Cortical Structure Segmentation." I was able to do the following steps: 1. Linear Registration (MRI to Stereotaxic Space) (mritotal) 2. Image Intensity Non-Uniformity Correction (N3 Package) 3. Nonlinear Registration With Average Brain Target (with nlfit/animal) 4. Identify Grey Matter, White Matter and CSF Voxels (classify package) The last step (5) of the procedure is to take the output of the linear and non-linear registration and combine the classified data to achieve a segmentation. Ok, I know stx_segment accomplishes this last crutial step. Where is this script located? I downloaded and installed all the software avaialble from http://www.bic.mni.mcgill.ca/software/distribution/ and I can not find the script. I am trying to validate some of the results mentioned in this published paper. On more thing that I dont understand: Animal stands for Automatic Nonlinear Image Matching and Anatomical Labeling. The animal package that is available to download (to my knowledge) includes only the "Automatic Nonlinear Image Matching" part. Where are the "Anatomical Labeling" routines? Can someone HELP me please? Thanks in advance -haytham From yves.roy@umontreal.ca Thu Jul 15 18:07:04 2004 From: yves.roy@umontreal.ca (Roy Yves) Date: Thu Jul 15 17:07:04 2004 Subject: [MINC-users] Installing Register on Win XP Message-ID: Hello: I downloaded the MNI-Register for Windows 95, 98, NT 4.0, and 2000, thinking it would work on XP Pro from http://www.bic.mni.mcgill.ca/users/fmorales/. The package contains 3 dlls and an executable: GLU32.DLL glut32.dll OPENGL32.DLL register.exe and... nothing happens when I run the executable (and there is absolutely no installation notes or README around to guide me) so I wonder what I should do? I also got the compiled register+Display package from ftp://ftp.bic.mni.mcgill.ca/pub/register+Display/compiled/ but, again, where should I put those files and what kind of normal behavior should I expect... Thanks for you help. Yves From dwagne@bic.mni.mcgill.ca Thu Jul 15 18:29:04 2004 From: dwagne@bic.mni.mcgill.ca (Dylan WAGNER) Date: Thu Jul 15 17:29:04 2004 Subject: [MINC-users] Installing Register on Win XP In-Reply-To: Message-ID: Hi, For register on windows you'll need the -rgb switch. Ie: register -rgb x.mnc y.mnc It's quite buggy, mind the buttons because you can only click on them once and then they stay stuck forcing a relaunch of register should you need to click them again. As for register on linux I find it incredibly slow, does anyone else have this problem? The windows and unix versions are much quicker. However in my case it could be that as I'm running linux in vmware and it's just not able to access the opengl support on my video card which I assume it uses to speed things up. Oddly Mri3dX runs smoothly on linux through vmware so who knows. Best, From jharlap@bic.mni.mcgill.ca Thu Jul 15 19:37:04 2004 From: jharlap@bic.mni.mcgill.ca (Jonathan Harlap) Date: Thu Jul 15 18:37:04 2004 Subject: [MINC-users] new version of dicom perl library Message-ID: <6F04E86D-D6AF-11D8-A41F-000A95B21886@bic.mni.mcgill.ca> For those on both minc-users and bic-users, my apologies for cross-posting... A new version of my branch of DICOMperl is now available, which adds support for floats and doubles (dicom value representation FL and FD, which previously were not supported), and officially does not support sequences (dicom value representation SQ, which previously was not supported but caused the library to hang or crash). This impacts on the functionality of dicom3_to_minc and get_dicom_info, both of which have not changed - they merely inherit the improvement by using the new library, as will any other software written to use my branch of DICOMperl. The updated version of the library is available from my web site at http://www.bic.mni.mcgill.ca/~jharlap/dicom/ BIC users can run dicom3_to_minc and get_dicom_info directly from my public bin directory (they no longer need to set the environment variable PERL5LIB) by simply running: ~jharlap/public/bin/dicom3_to_minc -help or ~jharlap/public/bin/get_dicom_info -help Cheers, Jon From rotor@cmr.uq.edu.au Thu Jul 15 22:59:03 2004 From: rotor@cmr.uq.edu.au (Andrew Janke) Date: Thu Jul 15 21:59:03 2004 Subject: [MINC-users] Installing Register on Win XP In-Reply-To: References: Message-ID: On Thu, 15 Jul 2004, Dylan WAGNER wrote: > It's quite buggy, mind the buttons because you can only click on > them once and then they stay stuck forcing a relaunch of register should > you need to click them again. These versions are getting quite old however. The approach I use to get the mni tools onto Windows is via cygwin. Once you have it installed and working (and OpenGL working via the links to the Windows core openGL) You should be able to download this statically built binary and run register without running cygwin-X as it will use Windows native OpenGL. http://www.cmr.uq.edu.au/~rotor/distro/register-cygwin-binary-2004-06-01.exe.gz Let us know how you get on. > As for register on linux I find it incredibly slow, does anyone > else have this problem? The windows and unix versions are much quicker. > However in my case it could be that as I'm running linux in vmware and > it's just not able to access the opengl support on my video card which I > assume it uses to speed things up. Oddly Mri3dX runs smoothly on linux > through vmware so who knows. VMware only emulates a very basic video card with no OpenGL support (and no pass-through to the underlying OpenGL calls within Windows). Thus things will be dog-slow as you will be running register via Mesa. Why Mri3dx runs fast is anyones guess, perhaps it doesn't use OpenGL and instead uses SDL or some other method. -- Andrew Janke ( rotorATcmr.uq.edu.au || www.cmr.uq.edu.au/~rotor ) Australia->University of Queensland->Centre for Magnetic Resonance W: +61 7 3232 7254 || H: +61 7 3800 4042 || M: +61 4 2138 8581 From nkovacev@sickkids.ca Mon Jul 19 12:55:04 2004 From: nkovacev@sickkids.ca (Natasha Kovacevic) Date: Mon Jul 19 11:55:04 2004 Subject: [MINC-users] mincblur bug Message-ID: <1090252286.3057.35.camel@lego.ocgc.ca> --=-3PX8crcFjT+4yg1Em+D5 Content-Type: text/plain Content-Transfer-Encoding: 7bit Greetings to all, Here at MICe we have discovered a bug in mincblur. The bug became obvious when we applied it to cropped mouse brain images which have the property that the minimum value in the image is some positive number. The culprit is function apodize_data (in file mincblur/apodize_data.c). The scale factor which is applied to near edge voxels seems to assume that the range of data is from 0 to some positive number. John Sled and I had some discussions on how to fix this. He has written a patch which fixes this by introducing an offset. This patched version is attached bellow. Its intent is to minimally disrupt the known behavior of mincblur. On the other hand, there is another way of fixing this bug: define offset as the minimum value within the entire image (this would slow things down because true min would have to be calculated first). The effect would be to smooth edge discontinuities rather then to apodize. We will patch our version, but would like to know the thoughts of mni_autoreg developers so that we can have the same versions. Best regards, Natasha --=-3PX8crcFjT+4yg1Em+D5 Content-Disposition: attachment; filename=apodize_data.c Content-Type: text/x-c; name=apodize_data.c; charset=UTF-8 Content-Transfer-Encoding: 7bit /* ----------------------------- MNI Header ----------------------------------- @NAME : apodize data.c @INPUT : volume of data + depth of apodization on each surface. @CREATED : Mon Jul 5 13:35:04 EST 1993 Louis Collins @MODIFIED : ---------------------------------------------------------------------------- */ #include #include #include #define GWID1 0.75 #define GWID2 0.9 /************************************************************/ /* return the value of the normal distribution (that has a */ /* normalized height of 1.0, given sigma, x and mu */ /* all in mm */ /************************************************************/ private float normal_height(float fwhm,float mu,float x) { float sigma,t2,f; sigma = fwhm/2.35482; if (sigma==0) { if (x==mu) f = 1.0; else f = 0; } else { t2 = (x-mu)*(x-mu)/(2*sigma*sigma); f = exp(-t2); } return(f); } public void apodize_data(Volume data, double xramp1,double xramp2, double yramp1,double yramp2, double zramp1,double zramp2) { int num_steps, row,col,slice; float scale1,scale2, scale; Real valid_min, valid_max, real_min, real_max, real_value, voxel_value, offset; int sizes[3]; Real step[3]; get_volume_sizes(data, sizes); get_volume_separations(data, step); get_volume_voxel_range(data, &valid_min, &valid_max); get_volume_real_range(data, &real_min, &real_max); /* compute offset so that apodization does not produce values outside of real_min, real_max range */ if (real_min > 0.0) { offset = real_min; } else if (real_max < 0.0) { offset = real_max; } else { offset = 0.0; } if (zramp1 > ABS(step[Z])/2) { /* number of slices to be apodized */ num_steps = ROUND( 1.25*zramp1/ABS(step[Z]) + 0.5); if (num_steps>ABS(sizes[Z])) { print_error_and_line_num("FWHM is greater than slice dimension\n",__FILE__, __LINE__); } for_less(slice, 0, num_steps) { scale1 = normal_height( zramp1*GWID1, 1.25*zramp1, (float)slice*ABS(step[Z])); scale2 = normal_height( zramp1*GWID2, 0.0, (float)(num_steps - 1 - slice)*ABS(step[Z])); scale = INTERPOLATE( slice/(num_steps-1.0) , scale1, scale2); for_less(row, 0, sizes[Y]) { for_less(col, 0, sizes[X]) { GET_VOXEL_3D(voxel_value, data, col, row, slice); if (voxel_value >= valid_min && voxel_value <= valid_max) { real_value = CONVERT_VOXEL_TO_VALUE(data, voxel_value); real_value = (real_value - offset) * scale + offset; voxel_value = CONVERT_VALUE_TO_VOXEL(data, real_value); SET_VOXEL_3D( data, col, row, slice, voxel_value); } } } } } if (zramp2 > ABS(step[Z])/2 ) { /* number of slices to be apodized */ num_steps = ROUND( 1.25*zramp2/ABS(step[Z]) + 0.5); if (num_steps>sizes[Z]) { print_error_and_line_num("FWHM is greater than slice dimension\n",__FILE__, __LINE__); } for_less(slice, 0, num_steps) { scale1 = normal_height( zramp2*GWID1, 1.25*zramp2, (float)slice*ABS(step[Z])); scale2 = normal_height( zramp2*GWID2, 0.0, (float)(num_steps - 1 - slice)*ABS(step[Z])); scale = INTERPOLATE( slice/(num_steps-1.0) , scale1, scale2); for_less(row, 0, sizes[Y]) { for_less(col, 0, sizes[X]) { GET_VOXEL_3D(voxel_value, data, col, row, sizes[Z]-1-slice); if (voxel_value >= valid_min && voxel_value <= valid_max) { real_value = CONVERT_VOXEL_TO_VALUE(data, voxel_value); real_value = (real_value - offset) * scale + offset; voxel_value = CONVERT_VALUE_TO_VOXEL(data, real_value); SET_VOXEL_3D( data, col, row, sizes[Z]-1-slice, voxel_value); } } } } } if (yramp1 > ABS(step[Y])/2 ) { /* number of rows to be apodized */ num_steps = ROUND( 1.25*yramp1/ABS(step[Y]) + 0.5); if (num_steps>sizes[Y]) { print_error_and_line_num("FWHM is greater than col dimension\n",__FILE__, __LINE__); } for_less(row, 0, num_steps) { scale1 = normal_height( yramp1*GWID1, 1.25*yramp1, (float)row*ABS(step[Y])); scale2 = normal_height( yramp1*GWID2, 0.0, (float)(num_steps - 1 - row)*ABS(step[Y])); scale = INTERPOLATE( row/(num_steps-1.0) , scale1, scale2); for_less(slice, 0, sizes[Z]) { for_less(col, 0, sizes[X]) { GET_VOXEL_3D(voxel_value, data, col, row, slice); if (voxel_value >= valid_min && voxel_value <= valid_max) { real_value = CONVERT_VOXEL_TO_VALUE(data, voxel_value); real_value = (real_value - offset) * scale + offset; voxel_value = CONVERT_VALUE_TO_VOXEL(data, real_value); SET_VOXEL_3D( data, col, row, slice, voxel_value); } } } } } if (yramp2 > ABS(step[Y])/2) { /* number of rows to be apodized */ num_steps = ROUND( 1.25*yramp2/ABS(step[Y]) + 0.5); if (num_steps>sizes[Y]) { print_error_and_line_num("FWHM is greater than col dimension\n",__FILE__, __LINE__); } for_less(row, 0, num_steps) { scale1 = normal_height( yramp2*GWID1, 1.25*yramp2, (float)row*ABS(step[Y])); scale2 = normal_height( yramp2*GWID2, 0.0, (float)(num_steps - 1 - row)*ABS(step[Y])); scale = INTERPOLATE( row/(num_steps-1.0) , scale1, scale2); for_less(slice, 0, sizes[Z]) { for_less(col, 0, sizes[X]) { GET_VOXEL_3D(voxel_value, data, col, sizes[Y]-1-row, slice); if (voxel_value >= valid_min && voxel_value <= valid_max) { real_value = CONVERT_VOXEL_TO_VALUE(data, voxel_value); real_value = (real_value - offset) * scale + offset; voxel_value = CONVERT_VALUE_TO_VOXEL(data, real_value); SET_VOXEL_3D( data, col, sizes[Y]-1-row, slice, voxel_value); } } } } } if (xramp1 > ABS(step[X])/2) { /* number of slices to be apodized */ num_steps = ROUND( 1.25*xramp1/ABS(step[X]) + 0.5); if (num_steps>sizes[X]) { print_error_and_line_num("FWHM is greater than col dimension\n",__FILE__, __LINE__); } for_less(col, 0, num_steps) { scale1 = normal_height( xramp1*GWID1, 1.25*xramp1, (float)col*ABS(step[X])); scale2 = normal_height( xramp1*GWID2, 0.0, (float)(num_steps - 1 - col)*ABS(step[X])); scale = INTERPOLATE( col/(num_steps-1.0) , scale1, scale2); for_less(slice, 0, sizes[Z]) { for_less(row, 0, sizes[Y]) { GET_VOXEL_3D( voxel_value, data, col, row, slice); if (voxel_value >= valid_min && voxel_value <= valid_max) { real_value = CONVERT_VOXEL_TO_VALUE(data, voxel_value); real_value = (real_value - offset) * scale + offset; voxel_value = CONVERT_VALUE_TO_VOXEL(data, real_value); SET_VOXEL_3D( data, col, row, slice, voxel_value); } } } } } if (xramp2 > ABS(step[X])/2) { /* number of slices to be apodized */ num_steps = ROUND( 1.25*xramp2/step[X] + 0.5); if (num_steps>sizes[X]) { print_error_and_line_num("FWHM is greater than col dimension\n",__FILE__, __LINE__); } for_less(col, 0, num_steps) { scale1 = normal_height( xramp2*GWID1, 1.25*xramp2, (float)col*ABS(step[X])); scale2 = normal_height( xramp2*GWID2, 0.0, (float)(num_steps - 1 - col)*ABS(step[X])); scale = INTERPOLATE( col/(num_steps-1.0) , scale1, scale2); for_less(slice, 0, sizes[Z]) { for_less(row, 0, sizes[Y]) { GET_VOXEL_3D( voxel_value, data, sizes[X]-1-col, row, slice); if (voxel_value >= valid_min && voxel_value <= valid_max) { real_value = CONVERT_VOXEL_TO_VALUE(data, voxel_value); real_value = (real_value - offset) * scale + offset; voxel_value = CONVERT_VALUE_TO_VOXEL(data, real_value); SET_VOXEL_3D( data, sizes[X]-1-col, row, slice, voxel_value); } } } } } } --=-3PX8crcFjT+4yg1Em+D5-- From tguo@imaging.robarts.ca Mon Jul 19 17:31:04 2004 From: tguo@imaging.robarts.ca ((Jessie) Ting Guo) Date: Mon Jul 19 16:31:04 2004 Subject: [MINC-users] new mritotal References: <1090252286.3057.35.camel@lego.ocgc.ca> Message-ID: <001101c46dcf$4b4c3580$c32914c6@irus.robarts.ca> Hello everyone, Could anyone please send me an image which was nonlinearly registered by mritotal? I downloaded and installed the latest version of mni-autoreg last Friday, but the result didn't very desirable to me. Although the new program is much faster than before, the image after nonlinear registration looked much worse than the before. There was no error message displayed during the whole process, so I am wondering what the problem should be. Thank you very much in advance. Jessie From yves.roy@umontreal.ca Wed Jul 21 13:34:04 2004 From: yves.roy@umontreal.ca (Roy Yves) Date: Wed Jul 21 12:34:04 2004 Subject: [MINC-users] DICOM (MOSAIC) to MINC conversion Message-ID: Hello: Is there anyone around knowing about solution avenues for the following questions on DICOM to MINC conversion: 1- Is there a DICOM (MOSAIC) to MINC converters available somewhere? Or do I have to do the conversion DICOM -> ANALYSE -> MINC (which doesn't appear to be a resonnable solution to me ==> See question 5 below). ==> I am about to look at and evaluate dicom3_to_minc and LONI Debabeler... (and I will report my results on the REPRIC web site, conversion tools page http://www.rsmnq.ca/repric/en/conversion_software.htm, and your comments are also more than welcome). 2- On one of the BIC's machine, I simply ran the installed dicom_to_minc on a (supposedly DICOM-MOSAIC, ==> See question 4 below) image to obtain an output MINC image of dimensions 384 x 384 x 1 (as given by mincinfo) pretty much all black (the conversion didn't work, --but I did not get any error messages...). How can these numbers make sense knowing that the original DICOM image were (supposedly) (64 x 64) x 28 slices ? 3- Is the *new* dicom3_to_minc supporting the conversion from DICOM-mosaic to MINC ? I just cannot find that info on the dicom3_to_minc page (http://www.bic.mni.mcgill.ca/~jharlap/dicom/#DICOMperl) (I am in the process of installig dicom3_to_minc, but ran into some problems... ==> See question 6 below. 4- Given an image (which is assumed to be) in DICOM format (say the info about the origin was lost...): - How can the true format of the image be found (the flavor, DICOMDIR or MOSAIC, the dimensions, and other reflective info like that), i.e. what are the available tools allowing that? I guess DICOMperl (http://dicomperl.sourceforge.net/, http://www.bic.mni.mcgill.ca/~jharlap/dicom/#DICOMperl, ) is one of them ? - I read somewhere (http://research.bmap.ucla.edu/MRIFAQ.html) that the latest version of SPM is reportedly able to handle the mosaic format. Anyone knowing whether it is true? Would it be a mosaicised *Analyse* format or *DICOM* supported (DICOM does not work for me under SPM2...) ? 5- Assuming that in order to obtain MINC images I need to first convert the DICOM to ANALYSE, which tools are people here using (your suggestions/remarks)? - LONI Debabeler (Java), - xmedcom (C), - epidcm2analyse.m , mprdcm2analyse.m (Matlab scripts available via the REPRIC web site http://www.rsmnq.ca/repric/en/conversion_software.htm). 6- dicom3_to_minc requires the module DICOMperl. Installing this module consists in 4 steps: 1. perl Makefile.PL 2. make 3. make test 4. (as root) make install I got the following error in step 3: ____________________________________________________ [yves@localhost DICOM-1.003]$ perl Makefile.PL Checking if your kit is complete... Looks good Writing Makefile for DICOM [yves@localhost DICOM-1.003]$ make cp lib/DICOM/Element.pm blib/lib/DICOM/Element.pm cp lib/DICOM/Private.pm blib/lib/DICOM/Private.pm cp lib/DICOM/Fields.pm blib/lib/DICOM/Fields.pm cp lib/DICOM.pm blib/lib/DICOM.pm cp lib/DICOM/VRfields.pm blib/lib/DICOM/VRfields.pm Manifying blib/man3/DICOM.3pm [yves@localhost DICOM-1.003]$ make test PERL_DL_NONLAZY=1 /usr/bin/perl "-MExtUtils::Command::MM" "-e" "test_harness(0, 'blib/lib', 'blib/arch')" t/*.t make: *** [test_dynamic] Segmentation fault ------------------------------------------------------- Anyone has a clue on what might be the problem. Many thanks. Yves From pgravel@bic.mni.mcgill.ca Wed Jul 21 16:46:04 2004 From: pgravel@bic.mni.mcgill.ca (Paul GRAVEL) Date: Wed Jul 21 15:46:04 2004 Subject: [MINC-users] Registration of MRIs in stx space Message-ID: Hi all, Does anybody have a program/routine to calculate inter-subjects anatomical variability, e.g. between Caudate, Putamen, etc., in mm or voxels when all the subjects' MRI are registered in stx space? The reason for this question is that before a statistical analysis we do some smoothing using a Gaussian Kernel. One of the reason for this smoothing (among others) is to reduce anatomical variability between subjects. Therefore, I am wondering if there is a way to quantify this variability. Thank you very much. Best Regards, Paul ______________________________ Paul Gravel Neurobiological Psychiatry Unit McGill University 1033 Pine Avenue West Montreal, Quebec, Canada, H3A 1A1 Phone: (514) 398-7301 Fax: (514) 398-4866 From rotor@cmr.uq.edu.au Thu Jul 22 01:46:03 2004 From: rotor@cmr.uq.edu.au (Andrew Janke) Date: Thu Jul 22 00:46:03 2004 Subject: [MINC-users] Registration of MRIs in stx space In-Reply-To: References: Message-ID: On Wed, 21 Jul 2004, Paul GRAVEL wrote: > Does anybody have a program/routine to calculate inter-subjects anatomical > variability, e.g. between Caudate, Putamen, etc., in mm or voxels when > all the subjects' MRI are registered in stx space? Assuming you already have segmented these structures in your population accurately, you could simply take the sum of the voxel-wise variance (or standard error) across each of the sub-structures. -- Andrew Janke ( rotorATcmr.uq.edu.au || www.cmr.uq.edu.au/~rotor ) Australia->University of Queensland->Centre for Magnetic Resonance W: +61 7 3232 7254 || H: +61 7 3800 4042 || M: +61 4 2138 8581 From rotor@cmr.uq.edu.au Thu Jul 22 02:16:04 2004 From: rotor@cmr.uq.edu.au (Andrew Janke) Date: Thu Jul 22 01:16:04 2004 Subject: [MINC-users] DICOM (MOSAIC) to MINC conversion In-Reply-To: References: Message-ID: On Wed, 21 Jul 2004, Roy Yves wrote: > 1- Is there a DICOM (MOSAIC) to MINC converters available somewhere? Or do I > have to do the conversion DICOM -> ANALYSE -> MINC (which doesn't appear to be > a resonnable solution to me ==> See question 5 below). > > ==> I am about to look at and evaluate dicom3_to_minc and LONI Debabeler... > (and I will report my results on the REPRIC web site, conversion tools page > http://www.rsmnq.ca/repric/en/conversion_software.htm, and your comments are > also more than welcome). As far as I am aware neither dicom_to_minc or dicom3_to_minc will help you here. However if you happen to have Siemens (it will work with no other mosaic files!) mosaic files then I have hacked together something that reads the SIEMENS "ASC_CONV" header within the DICOM header and uses this to convert the data. http://www.cmr.uq.edu.au/~rotor/software/progs/siemens_mosaic2mnc I'd be 'interested' if it works for you. :) > 2- On one of the BIC's machine, I simply ran the installed dicom_to_minc on a > (supposedly DICOM-MOSAIC, ==> See question 4 below) image to obtain an output > MINC image of dimensions 384 x 384 x 1 (as given by mincinfo) pretty much all > black (the conversion didn't work, --but I did not get any error messages...). > How can these numbers make sense knowing that the original DICOM image were > (supposedly) (64 x 64) x 28 slices ? 384 = 64 x 6. the "mosaic" format is a very literal mosiac of images. I suspect the ouput of dicom3_to_minc will be a nice little array of 6x6 images in each 'slice'. Take a look at the guts of siemens_mosaic2mnc it is little more than a wrapper that then chops the resulting converted minc file up into bits. > 3- Is the *new* dicom3_to_minc supporting the conversion from DICOM-mosaic to > MINC ? Not that I know of. Mosaic format is eseentially yet another hack perpetrated upon us due to the limitations of DICOM (2D files only) and since fMRI makes lots of them a few files are shoe-horned into one. > 4- Given an image (which is assumed to be) in DICOM format (say the info about > the origin was lost...): > > - How can the true format of the image be found (the flavor, DICOMDIR or > MOSAIC, the dimensions, and other reflective info like that), i.e. what are > the available tools allowing that? This ofter depends on the source of the DICOM image :(. I doubt DICOMDIR will help you here, it typically is a catalog of the files in the DICOM directory with a bit of header info included (scan type, sequence#, patient etc). > - I read somewhere (http://research.bmap.ucla.edu/MRIFAQ.html) that the latest > version of SPM is reportedly able to handle the mosaic format. Anyone knowing > whether it is true? Would it be a mosaicised *Analyse* format or *DICOM* > supported (DICOM does not work for me under SPM2...) ? There is no such thing as ANALYZE mosaic that I know of. (please no!) With respect to SPM reading mosaic, I suspect it can via some plug-in. The other option is of course xmedcon. > I got the following error in step 3: > PERL_DL_NONLAZY=1 /usr/bin/perl "-MExtUtils::Command::MM" "-e" "test_harness(0, > 'blib/lib', 'blib/arch')" t/*.t > make: *** [test_dynamic] Segmentation fault wierd, which platform? However this may be somewhat benign, does the make install step work? -- Andrew Janke ( rotorATcmr.uq.edu.au || www.cmr.uq.edu.au/~rotor ) Australia->University of Queensland->Centre for Magnetic Resonance W: +61 7 3232 7254 || H: +61 7 3800 4042 || M: +61 4 2138 8581 From yves.roy@umontreal.ca Thu Jul 22 11:38:06 2004 From: yves.roy@umontreal.ca (Roy Yves) Date: Thu Jul 22 10:38:06 2004 Subject: [MINC-users] DICOM (MOSAIC) to MINC conversion Message-ID: Thanks. Here is some extra information about all that... > However if you happen to have Siemens (it will work with no other > mosaic > files!) mosaic files then I have hacked together something > that > reads the SIEMENS > "ASC_CONV" header within the DICOM header and uses this to convert the data. > > http://www.cmr.uq.edu.au/~rotor/software/progs/siemens_mosaic2mnc > >I'd be 'interested' if it works for you. :) Will try it out soon and let you know on this forum, and on the REPRIC web site as well, conversion tool page: http://www.rsmnq.ca/repric/en/conversion_software.htm which will undergo major updates in the next few days. I also found out (thanks to Mike Ferreira) that Rick Hoge's dcm2mnc seems to be doing the job (still need to verify my results). See http://www.bic.mni.mcgill.ca/~mferre/dcm2mnc_help.html > I got the following error in step 3: > PERL_DL_NONLAZY=1 /usr/bin/perl "-MExtUtils::Command::MM" > "-e""test_harness(0, > 'blib/lib', 'blib/arch')" t/*.t > make: *** [test_dynamic] Segmentation fault wierd, which platform? As for the above error during the DICOMperl installation, well, my mistake, since it finally all worked ok when I installed as a superuser... :-| Many thanks to all of you. Yves From dwagne@bic.mni.mcgill.ca Mon Jul 26 18:45:04 2004 From: dwagne@bic.mni.mcgill.ca (Dylan WAGNER) Date: Mon Jul 26 17:45:04 2004 Subject: [MINC-users] Minc to analyze methods In-Reply-To: Message-ID: On Wed, 14 Jul 2004, Andrew Janke wrote: > > I can really only comment on mnc2a> > I have found that various analyze reading programs expect analyze files to be in > a standard orientation. Perhaps try this: > > mincreshape -dimorder time,zspace,yspace,xspace in.mnc out.mnc > > before converting to analyze. (ie: the "standard" dimension ordering expected > by analyze. Many thanks for the mincreshape tip. It did the trick. Still have to flip top/bottom in mricrow, but that's no big deal. I'll read up on mincreshape and see if I can flip them beforehand so as to avoid having to use mricro. One final question for people on BIC at the mni, how are you using ana2mnc? I've still not found make_links to generate the mnc2ana symbolic link. Or is mnc2ana already there for everyon but stored outside my path? Best, From rotor@cmr.uq.edu.au Mon Jul 26 20:49:04 2004 From: rotor@cmr.uq.edu.au (Andrew Janke) Date: Mon Jul 26 19:49:04 2004 Subject: [MINC-users] Minc to analyze methods In-Reply-To: References: Message-ID: On Mon, 26 Jul 2004, Dylan WAGNER wrote: > Many thanks for the mincreshape tip. It did the trick. Still have to > flip top/bottom in mricrow, but that's no big deal. I'll read up on > mincreshape and see if I can flip them beforehand so as to avoid having to > use mricro. I suspect this means that your step in Z is also -ve. You can flip dimensions using minreshape also, note that when you specify +direction to mincreshape it will only flip "image" dimensions by default as opposed to the slice direction. You can force mincreshape to flip all dimension such that they are all +ve as such (from the man page) ie: mincreshape in.mnc out.mnc -dimorder zspace,yspace,xspace \ +direction -dimsize zspace=-1 > One final question for people on BIC at the mni, how are you using > ana2mnc? I've still not found make_links to generate the mnc2ana symbolic > link. Or is mnc2ana already there for everyon but stored outside my path? make_links should really only be run by the person who installs ana2mnc. It does nothing more that this: ln -s ana2mnc mnc2ana ln -s ana2mnc ana_show ln -s .... -- Andrew Janke ( rotorATcmr.uq.edu.au || www.cmr.uq.edu.au/~rotor ) Australia->University of Queensland->Centre for Magnetic Resonance W: +61 7 3232 7254 || H: +61 7 3800 4042 || M: +61 4 2138 8581 From petersv@bic.mni.mcgill.ca Tue Jul 27 23:12:03 2004 From: petersv@bic.mni.mcgill.ca (Peter SAVADIJIEV) Date: Tue Jul 27 22:12:03 2004 Subject: [MINC-users] minc output problem Message-ID: Hi, I'm a new user of minc (and of this mailing list). I have a question, and I hope that someone will be able to help me. When I attempt to write my output minc files to disk I get an error. I tried different things, thinking that it may be a problem with my program, but to no avail. Finally, as a check, I decided to compile and run the sample code they give on the minc documentation website: http://www.bic.mni.mcgill.ca/~david/volume_io/section2_7_5.html I kept the code exactly the same, and I used one of the mnc files that I have as input. I still got exactly the same error, which makes me believe that it's not a problem with the code as such. The error message reads: nccreate: Bad Flag micreate: MINC package entry point Error: opening MINC file "output.mnc". Can anyone clarify what the cause of this error might be? The output file doesn't exist, so it cannot be that it refuses to overwrite an already existing file. Thanks a lot, Peter From jharlap@bic.mni.mcgill.ca Sat Jul 31 17:01:04 2004 From: jharlap@bic.mni.mcgill.ca (Jonathan Harlap) Date: Sat Jul 31 16:01:04 2004 Subject: [MINC-users] new version of dicom perl library Message-ID: <53691AFC-E32C-11D8-8BB7-000A95B21886@bic.mni.mcgill.ca> For those on both minc-users and bic-users, my apologies for cross-posting... Another new version of my branch of DICOMperl is now available, which improves handling of sequences (dicom value representation SQ, which previously was not supported but caused the library to die with an error message). Now any dicom sequences will not be read, and their values will be set to 'skipped' - but parsing the rest of the dicom file will continue unhindered. I have heard very few users request sequence support, so I do not expect that I will be putting in the time to properly read sequences anytime soon... If there is a groundswell of users who need the data in their sequences, I may reconsider, so please do let me know if you need it. This impacts on the functionality of dicom3_to_minc and get_dicom_info, both of which have not changed - they merely inherit the improvement by using the new library, as will any other software written to use my branch of DICOMperl. The updated version of the library is available from my web site at http://www.bic.mni.mcgill.ca/~jharlap/dicom/ BIC users can run dicom3_to_minc and get_dicom_info directly from my public bin directory (they no longer need to set the environment variable PERL5LIB) by simply running: ~jharlap/public/bin/dicom3_to_minc -help or ~jharlap/public/bin/get_dicom_info -help Cheers, Jon