From rboyes@dementia.ion.ucl.ac.uk Fri Sep 5 10:23:30 2003 From: rboyes@dementia.ion.ucl.ac.uk (Richard Boyes) Date: Fri, 5 Sep 2003 10:23:30 +0100 Subject: [MINC-development] mincstats Message-ID: This is a multi-part message in MIME format. ------=_NextPart_000_0005_01C37397.C08D7DA0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit hi all, while using mincstats i got a segfault from the following: rboyes@drg43:/tmp/minctest /home/packages/bin/mincstats -clobber -histogram hist correct14457.mnc Segmentation fault which seems to occur because i didn't supply a mask, which some of the output requires (if a mask is not passed in you end up printing a null pointer which gives a seg fault). A diff file to apply a fix is attached if anyone wants it. richard. ------=_NextPart_000_0005_01C37397.C08D7DA0 Content-Type: application/octet-stream; name="mincstats.diff" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="mincstats.diff" 325d324=0A= < =0A= 327c326=0A= < =0A= ---=0A= > =0A= 329c328=0A= < nfiles++;=0A= ---=0A= > nfiles++;=0A= 637,639c636=0A= < if(infiles[1] !=3D NULL) {=0A= < (void) fprintf(FP, "# mask file: %s\n", infiles[1]);=0A= < }=0A= ---=0A= > (void) fprintf(FP, "# mask file: %s\n", = infiles[1]);=0A= 692c689=0A= < if (All && !quiet && (infiles[1] !=3D NULL)) { (void) = fprintf(stdout, "Mask file: %s\n", infiles[1]);}=0A= ---=0A= > if (All && !quiet) { (void) fprintf(stdout, "Mask file: = %s\n", infiles[1]);}=0A= ------=_NextPart_000_0005_01C37397.C08D7DA0-- From minc-development@bic.mni.mcgill.ca Fri Sep 5 18:23:47 2003 From: minc-development@bic.mni.mcgill.ca (Robert VINCENT) Date: Fri, 5 Sep 2003 13:23:47 -0400 Subject: [MINC-development] mincstats In-Reply-To: Message-ID: Richard, Thanks for the submission - I'll apply the fix to the source tree. -bert On Fri, 5 Sep 2003, Richard Boyes wrote: > hi all, > > while using mincstats i got a segfault from the following: > > rboyes@drg43:/tmp/minctest /home/packages/bin/mincstats -clobber -histogram > hist correct14457.mnc > Segmentation fault > > which seems to occur because i didn't supply a mask, which some > of the output requires (if a mask is not passed in you end up printing > a null pointer which gives a seg fault). A diff file to apply a > fix is attached if anyone wants it. > > richard. > From minc-development@bic.mni.mcgill.ca Tue Sep 16 11:49:45 2003 From: minc-development@bic.mni.mcgill.ca (Chris Cocosco) Date: Tue, 16 Sep 2003 06:49:45 -0400 Subject: [MINC-development] Windoze Message-ID: Hi all, Many people in the medical imaging community develop software for MS-Windows, so I think that having MINC (and even volume_io) for Win32 would be very helpful for enlarging the MINC user community... (by the way, Unidata.UCAR also has a win32 port of netcdf-3.5.0) On the same topic, a pure-Java MINC library would be helpful too. As far as I can tell, Java is still the easiest way to write "platform independent" portable software or web-based viewers. Moreover, even when one is not concerned with portability, these days many developers prefer Java over C++. Again, Unidata also has a pure-Java version of NetCDF (and I suppose there's a Java HDF5 library available too), so only the core MINC library would have to be ported... maybe this could be added to the wish list for MINC 2.0 ? --Chris Cocosco Robert Vincent wrote: } Hi all, } } I entertained myself this weekend by building NetCDF 3.5 and MINC 1.1 on } Windows ME (I lead an exciting life, huh?). I have no idea if this was } actually a useful exercise. Can I get a show of hands? How many folks out } there could use MINC on Windows if it were generally available? And what } other pieces besides the core distribution would have to be ported for the } whole package to be truly useful? } } I created Makefiles for both GNU make (from Cygwin) and Microsoft NMAKE. } I just used Microsoft's compiler; it handles 99.9% of the code just fine - } I had to add a few #ifdefs here and there, perhaps changing 10 or 20 lines } of code. I tried several of the NetCDF and MINC tests and everything } checked out fine, although there is a minor but annoying inconsistency in } floating-point output from printf(). } } There are several large questions to be answered yet, though - for } example, how to handle shell and perl scripts. Obviously there are } solutions; I'm curious if anyone knows of an especially good perl } implementation for Win32. } } If anyone is interested, I have a binary ZIP file I can make available for } evaluation & testing purposes. Otherwise I'll just find other ways to } entertain myself next weekend... } } -bert } From minc-development@bic.mni.mcgill.ca Wed Sep 17 16:46:24 2003 From: minc-development@bic.mni.mcgill.ca (minc-development@bic.mni.mcgill.ca) Date: Wed, 17 Sep 2003 11:46:24 -0400 Subject: [MINC-development] MINC as a platform-independent portable web-friendly platform Message-ID: <20030917154624.BBCR7817.tomts7-srv.bellnexxia.net@[209.226.175.20]> Hello, If I may share a few, general thoughts.... I agree with Chris in recognizing the need to write portable software that runs on a variety of computing platforms. Ensuring portability and platform-independence of medical imaging software should be a primary concern. These issues should be considered early in the design and development of the application software. Also, I think that it is worthwhile to invest time in the early stages of development so that a software system (like MINC libraries, core and applications, in the actual layering) has built-in support for extensibility and modifiability to be able to handle future change in requirements (like the shift from minc 1.1 to 2.0). How ? Many design patterns address those requirements. How to achieve portable software? One way is through the development/reuse of host infrastructure middleware that provides an OS abstraction layer that shields application software from the details of the underlying OS. I am thinking about things like ACE, for networked applications. As for which language to use to implement the design, Java, being object-oriented and web-friendly, seems a good avenue. My humble 2 cents... Yves Roy From minc-development@bic.mni.mcgill.ca Wed Sep 17 18:58:22 2003 From: minc-development@bic.mni.mcgill.ca (Jason Lerch) Date: Wed, 17 Sep 2003 13:58:22 -0400 Subject: [MINC-development] MINC as a platform-independent portable web-friendly platform In-Reply-To: <20030917154624.BBCR7817.tomts7-srv.bellnexxia.net@[209.226.175.20]> References: <20030917154624.BBCR7817.tomts7-srv.bellnexxia.net@[209.226.175.20]> Message-ID: <1063821501.26113.34.camel@dennis.bic.mni.mcgill.ca> Greetings all, consider this a dissenting voice: I don't like Java, I don't particularly care if something is web-enabled or not, and I care even less if our software can run on Windows. Now, I realise that all of these concerns (windows, web, etc.) are important to many people, and justifiably so. But not at the expense of writing decent software to advance research in brain-imaging. So what are the pros for sticking with the good old C/C++/P{erl,ython} combo? They are threefold: 1) speed. Java is still slow. Some more hardware intensive stuff (i.e. graphics pipes on the ONYX) might only be accessible in C. 2) We are used to them. There is a lot of expertise in writing C code and perl scripts; one would have to present many good reasons to move away from that combo and into a different framework. 3) Libraries. We have them in C, we use many external ones written in C. I'm sure similar ones can be found in Java, but again a lot would have to be relearned. Furthermore, the C/C++ and scripting language combo is surprisingly portable, esepcially when used together with some autoconfiscation mechanism. And Java can be surprisingly unportable considering that that is what it was designed for (case in point: "synch all cursors" in JIV). And C/C++ and scripting gives you access to the object oriented world without trying to lock you into it. So I have no objections to someone writing a Java wrapper to MINC. But I would be unhappy if that became the standard development platform we are supposed to work in. Jason On Wed, 2003-09-17 at 11:46, yvesroy_@sympatico.ca wrote: > Hello, > > If I may share a few, general thoughts.... > > I agree with Chris in recognizing the need to write portable software > that runs on a variety of computing platforms. Ensuring portability and platform-independence of medical imaging software should be a primary concern. These issues should be considered early in the design and development of the application software. > > Also, I think that it is worthwhile to invest time in the early stages of development so that a software system (like MINC libraries, core and applications, in the actual layering) has built-in support for extensibility and modifiability to be able to handle future change in requirements (like the shift from minc 1.1 to 2.0). How ? Many design patterns address those requirements. > > How to achieve portable software? One way is through the development/reuse of host infrastructure middleware that provides an OS abstraction layer that shields application software from the details of the underlying OS. I am thinking about things like ACE, for networked applications. > > As for which language to use to implement the design, Java, being object-oriented and web-friendly, seems a good avenue. > > My humble 2 cents... > > Yves Roy > > > _______________________________________________ > 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 Sep 18 04:38:16 2003 From: minc-development@bic.mni.mcgill.ca (Andrew Janke) Date: Thu, 18 Sep 2003 13:38:16 +1000 Subject: [MINC-development] MINC as a platform-independent portable web-friendly platform In-Reply-To: <1063821501.26113.34.camel@dennis.bic.mni.mcgill.ca> References: <20030917154624.BBCR7817.tomts7-srv.bellnexxia.net@[209.226.175.20]> <1063821501.26113.34.camel@dennis.bic.mni.mcgill.ca> Message-ID: On Wed, 17 Sep 2003, Jason Lerch wrote: > consider this a dissenting voice: I don't like Java, me too. > Now, I realise that all of these concerns (windows, web, etc.) are important > to many people, and justifiably so. But not at the expense of writing decent > software to advance research in brain-imaging. Cannot agree more, I don't ever see MINC as a tool for the masses. Thats SPM/FSL's job. Mind you, I'm not stopping anyone from writing a java extension for MINC. -- Andrew Janke ( rotor@cmr.uq.edu.au || www.cmr.uq.edu.au/~rotor ) Australia->University of Queensland->Centre for Magnetic Resonance W: +61 7 3365 4100 || H: +61 7 3800 4042 || M: +61 4 2138 8581