From minc-development@bic.mni.mcgill.ca Mon Jan 5 03:02:24 2004 From: minc-development@bic.mni.mcgill.ca (Peter NEELIN) Date: Sun, 4 Jan 2004 22:02:24 -0500 Subject: [MINC-development] nu_correct on linux In-Reply-To: Message-ID: On Tue, 23 Dec 2003, Richard Boyes wrote: > when i try nu_correct, it jumps out straight away, > saying the field change is 1E-27. this has happened > for multiple images with bad bias fields, which doesn't > seem correct. If I recall correctly, nu_correct had some difficulties with masks that had ranges that did not correspond to its expectations (is that correct, John?). This is just a guess, but try using the -scan_range option for the mask images as well: #Mask file - no need to swap bytes rawtominc -byte -obyte -clobber -input ./bmask00000.img -coronal \ -xstep 0.9766 -ystep 1.8000 -zstep 0.9766 \ -orange 0 255 -scan_range ./bmask00000.mnc 120 256 256 Alternatively, replace the -orange option with "-range 0 255 -real_range 0 255" and do not use -scan_range. Peter ---- Peter Neelin (neelin@bic.mni.mcgill.ca) From rboyes@dementia.ion.ucl.ac.uk Tue Jan 6 09:42:11 2004 From: rboyes@dementia.ion.ucl.ac.uk (Richard Boyes) Date: Tue, 6 Jan 2004 09:42:11 -0000 Subject: [MINC-development] nu_correct on linux In-Reply-To: Message-ID: dear peter, thanks for your feedback - unfortunately it crops up with a different error, this time: rboyes@gyrus:~/cvs/bias-correct-regress/custom-sw/regress/data/junk rawtominc -byte -obyte -clobber -input ./bmask00000.img -coronal -xstep 0.9766 -ystep 1.8000 -zstep 0.9766 -range 0 255 -real_range 0 255 ./bmask00000.mnc 120 256 256 rboyes@gyrus:~/cvs/bias-correct-regress/custom-sw/regress/data/junk nu_correct -clobber -mask ./bmask00000.mnc ./00000.mnc /correct00000.mnc -stop 0.0005 -fwhm 0.075 -distance 100 -iterations 350 -mapping_dir . -shrink 3 Transforming slices:.........................................Done No points were chosen by the specified criteria resample_labels: crashed while running extracttag (termination status=256) nu_estimate_np_and_em: crashed while running resample_labels (termination status=256) nu_correct: crashed while running nu_estimate_np_and_em (termination status=256) i've tried running nu_correct without the mask (below), but i'm getting the problem of 1e-27 field change again. any other ideas, or can i send you any other information? rboyes@gyrus:~/cvs/bias-correct-regress/custom-sw/regress/data/junk nu_correct -clobber ./00000.mnc ./correct00000.mnc -stop 0.0005 -fwhm 0.075 -distance 100 -iterations 350 -mapping_dir . -shrink 3 Processing:.........................................Done Not implemented yet in cache_volume_range_has_changed() Not implemented yet in cache_volume_range_has_changed() Number of iterations: 1 CV of field change: 7.88338e-27 Transforming slices:.........................................Done 256+0 records in 256+0 records out Not implemented yet in cache_volume_range_has_changed() Not implemented yet in cache_volume_range_has_changed() Transforming slices:..................................................................... ...................................................Done thanks, richard. > -----Original Message----- > From: minc-development-admin@bic.mni.mcgill.ca > [mailto:minc-development-admin@bic.mni.mcgill.ca]On Behalf Of Peter > NEELIN > Sent: 05 January 2004 03:02 > To: Richard Boyes > Cc: MINC > Subject: Re: [MINC-development] nu_correct on linux > > > On Tue, 23 Dec 2003, Richard Boyes wrote: > > > when i try nu_correct, it jumps out straight away, > > saying the field change is 1E-27. this has happened > > for multiple images with bad bias fields, which doesn't > > seem correct. > > If I recall correctly, nu_correct had some difficulties with masks that > had ranges that did not correspond to its expectations (is that correct, > John?). This is just a guess, but try using the -scan_range option for the > mask images as well: > > #Mask file - no need to swap bytes > rawtominc -byte -obyte -clobber -input ./bmask00000.img -coronal \ > -xstep 0.9766 -ystep 1.8000 -zstep 0.9766 \ > -orange 0 255 -scan_range ./bmask00000.mnc 120 256 256 > > Alternatively, replace the -orange option with > "-range 0 255 -real_range 0 255" and do not use -scan_range. > > Peter > ---- > Peter Neelin (neelin@bic.mni.mcgill.ca) > > _______________________________________________ > MINC-development mailing list > MINC-development@bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-development From minc-development@bic.mni.mcgill.ca Wed Jan 7 16:52:32 2004 From: minc-development@bic.mni.mcgill.ca (John G. Sled) Date: Wed, 7 Jan 2004 10:52:32 -0600 Subject: [MINC-development] nu_correct on linux In-Reply-To: References: Message-ID: <20040107165232.GA13810@sickkids.ca> Dear Richard, The mask that is used by N3 is the intersection of that part of the volume with values greater than 1.0 and the part of the mask with values greater than 0. The N3 algorithm is likely to quit after a single iteration if only a few voxels meet this criteria. I suggest that you check the image data to see that the real values are greater than 1.0. with regards, John Sled On Tue, Jan 06, 2004 at 09:42:11AM -0000, Richard Boyes wrote: > dear peter, > > thanks for your feedback - unfortunately it crops up with a different > error, this time: > > rboyes@gyrus:~/cvs/bias-correct-regress/custom-sw/regress/data/junk > rawtominc -byte -obyte -clobber -input ./bmask00000.img -coronal -xstep > 0.9766 -ystep 1.8000 -zstep 0.9766 -range 0 255 -real_range 0 255 > ./bmask00000.mnc 120 256 256 > rboyes@gyrus:~/cvs/bias-correct-regress/custom-sw/regress/data/junk > nu_correct -clobber -mask ./bmask00000.mnc ./00000.mnc > /correct00000.mnc -stop 0.0005 -fwhm 0.075 -distance 100 -iterations > 350 -mapping_dir . -shrink 3 > Transforming slices:.........................................Done > No points were chosen by the specified criteria > resample_labels: crashed while running extracttag (termination status=256) > nu_estimate_np_and_em: crashed while running resample_labels (termination > status=256) > nu_correct: crashed while running nu_estimate_np_and_em (termination > status=256) > > i've tried running nu_correct without the mask (below), but i'm getting the > problem of 1e-27 field change again. any other ideas, or can i send > you any other information? > > rboyes@gyrus:~/cvs/bias-correct-regress/custom-sw/regress/data/junk > nu_correct -clobber ./00000.mnc ./correct00000.mnc -stop 0.0005 -fwhm > 0.075 -distance 100 -iterations 350 -mapping_dir . -shrink 3 > Processing:.........................................Done > Not implemented yet in cache_volume_range_has_changed() > Not implemented yet in cache_volume_range_has_changed() > Number of iterations: 1 > CV of field change: 7.88338e-27 > Transforming slices:.........................................Done > 256+0 records in > 256+0 records out > Not implemented yet in cache_volume_range_has_changed() > Not implemented yet in cache_volume_range_has_changed() > Transforming > slices:..................................................................... > ...................................................Done > > > thanks, richard. > > > > -----Original Message----- > > From: minc-development-admin@bic.mni.mcgill.ca > > [mailto:minc-development-admin@bic.mni.mcgill.ca]On Behalf Of Peter > > NEELIN > > Sent: 05 January 2004 03:02 > > To: Richard Boyes > > Cc: MINC > > Subject: Re: [MINC-development] nu_correct on linux > > > > > > On Tue, 23 Dec 2003, Richard Boyes wrote: > > > > > when i try nu_correct, it jumps out straight away, > > > saying the field change is 1E-27. this has happened > > > for multiple images with bad bias fields, which doesn't > > > seem correct. > > > > If I recall correctly, nu_correct had some difficulties with masks that > > had ranges that did not correspond to its expectations (is that correct, > > John?). This is just a guess, but try using the -scan_range option for the > > mask images as well: > > > > #Mask file - no need to swap bytes > > rawtominc -byte -obyte -clobber -input ./bmask00000.img -coronal \ > > -xstep 0.9766 -ystep 1.8000 -zstep 0.9766 \ > > -orange 0 255 -scan_range ./bmask00000.mnc 120 256 256 > > > > Alternatively, replace the -orange option with > > "-range 0 255 -real_range 0 255" and do not use -scan_range. > > > > Peter > > ---- > > Peter Neelin (neelin@bic.mni.mcgill.ca) > > > > _______________________________________________ > > MINC-development mailing list > > MINC-development@bic.mni.mcgill.ca > > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-development > > _______________________________________________ > MINC-development mailing list > MINC-development@bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-development > From minc-development@bic.mni.mcgill.ca Wed Jan 7 17:38:13 2004 From: minc-development@bic.mni.mcgill.ca (Vicka Corey) Date: Wed, 7 Jan 2004 12:38:13 -0500 Subject: [MINC-development] os x? In-Reply-To: <20040107165232.GA13810@sickkids.ca>; from jgsled@sickkids.ca on Wed, Jan 07, 2004 at 10:52:32AM -0600 References: <20040107165232.GA13810@sickkids.ca> Message-ID: <20040107123813.D5071@gate.nmr.mgh.harvard.edu> hi -- just checking back; any sign of the bugfixed os x distribution...? thanks, --vicka From minc-development@bic.mni.mcgill.ca Wed Jan 7 17:47:56 2004 From: minc-development@bic.mni.mcgill.ca (Jason Lerch) Date: Wed, 7 Jan 2004 12:47:56 -0500 Subject: [MINC-development] os x? In-Reply-To: <20040107123813.D5071@gate.nmr.mgh.harvard.edu> References: <20040107165232.GA13810@sickkids.ca> <20040107123813.D5071@gate.nmr.mgh.harvard.edu> Message-ID: any day now. I promise. Mea culpa about the delay .... Jason On Jan 7, 2004, at 12:38 PM, Vicka Corey wrote: > hi -- just checking back; any sign of the bugfixed os x > distribution...? > > thanks, > --vicka > _______________________________________________ > MINC-development mailing list > MINC-development@bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-development From minc-development@bic.mni.mcgill.ca Fri Jan 16 19:23:46 2004 From: minc-development@bic.mni.mcgill.ca (Vicka Corey) Date: Fri, 16 Jan 2004 14:23:46 -0500 Subject: [MINC-development] linking errors on os x Message-ID: <20040116142346.E29903@gate.nmr.mgh.harvard.edu> hi -- i've been trying to build freesurfer on an osx 10.3 laptop. i am using the minc 1.2 cd from the workshop, and am running into some errors: building libfsgdf stuff /usr/bin/libtool: internal link edit command failed ld: warning prebinding disabled because dependent library: /sw/lib/libtiff.3.dylib is not prebound ld: common symbols not allowed with MH_DYLIB output format with the -multi_module option /usr/pubsw/lib/libminc.a(minc_globdef.o) definition of common _minc_call_depth (size 4) /usr/pubsw/lib/libminc.a(minc_globdef.o) definition of common _minc_trash_var (size 4) /usr/pubsw/lib/libnetcdf.a(v2i.o) definition of common _cdf_routine_name (size 4) /usr/pubsw/lib/libminc.a(minc_globdef.o) definition of common _minc_callers_ncopts (size 4) gmake[2]: *** [tcl] Error 1 any ideas? also, any sign of the bugfixes from awhile back...? thanks, --vicka From minc-development@bic.mni.mcgill.ca Sun Jan 18 15:51:36 2004 From: minc-development@bic.mni.mcgill.ca (Jason Lerch) Date: Sun, 18 Jan 2004 10:51:36 -0500 Subject: [MINC-development] linking errors on os x In-Reply-To: <20040116142346.E29903@gate.nmr.mgh.harvard.edu> References: <20040116142346.E29903@gate.nmr.mgh.harvard.edu> Message-ID: <323E7FC6-49CE-11D8-912C-000A95DBBFD8@bic.mni.mcgill.ca> On Jan 16, 2004, at 2:23 PM, Vicka Corey wrote: > hi -- i've been trying to build freesurfer on an osx 10.3 laptop. i > am using > the minc 1.2 cd from the workshop, and am running into some errors: > > building libfsgdf stuff > /usr/bin/libtool: internal link edit command failed > ld: warning prebinding disabled because dependent library: > /sw/lib/libtiff.3.dylib is not prebound > ld: common symbols not allowed with MH_DYLIB output format with the > -multi_module option > /usr/pubsw/lib/libminc.a(minc_globdef.o) definition of common > _minc_call_depth (size 4) > /usr/pubsw/lib/libminc.a(minc_globdef.o) definition of common > _minc_trash_var (size 4) > /usr/pubsw/lib/libnetcdf.a(v2i.o) definition of common > _cdf_routine_name (size 4) > /usr/pubsw/lib/libminc.a(minc_globdef.o) definition of common > _minc_callers_ncopts (size 4) > gmake[2]: *** [tcl] Error 1 > > > any ideas? Might be the OSX namespace issue. Try setenv CC 'gcc -flat_namespace' (or the same for CXX if you are using c++). No idea if this is your problem, but it is worh a try. > also, any sign of the bugfixes from awhile back...? > Working on it as I write this. Jason From minc-development@bic.mni.mcgill.ca Fri Jan 23 17:35:02 2004 From: minc-development@bic.mni.mcgill.ca (Rick Hoge) Date: Fri, 23 Jan 2004 12:35:02 -0500 Subject: [MINC-development] micopy_all_var_values dies if non-standard variables are present in MINC files Message-ID: <79612804-4DCA-11D8-94C1-000A95A69FCE@nmr.mgh.harvard.edu> Hi - For a while we've been motivated to add 'custom' variables to MINC files to embed information about the experiment or analysis in a convenient way. It seems though that non-standard variables prevent some of the MINC tools from running. The following is an example: the file tmap.mnc has a variable added containing information about the analysis performed, and we are running MINC Version 1.0 mincresample -like norm30.mnc tmap.mnc junk2.mnc micopy_all_var_values: MINC package entry point Note that we don't want to use the history variable because we want a specific parameter that can be queried in subsequent analysis steps. I was under the impression the MINC/NetCDF should be extensible in this way without breaking tools that don't know about all the variables present. How should this be handled - does the MINC standard prohibit new variables? Thanks for any advice. I can put such a file on /scratch/ if anyone is interested. Rick From minc-development@bic.mni.mcgill.ca Fri Jan 23 17:58:08 2004 From: minc-development@bic.mni.mcgill.ca (Robert VINCENT) Date: Fri, 23 Jan 2004 12:58:08 -0500 Subject: [MINC-development] micopy_all_var_values dies if non-standard variables are present in MINC files In-Reply-To: <79612804-4DCA-11D8-94C1-000A95A69FCE@nmr.mgh.harvard.edu> Message-ID: Rick, Yes, it should work, but it wouldn't surprise me if it didn't! Please send one (or more) of your files and I'll see if I can fix it. -bert On Fri, 23 Jan 2004, Rick Hoge wrote: > > Hi - > > For a while we've been motivated to add 'custom' variables to MINC > files to embed information about the experiment or analysis in a > convenient way. It seems though that non-standard variables prevent > some of the MINC tools from running. > > The following is an example: the file tmap.mnc has a variable added > containing information about the analysis performed, and we are running > MINC Version 1.0 > > mincresample -like norm30.mnc tmap.mnc junk2.mnc > micopy_all_var_values: MINC package entry point > > Note that we don't want to use the history variable because we want a > specific parameter that can be queried in subsequent analysis steps. I > was under the impression the MINC/NetCDF should be extensible in this > way without breaking tools that don't know about all the variables > present. > > How should this be handled - does the MINC standard prohibit new > variables? Thanks for any advice. I can put such a file on /scratch/ > if anyone is interested. > > Rick > > > _______________________________________________ > MINC-development mailing list > MINC-development@bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-development > From minc-development@bic.mni.mcgill.ca Fri Jan 23 18:12:21 2004 From: minc-development@bic.mni.mcgill.ca (Rick Hoge) Date: Fri, 23 Jan 2004 13:12:21 -0500 Subject: [MINC-development] micopy_all_var_values dies if non-standard variables are present in MINC files In-Reply-To: References: Message-ID: Thanks for the quick reply! I put an example at the following URL: http://www.nmr.mgh.harvard.edu/~rhoge/stuff/fileWithNewVariable.mnc Perhaps I have screwed the file up in some way, but the single modification of writing the file without any new variable seems to fix my problems with micopy_all_vars. Actually, any comments on the validity of this file would be welcome - building MINC files from scratch (as this was done) has seemed a bit tricky. One thing you may notice in this sample is that the xspace, yspace, and zspace lists contain all zeros (what uses these lists? I guess these are to support non-uniform slice sampling?). Also I was lazy and wrote the same min and max values for all images: Rick P.S. Here's an excerpt of the end of the minc header - how should these lists be defined? data: zspace = 0, 0, 0, 0, 0, 0, 0 ; yspace = 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 ; xspace = 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 ; rootvariable = 0 ; image-min = -5.20979118347168, -5.20979118347168, -5.20979118347168, -5.20979118347168, -5.20979118347168, -5.20979118347168, -5.20979118347168 ; image-max = 18.2953414916992, 18.2953414916992, 18.2953414916992, 18.2953414916992, 18.2953414916992, 18.2953414916992, 18.2953414916992 ; MyNewVariable = 0 ; On Jan 23, 2004, at 12:58 PM, Robert VINCENT wrote: > Rick, > > Yes, it should work, but it wouldn't surprise me if it didn't! > > Please send one (or more) of your files and I'll see if I can fix it. > > -bert > > On Fri, 23 Jan 2004, Rick Hoge wrote: > >> >> Hi - >> >> For a while we've been motivated to add 'custom' variables to MINC >> files to embed information about the experiment or analysis in a >> convenient way. It seems though that non-standard variables prevent >> some of the MINC tools from running. >> >> The following is an example: the file tmap.mnc has a variable added >> containing information about the analysis performed, and we are >> running >> MINC Version 1.0 >> >> mincresample -like norm30.mnc tmap.mnc junk2.mnc >> micopy_all_var_values: MINC package entry point >> >> Note that we don't want to use the history variable because we want a >> specific parameter that can be queried in subsequent analysis steps. >> I >> was under the impression the MINC/NetCDF should be extensible in this >> way without breaking tools that don't know about all the variables >> present. >> >> How should this be handled - does the MINC standard prohibit new >> variables? Thanks for any advice. I can put such a file on /scratch/ >> if anyone is interested. >> >> Rick >> >> >> _______________________________________________ >> MINC-development mailing list >> MINC-development@bic.mni.mcgill.ca >> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-development >> From minc-development@bic.mni.mcgill.ca Fri Jan 23 21:09:30 2004 From: minc-development@bic.mni.mcgill.ca (Jason Lerch) Date: Fri, 23 Jan 2004 16:09:30 -0500 Subject: [MINC-development] New package in CVS: cortical_surface Message-ID: <6F9AB7F7-4DE8-11D8-9E9C-000A95DBBFD8@bic.mni.mcgill.ca> Greetings all, just to let you know that a new package has made into CVS (under registration/) called cortical_surface. This is David's single surface stuff that we use in order to compute a simple single surface used for masking the cerebrum away from the cerebellum, dura, skull, and brain-stem. It includes the C code for deform_surface and the Perl stuff for cortical_surface. Cheers, Jason From minc-development@bic.mni.mcgill.ca Wed Jan 28 21:34:09 2004 From: minc-development@bic.mni.mcgill.ca (Jason Lerch) Date: Wed, 28 Jan 2004 16:34:09 -0500 Subject: [MINC-development] New OS X binaries released Message-ID: Greetings all and apologies for cross-posting, I've just uploaded a new release of the OS 10.3 binaries to our web-site: http://www.bic.mni.mcgill.ca/software/distribution/osx.html The package should solve most outstanding issues, such as the broken N3, the lack of support for gzipped files, etc. The Register problem is still unresolved, though a workaround has been posted. The new package contains the following: This binary distribution contains the following packages: NetCDF 3.5.0 MINC 1.3 from CVS BICPL 1.4.0-1 Register 1.3.4 Display 1.3.8 Conglomerate 1.3 from CVS with some still uncommitted patches mni_autoreg 0.98k mni_perllib 0.07 Getopt-Tabular 0.3 mni_autoreg_model 1.03 ray_trace 1.0 EBTKS from CVS with still uncommitted patches classify from CVS N3 1.0.6 with ugly compile time hacks mincmorph 1.1 mincblob 1.1 cortical_surface 1.0 from CVS ana2mnc from CVS Please let me know of any issues that might arise. The ReadMe file should contain all the instructions necessary for using this distribution. Cheers, Jason