From a.janke at gmail.com Mon Sep 24 13:22:36 2012 From: a.janke at gmail.com (Andrew Janke) Date: Mon, 24 Sep 2012 13:22:36 -0400 Subject: [MINC-development] minc 2.2.00 Message-ID: Hi all, find it here: http://packages.bic.mni.mcgill.ca/tgz/minc-2.2.00.tar.gz There are a number of updates in here (addition of mincmorph, mincsample, etc). There are also a few changes in the libminc2 API regarding a number of bugs that have cropped up. I am at the BIC for a few days so Vladimir and myself have taken it upon ourselves to get MINC integrated into ITK a whole lot better (and easier) than it currently is. What this means is that we are now working on breaking MINC up into a library component (libminc) and minc-tools as per how the debian packages that Steve Robbins builds. This will make for an easier ITK/MINC integration and hopefully make things easier for things like python + minc. One of the major things we will do as part of this is attempt to make a libMINC that is MINC2 only and removes all the netCDF bits. This will mean a lot of code in volume_io will need to shift into MINC 2 proper (xfms, tags, etc). Of course this will be done as an option to the build process. So, comments? a From sean at rogue-research.com Mon Sep 24 20:28:15 2012 From: sean at rogue-research.com (Sean McBride) Date: Mon, 24 Sep 2012 20:28:15 -0400 Subject: [MINC-development] minc 2.2.00 In-Reply-To: References: Message-ID: <20120925002815.494986121@mail.rogue-research.com> On Mon, 24 Sep 2012 13:22:36 -0400, Andrew Janke said: >I am at the BIC for a few days so Vladimir and myself have taken it >upon ourselves to get MINC integrated into ITK a whole lot better (and >easier) than it currently is. What this means is that we are now >working on breaking MINC up into a library component (libminc) and >minc-tools as per how the debian packages that Steve Robbins builds. >This will make for an easier ITK/MINC integration and hopefully make >things easier for things like python + minc. > >One of the major things we will do as part of this is attempt to make >a libMINC that is MINC2 only and removes all the netCDF bits. This >will mean a lot of code in volume_io will need to shift into MINC 2 >proper (xfms, tags, etc). Of course this will be done as an option to >the build process. > >So, comments? +1 for ITK support! Maybe I misunderstand the last paragraph, but I hope said ITK reader be able to read both MINC1 and MINC2 files? At least optionally. Being able to optionally exclude the NetCDF dependency could be helpful to getting your MINCReader into ITK proper since, IIRC, ITK already includes HDF5 but not NetCDF. Cheers, -- ____________________________________________________________ Sean McBride, B. Eng sean at rogue-research.com Rogue Research www.rogue-research.com Mac Software Developer Montr?al, Qu?bec, Canada From vladimir.fonov at gmail.com Mon Sep 24 20:33:14 2012 From: vladimir.fonov at gmail.com (Vladimir S. Fonov) Date: Mon, 24 Sep 2012 20:33:14 -0400 Subject: [MINC-development] minc 2.2.00 In-Reply-To: <20120925002815.494986121@mail.rogue-research.com> References: <20120925002815.494986121@mail.rogue-research.com> Message-ID: <5060FBCA.1060502@gmail.com> Hello, It looks like we are going to rewrite ITK minc reader/writer to MINC2 API (currently my implementation uses MINC1 API), which means that minc1 files will not be directly supported. However, we might add a system call to mincconvert to convert minc1 into minc2 for reading. On 12-09-24 08:28 PM, Sean McBride wrote: > > +1 for ITK support! > > Maybe I misunderstand the last paragraph, but I hope said ITK reader be able to read both MINC1 and MINC2 files? At least optionally. Being able to optionally exclude the NetCDF dependency could be helpful to getting your MINCReader into ITK proper since, IIRC, ITK already includes HDF5 but not NetCDF. -- Best regards, Vladimir S. Fonov ~ vladimir.fonov gmail.com From a.janke at gmail.com Mon Sep 24 20:34:07 2012 From: a.janke at gmail.com (Andrew Janke) Date: Mon, 24 Sep 2012 20:34:07 -0400 Subject: [MINC-development] minc 2.2.00 In-Reply-To: <20120925002815.494986121@mail.rogue-research.com> References: <20120925002815.494986121@mail.rogue-research.com> Message-ID: >>One of the major things we will do as part of this is attempt to make >>a libMINC that is MINC2 only and removes all the netCDF bits. This >>will mean a lot of code in volume_io will need to shift into MINC 2 >>proper (xfms, tags, etc). Of course this will be done as an option to >>the build process. > +1 for ITK support! > > Maybe I misunderstand the last paragraph, but I hope said ITK reader be able to read both MINC1 and MINC2 files? We are aiming for MINC2 only (easily) At this point. > At least optionally. Being able to optionally exclude the NetCDF dependency could be helpful to getting your MINCReader into ITK proper since, IIRC, ITK already includes HDF5 but not NetCDF. And this is the point exactly. The idea is to have an option in the libminc build that will disable MINC1 (as compared to before where you enable MINC2). This is for the reason that you point out with HDF5 being in ITK already. As part of this we will shift a few chunks of volume_io to minc2 that are required. At the moment this is for reading of transforms and tag files only so that ITK can support these also. As for MINC1 support, Vlads ezminc based ITK reader already does this as does the original one for ITK. Still it's messy and the netCDF dependency precludes MINC's inclusion into ITK so MINC2 only it is. As for MINC1 files, the best way around this that I see is a stand-alone mincconvert. a From a.janke at gmail.com Mon Sep 24 20:34:17 2012 From: a.janke at gmail.com (Andrew Janke) Date: Mon, 24 Sep 2012 20:34:17 -0400 Subject: [MINC-development] minc 2.2.00 In-Reply-To: <5060FBCA.1060502@gmail.com> References: <20120925002815.494986121@mail.rogue-research.com> <5060FBCA.1060502@gmail.com> Message-ID: beaten to the punch! a On 24 September 2012 20:33, Vladimir S. Fonov wrote: > It looks like we are going to rewrite ITK minc reader/writer to MINC2 API > (currently my implementation uses MINC1 API), which means that minc1 files > will not be directly supported. However, we might add a system call to > mincconvert to convert minc1 into minc2 for reading. From sean at rogue-research.com Mon Sep 24 21:01:54 2012 From: sean at rogue-research.com (Sean McBride) Date: Mon, 24 Sep 2012 21:01:54 -0400 Subject: [MINC-development] minc 2.2.00 In-Reply-To: References: <20120925002815.494986121@mail.rogue-research.com> Message-ID: <20120925010154.383132700@mail.rogue-research.com> On Mon, 24 Sep 2012 20:34:07 -0400, Andrew Janke said: >And this is the point exactly. The idea is to have an option in the >libminc build that will disable MINC1 (as compared to before where you >enable MINC2). Understandably desirable. >As part of this we will shift a few chunks of volume_io to minc2 that >are required. At the moment this is for reading of transforms and tag >files only so that ITK can support these also. Nice. >As for MINC1 support, Vlads ezminc based ITK reader already does this >as does the original one for ITK. To what do you refer by "the original one for ITK". Do you mean itkMINC2ImageIO in ITK3? It only does MINC2. >Still it's messy and the netCDF >dependency precludes MINC's inclusion into ITK so MINC2 only it is. Does it? Did anyone ask the ITK maintainers about this? >As for MINC1 files, the best way around this that I see is a >stand-alone mincconvert. We currently use ITK3 to read ACR-NEMA, DICOM, PAR/REC, Analyze, NIfTI-1, and MINC2. And I use VTK to read MINC1 (vtkMINCImageReader). I was really hoping some future MINC reader from you guys could do both MINC1&2 so that ITK could open everything. :) It's understandable that the ITK devs might not want to add yet another 3rd party library (NetCDF) to ITK. But for all the 3rd party libs ITK includes, it also lets you point to your own copy, instead of ITK's, ex: ITK_USE_SYSTEM_ZLIB. Perhaps ITK could at least let you point it to your own NetCDF then your reader could have some "#ifdef NETCDF_FOUND" stuff to support MINC1 files anyway? Cheers, -- ____________________________________________________________ Sean McBride, B. Eng sean at rogue-research.com Rogue Research www.rogue-research.com Mac Software Developer Montr?al, Qu?bec, Canada From jason at phenogenomics.ca Mon Sep 24 21:29:30 2012 From: jason at phenogenomics.ca (Jason Lerch) Date: Mon, 24 Sep 2012 21:29:30 -0400 Subject: [MINC-development] minc 2.2.00 In-Reply-To: References: Message-ID: On 2012-09-24, at 1:22 PM, Andrew Janke wrote: [snip] Yay to the revisited libMINC! > One of the major things we will do as part of this is attempt to make > a libMINC that is MINC2 only and removes all the netCDF bits. This > will mean a lot of code in volume_io will need to shift into MINC 2 > proper (xfms, tags, etc). Of course this will be done as an option to > the build process. Not quite sure I understand this bit - surely volume_io will remain as part of the MINC distribution, right? Why would this core functionality have to move libraries - or is there some dependency that volume_io has on netCDF that can't be altered without tossing the baby out with the bathwater? Jason -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladimir.fonov at gmail.com Mon Sep 24 21:43:10 2012 From: vladimir.fonov at gmail.com (Vladimir S. Fonov) Date: Mon, 24 Sep 2012 21:43:10 -0400 Subject: [MINC-development] minc 2.2.00 In-Reply-To: <20120925010154.383132700@mail.rogue-research.com> References: <20120925002815.494986121@mail.rogue-research.com> <20120925010154.383132700@mail.rogue-research.com> Message-ID: <50610C2E.90205@gmail.com> Hello, On 24/09/2012 9:01 PM, Sean McBride wrote: >> Still it's messy and the netCDF >> dependency precludes MINC's inclusion into ITK so MINC2 only it is. > > Does it? Did anyone ask the ITK maintainers about this? ITK maintainers are not thrilled with dependency on external library. >> As for MINC1 files, the best way around this that I see is a >> stand-alone mincconvert. > > We currently use ITK3 to read ACR-NEMA, DICOM, PAR/REC, Analyze, > NIfTI-1, and MINC2. And I use VTK to read MINC1 > (vtkMINCImageReader). I was really hoping some future MINC reader > from you guys could do both MINC1&2 so that ITK could open > everything. :) Have you seen https://github.com/BIC-MNI/minc4itk ? It have been out there for about half a year, I think. Minc1&2 support for ITK 3 & 4 , unfortunately relies on externally built minc. > It's understandable that the ITK devs might not want to add yet > another 3rd party library (NetCDF) to ITK. But for all the 3rd party > libs ITK includes, it also lets you point to your own copy, instead > of ITK's, ex: ITK_USE_SYSTEM_ZLIB. Perhaps ITK could at least let > you point it to your own NetCDF then your reader could have some > "#ifdef NETCDF_FOUND" stuff to support MINC1 files anyway? It might also require substantial time commitment that nobody is willing to make. -- Best regards, Vladimir S. Fonov ~ vladimir fonov gmail com From a.janke at gmail.com Mon Sep 24 21:47:52 2012 From: a.janke at gmail.com (Andrew Janke) Date: Mon, 24 Sep 2012 21:47:52 -0400 Subject: [MINC-development] minc 2.2.00 In-Reply-To: References: Message-ID: > Yay to the revisited libMINC! Indeed. See: https://github.com/BIC-MNI/libminc For a sneak-peak. It's not complete yet. The CMake build should be good, the autoconf/make one needs work still. > Not quite sure I understand this bit - surely volume_io will remain as part > of the MINC distribution, right? Correct. > Why would this core functionality have to > move libraries - or is there some dependency that volume_io has on netCDF > that can't be altered without tossing the baby out with the bathwater? We want a MINC2 only build (via a build configuration option) for linking with ITK. ITK should also be able to read MINC xfms + tags as per the current MINC-ITK interfaces. volume_io requires netcdf, but the xfm+tags bits don't. Thus it makes sense to shift the xfm + tag readers from volume_io into minc2. And yes if you turn off the minc2 only build option you will still get everything just as before. a From baghdadi at phenogenomics.ca Tue Sep 25 11:23:20 2012 From: baghdadi at phenogenomics.ca (Leila Baghdadi) Date: Tue, 25 Sep 2012 11:23:20 -0400 Subject: [MINC-development] minc 2.2.00 Message-ID: <20260943.205321348586600300.JavaMail.root@mail2.phenogenomics.ca> Hi andrew, I have been wanting a minc2 only release since the day we finished minc2 development, please count me in as one of the helpers for this, its always fun to do minc2 development even if it means I have to do it at home with my kids screaming in the background ;) thanks again for all your efforts Leila ----- Original Message ----- From: Andrew Janke Sent: Mon, 9/24/2012 9:47pm To: MINC development discussion & planning Subject: Re: [MINC-development] minc 2.2.00 > Yay to the revisited libMINC! Indeed. See: https://github.com/BIC-MNI/libminc For a sneak-peak. It's not complete yet. The CMake build should be good, the autoconf/make one needs work still. > Not quite sure I understand this bit - surely volume_io will remain as part > of the MINC distribution, right? Correct. > Why would this core functionality have to > move libraries - or is there some dependency that volume_io has on netCDF > that can't be altered without tossing the baby out with the bathwater? We want a MINC2 only build (via a build configuration option) for linking with ITK. ITK should also be able to read MINC xfms + tags as per the current MINC-ITK interfaces. volume_io requires netcdf, but the xfm+tags bits don't. Thus it makes sense to shift the xfm + tag readers from volume_io into minc2. And yes if you turn off the minc2 only build option you will still get everything just as before. a _______________________________________________ MINC-development mailing list MINC-development at bic.mni.mcgill.ca http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-development From sean at rogue-research.com Tue Sep 25 20:05:14 2012 From: sean at rogue-research.com (Sean McBride) Date: Tue, 25 Sep 2012 20:05:14 -0400 Subject: [MINC-development] minc 2.2.00 In-Reply-To: <50610C2E.90205@gmail.com> References: <20120925002815.494986121@mail.rogue-research.com> <20120925010154.383132700@mail.rogue-research.com> <50610C2E.90205@gmail.com> Message-ID: <20120926000514.354061635@mail.rogue-research.com> On Mon, 24 Sep 2012 21:43:10 -0400, Vladimir S. Fonov said: >ITK maintainers are not thrilled with dependency on external library. Understandable of course. What about libminc itself? Do you think it'll be small enough for them to include in ITK itself? >Have you seen https://github.com/BIC-MNI/minc4itk ? It have been out >there for about half a year, I think. Minc1&2 support for ITK 3 & 4 , >unfortunately relies on externally built minc. I think I've seen it, but never tried... I've added it to my todo list. :) Cheers, -- ____________________________________________________________ Sean McBride, B. Eng sean at rogue-research.com Rogue Research www.rogue-research.com Mac Software Developer Montr?al, Qu?bec, Canada From sean at rogue-research.com Sun Sep 30 18:30:10 2012 From: sean at rogue-research.com (Sean McBride) Date: Sun, 30 Sep 2012 18:30:10 -0400 Subject: [MINC-development] minc 2.2.00 In-Reply-To: References: Message-ID: <20120930223010.201533602@mail.rogue-research.com> On Mon, 24 Sep 2012 13:22:36 -0400, Andrew Janke said: >find it here: > > http://packages.bic.mni.mcgill.ca/tgz/minc-2.2.00.tar.gz It doesn't build for me, with a pretty basic configure/make: libtool: link: /usr/bin/gcc-4.2 -w -isysroot /Developer/SDKs/MacOSX10.5.sdk -O0 -fstack-protector-all -D_FORTIFY_SOURCE=2 -arch i386 -o mincexample2 progs/mincexample/mincexample2.o -L/Users/builder/official_builds/netcdf-debug-i386/lib -L/Users/builder/official_builds/hdf5-debug-i386/lib ./.libs/libvolume_io2.a ./.libs/libminc2.a /Users/builder/official_builds/hdf5-1.8.9/../hdf5-debug-i386/lib/libhdf5.a -lz /Users/builder/official_builds/netcdf-4.2.1.1/../netcdf-debug-i386/lib/libnetcdf.a -lm /usr/bin/pod2man --section=1 progs/minccomplete/minccomplete > progs/minccomplete/minccomplete.man1 /usr/bin/pod2man --section=1 progs/minchistory/minchistory > progs/minchistory/minchistory.man1 /usr/bin/pod2man --section=1 progs/mincpik/mincpik > progs/mincpik/mincpik.man1 ezminc/examples/CMakeLists.txt make[2]: ezminc/examples/CMakeLists.txt: No such file or directory make[2]: *** [progs/mincpik/mincpik.man1] Error 1 make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2 Indeed the "ezminc/examples" folder has only one file: "volume_msq_dist.cpp" So then I tried building with cmake, and that worked. Is cmake now the preferred build system? (I prefer it, but want to use whatever is most stable/tested.) Cheers, -- ____________________________________________________________ Sean McBride, B. Eng sean at rogue-research.com Rogue Research www.rogue-research.com Mac Software Developer Montr?al, Qu?bec, Canada