From minc-development@bic.mni.mcgill.ca Tue Mar 2 05:40:36 2004 From: minc-development@bic.mni.mcgill.ca (Andrew Janke) Date: Tue, 2 Mar 2004 15:40:36 +1000 Subject: [MINC-development] Re: glim_image In-Reply-To: References: <20040224142811.GB2656913@shadow.bic.mni.mcgill.ca> Message-ID: On Tue, 24 Feb 2004, Jason Lerch wrote: > >> On this note, glim_image and things not packaged, does anyone have any > >> objections to glim_image being renamed (say to mincglm) and being > >> stuffed into > >> the base minc distro? It is a nice pure vanilla C proggie that was > >> 'peter blessed' from what I know. > > Urm, it's not packaged? Could have fooled me. Check the statistics > directory under /software/source. And I see no particular reason to > rename it, though I don't have any strong objections either. The general consensus on this was to package glim_image as part of an extra_tools package was it not? If all that is missing is packaging this is a somewhat easy task. With respect to the renaming issue, I would only do this such that we can a) dissociate glim_iamge from the minc_extras package b) get a bit of consistency into minc tools names. I'm still keen for mincglm or this too broad of a name? > The last time I asked whether we should distribute it the answer from > the powers that be (including Alex!) was no. But then again that was a > while ago. Hrm, and these powers were? Alan? a From minc-development@bic.mni.mcgill.ca Tue Mar 2 11:34:12 2004 From: minc-development@bic.mni.mcgill.ca (Alex ZIJDENBOS) Date: Tue, 2 Mar 2004 06:34:12 -0500 Subject: [MINC-development] Re: glim_image In-Reply-To: References: <20040224142811.GB2656913@shadow.bic.mni.mcgill.ca> Message-ID: <20040302113412.GA3158384@shadow.bic.mni.mcgill.ca> On Tue, Mar 02, 2004 at 03:40:36PM +1000, Andrew Janke wrote: > a) dissociate glim_iamge from the minc_extras package > b) get a bit of consistency into minc tools names. > > I'm still keen for mincglm or this too broad of a name? Seems fine to me... > > The last time I asked whether we should distribute it the answer from > > the powers that be (including Alex!) was no. But then again that was a > > while ago. > > Hrm, and these powers were? Alan? I suppose - and Keith should probably be asked as well, since glim_image was developed under his and Alan's/Peter's supervision. -- A From minc-development@bic.mni.mcgill.ca Tue Mar 2 13:30:37 2004 From: minc-development@bic.mni.mcgill.ca (Jason Lerch) Date: Tue, 2 Mar 2004 08:30:37 -0500 Subject: [MINC-development] Re: glim_image In-Reply-To: References: <20040224142811.GB2656913@shadow.bic.mni.mcgill.ca> Message-ID: On Mar 2, 2004, at 12:40 AM, Andrew Janke wrote: > On Tue, 24 Feb 2004, Jason Lerch wrote: > >>>> On this note, glim_image and things not packaged, does anyone have >>>> any >>>> objections to glim_image being renamed (say to mincglm) and being >>>> stuffed into >>>> the base minc distro? It is a nice pure vanilla C proggie that was >>>> 'peter blessed' from what I know. >> >> Urm, it's not packaged? Could have fooled me. Check the statistics >> directory under /software/source. And I see no particular reason to >> rename it, though I don't have any strong objections either. > > The general consensus on this was to package glim_image as part of an > extra_tools package was it not? Why create a new package called extra_tools - doesn't conglomerate basically fit this bill? > > If all that is missing is packaging this is a somewhat easy task. > With respect > to the renaming issue, I would only do this such that we can > > a) dissociate glim_iamge from the minc_extras package Now I'm confused - you want to create a separate package for glim_image? That already exists, nicely autoconfed and all. I thought you wanted to add it to the extras package. > b) get a bit of consistency into minc tools names. Heh. Good luck. Next thing we know you'll also advocate writing some documentation ;-) > > I'm still keen for mincglm or this too broad of a name? Isn't there some kinda rule that apps with minc in their name are general enough to deal with arbitrary dimensions? In which case I don't think that glim_image would qualify. Jason From minc-development@bic.mni.mcgill.ca Tue Mar 2 16:03:55 2004 From: minc-development@bic.mni.mcgill.ca (Sylvain MILOT) Date: Tue, 2 Mar 2004 11:03:55 -0500 Subject: [MINC-development] Re: glim_image In-Reply-To: Message-ID: Hello, I'm not opposed to changing the name of glim_image as long as the current version remains online with its current name. As for glim_image not being general enough to deal with arbitrary dimensions, well I've used it successfully with 2mm data (91 109 91). At least the results were very close to an analysis done with the old traditional PET analysis template 1.34,1.72,1.5 mm^3 (128,128,80). I haven't looked at the code recently but I maybe I should have a peak ... Or do you mean arbitrary amongst the individual observations? Sylvain On Tue, 2 Mar 2004, Jason Lerch wrote: > > On Mar 2, 2004, at 12:40 AM, Andrew Janke wrote: > > > On Tue, 24 Feb 2004, Jason Lerch wrote: > > > >>>> On this note, glim_image and things not packaged, does anyone have > >>>> any > >>>> objections to glim_image being renamed (say to mincglm) and being > >>>> stuffed into > >>>> the base minc distro? It is a nice pure vanilla C proggie that was > >>>> 'peter blessed' from what I know. > >> > >> Urm, it's not packaged? Could have fooled me. Check the statistics > >> directory under /software/source. And I see no particular reason to > >> rename it, though I don't have any strong objections either. > > > > The general consensus on this was to package glim_image as part of an > > extra_tools package was it not? > > Why create a new package called extra_tools - doesn't conglomerate > basically fit this bill? > > > > > If all that is missing is packaging this is a somewhat easy task. > > With respect > > to the renaming issue, I would only do this such that we can > > > > a) dissociate glim_iamge from the minc_extras package > > Now I'm confused - you want to create a separate package for > glim_image? That already exists, nicely autoconfed and all. I thought > you wanted to add it to the extras package. > > > b) get a bit of consistency into minc tools names. > > Heh. Good luck. Next thing we know you'll also advocate writing some > documentation ;-) > > > > > I'm still keen for mincglm or this too broad of a name? > > Isn't there some kinda rule that apps with minc in their name are > general enough to deal with arbitrary dimensions? In which case I don't > think that glim_image would qualify. > > Jason > > _______________________________________________ > MINC-development mailing list > MINC-development@bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-development > --- Sylvain Milot (sylvain@bic.mni.mcgill.ca) Positron Imaging Laboratories Montreal Neurological Institute Webster 2B, Room 208 Montreal, Qc., Canada, H3A 2B4 Phone: (514)-398-4965, 1996 Fax: 8948 From minc-development@bic.mni.mcgill.ca Tue Mar 2 16:08:00 2004 From: minc-development@bic.mni.mcgill.ca (Jason Lerch) Date: Tue, 2 Mar 2004 11:08:00 -0500 Subject: [MINC-development] Re: glim_image In-Reply-To: References: Message-ID: On Mar 2, 2004, at 11:03 AM, Sylvain MILOT wrote: > > Hello, > > I'm not opposed to changing the name of glim_image as long as the > current version remains online with its current name. > > As for glim_image not being general enough to deal with arbitrary > dimensions, well I've used it successfully with 2mm data (91 109 91). > At least the results were very close to an analysis done with the old > traditional PET analysis template 1.34,1.72,1.5 mm^3 (128,128,80). > > I haven't looked at the code recently but I maybe I should have a peak > ... > Or do you mean arbitrary amongst the individual observations? The code hasn't changed in years, as far as I know (only the build process). I thought that it wanted 3D data, but that was a guess, so if your experience tells you otherwise than I am in all likelihood wrong! Jason > > Sylvain > > On Tue, 2 Mar 2004, Jason Lerch wrote: > >> >> On Mar 2, 2004, at 12:40 AM, Andrew Janke wrote: >> >>> On Tue, 24 Feb 2004, Jason Lerch wrote: >>> >>>>>> On this note, glim_image and things not packaged, does anyone have >>>>>> any >>>>>> objections to glim_image being renamed (say to mincglm) and being >>>>>> stuffed into >>>>>> the base minc distro? It is a nice pure vanilla C proggie that >>>>>> was >>>>>> 'peter blessed' from what I know. >>>> >>>> Urm, it's not packaged? Could have fooled me. Check the statistics >>>> directory under /software/source. And I see no particular reason to >>>> rename it, though I don't have any strong objections either. >>> >>> The general consensus on this was to package glim_image as part of an >>> extra_tools package was it not? >> >> Why create a new package called extra_tools - doesn't conglomerate >> basically fit this bill? >> >>> >>> If all that is missing is packaging this is a somewhat easy task. >>> With respect >>> to the renaming issue, I would only do this such that we can >>> >>> a) dissociate glim_iamge from the minc_extras package >> >> Now I'm confused - you want to create a separate package for >> glim_image? That already exists, nicely autoconfed and all. I thought >> you wanted to add it to the extras package. >> >>> b) get a bit of consistency into minc tools names. >> >> Heh. Good luck. Next thing we know you'll also advocate writing some >> documentation ;-) >> >>> >>> I'm still keen for mincglm or this too broad of a name? >> >> Isn't there some kinda rule that apps with minc in their name are >> general enough to deal with arbitrary dimensions? In which case I >> don't >> think that glim_image would qualify. >> >> Jason >> >> _______________________________________________ >> MINC-development mailing list >> MINC-development@bic.mni.mcgill.ca >> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-development >> > > --- > Sylvain Milot (sylvain@bic.mni.mcgill.ca) > Positron Imaging Laboratories > Montreal Neurological Institute > Webster 2B, Room 208 > Montreal, Qc., Canada, H3A 2B4 > Phone: (514)-398-4965, 1996 Fax: 8948 > > _______________________________________________ > 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 Tue Mar 2 17:56:07 2004 From: minc-development@bic.mni.mcgill.ca (Alex ZIJDENBOS) Date: Tue, 2 Mar 2004 12:56:07 -0500 Subject: [MINC-development] Re: glim_image In-Reply-To: References: Message-ID: <20040302175607.GB6589@bic.mni.mcgill.ca> On Tue, Mar 02, 2004 at 11:08:00AM -0500, Jason Lerch wrote: > On Mar 2, 2004, at 11:03 AM, Sylvain MILOT wrote: > > > >Hello, > > > >I'm not opposed to changing the name of glim_image as long as the > >current version remains online with its current name. > > > >As for glim_image not being general enough to deal with arbitrary > >dimensions, well I've used it successfully with 2mm data (91 109 91). > >At least the results were very close to an analysis done with the old > >traditional PET analysis template 1.34,1.72,1.5 mm^3 (128,128,80). > > > >I haven't looked at the code recently but I maybe I should have a peak > >... > >Or do you mean arbitrary amongst the individual observations? > > The code hasn't changed in years, as far as I know (only the build > process). I thought that it wanted 3D data, but that was a guess, so if > your experience tells you otherwise than I am in all likelihood wrong! I'm a bit confused - the 'arbitrary dimensions' referred to the number of dimensions, not the actual voxel dimensions. Does glim_image handle 2D, 4D, or nD data? If it uses voxel_loop I assume it does, but I really don't know. -- A Sko?a?u nyja vef Hjartaverndar, www.hjarta.is _____ ?essi tolvupostur og vi?hengi gati innihaldi? truna?arupplysingar og/e?a einkamal og er eingongu atla?ur ?eim sem hann er stila?ur a. Efni hans og innihald er a abyrg??ess starfsmanns sem sendir hann ef ?a? tengist ekki starfsemi Hjartaverndar Ef sending ?essi hefur ranglega borist y?ur vinsamlega gati? fyllsta truna?ar,tilkynni? sendanda og ey?ileggi? sendinguna eins og skylt er skv. 44. gr. laga nr. 107/1999 um fjarskipti. The information transmitted, including any attachment, may contain confidential and/or privileged material and is intended only for the addressee only. The contents of the message are the individual senders responsibility if it is not related to the operation of Hjartavernd If you receive this in error, please keep the information confidential, contact the sender and delete the material from your system. From minc-development@bic.mni.mcgill.ca Tue Mar 2 20:46:13 2004 From: minc-development@bic.mni.mcgill.ca (Vicka Corey) Date: Tue, 2 Mar 2004 15:46:13 -0500 Subject: [MINC-development] 64-bit linux, and a poke on os x? In-Reply-To: ; from rotor@cmr.uq.edu.au on Tue, Mar 02, 2004 at 03:40:36PM +1000 References: <20040224142811.GB2656913@shadow.bic.mni.mcgill.ca> Message-ID: <20040302154613.M15620@gate.nmr.mgh.harvard.edu> hi folks -- first, a ping about an outstanding issue: has there been an os x rebuild with -fno-common, so that i can make dynamic libraries that work? and second and de novo, has anybody built 64-bit minc libraries yet? i have started a 64-bit linux port, and am getting "incompatible" library errors for libvolume_io.a.... (if the answers to both of the above are "no", please point me to the latest in code snapshots :) thanks, --vicka From minc-development@bic.mni.mcgill.ca Tue Mar 2 20:50:57 2004 From: minc-development@bic.mni.mcgill.ca (Jason Lerch) Date: Tue, 2 Mar 2004 15:50:57 -0500 Subject: [MINC-development] 64-bit linux, and a poke on os x? In-Reply-To: <20040302154613.M15620@gate.nmr.mgh.harvard.edu> References: <20040224142811.GB2656913@shadow.bic.mni.mcgill.ca> <20040302154613.M15620@gate.nmr.mgh.harvard.edu> Message-ID: <4E3FF97A-6C8B-11D8-86DC-000A95DBBFD8@bic.mni.mcgill.ca> On Mar 2, 2004, at 3:46 PM, Vicka Corey wrote: > hi folks -- > > first, a ping about an outstanding issue: has there been an os x > rebuild > with -fno-common, so that i can make dynamic libraries that work? > Not yet. Probably won't happen this week, but maybe over the weekend or next week. > and second and de novo, has anybody built 64-bit minc libraries yet? i > have started a 64-bit linux port, and am getting "incompatible" library > errors for libvolume_io.a.... I've built 64-bit minc under IRIX. There were some issues, though I think at least the MINC library has all the resulting patches incorporated. Jason > > (if the answers to both of the above are "no", please point me to the > latest > in code snapshots :) > > 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 Wed Mar 3 00:31:30 2004 From: minc-development@bic.mni.mcgill.ca (Andrew Janke) Date: Wed, 3 Mar 2004 10:31:30 +1000 Subject: [MINC-development] Releasing glim_image upon the masses In-Reply-To: <20040302113412.GA3158384@shadow.bic.mni.mcgill.ca> References: <20040224142811.GB2656913@shadow.bic.mni.mcgill.ca> <20040302113412.GA3158384@shadow.bic.mni.mcgill.ca> Message-ID: Morning John, Peter and Keith, You may remember glim_image (mini fmristat) from times gone past, a few of us here (read: me) are interested in relasing this as an add-on package to the core MINC distribution. Do any of you as the original authors have reservations or objections to this? As far as I can tell glim_image is n-dimensional and thus would warrant inclusion. Thanks Andrew From minc-development@bic.mni.mcgill.ca Wed Mar 3 00:35:38 2004 From: minc-development@bic.mni.mcgill.ca (Andrew Janke) Date: Wed, 3 Mar 2004 10:35:38 +1000 Subject: [MINC-development] Re: glim_image In-Reply-To: References: <20040224142811.GB2656913@shadow.bic.mni.mcgill.ca> Message-ID: On Tue, 2 Mar 2004, Jason Lerch wrote: > > The general consensus on this was to package glim_image as part of an > > extra_tools package was it not? > > Why create a new package called extra_tools - doesn't conglomerate > basically fit this bill? Surely you jest? Conglomerate is currently littered with stand-alone C-programs that can be replaced with more general perl 10 liners. > > a) dissociate glim_iamge from the minc_extras package > > Now I'm confused - you want to create a separate package for > glim_image? That already exists, nicely autoconfed and all. I thought > you wanted to add it to the extras package. glim_image is already autoconfed. As is mincmorph and mincblob and a few others. I am thinking about mashing these and a few others into a minc-extras type package. There is no reason as to why they cannot all exist separately though, in some ways this is better as when we relase a bug-fix for one package the whole lot don't have to be re-released. > > b) get a bit of consistency into minc tools names. > > Heh. Good luck. Next thing we know you'll also advocate writing some > documentation ;-) heh. > > I'm still keen for mincglm or this too broad of a name? > > Isn't there some kinda rule that apps with minc in their name are > general enough to deal with arbitrary dimensions? In which case I don't > think that glim_image would qualify. glim_image does handle arbitrary dimensionality IIRC. a From minc-development@bic.mni.mcgill.ca Wed Mar 3 00:49:23 2004 From: minc-development@bic.mni.mcgill.ca (Andrew Janke) Date: Wed, 3 Mar 2004 10:49:23 +1000 Subject: [MINC-development] Re: glim_image In-Reply-To: <20040302175607.GB6589@bic.mni.mcgill.ca> References: <20040302175607.GB6589@bic.mni.mcgill.ca> Message-ID: On Tue, 2 Mar 2004, Alex ZIJDENBOS wrote: > I'm a bit confused - the 'arbitrary dimensions' referred to the number > of dimensions, not the actual voxel dimensions. Does glim_image handle > 2D, 4D, or nD data? If it uses voxel_loop I assume it does, but I > really don't know. glim_image uses voxel_loop (why wouldn't it? these are voxel-based stats on hopefully pre-blurred data) It also happens to include volume_io, but from my trawl through the code not for data in/out-put a From minc-development@bic.mni.mcgill.ca Wed Mar 3 01:15:39 2004 From: minc-development@bic.mni.mcgill.ca (Peter NEELIN) Date: Tue, 2 Mar 2004 20:15:39 -0500 Subject: [MINC-development] Re: Releasing glim_image upon the masses In-Reply-To: Message-ID: On Wed, 3 Mar 2004, Andrew Janke wrote: > You may remember glim_image (mini fmristat) from times gone past, a few of us > here (read: me) are interested in relasing this as an add-on package to the core > MINC distribution. > > Do any of you as the original authors have reservations or objections to this? > As far as I can tell glim_image is n-dimensional and thus would warrant > inclusion. I only contributed in a minor way (advice at the beginning and a few patches later), so I don't really have much of a say in this. But I have always been in favour of freely distributing glim_image (or mincglm, if you prefer), and I still am. Peter ---- Peter Neelin (neelin@bic.mni.mcgill.ca) From minc-development@bic.mni.mcgill.ca Wed Mar 3 01:27:33 2004 From: minc-development@bic.mni.mcgill.ca (Peter NEELIN) Date: Tue, 2 Mar 2004 20:27:33 -0500 Subject: [MINC-development] 64-bit linux, and a poke on os x? In-Reply-To: <4E3FF97A-6C8B-11D8-86DC-000A95DBBFD8@bic.mni.mcgill.ca> Message-ID: On Tue, 2 Mar 2004, Jason Lerch wrote: > On Mar 2, 2004, at 3:46 PM, Vicka Corey wrote: > > and second and de novo, has anybody built 64-bit minc libraries yet? i > > have started a 64-bit linux port, and am getting "incompatible" library > > errors for libvolume_io.a.... > > I've built 64-bit minc under IRIX. There were some issues, though I > think at least the MINC library has all the resulting patches > incorporated. Depending on what one means by 64-bit, I believe that John Sled built a 64-bit version for linux a while back. I believe that in his case, 64-bit referred to file size only, allowing the minc file to exceed 2 GB. I made some code re-arrangements to ensure that image data always appeared at the end of the file, since NetCDF variable offsets are 32-bit. I think that the program memory space was still 32-bit, so one could only use volume_io programs that used caching. John, is this correct? Peter ---- Peter Neelin (neelin@bic.mni.mcgill.ca) From minc-development@bic.mni.mcgill.ca Fri Mar 5 22:34:56 2004 From: minc-development@bic.mni.mcgill.ca (John G. Sled) Date: Fri, 5 Mar 2004 16:34:56 -0600 Subject: [MINC-development] 64-bit linux, and a poke on os x? In-Reply-To: References: <4E3FF97A-6C8B-11D8-86DC-000A95DBBFD8@bic.mni.mcgill.ca> Message-ID: <20040305223456.GD30698@sickkids.ca> On Tue, Mar 02, 2004 at 08:27:33PM -0500, Peter NEELIN wrote: > On Tue, 2 Mar 2004, Jason Lerch wrote: > > > On Mar 2, 2004, at 3:46 PM, Vicka Corey wrote: > > > and second and de novo, has anybody built 64-bit minc libraries yet? i > > > have started a 64-bit linux port, and am getting "incompatible" library > > > errors for libvolume_io.a.... > > > > I've built 64-bit minc under IRIX. There were some issues, though I > > think at least the MINC library has all the resulting patches > > incorporated. > > Depending on what one means by 64-bit, I believe that John Sled built a > 64-bit version for linux a while back. I believe that in his case, 64-bit > referred to file size only, allowing the minc file to exceed 2 GB. I made > some code re-arrangements to ensure that image data always appeared at the > end of the file, since NetCDF variable offsets are 32-bit. I think that > the program memory space was still 32-bit, so one could only use volume_io > programs that used caching. John, is this correct? > Yes, that is true. I ran into some troubles with volume_io and large files, though, that I haven't pursued. John > 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 Tue Mar 9 22:01:53 2004 From: minc-development@bic.mni.mcgill.ca (Vicka Corey) Date: Tue, 9 Mar 2004 17:01:53 -0500 Subject: [MINC-development] ftp site? Message-ID: <20040309170152.P3774@gate.nmr.mgh.harvard.edu> hi folks -- is there something up with ftp://ftp.bic.mni.mcgill.ca/pub/minc/ ? i am trying to download the source (for my opteron build) and can't seem to get to it... thanks, --vicka From minc-development@bic.mni.mcgill.ca Tue Mar 9 22:31:27 2004 From: minc-development@bic.mni.mcgill.ca (Reza ADALAT) Date: Tue, 9 Mar 2004 17:31:27 -0500 Subject: [MINC-development] ftp site? In-Reply-To: <20040309170152.P3774@gate.nmr.mgh.harvard.edu> Message-ID: Hi Vicka, For downloading the BIC software, instead of the ftp site, go to: http://www.bic.mni.mcgill.ca/software/distribution/ Regards, Reza >> On Tue, 9 Mar 2004, Vicka Corey wrote: > hi folks -- is there something up with ftp://ftp.bic.mni.mcgill.ca/pub/minc/ ? > i am trying to download the source (for my opteron build) and can't seem to > get to it... > > 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 Tue Mar 16 18:00:02 2004 From: minc-development@bic.mni.mcgill.ca (Vicka Corey) Date: Tue, 16 Mar 2004 13:00:02 -0500 Subject: [MINC-development] flags for 64-bit opteron compilation Message-ID: <20040316130002.A14203@gate.nmr.mgh.harvard.edu> just a little note: i am working on a 64-bit opteron amd freesurfer port, using suse linux and gcc 3.2.2. had to add the -fPIC and -DPIC flags to builds of netcdf and minc to get libraries i could use without errors at compile (of course, i have yet to see if they actually work :) mostly wanted to get this into the archive... cheers --vicka