From minc-development@bic.mni.mcgill.ca Mon Feb 10 17:41:43 2003 From: minc-development@bic.mni.mcgill.ca (Jason Lerch) Date: 10 Feb 2003 12:41:43 -0500 Subject: [MINC-development] two prereleases: bicpl 1.4.0 and ray_trace 1.0 Message-ID: <1044898904.5287.7.camel@dennis.bic.mni.mcgill.ca> Hello all, anyone feel like testing two packages: /home/bic/jason/seconddir/tmp/ray_trace-1.0.tar.gz and /home/bic/jason/seconddir/tmp/bicpl-1.4.0.tar.gz The bicpl has gained some code from the former libdavid. ray_trace is a ray-tracing programme that David MacDonald wrote, now autoconfiscated. You'll need bicpl 1.4 to get ray_trace to build. Let me know what problems arise. Should there be none, I'll check all the changes in to CVS and release this stuff to the world. Jason From minc-development@bic.mni.mcgill.ca Tue Feb 11 06:30:59 2003 From: minc-development@bic.mni.mcgill.ca (Andrew Janke) Date: Tue, 11 Feb 2003 16:30:59 +1000 Subject: [MINC-development] mincrandsample Message-ID: I have added another 'goodie', (/s/s/minc_dev/mincrandsample) ** wotsitdo? Generates random samplings of an input series of minc files. (or random MINC masks should you prefer). ie: to generate 1000 random samples from the input file data.mnc within the mask mask.mnc. mincrandsample data.mnc -num_points 1000 -mask mask.mnc raw_data Raw data will be output as a stream of doubles. You can also use stdout: mincrandsample data.mnc -num_points 1000 -mask mask.mnc - >> raw_data Or perhaps generate a new mask of the chosen (random) sampling: mincrandsample data.mnc -num_points 1000 -sample samp.mnc - > raw_data It can also handle a input series of files (output will also be a corresponding vector or doubles) mincrandsample data1.mnc data2.mnc data3.mnc -num_points 1000 - > raw_data ** wotsitgoodfor? Well I wrote it as a precursor proggie for most of the predictive modelling we do based upon a random sampling of input data (that is then trained multiple times to generate a model). ** wotmightyouuseitfor? I'd imagine most people are uninterested in the output data and would only have a use for it's ability to create a random sampling of a mask. ie: mincrandsample mask.mnc -mask mask.mnc -sampling rand_mask.mnc \ -num_points 2500 - > /dev/null -- Andrew Janke ( rotor@cmr.uq.edu.au || www.cmr.uq.edu.au/~rotor ) Australia->University of Queensland->Centre for Magnetic Resonance Work: +61 7 3365 4100 || Home: +61 7 3800 4042 From minc-development@bic.mni.mcgill.ca Mon Feb 17 06:55:14 2003 From: minc-development@bic.mni.mcgill.ca (Andrew Janke) Date: Mon, 17 Feb 2003 16:55:14 +1000 Subject: [MINC-development] mincinsert Message-ID: No I haven't written it yet, (I'm thinking about it). Does anyone else have a use for a complement to mincextract? ie: # get a chunk of data $ mincextract -float -start 12,0,10 -count 10,10,10 file.mnc > raw_data # do something with it $ youfuncommand < raw_data > new_raw_data # put it back $ mincinsert -float -start 12,0,10 -count 10,10,10 file.mnc < new_raw_data I am a bit unsure as to whether the volume should be modified in-place though as none of the other minc commands do this. dunno. ? -- Andrew Janke ( rotor@cmr.uq.edu.au || www.cmr.uq.edu.au/~rotor ) Australia->University of Queensland->Centre for Magnetic Resonance Work: +61 7 3365 4100 || Home: +61 7 3800 4042 From minc-development@bic.mni.mcgill.ca Tue Feb 25 09:13:36 2003 From: minc-development@bic.mni.mcgill.ca (Andrew Janke) Date: Tue, 25 Feb 2003 19:13:36 +1000 Subject: [MINC-development] mincmorph 1.4 (the probable replacement for binop) Message-ID: I have finally managed to finish this problem child. /software/source/minc_dev/mincmorph Up 'till now the Group (Connected Component Labelling) bit might have worked in some cases but was generally broken. It now works, well at least untill one of you lot break it. :) The major change is that the NC_FLOAT datatype is used internally. This has obvious ramifications WRT memory use, but I was becomming very ticked off with range problems that crop up due to the many combinations of operators. (ie gray-level dilation combined with CCL...) ie: to label all the groups (in ascending order) in the file in.mnc between the values of 10 and 100. mincmorph -successive 'B[10:100]G' in.mnc out.mnc Because the groups are ascending you can then use minmath to get the 2 largest groups or just add a bit to the command above: mincmorph -successive 'B[10:100]GK[0:2]' in.mnc out.mnc But why stop there? Let's dilate it a bit: mincmorph -successive 'B[10:100]GK[0:2]DDDD' in.mnc out.mnc And just to show off, compute a distance transform mincmorph -successive 'B[10:100]GK[0:2]DDDDF' in.mnc out.mnc And then do sobel edge detection... (assuming that you've made sobel.kern) mincmorph -successive 'B[10:100]GK[0:2]DDDDFR[sobel.kern]X' in.mnc out.mnc For this matter all the operations are WRT an input kernel, a 3x3x3 8 connectivity kernel is the default. This means that you can finally do those Erosions and Dilations in the transverse direction (or coronal) for that matter. As always, comments, criticism and invitations of finding a real life accepted. -- Andrew Janke ( rotor@cmr.uq.edu.au || www.cmr.uq.edu.au/~rotor ) Australia->University of Queensland->Centre for Magnetic Resonance Work: +61 7 3365 4100 || Home: +61 7 3800 4042 From minc-development@bic.mni.mcgill.ca Wed Feb 26 21:12:09 2003 From: minc-development@bic.mni.mcgill.ca (John G. Sled) Date: Wed, 26 Feb 2003 16:12:09 -0500 Subject: [MINC-development] Summary of January meeting Message-ID: <20030226161209.A5168@sickkids.ca> As many of you are aware, we had a meeting in January to discuss the design of MINC 2.0. The meeting proved productive and covered a large number of issues. The following is a summary of the meeting. The major decision at the meeting was that we pursue HDF5 and not NetCDF as the low level file management library. While this decision is not yet set in stone, the consensus was that the features that HDF5 provides as well as its overall vitality make it a compelling choice. Specifically, it supports large files with arbitrary layout, it implements blocked disk layout (chunking in HDF5 terminology), and it has a mechanism to plug in compression algorithms for compressed chunks. Bert and Leila have been investigating whether these benefits can be realized for this project. The most complex issue at present is how to implement the fixed point integer translations. Another issue that was discussed in detail was how to handle backwards compatibility. The conclusion was that the minimum acceptable level of compatibility could be met by having all tools transparently run a file format conversion program to generate a temporary file in the new format. The reverse process could optionally be invoked when files are written to return them to the old format. It was unclear from the discussion whether a more efficient method of achieving backward compatibility could be implemented without compromising the functionality of the new library. There was also some discussion on what the default behaviour in terms of writing files should be if the input file was in MINC 1.x format. The conversion program would also be available as a stand alone application. With respect to multiresolution, the multi-thumbnail approach to multiple resolutions was agreed to be the simpler and more practical solution. It appears that HDF5 allows new data organizations to added in a manner that is transparent to the API. This mechanism could later be used to add a wavelet implementation of multiresolution data layout if desired. There was much discussion of the handling of data types at the meeting. It was agreed that there should be three types of scalar data: integer, real, and enumerated. Any of these can be represented by either a integer or floating point format. For example, a real number with an integer representation would use the familiar voxel and real range mapping. It was not immediately clear what granularity is appropriate for these mappings. For example, the old strategy of one mapping per slice could be used or perhaps one mapping per block in block format files. The latter may be possible to implement transparently using the filter mechanism in HDF5. Volumes with enumerated data type would include a dictionary in the header that mapped strings to integer values. It was also proposed that the record data type in HDF5 be used to implement non-scalar types such as complex numbers and vectors. The consensus was that the interpretation of these types should be application specific rather than in the core library. So, for example, even though a variety of types might be specified it would be up to specific applications to implement such operations as multiply and divide. A copy operation would be provided for all types. With respect to structuring MINC 2.0, the functionality of libminc would greatly increased such that for applications that do their own memory management, libminc would be the prefered choice instead of volume_io. In order to maintain the functionality of existing applications, voxel_loop and volume_io would be revised to use the new libminc without changing their API. It was also agreed that a rewrite of the file access functionality in EMMA would be needed in order that the MatLab based data analysis continue to function. The plan is also to create a successor to VolumeIO that would provide memory management. It was not clear at the meeting what form this new library should take. At present Bert, John C., Leila and I are working on a design document based on these ideas. Once a draft is ready, this will be circulated to the list. Please feel free to comment on any of the issues I've mentioned. cheers, John From minc-development@bic.mni.mcgill.ca Thu Feb 27 16:26:18 2003 From: minc-development@bic.mni.mcgill.ca (Vicka Corey) Date: Thu, 27 Feb 2003 11:26:18 -0500 Subject: [MINC-development] joining the list, and tmp_nam errors? Message-ID: <20030227112618.A8157@gate.nmr.mgh.harvard.edu> Hi -- I hope this abrupt post isn't out of line.... I am working on the Freesurfer software at MGH. We are having issues with various developers using various versions of the minc and mni libraries, and making their own changes to the code (mostly to avoid the errors that gcc-2.96 gives for "tmp_nam", which they find annoying). In my role as software janitor, I'd like to try to help clean this up. So some questions: 1. Are there versions of minc that don't use tmp_nam()? We have various between 0.7 and 1.1 here, and they all do in one place or another, though not always the same ones. 2. Can I join the mailing list? If I submit a patch to get rid of those calls, any chance it could make it into the distribution? thanks much, --vicka Vicka Rael Corey, Ph.D. vicka@nmr.mgh.harvard.edu BIRN Group 617 724 7744 MGH/MIT/HMS Athinoula A. Martinos Center for Biomedical Imaging 149 (2301) 13th Street, Charlestown, MA 02129 USA From minc-development@bic.mni.mcgill.ca Thu Feb 27 16:51:36 2003 From: minc-development@bic.mni.mcgill.ca (Steve ROBBINS) Date: Thu, 27 Feb 2003 11:51:36 -0500 Subject: [MINC-development] joining the list, and tmp_nam errors? In-Reply-To: <20030227112618.A8157@gate.nmr.mgh.harvard.edu>; from vicka@nmr.mgh.harvard.edu on Thu, Feb 27, 2003 at 11:26:18AM -0500 References: <20030227112618.A8157@gate.nmr.mgh.harvard.edu> Message-ID: <20030227115136.J6686538@shadow.bic.mni.mcgill.ca> On Thu, Feb 27, 2003 at 11:26:18AM -0500, Vicka Corey wrote: > 1. Are there versions of minc that don't use tmp_nam()? We have various > between 0.7 and 1.1 here, and they all do in one place or another, > though not always the same ones. MINC 1.1 is the latest, so yes, the tmpnam() calls are still in there. > 2. Can I join the mailing list? If I submit a patch to get rid of those > calls, any chance it could make it into the distribution? I don't see why it wouldn't. I also find the compiler warning to be a nuisance. -S From minc-development@bic.mni.mcgill.ca Thu Feb 27 16:53:03 2003 From: minc-development@bic.mni.mcgill.ca (Leila Baghdadi) Date: Thu, 27 Feb 2003 11:53:03 -0500 (EST) Subject: [MINC-development] joining the list, and tmp_nam errors? In-Reply-To: <20030227112618.A8157@gate.nmr.mgh.harvard.edu> Message-ID: Vicka we are (MNI and MICe Imaging) are in the process of designing and implementing MINC2.0. I suggest you take a look at the e-mail archives to get some info about different functionality and design criteria. To my knowledge joining the list is no problem for any parties who is interested. Hope this helps Leila On Thu, 27 Feb 2003, Vicka Corey wrote: > Hi -- I hope this abrupt post isn't out of line.... > > I am working on the Freesurfer software at MGH. We are having issues > with various developers using various versions of the minc and mni > libraries, and making their own changes to the code (mostly to avoid > the errors that gcc-2.96 gives for "tmp_nam", which they find annoying). > In my role as software janitor, I'd like to try to help clean this up. > > So some questions: > > 1. Are there versions of minc that don't use tmp_nam()? We have various > between 0.7 and 1.1 here, and they all do in one place or another, > though not always the same ones. > > 2. Can I join the mailing list? If I submit a patch to get rid of those > calls, any chance it could make it into the distribution? > > thanks much, > --vicka > > Vicka Rael Corey, Ph.D. vicka@nmr.mgh.harvard.edu > BIRN Group 617 724 7744 > MGH/MIT/HMS Athinoula A. Martinos Center for Biomedical Imaging > 149 (2301) 13th Street, Charlestown, MA 02129 USA > _______________________________________________ > 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 Thu Feb 27 18:49:00 2003 From: minc-development@bic.mni.mcgill.ca (Vicka Corey) Date: Thu, 27 Feb 2003 13:49:00 -0500 Subject: [MINC-development] BTW, what happened to "minctracc"? In-Reply-To: <200302271643.h1RGh4p7253104@shadow.bic.mni.mcgill.ca>; from minc-development-request@bic.mni.mcgill.ca on Thu, Feb 27, 2003 at 11:43:04AM -0500 References: <200302271643.h1RGh4p7253104@shadow.bic.mni.mcgill.ca> Message-ID: <20030227134900.C14520@gate.nmr.mgh.harvard.edu> Hi -- while I'm here, I'd like to ask a question I've been wondering about: We have an old script here that calls "minctracc". That exists in version 0.7, but not in 1.1. What happened to it? Has it been replaced by something else? thanks, --vicka From minc-development@bic.mni.mcgill.ca Thu Feb 27 19:03:17 2003 From: minc-development@bic.mni.mcgill.ca (Steve ROBBINS) Date: Thu, 27 Feb 2003 14:03:17 -0500 Subject: [MINC-development] BTW, what happened to "minctracc"? In-Reply-To: <20030227134900.C14520@gate.nmr.mgh.harvard.edu>; from vicka@nmr.mgh.harvard.edu on Thu, Feb 27, 2003 at 01:49:00PM -0500 References: <200302271643.h1RGh4p7253104@shadow.bic.mni.mcgill.ca> <20030227134900.C14520@gate.nmr.mgh.harvard.edu> Message-ID: <20030227140316.A7034298@shadow.bic.mni.mcgill.ca> On Thu, Feb 27, 2003 at 01:49:00PM -0500, Vicka Corey wrote: > Hi -- while I'm here, I'd like to ask a question I've been wondering about: > > We have an old script here that calls "minctracc". That exists in version > 0.7, but not in 1.1. What happened to it? Has it been replaced by something > else? Minctracc comes from the "mni_autoreg" package, not MINC per se. You can get it from http://www.bic.mni.mcgill.ca/software/distribution/ -S From minc-development@bic.mni.mcgill.ca Thu Feb 27 22:41:04 2003 From: minc-development@bic.mni.mcgill.ca (Vicka Corey) Date: Thu, 27 Feb 2003 17:41:04 -0500 Subject: [MINC-development] OS X In-Reply-To: <20030227134900.C14520@gate.nmr.mgh.harvard.edu>; from vicka@nmr.mgh.harvard.edu on Thu, Feb 27, 2003 at 01:49:00PM -0500 References: <200302271643.h1RGh4p7253104@shadow.bic.mni.mcgill.ca> <20030227134900.C14520@gate.nmr.mgh.harvard.edu> Message-ID: <20030227174104.B25806@gate.nmr.mgh.harvard.edu> Hi -- I guess having just arrived I have a lot to say.... I'm building minc and its friends under OS X, as part of doing the Freesurfer port to OS X. I got minc 1.0 working awhile ago, but since I'm going to try to write some patches, I thought I would get 1.1 and build that. 1. It's not happy out of the box; I'm slogging through configure and the Makefile. But as long as I'm asking, anyone here have any tips? 2. I was looking through the archives, and it seems as though OS X is not on the list of systems to be supported in 2.0. This worries me considerably, as there's a demand for an OS X Freesurfer, and we depend on minc. What's up with this? thanks, --vicka From minc-development@bic.mni.mcgill.ca Thu Feb 27 22:55:40 2003 From: minc-development@bic.mni.mcgill.ca (Robert VINCENT) Date: Thu, 27 Feb 2003 17:55:40 -0500 Subject: [MINC-development] OS X In-Reply-To: <20030227174104.B25806@gate.nmr.mgh.harvard.edu> Message-ID: Vicka, Regarding #1, I'm not an OS X expert, so I can't provide any tips, but I'm happy to try to help you get the code built, and to fix the 1.1 release to build more readily. Regarding #2, speaking only for myself at this point, I would like to support OS X in all future releases of minc. -bert On Thu, 27 Feb 2003, Vicka Corey wrote: > Hi -- I guess having just arrived I have a lot to say.... > > I'm building minc and its friends under OS X, as part of doing the > Freesurfer port to OS X. I got minc 1.0 working awhile ago, but > since I'm going to try to write some patches, I thought I would get > 1.1 and build that. > > 1. It's not happy out of the box; I'm slogging through configure and > the Makefile. But as long as I'm asking, anyone here have any tips? > > 2. I was looking through the archives, and it seems as though OS X is > not on the list of systems to be supported in 2.0. This worries me > considerably, as there's a demand for an OS X Freesurfer, and we > depend on minc. What's up with this? > > 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 Thu Feb 27 22:55:29 2003 From: minc-development@bic.mni.mcgill.ca (Vicka Corey) Date: Thu, 27 Feb 2003 17:55:29 -0500 Subject: [MINC-development] OS X In-Reply-To: <20030227174104.B25806@gate.nmr.mgh.harvard.edu>; from vicka@nmr.mgh.harvard.edu on Thu, Feb 27, 2003 at 05:41:04PM -0500 References: <200302271643.h1RGh4p7253104@shadow.bic.mni.mcgill.ca> <20030227134900.C14520@gate.nmr.mgh.harvard.edu> <20030227174104.B25806@gate.nmr.mgh.harvard.edu> Message-ID: <20030227175529.C25806@gate.nmr.mgh.harvard.edu> and replying to myself.... > I'm building minc and its friends under OS X, as part of doing the > Freesurfer port to OS X. I got minc 1.0 working awhile ago, but > since I'm going to try to write some patches, I thought I would get > 1.1 and build that. > > 1. It's not happy out of the box; I'm slogging through configure and > the Makefile. But as long as I'm asking, anyone here have any tips? Actually minc 1.1 per se seems to have compiled fine. For the record, I was getting some problems from mni_autoreg-0.98j. The configure script complained that it couldn't get the host, so I offered it a bogon (--host=Darwin), and I symlinked the obscurely-placed system malloc.h to /usr/lib to get the make to work. Does anyone else here care about OS X? --vicka From minc-development@bic.mni.mcgill.ca Thu Feb 27 23:36:27 2003 From: minc-development@bic.mni.mcgill.ca (Steve ROBBINS) Date: Thu, 27 Feb 2003 18:36:27 -0500 Subject: [MINC-development] OS X In-Reply-To: <20030227175529.C25806@gate.nmr.mgh.harvard.edu>; from vicka@nmr.mgh.harvard.edu on Thu, Feb 27, 2003 at 05:55:29PM -0500 References: <200302271643.h1RGh4p7253104@shadow.bic.mni.mcgill.ca> <20030227134900.C14520@gate.nmr.mgh.harvard.edu> <20030227174104.B25806@gate.nmr.mgh.harvard.edu> <20030227175529.C25806@gate.nmr.mgh.harvard.edu> Message-ID: <20030227183627.B7034298@shadow.bic.mni.mcgill.ca> On Thu, Feb 27, 2003 at 05:55:29PM -0500, Vicka Corey wrote: > and replying to myself.... > > I'm building minc and its friends under OS X, as part of doing the > > Freesurfer port to OS X. I got minc 1.0 working awhile ago, but > > since I'm going to try to write some patches, I thought I would get > > 1.1 and build that. > > > > 1. It's not happy out of the box; I'm slogging through configure and > > the Makefile. But as long as I'm asking, anyone here have any tips? > > Actually minc 1.1 per se seems to have compiled fine. Good! I made notes for myself while building our stuff for Mac OSX. This was done a while ago and the notes are extremely terse, but you're welcome to have a look http://www.bic.mni.mcgill.ca/~stever/Software/RelNotes/MacOSX/ If you run into further snags, do post them here. > For the record, > I was getting some problems from mni_autoreg-0.98j. The configure script > complained that it couldn't get the host, so I offered it a bogon > (--host=Darwin), The problem with the configure script is known. Your solution will work sometimes, but the better solution is to update config.sub and config.guess before running configure. I have sufficiently-modern versions on my web page (URL above) that you can just drop into the source directory after unpacking. > and I symlinked the obscurely-placed system malloc.h > to /usr/lib to get the make to work. Ah. The code should be fixed so that malloc.h is not needed, actually. Thanks for noting that. -S From minc-development@bic.mni.mcgill.ca Fri Feb 28 01:35:18 2003 From: minc-development@bic.mni.mcgill.ca (Andrew Janke) Date: Fri, 28 Feb 2003 11:35:18 +1000 Subject: [MINC-development] OS X In-Reply-To: <20030227175529.C25806@gate.nmr.mgh.harvard.edu> Message-ID: On Thu, 27 Feb 2003, Vicka Corey wrote: > > 1. It's not happy out of the box; I'm slogging through configure and > > the Makefile. But as long as I'm asking, anyone here have any tips? > > Actually minc 1.1 per se seems to have compiled fine. For the record, > I was getting some problems from mni_autoreg-0.98j. The configure script > complained that it couldn't get the host, so I offered it a bogon > (--host=Darwin), and I symlinked the obscurely-placed system malloc.h > to /usr/lib to get the make to work. > > Does anyone else here care about OS X? ME! I see it as a "platform for the clinicians" :). I have managed to build most of minc (Excluding register and Display) for OSX and now have a number of neurologists/clinicians quite happilly going home with their laptops and tracing stuff for me (in Display). For this I used Steve Robbins pre-built minc "OSX package". On this note, jason lerch was toying with a automated package builder a while back, I think it included support for Mac packages but am unsure. The easiest way to get minc et al to the Mac as a pre-built package may be via fink using a modified version of Steve Robbins's .deb debian packages. -- Andrew Janke ( rotor@cmr.uq.edu.au || www.cmr.uq.edu.au/~rotor ) Australia->University of Queensland->Centre for Magnetic Resonance Work: +61 7 3365 4100 || Home: +61 7 3800 4042 From minc-development@bic.mni.mcgill.ca Fri Feb 28 02:43:43 2003 From: minc-development@bic.mni.mcgill.ca (Rick Hoge) Date: Thu, 27 Feb 2003 21:43:43 -0500 Subject: [MINC-development] OS X In-Reply-To: Message-ID: <73A69FDC-4AC6-11D7-8FA1-000393B3ACC6@nmr.mgh.harvard.edu> >> Does anyone else here care about OS X? > > ME! I see it as a "platform for the clinicians" :). I have managed to > build > most of minc (Excluding register and Display) for OSX and now have a > number of > neurologists/clinicians quite happilly going home with their laptops > and tracing > stuff for me (in Display). For this I used Steve Robbins pre-built > minc "OSX > package". > > On this note, jason lerch was toying with a automated package builder > a while > back, I think it included support for Mac packages but am unsure. > > The easiest way to get minc et al to the Mac as a pre-built package > may be via > fink using a modified version of Steve Robbins's .deb debian packages. I've been using the register binary that's currently available on the MNI ftp site. Under the new X11 release it is really fast (faster than Linux, which was not the case under XDarwin). For some reason Display gives the error message 'Cannot find menu file Display.menu and no compiled-in fallback' I also have OS X emma binaries if anyone is using Matlab - not sure who's maintaining Emma now... Rick ______________________________________ Richard D. Hoge, Ph.D. Instructor, HMS Department of Radiology A. A. Martinos Center for Biomedical Imaging 149 13th St. Charlestown MA 02129 phone 617-726-6598 fax 617-726-7422 ______________________________________ From minc-development@bic.mni.mcgill.ca Fri Feb 28 03:22:35 2003 From: minc-development@bic.mni.mcgill.ca (Andrew Janke) Date: Fri, 28 Feb 2003 13:22:35 +1000 Subject: [MINC-development] OS X In-Reply-To: <73A69FDC-4AC6-11D7-8FA1-000393B3ACC6@nmr.mgh.harvard.edu> Message-ID: On Thu, 27 Feb 2003, Rick Hoge wrote: > > The easiest way to get minc et al to the Mac as a pre-built package > > may be via > > fink using a modified version of Steve Robbins's .deb debian packages. > > I've been using the register binary that's currently available on the > MNI ftp site. Under the new X11 release it is really fast (faster than > Linux, which was not the case under XDarwin). For some reason Display > gives the error message > > 'Cannot find menu file Display.menu and no compiled-in fallback' This should here /usr/local/mni/include/Display.menu (assuming register/Display is in /usr/local/mni/bin) Which binary version are you referring to? I used the "complete" minc/register/Display tar 'distribution' that either Steve or Dale compiled. I now can't seem to find it anywhere now? It was posted to the BIC geeks list (which I don't have web access to here) IIRC, dale? BTW I agree with the comments about speed, the Mac X11 binary is definitely speedy compared to the previous Orobor/Darwin X servers. a From minc-development@bic.mni.mcgill.ca Fri Feb 28 03:25:09 2003 From: minc-development@bic.mni.mcgill.ca (Andrew Janke) Date: Fri, 28 Feb 2003 13:25:09 +1000 Subject: [MINC-development] OS X In-Reply-To: Message-ID: On Fri, 28 Feb 2003, Andrew Janke wrote: > > I've been using the register binary that's currently available on the > > MNI ftp site. Under the new X11 release it is really fast (faster than > > Linux, which was not the case under XDarwin). For some reason Display > > gives the error message > > > > 'Cannot find menu file Display.menu and no compiled-in fallback' Oh, also forgot, another way around this is as such when building Display: ./configure --disable-menu-fallback .... -- Andrew Janke ( rotor@cmr.uq.edu.au || www.cmr.uq.edu.au/~rotor ) Australia->University of Queensland->Centre for Magnetic Resonance Work: +61 7 3365 4100 || Home: +61 7 3800 4042 From minc-development@bic.mni.mcgill.ca Fri Feb 28 12:48:17 2003 From: minc-development@bic.mni.mcgill.ca (Rick Hoge) Date: Fri, 28 Feb 2003 07:48:17 -0500 Subject: [MINC-development] OS X In-Reply-To: Message-ID: > Which binary version are you referring to? I used the "complete" > minc/register/Display tar 'distribution' that either Steve or Dale > compiled. > I now can't seem to find it anywhere now? Thanks for the tip on Display - I'll check it out. I just checked and the Mac OSX binaries are still available at ftp://ftp.bic.mni.mcgill.ca/pub/register+Display/compiled/ the file is Display+register_bin_macosx_v1.3.5.tar.gz Rick From minc-development@bic.mni.mcgill.ca Fri Feb 28 17:02:31 2003 From: minc-development@bic.mni.mcgill.ca (John G. Sled) Date: Fri, 28 Feb 2003 12:02:31 -0500 Subject: [MINC-development] OS X In-Reply-To: ; from rotor@cmr.uq.edu.au on Fri, Feb 28, 2003 at 11:35:18AM +1000 References: <20030227175529.C25806@gate.nmr.mgh.harvard.edu> Message-ID: <20030228120230.A8379@sickkids.ca> > ME! I see it as a "platform for the clinicians" :). I have managed to build > most of minc (Excluding register and Display) for OSX and now have a number of > neurologists/clinicians quite happilly going home with their laptops and tracing > stuff for me (in Display). For this I used Steve Robbins pre-built minc "OSX > package". > Does 'most of minc' include N3? I have received many requests lately for the N3 code on OSX. John From minc-development@bic.mni.mcgill.ca Fri Feb 28 17:13:58 2003 From: minc-development@bic.mni.mcgill.ca (Robert VINCENT) Date: Fri, 28 Feb 2003 12:13:58 -0500 Subject: [MINC-development] OS X In-Reply-To: <20030228120230.A8379@sickkids.ca> Message-ID: Speaking of N3, I'm actively working on getting it to build with GCC 3.2 using automake/autoconf. Hopefully this means we will soon have N3 working on OS X. -bert On Fri, 28 Feb 2003, John G. Sled wrote: > > > ME! I see it as a "platform for the clinicians" :). I have managed to build > > most of minc (Excluding register and Display) for OSX and now have a number of > > neurologists/clinicians quite happilly going home with their laptops and tracing > > stuff for me (in Display). For this I used Steve Robbins pre-built minc "OSX > > package". > > > > Does 'most of minc' include N3? I have received many requests lately > for the N3 code on OSX. > > John > _______________________________________________ > 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 Feb 28 22:27:39 2003 From: minc-development@bic.mni.mcgill.ca (Vicka Corey) Date: Fri, 28 Feb 2003 17:27:39 -0500 Subject: [MINC-development] OS X In-Reply-To: <20030227183627.B7034298@shadow.bic.mni.mcgill.ca>; from stever@bic.mni.mcgill.ca on Thu, Feb 27, 2003 at 06:36:27PM -0500 References: <200302271643.h1RGh4p7253104@shadow.bic.mni.mcgill.ca> <20030227134900.C14520@gate.nmr.mgh.harvard.edu> <20030227174104.B25806@gate.nmr.mgh.harvard.edu> <20030227175529.C25806@gate.nmr.mgh.harvard.edu> <20030227183627.B7034298@shadow.bic.mni.mcgill.ca> Message-ID: <20030228172739.A3545@gate.nmr.mgh.harvard.edu> Just another note on minc 1.1 for OS X: On Thu, Feb 27, 2003 at 06:36:27PM -0500, Steve ROBBINS wrote: > > Actually minc 1.1 per se seems to have compiled fine. > > If you run into further snags, do post them here. Today I set out to link Freesurfer with the 1.1 libminc.a, and it was not happy when I wanted to make dynamic libraries: ld: common symbols not allowed with MH_DYLIB output format ld: common symbols not allowed with MH_DYLIB output format /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/libminc.a(minc_globdef.o) definition of common _minc_callers_ncopts (size 4) /usr/bin/libtool: internal link edit command failed I added -fno-common to CFLAGS in the minc Makefile, which seems to have fixed it. --vicka