From stebollmann at gmail.com Thu Feb 1 04:48:49 2018 From: stebollmann at gmail.com (Steffen Bollmann) Date: Thu, 1 Feb 2018 19:48:49 +1000 Subject: [MINC-users] new version of minc-toolkit-v2 is release In-Reply-To: References: Message-ID: Dear Vladimir, Thank you for also providing singularity and docker containers :) I think I spotted a little typo on the website: - Docker minc-toolkit-v1 1.0.09: docker pull nistmni/minc-toolkit:1.9.16 Thank you Best Steffen 2018-01-25 6:33 GMT+10:00 Vladimir S. FONOV : > Hello Again, > > small correction, the download link for MacOS X version is > http://packages.bic.mni.mcgill.ca/minc-toolkit/MacOSX/ > minc-toolkit-1.9.16-20180117-Darwin-x86_64.dmg > tomorrow it will get updated to the correct one : > http://packages.bic.mni.mcgill.ca/minc-toolkit/MacOSX/ > minc-toolkit-1.9.16-20180117-Darwin-10.8-x86_64.dmg > > On 24 January 2018 at 14:23, Vladimir S. FONOV > wrote: > > > Hello Everybody, > > > > I released a new version of the minc-toolkit-v2, version 1.9.16 > > > > It includes all the changes to libminc, minctools, Display, Register etc > > as of 20181117, also it is build based on NetCDF version 4.5.0, HDF5 > > version 1.8.20 , ITK version 4.13.0 > > > > > > The links to download are here: http://bic-mni.github.io/ > > > > I also created several containers to simplify installation: > > > > All Containers are based on Ubuntu 16.04 64bit and include R 3.4.3 + > > tidyverse + RMINC 1.5.1.0 , python 2.7 + pyminc + pyezminc + minc2_simple > > and also standard anatomical models and beast templates installed in > > /opt/minc > > > > Docker minc-toolkit-v2 1.9.16: docker pull nistmni/minc-toolkit:1.9.16 > > Docker minc-toolkit-v1 1.0.09: docker pull nistmni/minc-toolkit:1.9.16 > > Singularity minc-toolkit-v2 1.9.16: singularity pull --name > > minc-toolkit-1.9.16.simg shub://vfonov/minc-toolkit-containers:1.9.16 > > > > Also I created containers without anatomical templates and visual tools > > (mostly to save space): > > > > Docker minc-toolkit-v2 1.9.16: "docker pull > nistmni/minc-toolkit-min:1.9.1 > > 6" > > Singulatity minc-toolkit-v2 1.9.16: "singularity pull --name > > minc-toolkit-1.9.16-min.simg shub://vfonov/vfonov/minc-tool > > kit-containers:1.9.16-min" > > > > > > It is fairly easy to make your own containers, the source code for making > > containers from above are here: https://github.com/vfonov/minc > > -toolkit-containers > > > > Also, if you need to build minc-toolkit for another distribution , you > can > > modify docker-based build system: https://github.com/BIC-MNI/bui > > ld_packages > > > > > > -- > > Best regards, > > > > Vladimir S. FONOV ~ vladimir.fonov gmail.com > > > > > > -- > Best regards, > > Vladimir S. Fonov ~ vladimir fonov gmail com > _______________________________________________ > MINC-users at bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users > From vladimir.fonov at gmail.com Thu Feb 1 16:03:08 2018 From: vladimir.fonov at gmail.com (Vladimir S. FONOV) Date: Thu, 1 Feb 2018 16:03:08 -0500 Subject: [MINC-users] new version of minc-toolkit-v2 is release In-Reply-To: References: Message-ID: <1b01c223-1889-2a61-08aa-8df49564c9a7@gmail.com> Thank you, I fixed it on the web site. On 2018-02-01 04:48 AM, Steffen Bollmann wrote: > Dear Vladimir, > > Thank you for also providing singularity and docker containers :) > > I think I spotted a little typo on the website: > - Docker minc-toolkit-v1 1.0.09: docker pull nistmni/minc-toolkit:1.9.16 > Thank you > Best > Steffen > > 2018-01-25 6:33 GMT+10:00 Vladimir S. FONOV : > >> Hello Again, >> >> small correction, the download link for MacOS X version is >> http://packages.bic.mni.mcgill.ca/minc-toolkit/MacOSX/ >> minc-toolkit-1.9.16-20180117-Darwin-x86_64.dmg >> tomorrow it will get updated to the correct one : >> http://packages.bic.mni.mcgill.ca/minc-toolkit/MacOSX/ >> minc-toolkit-1.9.16-20180117-Darwin-10.8-x86_64.dmg >> >> On 24 January 2018 at 14:23, Vladimir S. FONOV >> wrote: >> >>> Hello Everybody, >>> >>> I released a new version of the minc-toolkit-v2, version 1.9.16 >>> >>> It includes all the changes to libminc, minctools, Display, Register etc >>> as of 20181117, also it is build based on NetCDF version 4.5.0, HDF5 >>> version 1.8.20 , ITK version 4.13.0 >>> >>> >>> The links to download are here: http://bic-mni.github.io/ >>> >>> I also created several containers to simplify installation: >>> >>> All Containers are based on Ubuntu 16.04 64bit and include R 3.4.3 + >>> tidyverse + RMINC 1.5.1.0 , python 2.7 + pyminc + pyezminc + minc2_simple >>> and also standard anatomical models and beast templates installed in >>> /opt/minc >>> >>> Docker minc-toolkit-v2 1.9.16: docker pull nistmni/minc-toolkit:1.9.16 >>> Docker minc-toolkit-v1 1.0.09: docker pull nistmni/minc-toolkit:1.9.16 >>> Singularity minc-toolkit-v2 1.9.16: singularity pull --name >>> minc-toolkit-1.9.16.simg shub://vfonov/minc-toolkit-containers:1.9.16 >>> >>> Also I created containers without anatomical templates and visual tools >>> (mostly to save space): >>> >>> Docker minc-toolkit-v2 1.9.16: "docker pull >> nistmni/minc-toolkit-min:1.9.1 >>> 6" >>> Singulatity minc-toolkit-v2 1.9.16: "singularity pull --name >>> minc-toolkit-1.9.16-min.simg shub://vfonov/vfonov/minc-tool >>> kit-containers:1.9.16-min" >>> >>> >>> It is fairly easy to make your own containers, the source code for making >>> containers from above are here: https://github.com/vfonov/minc >>> -toolkit-containers >>> >>> Also, if you need to build minc-toolkit for another distribution , you >> can >>> modify docker-based build system: https://github.com/BIC-MNI/bui >>> ld_packages >>> >>> >>> -- >>> Best regards, >>> >>> Vladimir S. FONOV ~ vladimir.fonov gmail.com >>> >> >> >> >> -- >> Best regards, >> >> Vladimir S. Fonov ~ vladimir fonov gmail com >> _______________________________________________ >> MINC-users at bic.mni.mcgill.ca >> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users >> > _______________________________________________ > MINC-users at bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users > -- Best regards, Vladimir S. FONOV ~ vladimir.fonov gmail.com From vladimir.fonov at gmail.com Sat Feb 3 15:27:06 2018 From: vladimir.fonov at gmail.com (vladimir.fonov at gmail.com) Date: Sat, 3 Feb 2018 15:27:06 -0500 Subject: [MINC-users] stable version of libminc? In-Reply-To: <1608322.4KALzQKMKt@riemann> References: <1608322.4KALzQKMKt@riemann> Message-ID: Hello Steve, I generally build libminc as part of minc-toolkit , so it would be logical to build libminc package based on the version referenced from corresponding release tag of the minc-toolkit. > On Feb 3, 2018, at 14:24, Steve Robbins wrote: > > On Wednesday, January 24, 2018 1:23:55 PM CST Vladimir S. FONOV wrote: >> Hello Everybody, >> >> I released a new version of the minc-toolkit-v2, version 1.9.16 >> >> It includes all the changes to libminc, minctools, Display, Register etc >> as of 20181117, [...] > > Are you taking libminc from the develop branch of git? > > Are users generally using develop? > > I'm in one of my irregular "should update minc for debian" moods. The last > official release I see on github is Sept 2015, which is also the date of the > last activity on the master. Presuming folks generally just build from > develop: I can upload that to Debian. Is the develop tip reasonably stable > today? > > Thanks, > -Steve Best regards, Vladimir S. FONOV ~ v.s.fonov ilmarin.info From zijdenbos at gmail.com Mon Feb 26 00:03:05 2018 From: zijdenbos at gmail.com (Alex Zijdenbos) Date: Mon, 26 Feb 2018 00:03:05 -0500 Subject: [MINC-users] icbm_template stx sampling lattice definitions Message-ID: Hello all, I realized that the way the icbm_sampling lattices are defined, is not ideal for certain applications. Specifically, all the icbm_template_X.XXmm.mnc lattice definitions, all have the same start values, and I believe that the world coordinate origin always falls in the center of a voxel. This gets a bit annoying when dealing with issues of symmetry. E.g., if you are looking to define L/R in these spaces, there is a x=0 plane of voxels for which it is not clear whether it belongs to L or R. By the same token, the bounding boxes of these spaces do not line up, and the voxel dimensions do not follow a regular series, where twice the resolution means twice the number of voxels. I am fairly sure that this inherent asymmetry actually affects the behaviour of some tools as well. I've always thought it would be better to define the standard sampling lattice with respect to the world coordinate origin which would be *between* voxels; such that the lattices, albeit with different start values, would line up with respect to the origin. I don't fully recall why we (Peter?) developed these lattice templates like this back then. Obviously I can define new lattices to suit my needs; but standardization has its benefits :-) Was curious if anybody had any thoughts about this. -- A From vladimir.fonov at gmail.com Mon Feb 26 17:07:37 2018 From: vladimir.fonov at gmail.com (Vladimir S. FONOV) Date: Mon, 26 Feb 2018 17:07:37 -0500 Subject: [MINC-users] icbm_template stx sampling lattice definitions In-Reply-To: References: Message-ID: <79edea4e-de2b-bc3c-b2b8-38335c07ade0@gmail.com> Hello, you can take a look at mni icbm 2009c - it actually uses different sampling then the old mni template, addressing the same problems. On 2018-02-26 12:03 AM, Alex Zijdenbos wrote: > Hello all, > > I realized that the way the icbm_sampling lattices are defined, is not > ideal for certain applications. Specifically, all the > icbm_template_X.XXmm.mnc lattice definitions, all have the same start > values, and I believe that the world coordinate origin always falls in the > center of a voxel. > > This gets a bit annoying when dealing with issues of symmetry. E.g., if you > are looking to define L/R in these spaces, there is a x=0 plane of voxels > for which it is not clear whether it belongs to L or R. By the same token, > the bounding boxes of these spaces do not line up, and the voxel dimensions > do not follow a regular series, where twice the resolution means twice the > number of voxels. I am fairly sure that this inherent asymmetry actually > affects the behaviour of some tools as well. > > I've always thought it would be better to define the standard sampling > lattice with respect to the world coordinate origin which would be *between* > voxels; such that the lattices, albeit with different start values, would > line up with respect to the origin. > > I don't fully recall why we (Peter?) developed these lattice templates like > this back then. Obviously I can define new lattices to suit my needs; but > standardization has its benefits :-) Was curious if anybody had any > thoughts about this. > -- Best regards, Vladimir S. FONOV ~ vladimir.fonov gmail.com